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

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

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

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

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

還有其它有意義的補充：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. 認可發現缺陷的價值，但更重視對軟件產品質量的全面評估與持續反饋

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

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

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

這意味著：

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