我之前也梳理過很多測試方面的原則，可以概括為十大測試原則：
測試目標要明確，並建立合理的階段性目標
一切從客戶/使用者的角度出發，想客戶所想
測試盡早介入，一旦專案啟動，測試就要介入進去。
盡可能確保軟體的可測試性
持續地測試、持續地反饋，最大程度地降低研發成本，提高研發效率
測試時不能窮盡的，應設定合理的測試目標或測試終止的條件
基於專案的上下文來制定相應的測試策略
基於風險的測試策略總是有效的
測試計畫不僅是文件，更是乙個過程，應根據測試狀態不斷變化而進行調整
80/20原則，發現錯誤越多的地方，越要投入更多的測試資源或進行更深入的測試
所謂現代測試原則，是適應敏捷開發模式的 （人們往往把敏捷開發看成是現代開發模式） ，而不適合傳統開發模式的。從敏捷開發目標看，就是要做到快速交付、持續交付。作為測試，就是如何助開發一臂之力，實現高質量的持續交付。alan page和brent jensen（簡稱：ab）認為「 在敏捷開發中，測試人員可以開始從質量所有者轉變為可交付質量的大使，提供價值，並改善團隊的質量文化 」。這種提法值得商榷：
在傳統開發中，測試人員也不應該是質量的所有者 。質量一定是整個團隊和公司管理者共同擁有，而且測試人員也不是質量的管理者，因為有質量管理人員或質量保證人員（qa），甚至不是質量改進的最主要的驅動者 （團隊的每乙個都應該是質量的驅動者） ，因為還有工程過程組（sepg）。雖然上線後漏掉缺陷，有些公司第乙個責怪的人會是測試人員。即使在傳統的公司中，這樣做的公司也算是比較落後的公司，不能把落後的公司的實踐算在傳統測試的頭上。如果要問責，也是要把開發人員和測試人員一塊叫過來，看看問題究竟出在**。
大使，有全權代表的含義，也有形象代言人的含義， 這裡是指：敏捷 測試人員作為質量的代言人還是作為全權代表？ 感覺都不對，這樣是不是回到老路上去，而且把測試的責任搞含糊了。 測試人員就是不斷暴露軟體產品的質量風險，不斷發現問題，及時反饋給團隊，幫助團隊持續提公升質量 。
感覺ab的出發點就錯了。那我們再看看這七項現代測試原則有什麼新東西？是不是真正能成為敏捷測試的原則？
1.我們的首要任務是改善業務
ab認為 ：現代測試人員，熱衷於提高效率，並希望加快發布流程，更快地為客戶提供價值。強調為團隊增添價值，應用於功能團隊的良好測試思維是增值，而非成本，因為過去人們往往把測試看作是成本中心。這種價值可以通過資料來驅動，表示為客戶所熟悉的一些指標。
點評 ：不僅是測試，開發也一樣，都是為業務服務的，業務驅動開發、業務驅動測試，甚至我們說： 不以業務敏捷的敏捷都是偽敏捷 。從這一點看，這條原則沒錯。但是，這條原則適合傳統的開發，而不侷限於敏捷方法； 也適合整個敏捷團隊， 而 不侷限於測試人員。其次，ab的解釋，並沒有真正觸及到「業務為先的測試」、「業務驅動測試」的實質，即如何明確表達「業務驅動測試的準則」。
2.我們加速團隊，並使用精益思維和約束理論等模型來幫助識別、排序和緩解系統的瓶頸。
ab認為 ：測試人員做較少的測試，更多是驅動質量的提公升，指導開發人員設計小規模的測試（ 這來自google公司對測試的劃分：小規模、中等規模、大規模的測試，而不是我們通常說的單元測試、系統測試、驗收測試） ，讓開發人員做更多測試。測試人員負責那些大規模的測試。通過單項工作的結對體驗 （如結對程式設計、結對測試） ，團隊可以在**中找到更多缺陷，並更快地培育質量。
（不急，先了解兩個知識點）
補充知識點： 精益思想 （正好也是7項原則） 1) 尊重一線人員 。工作在一線的人最了解實際情況，能制定更好的應對措施，更有能力提出正確的改進意見； 2) 消除浪費 。任何不能為客戶增加價值的行為即是浪費，為了消除浪費，必須以價值流來識別浪費，並指出浪費的根源並消除它，識別和消除浪費的過程是持續不斷的； 3) 增強學習 。軟體開發是持續學習的過程，從而能夠面對各種挑戰； 4) 盡量延遲決定 。直到能夠基於事實而非不確定的假定和**來做出決定，因為系統越來越複雜，軟體開發中存在更多的不確定性； 5) 構建質量 。如果從研發的各個階段（需求、設計、程式設計等）都能保證產出物的質量，我們就能以最低的成本達到產品的質量目標，即最大程度地減少浪費； 6) 快速交付 。只有將產品交付給使用者，才產生價值。交付越快，產生價值越早； 7) 整體優化 。區域性的優化，若不能帶來整體的改善，將是沒有價值的。
補充知識點： 約束理論
約束即阻礙企業有效擴大產出能力、降低庫存和執行成本的環節，即任何乙個多階段生產系統，如果其中乙個階段的產出取決於前面乙個或幾個階段的產出， 那麼產出率最低的階段決定著整個系統的生產能力 。 約束理論是企業識別並消除在實現目標過程中存在的制約因素(即約束）的管理理念和原則 ，主要操作過程是：
1)找出系統中存在哪些約束（來自原料、能力、流程、市場等方面的約束）； 2)最大限度利用瓶頸，即提高瓶頸利用率； 3)使企業的所有其他活動服從第二步中提出的各種措施； 4)打破瓶頸，即設法解決第一步中找出的瓶頸；
5)重返第一步，持續改善。
3.測試人員是持續改進的力量，幫助團隊適應和優化以獲得成功，而不是提供安全網來捕捉失效。
ab認為 ：隨著逐步將更多**密集型測試任務轉移給開發人員，並讓測試人員指導和領導測試工作，團隊專案的質量得到提高。測試人員不再被視為最後一道質量防線，而成為「設法留住客戶、讓客戶使用應用程式」的第一道攻擊線。
點評 ：讓測試人員變被動為主動，幫助團隊持續改進，從而不斷提公升構建的質量，這挺好。從本質上講， 這種任務 是真正sqa人員或管理人員所承擔的責任，只是許多公司sqa人員是缺失的，管理人員也不夠關注質量，結果就讓測試人員來承擔了。但這種原則更應歸為質量文化建設、質量管理的原則，而不能算測試原則。就像前面說的，ab把測試人員當作質量大使，所以讓測試人員更關注 質量文化建設 的建設，從這個角度看，也沒錯。
4.非常關注團隊的質量文化，我們指導、領導和培養團隊，以建立更成熟的質量文化。
ab認為 ：建立代替孤立的測試人員的社群，這對於發展成熟的質量文化很重要。借助協作和創新，社群成員與其他成員建立共鳴，並能推進專案的成長和新想法。
點評 ：這也是質量文化，不是測試，但具體的實踐——「在企業內部建立社群」挺好。我之前演講或企業內訓中也提過， 當實實在在的測試部門不存在時，我們可以建立虛擬的測試部門——測試社群 。這在一些公司（如cisco）都有類似的實踐。
5.相信： 唯一能夠判斷和評估我們產品質量是客戶。
ab認為 ：現代測試實踐中，客戶的反饋是非常重要的。收集客戶反饋，直接或間接地從客戶那裡收集資料，使團隊能夠最好地判斷客戶是如何響應功能的。
6.廣泛使用資料來深入了解客戶使用情況，然後縮小產品假設和業務影響之間的差距。
點評 ：這是第1原則、第5原則的延伸，要客觀地獲得使用者的反饋，客戶使用產品的資料是關鍵的資訊**。如何基於這些資料，構建測試模型或幫助我們建立test oracle，需要具體的方法和工具來支援。
7.擴充套件整個團隊的測試能力和專業知識;了解這可能會減少（或消除）對專業測試專家的需求。
ab認為 ：「我是否需要辭掉工作並成為開發人員？」不，專注於自己的測試使命，如引領質量文化、尋找改進、投入到測試工具的使用並獲取知識以更好地幫助業務等。
點評 ：當測試人員指導開發人員做測試，可能會擔心革了自己的命，所以才有開頭那一問。 如果對測試有信心、對自己有 信心 ，就沒有這種擔心 ，否則做一些改變，「成為開發人員」也不失為明智的選擇。乙個工程師，能做開發工作也能做測試工作，自然在職場上更具競爭力，只是在「開發」和「測試」中，我們還是有自己更擅長的一面。
軟體測試原則
1.測試證明軟體存在缺陷 無論執行什麼樣的測試操作都能證明當前軟體是有缺陷的 2.不能執行窮盡測試 有些功能是沒有辦法將所有的測試情況都邏輯出來，所以任何的測試操作都有結束的時間 3.缺陷存在群集現象 對於軟體功能說，核心功能佔20 非核心80 在實際工作中我們會集中測試20 的核心功能，所以這個部...
軟體測試原則
軟體測試規範 zero bug和good enough 對於相對複雜的產品或系統來說，沒有bug是不可能的，我們只能想方設法把軟體的bug數控制在可以忍受的範圍內 good enough 原則就是一種權衡投入 產出的原則 不充分的測試時不負責任的，過分的測試是一種資源的浪費 不要窮舉測試 窮舉測試指...
軟體測試基礎 軟體測試的原則
所有的軟體測試都應該追溯到使用者需求。即應該重視需求文件，明確最初的需求才能盡可能減少後期的錯誤 盡早啟動測試工作，盡可能早地發現問題。問題越是遺留到後面修改的成本越大 pareto法則適用於軟體測試，又稱28效率法則，即早期應該能夠發現大量的問題 窮盡測試是不可能的，應當做適當的風險分析 殺蟲劑免...