宣言發布後，得到不少網友的肯定。最給力的，要屬@培根芝士牛蛙堡
:感覺總結的太到位，
can』
t agree more
了，最近在看《軟測之魂》，很多觀點都是異曲同工啊，雖說就簡單四句話，但是每一句話展開去都能寫一本書
。還有@
讓測試飛起來
：又見右下八卦圖亮點。每當遇到左、右難以分辯時就想到它，並以此為基點，償試思考再進一步，思絲多而力爭不亂。分割線不是直的喲，似乎體現開發中有測試(除錯)，測試中有開發，而又不完全符合對立統一。
當然，也有不同聲音，例如：@胡爭輝
：首先應當強調產品工程，然後在產品工程中強調需求工程，其次在需求工程的基礎上強調品質保證工程。脫離的產品工程的品質保證工程是無本之木，無源之水。這實際和我宣言沒有關係，這裡絲毫沒有否定產品工程，也沒有否定需求工程，實際第一句「更鼓勵事先確定驗證的標準並以此來驅動開發」就是強調需求的重要性。需求是軟體開發的源泉，而這裡關注點是「軟體測試」，比較侷限於測試自身的內涵和測試與開發的關係。如果拓展出去，我需要發表我的「軟體工程宣言」了。
還有其它有意義的補充：
那下面回歸主題，就我自己的軟體測試宣言，逐條分別進行說明，並簡要闡述如何將它們應用於實際的軟體開發工作之中。
1. 認可測試的價值，但更鼓勵事先確定驗證的標準並以此來驅動開發
首先認識測試的價值，測試是質量保證的重要手段之一，正如在我的部落格中所討論的「
軟體測試究竟發揮什麼作用？
」：所以軟體測試的價值不容忽視，但是我們一直提倡「質量更是內建的（quality is built in）」，軟體產品的質量是在需求分析、功能設計、系統設計、程式設計等過程中逐漸形成的，事先清楚客戶的需求，明確軟體產品的驗收標準，基於這些需求和驗收標準來開發，開發人員清楚自己要實現的目標、清楚待實現系統的要求和限制，在工作中能夠第一次將事情做對，或者說，第一次將事情做對的可能性會顯著提高，在需求、設計、**中引入的缺陷就會大大減少。理解這一點並不難，如果還是不能很好理解，就看看磚牆是如何砌成的？是先拉上水準線再牆砌，還是牆砌好之後再拉線來檢測？
而且，對測試人員說，全生命週期的測試依據也明確了，能夠及時提供明確的質量反饋，測試與開發之間也不容易引起的爭議，測試效率也會明顯改善。本句宣言和驗收測試驅動開發（acceptance test driven development, atdd）擁有共同的思想和內涵，無論是在傳統研發流程中還是在敏捷過程中，都可以嘗試這樣去做。雖然在某些專案上需求不夠清楚、或需求變化比較大，但也不能成為「自己懶於徹底分析需求」的藉口，能明確60%的需求，也不能做到30%就停下來了。 否則，無論是「迭代」、還是「重構」，都是「返工」美化之後的代名詞。難道企業希望自己團隊常犯錯誤而不斷修正嗎？
2. 認可專業測試人員的不可替代的價值，但更鼓勵開發人員做好測試
上一句已經回答了測試的價值，而這裡是討論測試工作由誰來做？測試有價值，但不一定由專職的測試人員來做，正如一些公司（如facebook）沒有專職的測試人員，軟體產品的研發也能正常開展。也許在某些初創的企業、特殊商業模式的軟體服務、某些移動終端的且免費的產品等可以不要專職的測試人員，但對大多數軟體產品、軟體企業還是需要專業的測試人員，因為系統複雜、業務更複雜的原因，更可能是測試本身更需要方法和技術。當我們不能簡單地掌握軟體產品（系統）的測試方法和技術，就需要專業的測試人員。即使在相對低端的製造業，掌握其工作技能不是很難，但熟練工人的工作效率也是初級操作工的幾倍。而軟體測試所涉及的方法、技術與工具，從功能測試到效能測試、安全性測試、相容測試、可達性測試到可靠性測試等，從測試計畫、測試分析與設計到測試結果分析，從等價類劃分、判定表、因果圖到基於模型的測試、自動化測試等，已形成乙個龐大的體系，沒有專注，很難做得精，不能精通測試，又如何有良好的測試效率呢？沒有專業的測試技能，測試的風險也很大。這些內容，在我的另一篇部落格「
專業測試團隊會消亡還是新生
如果沒有專業的測試團隊
，那麼天上的飛機一定會無緣無故地掉下來，icu裡面的心電監護儀罷工也不會是新聞，核彈未接收到真正的發射命令而自行啟動也不是沒有可能，
這個世界將不再是安全的世界。」
為什麼更鼓勵開發人員做好測試呢？這是因為：
這裡鼓勵開發人員做的測試，主要集中在單元測試（功能、效能方面的測試）、整合測試等方面。而系統的測試、使用者需求的進一步驗證和確認、大規模的效能測試、相容性測試、安全性測試等則有專業的測試人員完成。
3. 認可測試計畫的價值，但更強調計畫是乙個基於風險不斷調整的過程
這點比較容易理解，做一件事，如果沒有計畫就比較盲目，失敗的可能性就很大。測試計畫目的就是明確測試的目標、測試的需求（包括測試範圍、測試任務優先順序等）、測試風險、測試資源和進度安排等，但同時需求會發生變更、開發的設計與**質量超出我們的預料、測試工作量估算不足以及其它新的測試風險等各種因素的影響，我們可能需要不斷調整測試計畫，以適應新的測試需求等。計畫重要，但不是一成不變的，也就是我們強調：
4. 認可探索式測試的價值，但更希望測試是具有系統方法的、相對規範的過程
我們都知道，測試不能窮盡，測試不能做到百分之百，總是有不能測到的地方，總是有缺陷遺留下來，這就給我們留下了足夠的探索空間。探索式測試（exploratory testing，et）的出現正是因為在軟體系統中存在許多未知的東西難以得到快速、簡單的驗證，需要我們轉變思路，不要以固定的模式來完成測試，而是要換一種新的模式來進行測試，以提高測試效率。因為需求不清楚、時間緊等各種原因，探索式測試才更有效，在一定程度上是因為軟體開發本身的問題，所以，我也戲稱「敏捷開發」為「探索式開發」。從這個意義上講，探索式測試方法是不得已而為之的一種方式。在傳統行業，沒有看到一種「探索式檢驗」（除了食品安全檢驗，在我國還不夠成熟，可能會採用探索式檢驗，哈哈），而是有明確的技術規格，有相應的檢測儀器或方法進行檢驗，可以明確地給出檢查結果。
探索式測試作為明確的術語或概念，最早是由測試專家cemkaner博士在2023年提出的，距今天差不多有30年，但絕大多數測試人只是最近幾年才聽到或熟知這個概念。說明其價值是有限的，如果價值很高，也不至於我們現在才比較關注的。但最近幾年探索式測試很熱，為什麼？
一方面要感謝james a. whittaker撰寫的《exploratorysoftware testing
》一書，比較全面地介紹了探索式軟體測試（國內是2023年引進本書的，但也有不足，我在為史亮和高翔寫的《探索式測試實踐之路》的序中談到這一點），對推廣探索式測試有很大的促進作用。另方面，在網際網路時代，需求衍變越來越快；軟體已經成為一種服務（saas），迭代週期越來越頻繁。敏捷方法開始流行，被軟體企業廣泛採用，敏捷測試隨之而生，正是探索式測試用武之時。而且探索式測試的確給人一些新鮮的感覺，將測試工作變成更有趣的探索式活動，在享受工作的同時完成測試，容易受到測試工程師的歡迎。
探索式測試也在不斷發展，人們試圖幫助它建立一套方法體系，例如james bach提出的基於會話的測試管理(session based test management,簡稱 sbtm)。該管理方法將測試任務分解成一系列會話(sessions，發生在特定時間盒內的會話活動，對軟體系統的測試就是看成不斷地問系統的過程，從系統那裡獲得答案，探索式測試的會話特徵更為明顯),測試人員在會話過程中完成乙個特定測試任務的設計、執行和記錄。
任何嚴重的缺陷的遺漏可能給公司帶來不可估量的損失，軟體測試更注重對軟體質量的全面評估，最大程度地減少軟體產品的質量風險，從這個意義看，測試目標、測試需求、測試風險等都是非常重要的，需要認真分析，然後在此基礎上進行系統的測試設計。測試的結果需要嚴格的覆蓋率衡量，而要確保高覆蓋率，需要事先進行精心的設計，從業務流程、資料流程、使用者場景等各個方面進行細緻分析，採用合適的測試方法設計出相應的測試用例來覆蓋流程路徑、資料輸入空間以及各種產品使用的場景。事先能從需求覆蓋出發來設計測試用例，事後還可以從**覆蓋來檢驗測試的效果。當然，更理想的方式是用基於模型的測試或形式化方法來驗證系統的需求，給出更客觀的、更準確的質量評估，我們對產品的發布就更有信心，客戶就能得到高質量的產品或服務。
5. 認可發現缺陷的價值，但更重視對軟體產品質量的全面評估與持續反饋
發現乙個缺陷並得到修正，產品的質量就減少乙份風險；在當前產品中發現的缺陷越多，就能更多地消除產品的質量風險，這是軟體測試價值之乙個方面的體現。但我們不能有這樣的思想：測試人員發現的缺陷越多，測試人員的價值越大。例如，我們不能一直等開發人員把設計、**都工作全部完成之後，我們再來發現問題，以體現測試的價值。我們更不能明明看著開發人員犯錯誤、或者明明知道開發人員可能會在某些地方犯錯誤，我們也不給予提醒、不給予幫助，而是等到他們做完工作，我們再把問題發現出來，以體現我們的價值。
正確的做法則是及時提供有關質量的反饋，可能是一種質量風險的提示，也可能是一種質量擔心的傾訴，更可能是一種有關質量改進的、積極的建議。例如：
這意味著：
軟體開發宣言
敏捷軟體開發宣言及原則 宣言 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過 遵循計畫 原則 1 我們最優先做的是通過盡早 持續的交付有價值的軟體來使客戶滿意。2 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。...
敏捷軟體開發宣言
注 以人為本的思想，利用工具的是人，遵循過程的也是人，如果有最好的工具和過程，而個體卻沒有很好的去利用工具，遵循過程的話，工具和過程也不能發揮預計的效果 另外，流程和工具的一部分作用也是為了團隊成員更好地互動 所以個體和互動是跟本，過程和工具固然重要，卻是輔 注 文件有很多作用，比如變更的記錄和交流...
敏捷軟體開發宣言
1.個體和互動 勝過 過程和工具 首先，團隊合作，溝通和交流能力很重要，有時比程式設計能力還重要。其次，使用合適的工具對於正確完成工作也很重要，從小的免費的工具開始使用，滿足不了需求時再換其他工具。最後，應該先構建團隊，再讓團隊基於需要配置環境。2.可以工作的軟體 勝過 面面俱到的文件 因為 不是傳...