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

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

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

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

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

還有其它有意義的補充：

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

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

1. 認可測試的價值，但更鼓勵事先確定驗證的標準并以此來驅(qū)動開發(fā) 

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

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

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

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

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

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

為什么更鼓勵開發(fā)人員做好測試呢？這是因為：

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

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

3. 認可測試計劃的價值，但更強調(diào)計劃是一個基于風險不斷調(diào)整的過程

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

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

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

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

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

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

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

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

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

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

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

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

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

這意味著：

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