在日常需求的
測試過程中，因為時間和資源的相對緊張，往往會遇到prd不夠細緻，而uc描述也過於簡單的情況，這個時候會讓經驗不夠豐富的
測試人員有種無從入手的感覺。其實由於思考方式、對
需求的理解程度、
開發和編寫uc的經驗、以及文字描述的習慣不同，
開發人員首次提交的uc，並不一定能立即指導
測試人員
編寫出一系列相對健壯的tc。
雖然說測試人員有權利退回需求不明的測試任務，但是在遇到「不得已而為之」的時候(比如緊急需求)，想辦法解決問題，給出需求方建議總是好過什麼都不做的退出測試。
因此需要在tc編寫之前進行uc的評審，而uc的評審過程並不僅僅是乙個需求再確認的過程，在評審之前測試人員就應該帶著思考(類似於checklist)去盡可能的挖掘uc所覆蓋到prd的點以及所有自己的疑問，並且通過溝通盡早的解決疑問。
在這裡，我個人想強調一下疑問，因為自己沒有疑問並不代表真的沒有問題，反而沒有疑問才是最大的問題。誰都知道沒有什麼事物是絕對完美，包括開發人員編寫的 uc，測試人員編寫的tc，我們做測試不是要追求極致，但是至少要盡可能的降低因為遺漏問題而產生的風險，盡早的發現問題，解決問題。然而沒有仔細的推敲和思考很難發現隱藏的問題，所以說沒有疑問從某種程度上講，是我們思考的還不夠。舉乙個最為簡單也是最為普遍的例子，我們一定都有過在編寫tc過程中才發現有不確定的內容並向開發人員進行確認的經歷，從某種角度講，這就說明了uc的評審過程中，我們有遺漏。所以，只有充分的思考，才有可能捕獲疑問，才有可能解決疑問，才有可能降低遺漏。
說完了疑問，在這裡就不得不說一說思考，到底在uc評審之前我們應該思考些什麼，或者說到底有哪些內容是我們需要去把握的，個人覺得可以從以下幾點著手：
1.如果說功能測試
2.在確定元素之後，就必須考慮元素對使用者的開放性。即使用者的訪問、操作許可權。一般而言，許可權的控制往往有三種展現方式：一是通過頁面元素的直接遮蔽使無許可權的使用者不可見，一是無操作許可權使用者使用時提示沒有許可權，還有就是對於沒有許可權的使用者操作內容顯示為不可用狀態。測試人員必須確認uc中有該部分的描述，並確認具體屬於哪種形式和其控制方式。否則在編寫tc過程中就會出現遺漏，從而會導致bug
的遺漏。
3.明確入口。由於web
自身的特點，乙個頁面的訪問往往會存在多個入口，每乙個入口的前置條件都有可能不同，因此測試人員必須確認所有可到達的路徑及其條件。
4.在明確頁面布局及元素、許可權控制、入口後，我們就應該進一步了解一些具體的操作細節。例如結合demo圖(如果有的話)，確定哪些是輸入，哪些是輸出。而在考慮這些輸入和輸出的時候我們不光要知道頁面展現出來的輸入、輸出項，一些未展現出來的的輸入、輸出項，即隱藏的資料也是測試人員需要了解的。如註冊使用者，可能我們在頁面上只需輸入類似使用者名稱、id之類的輸入項，當成功後系統也只是提示操作成功，並返回註冊的使用者資訊頁面，而實際上，在註冊成功的同時，資料庫
裡不僅僅只是新增了使用者所輸入的資訊，使用者id，使用者建立的時間等資訊都是系統自動生成但又不展現給使用者的，儘管使用者並不關心此類資料，但是測試人員必須了解並且跟蹤這些資料。確保資料的正確建立。因為當錯誤的資料被呼叫時，就會引發一系列未知的問題。所以測試人員必須關心資料。
5.對於輸入項，還應明確有無初始值、預設值設定。如果有，就應該考慮是不是需要與「重置」操作配合。此外，輸入項有無輸入控制，如果有，還應該確認對應的異常處理機制，包括提示資訊的文案說明。
6.對於輸出項(返回項)，首先要明確具體有哪些輸出，其次需要明確是返回當前頁面的操作，還是新視窗。若為前者，就需要考慮輸出後是否影響輸出前的操作;若為後者，還需考慮是否能從該頁面返回原視窗等等。
7.除了關注頁面展現，測試人員還應該明確需求實現中涉及的所有表結構，包括表之間的關係。通過表關係，可進一步考慮本次需求可能會影響到的其它需求。並通過比對頁面元素，了解頁面展現和具體表結構的對應關係，從而確定是否有遺漏和冗餘。
其實，個人認為帶著思考去評審uc或者是編寫tc，絕對不止是確認需求和描述自己的操作步驟，通過在跟開發人員的溝通過程中，引導他們一起去思考和去檢驗自己的**，其實也是在測試，這樣的行為可以說大大的提高了測試的效率，因為很多問題在測試人員開始執行測試之前都已被開發人員所修正，如此一來，在執行測試的時間裡，測試人員就可以更好地聚焦於業務邏輯層的實現，使得測試更為充分。從某種角度講這也是缺陷
的預防。當然，缺陷
預防的路還有很長，但是我們不用害怕和沮喪，一點點做起來，一步乙個腳印的走下去，目標總會近，如果我們每個人再加把勁，多多分享和共享，那麼我相信，我們的團隊會走的更快、更好。
需求不明的測試
摘抄記錄 我們做測試不是要追求極致，但是至少要盡可能的降低因為遺漏問題而產生的風險，盡早的發現問題，解決問題。或者說需求不明,我們應該怎麼做?比如我的專案中只有低保真和高保真,沒有明確需求 高保真 低保真圖 頁面元素覆蓋哪些需求，是否冗餘 頁面元素型別，比如列表 文字框，按鈕等等 解析 即頁面的元素...
如何應對沒有需求的測試
軟體測試 時候發現根本沒有需求，一問開發和需求，發現原來是我們的專案經理口口相傳，告訴開發要怎麼怎麼做。可想而之，這個過程是沒有設計的，開發過程當中遇到問題，就會問，專案經理即時馬上給出答覆。而到了測試，測試人員在完全不了解狀況的時候，在介面上點了點，也不知道要點多少東西，反正一會告訴我說版本測試完...
如何做好需求收集
專案前期需求收集過程的效果好壞，會對軟體產品的最終質量產生直接的影響。如何收集好需求，本文作者給出了一條行之有效的實際操作途徑。什麼是需求收集？需求收集，是確定和理解不同類別使用者的需要和限制的過程，是需要高度協作的活動，是在問題及其最終解決方案之間架設橋梁的第一步，因此其重要性不言而喻。據調查顯示...