規(guī)范測試流程

1、.規(guī)范軟件測試流程測試計(jì)劃做任何事情都會有輸入輸出，對于測試過程我們可以把輸入理解為測試計(jì)劃、測試環(huán)境準(zhǔn)備、測試工具的選擇等等，輸出可以理解為測試結(jié)果。測試用例設(shè)計(jì)即可以理解為以測試計(jì)劃為輸入的輸出，也可以理解為以測試結(jié)果為輸出的輸入，在這里咬文嚼字沒有任何意義。所有的這些書籍和過程文檔無外乎告訴我們一個(gè)道理，做測試需要做好準(zhǔn)備工作，把做一件事需要做的準(zhǔn)備工作做好，明確做這件事的目的，最終達(dá)成目的并驗(yàn)證結(jié)果是我們要做的事情。這要求我們有一個(gè)完善的“測試計(jì)劃書”。輸入：測試目的，測試計(jì)劃，測試用例設(shè)計(jì)書，測試環(huán)境輸出：測試結(jié)果報(bào)告書，BUG票，BUG分析，追加測試用例測試計(jì)劃的編寫工作應(yīng)該從以下

2、幾個(gè)方面考慮問題：1、要充分考慮測試計(jì)劃的實(shí)用性，即，測試計(jì)劃與實(shí)際之間的接近程度和可操作性。編寫測試計(jì)劃的目的在于充分考慮執(zhí)行測試時(shí)的各種資源，包括測試內(nèi)容、測試標(biāo)準(zhǔn)、時(shí)間資源、人力資源等等，準(zhǔn)確地說是要分析執(zhí)行時(shí)所能夠調(diào)用的一切資源以及受各種條件限制，可能受到的各種影響。說的再明確一點(diǎn)就是要“計(jì)劃”“如何”去做“測試工作”，而不是“如何編寫測試計(jì)劃”。2、要堅(jiān)持“5W1H”的原則，明確測試內(nèi)容與過程。 明確測試的范圍和內(nèi)容(WHAT)； 明確測試的目的(WHY)； 明確測試的開始和結(jié)束日期(WHEN)； 明確給出測試文檔和軟件冊存放位置(WHERE)； 明確測試人員的任務(wù)分配(WHO)；

3、明確指出測試的方法和測試工具(HOW)。測試用例為什么說測試用例重要？測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執(zhí)行環(huán)節(jié)的基本依據(jù)。測試用例主要設(shè)計(jì)方法 錯(cuò)誤推測法 場景法 等價(jià)類劃分法 邊界值分析法 判定表法 因果圖法 狀態(tài)遷徙圖法 流程分析法 正交分析法 正交實(shí)驗(yàn)法如果是自己做的設(shè)計(jì)，自己PG，其實(shí)錯(cuò)誤推測法，場景法，流程分析法收效會明顯得多。因?yàn)槭煜ち鞒?，所以對可能存在問題的地方也是一目了然，不過這些對經(jīng)驗(yàn)的要求又太高。改進(jìn)測試用例執(zhí)行過程 項(xiàng)目的測試負(fù)責(zé)人和測試工程師參與軟件需求調(diào)研，以測試角度分析需求的可測性，可構(gòu)思將來對其測試的方法、原則等；更重要的是，對不可

4、測或難以測試性問題要及時(shí)與客戶或項(xiàng)目經(jīng)理協(xié)調(diào)解決。 全面了解系統(tǒng)需求，從客戶角度考慮軟件測試需要達(dá)到的驗(yàn)證狀態(tài)，即何些功能點(diǎn)需重點(diǎn)測試、何些無需，以便將來制定測試計(jì)劃。 有健全且嚴(yán)格的體制保證測試執(zhí)行者嚴(yán)格按照測試用例執(zhí)行測試。 如有對測試用例認(rèn)識模糊或內(nèi)容遺漏的地方，可暫做記錄待后期解決，或經(jīng)測試負(fù)責(zé)人與項(xiàng)目其他管理人員同意方可更新用例庫。 測試負(fù)責(zé)人每日負(fù)責(zé)跟蹤本測試子周期或階段的測試用例執(zhí)行情況，以及每日提交的缺陷報(bào)告，根據(jù)執(zhí)行進(jìn)展?fàn)顟B(tài)以及缺陷數(shù)量或嚴(yán)重等級與項(xiàng)目高層或其他人員展開交流，商議解決途徑，并確定或調(diào)整未來時(shí)間的測試任務(wù)。 測試執(zhí)行者負(fù)責(zé)執(zhí)行自己區(qū)域的測試用例，還要負(fù)責(zé)跟蹤該區(qū)

