敏捷開發(fā)中的敏捷測試《敏捷測試全攻略》

敏捷測試全攻略目錄敏捷開發(fā)中的軟件測試...................................................................................................................3什么是敏捷測試？...................................................................................................................3敏捷測試中測試人員扮演的角色...........................................................................................3單元測試和可接受性測試.......................................................................................................3測試人員是否應該擁抱敏捷開發(fā)？.......................................................................................3敏捷測試實踐...........................................................................................................................4敏捷測試的挑戰(zhàn)...............................................................................................................................4什么是敏捷開發(fā)？...................................................................................................................4為什么以前的開發(fā)模式不再適用？.......................................................................................5測試的作用...............................................................................................................................5敏捷測試的挑戰(zhàn)之一：測試員是否不再需要了？...............................................................5敏捷測試的挑戰(zhàn)之二：測試不完整的軟件...........................................................................5敏捷測試的挑戰(zhàn)之三：可接受性測試是否過于簡單了？...................................................5敏捷測試的挑戰(zhàn)之四：把測試員作為工程組的一局部.......................................................6敏捷測試的挑戰(zhàn)之五：測試什么時候完成？.......................................................................6敏捷測試的挑戰(zhàn)之六：我們還需要bug跟蹤系統(tǒng)嗎？.......................................................6敏捷測試的挑戰(zhàn)之七：用什么質量標準來度量敏捷工程...................................................6敏捷測試的挑戰(zhàn)之七：回歸測試...........................................................................................7敏捷測試的挑戰(zhàn)之八：回歸測試工具...................................................................................7敏捷測試用例設計...........................................................................................................................8測試用例的粒度.......................................................................................................................8基于需求的測試用例設計.......................................................................................................9測試用例的評價.......................................................................................................................9測試用例數(shù)據(jù)生成的自動化.................................................................................................10敏捷自動化測試.............................................................................................................................10公式化的典型的自動化測試過程.........................................................................................10敏捷自動化測試的原那么.........................................................................................................11工具支持測試.........................................................................................................................11到處是工具.............................................................................................................................12“工具鐵匠”的任務.................................................................................................................12測試員可能會問“工具鐵匠”的問題.....................................................................................12管理敏捷自動化測試.............................................................................................................12敏捷測試指引〔1〕-簡介..............................................................................................................13敏捷測試指引〔2〕-測試與例子....................................................................................................14敏捷測試指引〔3〕-用面向技術的例子支援程序員................................................................16敏捷測試指引〔4〕-用面向業(yè)務的例子支援工程組................................................................18激發(fā)出正確的代碼.................................................................................................................18促進工程交流.........................................................................................................................18讓可能發(fā)生的更加明顯.........................................................................................................19

敏捷測試指引〔5〕-用面向業(yè)務的例子批判產品....................................................................20敏捷測試指引〔6〕-用面向技術的例子批判產品....................................................................21敏捷測試指引〔7〕-敏捷工程中的測試員................................................................................22敏捷開發(fā)中的7種測試類型.........................................................................................................25

敏捷開發(fā)中的軟件測試參考：BretPettichord的《AgileTesting-Whatisit?Canitwork?》和《AgileTestingChallenges》敏捷宣言：個體和交互比過程和工具更有價值；能工作的軟件比全面的文檔更有價值；顧客的協(xié)作比合同談判更有價值；及時響應變更比遵循方案更有價值。-什么是敏捷測試？測試遵循敏捷宣言進行，把開發(fā)作為顧客看待。工程的測試采用敏捷方法論。敏捷測試的原那么與上下文驅動測試〔Context-DrivenTesting：context-driven-testing〕的原那么有交集，例如，上下文驅動測試的七大原那么中的第三條：工作在一起的工程組成員是工程的上下文的最重要的組成局部。就與敏捷宣言中的“個體和交互比過程和工具更有價值”一樣強調人的作用。敏捷測試中測試人員扮演的角色1、測試是工程的“車頭燈”，它告訴大家現(xiàn)在到哪了，正在往哪個方向走。2、測試為工程組提供信息，使得工程組基于可靠的信息作出正確的決定。3、“BUG”是讓用戶感覺煩惱的東西，測試人員不作出發(fā)布的決定。4、測試員不保證質量，整個工程組對質量負責。5、測試不是抓蟲子的游戲，它的目的不是糾纏在錯誤中，而是幫助找到目標。單元測試和可接受性測試測試驅動開發(fā)，開發(fā)人員在寫代碼之前要先寫單元測試，用于激發(fā)代碼的編寫、改良設計〔降低耦合度，增加內聚〕、支持重構。很多開源的測試工具支持單元測試〔xUnit〕。用戶故事是需要編碼實現(xiàn)的功能特性的簡短的描述。可接受性測試驗證用戶故事的完整性。理想的情況下，用戶故事是在代碼編寫前就寫完。測試人員是否應該擁抱敏捷開發(fā)？有些人說XP會導致差的質量并且是偷懶的借口。我認為XP是令人沖動的，并將在行業(yè)中改良測試的實踐。參見《TestersShouldEmbraceAgileProgramming》〔://io/~wazmo/papers/embrace_agile_programming.html〕敏捷測試實踐通過對話產生測試，誰來測試？客戶往往太忙了，不可能參與測試。定義測試是很關鍵的活動，應該把開發(fā)人員和顧客代表包括進來，不要只是測試員自己做。把用戶故事轉換成測試。測試提供的是目標和指南、及時的反響、進度度量。測試應該用指定的格式出現(xiàn)，以便讓用戶或顧客能清楚明白，還要足夠的明確，以便能被執(zhí)行。開發(fā)人員負責提供支持自動化測試的特性。大局部情況下，為產品添加測試接口，而盡量不用外部測試工具。方案在每個迭代中探索產品，尋找bug、遺漏的特性和改良的時機。進一步學習LessonsLearnedinSoftwareTesting-AgileTestingPapers-敏捷測試的挑戰(zhàn)參考：BretPettichord的《AgileTesting-Whatisit?Canitwork?》和《AgileTestingChallenges》我們從上下文驅動測試的七大原那么(context-driven-testing)可以看出，上下文驅動測試傾向于快速的反響和適應變化的環(huán)境。所以上下文驅動測試的很多原那么和做法可以應用到敏捷開發(fā)的軟件測試中來。什么是敏捷開發(fā)？敏捷開發(fā)是遞增式的、迭代的、不斷調整的開發(fā)模式。我們逐漸地建立起軟件系統(tǒng)，能看到系統(tǒng)在成長，能展示進度。通過屢次發(fā)布或工程的階段檢查點，每一次都比上一次靠近目標。迭代包括需求的開發(fā)和測試，典型的迭代周期是2周。目標隨著從上一次的迭代中學到的東西、反響以及商業(yè)時機而調整。在敏捷開發(fā)中，工作被分解成“故事”，也叫特性或用例，組合成任務分派給不同的程序員。定義好接受標準，開發(fā)直到單元測試和接受測試通過才算完成。敏捷開發(fā)講求合作，結對進行編程，防止個人擁有專門的知識，代碼屬于工程組共有。在敏捷開發(fā)中不存在回退，講究持續(xù)地集成，單元測試〔通常使用測試驅動的開發(fā)方式〕，持續(xù)地進行回歸測試。

