制定項目的測試策略

制定工程的測試策略你需要一個測試策略。為什么？最近，我需要為自己工作的工程制定一份完整的測試策略。在我剛來到這個工程組時，我覺察開發(fā)人員試圖使用一個不完整的瀑布生命周期模型的團隊根底。剛好，這個工程組有大約12個開發(fā)人員，正處在利用并行開發(fā)工作來爭論更多動地承諾會在剩余的一年時間內完畢工程是這樣，由于這不是我第一次遇到這種狀況。測試技術和工程所使用的測試工具重要的一點，測試策略應當使測試過程中的溝通變得更為簡潔，而它會影響到整個工程組。要查找一些解決他們的方法：缺乏可重復性測試—-工程缺少回歸測試。缺乏可見性測試—碼的期限。反作用的構建過程—他構建人的需要。沒有對測試環(huán)境或測試數(shù)據(jù)進展把握。代碼公布后，沒有進展單元或集成測試。程。下面的故事會告知我們如何定義并實施一個測試策略。讓我們開頭吧在開發(fā)周期內找到最嚴峻的bugs。想盡早地覺察最嚴峻的缺陷，需要把工程的測試局部和開發(fā)局部聯(lián)合在一起，包括不同的測試階段、測試類型、工程環(huán)境，以及如何在環(huán)境、角色、職責之間升級代碼，還有普遍使用的工具。這個看起來是不是有點簡潔？實際上，它比你想象的簡潔。保持簡潔：寫字板上的打算個人解。制定測試策略時，你需要把工程組的其他人包含進來。一般有工程經理、開發(fā)主管、架構師、DBA〔數(shù)據(jù)庫治理員〕，以及其他一些關鍵人物，他們具有一些可利用的技術資源，施。至少，他們可以給你更多有關測試類型的現(xiàn)實想法單元測試、代碼復查、執(zhí)行期分析等等〕。我通常試著查找那些最大程度地包含在工程中的人，和他們一起開會爭論。由于，他們的洞察力和建議往往是格外貴重的。1步：根本策略輪廓寫字板—-輪廓〔包含了工程所執(zhí)行的測試類型寫字板—-輪廓圖一測試策略，一個清楚的框架需要清楚的定義。2步：目前的安排用一些功能測試允許的狀況下，從前面的一次公布開頭，是手工地基于測試用例的測試。5〔關鍵的衡量指標〔QA〕〔另一個關鍵的衡量指標〕2了爭論，確定了那些能準確地反映當前過程的數(shù)字。2寫字板—-測試的當前狀態(tài)3步：突如其來的改進一旦全部的人都同意了寫字板上有關衡量指標的內容與我們當前的資源〔人力和財力〕水平相符合。同時，我們意識到，很可能不能再擴大測試在此問題上。固然，我們也可以把關注點放在我們所經受的那些關鍵問題上〔還記得前面我所排列的那些問題嗎？〕在第六屆IEEE關于WebSite進展的國際研討會上，HungNguyen為我們描述了一種制定測試策略的技術—-獲得一個“bugcentric立一個清楚的目標。最糟的莫過于你的測試策略具有一個錯誤的目標—-這個策略注定會以決一些問題，但同時，會讓我們更加的難于解決剩余的問題〔實際沒有如此困難。在我們自由爭論的時候，商定了很多問題，并得到了一些結論：利用單元測試和集成測試，我們可以盡早地覺察更多的問題，并預備自動化測試的初始級別，同時，它們?yōu)槲覀児┙o了一些衡量指標，這些指標讓我們可以更好的跟蹤開發(fā)過程，這樣，我們可以做出打算—-何時移動我們的代碼〔多數(shù)狀況下，我們使用J2EEOracle來構建應用程序，同時，也使用一些其他的技J2EE或Oracl〕時他們也會漸漸地要求一些更為準確的性能測試—-盡管我們對此還只是略知皮毛。了。盡管那是格外重要的事情，由于我們不能無視安全性測試、可用性測試、配置測試和數(shù)據(jù)完整性測試，以及上百種其他類型的測試。我們打算進展一些基于session〔session-based〕的探究性測試，初是以成對的方式執(zhí)行該測試的，直到我們更為適應這種類型測試的過程，同時，也進展了我們快速學習和解決問題的力氣。一旦我們適應了探究性測試的工作，那么我們可以開頭執(zhí)行更多的sessions。我們覺察，需要建立一個正規(guī)的且自動化的煙霧測試，它適用于全部環(huán)境，它和自動化回歸測試的腳本集一起被用來測試那些高風險的功能，以及高容量的事務處理。我們知道，用戶的承受測試〔UAT〕遠遠達不到它應有的效果。因我們提出要制定更為具體的UATUAT的工作，由我們供給更多的指南、資源和培訓來幫助用戶進展承受測試，我們的目的只是期望UAT執(zhí)行的更為順當。我們商定了代碼何時可以在環(huán)境之間移動的衡量指標。無論是單元試，還是集成測試，90%的測試通過率對代碼而言已經足夠了，甚至可以從中了解到一些還會消滅的bug—-只要不存在長期影響系統(tǒng)正常運行的bug就行。我們打算要執(zhí)行嚴格的代碼復查，以保證在早期〔更可取的是在寫接近完成代碼時〕就覺察問題，而不是在代碼公布之后。我們創(chuàng)立了煙霧測試之后100%的通過這些測試，這樣才能前進入下一個級別。系統(tǒng)測試中，我們無論如何都不能讓任何嚴峻或高級別的缺陷遺留一個過程中，但是也存在這樣的一些缺陷，是我們所能容忍的，我們可以和用戶進展溝通，以此來確定他們的期望：問題現(xiàn)在就被修復，還是放在后面解決。缺陷趨勢分析，來幫助我們衡量系統(tǒng)測試工作的效果。我在寫字板上記錄了會議內容，如圖3所示，分別用不同的顏色進展了標注。3寫字板—-添加的測試類型和衡量指標4步：組織打算〔寫在寫字板上〕4所示的藍色方括號和箭頭。4書寫板—-職責、環(huán)境—QA我們知道了大多數(shù)測試工作的分布狀況。5步：確定要使用的工具IBMRational固然，我們也需要其他一些有幫助意義的工具作為它們的補充。比方單元測試，我們選用JUnit，由于我們的開發(fā)人員知道該如何使用它—-另外，免費和簡潔上手的特點也是選擇它JlintRationalClearCase進展資源和測試資產的把握；使用ClearQuest跟蹤問題；Purify、Quantify和PureCoverage被用來進展運行期分析；需求治理〔rm〕RequisitePro；自動化測試使用Robot和TestManager。原來，我們也爭論過使用其他一些運行期分析和資源把握工具，但是考慮到5呈現(xiàn)的寫字板上，包含了這些信息。5書寫板—-最終所形成的測試策略完成這些之后，接下來我們可以實施它了。實施的看法—-Visio技術，或者更有意義的衡量指標。打算了。在此打算中，答復下面的問題：包含了各測試類型的迭代過程是什么？〔迭代過程。〕我們如何對之前沒有做過測試的小組進展測試培訓？〔的利用和安排?！澄覀兒螘r開頭安裝、配置的測試工具，并進展相關的培訓？〔工具的使用問題，會影響測試的實際進度。〕由誰來負責每個測試階段的治理工作？〔指定一個測試負責人。〕我們如何打算這份測試策略的修訂和更工作？〔的版本變更