用例編號是根據(jù) 項(xiàng)目名模塊名功能名
1.測試用例的概念和作用
對一個(gè)測試工程師來說,測試用例的設(shè)計(jì)編寫是一項(xiàng)必須掌握的能力，但有效的設(shè)計(jì)和熟練的編寫測試用例卻是一個(gè)十分復(fù)雜的技術(shù)，測試用例編寫者不僅要掌握軟件測試技術(shù)和流程，而且要對整個(gè)軟件不管從業(yè)務(wù)，還是對軟件的設(shè)計(jì)、程序模塊的結(jié)構(gòu)、功能規(guī)格說明等都要有透徹的理解。
測試的設(shè)計(jì)方法不是單獨(dú)存在的，具體到每個(gè)測試項(xiàng)目里都有很多種方法，每種類型都有各自的特點(diǎn)。
1.測試用例的定義：
A.80**100 有效的測試用例
B.測試用例的覆蓋度 80%左右
任意的測試用例都含有 用例編號 （項(xiàng)目名字—模塊名字_用例編號）
所屬模塊
執(zhí)行條件
測試輸入（具體的執(zhí)行步驟 ）
預(yù)期結(jié)果
實(shí)際結(jié)果
用例是否通過
測試人（執(zhí)行測試用例的人）
版本
備注
測試用例是執(zhí)行測試的依據(jù)，把測試系統(tǒng)的操作步驟用文檔的形式描述出來
（1）測試用例是為達(dá)到最佳的測試效果或高效的揭露隱藏的錯(cuò)誤，而精心設(shè)計(jì)的少量測試數(shù)據(jù)，包括測試輸入、執(zhí)行條件和預(yù)期的結(jié)果，實(shí)際結(jié)果
（2）測試用例是執(zhí)行的最小實(shí)體。
（3）測試用例是測試工作的指導(dǎo)，是軟件測試的必須遵守的準(zhǔn)則，更是軟件測試質(zhì)量穩(wěn)定的根本保障
2.測試用例的特征：
1、正確性：測試用例最好是要求輸入用戶實(shí)際數(shù)據(jù)已驗(yàn)證系統(tǒng)是否滿足需求規(guī)格說明書的需求，并且測試用例中的測試的應(yīng)保證至少覆蓋需求規(guī)格說明書中的各項(xiàng)功能。
2、完整性：一些基本功能，如有遺漏，那是不可原諒的。
3、準(zhǔn)確：按測試用例輸入實(shí)施測試后，要能根據(jù)測試用例描述的輸出得出正確的結(jié)論，不能出現(xiàn)模糊不清的語言。
4、清晰、簡潔：好的測試用例描述清晰，每一步都應(yīng)有相應(yīng)的作用，有很強(qiáng)的的針對性，不應(yīng)出現(xiàn)一些無用的操作步驟。
5、可維護(hù)性：由于軟件開發(fā)過程中需求變更等原因的影響，常常對測試用例進(jìn)行修改、增加、刪除等，以便測試用符合相應(yīng)測試要求。
6、適應(yīng)性：測試用例應(yīng)該適合特定的測試環(huán)境以及符合整個(gè)團(tuán)隊(duì)的測試水平。
7、可重復(fù)性：要求不同測試者在同樣的測試環(huán)境下使用同樣測試用例都能得出相應(yīng)結(jié)論。
8、可追溯性、可移植性
3.編寫測試用例的好處：
測試用例的作用：
在開始實(shí)施測試之前設(shè)計(jì)好測試用例，可以避免盲目測試并提高測試效率。
測試用例的使用令軟件測試的實(shí)施重點(diǎn)突出、目的明確。
在軟件版本更新后只需修正少部分的測試用例便可展開測試工作，降低工作強(qiáng)度、縮短項(xiàng)目周期。
檢驗(yàn)軟件是否滿足客戶需求、體現(xiàn)一個(gè)測試人員的工作量、展現(xiàn)測試用例的設(shè)計(jì)思路
功能模塊的通用化和復(fù)用化使軟件易于開發(fā)，而相對于功能模塊的測試用例的通用化和復(fù)用化則會(huì)使軟件測試易于開展，并隨著測試用例的不斷精化其效率也不斷攀升。
2.需求分析
1.什么是需求？
需求：客戶的需要的東西以及對東西的要求
2.需求的種類有什么？
1.用戶需求：關(guān)注系統(tǒng)是否滿足用戶習(xí)慣
2.行業(yè)業(yè)務(wù)需求（界面提示信息為行業(yè)術(shù)語，處理和操作模式為行業(yè)從業(yè)人員習(xí)慣模式等）
3.實(shí)際使用環(huán)境需求（網(wǎng)絡(luò)帶寬，速率，斷電數(shù)據(jù)備份，軟件部署設(shè)置等）
4.操作使用需求（類似快捷鍵，緊急關(guān)閉，數(shù)據(jù)恢復(fù)保護(hù)，回退機(jī)制，安裝兼容性，語言環(huán)境等）
5.用戶需求引發(fā)的測試需求（按軟件測試質(zhì)量模型進(jìn)行劃分）
6.功能需求：關(guān)注系統(tǒng)是否滿足功能要求
3.測試用例的設(shè)計(jì)方法和編寫
1.如何設(shè)計(jì)測試用例？
對各個(gè)功能模塊進(jìn)行測試點(diǎn)分析提取測試點(diǎn)再對測試點(diǎn)進(jìn)行用例編寫
比如對PC端QQ賬號的登錄模塊，提取測試點(diǎn)就有：
①正常登陸
②賬號為空時(shí)點(diǎn)擊登錄
③密碼為空時(shí)點(diǎn)擊登錄
④賬號密碼都為空時(shí)點(diǎn)擊 登錄
⑤密碼錯(cuò)誤時(shí)點(diǎn)擊登錄
⑥找回密碼功能是否有效
⑦記住密碼功能是否有效
⑧ 自動(dòng)登錄功能是否有效
9 多個(gè)qq號登錄
10.二維碼掃描登錄
2.編寫測試用例該注意什么？
根據(jù)產(chǎn)品規(guī)格，測試基本功能；
考慮設(shè)計(jì)一般用戶（非專業(yè)人員）的使用方案；
考慮設(shè)計(jì)稀有或特殊的使用方案；
與系統(tǒng)其他組成部分的配合（如FAX和上網(wǎng)可能要用到MODEM，？測試中考慮對設(shè)備的共享）；
考慮特殊情況（如內(nèi)存和硬件的沖突等）；
設(shè)計(jì)極端情況（如內(nèi)存泄漏、破壞性測試等）；
好的測試用例集能花費(fèi)最小的代價(jià)（人力、物力、財(cái)力、時(shí)間）做最好的測試。
3.測試用例的4個(gè)特性
1.代表性：能夠代表并覆蓋各種合理的和不合理、合法的和不合法的、邊界的和越界的以及極限的輸入數(shù)據(jù)、操作等。
2.針對性：對程序中的可能存在的錯(cuò)誤有針對性地測試
3.可判定性：測試執(zhí)行結(jié)果的正確性是可判定的，每一個(gè)測試用例都應(yīng)有相應(yīng)的期望結(jié)果
4.可重現(xiàn)性：對同樣的測試用例，系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是相同的。
第一個(gè)數(shù)字 和 第二個(gè)數(shù)字都為 0-10 之間的數(shù) 計(jì)算結(jié)果
？ + ？ = ？
1-10 1 -10 正向測試用例
反向
4.測試用例通常包括以下幾個(gè)組成元素：
測試用例編號 測試用例名稱 測試用例設(shè)計(jì)者 軟件版本號 測試目的
參考信息 測試環(huán)境 輸入數(shù)據(jù)操作步驟 預(yù)期結(jié)果 測試結(jié)果 測試功能模塊
5.測試用例示例
你用到的測試方法/測試策略有哪些？
等價(jià)類劃分 邊界值 因果圖 場景法 正交表
等價(jià)類劃分 場景法 因果圖 判定法 正交法 錯(cuò)誤推斷法
4.編寫測試用例的基本方法
1.等價(jià)類劃分法
1..概念
有效，無效
等價(jià)類劃分是指分步驟地把海量（無限）的測試用例集減得很小，但過程同樣有效。
等價(jià)類 ：何為等價(jià)類，某個(gè)輸入域的集合，在這個(gè)集合中每個(gè)輸入條件都是等效的。
一般可分為有效等價(jià)類和無效等價(jià)類
比如：在一個(gè)系統(tǒng)中，填寫一個(gè)多少歲的未成年人數(shù)學(xué)考了多少分（假設(shè)成年人年齡為x,0<x<=18,數(shù)學(xué)成績?yōu)閥：0<=y<=100
那么年齡按照等價(jià)類劃分可分為x<0,0<x<=18,x>18,有效等價(jià)類是0<x<=18，無效等價(jià)類是x<0，x>18
數(shù)學(xué)成績按照等價(jià)類劃分可分為y<0,0<=y<=100,y>100,有效等價(jià)類是0<=y<=100，無效等價(jià)類是y<0，y>100
示例
計(jì)算兩個(gè)1～100之間整數(shù)的和。
如果要進(jìn)行完全測試，一共要設(shè)計(jì)多少個(gè)測試用例呢？加數(shù)1有1～100共計(jì)100個(gè)取值，加數(shù)2也有1～100共計(jì)100個(gè)取值，所以他們之間的組合就有100*100=10000種組合可能，但這只是測試了正常范圍內(nèi)的取值。如果用戶輸入的數(shù)據(jù)不在1～100之間呢，窮舉測試肯定不可能的。由此引入了等價(jià)類劃分思想。
等價(jià)類劃分為：
有效等價(jià)類：指符合《需求規(guī)格說明書》，輸入合理的數(shù)據(jù)集合
無效等價(jià)類：指不符合《需求規(guī)格說明書》，輸入不合理的數(shù)據(jù)集合
我們將輸入域分成了一個(gè)有效等價(jià)類（1～100）和兩個(gè)無效等價(jià)類（<1,>100），并為每一個(gè)等價(jià)類進(jìn)行編號，然后我們就可以從每一個(gè)等價(jià)類中選取一個(gè)代表性的數(shù)據(jù)來測試，設(shè)計(jì)如下表所示的測試用例
在任意文本輸入框中可以填寫的 字符類型 中文 英文 特殊符號 空格 數(shù)字
2.邊界值法
一般邊界值分析是因?yàn)槌绦蜷_發(fā)循環(huán)體時(shí)的取數(shù)可能會(huì)因?yàn)?lt;,<=搞錯(cuò)。
比如下面代碼
for(int i = 0;i <100; i ++) 有效等價(jià)劃分 -1 0 100 101
{
int j = i+1;
System.out.println("循環(huán)第“+j+"次")//循環(huán)地做某件事情
}
這里的程序是循環(huán)了100次，所以會(huì)做100次;
如果程序員不小心，把i <100寫成i <= 100，則會(huì)溢出，這時(shí)候邊界值檢查是一個(gè)很好的測試方法。
比如：在一個(gè)系統(tǒng)中，填寫一個(gè)多少歲的成年人數(shù)學(xué)考了多少分（假設(shè)成年人年齡為x,0<x<=18,數(shù)學(xué)成績?yōu)閥：0<=y<=100
根據(jù)上面的等價(jià)類劃分法我們可知，年齡的有效等價(jià)類是0<x<=18，所以邊界值就是0，1，18，19
數(shù)學(xué)成績的,有效等價(jià)類是0<=y<=100，所以邊界值就是-1，0，100，101
對數(shù)據(jù)進(jìn)行軟件測試，就是在檢查用戶輸入的信息、返回的結(jié)果以及中間計(jì)算結(jié)果是否正確。即使最簡單的程序要處理的數(shù)據(jù)量也可能極大，使這些數(shù)據(jù)得以測試的技巧是，根據(jù)一些關(guān)鍵的原則進(jìn)行等價(jià)類的劃分，以合理減少測試用例，這些關(guān)鍵的原則是：邊界條件，次邊界條件、空值和無效數(shù)據(jù)。
確定邊界值的方法（）
確定邊界情況（輸入或輸出等價(jià)類的邊界）
選取正好等于、剛剛大于或剛剛小于邊界值作為測試數(shù)據(jù)
輸入要求是1 ～ 100之間的整數(shù)，因此自然產(chǎn)生了1和100兩個(gè)邊界，我們在設(shè)計(jì)測試用例的時(shí)，要重點(diǎn)考慮這兩個(gè)邊界問題。
注明:邊界值不是從每個(gè)等價(jià)類中挑一個(gè)作為代表，而是把每個(gè)等價(jià)類的邊界都進(jìn)行測試。
3.因果圖法
1.概念:
因果圖法比較適合輸入條件比較多的情況，測試所有的輸入條件的排列組合。所謂的原因就是輸入，所謂的結(jié)果就是輸出。
2.因果圖基本圖形符號
恒等：若原因出現(xiàn)，則結(jié)果出現(xiàn)；若原因不出現(xiàn)，則結(jié)果不出現(xiàn)。
非（～）：若原因出現(xiàn)，則結(jié)果不出現(xiàn)；若原因不出現(xiàn)，則結(jié)果出現(xiàn)。
或（∨）：若幾個(gè)原因中有一個(gè)出現(xiàn)，則結(jié)果出現(xiàn)；若幾個(gè)原因都不出現(xiàn)，則結(jié)果不出現(xiàn)。
與（∧）：若幾個(gè)原因都出現(xiàn)，結(jié)果才出現(xiàn)；若其中有一個(gè)原因不出現(xiàn)，則結(jié)果不出現(xiàn)。
3.因果圖的約束符號
E（互斥）：表示兩個(gè)原因不會(huì)同時(shí)成立，兩個(gè)中最多有一個(gè)可能成立
I（包含）：表示三個(gè)原因中至少有一個(gè)必須成立
O（惟一）：表示兩個(gè)原因中必須有一個(gè)，且僅有一個(gè)成立
R（要求）：表示兩個(gè)原因，a出現(xiàn)時(shí)，b也必須出現(xiàn)，a出現(xiàn)時(shí)，b不可能不出現(xiàn)
M（屏蔽）：兩個(gè)結(jié)果，a為1時(shí)，b必須是0，當(dāng)a為0時(shí)，b值不定
判定表法
4.場景法
1.測試用例設(shè)計(jì)的思想
現(xiàn)在的軟件幾乎都是用事件觸發(fā)來控制流程的，事件觸發(fā)時(shí)的情景便形成了場景，而同一事件不同的觸發(fā)順序和處理結(jié)果就形成事件流。這種在軟件設(shè)計(jì)方面的思想也可以引入到軟件測試中，可以比較生動(dòng)地描繪出事件觸發(fā)時(shí)的情景，有利于測試設(shè)計(jì)者設(shè)計(jì)測試用例，同時(shí)使測試用例更容易理解和執(zhí)行。
用例場景是通過描述流經(jīng)用例的路徑來確定的過程，
這個(gè)流經(jīng)過程要從用例開始到結(jié)束遍歷其中所有基本流和備選流。
基本流和備選流
如圖所示，圖中經(jīng)過用例的每條路徑都用基本流和備選流來表示，直黑線表示基本流，是經(jīng)過用例的最簡單的路徑。備選流用不同的色彩表示，一個(gè)備選流可能從基本流開始，在某個(gè)特定條件下執(zhí)行，然后重新加入基本流中（如備選流1和3）；也可能起源于另一個(gè)備選流（如備選流2），或者終止用例而不再重新加入到某個(gè)流（如備選流2和4）。
遵循上圖中每個(gè)經(jīng)過用例的可能路徑，可以確定不同的用例場景。從基本流開始，再將基本流和備選流結(jié)合起來，可以確定以下用例場景：
場景 1 基本流
場景 2 基本流 備選流 1
場景 3 基本流 備選流 1 備選流 2
場景 4 基本流 備選流 3
場景 5 基本流 備選流 3 備選流 1
場景 6 基本流 備選流 3 備選流 1 備選流 2
場景 7 基本流 備選流 4
場景 8 基本流 備選流 3 備選流 4
注：為方便起見，場景 5、6 和 8 只描述了備選流 3 指示的循環(huán)執(zhí)行一次的情況。
2.銀行案例ATM:
個(gè)人標(biāo)識號 (PIN＝personal identification number )，用于保護(hù)智能卡免受誤用的秘密標(biāo)識代碼。PIN 與密碼類似，只有卡的所有者才知道該 PIN。只有擁有該智能卡并知道 PIN 的人才能使用該智能卡
第一次測試中，根據(jù)測試計(jì)劃，我們需要核實(shí)提款用例已經(jīng)正確地實(shí)施。此時(shí)尚未實(shí)施整個(gè)用例，只實(shí)施了下面的事件流：
基本流-提取預(yù)設(shè)金額（100 元、200元、500元、1000元）
備選流2 - ATM 內(nèi)沒有現(xiàn)金
備選流3 - ATM 內(nèi)現(xiàn)金不足
備選流4 - PIN 有誤
備選流5 - 帳戶不存在/帳戶類型有誤
備選流6 - 帳面金額不足
對于這7個(gè)場景中的每一個(gè)場景都需要確定測試用例。可以采用矩陣或決策表來確定和管理測試用例。
從確定執(zhí)行用例場景所需的數(shù)據(jù)元素入手構(gòu)建矩陣。然后，對于每個(gè)場景，至少要確定包含執(zhí)行場景所需的適當(dāng)條件的測試用例。
下面顯示了一種通用格式，其中各行代表各個(gè)測試用例，而各列則代表測試用例的信息。
本示例中，對于每個(gè)測試用例，存在一個(gè)測試用例ID、條件（或說明）、測試用例中涉及的所有數(shù)據(jù)元素（作為輸入或已經(jīng)存在于數(shù)據(jù)庫中）以及預(yù)期結(jié)果。
5.錯(cuò)誤推測法
錯(cuò)誤猜測法是測試經(jīng)驗(yàn)豐富的人喜歡使用的一種測試用例設(shè)計(jì)方法。
一般這種方法是基于經(jīng)驗(yàn)和直覺推測程序中可能發(fā)送的各種錯(cuò)誤，有針對性地設(shè)計(jì)。只能作為一種補(bǔ)充。
例如，測試手機(jī)終端的通話功能，可以設(shè)計(jì)各種通話失敗的情況來補(bǔ)充測試用 例：
1.無SIM 卡插入時(shí)進(jìn)行呼出（非緊急呼叫）
2.插入已欠費(fèi)SIM卡進(jìn)行呼出
3.射頻器件損壞或無信號區(qū)域插入有效SIM卡呼出
4.網(wǎng)絡(luò)正常，插入有效SIM卡，呼出無效號碼（如1、888、333333、不輸入任何號碼等）
5.網(wǎng)絡(luò)正常，插入有效SIM卡，使用“快速撥號”功能呼出設(shè)置無效號碼的數(shù)字
技巧：最重要的是要思考和分析測試對象的各個(gè)方面，多參考以前發(fā)現(xiàn)的bug的相關(guān)數(shù)據(jù)，總結(jié)的經(jīng)驗(yàn)，個(gè)人多考慮異常的情況、反面的情況、特殊的輸入，以一個(gè)攻擊者的態(tài)度對待程序，就能設(shè)計(jì)出比較完善的測試用例來。
6.正交表法
正交實(shí)驗(yàn)法就是利用排列整齊的表 -正交表來對試驗(yàn)進(jìn)行整體設(shè)計(jì)、綜合比較、統(tǒng)計(jì)分析，實(shí)現(xiàn)通過少數(shù)的實(shí)驗(yàn)次數(shù)找到較好的生產(chǎn)條件，以達(dá)到最高生產(chǎn)工藝效果，這種試驗(yàn)設(shè)計(jì)法是從大量的試驗(yàn)點(diǎn)中挑選適量的具有代表性的點(diǎn)，利用已經(jīng)造好的表格—正交表來安排試驗(yàn)并進(jìn)行數(shù)據(jù)分析的方法。正交表能夠在因素變化范圍內(nèi)均衡抽樣，使每次試驗(yàn)都具有較強(qiáng)的代表性，由于正交表具備均衡分散的特點(diǎn)，保證了全面實(shí)驗(yàn)的某些要求，這些試驗(yàn)往往能夠較好或更好的達(dá)到實(shí)驗(yàn)的目的。正交實(shí)驗(yàn)設(shè)計(jì)包括兩部分內(nèi)容：第一，是怎樣安排實(shí)驗(yàn)；第二，是怎樣分析實(shí)驗(yàn)結(jié)果。
應(yīng)用場景：在一個(gè)界面中有多個(gè)控件，每個(gè)控件有多個(gè)取值，控件之間可以相互組合，不可能（也沒有必要）為每一種組合編寫一條用例，如何使用最少最優(yōu)的組合進(jìn)行測試。——正交排列法
判定表，因果圖也是考慮控件組合，但是組合數(shù)量較少（一般不會(huì)超過20中）
公式：Ln(mk)
k是表的列數(shù)，表示控件的個(gè)數(shù)（因數(shù)個(gè)數(shù)）
m是每個(gè)控件的取值個(gè)數(shù)（因數(shù)水平）
n是表的行數(shù)，也就是需要測試組合的次數(shù)
正交表查詢地址：<u>https://www.york.ac.uk/depts/maths/tables/orthogonal.htm</u>
正交排列法：<u>http://support.sas.com/techsup/technote/ts723_Designs.txt</u>
正交表測試用例設(shè)計(jì)方法的特點(diǎn)是什么？
1、用最少的實(shí)驗(yàn)覆蓋最多的操作，測試用例設(shè)計(jì)很少，效率高，但是很復(fù)雜；
2、對于基本的驗(yàn)證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復(fù)雜的缺陷，還是無能為力 的；
3、體的環(huán)境下，正交表一般都很難做的。大多數(shù)，只在系統(tǒng)測試的時(shí)候使用此方法。
5.測試用例的評審和變更
測試用例并非一成不變。如果軟件修改之后發(fā)生變化，或者需求發(fā)生變更，那么測試用例便不再滿足當(dāng)前版本軟件的測試需求，由此需要進(jìn)行修改和變更操作。
首先要清楚內(nèi)部評審的定義，是測試組內(nèi)部的評審，還是項(xiàng)目組內(nèi)部的評審。評審的定義不同，內(nèi)容也不會(huì)相同。
如果是測試組內(nèi)部的評審，應(yīng)該著重于：
1.測試用例本身的描述是否清晰，是否存在二義性；
2.是否考慮到測試用例的執(zhí)行效率.往往測試用例中步驟不斷重復(fù)執(zhí)行，驗(yàn)證點(diǎn)卻不同，而且測試設(shè)計(jì)的冗余性，都造成了效率的低下；
3.是否針對需求跟蹤矩陣，覆蓋了所有的軟件需求；
4.是否完全遵守了軟件需求的規(guī)定。這并不一定的，因?yàn)榧词乖賴?yán)格的評審，也會(huì)出現(xiàn)錯(cuò)誤，應(yīng)具體情況具體對待。
如果是項(xiàng)目組內(nèi)部的評審，也就需要評審委員會(huì)來做了，角度不同，評審的標(biāo)準(zhǔn)也不同。比如收集客戶需求的人員注重你的業(yè)務(wù)邏輯是否正確，分析軟件需求規(guī)格的人注重你的用例是否跟規(guī)格要求一致，開發(fā)負(fù)責(zé)人會(huì)注重你的用例中對程序的要求是否合理。
測試用例的評審能夠使用例的結(jié)構(gòu)更清晰，覆蓋的用戶場景更全面對于測試工程師來說也是一個(gè)快速提高用例設(shè)計(jì)能力的過程。
1、需要評審的原因
測試用例是軟件測試的準(zhǔn)則，但它并不是一經(jīng)編制完成就成為準(zhǔn)則。由于用例開發(fā)人員的設(shè)計(jì)經(jīng)驗(yàn)和對需求理解的深度各不相同，所以用例的質(zhì)量難免會(huì)有不同程度的差異。
2、進(jìn)行評審的時(shí)機(jī)
一般會(huì)有兩個(gè)時(shí)間點(diǎn)。第一，是在用例的初步設(shè)計(jì)完成之后進(jìn)行評審第二是在整個(gè)詳細(xì)用例全部完成之后進(jìn)行二次評審。如果項(xiàng)目時(shí)間比較緊張，盡可能保證對用例設(shè)計(jì)進(jìn)行評審，提前發(fā)現(xiàn)其中的不足之處.
3、參與評審人員
這里會(huì)分為多個(gè)級別進(jìn)行評審。
1)部門評審，測試部門全體成員參與的評審。
2)公司評審，這里包括了項(xiàng)目經(jīng)理、需求分析人員、架構(gòu)設(shè)計(jì)人員、開發(fā)人員和測試人員。
3)客戶評審，包括了客戶方的開發(fā)人員和測試人員。這種情況在外包公司比較常見。
4、評審內(nèi)容
評審的內(nèi)容有以下幾個(gè)方面
1)用例設(shè)計(jì)的結(jié)構(gòu)安排是否清晰、合理，是否利于高效對需求進(jìn)行覆蓋。
2)優(yōu)先極安排是否合理。
3)是否覆蓋測試需求上的所有功能點(diǎn)。
4)用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結(jié)果是否清晰、正確期待結(jié)果是否有明顯的驗(yàn)證方法。
5)是否已經(jīng)刪除了冗余的用例。
6)是否包含充分的負(fù)面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數(shù)量，畢竟一個(gè)健壯的軟件，其中80%的代碼都是在"保護(hù)"20%的功能實(shí)現(xiàn)。
7)是否從用戶層面來設(shè)計(jì)用戶使用場景和使用流程的測試用例。
8)是否簡潔，復(fù)用性強(qiáng)。例如，可將重復(fù)度高的步驟或過程抽取出來定義為一些可復(fù)用標(biāo)準(zhǔn)步驟。
個(gè)人認(rèn)為，一個(gè)"健康"的測試用例至少要通過前5個(gè)標(biāo)準(zhǔn)。
5、評審的方式
1)召開評審會(huì)議。與會(huì)者在設(shè)計(jì)人員講解之后給出意見和建議，同時(shí)進(jìn)行詳細(xì)的評審記錄。
2)通用郵件與相關(guān)人員溝通
3)通用IM工具直接與相關(guān)人員交流
方式只是手段，得到其它人員對于用例的反饋信息才是目的。
無論采用那種方式，都應(yīng)該在溝通之前把用例設(shè)計(jì)的相關(guān)文檔發(fā)送給對方進(jìn)行前期的學(xué)習(xí)和了解，以節(jié)省溝通成本。
6、評審結(jié)束標(biāo)準(zhǔn)
在評審活動(dòng)中會(huì)收集到用例的反饋信息，在此基礎(chǔ)上進(jìn)行用例更新，直到通過評審。
6.測試計(jì)劃
1.測試計(jì)劃
--一場對所有軟件BUG展開的殲滅戰(zhàn)
確定測試范圍
制定測試策略
測試資源安排
-------測試時(shí)間、工作量、人員
-------由于每個(gè)人的思維存在局限性，每項(xiàng)測試最后安排不少于2個(gè)人測試，以便交叉測試
進(jìn)度安排
-------最好能預(yù)留一段緩沖時(shí)間，用于應(yīng)對計(jì)劃的變更，以及讓測試員有時(shí)間完善和補(bǔ)充測試用例
風(fēng)險(xiǎn)及對策
-------可考慮建立后備機(jī)制
