怎樣詮釋測試
--
記開展測試的記憶式方法
james bach
《how do you spell testing》
roger
翻譯於5/24//2010
在探索性測試中，我們設計和執行測試是實時的。那麼我們應該怎樣組織我們的思維以使我們能思考出有價值的測試？有一種方式就是通過使用啟發式方法（
heuristic
）和記憶式方法（
mnemonics
）進行。啟發式方法是一種「依據
經驗法則，簡單化或有依據的猜測
」。舉個例子，在房間門口的地毯下找出鑰匙就是一種啟發式方法。相比之下，記憶式方法是用一種「用詞語，押韻，或其它的記憶方法來將複雜而又冗長的資訊進行有效記憶的方式」。同時採用啟發式方法和記憶式方法，對我們在壓力下解決問題有非常大的幫助。
sfdpo詮釋測試
在測試中我運用的啟發式方法和記憶式方法可稱為「
san francisco depot
」，或者稱為
sfdpo
。這些字母代表著
structure, function, data, platform
和operations
。每個詞代表著軟體產品乙個不同的方面。對於產品，思考以上提及的每個方面，會使我想起很多非常有趣的測試方法。所以當我被要求去測試一些我從沒有見過的東西時，我會對自己說「
san francisco depot
」，回憶以上五個產品元素的每乙個，然後開始思考我該測試些什麼。 ·
structure
（它是什麼）：它有哪些檔案組成？我了解它的構造資訊嗎？它是乙個程式還是多個？它有哪些配套的材料？我能按模組劃分來測試嗎？ ·
function
（它能做什麼）：它的功能是什麼？它有哪些錯誤處理呢？它有怎樣的介面呢？它會做哪些使用者不可見的事情？它與作業系統是怎樣互動的？ ·
data
（資料是如何處理的）：有哪些怎樣的輸入？輸出又是什麼樣的？它能處於什麼樣的模式或狀態？它是否會預先裝載資料？輸入是否對時間和順序上一定的要求呢？ ·
platform
（它依附於什麼）：它執行於什麼樣的作業系統之上？環境需要以某些特別的方式進行配置嗎？它依附於第三方元件嗎？ ·
operations
（它是怎樣被使用的）：誰將使用它？它會在**被使用，怎麼使用？它被用於做什麼？使用者有哪些特定的使用方式呢？我們能獲取一些使用者資料來幫助我們測試顯得更真實些？
思想之光
通過使用如
sfdpo
這樣的小技巧，我能非常快速的得到一些關於產品的想法。但是我不只喜歡速度，可靠性也是。在我發現
sfdpo
之前，我能想到很多測試的點子，但是我覺得這些點子是隨機和散亂的。我沒有方法來評估我分析的完整性。如今我掌握了啟發式方法和記憶式方法，雖然我知道我仍然會忘記掉測試某些東西，但是至少我已經很系統地測過產品的主要方面。從測試方法到質量標準，我已經在每一件事情上使用啟發式方法。
因為你知道的一些事情，並不會在它被需要的時候能被你想起，所以
sfdpo
不乙個模板或測試計畫，它僅僅是一種方法，在你測試的時候能使你產生很多重要的想法。它是你有用的工具包中的一部分。如果你想成為一名出色的、可靠的探索性測試人員，最關鍵的事情是開始收集和創造能對你有用的啟發式方法庫。同時，請記住，沒有任何啟發式智慧型。智慧型其實在你心中，啟發式方法僅僅是喚起你心中的那些想法，如同一些排序好的認知鬧鐘，它並不能告訴你準確的行動步驟在何時何處。這就是技能和經驗所在。
好的測試是一門微妙的藝術，對此你應該掌握一些有效的工具。
後記（譯者）：
一直以來，對探索性測試到底該怎麼進行都心存迷惑。也看到過很多人感慨，對於乙個陌生的軟體，怎樣能快速的發現
bug這樣乙個問題感到沒有思路，或許此文能提供些借鑑和參考。
軟體測試宣言的詮釋
宣言發布後，得到不少的肯定。最給力的，要屬 培根芝士牛蛙堡 感覺總結的太到位，can t agree more 了，最近在看 軟測之魂 很多觀點都是異曲同工啊，雖說就簡單四句話，但是每一句話展開去都能寫一本書 還有 讓測試飛起來 又見右下八卦圖亮點。每當遇到左 右難以分辯時就想到它，並以此為基點，償...
基於QA工作開展的測試計畫
上篇說到，測試計畫要根據客戶的需求，以及專案經理對專案整體的認識進行制定。今天在這裡新增一些東西，請大家幫忙指正，謝謝！這裡首先要說到的是客戶關注的是什麼。對於測試來說，客戶關心的是，測試或者說qa人員如何把軟體的質量控制好，測試人員在整個軟體開發的各個環節當中，會做什麼以及怎麼做。掌握好了每個環節...
需求階段測試工作的開展
首先，測試用例和測試工作本身是不斷完善的，在開發過程的初期，可以認為是需求階段，或者沒有規範需求工作的設計階段。如果有乙個比較明確的需求文件，可以在這個階段檢查完了需求文件以後開始設計測試用例。這裡，對於需求文件的檢查主要是兩個方面 1.檢查需求文件描述的正確性，愚以為測試人員要對於真實的系統所涉及...