【摘抄記錄】我們做測試不是要追求極致，但是至少要盡可能的降低因為遺漏問題而產生的風險，盡早的發現問題，解決問題。
或者說需求不明,我們應該怎麼做?
比如我的專案中只有低保真和高保真,沒有明確需求
高保真、低保真圖
頁面元素覆蓋哪些需求，是否冗餘
頁面元素型別，比如列表、文字框，按鈕等等
解析：即頁面的元素。一張好圖勝似千言萬語。這句話確實有其道理，所以介面原型圖不僅能幫助開發人員省去很多文字上的描述，也避免了在測試過程中針對頁面布局引起測試人員和開發人員爭議，更能讓測試人員建立乙個整體的概念。因此，測試人員可以「提醒」開發人員提供demo截圖，但是並不是每乙份uc生成時都有充足的資源來獲取demo。無論 uc中是否有demo提供，我們真正應該關注的包括兩點：一是頁面包括哪些元素，是否覆蓋了需求，有無冗餘。再就是各元素的型別，比如列表、文字框，按鈕等等。
確認許可權展現屬於哪種形式和其控制方式：
方式：
1）通過頁面元素的直接遮蔽使無許可權的使用者不可見
2）無操作許可權使用者使用時提示沒有許可權
3）沒有許可權的使用者操作內容顯示為不可用狀態（置灰）
解析：即使用者的訪問、操作許可權。一般而言，許可權的控制往往有三種展現方式：一是通過頁面元素的直接遮蔽使無許可權的使用者不可見，一是無操作許可權使用者使用時提示沒有許可權，還有就是對於沒有許可權的使用者操作內容顯示為不可用狀態。測試人員必須確認uc中有該部分的描述，並確認具體屬於哪種形式和其控制方式。否則在編寫tc過程中就會出現遺漏，從而會導致bug的遺漏。
確認所有可到達的路徑及其條件
解析：由於web自身的特點，乙個頁面的訪問往往會存在多個入口，每乙個入口的前置條件都有可能不同，因此測試人員必須確認所有可到達的路徑及其條件。
解析：例如結合demo圖(如果有的話)，確定哪些是輸入，哪些是輸出。而在考慮這些輸入和輸出的時候我們不光要知道頁面展現出來的輸入、輸出項，一些未展現出來的的輸入、輸出項，即隱藏的資料也是測試人員需要了解的。如註冊使用者，可能我們在頁面上只需輸入類似使用者名稱、id之類的輸入項，當成功後系統也只是提示操作成功，並返回註冊的使用者資訊頁面，而實際上，在註冊成功的同時，資料庫裡不僅僅只是新增了使用者所輸入的資訊，使用者id，使用者建立的時間等資訊都是系統自動生成但又不展現給使用者的，儘管使用者並不關心此類資料，但是測試人員必須了解並且跟蹤這些資料。確保資料的正確建立。因為當錯誤的資料被呼叫時，就會引發一系列未知的問題。所以測試人員必須關心資料。
外包專案一般沒有這些細節資料
輸入項有無輸入控制（淺色字型提示、字元限制、長度限制、錯誤提示）
初始頁面，如聯絡歷史為空
若為前者，就需要考慮輸出後是否影響輸出前的操作;
若為後者，還需考慮是否能從該頁面返回原視窗等等。
通過表關係，可進一步考慮本次需求可能會影響到的其它需求。並通過比對頁面元素，了解頁面展現和具體表結構的對應關係，從而確定是否有遺漏和冗餘。
注意檢視資料庫，不過這一般是測試過程中，操作結束後，檢視資料庫對應資料減少或增加數量是否正確，比如**活動中，獎品剩餘數量對應是否正確
如何應對不明需求做好測試
在日常需求的 測試過程中，因為時間和資源的相對緊張，往往會遇到prd不夠細緻，而uc描述也過於簡單的情況，這個時候會讓經驗不夠豐富的 測試人員有種無從入手的感覺。其實由於思考方式 對 需求的理解程度 開發和編寫uc的經驗 以及文字描述的習慣不同，開發人員首次提交的uc，並不一定能立即指導 測試人員 ...
如何在需求不明確的情況下保證測試質量
需求不明確在很多狀況 很多公司都會出現，而且需求經常會隨市場的需要而隨時更改。它通常發生在乙個專案的初期或者專案為某個成熟專案的子專案，相 關部門認為不需要定義明確的需求就可以更改立項的時候。無論那種情況，既然是產品，當產品進入測試部門進行測試的時候，我們總要有乙個標準來衡量軟體的質 量，每次測試的...
需求不明確情況下如何建立測試用例
基於目前國內很多企業的測試行業還剛剛起步，很多測試內容和流程管理還不規範，各種軟體的開發模式也良莠不齊，我想談談在這種情況下是如何建立測試用例庫的，也希望我能拋磚引玉，能夠一起討論。建立功能測試用例主要面臨的問題建立測試用例的依據是什麼？我認為在這種情況下可以參照的文件是1 需求說明書 2 使用者手...