1.1測試策略和計劃
在制定測試策略時，要基于被測軟件的質(zhì)量目標(biāo)。質(zhì)量目標(biāo)就是測試的需求。它們決定了測試的階段和質(zhì)量的目標(biāo)。要想最優(yōu)化測試的活動并制定一個切實可行的測 試計劃，需要將被測軟件分解成為一個一個的業(yè)務(wù)功能。在進(jìn)行業(yè)務(wù)功能分解時，要以黑盒的方法來看待被測軟件的功能，即獨立于軟件的實現(xiàn)方法。若想計算測試 的效果并且保證測試的活動適合于特定業(yè)務(wù)的需要，則需要引入風(fēng)險評估的手段。
1.1.1 需求
測試的必要條件是要確定預(yù)期結(jié)果或者需求。為了能更好的了解需求，將需求進(jìn)行分類是非常有幫助的。以我們的觀點，可以將需求分為功能性需求和質(zhì)量需求（非功能性需求）。功能性需求描述了在業(yè)務(wù)上期望如何使用新的軟件系統(tǒng)，且該系統(tǒng)中應(yīng)該包括哪些功能。質(zhì)量需求包括的是軟件系統(tǒng)的通用特性，且獨立于功能。
1.1.1.1 功能性需求
功能性需求以業(yè)務(wù)設(shè)計圖的方式記錄于文檔中。為了在TestDirector中將需求作為測試的基礎(chǔ)，需要將需求導(dǎo)入到TestDirector中。相應(yīng)的業(yè)務(wù)設(shè)計圖作為需求的附件存在，并作為將來測試活動的依據(jù)。
1.1.1.2 質(zhì)量需求
質(zhì)量需求由兩部分構(gòu)成，一部分是為整個產(chǎn)品或者項目定義的質(zhì)量目標(biāo)，另一部分是每個業(yè)務(wù)功能的質(zhì)量需求，這些業(yè)務(wù)功能的質(zhì)量需求取決于風(fēng)險評估的結(jié)果。
1.1.1.2.1 質(zhì)量目標(biāo)
1）適應(yīng)性
組件被修改以適應(yīng)新需求的難易程度。
2）完整性
組件實現(xiàn)所有需要的能力的程度。
3）正確性
a) 組件在規(guī)格分析、設(shè)計和實現(xiàn)過程中無錯誤的程度
b) 組件滿足需求或者用戶需要與期望的程度
c) 基于給定輸入產(chǎn)生相應(yīng)輸出的能力，并且這個過程符合或者滿足需求
4）有效性
當(dāng)組件完成指定任務(wù)時，能最少使用所需資源的程度。
5）可維護(hù)性
組件被修改以糾正錯誤，提高性能或其他屬性，或者適應(yīng)被改變了的環(huán)境的難易程度
6）模塊性
軟件系統(tǒng)由離散的組件組成的程度，即改變一個組件時能將對其他組件的影響降至最低。
7）可移植性
軟件系統(tǒng)或組件能被轉(zhuǎn)移到其他硬件平臺或者軟件平臺上的難易程度。
8）可靠性
組件在一定的時間內(nèi)、一定的條件下執(zhí)行所需完成功能的能力。
9）可用性
用戶對軟件組件的理解和操作的難易程度。
1.1.1.2.2 業(yè)務(wù)功能的質(zhì)量需求
業(yè)務(wù)功能的質(zhì)量需求是依據(jù)業(yè)務(wù)的風(fēng)險進(jìn)行定義的。業(yè)務(wù)風(fēng)險和技術(shù)復(fù)雜度的信息存儲在測試的需求中。這兩個參數(shù)決定了測試的程序和測試的工作量。另外，針對業(yè)務(wù)功能分配測試員，并且將測試活動的當(dāng)前狀態(tài)落實到紙面上。只有這樣做才能在針對業(yè)務(wù)功能的整個測試過程中監(jiān)控測試的狀態(tài)。
1.1.2 測試階段的定義
依據(jù)已經(jīng)定義的質(zhì)量目標(biāo)，我們需要將測試階段進(jìn)行合理的劃分。
通常情況有以下幾個階段：
1）開發(fā)員自測試階段（不在我們的考慮范圍之內(nèi)）
2）業(yè)務(wù)功能測試（單元測試）
3）業(yè)務(wù)流程測試（應(yīng)用級的集成測試）
4）業(yè)務(wù)集成測試（端到端的集成測試）
5）性能測試
6）系統(tǒng)集成測試
下面的表中描述了每個測試階段需要達(dá)到的質(zhì)量目標(biāo)：
業(yè)務(wù)功能測試和業(yè)務(wù)流程測試是在軟件項目開發(fā)過程中完成的。而業(yè)務(wù)集成測試和系統(tǒng)集成測試則組合成回歸測試，用于軟件系統(tǒng)上線前或者發(fā)布為產(chǎn)品前來檢驗軟件的質(zhì)量。
1.1.3 質(zhì)量門
測試是在不同的階段中完成的。劃分不同階段的原因就是將不同的質(zhì)量目標(biāo)分配到不同的階段中，從而能將測試的執(zhí)行盡可能的提前。所以，在相鄰的測試階段中設(shè)置一個質(zhì)量門就成為保障成功的關(guān)鍵要素。
下面的圖中展示了每兩個相鄰階段的質(zhì)量門是如何設(shè)定的：
下面是對質(zhì)量門的一種詳細(xì)定義：
1）在業(yè)務(wù)功能測試之后
u 業(yè)務(wù)功能測試的測試用例執(zhí)行了80%以上
u 業(yè)務(wù)功能測試的測試用例（A級風(fēng)險）執(zhí)行了100%
u 少于5個服務(wù)器端錯誤
u 少于30個中級錯誤
u 無致命性缺陷
2）在業(yè)務(wù)流程測試之后
u 業(yè)務(wù)功能測試通過
u 業(yè)務(wù)流程執(zhí)行了100%
u 無業(yè)務(wù)流程完全失效，所有的錯誤都可以被修復(fù)
u 無致命性缺陷
3）在業(yè)務(wù)集成測試之后
u 業(yè)務(wù)流程測試通過
u 業(yè)務(wù)集成流程執(zhí)行了100%
u 無致命性缺陷
1.1.4 功能分解
在計劃測試活動之前，功能分解應(yīng)該作為第一個要完成的活動。進(jìn)行功能分解時，應(yīng)該邀請業(yè)務(wù)方面和需求分析方面的代表共同參加。通常情況下，要遵從下面的原則：
1) 每個用戶情形都是一個業(yè)務(wù)功能
2) 如果一組用戶情形非常相似，那它們應(yīng)該組合在一起形成一個業(yè)務(wù)功能
3) 如果一個用戶情形非常大或者非常復(fù)雜，則應(yīng)該將其分解為兩個或者更多的業(yè)務(wù)功能
進(jìn)行功能分解的思路體現(xiàn)在“將測試的單元確定為包含少量功能點的單位”，這樣，每個測試單元的測試用例的數(shù)量就會被限制在一定的范圍之內(nèi)。我們可以將分解的目標(biāo)設(shè)定為每個業(yè)務(wù)功能只有最多30-40個測試用例。 既然質(zhì)量保證的基本思路是降低缺陷破壞業(yè)務(wù)的風(fēng)險，同時為了確保質(zhì)量保證的資源得到充分的利用，我們需要對每個業(yè)務(wù)功能進(jìn)行風(fēng)險的評估。
1.1.5 風(fēng)險評估
還要考慮到的是，我們也要對技術(shù)影響進(jìn)行分析。這樣我們能對完成每個業(yè)務(wù)功能的測試活動所需的工作量進(jìn)行估算。
1.1.5.1 業(yè)務(wù)風(fēng)險分析
業(yè)務(wù)風(fēng)險評估需要針對被測軟件的所有業(yè)務(wù)功能。評估的標(biāo)準(zhǔn)應(yīng)該在整個業(yè)務(wù)的范圍內(nèi)是唯一的，才能在企業(yè)范圍內(nèi)使不同的評估結(jié)果具有可比性。
| 結(jié)果 標(biāo)準(zhǔn) | A 高級風(fēng)險 | B 中級風(fēng)險 | C 低級風(fēng)險 |
| 流程的類型 | 計算/驗證 | 數(shù)據(jù)的改變 | 顯示 |
| 業(yè)務(wù)影響 | 合法性 | 錯誤信息 | 無 |
| 使用頻度 | 非常頻繁 | 經(jīng)常 | 極少 |
| 受影響客戶的數(shù)量 | 大量/非常重要 | |