我們在測試工作中都會遇到這種情況，就是不明需求，怎么才能做好測試呢：
1. 如果說功能測試更多的是站在用戶的角度進行測試，那么我們首先關注的必然是頁面的展現。即頁面的元素。一張好圖勝似千言萬語。這句話確實有其道理，所以界面原型圖不僅能幫助開發人員省去很多文字上的描述，也避免了在測試過程中針對頁面布局引起測試人員和開發人員爭議，更能讓測試人員建立一個整體的概念。因此，測試人員可以“提醒”開發人員提供demo截圖，但是并不是每一份UC生成時都有充足的資源來獲取demo。無論UC中是否有demo提供，我們真正應該關注的包括兩點：一是頁面包括哪些元素，是否覆蓋了需求，有無冗余。再就是各元素的類型，比如列表、文本框，按鈕等等。
2.在確定元素之后，就必須考慮元素對用戶的開放性。即用戶的訪問、操作權限。一般而言，權限的控制往往有三種展現方式：一是通過頁面元素的直接屏蔽使無權限的用戶不可見，一是無操作權限用戶使用時提示沒有權限，還有就是對于沒有權限的用戶操作內容顯示為不可用狀態。測試人員必須確認UC中有該部分的描述，并確認具體屬于哪種形式和其控制方式。否則在編寫TC過程中就會出現遺漏，從而會導致bug的遺漏。
3.明確入口。由于web自身的特點，一個頁面的訪問往往會存在多個入口，每一個入口的前置條件都有可能不同，因此測試人員必須確認所有可到達的路徑及其條件。
4. 在明確頁面布局及元素、權限控制、入口后，我們就應該進一步了解一些具體的操作細節。例如結合demo圖(如果有的話)，確定哪些是輸入，哪些是輸出。而在考慮這些輸入和輸出的時候我們不光要知道頁面展現出來的輸入、輸出項，一些未展現出來的的輸入、輸出項，即隱藏的數據也是測試人員需要了解的。如注冊用戶，可能我們在頁面上只需輸入類似用戶名、id之類的輸入項，當成功后系統也只是提示操作成功，并返回注冊的用戶信息頁面，而實際上，在注冊成功的同時，數據庫里不僅僅只是添加了用戶所輸入的信息，用戶ID，用戶創建的時間等信息都是系統自動生成但又不展現給用戶的，盡管用戶并不關心此類數據，但是測試人員必須了解并且跟蹤這些數據。確保數據的正確創建。因為當錯誤的數據被調用時，就會引發一系列未知的問題。所以測試人員必須關心數據。
5.對于輸入項，還應明確有無初始值、默認值設置。如果有，就應該考慮是不是需要與“重置”操作配合。此外，輸入項有無輸入控制，如果有，還應該確認對應的異常處理機制，包括提示信息的文案說明。
6.對于輸出項(返回項)，首先要明確具體有哪些輸出，其次需要明確是返回當前頁面的操作，還是新窗口。若為前者，就需要考慮輸出后是否影響輸出前的操作;若為后者，還需考慮是否能從該頁面返回原窗口等等。
7.除了關注頁面展現，測試人員還應該明確需求實現中涉及的所有表結構，包括表之間的關系。通過表關系，可進一步考慮本次需求可能會影響到的其它需求。并通過比對頁面元素，了解頁面展現和具體表結構的對應關系，從而確定是否有遺漏和冗余。
當然，以上這幾點可能還很不完整，僅僅是我在近期的日常需求測試過程中的一點感悟，還需要我在實踐的過程中去補充和修正，當然也歡迎大家一起來修正。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