5、域軟件缺陷的修改進(jìn)展，根據(jù)其狀態(tài)不斷驗(yàn)證軟件功能點(diǎn)。 通過缺陷管理工具來管理軟件缺陷；這樣的集成工具都提供了清晰的報(bào)告模版及強(qiáng)大的追蹤功能，測試團(tuán)隊(duì)的每一成員按照自己的角色和權(quán)限訪問缺陷管理工具，并不斷跟蹤軟件缺陷的狀態(tài)。測試過程測試的過程應(yīng)該為五個(gè)階段，分別是發(fā)現(xiàn)問題、問題解析、解決方案、執(zhí)行、驗(yàn)收。發(fā)現(xiàn)問題這個(gè)步驟最重要的就是發(fā)現(xiàn)(Discover)問題，詳述(Discribe)問題，并且正確而詳細(xì)地記錄(Document)下來。在進(jìn)入下一步驟前，我們測試人員應(yīng)該問問自已以下這些問題：對于問題是否已經(jīng)有簡明的描述。這一部分我們經(jīng)常會犯的錯(cuò)誤有2點(diǎn)： 過分熟悉流程的測試人員，這是由于目前我們

6、的測試人員和開發(fā)人員沒有獨(dú)立，會直接把問題解析寫在問題描述中，雖然當(dāng)時(shí)方便了問題解析對問題的解決節(jié)約了時(shí)間，但是當(dāng)日后發(fā)生類似問題時(shí)由于沒有恰當(dāng)?shù)膯栴}描述導(dǎo)致問題解析無法比對，反而浪費(fèi)了人力。 是問題描述過于含糊。如“XXXX-XX-XX發(fā)現(xiàn)系統(tǒng)死機(jī)”，這樣的描述對問題解析者來說無疑大海撈針，問題記錄者應(yīng)詳盡的描述問題發(fā)生的背景，場合，以用記錄描述可以再現(xiàn)為要求描述問題，根據(jù)問題描述可以在實(shí)驗(yàn)室環(huán)境再現(xiàn)問題。嚴(yán)格比對測試輸出，避免錯(cuò)過問題。經(jīng)常會有問題明明PT甚至MT階段就能發(fā)現(xiàn)卻遺留到了ST階段。這是由于我們在測試過程中沒有認(rèn)真比對結(jié)果造成的，協(xié)議棧測試最重要的測試成果物就是LOG，是否對L

7、OG中每一個(gè)接口，每一個(gè)參數(shù)進(jìn)行了確認(rèn)。如果時(shí)間緊迫不可能對每一個(gè)參數(shù)進(jìn)行檢查，最起碼是否對我們關(guān)心的參數(shù)，對關(guān)鍵流程進(jìn)行了檢查。有時(shí)候很多問題時(shí)仔細(xì)看LOG就能發(fā)現(xiàn)的。所以， 嚴(yán)格比對測試結(jié)果是否為測試用例的期望。 對關(guān)鍵流程和關(guān)鍵參數(shù)進(jìn)行檢查。 測試一定要經(jīng)過回歸驗(yàn)證。問題解析Explore the conditions：探究原因，為問題提供明確的定義與定位。這個(gè)步驟的主要任務(wù)：是廣泛搜集相關(guān)數(shù)據(jù)，盡量了解系統(tǒng)的每一個(gè)方面，避免深入分析時(shí)，漏了某個(gè)關(guān)鍵的現(xiàn)象而誤入歧途；重點(diǎn)：是探索(Explore)，尋找證據(jù)(Evidence)，建立(Establish)整個(gè)問題的來龍去脈的假設(shè)。有2點(diǎn)特

