赤裸裸的現實數據表明哪怕項目的自動化系統做的再好，最終問題中的大多數還是得通過手工測試發現，對於更加敏捷的移動端測試，很有必要豐富測試方法與測試理論，而探索式測試就很適合敏捷式測試。
1． 缺陷預防和缺陷檢測
測試人員更多的都是在關注缺陷檢測上，主要任務也確實是缺陷檢測上。讀完此書的最大感想之一就是缺陷預防的重要性，儘管缺陷預防工作一般都是由開發人員完成。
儘量減少錯誤並提高軟件質量，主要有兩大類技術：缺陷預防和缺陷檢測
缺陷預防工作的重要性：
一份預防往往等價於十份治療！
軟件和人的身體健康是一樣的，當檢測出有毛病了，就已經晚了，此時要付出的代價往往大的多，而若能好好地做好預防工作，效率絕對會大大提高。而現實中並不是每個開發團隊都會很好地去做缺陷預防工作。
缺陷預防包括編寫更好的設計規範、實施代碼審覈制度、運行代碼靜態分析工具、運行單元測試（往往是自動化單元測試）。對於android應用開發團隊，可以以Jenkins+PMD+lint完成自動化靜態代碼分析，以推動代碼規範的實施，進一步地進行單元測試，不斷提高代碼質量！
軟件項目和足球挺像的，沒有哪個防守做得好的球隊是僅靠後衛的，而是需要整個團隊協同工作，丟球反搶、前場就得開始逼搶！
2． 程序員引入的缺陷和運行環境導致的缺陷
軟件缺陷的根源:程序員引入的缺陷和運行環境導致的缺陷
對於android應用的測試也是非常的明顯，常常在某個手機型號上一切正常，往生只有安裝到某一特定手機型號時問題才能重現，因此只保證檢測出程序員引入的缺陷還遠遠不夠，即需要做好足夠的兼容性測試。
數據：當數據量積累到一定程度，軟件出現故障了！除了系統本身的兼容性問題外，運行環境還包括測試時的數據與正式線上數據不一致導致發佈到線上才能檢測出一些特定問題，因此應該儘量在測試環境編造與線上儘可能一致的數據，且運行儘可能長的時間。
軟件狀態：雖然兩次輸入的數據完全相同，但測試結果可能完全不同，第一次我們測試的是軟件處於一個未被初始化的狀態時如何產生輸出，而第二次測試的則是當軟件處於一個已被初始化的狀態時如何產生輸出的。
新的環境：那些老代碼或者接受重新修改，或者是沒被改動就放到新環境中運行，很容易發生失效的情況。對於android應用，就意味着如果android新發布了個系統，應用能否繼續在這個系統上正常就需要重新測試衡量了，此時常常那些老代碼就無法正常運行了。應用中有做修改的代碼能否在舊的android系統上運行也需要重新測試衡量了。
3． 關於測試用例
對於測試用例的看法思維上算改變很大了，之前的想法是希望儘可能的把用例寫詳細，越詳細越好！但對於移動端的測試，對於迭代迅速、需求變更迅速的情況下真心有必要寫得很詳細嗎！在這種情況下許多用例很快就失效了，且維護麻煩、成本高。
探索式測試一書中有這麼個觀點：如果一個測試用例很可能馬上就失效，當初就根本沒有必要去維護編寫它。
探索式測試是測試腳本可以規定得很細，也可以只含有一些粗線條的描述，測試人員需要學習隨機應變的本領，掌握面對各種選擇時如何可以進行合理的判斷。即編寫用例時可以大致描述出步驟場景，對於具體的輸入則可以充分發揮探索式測試的優勢，以更發散更具有創造性的去思考怎樣的輸入或怎樣的操作更可以讓軟件失效。將有組織有目標的旅遊就和自由風格漫無目的的閒逛緊密地結合起來。
4． 關於測試人員的價值
閱讀本書一個很大的改變就是關於測試人員的價值觀念的轉變。
對於測試人員的評估，原文：真正的評估並不在于衡量找到軟件缺陷的數量，而在於改正這些缺陷後軟件質量得到改善的程序，評估測試人員時不要用軟件缺陷的數量、軟件缺陷的嚴重性、測試用例的多少、自動化測試的代碼量、迴歸測試套件的數目以及任何具體的指標來衡量可以通過觀察測試人員究竟提高了多少開發人員的工作績效，將此作爲評估測試人員績效的依據隨着開發人員素質的提高，最終同時達到軟件缺陷數量下降和生產效率提高的目的，這遠遠超過了只注重發現並清除軟件缺陷的簡單方式。
非常贊同這個觀點：授人以魚不如授人以漁，要想真正提高軟件質量，最根本的辦法就是提高開發人員的編碼水平，而編碼水平提高後對軟件質量產生的提高將是持久性的，反過來也說明了推動團隊完善代碼審覈制度、靜態代碼檢測、單元測試等缺陷預防工作的重要性，只有這樣才能不斷提高團隊的開發水平、提高代碼質量、提高軟件質量，達到良性循環！
當然了，文章所說的評估方法不按各種指標現實中估計很難~通過觀察提高了多少開發人員的工作績效也不靠譜，因爲這其中有太多因素變量。
測試人員應該常常想想使命或理想，軟件是有魔力的，但這偉大的魔力常常因爲缺陷而造嚴重的後果，爲了將來某一天軟件能完全正確工作而孜孜不倦地奮鬥着！
5.其他
a.大多數開發人員不喜歡編寫錯誤處理代碼，測試人員必須重視對這些地方的測試，儘量想辦法或者通過查看開發人員編寫的錯誤處理代碼，測試時想辦法使軟件運行錯誤處理代碼。
b.發佈出去的版本在用戶手裏還是會出現各種各樣的問題，因此需要儘可能多的模擬覆蓋真實用戶的使用場景。
c.缺陷常常是扎堆的，某一模塊出現缺陷時，應該更加仔細地測試這一模塊及其附近模塊，且一個好的缺陷往往隱藏着一個更大的缺陷，應該深入探索。
d.盡你最大的努力注意並記住軟件採取的動作次序，同時記住應用程序的響應，如果應用常常崩潰，那麼打開DDMS時時監控日誌吧。
e.保證當前的測試項目獲得成功的同時，應該學習你應該做些什麼以便下一個測試項目更加容易，持續進步。
6．探索式測試方法
商業區測試類型
指南測試法：要求測試人員通過閱讀用戶手冊並嚴格遵照手冊的建議執行操作
賣點測試法：找到那些最能賣錢的特性，應該觀摩那些銷售演示
地標測試法：選擇一個地標，到達目標後，再選擇另一個地標
極限測試法：向軟件提出很多難以回答的問題
快遞測試法：測試人員專注於數據，確認那些被存儲起來的輸入數據，並跟隨它們走遍軟件
深夜測試法：對於應用程序自動做的事情有時可以強制去讓他執行
遍歷測試法：選擇一個目標，使用可以發現的最短路徑來訪問目標包含的所有對象
歷史區測試類型
惡鄰測試法：缺陷通常扎堆，某個代碼區域缺陷多，可以對鄰近功能使用遍歷測試法進行測試
博物館測試法：
那些老代碼或者接受重新修改，或者是沒被改動就放到新環境中運行，很容易發生失效的情況
上一版測試法：必須運行先前版本上支持的所有場景和測試用例
娛樂區測試類型
配角測試法：越緊鄰那些主要功能，越容易被人注意，這些特性不能忽視
深巷測試法：應該測試該使用情況中排在最下面的幾項特性
通宵測試法：軟件能多長時間運行而不崩潰，將軟件一直處於開啓狀態
旅遊區測試類型
收藏家測試法：收集軟件的輸出，確保能觀察到軟件能生成的任何一個輸出
長路徑測試法：到達目的地前儘量多地在應用程序中穿行
超模測試法：只是測試界面，測試中注意觀察界面上的各種元素
測一送一測試法：同時打開同一文件或者讓它們同時在網絡上傳輸數據
芬格蘭酒吧測試法：有些功能很難找到，需要花大量的時間深入瞭解待測的應用程序
旅館區測試類型
取消測試法：可以對任何提供取消選項的功能或者需要較長時間才能完成的功能做同樣的操作
懶漢測試法：測試人員做盡量少的實際工全，接受所有默認值，保持表單爲空等
破舊區測試類型
破壞測試法：強迫軟件做一些操作，掌握軟件成功完成操作必須使用的資源，在不同程度上移除那些資源或限制用那些資源
反判測試法：要求輸入最不可能的數據，或者已知的惡意輸入
強迫症測試法：一遍又一遍地輸入同樣的數據
