章四 檢查產品說明書
一、產品說明書的低層次測試技術
1、產品說明書屬性檢查清單
經過深思熟慮，可稱為「一字不漏」的優秀產品說明書應具有8個重要的屬性：
1）完整：是否有遺漏和丟失？完全嗎？單獨使用時是否包含所有內容？
2）準確：既定解決方案正確嗎？目標定義明確嗎？有沒有錯誤？
3）精確、不含糊、清晰：描述是否一清二楚？是否有單獨的解釋？容易看懂和理解嗎？
4）一致：產品功能是否自相矛盾，或與其它功能有無衝突？
5）貼切：描述功能的陳述是否必要？有沒有多餘資訊？功能是否符合原來的客戶要求？
6）合理：在規定的預算和進度下，以現有人力、工具和資源能否實現？
7）**無關：產品說明書是否堅持定義產品，而不是定義其軟體設計、架構和**？
8）可測試性：功能是否測試？給測試員提供的建立驗證操作的資訊是否足夠？
2、產品說明書術語檢查清單
在審查產品說明書時，還有乙個問題用語檢查清單。問題用語通常表明功能沒有仔細考慮——可能歸結於前文所述的某一屬性。
1）總是、每一種、所有、沒有、從不：看到此類絕對肯定或否定的描述，需要確認是這樣的。軟體測試員要考慮違反這些情況的用例。
2）當然、因此、明顯、顯然、必然：這些話意圖說服你接受假定情況，不要上當。
3）某些、有時、常常、通常、經常、大多、幾乎：這些話太過模糊，「有時」發生作用的功能無法測試。
4）等等、諸如此類、依此類推、例如：以這樣的詞結束的功能清單無法測試。功能清單要絕對或者解釋明確，以免讓人對功能清單內容產生迷惑。
5）良好、迅速、廉價、高效、小、穩定：這些是無法量化的術語，無法測試的。必須進一步準確定義其含義。
6）處理、進行、拒絕、跳過、排除：這些用語可能會隱藏大量需要說明的功能。
7）如果...那麼...：找出「如果...那麼...」而缺少配套的「否則」結構的陳述。想想沒有如果發生會怎樣。
章五 帶上眼罩測試軟體
一、動態黑盒測試：不深入**細節測試軟體的方法。常被稱為行為測試。
1、有效的動態測試需要關於軟體行為的一些定義——也即需求文件或者產品說明書。
清楚了被測試軟體的輸入和輸出之後，接下來要開始定義測試用例（test case）。測試用例是指進行測試時使用的特定輸入，以及測試軟體的過程步驟。
選擇測試用例是軟體測試員最重要的一項任務。不正確的選擇可能導致測試量國大或者過小，甚至測試目標不對。準確評估風險，把無窮盡的可能性減少到可以控制的範圍是成功的訣竅。
2、在沒有產品說明書時使用探索測試。
了解軟體、設計測試、執行測試同時執行。此時需要把軟體當作產品說明書來對待，系統地逐項了解軟體的功能、記錄軟體的執**況、詳述描述功能。
先用靜態黑盒技術，再用動態黑盒技術。
二、通過性測試和失效性測試
1、測試軟體有兩種基本方法：通過性測試（test-to-pass）和失效性測試（test-to-fail）。
在進行通過性測試時，是確認軟體至少能做什麼，而不會考驗其能力。
2、在設計和執行測試用例時，總是首先進行通過性測試。在破壞性測試之前看看軟體基本功能是否能實現是很重要的，軟體測試員可能會吃驚地發現僅僅正常使用軟體就會發現那麼多軟體缺陷。
3、確信軟體在普通情況下能正確執行之後，就可以採取各種手段搞垮軟體來找出軟體缺陷了。
純粹為了破壞軟體而設計和執行的測試用例稱為失效性測試或錯誤強制測試。
失效性測試通常不會突然出現，它是蓄意攻擊軟體的薄弱環節。
產品維護時編寫產品說明書
在專案開發過程中，經常會有不突然需要更改的需求，如何進行科學化的管理使這些更改，使這些改動的每乙個細節能在下一次閱讀時更簡單的被人了解。舉乙個例子，wms庫存 倉庫管理系統 分配邏輯，倉庫的出庫單分為兩種 日常出庫單和活動出庫單，由於活動發貨的貨品都在倉庫裡專門的活動區揀貨，所以活動單如 果庫存分配...
需求說明書四要素
需求說明書 是需求階段最關鍵的產出物，我們公司測試部的同事常常抱怨，有的專案的需求說明書看到末尾還是不清楚系統要做什麼，無法寫出測試用例。我想我們很多人，尤其是工作經驗不多的人，對需求說明書要寫些什麼東西也是糊里糊塗的，即使能夠從 rup的教材上搬出來一些名詞，也往往不理解其中的內涵。我把我的經驗寫...
產品需求說明書模版總結
此文也算是讀 人人都是產品經理 prd一節的讀書筆記。編寫prd的主要目的有以下幾點 1 梳理規定產品需求 2 為專案干係人了解產品需求提供可靠的途徑 3 作為產品設計 開發 測試 交維的需求依據 4 需求變更跟蹤管理的載體 prd模版包含下圖各個部分 這裡列出書中的uc模版 uc 用例名稱 用例i...