1. 思想原則
懷疑一切：測試就是為了發現錯誤，交給你的產品就是有錯誤的產品。不管程序人員如何“信誓旦旦”，你的工作就是以發現BUG而“油然而生”自己的“成就感”。
寧可錯殺一千，不能放過一個：不能“遷就”自己的感覺，不要擔心自己的“無知”。理解錯了很正常，但放任過去可能會“後患無窮”。即便是“幫助”中的一個標點符號，也要推敲一下。
實事求是：不要誇大錯誤的性質，也不要對錯誤“輕描淡寫”。
2. 技術原則
一次和三次：BUG出現一次程序肯定有錯誤，不要相信“以後決不會出現”的許諾；讓BUG重複出現三次，才有可能摸清楚BUG出現的操作規律，記錄詳細的操作規律對程序員縮小查錯範圍十分重要。
路徑覆蓋：要按照軟件設計的數據流程，遍歷所有流程分支。不要想象程序中存在“等同狀態”或“與此類推”的情況。沒走到的地方肯定有BUG。
確定預期輸出結果：測試之前就應明確什麼是正確結果，甚至每一個操作事先都要知道正確的結果是什麼。
合法輸入與非法輸入相結合：程序員對合法輸入測試較多，他們最可能疏忽的就是“非法”輸入操作。用戶的使用方式“千奇百怪”，你不知道他們要如何操作，所以，你必須設計操作方式。
測試複核：找一個BUG十分不易，如果沒改正你就“白費勁”了。對於測試出的錯誤修改後必須要驗證，並且考慮到可能影響的範圍。
提供信息：測試應該為排錯提供必要的診斷信息，找出錯誤出現的規律十分必要。
儘早暴露缺陷：缺陷暴露得越早，越能降低開發和維護成本。例如，需求分析中的缺陷如果在需求評審時被暴露出來，只需要改幾個字就可以了；如果在設計評審時暴露出來，產品的框架結構可能需要調整；若待編碼完成後暴露出來，設計人員和程序員幾個月的辛苦可能付諸東流；如果到測試完成後，發現需求錯誤，開發過程可能要延期，造成巨大的人員和時間浪費。最不幸的是，如果到用戶現場實施階段暴露出來，用戶發現根本不是自己所要的產品，可能退貨或返工，那麼所有的投入都是無用功。軟件壽命週期中，暴露缺陷的階段與修改缺陷產生的開發成本之間的對應關係如下圖所示：
暴露缺陷的階段與開發成本的關係
現代測試理論認為，對軟件壽命週期全過程的工作產品（包括需求文檔、設計文檔等）的檢查和評審都是軟件測試的工作範圍。
閱讀更多 調音哥 的文章