8、別重要： 分析問題的時(shí)候一定要全面，進(jìn)行水平展開，將類似問題一網(wǎng)打盡。 一定要分析問題的影響。因?yàn)橐粋€(gè)很小的改動會系統(tǒng)都可能造成難以估量的影響。解決方案Track down possible approaches：提供可能的解決方案。這個(gè)步驟的主要任務(wù)：深入分析數(shù)據(jù)間的關(guān)聯(lián)性，并對整個(gè)問題的前因后果提出假設(shè)，最后擬定出相應(yīng)的策略(計(jì)劃)。如果前一個(gè)步驟做得不夠詳實(shí)，在這個(gè)步驟我們可能就會誤判，導(dǎo)致努力了半天，但就是找不到瓶頸點(diǎn)。對于一個(gè)問題可能有多個(gè)解決方案，有的實(shí)施簡單，有的影響小，有的準(zhǔn)確性高。這時(shí)就有選擇和取舍。在問題解決時(shí)一定要把所有可能的方案都找出來，不要圖簡單，因?yàn)樽詈唵蔚牟灰姷檬?/p>

9、最合適的方案。取舍的原則：1. 正確性。不管哪種方案一定是要能解決問題的。如果不能將問題徹底解決不管多簡單都不是好的方案。2. 影響性。一定要選擇影響最小的方案。3. 實(shí)施性。當(dāng)測試緊張時(shí)也可選擇用臨時(shí)方案替代，然后再仔細(xì)研究應(yīng)對。因?yàn)橛行﹩栴}的解決并不是一天兩天能對應(yīng)完的，這時(shí)就需要一個(gè)臨時(shí)的替代方案。當(dāng)然做好版本管理非常重要。4. 及時(shí)修正。執(zhí)行方案時(shí)，仍然要注意系統(tǒng)的反應(yīng)。因?yàn)樾碌淖C據(jù)可能證明你先前的判斷錯(cuò)誤，因而要修正策略，甚至是退回到上一步以重新擬定計(jì)劃。驗(yàn)收 確認(rèn)解決方案成功與否。 解決的方式是否有邊際效應(yīng)，造成其他的問題。 是否真正根除了問題，還是僅表象地頭痛醫(yī)頭，腳痛醫(yī)腳建立問

10、題的假設(shè)時(shí)，很容易將問題特殊化，僅局部地解決該現(xiàn)象。 建立持續(xù)跟蹤的計(jì)劃。當(dāng)無法確定已經(jīng)根除問題，那可能就要擬定持續(xù)跟蹤的計(jì)劃。決定是否要持續(xù)觀查某些計(jì)數(shù)器，跟蹤某些現(xiàn)象是否還會發(fā)生，若發(fā)生了要如何解決等等。測試用例檢查單1. 是否涵蓋了需求文檔上的每個(gè)功能點(diǎn)2. 是否涵蓋了需求文檔上的每條業(yè)務(wù)規(guī)則說明3. 是否覆蓋了輸入條件的各種有意義組合4. 是否覆蓋了業(yè)務(wù)操作的基本路徑和異常路徑5. 是否考慮了重要表單字段的數(shù)據(jù)合法性檢查6. 是否考慮了其他的測試類型(對某個(gè)功能很重要，但未在需求文檔中提及的，如安全測試、周期性測試和故障恢復(fù)等方面)7. 是否考慮了對其他模塊/功能的影響8. 是否使用了項(xiàng)目組的標(biāo)準(zhǔn)用例模板9. 用例是否覆蓋了測試設(shè)計(jì)中定義的所有場景10.用例編號是否統(tǒng)一、規(guī)范11.用例名稱是否簡潔、明了12.目的字段是否準(zhǔn)確地描述了對應(yīng)場景的測試輸入的特征(不同數(shù)據(jù)，操作，配置等)13.前提條件字段的條目是否充分、準(zhǔn)確，操作上是否不依賴于同組之外的其他用例14.對應(yīng)的需求編號字段是否填寫正確15.用例粒度、預(yù)估出的執(zhí)行時(shí)間是否適當(dāng)16.同組用例中，僅數(shù)據(jù)不同的，是否實(shí)現(xiàn)了測試步驟的重用17.某