從2000年開始從事軟件測(cè)試，逐漸形成自己的軟件測(cè)試思想，而第一次比較清晰呈現(xiàn)自己的測(cè)試的思想是2007年出版的《全程軟件測(cè)試》，正如前言所敘：“從項(xiàng)目啟動(dòng)的第一天起到需求和設(shè)計(jì)的評(píng)審階段，從后期的缺陷修正到產(chǎn)品維護(hù)——在整個(gè)軟件生命周期中，開發(fā)人員和測(cè)試人員愉快地合作、共同努力，將軟件產(chǎn)品的開發(fā)效率和質(zhì)量推到一個(gè)新的高度。”，這些思想在測(cè)試管理工作的體現(xiàn)就是讓測(cè)試人員更早地融入項(xiàng)目中，更主動(dòng)、更密切地與開發(fā)人員協(xié)作，與項(xiàng)目相關(guān)利益者合作，確保項(xiàng)目按時(shí)按質(zhì)地完成，即：

• 測(cè)試人員越快地發(fā)現(xiàn)缺陷，項(xiàng)目越能盡早結(jié)束；
• 測(cè)試人員盡可能多地發(fā)現(xiàn)Bug，遺留在產(chǎn)品中的Bug就會(huì)越少，產(chǎn)品的質(zhì)量就會(huì)越高； 
• 測(cè)試人員和自己（開發(fā)人員）的工作都是為了相同的目標(biāo)——按時(shí)、高質(zhì)量地發(fā)布產(chǎn)品； 

而此后和業(yè)界的測(cè)試人員、開發(fā)人員交流更多，思考得更多，在測(cè)試上的思想更清晰，于是在2012年9月5日在新浪微博（http://weibo.com/1652927771/yArIqoCKW ）上發(fā)表了自己的個(gè)人軟件測(cè)試宣言：

宣言發(fā)布后，得到不少網(wǎng)友的肯定。最給力的，要屬@培根芝士牛蛙堡:感覺總結(jié)的太到位，can’t agree more了，最近在看《軟測(cè)之魂》，很多觀點(diǎn)都是異曲同工啊，雖說就簡(jiǎn)單四句話，但是每一句話展開去都能寫一本書。還有@讓測(cè)試飛起來：又見右下八卦圖亮點(diǎn)。每當(dāng)遇到左、右難以分辯時(shí)就想到它，并以此為基點(diǎn)，償試思考再進(jìn)一步，思絲多而力爭(zhēng)不亂。分割線不是直的喲，似乎體現(xiàn)開發(fā)中有測(cè)試(調(diào)試)，測(cè)試中有開發(fā)，而又不完全符合對(duì)立統(tǒng)一。

當(dāng)然，也有不同聲音，例如：@胡爭(zhēng)輝：首先應(yīng)當(dāng)強(qiáng)調(diào)產(chǎn)品工程，然后在產(chǎn)品工程中強(qiáng)調(diào)需求工程，其次在需求工程的基礎(chǔ)上強(qiáng)調(diào)品質(zhì)保證工程。脫離的產(chǎn)品工程的品質(zhì)保證工程是無本之木，無源之水。這實(shí)際和我宣言沒有關(guān)系，這里絲毫沒有否定產(chǎn)品工程，也沒有否定需求工程，實(shí)際第一句“更鼓勵(lì)事先確定驗(yàn)證的標(biāo)準(zhǔn)并以此來驅(qū)動(dòng)開發(fā)”就是強(qiáng)調(diào)需求的重要性。需求是軟件開發(fā)的源泉，而這里關(guān)注點(diǎn)是“軟件測(cè)試”，比較局限于測(cè)試自身的內(nèi)涵和測(cè)試與開發(fā)的關(guān)系。如果拓展出去，我需要發(fā)表我的“軟件工程宣言”了。

還有其它有意義的補(bǔ)充：

•  @程序員鄒欣：值得開發(fā)，測(cè)試，項(xiàng)目管理人員思考。 認(rèn)可內(nèi)部測(cè)試的重要性, 但更重視產(chǎn)品對(duì)用戶的長(zhǎng)期影響；
•  @王立杰-WangLijie：認(rèn)可測(cè)試對(duì)質(zhì)量的改善，但更提倡質(zhì)量是內(nèi)建的；
•  與@Testin-Daiyibin 討論之后，增加一條，即：認(rèn)可自動(dòng)化測(cè)試的價(jià)值，但更提倡測(cè)試分析和設(shè)計(jì)的創(chuàng)造性和系統(tǒng)性。

