使用風險分析，確定測試的重點

由于很少有機會對一個應用軟件進行所有可能的測試 (包括所有可能的事件組合、所有的相關性、或者一切可能出錯的東西)，對大多數(shù)軟件開發(fā)項目來說，利用風險分析是適當?shù)摹?/p>

這需要判斷技能、常識、感覺和經(jīng)驗。如果有正當理由，也可采用正式的方法。需要考慮下列因素：

對于該項目的用途而言，哪種功能最重要?

哪種功能對用戶最明顯?

哪種功能對安全影響最大?

哪種功能對用戶最有用?

對客戶來說，該應用軟件的哪個部分最重要?

在開發(fā)過程中，該應用軟件的哪個部分可以最先測試?

哪一部分代碼最復雜，容易導致出現(xiàn)錯誤?

哪一部分的應用程序是在急迫或在驚恐的情況下開發(fā)出來的?

哪一部分程序與過去項目中引起問題的部分相類似/有關?

哪一部分程序與過去項目中需要大量維護的部分相類似/有關?

需求和設計的那些部分不清楚或不容易讀?

開發(fā)人員認為在應用軟件中哪些部分是高風險的?

哪些問題能造成最差的發(fā)行?

哪些問題最能引起用戶抱怨?

哪些測試可以容易地覆蓋多種功能?

哪些測試在覆蓋高風險部分的測試時使用時間最少?

如果需求一直在變化怎么辦?

這是一個常見的令人頭疼的問題。

如果可能，盡早與承擔該項目風險的人接觸，以便了解需求會怎樣改變，從而可以盡早地改變測試計劃和策略。

如果在對應用程序進行初始設計時多考慮一些適應性，那么以后在發(fā)生需求的改變時，就不需要再為改變做很多事情了。

好的代碼注釋和好的文檔有助于開發(fā)人員作出相應的改變。

只要有可能，就應使用快速原型 (rapid prototyping)，以幫助用戶確認他們的需求，從而減少變更。

在項目的時間表中應當留出余量，以應付可能出現(xiàn)的變更。

盡量把新的需求納入應用軟件的“下一版”，而把原始需求作為“第一版”。

通過談判，把易于實現(xiàn)的新的變更列入項目，而把難于實現(xiàn)的新需求列入該應用軟件的以后的版本。

要確保讓客戶和管理人員了解變更對進度表的影響、所帶來的風險、以及因變更所引起的大量資金消耗。

在應付改變時，應在為建立自動測試而作的努力和重新進行測試所做的努力之間取得平衡。

在設計自動測試劇本時，試圖使其有一些靈活性。

在對應用軟件進行自動測試時，要把注意力集中在看來不大會改變的部分。

對變更進行適當?shù)娘L險分析，以減少回歸測試的要求。

在設計測試案例時要有一定的靈活性。做到這一點并不容易，所以要降低測試案例的詳細程度，或者只建立高級的通用型的測試計劃。

少注意詳細的測試計劃和測試案例，要把重點放在專門的測試 (ad hoc testing) 上。

面向?qū)ο蟮脑O計如何影響測試?

好的面向?qū)ο蟮墓こ淘O計使得從代碼追溯內(nèi)部設計、再到功能測試，最后追溯到需求，成為一件容易的事。

因為它對黑盒測試的影響很少 (不需要了解應用軟件的內(nèi)部設計) ，而白盒測試只需針對該應用軟件的對象。如果該應用軟件設計得好，就可簡化測試設計。