在日常需求的測試過程中，因為時間和資源的相對緊張，往往會遇到PRD不夠細致，而UC描述也過于簡單的情況，這個時候會讓經(jīng)驗不夠豐富的測試人員有種無從入手的感覺。其實由于思考方式、對需求的理解程度、開發(fā)和編寫UC的經(jīng)驗、以及文字描述的習慣不同，開發(fā)人員首次提交的UC，并不一定能立即指導測試人員編寫出一系列相對健壯的TC。

　　雖然說測試人員有權(quán)利退回需求不明的測試任務(wù)，但是在遇到“不得已而為之”的時候(比如緊急需求)，想辦法解決問題，給出需求方建議總是好過什么都不做的退出測試。

　　因此需要在TC編寫之前進行UC的評審，而UC的評審過程并不僅僅是一個需求再確認的過程，在評審之前測試人員就應(yīng)該帶著思考(類似于checklist)去盡可能的挖掘UC所覆蓋到PRD的點以及所有自己的疑問，并且通過溝通盡早的解決疑問。

　　在這里，我個人想強調(diào)一下疑問，因為自己沒有疑問并不代表真的沒有問題，反而沒有疑問才是最大的問題。誰都知道沒有什么事物是絕對完美，包括開發(fā)人員編寫的 UC，測試人員編寫的TC，我們做測試不是要追求極致，但是至少要盡可能的降低因為遺漏問題而產(chǎn)生的風險，盡早的發(fā)現(xiàn)問題，解決問題。然而沒有仔細的推敲和思考很難發(fā)現(xiàn)隱藏的問題，所以說沒有疑問從某種程度上講，是我們思考的還不夠。舉一個最為簡單也是最為普遍的例子，我們一定都有過在編寫TC過程中才發(fā)現(xiàn)有不確定的內(nèi)容并向開發(fā)人員進行確認的經(jīng)歷，從某種角度講，這就說明了UC的評審過程中，我們有遺漏。所以，只有充分的思考，才有可能捕獲疑問，才有可能解決疑問，才有可能降低遺漏。

　　說完了疑問，在這里就不得不說一說思考，到底在UC評審之前我們應(yīng)該思考些什么，或者說到底有哪些內(nèi)容是我們需要去把握的，個人覺得可以從以下幾點著手：

　　1.如果說功能測試更多的是站在用戶的角度進行測試，那么我們首先關(guān)注的必然是頁面的展現(xiàn)。即頁面的元素。一張好圖勝似千言萬語。這句話確實有其道理，所以界面原型圖不僅能幫助開發(fā)人員省去很多文字上的描述，也避免了在測試過程中針對頁面布局引起測試人員和開發(fā)人員爭議，更能讓測試人員建立一個整體的概念。因此，測試人員可以“提醒”開發(fā)人員提供demo截圖，但是并不是每一份UC生成時都有充足的資源來獲取demo。無論 UC中是否有demo提供，我們真正應(yīng)該關(guān)注的包括兩點：一是頁面包括哪些元素，是否覆蓋了需求，有無冗余。再就是各元素的類型，比如列表、文本框，按鈕等等。

　　2.在確定元素之后，就必須考慮元素對用戶的開放性。即用戶的訪問、操作權(quán)限。一般而言，權(quán)限的控制往往有三種展現(xiàn)方式：一是通過頁面元素的直接屏蔽使無權(quán)限的用戶不可見，一是無操作權(quán)限用戶使用時提示沒有權(quán)限，還有就是對于沒有權(quán)限的用戶操作內(nèi)容顯示為不可用狀態(tài)。測試人員必須確認UC中有該部分的描述，并確認具體屬于哪種形式和其控制方式。否則在編寫TC過程中就會出現(xiàn)遺漏，從而會導致bug的遺漏。

    3.明確入口。由于web自身的特點，一個頁面的訪問往往會存在多個入口，每一個入口的前置條件都有可能不同，因此測試人員必須確認所有可到達的路徑及其條件。

　　4.在明確頁面布局及元素、權(quán)限控制、入口后，我們就應(yīng)該進一步了解一些具體的操作細節(jié)。例如結(jié)合demo圖(如果有的話)，確定哪些是輸入，哪些是輸出。而在考慮這些輸入和輸出的時候我們不光要知道頁面展現(xiàn)出來的輸入、輸出項，一些未展現(xiàn)出來的的輸入、輸出項，即隱藏的數(shù)據(jù)也是測試人員需要了解的。如注冊用戶，可能我們在頁面上只需輸入類似用戶名、id之類的輸入項，當成功后系統(tǒng)也只是提示操作成功，并返回注冊的用戶信息頁面，而實際上，在注冊成功的同時，數(shù)據(jù)庫里不僅僅只是添加了用戶所輸入的信息，用戶ID，用戶創(chuàng)建的時間等信息都是系統(tǒng)自動生成但又不展現(xiàn)給用戶的，盡管用戶并不關(guān)心此類數(shù)據(jù)，但是測試人員必須了解并且跟蹤這些數(shù)據(jù)。確保數(shù)據(jù)的正確創(chuàng)建。因為當錯誤的數(shù)據(jù)被調(diào)用時，就會引發(fā)一系列未知的問題。所以測試人員必須關(guān)心數(shù)據(jù)。

　　5.對于輸入項，還應(yīng)明確有無初始值、默認值設(shè)置。如果有，就應(yīng)該考慮是不是需要與“重置”操作配合。此外，輸入項有無輸入控制，如果有，還應(yīng)該確認對應(yīng)的異常處理機制，包括提示信息的文案說明。

    6.對于輸出項(返回項)，首先要明確具體有哪些輸出，其次需要明確是返回當前頁面的操作，還是新窗口。若為前者，就需要考慮輸出后是否影響輸出前的操作;若為后者，還需考慮是否能從該頁面返回原窗口等等。

　　7.除了關(guān)注頁面展現(xiàn)，測試人員還應(yīng)該明確需求實現(xiàn)中涉及的所有表結(jié)構(gòu)，包括表之間的關(guān)系。通過表關(guān)系，可進一步考慮本次需求可能會影響到的其它需求。并通過比對頁面元素，了解頁面展現(xiàn)和具體表結(jié)構(gòu)的對應(yīng)關(guān)系，從而確定是否有遺漏和冗余。

　　當然，以上這幾點可能還很不完整，僅僅是近期的日常需求測試過程中的一點感悟。

　　其實，帶著思考去評審UC或者是編寫tc，絕對不止是確認需求和描述自己的操作步驟，通過在跟開發(fā)人員的溝通過程中，引導他們一起去思考和去檢驗自己的代碼，其實也是在測試，這樣的行為可以說大大的提高了測試的效率，因為很多問題在測試人員開始執(zhí)行測試之前都已被開發(fā)人員所修正，如此一來，在執(zhí)行測試的時間里，測試人員就可以更好地聚焦于業(yè)務(wù)邏輯層的實現(xiàn)，使得測試更為充分。從某種角度講這也是缺陷的預防。當然，缺陷預防的路還有很長，但是我們不用害怕和沮喪，一點點做起來，一步一個腳印的走下去，目標總會近，如果我們每個人再加把勁，多多分享和共享，那么我相信，我們的團隊會走的更快、更好。