那下面回歸主題，就我自己的軟件測(cè)試宣言，逐條分別進(jìn)行說明，并簡(jiǎn)要闡述如何將它們應(yīng)用于實(shí)際的軟件開發(fā)工作之中。

1. 認(rèn)可測(cè)試的價(jià)值，但更鼓勵(lì)事先確定驗(yàn)證的標(biāo)準(zhǔn)并以此來驅(qū)動(dòng)開發(fā) 

首先認(rèn)識(shí)測(cè)試的價(jià)值，測(cè)試是質(zhì)量保證的重要手段之一，正如在我的博客中所討論的“軟件測(cè)試究竟發(fā)揮什么作用？”：

• 對(duì)產(chǎn)品質(zhì)量完成全面的評(píng)估，為軟件產(chǎn)品發(fā)布（如驗(yàn)收測(cè)試）、軟件系統(tǒng)部署（如性能規(guī)劃測(cè)試）、軟件產(chǎn)品鑒定（第三方獨(dú)立測(cè)試）委托方和被委托方糾紛仲裁（第三方獨(dú)立測(cè)試）和其它決策提供信息；
• 通過持續(xù)的測(cè)試（包括需求評(píng)審、設(shè)計(jì)評(píng)審、代碼評(píng)審等）可以對(duì)產(chǎn)品質(zhì)量提供持續(xù)的、快速的反饋，從而在整個(gè)開發(fā)過程中不斷地、及時(shí)地改進(jìn)產(chǎn)品的質(zhì)量，并減少各種返工，降低軟件開發(fā)的成本；
• 通過測(cè)試發(fā)現(xiàn)所要交付產(chǎn)品的缺陷，特別是盡可能地發(fā)現(xiàn)各種嚴(yán)重的缺陷，降低或消除產(chǎn)品質(zhì)量風(fēng)險(xiǎn)，提高客戶的滿意度，擴(kuò)大市場(chǎng)份額，提高客戶的忠誠(chéng)度。
• 通過對(duì)缺陷進(jìn)行分析，找出缺陷發(fā)生的根本原因（軟件過程中的問題，包括錯(cuò)誤的行為方式）或總結(jié)出軟件產(chǎn)品的缺陷模式，避免將來犯同樣的錯(cuò)誤或產(chǎn)生類似的產(chǎn)品問題，達(dá)到缺陷預(yù)防的目的

所以軟件測(cè)試的價(jià)值不容忽視，但是我們一直提倡“質(zhì)量更是內(nèi)建的（Quality is built in）”，軟件產(chǎn)品的質(zhì)量是在需求分析、功能設(shè)計(jì)、系統(tǒng)設(shè)計(jì)、編程等過程中逐漸形成的，事先清楚客戶的需求，明確軟件產(chǎn)品的驗(yàn)收標(biāo)準(zhǔn)，基于這些需求和驗(yàn)收標(biāo)準(zhǔn)來開發(fā)，開發(fā)人員清楚自己要實(shí)現(xiàn)的目標(biāo)、清楚待實(shí)現(xiàn)系統(tǒng)的要求和限制，在工作中能夠第一次將事情做對(duì)，或者說，第一次將事情做對(duì)的可能性會(huì)顯著提高，在需求、設(shè)計(jì)、代碼中引入的缺陷就會(huì)大大減少。理解這一點(diǎn)并不難，如果還是不能很好理解，就看看磚墻是如何砌成的？是先拉上水準(zhǔn)線再墻砌，還是墻砌好之后再拉線來檢測(cè)？

而且，對(duì)測(cè)試人員說，全生命周期的測(cè)試依據(jù)也明確了，能夠及時(shí)提供明確的質(zhì)量反饋，測(cè)試與開發(fā)之間也不容易引起的爭(zhēng)議，測(cè)試效率也會(huì)明顯改善。本句宣言和驗(yàn)收測(cè)試驅(qū)動(dòng)開發(fā)（Acceptance Test Driven Development, ATDD）擁有共同的思想和內(nèi)涵，無論是在傳統(tǒng)研發(fā)流程中還是在敏捷過程中，都可以嘗試這樣去做。雖然在某些項(xiàng)目上需求不夠清楚、或需求變化比較大，但也不能成為“自己懶于徹底分析需求”的借口，能明確60%的需求，也不能做到30%就停下來了。 否則，無論是“迭代”、還是“重構(gòu)”，都是“返工”美化之后的代名詞。難道企業(yè)希望自己團(tuán)隊(duì)常犯錯(cuò)誤而不斷修正嗎？