為什么以前的開發(fā)模式不再適用？以前的開發(fā)模式要求有詳細的測試方案，但是缺乏足夠的時間來寫，而且測試方案受很多因素的影響經常改變。以前的開發(fā)過程會專門留出一個階段來測試，但是你不能定義進入和退出的標準，測試階段會隨之而過。以前的開發(fā)模式強調變更控制，但是現(xiàn)在的軟件需求變更非常頻繁，變更成了家常便飯。以前的開發(fā)模式要求測試要對軟件做出權威的判斷，但是測試很難做出權威的關于軟件正確性的判斷。測試的作用有價值的東西有么提供產品，要么提供效勞。那么測試提供什么產品或效勞呢？有人認為測試提供調試通過的、經過測試的軟件。這是錯誤的答復。測試不提供產品，測試提供信息，關于開發(fā)過程中的軟件的狀態(tài)的信息，以便基于這些信息做出決定。敏捷測試的挑戰(zhàn)之一：測試員是否不再需要了？既然有開發(fā)人員做單元測試了，我們還需要測試員嗎？有些工程團隊采用了敏捷開發(fā)方式后把測試員都給解雇了，然后過了不久他們就懊悔了。測試可以是除QA或測試員外的人來做，例如業(yè)務分析員，有些工程團隊讓開發(fā)人員來做接受性測試。但是有專門的測試員帶來兩個好處：1、專注于用戶使用而不是軟件的技術實現(xiàn)2、專注于發(fā)現(xiàn)軟件的錯誤而不是證明完整性敏捷測試的挑戰(zhàn)之二：測試不完整的軟件頻繁的迭代產生的測試版本很多時候是不完整的，測試員如何測試這些不完整的代碼呢？“故事”應該從業(yè)務價值方面來定義。一個“故事”應該在一個迭代周期內完成。好的“故事”是不容易定義出來的，但是差的故事對測試人員的影響比對開發(fā)人員的影響還要大。有時候測試人員需要幫助定義“故事”。敏捷測試的挑戰(zhàn)之三：可接受性測試是否過于簡單了？測試人員如果只是做可接受性測試，只是驗證“故事”是否完整，豈不是太簡單了？這樣怎么能做好測試呢？其實，每一個迭代都需要額外的測試，而不僅僅是局限于驗證“故事”的完整性。在迭代測試中還要按需進行下面類型的測試：探索性測試：同時學習系統(tǒng)、方案和執(zhí)行測試，尋找bug、遺漏的特性和改良的時機。組合交互測試：專注于特性之間的交互。場景測試：模擬真實世界的場景進行測試。疲勞測試：長時間地執(zhí)行軟件業(yè)務循環(huán)測試：基于月末、季度末等業(yè)務循環(huán)的邊界來執(zhí)行場景壓力測試：對系統(tǒng)施加強大的壓力進行測試敏捷測試的挑戰(zhàn)之四：把測試員作為工程組的一局部把測試員作為工程組中的一員不是犧牲了他們作為一個組織的完整性嗎？測試員一直被認為是受壓迫的對象，經常坐在一起互相訴苦、互相支持?，F(xiàn)在是時候結束這種情況了。測試員應該跟開發(fā)人員和分析師坐在一起，當工程組中有更多的正式或非正式的溝通時才有可能到達敏捷。敏捷測試的挑戰(zhàn)之五：測試什么時候完成？沒有專門分配的時間來完成測試，我們怎么知道什么時候測試應該結束？敏捷測試員需要根據(jù)工程和產品的風險來調整測試。根本上測試的優(yōu)先級應該跟“故事”的優(yōu)先級一致。BUG列表也提供了測試完整性的提示。一個好的測試員是永遠都能找到需要完成的測試來做的。為什么需要跟開發(fā)人員結對進行測試呢？因為開發(fā)人員對潛在的錯誤有一定的洞察力，測試員對約束和錯誤的時機有一定的洞察力。而他們在一起能使自動化測試更加成功。測試員應該自動化可接受性測試，使用與開發(fā)環(huán)境一樣的編程語言來編寫可接受性測試的代碼，重用單元測試的框架，使軟件更加可測。利用“灰盒”測試。設法弄清楚系統(tǒng)各模塊之間的關系，分析變更的影響，看什么是需要測試的，什么是可以不測試的。弄清楚bug，bug的外表現(xiàn)象是什么？產生bug的根本原因是什么？弄清楚風險，使用解決風險的測試策略，調整測試目標。敏捷測試的挑戰(zhàn)之六：我們還需要bug跟蹤系統(tǒng)嗎？有些人說敏捷團隊不需要跟蹤bug，只需要把發(fā)現(xiàn)的bug盡快修正就行了。這種做法只適用于開發(fā)過程的測試，如果是一個完整迭代的測試，你就需要bug跟蹤系統(tǒng)，因為有些bug不是在這個迭代馬上修改的。敏捷測試的挑戰(zhàn)之七：用什么質量標準來度量敏捷工程其中一個最好的質量標準是發(fā)布后逃逸的bug數(shù)量。不辛的是，這是個事后的衡量標準。采用每個迭代后計算逃逸bug數(shù)量的方法能標識代碼的質量。我們還可以從bug學習到很多東西：1、是否有些類型的bug在可接受性測試中發(fā)現(xiàn)的，其實是可以在單元測試就發(fā)現(xiàn)呢？如果是，把它參加到單元測試。2、我們是否能讓bug的發(fā)現(xiàn)過程或bug的診斷更簡單？3、我們是否能讓程序員不那么容易犯這種普通的錯誤？敏捷測試的挑戰(zhàn)之八：回歸測試伴隨著頻繁的迭代，我們需要頻繁地重新測試，單元測試是缺乏夠的。我們怎樣有效地進行用戶層面的回歸測試呢？你不一定需要在每次的迭代都做完整的回歸測試?？梢悦總€迭代運行一局部的測試。需要某種程度上的用戶層次的自動化回歸測試。敏捷測試的挑戰(zhàn)之九：回歸測試工具大局部的商業(yè)測試工具在敏捷環(huán)境下都不是很好用。大局部有這些缺點：1、指定的語言大局部商業(yè)測試工具會指定某種語言，例如：WinRunner〔TSL〕、SilkTest〔4test〕、Robot〔TestBasic〕，但是一些新的工具也開始使用標準語言，例如：AstraQuickTest〔VBScript〕，XDETester〔Java〕參考2、與源代碼控制的結合不好很多工具沒有與源代碼控制工具集成，使用臨時文件和目錄〔WinRunner〕，參考://paulhammant/blog/000245.html關鍵信息存儲在Repositories中，例如Rational3、很難與持續(xù)集成配合使用缺乏外部調用的API，不允許作為一個庫被使用，因此很難與持續(xù)集成整合在一起。一些新的工具那么有所改良，例如TestComplete4、不能在所有機器上部署〔受License限制〕受限制的、昂貴的License，使得很多開發(fā)人員不能例如工具運行測試這些問題使得他們對于整個團隊來講不夠實用。敏捷團隊傾向于構建自己的測試工具和利用開源工具。開源測試工具現(xiàn)在已經出現(xiàn)很多開源的測試工具，支持windows、Java、Web等平臺，現(xiàn)在大局部都集中在web平臺，例如:Unit、WTR等。關于AgileTesting，可以參考以下資料：.AgileTestingPapers.“WherearetheTestersinXP?”.MailingList敏捷測試用例設計敏捷宣言：個體和交互比過程和工具更有價值；能工作的軟件比全面的文檔更有價值；顧客的協(xié)作比合同談判更有價值；及時響應變更比遵循方案更有價值。-并非每個企業(yè)都能嚴格按敏捷的相關開發(fā)方法進行工程管理，例如測試驅動、XP、SCRUM等。也并非都需要按這些方式管理才能實現(xiàn)敏捷。只要我們理解了敏捷的原那么和精髓，我認為很多方法、很多地方都可以應用敏捷的思想，實現(xiàn)敏捷的管理。測試用例的設計是其中一項。測試用例的粒度測試用例可以寫得很簡單，也可以寫得很復雜。最簡單的測試用例是測試的綱要，僅僅指出要測試的內容，如探索性測試〔ExploratoryTesting〕中的測試設計，僅會指出需要測試產品的哪些要素、需要到達的質量目標、需要使用的測試方法等。而最復雜的測試用例就像飛機維修人員使用的工作指令卡一樣，會指定輸入的每項數(shù)據(jù)，期待的結果及檢驗的方法，具體到界面元素的操作步驟，指定測試的方法和工具等等。測試用例寫得過于復雜或過于詳細，會帶來兩個問題：一個是效率問題，一個是維護本錢問題。另外，測試用例設計得過于詳細，留給測試執(zhí)行人員的思考空間就比擬少，容易限制測試人員的思維。測試用例寫得過于簡單，那么可能失去了測試用例的意義。過于簡單的測試用例設計其實并沒有進行“設計”，只是把需要測試的功能模塊記錄下來而已，它的作用僅僅是在測試過程中作為一個簡單的測試方案，提醒測試人員測試的主要功能包括哪些而已。測試用例的設計的本質應該是在設計的過程中理解需求，檢驗需求，并把對軟件系統(tǒng)的測試方法的思路記錄下來，以便指導將來的測試。大多數(shù)測試團隊編寫的測試用例的粒度介于兩者之間。而如何把握好粒度是測試用例設計的關鍵，也將影響測試用例設計的效率和效果。我們應該根據(jù)工程的實際情況、測試資源情況來決定設計出怎樣粒度的測試用例。軟件是開發(fā)人員需要去努力實現(xiàn)敏捷化的對象，而測試用例那么是測試人員需要去努力實現(xiàn)敏捷化的對象。要想在測試用例的設計方面應用“能工作的軟件比全面的文檔更有價值”這一敏捷原那么，那么關鍵是考慮怎樣使設計出來的測試用例是能有效工作的。基于需求的測試用例設計基于需求的用例場景來設計測試用例是最直接有效的方法，因為它直接覆蓋了需求，而需求是軟件的根本，驗證對需求的覆蓋是軟件測試的根本目的。要把測試用例當成“活”的文檔〔EffectiveSoftwareTesting:50SpecificWaystoImproveYourTesting–ElfriedeDustin〕，因為需求是“活”的、善變的。因此在設計測試用例方面應該把敏捷的“及時響應變更比遵循方案更有價值”這一原那么。不要認為測試用例的設計是一個階段，測試用例的設計也需要迭代，在軟件開發(fā)的不同的階段都要回來重新審視和完善測試用例。測試用例的評價測試用例設計出來了，質量如何，如何提高測試用例設計的質量？就像軟件產品需要通過各種手段來保證質量一樣，測試用例的質量保證也需要綜合使用各種手段和方法。測試用例的檢查可以有多種方式，但是最敏捷的應當屬臨時的同行評審。我認為同行評審，尤其是臨時的同行評審，應該演變成類似結對編程一樣的方式。從而表達敏捷的“個體和交互比過程和工具更有價值”，要強調測試用例設計者之間的思想碰撞，通過討論、協(xié)作來完成測試用例的設計，原因很簡單，測試用例的目的是盡可能全面地覆蓋需求，而測試人員總會存在某方面的思維缺陷，一個人的思維總是存在局限性。因此需要一起設計測試用例。除了同行評審，還應該盡量引入用戶參與到測試用例的設計中來，讓他們參與評審，從而體現(xiàn)敏捷的“顧客的協(xié)作比合同談判更有價值”這一原那么。這里顧客的含義比擬廣泛，關鍵在于你怎樣定義測試，如果測試是對產品的批判，那么顧客應該指最終用戶或顧客代表〔在內部可以是市場人員或領域專家〕；如果測試是指對開發(fā)提供幫助和支持，那么顧客顯然就是程序員了。因此，參與到測試用例設計和評審中來的人除了測試人員自己和管理層外，還應該包括最終用戶或顧客代表，還有開發(fā)人員。測試用例數(shù)據(jù)生成的自動化在測試用例設計方面最有希望實現(xiàn)自動化的，要當屬測試用例數(shù)據(jù)生成的自動化了。因為設計方面的自動化在可想象的將來估計都很難實現(xiàn)，但是數(shù)據(jù)那么不同，數(shù)據(jù)的組合、數(shù)據(jù)的過濾篩選、大批量數(shù)據(jù)的生成等都是計算機擅長的工作。很多時候，測試用例的輸入?yún)?shù)有不同的類型、有不同的取值范圍，我們需要得到測試用例的輸入?yún)?shù)的不同組合，以便全面地覆蓋各種可能的取值情況。但是全覆蓋的值域可能會不可思議地廣泛，我們又需要科學地篩選出一些有代表性的數(shù)據(jù)，以便減輕測試的工作量。在這方面可利用正交表設計數(shù)據(jù)或成對組合法設計數(shù)據(jù)。可利用一些工具，例如TConfig、PICT等來產生這些數(shù)據(jù)。在性能測試、容量測試方面，除了設計好測試用例考慮如何測試外，還要準備好大量的數(shù)據(jù)。大量數(shù)據(jù)的準備可以使用多種方式：編程生成、SQL語句生成〔基于數(shù)據(jù)庫的數(shù)據(jù)〕、利用工具生成。工具未必能生成所有滿足要求的數(shù)據(jù)，但是卻是最快速的，編程能生成所有需要的數(shù)據(jù)，但是可能是最復雜、最慢的方式。所以應該盡量考慮使用一些簡單實用的工具，例如DataFactory等。敏捷自動化測試原文：AgileTestAutomation–Jamesbach公式化的典型的自動化測試過程1、購置一個昂貴的GUI測試執(zhí)行工具〔例如Rational、Mercury、Compuware等〕2、定義很多測試用例3、招聘一個自動化測試組實現(xiàn)每個測試用例的自動化執(zhí)行4、構建一個完整的測試庫和框架5、不斷地完善和修正如果你的產品很容易測試并且變更不大的話，以上方式很適合。但是關于自動化測試，我們?yōu)槭裁聪氲媚敲椽M窄？嘗試把自動化測試想成是“任何使用工具來支持測試”。敏捷自動化測試就是把敏捷開發(fā)的原那么應用在測試自動化上。敏捷自動化測試的原那么1、測試自動化意味著使用工具支持測試工程的各個方面，不僅僅是測試執(zhí)行方面。2、當測試自動化得到指定的程序員〔toolsmiths-“工具鐵匠”〕支持時，會不斷地順利進行。3、“工具鐵匠”由測試員領導。4、“工具鐵匠”收集并應用各種各樣的工具來支持測試。5、“工具鐵匠”幫助實現(xiàn)可測特性并“打造”工具以便利用這些可測特性。6、組織實現(xiàn)測試自動化是為了完成某個短期的目標。7、防止盲目進行長期的自動化測試任務，而不是基于業(yè)務場景的分析。工具支持測試1、測試創(chuàng)立〔數(shù)據(jù)和腳本的產生〕工具可以產生特定的數(shù)據(jù)，例如：隨機的Email信息，或產生數(shù)據(jù)庫，或產生組合參數(shù)來覆蓋我們的測試。2、系統(tǒng)配置工具可以保持或重現(xiàn)系統(tǒng)參數(shù)，把系統(tǒng)設置到某個特定的狀態(tài)，或創(chuàng)立或回滾到一個“ghost”的磁盤3、模擬工具可以為測試模擬一些不具備的環(huán)境條件，這些環(huán)境可能會很難出現(xiàn)或提供起來很昂貴。4、測試執(zhí)行工具可以操作軟件系統(tǒng)本身，模擬用戶的GUI操作或繞過GUI層直接使用某些測試接口。5、問題分析工具可以使某些不可見的東西可見。穩(wěn)定地分析產品或分析log文件，或監(jiān)視系統(tǒng)參數(shù)。6、“預言”“預言”是通過某些機制來判斷錯誤或成功。工具可以自動地判斷產品的某些類型的錯誤條件。7、記錄和覆蓋分析工具可以幫助記錄測試過程覆蓋的地方和未覆蓋的地方。8、試管理工具可以記錄測試結果，組織測試用例。到處是工具1、MSDN庫2、微軟的很多開發(fā)工具都包括很多有用的小工具3、微軟兼容性工具包和其他免費工具〔microsoft〕4、基于網(wǎng)頁的測試資源〔HTMLcheckers、accessibilityanalyzers等〕5、widows資源包6、腳本語言〔例如：Perl、Ruby、TCL〕和相關庫7、共享資源庫〔download〕8、操作系統(tǒng)監(jiān)視工具〔sysinternals〕9、開源測試軟件〔〕10、探索性測試的監(jiān)視軟件〔spectorsoft〕11、工程組其他人正在使用的工具“工具鐵匠”的任務1、快速響應測試員的請求并提供協(xié)助2、查找影響測試效率的問題3、調查測試員關心的問題的可能的解決方案4、應用技術改良測試過程5、提供產品的可測性功能特性6、研究工具并學習怎樣使用7、收集開發(fā)人員或測試員創(chuàng)立的工具8、對產品進行評審以便方案自動化的可能性測試員可能會問“工具鐵匠”的問題1、我怎樣測試這個新的功能？2、我如何才能看到產品內部做了什么？3、我如何判斷測試是否通過？4、有沒有方法讓我能自動地執(zhí)行這些操作？5、有沒有方法讓bug重現(xiàn)更加容易些？6、幫助我調查這些bug7、這里有一個測試要執(zhí)行，你能否幫助我產生1000個變量？8、我的測試覆蓋了產品的多少地方？9、我想對產品進行壓力測試，是否有什么工具可以使用？管理敏捷自動化測試1、請求清單請求清單是測試員發(fā)出的自動化測試要求2、任務清單任務清單是每位“工具鐵匠”收到的分派任務3、移交清單移交清單是目前被測試組使用的解決方案。每個都包括解決方案對測試效率的影響的簡要描述4、維護清單維護清單是需要改良的解決方案的清單。可以考慮把它分成兩局部：關鍵維護和增強維護。5、障礙清單障礙清單是所有尚未解決的影響測試效率的問題清單。這些問題需要新的昂貴的工具、實際的可測試性改良、或者需要更多工作而難以在短期實現(xiàn)對于一個大型的測試組來說，至少需要一名“工具鐵匠”，但是不要把所有測試員都作為“工具鐵匠”，因為這樣做的本錢太高，這樣所有測試員都要像“工具鐵匠”一樣思考問題。敏捷測試指引〔1〕-簡介原文：AgileTestingDirections–Introduction〔BrianMarick〕在XPAgileUniverse上，兩個人-或許更多-告訴我說，我在敏捷測試的開展方面奉獻不夠。我在過去5年里花了太多的時間說我不知道敏捷測試會怎樣，沒有足夠的指示和指導?！暗亲屛覀兛纯?，也許我們可以找到?！彼麄兛赡苁菍Φ?。因此我讓本文作為這方面的一個起點。我先重申一些普遍的概念區(qū)別，以作為起點。如果你聽到別人在談論敏捷工程中的測試，問一下那些測試是面向業(yè)務的還是面向技術的，會對你有很大的幫助。面向業(yè)務的測試是你可以用一個業(yè)務專家感興趣的術語來向他描述測試。如果你通過描述測試答復了什么問題，你可以使用業(yè)務領域的術語：“如果你支取超過你的賬戶余額的現(xiàn)金，系統(tǒng)是否會自動給予你一筆與超出局部等額的貸款？”面向技術的測試是你使用程序員的領域的術語來描述測試：“不同的瀏覽器會通過不同的方式實現(xiàn)Javascript，所以我們測試產品是否能在最主要的瀏覽器上工作?！被蛘撸骸叭绻脩粲涗洸淮嬖?，PersistentUser#delete不應該執(zhí)行?！薄策@些分類有著很多模糊的界線，例如，選擇測試哪個瀏覽器配置，局部是業(yè)務決定。〕問一下正在討論測試的人，他們希望測試支援編程還是批判產品。對于“支援編程”，我的意思是程序員把測試作為編程的主要組成局部。例如，一些程序員編寫測試用例來告訴他們下一步應該寫什么代碼。通過編寫那些代碼，他們改變一些程序的行為。這些更改之后通過運行這局部的測試來保證他們修改的是他們需要的。運行其它的測試來確保更改的行為不會影響其它不需要更改的局部。批判產品的測試那么不是專注于編程方面。而是在已完成的產品上查找發(fā)現(xiàn)產品的缺乏之處。如果把這兩類區(qū)別放到一起，就得到下面的矩陣圖：接下來，我會談談這個矩陣的每個區(qū)域，我關于它們的開展的預測。敏捷測試指引〔2〕-測試與例子原文：AgileTestingDirections–TestsandExamples〔BrianMarick〕'Italldependsonwhatyoumeanbyhome.'[...]'Homeistheplacewhere,whenyouhavetogothere,Theyhavetotakeyouin.''IshouldhavecalleditSomethingyousomehowhaven'ttodeserve.'--RobertFrost,"TheDeathoftheHiredMan"“這在于你如何理解家的概念。”……“家是你隨時隨地可以去的地方，是他們會讓你進去的地方”“我應該把它稱為你不知何故，不值得擁有的東西”--RobertFrost，“TheDeathoftheHiredMan”上次，我畫了這樣一張矩陣圖：左邊是偏向“支援編程”的測試，右邊是偏向“批判產品”的測試。但是兩種測試的意義和內涵存在很大的不同。對于支援編程，測試主要作為準備和保證。你通過寫測試代碼來說明關于問題的思考。你把它作為說明性的例子來描述代碼應該怎樣做。幸運地是，它同時是活潑地檢查代碼的說明性例子，即重新保證。這些測試也會找bug，但是那是第二目的。在另一方面，測試是關于暴露主要錯誤和遺漏。這里，測試的原義就是關于bug。有其它的意義，但是首要的意義是最主要的?！埠芏鄿y試員，尤其是最好的測試員，在他們的身上已經融入了那些詞語的內涵。〕我想做個嘗試。如果我們在矩陣的左邊不使用“testing”和“test”這些詞語會怎樣？如果我們把它叫做“checkedexamples”〔檢查例子〕怎樣？設想兩個XP程序員坐在代碼前面。他們開始構建一個例子來說明下一步要做什么。他們會檢查，在代碼還沒寫之前?！踩绻麑懥耍鞘呛芴厥鈧€別的情況?！乘麄兙帉懘a。檢查例子是否運行正確，其他例子也保持正確。然后繼續(xù)下一個例子用于展示下一步應該做的事情。替換詞語有意義嗎？是否只是文字上的替換而已？你做一些嘗試，然后答復這些問題吧。嘗試經常使用“example(例子)”，經常使用讓它聽起來不會感覺很奇怪?，F(xiàn)在，當你坐在代碼前面時，是否根本改變了你的觀點？是否有了一些不同：在你向客戶要求一個例子，而不是一個測試時。加上一些形容詞：example(例子)是否看起來更具激發(fā)性、更生動、更有深刻內涵？與強大的測試存在怎樣的區(qū)別？〔“強大”作為附加給測試的典型的形容詞?！硿y試人員在XP工程中，每個人都在制作例子，沒有人做測試，這樣是否看起來更輕松些？敏捷測試指引〔3〕-用面向技術的例子支援工程組原文：AgileTestingDirections–Technology-FacingProgrammerSupport〔BrianMarick〕為了幫助討論和理解，我把“敏捷工程中的測試”這一主題分解成4個區(qū)分的主題。今天，我講一下我們怎樣使用面向技術的例子來幫助和支援程序開發(fā)。這里適用的一個是測試驅動開發(fā)，在KentBeck的書中，DavidAstel最近的書，Phlip,J.B.Rainsberger接下來的書中都討論了這種開發(fā)方式。我認為測試驅動開發(fā)〔我現(xiàn)在會叫它例子驅動開發(fā)，example-drivendevelopment〕是可靠的。它不是主流的開發(fā)方式，但是看起來要成為主流了。套用GeoffreyMoore的話，我認為它正在跨越鴻溝的路途中。也可以這樣說，例子驅動開發(fā)已經從ThomasKuhn所說的“革命性的科學”開展到“正規(guī)科學”。在正規(guī)科學中，人們擴展了特定方法的適用范圍。因此我們現(xiàn)在很多人在GUI應用EDD〔sic〕，設法讓它與遺留代碼〔legacycode〕一起工作，討論mockobjects的好的使用方法，討論處理私有方法的技術，等等。但是這些都不是重大的開展。我希望不久的將來會看到更多同時擁有測試和編程的技巧的人被吸引到敏捷工程中來。這些人既不會成為像純測試人員那樣的好測試員，也不會成為像純編程人員那樣好的編程人員。但是那還是不錯的，如果你跟我一樣相信敏捷工程應該重視通才多于重視專才的話。我不是這樣的混合人物。我沒有與純編程人員一起做很多的結對編程。但是我注意到，在維持編程的進度和目標的希望與確保很多好的測試的主意被考慮到的希望之間存在著緊張的關系。我發(fā)現(xiàn)我自己在進入程序員模式和退出并考慮全局的之間振蕩。從經驗看來，我們需要更好的思路來管理這個過程，以及關于什么類型的“測試思考”在編碼過程中是適宜的。也可能有一些測試員在敏捷工程中不擔當程序員的工作。不過，他們中的一些人還是跟程序員結對討論單元測試〔關于程序員如何檢查代碼〕。程序員學習如何防止哪些類型的bug，測試員學習他們正在測試的是什么。不知何故，加拿大的卡爾加里成為了這些活動的溫床，我指望JonathanKohl，JanetGregory和其他人告訴我怎樣才能做好。我需要強調這些都是關于人的。傳統(tǒng)上，測試員與編程人員會有很緊密〔或者很廣闊〕的關系。對于矩陣的支援程序員這局部，我相信傳統(tǒng)的關系是不適宜的。我使用術語“checkedexamples〔檢查例子〕”作為支援程序員的測試。我們可以把這個概念一分為二。一局部作為指引下一步編碼的決定。另外一局部是自動化的例子，作為“改變探測器”〔changedetectors〕，看剛剛的修改是否是你期待的。通常的習慣是，改變探測器僅僅是保存的代碼的保護性例子?！材阕屇愕膯卧獪y試套件作為救助，一個對應一個地，在編碼的同時測試?！衬遣皇沁壿嬌系囊?。我喜歡先建立一些關于什么時候做其他事情的知識。例如，考慮這樣的維護場景：你首先開發(fā)了一些代碼例子。一個月后，別人加了一個新的例子并改變了代碼以便匹配。很多之前為那局部代碼開發(fā)的例子都成了“badexamples”壞例子了。〔測試失敗，但是因為他們現(xiàn)在是錯誤的，不是因為代碼錯誤?！承拚切├右员闼麄円恢?。我的意思是在下表的左邊的事件序列本來是期望與右邊的測試一樣的?！蚕瓤醋筮厵?，然后看右邊。〕最近壞掉的例子被重寫以便匹配一個理想的開發(fā)順序，在這個過程中不需要重寫任何例子。但是為什么？在上表的左列，新的例子foo沒有用于驅動開發(fā)，只是作為檢查。對于驅動開發(fā)來說是最正確的可能對于檢查來說不是最正確的。假設軟件系統(tǒng)開發(fā)切面層〔shearinglayers〕，切面層的接口通常是不會改變很大的。為了可維護性，在修改時移植壞掉的例子到界切面層是有意義的。取代一個例子對應一個類的一個方法的做法，我們現(xiàn)在使用一個例子對應整個子系統(tǒng)。那可能會很糟糕-想想調試–但是它減少了維護的負擔，甚至能提供關于子系統(tǒng)的行為的完整文檔的好處。我希望人們分清楚兩個角色–指引不遠的將來和重新檢查過去–會發(fā)現(xiàn)有建設性的知識。例如，什么時候編寫面向技術的“改變探測器”〔而這些與指引編程沒有任何關系〕可能會有用？我在上面說的測試驅動開發(fā)是“期中一個適合”今天的主題的東西。那么其他適合的是什么？我不知道。EDD是否是最適宜的？〔是否最近可能發(fā)生革命性的改變？〕我也不知道–我要依賴那些善于打破舊習的人來幫我找出來。對此我將非常感興趣。敏捷測試指引〔4〕-用面向業(yè)務的例子支援工程組原文：AgileTestingDirections–Technology-FacingProgrammerSupport〔BrianMarick〕為了幫助討論和理解，我把“敏捷工程中的測試”這一主題分解成4個區(qū)分的主題。今天，我講一下我們怎樣使用面向業(yè)務的例子來幫助和支援整個工程組的工作〔不僅僅是程序員〕。我指望工程例子做三件事：激發(fā)程序員寫出正確的代碼，促進技術專家與業(yè)務專家之間的對話，幫助業(yè)務專家更快地在產品中實現(xiàn)可能的特性。讓我們一步步來分析他們。激發(fā)出正確的代碼這是測試標準的驅動〔或例子驅動〕設計從內部接口到整個產品接口的直接推導。為了添加一個新的功能特性，先用1個或多個例子來說明它應該怎樣工作。然后程序員編寫代碼來匹配那些例子。編寫和維護例子直到需要的代碼都得到了。然后功能特性也就完成了〔到目前為止〕。雖然推斷是直接的，但是我們在得到細節(jié)之前還有一段路要走，在充分理解實踐之前。我在下面會講更多關于這方面的內容。促進工程交流把例子仍過墻給程序員并期待他寫出正確的代碼與仍給他需求文檔一樣是行不通的。程序員需要上下文、背景和關于默認慣例的一些知識。他們通過與業(yè)務專家交流得到那些東西。例子可以改善交流，通過提供一些東西給大家討論。它們把討論具體化。例子可以提供顯著幫助的地方，我想，是得出一個公共的詞匯表。我喜歡這個想法：領域方面的術語應該通過轉化到代碼中的對象來使其“具體化”。不是幼稚地按“寫出業(yè)務領域并在名詞下面劃橫線”的面向對象的設計方式，而是用EricEvans的領域驅動設計〔Domain-DrivenDesign〕的更完善的方式因此我們必須有一個對領域知識的理解從模糊到具體的過程，轉化到0和1的過程?？雌饋砝邮且粋€中間步驟，逐漸讓知識不模糊的過程。但是，使用例子來指引程序員，還有很多需要學習和研究。讓可能發(fā)生的更加明顯我們希望業(yè)務專家在他們意識到產品通過A的方式做了B，通過X的方式做了Y，因此有必要做一些新的Z，這些他們以前沒有想到的事情的時候，發(fā)出“啊哈！”的聲音。我們也同樣希望工程組的其他人有類似的表現(xiàn)，這樣他們可以向業(yè)務專家提議一些東西。簡而言之，我們需要創(chuàng)造力。可能最正確的釋放創(chuàng)造力的方式是讓你親手編寫軟件并測試。但是另外一種方式是解釋例子給其他人聽。是否曾經在找bug方面存在困難，然后在開始解釋你的代碼給別人聽的時候蹦出很多錯誤？對于我來說，在寫用戶文檔的時候也會有類似的效果：我使用例子來解釋軟件背后的根本概念，它們是如何組合在一起工作的。我會經常發(fā)現(xiàn)它們不工作。與碰到bug的感覺是一樣的，雖然我要解釋的可能不是一個真正坐在我前面的人，而是一個假想的讀者。因此，我們創(chuàng)立例子和討論例子的方式可能會加速產品的進展。我下一年專注的幾個研究方向中的其中一個就是面向業(yè)務的例子。我已經準備好了$15000用于調查能很好地使用它們的機構。如果你知道有這樣的機構，請聯(lián)系我。在調查了他們之后，我希望能講關于下面的一些故事：1、關于例子的進度的故事。什么時候創(chuàng)立它們？在程序員開始編碼之前創(chuàng)立了多少例子？什么例子最先創(chuàng)立？2、關于人們圍繞例子的交流的故事。誰參與了？交流的形式是怎樣的？誰把例子寫下來？業(yè)務專家來寫的時候是怎樣的？程序員來寫呢？測試人員呢？〔當不同的人之間切換時人們注意到什么了？〕在把例子轉換到代碼的過程中例子變化的情況是怎樣的？3、關于面向業(yè)務的例子和面向技術的例子〔單元測試〕之間的交互的故事。程序員在什么時候、怎樣把注意力從一個轉到另外一個的？面向顧客的例子是否經常檢查？例子是否會從一個分類轉到另外一個分類？4、關于面向業(yè)務的例子影響設計和代碼結構的故事5、關于FIT的故事。對于什么樣的系統(tǒng)最適宜？FIT最好的一個特性之一是它鼓勵把說明性的文字環(huán)繞著例子–大家怎么利用它呢？當人們從其他方法〔用腳本語言編寫例子〕轉移到FIT的時候，學到了什么東西？而轉向其他方向的人們學到了什么？當開發(fā)一個工程的詞匯表的時候FIT和腳本語言比擬起來會怎樣？6、關于推動代碼的例子〔“...這里是功能X的另外一個重要的方面”〕和排除bug的例子〔“.不要忘記產品要在這種情況下工作”〕之間的平衡的故事。怎樣的bug需要預防，怎樣的bug應該留給產品批判的階段〔矩陣表的另外一半〕？〔參見BillWake的"generative"and"elaborative"tests?！?、關于檢查性例子與變化檢測者之間的區(qū)別的故事。在面向業(yè)務和面向技術方面是否存在不同。只有當我們把這些故事都收集起來之后，關于面向業(yè)務的例子的實踐才能被很好地理解，才能成為慣例，就像面向技術的例子的實踐一樣。敏捷測試指引〔5〕-用面向業(yè)務的例子批判產品原文：AgileTestingDirections–business-facingproductcritiques〔BrianMarick〕為了幫助討論和理解，我把“敏捷工程中的測試”這一主題分解成4個區(qū)分的主題。今天，我開始講矩陣的右邊：產品批判。使用面向業(yè)務的例子來設計產品是好的，但是假設例子是錯誤的怎么辦？誰都會犯錯誤。業(yè)務專家會忘記一些用戶真正需要的東西?；蛘邩I(yè)務專家錯誤地表達了需求，而程序員卻非常忠誠地實現(xiàn)了錯誤的東西。那些錯誤，如果記起來了或注意到了，那么可能會當作bug，也可能被認為是需要的功能特性。但兩者的界限很模糊。我會簡單地把它們叫做“問題”。問題是如何引起工程組的注意的呢？l很多敏捷工程組會在一個迭代結束時向業(yè)務專家和感興趣的外部人員演示軟件系統(tǒng)。這時候會是激怒某個人的時候，“噢.我是那樣說過，但是我不是這個意思”。l敏捷工程喜歡頻繁地發(fā)布軟件給它的用戶〔可能比用戶希望更新的頻率還要頻繁〕。當用戶試用產品的時候，他們會指出存在的問題。這些反響循環(huán)很緊湊，比傳統(tǒng)的工程要緊密，因為敏捷工程喜歡短的迭代。但是它們不是最理想的。業(yè)務專家可能由于過于靠近工程而不能以新的、沒有偏見的眼光去發(fā)現(xiàn)問題。用戶通常不報告他們在軟件使用中發(fā)現(xiàn)的問題。當他們反響問題時，報告得又不夠專業(yè)以致沒辦法執(zhí)行。而反響的周期不能像敏捷工程希望的那樣的頻繁?？赡軆H僅是針對一行代碼的改變的反響，但是需要等上3個月才能從用戶那收集到。因此，我們需要額外的產品批判形式–能注意到用戶會怎樣，而且能及時注意到。產品批判的方式擁有前期創(chuàng)立的例子所不具備的資源：一個新的迭代版本的真正工作的軟件。當你描述某些目前不存在的東西的時候，你是在腦海里操作一個抽象的東西，一個你想象中的物品。當你親手操作一個產品的時候會激發(fā)不同的理解和判斷。你可能注意到，當試駕一輛汽車的時候，你不會專注于它的規(guī)格說明。操縱是與思考不一樣的。因此，面向業(yè)務的產品批判應該專注于操作方面，嘗試逼近真正的不同用戶的體驗。就像JamesBach，CemKaner，ElisabethHendrickson他們所說的探索性測試〔Exploratory〕的形式。進一步的，我發(fā)現(xiàn)我們在嘗試至少5種類型的探索性測試：1、一個探索性測試員2、結對探索性測試員。JamesBach和CemKaner可能在這方面有最多的經驗。3、探索性測試員與一個程序員結對。JonathanKohl會在2004年1月的STQE雜志〔://stqemagazine/〕有一篇這樣的文章。我在這方面沒有什么經驗，程序員也喜歡這樣的方式。值得注意的是，當我在RoleModelSoftware進行這種方式的時候，它導致了一個有趣的并且有用的關于根底程序的討論。那樣的話，它成了一種類似回憶的方式，這進一步讓我相信它是迭代結束時很好的一種活動。4、讓探索性測試員與工程中的業(yè)務專家結對5、讓探索性測試員與感興趣的非參與者〔用SCRUM的術語來說就是“chickens，小雞”〕，例如經理主管、新用戶等等。對于每一種，我們應該探索關于什么時候測試員應該是工程組外的人的問題。這些外部的測試人員不會存在偏見和先入為主，但是存在缺點就是：他們需要花更多的時間來學習一些基本的東西。那也會使發(fā)現(xiàn)的問題存在一些偏離。當我一年前開始在敏捷工程談論探索性測試的時候，我想它會在發(fā)現(xiàn)bug的同時對提出一些大膽的關于產品的新構思有啟迪作用。一個過程能發(fā)現(xiàn)兩類問題。有一段時間，我把它叫做“探索性學習”來強調它的擴展的角色。后來我推斷這兩個目標不能很好地走在一起。因為找bug實在是太誘人了–對于功能特性的思考會在探索性測試的過程中迷失。有些時候能同時出現(xiàn)，但是缺乏夠。所以我想可能需要一個單獨的功能特性的腦力風暴活動。關于這一點，現(xiàn)在我還沒有什么特別好的主意。“需要進一步的研究”。敏捷測試指引〔6〕-用面向技術的例子批判產品原文：AgileTestingDirections–technology-facingproductcritiques〔BrianMarick〕為了幫助討論和理解，我把“敏捷工程中的測試”這一主題分解成4個區(qū)分的主題。今天，我將完成矩陣的右邊局部：面向技術的產品批判，而不是面向業(yè)務的。我選擇探索性測試作為面向業(yè)務的產品批判的工具。但是雖然它也可能找到平安性問題、性能問題、通常在壓力下才出現(xiàn)的bug、可用性問題〔例如對色盲人士的適用性〕等，但是我不會依賴它來完成這些方面的測試。而且，這些非功能性的問題或非功能性的需求很難用例子來詳細說明。所以看起來預防或找出這些bug目前為止還未納入到我們的故事中來。幸運的是，還有矩陣的最后一個四分區(qū)之一。我想關鍵是，找出這樣的非功能需求的bug更多的是技術性問題。你不能隨意地就能知道一些平安性的知識。性能測試可以說是“妖法”?？捎眯圆皇莻€“需要你知道很多計算機知識”的技術性的話題，但是它要求你知道很多關于人的知識〔MarkPilgrims的DiveIntoAccessibility，見:///，是個針對這方面的豐富知識的入門介紹〕。雖然我老是說敏捷工程需要“通才”，但是這里的區(qū)域那么需要的是“專才”。如果平安性是對于你的工程來說很重要的話，找個平安專家，在很多平安領域擁有豐富經驗的人。〔也就是說，平安知識要比領域知識重要?！尺@些人能教會工程組怎樣構建平安的產品、并測試平安性是否被構建到產品中?！灿腥さ氖牵哼@些區(qū)域給我的印象是在設計和批判的角色之間的別離沒有產品功能開發(fā)那么明顯。JakobNielsen既寫關于可用性設計的東西，也寫可用性測試方面的東西。平安性方面的人物也是類似的，像GrayMcGraw和BruceSchneier，除了JamesWhittaker好似專注于安全測試方面。我不知道我的印象是否正確？對于性能測試人員好似沒那么正確，雖然我知道很多優(yōu)秀的性能測試員也能出色地設計出高性能的系統(tǒng)?！骋虼?，敏捷好似沒有給這些人帶來什么東西。這些專家繼續(xù)存在，他們開展成不同的等級，他們值得進一步的開展，他們掌握了很多好的東西?？赡軙蝗缦胂笾械恼_，但是我想他們應該就這樣繼續(xù)保持著。看起來我好似完成了我的關于敏捷測試的未來指引的系列。但是還有一個問題：究竟，在敏捷工程中是否應該有測試員？對于這是個熱點問題，我應該覆蓋到。敏捷測試指引〔7〕-敏捷工程中的測試員原文：AgileTestingDirections–Testersonagileprojects〔BrianMarick〕敏捷工程中是否應該有測試員呢？首先：替換測試員的是誰？是讓非測試專業(yè)人員〔程序員、業(yè)務專家、技術文檔編寫人員等〕來執(zhí)行這樣的活動：幫助創(chuàng)立指導性的例子和對產品進行批判？還是，反過來，讓測試員來做編程、業(yè)務分析、技術寫作等工作呢？把“測試”僅僅作為技能的集合而存在，在工程中擁有充足的數(shù)量，用于效勞所有需要這些技能的任務。為什么非專業(yè)測試員會是個壞主意？這里是一些可能的原因：l測試技能很難學到。如果你嘗試作為測試員同時是程序員，或者作為測試員同時是技術文檔編寫人員，你不會擁有所需要的最少的技能來成為足夠好的測試員。l假設你是世界上最好的籃球運發(fā)動，同時是最棒的洗車工。你可能還是愿意讓別人幫你洗你的車，因為比起你自己洗車省下的錢，你可以賺取更多的時間來打籃球。這就是相對優(yōu)勢的一個例子。因此，為什么不讓一個懂得測試的訣竅的人只是做測試，而讓一個在編程方面相對強的人專注于編程呢？l測試雖然說不上是是一種天生的技能，但是某些人就是喜歡吹毛求疵，有些人那么不擅于批判。l很多人在找自己工作的錯誤時會有困難。因此把測試和其它任務混在一起的話會測試得很糟糕。中間存在太多情緒上的利益沖突了。l測試員能從“有用的無知”得到很多益處。不知道實現(xiàn)的細節(jié)使得他們更容易從用戶的角度看什么類型的錯誤是用戶容易犯的。論據(jù)讓我首先解釋一下“最小所需技能”和“相對優(yōu)勢”。這些論據(jù)在面向技術的產品批判中是最強的，像平安性測試或可用性測試。在一個實際的工程，我一定能看到專門的平安性測試員。在小一點的工程，我能看到臨時出現(xiàn)的平安性測試員。對于我在面向業(yè)務的產品批判中所依賴的探索性測試員，我不那么確信。探索性測試員發(fā)現(xiàn)的這么多的bug中，很多是程序員可以預防的，如果他們能經?？纯茨切゜ug并使它們內在化。把bug內在化的最好的途徑是把程序員納入到尋找bug的行列，而不僅僅是修改bug。如果測試人員來寫其中的一些代碼，那么bug會