1.首先測試經過變更的部分，然後測試沒有變化的部分

2.首先測試核心功能，然後測試輔助功能，測試產品所完成的關鍵和常用功能，測試完成產品基本任務的功能

3.首先測試能力，然後測試可靠性

4.首先測試常見情況，然後測試少見情況

5.首先測試常見威脅，然後測試罕見威脅。最有可能出現的壓力和錯誤情況進行測試

6.首先測試影像大的問題，然後測試影像小的問題。測試在出現失效的情況下會產生大量破壞的產品部件

7.首先測試最重要的部分，然後測試沒有要求的部分。測試對團隊其他人有重要意義的任務部分的任何問題。

8.測試人員如果對產品，產品必須與之互動的軟體和硬體以及將使用軟體的人越瞭解，越有肯能更快地找出重要問題

9.測試結束的含義（完備測試可能的含義），完全發現了產品中每個問題；完全檢查了產品的每個部分；完成了自認為是有用和經濟的測試；儘自己所能，完全達到了專案團隊制定的目標；完成了約定的測試；完成了在一定條件下人所能夠測試的所有內容；完成了自己知道如何測試的所有內容；完成了自己所承擔的測試部分，不考慮其他人的工作；完成了對產品很廣，但不是很深的測試；完成了對產品的一種測試；用完了分配給測試的時間；

“完備”的定義並不是在專案一開始就能夠最終確定的，隨著測試專案的進展，隨著新測試任務的突然出現，需要重新考慮。

為了解決在完備性上的普遍溝通問題，可讓客戶詳細瞭解測試過程。總結自己實施的測試，以及為什麼值得實施這些測試，並告訴客戶自己沒有做的其他值得做的測試，以及為什麼沒有做這些測試。

10.質量來源與構建產品的人，有時這對他們來說是要揹負的沉重負擔。測試員使命中的很大一部分，就是幫助他們更有效地對付真正的負擔。如果測試員自認為是專案團隊中唯一關心交付好產品的人，就不能很好地完成這部分使命。

11.避免問題的關鍵就是不關注問題，而是關注自己的目標。（針對場外因素）

12.當測試員獲得控制產品釋出的權力之後，同時也承擔了產品質量的全部責任。大多數有效的專案團隊，都採用某種方式的集體決定是否釋出產品。如果測試員被授權決定產品的釋出，會毫不猶豫建議立即堅持與專案團隊的其他角色一起分擔這種權力

13.測試員的大腦是經過仔細調諧的推理機器，用精神力量做好事，而不是壞事

14.研究認識論，有助於測試。如何蒐集和評估證據；如何進行有效推論；如何使用不同邏輯形式；擁有合理的信念意味著什麼；形式和費形式推理之間的差別；非形式推理的常見謬誤；自然語言的含義與模糊性；如何做出好的決策；

將認識論運用於軟體測試，要問與以下類似的問題：怎麼知道軟體足夠好；如果軟體並不是足夠好，怎樣才能知道；怎樣知道完成了足夠的測試；

研究認識論可以幫助測試員設計有效的測試策略，更好地意識到自己工作中的錯誤，理解自己的測試能夠證明什麼、不能證明什麼，並編寫無懈可擊的測試報告

推薦書籍：《批判性思維的工具：心理學的元思想》《思考與決策》《研究的技巧》

15.認知性理學是測試的基礎

人的感覺和記憶可靠性；信念從哪裡來；信念如何影像人的行為；做出決策所使用的偏見和捷徑；如何瞭解並分享所知道的資訊；如何考慮複雜的事情；在壓力下如何思考；如何識別模式；如何把想法和事務分類；如何注意事務之間的差別；記憶事件中的失真；如何構建部分記憶的事件

《曠野中的認知》《理論與證據：科學推理的能力的開發》

16.帶著問題閱讀，帶著見解閱讀，帶著經驗閱讀。或者說要有問題才去閱讀，要有見解、理解才去閱讀，要有經驗才去閱讀。閱讀源於人生，生活

17.測試需要推斷，並不只是做輸出與預期結果的比較

流行的觀點認為，測試員只是執行測試用例，並對照預期結果比較執行結果。這種觀點把測試看做是簡單的比較活動，沒有看到一些聰明人必須設計測試，並確定預期輸出。測試設計人員幾乎重來沒有得到過應該測試什麼的權威知道，更不要說應該期望什麼了。可以得到的知道是要解釋的主題。在現實中，大多數測試設計都是基於推斷，或基於與測試員的推斷有關的經驗。不僅如此，這些推斷還要隨時間發生變化。像測試員那樣思考，就是要掌握探索式推斷的藝術。數學和科學推理過程是探索式的，而不是指令碼化的。

《證明與反駁：數學發現的邏輯》

18.不要將實驗與測試混淆起來

實驗的含義：可能表示測試員執行一段探索式測試，產生一些沒有文件或實驗產品的臨時性實驗。實驗的概念是自包含的、實在的，與其他方便實驗不同，但也是受限的。

測試：至少包括以下四種活動

配置：準備要測試的產品，將其置於正確的起始狀態

執行：輸入、輸出

觀察：對比

評估：評估

19.運用試探法快速產生測試思路

測試邊界；測試所有錯誤訊息；測試與程式設計師的配置不同的配置；執行比較難設定的測試；避免冗餘測試

20.測試員不能避免偏向，但是可以管理偏向

