說說《探索性軟體測試》這本書吧，閱讀之後一些個人理解和思考，純文字，不感興趣可忽略。。。
第一章有這麼一句話：從設計來說，有些軟體的功能本身就存在功能邏輯上的錯誤或不友好，且產生的效果完全違揹我們的初衷。
做軟體測試工作，或許第一件要知道的事情就是：沒有完美的設計和產品。
也許這也是軟體測試這個行業產生以及發展至今的原因吧，即使軟體設計、開發、測試流程不斷在優化完善，但它依然存在缺陷！
軟體缺陷**於軟體開發本身，主要原因是軟體工程師沒有理解、預見或測試到所有可以執行的環境。
或者換一句話來說：程式永遠無法預防使用者的各種操作而帶來的損失。
軟體應用的四個基本功能：接收輸入、產生輸出、儲存資料、執行運算
那麼，如何盡可能把缺陷排除在交付使用者使用之前？主要有以下兩點：
1、缺陷預防
這一點主要從軟體開發人員角度來說：編寫更好地設計規範、實施**審核（code review）、**靜態分析、單元測試（unit testing）等等；
測試人員視角：如何攻破這個功能
二者相輔相成，缺一不可
說到這裡，想起一種軟體研發模式：測試驅動開發（tdd：test-driven-development）
②靜態**分析：不需要實際執行**程式，其主要包括分析程式源**（source code）、目標**（object code）、最終編譯生成的二進位制檔案或程式。
③資料：軟體需要io資料，才能覆蓋程式中各個**路徑、程式、功能；軟體測試是個動態的過程，在不同環境執行軟體，使用合理的測試資料，嘗試多次不同的輸入。
2、缺陷檢測
軟體測試工程師的工作，就是盡可能主動暴露、發現缺陷，並配合其他軟體工程師解決缺陷；而測試人員的測試形式，一般有兩種：利用工具進行自動化測試和手工測試。
①自動化測試
說起自動化測試，常見的型別有ui自動化、介面自動化以及單元自動化；業內對其的評價，也可以說各執己見，它的優點和缺點，都很明顯。
優點：編寫**指令碼執行測試用例，效率高，省卻了大量的時間和人力成本
缺點：**指令碼維護成本較大、前期人力時間需要投入的成本大、需要比較穩定的環境等等，還有，如何確定自動化測試真的完成了應該完成的任務？是否輸出了正確的結果？
②手工測試
這種型別的測試人員，可以說佔軟體測試從業人員的大多數，業內俗稱點工（點點點），說來有點嘲諷，很多人覺得點點點沒有技術含量，都是自嘲居多（雖然我也偶爾開玩笑
說自己專注點工多年^_^）。不過話說回來，點點點也有很多東西需要學習，如何分析需求、設計覆蓋率足夠高的用例，如何有效的執行用例發現缺陷、及時跟蹤、和開發人員
溝通、定位缺陷、協助解決缺陷，以及足夠大的腦洞，比較好的閱讀理解以及文件編寫能力，這些都很需要時間去鑽研練習以及實踐。
探索性軟體測試
本書主要內容就是探索性測試這個方法，或者說，一種思維邏輯方式、方**，更合適。
主要有兩塊內容，區域性探索性測試和全域性探索性測試。
探索性軟體測試核心：強調個人自由與責任的測試方法，讓測試人員藉由不斷學習來改善測試的規劃與執行，同時在測試過程中同時改善測試的案例來達到不斷互補優化。
大概總結了一下，其主要內容就是以下幾個點：
①何時何人採用何種方法測試什麼
②對需求的探索、了解、熟悉
③對工作流的不斷探索
④測試案例的重用性、簡潔有效性
④模組拆分、關注io上下游、
⑤方**、探索論、思考總結優化
探索性軟體測試的三個目標：
①理解應用程式的工作邏輯和原理，介面，以及實現了哪些功能
②盡量了解熟悉軟體的所有功能
③尋找缺陷
下面列舉一些書中總結出的探索性測試方法：
指南測試法：城市的題圖通常都會標註一些熱門的旅遊景點，測試這些熱門的區域是非常重要的。不管在任何一次發布的過程中，核心功能是肯定要覆蓋到的。指南測試要求測試人員嚴格
按照使用者手冊的建議執行操作，有可能是手冊描述不到位或者核心功能並不像宣傳的那樣好。
賣點測試法：此方法是鼓勵測試人員**銷售給客戶演示的demo，理解銷售的角度哪些功能對客戶來說是最大的賣點，他們未必就是核心功能，但值得測試人員把它們當核心功能來對待。
同時，也許刁鑽的客戶會提出各種質疑，這些質疑和稀奇古怪的問題也可以納入測試人員的設計中。
地標測試法：在旅遊的時候，如果我們設計了要到訪的地方，通常會在地圖上插上旗子，這就是地標。但是沒有人規定我們應該按照何種順序去到訪這些地標。不同的測試人員可能會選擇
不同的順序，有經驗的測試人員會基於對軟體產品架構和技術層面的理解，採取一些古怪的路徑但更可能發現缺陷。
極限測試法：向軟體提出難以回答的問題，比如最大可以發揮到什麼程度，承受多少使用者，承載多少資料。那個特性或功能會把軟體逼到極限運作，哪些輸入和資料會消耗軟體最多的計算
能力？哪些輸入可能繞過它的錯誤檢測？
快遞測試法：快遞運送的貨物，就好比軟體裡的資料，結果不同的地點轉接，拆包裝包最終到底目的地。所以快遞測試專注的是資料，跟隨它們走遍整個軟體。
深夜測試法：城市燈火闌珊會在午夜過後逐漸安靜下來，商場店鋪紛紛打烊。但是軟體不應該停止工作，軟體測試人員有時應該刻意的關注在冷門時間段軟體所做的附屬工作，比如資料備份
歸檔、維護監控任務的執行等等。
博物館測試法：這是針對軟體的遺留**，保留了些許年代的一些功能，找出它們來驗證是否有出現失效。當初開發它們的時候，甚至可能缺乏文件，但這並不意味著它們應該被忽略。
深巷測試法：在每個城市，都有些地方並不吸引遊客意味著不吸引人群，但作為測試人員來說，反而是這種最不可能被用到或者最不吸引使用者的特性，容易潛藏著難以發現的bug。
通宵測試法：繁華的都市總會有通宵熱鬧的地方，比如***ktv之類的，它們從不中斷。那麼應用程式是否也能堅持到最後呢？當它面臨持續不斷的呼叫、輸入、重讀重寫之類的操作，
如果執行時間足夠長，就很可能會出問題，記憶體會需要**、資料需要清空，永遠不要關閉它，保持不間斷的執行。（更多的時候會採用自動化或者機械人思想）
長路徑測試法：把那個在應用程式埋藏最深的介面當做測試目標（離起始點最遠的那個介面），觀察經過的每乙個介面
超模測試法：針對ui的表面測試，衡量軟體的展現能力，像t型台的超模那樣，不去關注她們幕後的辛酸痛苦勞累，跳出產品專家或測試的頭銜，以普通觀眾的角度，去關注那些能看到的
介面展現，元素是否被正確繪製、是否難看、顏色風格是否一致、介面的切換變化是否表意清晰？
取消測試法：此方法的思想是啟動了立即停止，特別是一些執行流程比較耗時的功能如備份還原或者搜尋，在啟動之後，立即取消。發散一點還可以變成，啟動乙個耗時操作，不停止立即
啟動另外乙個耗時操作，以此來檢測應用程式的自我清除能力。
懶漢測試法：選擇盡可能少的輸入，能不輸入盡量不輸入，能不修改盡量不修改，觀察應用程式是否能響應得出正確結果。
反叛測試法：你見過去酒吧不喝酒點果汁的麼？反叛思想要求輸入最不可能的資料，或者已知的而已輸入，測試人員可以採用逆向思維、明知一些資料違反規則，卻偏偏要採用這樣的資料，
或者不按照正確的順序來輸入。
強迫症測試法：測試人員強迫軟體一邊又一邊接受同樣的資料，反覆執行同樣的操作，最重要的特點就是重複。此種思維方式，常常打破了開發人員設計**的思路，他們預想著你會按步驟
操作，卻不曾考慮過你反覆的執行第一步應該如何處理。
最後，在本書的末尾篇章找到如下內容，算是寥有收穫。
軟體測試十戒律：
1.汝應用大量輸入反覆錘煉汝之應用程式
2.汝應貪圖汝之鄰居的應用程式
3.汝應親自尋找睿智的預言家
4.汝不應崇拜無法重現的失效
5.汝應尊重汝的模型和自動化測試
6.汝應利用開發人員的過錯與他們作對
7.汝應醉心於**應用程式（慶祝藍屏吧）
8.汝應保持安息日（指產品發布時刻）的聖潔
9.汝應貪圖開發人員的源**
探索性測試
每乙個好的缺陷背後，都可能藏著乙個更好的缺陷，在你確實了解缺陷的影響程度和破壞力之前永遠不要停止探索。探索性測試的目標 理解應用程式如何工作，他的介面看起來怎樣，實現了什麼功能 強迫軟體展示其全部能力 找到缺陷 探索性測試的方 賣點測試法 此方法鼓勵測試人員 銷售部門給客戶演示的demo，理解從銷售...
探索性測試
探索性測試概念 摘 探索性測試 et 是敏捷世界裡的一種重要測試方法，作為乙個研究性的工具，它是使用者故事測試和自動化回歸集的重要補充。它是一種經過深思熟慮的測試方式，沒有測試指令碼，可以使你的測試超出各種明顯已經測試過的場景。探索測試將學習，測試設計和測試執行整合在一起，形成一種測試方法。探索性測...
探索性測試
探索性測試的定義 探索性測試 et 是敏捷世界裡的一種重要測試方法，作為乙個研究性的工具，它是使用者故事測試和自動化回歸集的重要補充。它是一種經過深思熟慮的測 試方式，沒有測試指令碼，可以使你的測試超出各種明顯已經測試過的場景。探索測試將學習，測試設計和測試執行整合在一起，形成一種測試方法。探索性測...