2. 認(rèn)可專業(yè)測(cè)試人員的不可替代的價(jià)值，但更鼓勵(lì)開發(fā)人員做好測(cè)試

上一句已經(jīng)回答了測(cè)試的價(jià)值，而這里是討論測(cè)試工作由誰來做？測(cè)試有價(jià)值，但不一定由專職的測(cè)試人員來做，正如一些公司（如facebook）沒有專職的測(cè)試人員，軟件產(chǎn)品的研發(fā)也能正常開展。也許在某些初創(chuàng)的企業(yè)、特殊商業(yè)模式的軟件服務(wù)、某些移動(dòng)終端的且免費(fèi)的產(chǎn)品等可以不要專職的測(cè)試人員，但對(duì)大多數(shù)軟件產(chǎn)品、軟件企業(yè)還是需要專業(yè)的測(cè)試人員，因?yàn)橄到y(tǒng)復(fù)雜、業(yè)務(wù)更復(fù)雜的原因，更可能是測(cè)試本身更需要方法和技術(shù)。當(dāng)我們不能簡(jiǎn)單地掌握軟件產(chǎn)品（系統(tǒng)）的測(cè)試方法和技術(shù)，就需要專業(yè)的測(cè)試人員。即使在相對(duì)低端的制造業(yè)，掌握其工作技能不是很難，但熟練工人的工作效率也是初級(jí)操作工的幾倍。而軟件測(cè)試所涉及的方法、技術(shù)與工具，從功能測(cè)試到性能測(cè)試、安全性測(cè)試、兼容測(cè)試、可達(dá)性測(cè)試到可靠性測(cè)試等，從測(cè)試計(jì)劃、測(cè)試分析與設(shè)計(jì)到測(cè)試結(jié)果分析，從等價(jià)類劃分、判定表、因果圖到基于模型的測(cè)試、自動(dòng)化測(cè)試等，已形成一個(gè)龐大的體系，沒有專注，很難做得精，不能精通測(cè)試，又如何有良好的測(cè)試效率呢？沒有專業(yè)的測(cè)試技能，測(cè)試的風(fēng)險(xiǎn)也很大。這些內(nèi)容，在我的另一篇博客“專業(yè)測(cè)試團(tuán)隊(duì)會(huì)消亡還是新生”進(jìn)行了充分討論。正如網(wǎng)友在本博客上還評(píng)論說：“如果沒有專業(yè)的測(cè)試團(tuán)隊(duì)，那么天上的飛機(jī)一定會(huì)無緣無故地掉下來，ICU里面的心電監(jiān)護(hù)儀罷工也不會(huì)是新聞，核彈未接收到真正的發(fā)射命令而自行啟動(dòng)也不是沒有可能，這個(gè)世界將不再是安全的世界。”

為什么更鼓勵(lì)開發(fā)人員做好測(cè)試呢？這是因?yàn)椋?/span>

• 單元測(cè)試是基礎(chǔ)，沒有單元的質(zhì)量，如何有系統(tǒng)的質(zhì)量？而單元測(cè)試主要是在代碼層次上展開，而且和編程交織在一起，編程和單元測(cè)試難以分開處理，所以單元測(cè)試最好由開發(fā)人員來做，確保良好的工作效率與工作質(zhì)量；
• 如果開發(fā)了一個(gè)測(cè)試工具，先讓開發(fā)人員用起來好，還是只讓測(cè)試人員用？無論是功能測(cè)試工具還是性能測(cè)試、安全性測(cè)試工具，都可以讓開發(fā)人員先用，測(cè)試的效率會(huì)更高。一邊構(gòu)建、一邊驗(yàn)證，更能及時(shí)發(fā)現(xiàn)問題，能更快調(diào)試和修正問題，將問題消除在萌芽之中。這也就是為什么我們一直提倡持續(xù)構(gòu)建、持續(xù)測(cè)試；
• 如果開發(fā)人員做更多測(cè)試，就更能認(rèn)識(shí)到自己的問題，了解問題產(chǎn)生的原因，將來在設(shè)計(jì)、編程中更好地避免同樣問題的發(fā)生，預(yù)防缺陷效果更好。

