1. 「測試名稱應該從使用者的角度來描述是什麼以及為什麼」；核心思想是一名開發者應該能夠從測試名稱理解測試行為是什麼樣的。
2. 「測試也是**，愛他們吧」；僅在產品**中做重構是不夠的。易於理解的測試更易於維護，而且後來的人也更容易弄清楚。 「我憎恨、憎恨長而複雜的測試。如果乙個測試的setup方法有30行，請將這些**放在乙個creation方法中。乙個長測試會激怒開發者並讓其頭昏眼花。如果在產品**中沒有長方法，為什麼會允許在我們的測試**中有長方法？」
3. 「不要設定單一fixture的模式/組織風格」；通常情況下是乙個類對應乙個testfixture，但有時候這樣的標準並不適用。
4.「測試外部行為而不是內部結構。」 或者，測試乙個類的期望行為而不是它的目前結構。
5. 盡可能做到每個測試乙個斷言。
6. 如果在乙個測試中有任何「if else」語句，將語句分支移到單獨的測試方法中。
7. 如果被測試的方法有if else分支，該方法應該被重構。
8. 測試方法名稱應該表明是某種測試。例如，testmakereservation與testmakenoreservation()是不同的。
9.每測試一斷言的說法為乙個「邏輯斷言」，「有時，由於被測試的api缺乏表達能力，你需要寫多個斷言語句來獲得期望的結果。很多工作就是試圖讓乙個斷言做更多的工作。」
10. 實作：fixture命名保持一致
11. 實作：模擬目標**的命名空間
12. 實作：setup/teardown方法命名保持一致
13. 考慮：分離測試與產品**
14. 實作：按功能給測試命名
15. 考慮：在期望異常的命名中使用「cannot」作為字首
效能測試標準及準則
效能測試目的 效能測試目標 1 系統新上線 測試明確的數字標準對比情況下，驗證系統是否可以上線。測試系統的極限，如 系統某些資源已經耗盡，cpu 控制代碼 記憶體 資料庫出現大量的slow query 或者系統有些處理已經變數 或者證明系統能否根據硬體水平擴充套件的。2 沒有可以比較的測試結果，但是...
如何建立有效的軟體測試準則？
典型的既無意義，也不能實現目標的兩個測試結束準則 1用完了安排的測試時間後，測試便結束。2當執行完所有測試用例都未發現錯誤，測試便結束。也就是說，當所有的測試用例不成功時便結束。第一條準則沒有任何作用，因為可以什麼都不做就能滿足它。它並不能衡量測試的質量。第二條準則同樣無用。因為它與測試用例的質量無...
如何把測試做的更好 測試幾宗罪
進到乙個新專案，作為測試人員應該都是想把測試做好，專案在符合客戶質量要求的情況下按時交付的吧。但往往都事與願違，造成這個結果的原因有很多很多。通過這段時間做自動化測試，站在自動化測試的角度看手工測試，以及排除其他部門的問題，單說測試自身的問題來和大家分析討論一下怎樣我能做到更好。先說一下背景，我是中...