如何在快速變更的環境中開展測試工作

轉自：http://www.51testing.com/?action_viewnews_itemid_10319.html
一句古老的諺語說的，世界上唯一永恆的東西就是改變。在軟件開發過程當中，傳統的開發模式的一個缺

點就是他能夠呈現較少的改變甚至沒有改變。真實世界每天都在改變。正因爲此，其他的開發模式，如快

速應用開發（RAD）已經提升到可以包含改變並在計劃過程中使用改變來精煉開發。

在RAD模式幫助軟件開發者更早的得到更新的版本並更快的運行程序的同時，他也給測試人員帶來很多令

人頭疼的煩惱。因爲每個改變都可能產生新的缺陷。找到新缺陷的唯一的方法就是使用迴歸測試，迴歸測

試可以完整的重複先前的測試過程並與得到的結論進行比較，以便找到不同的地方。

接下來就產生了2個問題：1）能否在快速變更的需求過程中進行徹底的測試？2）在測試快速變更的軟件

時需要採用什麼策略？


 

能否在快速變更的需求過程中進行徹底的測試？

答案是，不能。這是一個惡作劇式的問題，因爲在大多數情況下，即便是在穩定的環境當中，進行徹底的

測試都是不可能的。我們可以將這個問題改成這樣，“能否在快速多變的環境中進行有效的測試？”我們

能否期望在測試軟件時能夠充分有效的利用人力及其他資源？我們能否期望在測試中找到預期數量的缺陷

？

通過觀察使用RAD模式進行開發的項目，我發現要找到缺陷和得到任何程度的成效的本質的部分就是測試

過程。由於在軟件開發中，大多數我們使用的測試標準是規範是使用不重複的過程，所以很多人在測試

RAD環境的軟件時，採用的方法是平時我們在其他環境中使用的方法——在各個不同的地方使用較少的用

例來查找問題和缺陷。


 

我們可以採用什麼樣的策略呢？

研究每個單獨的環境當中需要採用的策略將會耗費過多的時間，這裏有一些通用的策略，可以在快速改變

的測試環境中使用。

首先，你必須接受一個事實，那就是不可能花去6個星期的時間來測試一個天天都在改變的軟件。這就意

味着你需要限定測試過程使得他可以快速並有效的進行。

做一個風險程度的估定。知道風險的標準是關鍵所在，因爲你需要在一個較短的時間內來確定你要測試內

容的優先級。風險越高，冊是的優先級越高。

自動化測試過程。迴歸測試工具幫助你在短時間內進行重複的測試工作。好的工具需要在軟件及培訓方面

進行重要的投資，但他不能一天不間斷的工作。有一些事情需要在自動測試之前考慮並提前做好。

你必須擁有軟件的工作標準文檔來跟將來的測試進行比較。

你必須定義需求，測試用例和測試環境。工具只能記錄並回放基於操作者的操作行爲的活動。

數據維護是關鍵。你將怎樣維護這些測試數據？例如，如果你使用迴歸測試工具來添加一個記錄，腳本文

件將得到“重複的記錄”這樣的錯誤。

這將耗費相當多的時間以及金錢來使得這個工具融入到你們的公司。在此之前還必須對相關人員進行工具

使用的培訓。因此，必須使人們相信，跟目前工作當中需要建立測試腳本和測試用例這些瑣碎的事情相比

，這樣做對於長期利益的發展是非常有價值的。

在快速多變的環境中進行測試並不是不可能的，但是他需要能夠做出快速的響應，靈敏的進行操作，並且

與變更的軌跡保持一致。那些不願意考慮新技術，如自動化測試的公司、組織將不能在快速多變的開發環

境中開展有效的測試工作。這就好比是手工工具來蓋一座房子，很顯然他最終是無法成功的。

    在快速多變開發環境中同樣也需要一個對於機構和過程的新觀念。單獨使用工具並不是最終的答案。

必須有一個能快速執行並且充分有效的利用人力資源和時間的操作程序。要達到工具使用、操作程序以及

人力的完美結合，必將是一個很大的挑戰。


英文原文：

Testing During Rapid Change


 

As the old adage goes, "the one thing that remains constant is change." In software

development, one of the weaknesses of the classic waterfall approach is that it assumes

little or no change. The real world changes every day. Because of this, other development

models such as Rapid Application Development (RAD) have been promoted to embrace change and

use it to refine the software through planned iterations.

While RAD helps software developers get early versions up and running very quickly, it

causes testers many headaches. With each and every change is the opportunity to create new

defects. The only way to find new defects is to perform a regression test which completely

repeats a previous test and compares the results to find differences.

Two questions come to mind: 1) "Is it possible to completely test during rapid change?", and

2) "Which strategies can be used to test rapidly changing software?"


 

Is It Possible to Completely Test During Rapid Change?

Actually, no. However, that's a trick question because in most cases it is not possible to

completely test software even in stable environments1. The essence of this question might be

to ask, "Is it possible to test effectively during rapid change?" Can we expect to make the

best use of people and other resources to test software? Can we expect to find the expected

number of defects?

By observing projects using RAD, I have observed that a process for testing is essential to

finding defects with any degree of effectiveness. Since the norm is to have no repeatable

processes for most of what we do in building software, many people test in a RAD environment

the same way they do in other environments - try a few cases here and there and look for

problems.


 

Which Strategies Can Be Used?

It takes time to learn what works in each unique environment, but here are some general

strategies that can be used for testing during rapid change:

First of all, accept the fact that you do not have the luxury of performing a six week test

on software that changes every day. This means you will need to define a testing process

that can be performed quickly and efficiently.

Perform a risk assessment. Knowing the level of risk is crucial, since you will need to

prioritize your testing efforts to fit within a short window of time. The higher the risk,

the higher the testing priority.

Automate your testing. Capture/playback tools help you perform repeatable tests in an

unattended session. Good tools require a significant investment in software and training,

but it beats working 24 hours a day. Some things to consider before automating:

You must have a working baseline version of the software to perform comparisons with future

tests.

You must define business requirements, test cases and test scenarios. The tool can only

record and playback based on what actions the user performs.

Data is a key consideration. How will you maintain the test data? For example, if you use a

capture/playback tool to add a record, a reply of the scrīpt will get a "duplicate record on

file" error.

It takes time and a whole lot of spending money to integrate the tool into your

organization. People need to be trained in how to use the tool. In addition, people need to

be sold on the long-term benefits as compared to the short-term work required to setup the

test scrīpts and test cases.

Testing during rapid change is not impossible, but it does require rapid response, working

smart, and keeping track of changes. Organizations that have been unwilling to consider new

technologies such as automated testing tools will not be able to effectively test during

rapid change. It is like building a house with hand tools - sure it can be done, eventually.

Testing during rapid change also requires a new mindset of organization and processes. Tools

alone are not the answer. There must be a process that can be executed quickly and makes the

best use of people and time. It is arriving at the optimal combination of tools, processes,

and people that is the challenge.