這里鼓勵(lì)開發(fā)人員做的測(cè)試，主要集中在單元測(cè)試（功能、性能方面的測(cè)試）、集成測(cè)試等方面。而系統(tǒng)的測(cè)試、用戶需求的進(jìn)一步驗(yàn)證和確認(rèn)、大規(guī)模的性能測(cè)試、兼容性測(cè)試、安全性測(cè)試等則有專業(yè)的測(cè)試人員完成。

3. 認(rèn)可測(cè)試計(jì)劃的價(jià)值，但更強(qiáng)調(diào)計(jì)劃是一個(gè)基于風(fēng)險(xiǎn)不斷調(diào)整的過程

這點(diǎn)比較容易理解，做一件事，如果沒有計(jì)劃就比較盲目，失敗的可能性就很大。測(cè)試計(jì)劃目的就是明確測(cè)試的目標(biāo)、測(cè)試的需求（包括測(cè)試范圍、測(cè)試任務(wù)優(yōu)先級(jí)等）、測(cè)試風(fēng)險(xiǎn)、測(cè)試資源和進(jìn)度安排等，但同時(shí)需求會(huì)發(fā)生變更、開發(fā)的設(shè)計(jì)與代碼質(zhì)量超出我們的預(yù)料、測(cè)試工作量估算不足以及其它新的測(cè)試風(fēng)險(xiǎn)等各種因素的影響，我們可能需要不斷調(diào)整測(cè)試計(jì)劃，以適應(yīng)新的測(cè)試需求等。計(jì)劃重要，但不是一成不變的，也就是我們強(qiáng)調(diào)：

• 測(cè)試計(jì)劃不能停留在文檔上面，它是對(duì)測(cè)試過程的規(guī)劃與指導(dǎo)，使測(cè)試工作開展得更順利、更有效；
• 測(cè)試計(jì)劃不是一個(gè)文檔，而是一個(gè)計(jì)劃的過程，適時(shí)調(diào)整以及時(shí)滿足項(xiàng)目新的需求；
• 對(duì)測(cè)試計(jì)劃的調(diào)整也是學(xué)習(xí)的過程，有利于將來（為下一個(gè)項(xiàng)目）制定出更可靠的測(cè)試計(jì)劃。

4. 認(rèn)可探索式測(cè)試的價(jià)值，但更希望測(cè)試是具有系統(tǒng)方法的、相對(duì)規(guī)范的過程

我們都知道，測(cè)試不能窮盡，測(cè)試不能做到百分之百，總是有不能測(cè)到的地方，總是有缺陷遺留下來，這就給我們留下了足夠的探索空間。探索式測(cè)試（Exploratory Testing，ET）的出現(xiàn)正是因?yàn)樵谲浖到y(tǒng)中存在許多未知的東西難以得到快速、簡(jiǎn)單的驗(yàn)證，需要我們轉(zhuǎn)變思路，不要以固定的模式來完成測(cè)試，而是要換一種新的模式來進(jìn)行測(cè)試，以提高測(cè)試效率。因?yàn)樾枨蟛磺宄r(shí)間緊等各種原因，探索式測(cè)試才更有效，在一定程度上是因?yàn)檐浖_發(fā)本身的問題，所以，我也戲稱“敏捷開發(fā)”為“探索式開發(fā)”。從這個(gè)意義上講，探索式測(cè)試方法是不得已而為之的一種方式。在傳統(tǒng)行業(yè)，沒有看到一種“探索式檢驗(yàn)”（除了食品安全檢驗(yàn)，在我國(guó)還不夠成熟，可能會(huì)采用探索式檢驗(yàn)，哈哈），而是有明確的技術(shù)規(guī)格，有相應(yīng)的檢測(cè)儀器或方法進(jìn)行檢驗(yàn)，可以明確地給出檢查結(jié)果。

探索式測(cè)試作為明確的術(shù)語或概念，最早是由測(cè)試專家CemKaner博士在1983年提出的，距今天差不多有30年，但絕大多數(shù)測(cè)試人只是最近幾年才聽到或熟知這個(gè)概念。說明其價(jià)值是有限的，如果價(jià)值很高，也不至于我們現(xiàn)在才比較關(guān)注的。但最近幾年探索式測(cè)試很熱，為什么？