測試員是有偏向的，這使得測試員選擇一部分測試的可能性要比其他測試大。如果有一段很長的編輯欄位，測試員也許更可能輸入諸如111111111，而不是43235233，因為輸入字元重複的字串，要比從0到9的隨機數更容易。也許這是一種很小的偏向，但仍是一種偏向。更糟的偏向是，大多數的測試員傾向於測試最視覺化的功能，不管是不是重要的功能。此外，大多數測試員還傾向與考慮認為與自己類似的使用者，傾向於使用非常簡單、非常荒謬的輸入，而不是具有中等複雜度的現實輸入。

21.過於詳細沒有什麼好處。當編寫測試過程時，要避免與測試概念無關的細化。包括所有必要的資訊和設計與解釋測試所需的細節，但是要讓未來的測試員有創造性和判斷力的執行，讓未來測試員引入變化以使現在所編寫的測試過程新鮮、高效。

22.關注測試員、覆蓋率、潛在問題、活動和評估的組合測試手段

一種測試手段的分類系統，“五要素測試系統”，人們可以做的所有測試都可以在以下五個方面進行描述。

測試員：進行測試的人

覆蓋率：測試了哪些內容

潛在問題：測試的原因

活動：如何測試

評估：怎樣判斷通過還是不通過

23.功能測試、極值測試、基於需求的測試（覆蓋率：測試在這個需求文件中列出的所有內容；潛在問題：測試不滿足這個需求的各種方式；評估）、使用者測試

24.關注測試內容的基於覆蓋率的測試手段

功能測試、特性或功能整合測試、選單瀏覽、域測試、等價類分析、邊界測試、最佳代表測試、輸入欄位測試大綱或矩陣、用各種方法對映和測試編輯欄位、邏輯測試、基於狀態的測試、路徑測試、語句與分支覆蓋率、配置覆蓋率、基於規格說明的測試、基於需求的測試、組合測試

25.關注測試原因基於問題的測試手段

輸入約束、輸出約束、計算約束、儲存約束

26.關注測試方法的基於活動的測試手段

迴歸測試、指令碼測試、冒煙測試、探索式測試、遊擊式測試、場景測試、安裝測試、負載測試、長序列測試（可靠性測試、耐力測試）、效能測試

27.關注測試是否通過的基於評估的測試手段

自校驗資料、與已儲存的結果進行比較、與規格說明或其他權威文件比較、基於理念的測試

28.及時報告缺陷。不要等到第二天或下午才報告程式錯誤，不要等到忘記了一些關鍵細節才報告。拖延的時間越長，程式錯誤被解決的可能性就越小。

29.小缺陷也值得報告和修改。小錯誤會使客戶感到困惑，並降低客戶對產品的其他部分降低信心

30.時刻明確嚴重等級和優先順序之間的差距。嚴重等級表示程式錯誤影響或後果，優先順序表示什麼時候公司要求修改錯誤。

31.不可重視的錯誤會是公司能夠交付的最昂貴的缺陷。有事程式的表現沒有辦法重現。看到程式錯誤一次，但不知道如何使其再次出現。如果產品交付客戶後還出現這種情況，會影響客戶對產品的信心。在報告不可重現的程式錯誤時，要明確說明自己不能重現這個程式錯誤。

32.當報告小缺陷時，要特別注意使報告簡明，並經過充分分析。當要報告一個不可重現的程式錯誤，特別是在專案後期時，需要格外注意努力重現該程式錯誤。如果做了大量後續測試任然不能重現產生該程式錯誤，則說明這個程式錯誤是不可重現的，並描述操作的定位工作，以及所遇到的程式錯誤徵兆

33.注意自己的語氣，所批評的每一個人都會看到報告。錯誤報告帶有責備或居高臨下的語氣是沒有溢位的。稱程式設計師不夠專業、思想保守或愚蠢都是得不償失的。

34.使自己的報告具有可讀性，即使物件是疲勞和暴躁的人。要使重現步驟的描述簡潔

一次只走查該程式錯誤一步

為每一步編號

不要跳過重現問題所需的任何步驟

列出使讀者能夠重現失效的最少步驟集

通過空行使報告更容易瀏覽

使用簡短句子

說明實際發生了什麼，自己預期會發生什麼

如果後果很嚴重，但是測試員有理由懷疑程式設計師不理解為什麼很嚴重，可解釋為什麼自己認為很嚴重

要始終保持中立語氣

35.測試惰性不能成為程式錯誤修改推遲的原因。

如果測試經理要求程式設計師不要修改程式錯誤，只因為修改會影響太多的檢查單、指令碼或其他測試工作制品，因此要佔用太多的管理時間，那麼說明測試過程存在致命缺陷

36.自動化測試目標：迅速檢查出新版本中的不穩定更新；儘可能迅速暴露迴歸程式錯誤；儘快報告問題，因為這會使程式錯誤修改更容易

37.拓展測試領域，不要不斷重複相同的測試，離開自動化測試就不能完成某些測試，而另外一些自動化測試則會大大擴充套件測試範圍。

負載測試

效能基準測試

配置測試

耐力測試

競爭條件

組合錯誤

38.為了有效地應用解決方案，需要清楚地理解問題

39.使用IEEE標準829作為測試文件

1.首先測試邏輯較複雜的部分，然後測試邏輯較簡單的部分。邏輯較複雜的部分在用例階段使用測試思想盡量將可能性考慮全面