在日常需求的測試過程中，因?yàn)闀r(shí)間和資源的相對緊張，往往會(huì)遇到PRD不夠細(xì)致，而UC描述也過于簡單的情況，這個(gè)時(shí)候會(huì)讓經(jīng)驗(yàn)不夠豐富的測試人員有種無從入手的感覺。其實(shí)由于思考方式、對需求的理解程度、開發(fā)和編寫UC的經(jīng)驗(yàn)、以及文字描述的習(xí)慣不同，開發(fā)人員首次提交的UC，并不一定能立即指導(dǎo)測試人員編寫出一系列相對健壯的TC。
雖然說測試人員有權(quán)利退回需求不明的測試任務(wù)，但是在遇到“不得已而為之”的時(shí)候(比如緊急需求)，想辦法解決問題，給出需求方建議總是好過什么都不做的退出測試。
因此需要在TC編寫之前進(jìn)行UC的評審，而UC的評審過程并不僅僅是一個(gè)需求再確認(rèn)的過程，在評審之前測試人員就應(yīng)該帶著思考(類似于checklist)去盡可能的挖掘UC所覆蓋到PRD的點(diǎn)以及所有自己的疑問，并且通過溝通盡早的解決疑問。
在這里，我個(gè)人想強(qiáng)調(diào)一下疑問，因?yàn)樽约簺]有疑問并不代表真的沒有問題，反而沒有疑問才是最大的問題。誰都知道沒有什么事物是絕對完美，包括開發(fā)人員編寫的 UC，測試人員編寫的TC，我們做測試不是要追求極致，但是至少要盡可能的降低因?yàn)檫z漏問題而產(chǎn)生的風(fēng)險(xiǎn)，盡早的發(fā)現(xiàn)問題，解決問題。然而沒有仔細(xì)的推敲和思考很難發(fā)現(xiàn)隱藏的問題，所以說沒有疑問從某種程度上講，是我們思考的還不夠。舉一個(gè)最為簡單也是最為普遍的例子，我們一定都有過在編寫TC過程中才發(fā)現(xiàn)有不確定的內(nèi)容并向開發(fā)人員進(jìn)行確認(rèn)的經(jīng)歷，從某種角度講，這就說明了UC的評審過程中，我們有遺漏。所以，只有充分的思考，才有可能捕獲疑問，才有可能解決疑問，才有可能降低遺漏。
說完了疑問，在這里就不得不說一說思考，到底在UC評審之前我們應(yīng)該思考些什么，或者說到底有哪些內(nèi)容是我們需要去把握的，個(gè)人覺得可以從以下幾點(diǎn)著手：
1. 如果說功能測試更多的是站在用戶的角度進(jìn)行測試，那么我們首先關(guān)注的必然是頁面的展現(xiàn)。即頁面的元素。一張好圖勝似千言萬語。這句話確實(shí)有其道理，所以界面原型圖不僅能幫助開發(fā)人員省去很多文字上的描述，也避免了在測試過程中針對頁面布局引起測試人員和開發(fā)人員爭議，更能讓測試人員建立一個(gè)整體的概念。因此，測試人員可以“提醒”開發(fā)人員提供demo截圖，但是并不是每一份UC生成時(shí)都有充足的資源來獲取demo。無論UC中是否有demo提供，我們真正應(yīng)該關(guān)注的包括兩點(diǎn)：一是頁面包括哪些元素，是否覆蓋了需求，有無冗余。再就是各元素的類型，比如列表、文本框，按鈕等等。
2.在確定元素之后，就必須考慮元素對用戶的開放性。即用戶的訪問、操作權(quán)限。一般而言，權(quán)限的控制往往有三種展現(xiàn)方式：一是通過頁面元素的直接屏蔽使無權(quán)限的用戶不可見，一是無操作權(quán)限用戶使用時(shí)提示沒有權(quán)限，還有就是對于沒有權(quán)限的用戶操作內(nèi)容顯示為不可用狀態(tài)。測試人員必須確認(rèn)UC中有該部分的描述，并確認(rèn)具體屬于哪種形式和其控制方式。否則在編寫TC過程中就會(huì)出現(xiàn)遺漏，從而會(huì)導(dǎo)致bug的遺漏。
3.明確入口。由于web自身的特點(diǎn)，一個(gè)頁面的訪問往往會(huì)存在多個(gè)入口，每一個(gè)入口的前置條件都有可能不同，因此測試人員必須確認(rèn)所有可到達(dá)的路徑及其條件。
4. 在明確頁面布局及元素、權(quán)限控制、入口后，我們就應(yīng)該進(jìn)一步了解一些具體的操作細(xì)節(jié)。例如結(jié)合demo圖(如果有的話)，確定哪些是輸入，哪些是輸出。而在考慮這些輸入和輸出的時(shí)候我們不光要知道頁面展現(xiàn)出來的輸入、輸出項(xiàng)，一些未展現(xiàn)出來的的輸入、輸出項(xiàng)，即隱藏的數(shù)據(jù)也是測試人員需要了解的。如注冊用戶，可能我們在頁面上只需輸入類似用戶名、id之類的輸入項(xiàng)，當(dāng)成功后系統(tǒng)也只是提示操作成功，并返回注冊