一方面要感謝James A. Whittaker撰寫的《ExploratorySoftware Testing》一書，比較全面地介紹了探索式軟件測(cè)試（國(guó)內(nèi)是2010年引進(jìn)本書的，但也有不足，我在為史亮和高翔寫的《探索式測(cè)試實(shí)踐之路》的序中談到這一點(diǎn)），對(duì)推廣探索式測(cè)試有很大的促進(jìn)作用。另方面，在互聯(lián)網(wǎng)時(shí)代，需求衍變?cè)絹碓娇欤卉浖呀?jīng)成為一種服務(wù)（SaaS），迭代周期越來越頻繁。敏捷方法開始流行，被軟件企業(yè)廣泛采用，敏捷測(cè)試隨之而生，正是探索式測(cè)試用武之時(shí)。而且探索式測(cè)試的確給人一些新鮮的感覺，將測(cè)試工作變成更有趣的探索式活動(dòng)，在享受工作的同時(shí)完成測(cè)試，容易受到測(cè)試工程師的歡迎。

探索式測(cè)試也在不斷發(fā)展，人們?cè)噲D幫助它建立一套方法體系，例如James Bach提出的基于會(huì)話的測(cè)試管理(Session Based Test Management,簡(jiǎn)稱 SBTM)。該管理方法將測(cè)試任務(wù)分解成一系列會(huì)話(Sessions，發(fā)生在特定時(shí)間盒內(nèi)的會(huì)話活動(dòng)，對(duì)軟件系統(tǒng)的測(cè)試就是看成不斷地問系統(tǒng)的過程，從系統(tǒng)那里獲得答案，探索式測(cè)試的會(huì)話特征更為明顯),測(cè)試人員在會(huì)話過程中完成一個(gè)特定測(cè)試任務(wù)的設(shè)計(jì)、執(zhí)行和記錄。

但從探索式測(cè)試的“探索”概念本身來看，還是強(qiáng)調(diào)“設(shè)計(jì)與執(zhí)行”同時(shí)發(fā)生的特點(diǎn)來看，探索式測(cè)試更多強(qiáng)調(diào)人的創(chuàng)造性，強(qiáng)調(diào)隨軟件功能的使用對(duì)其理解不斷深入來發(fā)現(xiàn)問題，更強(qiáng)調(diào)這種上下文驅(qū)動(dòng)的思維模式，而對(duì)驗(yàn)收的標(biāo)準(zhǔn)、驗(yàn)證的具體指標(biāo)缺乏關(guān)注，更談不上測(cè)試需求的分析、測(cè)試的系統(tǒng)設(shè)計(jì)，在系統(tǒng)性和規(guī)范性方面有很大的欠缺，所以難以得到國(guó)際標(biāo)準(zhǔn)的支持，在多數(shù)軟件產(chǎn)品的測(cè)試工作中探索式測(cè)試只能起著輔助、補(bǔ)充的作用。

任何嚴(yán)重的缺陷的遺漏可能給公司帶來不可估量的損失，軟件測(cè)試更注重對(duì)軟件質(zhì)量的全面評(píng)估，最大程度地減少軟件產(chǎn)品的質(zhì)量風(fēng)險(xiǎn)，從這個(gè)意義看，測(cè)試目標(biāo)、測(cè)試需求、測(cè)試風(fēng)險(xiǎn)等都是非常重要的，需要認(rèn)真分析，然后在此基礎(chǔ)上進(jìn)行系統(tǒng)的測(cè)試設(shè)計(jì)。測(cè)試的結(jié)果需要嚴(yán)格的覆蓋率衡量，而要確保高覆蓋率，需要事先進(jìn)行精心的設(shè)計(jì)，從業(yè)務(wù)流程、數(shù)據(jù)流程、用戶場(chǎng)景等各個(gè)方面進(jìn)行細(xì)致分析，采用合適的測(cè)試方法設(shè)計(jì)出相應(yīng)的測(cè)試用例來覆蓋流程路徑、數(shù)據(jù)輸入空間以及各種產(chǎn)品使用的場(chǎng)景。事先能從需求覆蓋出發(fā)來設(shè)計(jì)測(cè)試用例，事后還可以從代碼覆蓋來檢驗(yàn)測(cè)試的效果。當(dāng)然，更理想的方式是用基于模型的測(cè)試或形式化方法來驗(yàn)證系統(tǒng)的需求，給出更客觀的、更準(zhǔn)確的質(zhì)量評(píng)估，我們對(duì)產(chǎn)品的發(fā)布就更有信心，客戶就能得到高質(zhì)量的產(chǎn)品或服務(wù)。

5. 認(rèn)可發(fā)現(xiàn)缺陷的價(jià)值，但更重視對(duì)軟件產(chǎn)品質(zhì)量的全面評(píng)估與持續(xù)反饋

發(fā)現(xiàn)一個(gè)缺陷并得到修正，產(chǎn)品的質(zhì)量就減少一份風(fēng)險(xiǎn)；在當(dāng)前產(chǎn)品中發(fā)現(xiàn)的缺陷越多，就能更多地消除產(chǎn)品的質(zhì)量風(fēng)險(xiǎn)，這是軟件測(cè)試價(jià)值之一個(gè)方面的體現(xiàn)。但我們不能有這樣的思想：測(cè)試人員發(fā)現(xiàn)的缺陷越多，測(cè)試人員的價(jià)值越大。例如，我們不能一直等開發(fā)人員把設(shè)計(jì)、代碼都工作全部完成之后，我們?cè)賮戆l(fā)現(xiàn)問題，以體現(xiàn)測(cè)試的價(jià)值。我們更不能明明看著開發(fā)人員犯錯(cuò)誤、或者明明知道開發(fā)人員可能會(huì)在某些地方犯錯(cuò)誤，我們也不給予提醒、不給予幫助，而是等到他們做完工作，我們?cè)侔褑栴}發(fā)現(xiàn)出來，以體現(xiàn)我們的價(jià)值。

正確的做法則是及時(shí)提供有關(guān)質(zhì)量的反饋，可能是一種質(zhì)量風(fēng)險(xiǎn)的提示，也可能是一種質(zhì)量擔(dān)心的傾訴，更可能是一種有關(guān)質(zhì)量改進(jìn)的、積極的建議。例如：

• 在需求分析時(shí)，發(fā)現(xiàn)需求不夠清晰，發(fā)現(xiàn)可能給開發(fā)、測(cè)試帶來困惑的地方，都要及時(shí)指出來，并幫助糾正。
• 如果發(fā)現(xiàn)文檔中新增加的功能沒有多大意義，或者是自己難以看清楚其功能對(duì)客戶的價(jià)值，就要主動(dòng)和產(chǎn)品經(jīng)理溝通，建議拿掉這個(gè)功能，或讓產(chǎn)品經(jīng)理解釋清楚、說服自己。
• 如果覺得開發(fā)任務(wù)安排不合理，或覺得開發(fā)之前的討論、培訓(xùn)不夠，對(duì)業(yè)務(wù)理解還很膚淺，就要及時(shí)和開發(fā)溝通，幫忙消除這種潛在的質(zhì)量風(fēng)險(xiǎn)；
• 如果發(fā)現(xiàn)開發(fā)不重視單元測(cè)試、或者單元測(cè)試做得很少，就要協(xié)助開發(fā)做好單元測(cè)試，提供單元測(cè)試指導(dǎo)，提供單元測(cè)試框架，提供一切可以幫助開發(fā)改善單元測(cè)試的服務(wù)。
• 如果發(fā)現(xiàn)個(gè)別的開發(fā)工程師不遵守編程規(guī)范，就要啟動(dòng)質(zhì)量反饋機(jī)制…
•  … …

這意味著：

• 測(cè)試工作不是軟件開發(fā)生命周期的某個(gè)環(huán)境、某個(gè)階段性的工作，而是貫穿整個(gè)軟件軟件開發(fā)生命周期，測(cè)試人員無時(shí)無刻不在關(guān)注質(zhì)量；
• 測(cè)試人員不僅僅要關(guān)注已經(jīng)存在的產(chǎn)品缺陷的問題，還要關(guān)注可能導(dǎo)致缺陷發(fā)生的問題，盡量幫助產(chǎn)品需求人員、設(shè)計(jì)人員、編程人員預(yù)防質(zhì)量問題的發(fā)生。
• 測(cè)試不僅僅是測(cè)試人員的工作，而且和軟件開發(fā)的其他團(tuán)隊(duì)（人員）有關(guān)系；測(cè)試工作不是測(cè)試團(tuán)隊(duì)內(nèi)部的事，而是整個(gè)開發(fā)團(tuán)隊(duì)的事。