測試用例評審(功能測試的用例評審需要關注的是哪些?)
1.功能測試的用例評審需要關注的是哪些?
用例評審主要是QA、產(chǎn)品人員、開發(fā)人員和測試人員針對測試用例能否用于項目的測試而做的，我在TestBird從事了多年的項目測試，測試用例是給測試人員執(zhí)行用的，所以要求盡量的詳細而不冗余，精湛而不紕漏，至于一些覆蓋率的問題還是測試內部評審時要考慮的問題，與項目的用例評審沒有關系。
主要分為4個環(huán)節(jié)：需求評審、需求實現(xiàn)流程圖評審、測試大綱評審、測試用例檢查每個環(huán)節(jié)都包含很多內容，比如說需求評審主要是：檢查需求理解無偏差、檢查需求講解思路清晰、檢查需求討論會議提出需求建議、需求討論的問題都有體現(xiàn)，并且記錄的詳細、檢查需求講解時存在問題的記錄，跟進結論。流程圖評審，包括要檢查實現(xiàn)邏輯的深度與仔細程度。
例如：軟件升級實現(xiàn)邏輯--什么時候獲取服務器版本信息？版本信息有什么？ 版本信息獲取失敗的處理？獲取的版本信息版本比對策略是什么？比對后的下載邏輯策略是什么？下載的文件保存在哪里？下載過程的失敗處理？下載成功后的安裝策略是什么？安裝失敗的處理邏輯是什么？安裝成功后的數(shù)據(jù)加載時機以及加載哪些數(shù)據(jù)？等等建議你還是找找相關刊物，有很多具體的內容。
2.如何對測試用例進行評審
4、評審內容 評審的內容有以下幾個方面： 1） 用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋。
2） 優(yōu)先極安排是否合理。 3） 是否覆蓋測試需求上的所有功能點。
4） 用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結果是否清晰、正確；期待結果是否有明顯的驗證方法。
5） 是否已經(jīng)刪除了冗余的用例。 6） 是否包含充分的負面測試用例。
充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數(shù)量，畢竟一個健壯的軟件，其中80%的代碼都是在“保護”20%的功能實現(xiàn)。 7） 是否從用戶層面來設計用戶使用場景和使用流程的測試用例。
8） 是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟。
個人認為，一個“健康”的測試用例至少要通過前5個標準。 5、評審的方式 1） 召開評審會議。
與會者在設計人員講解之后給出意見和建議，同時進行詳細的評審記錄。 2） 通用郵件與相關人員溝通 3） 通用IM工具直接與相關人員交流 方式只是手段，得到其它人員對于用例的反饋信息才是目的。
無論采用那種方式，都應該在溝通之前把用例設計的相關文檔發(fā)送給對方進行前期的學習和了解，以節(jié)省溝通成本。 6、評審結束標準 在評審活動中會收集到用例的反饋信息，在此基礎上進行用例更新，直到通過評審。
3.如何有效的進行測試用例評審
主要是避免責任不清，出現(xiàn)扯皮，誤工等現(xiàn)象。
所以，必須參加測試用例評審。首先要清楚內部評審的定義，是測試組內部的評審，還是項目組內部的評審。
評審的定義不同，內容也不會相同。 如果是測試組內部的評審，應該著重于： 1.測試用例本身的描述是否清晰，是否存在二義性； 2.是否考慮到測試用例的執(zhí)行效率.往往測試用例中步驟不斷重復執(zhí)行，驗證點卻不同，而且測試設計的冗余性，都造成了效率的低下； 3.是否針對需求跟蹤矩陣，覆蓋了所有的軟件需求； 4.是否完全遵守了軟件需求的規(guī)定。
這并不一定的，因為即使再嚴格的評審，也會出現(xiàn)錯誤，應具體情況具體對待。 如果是項目組內部的評審，也就需要評審委員會來做了，角度不同，評審的標準也不同。
4.測試人員如何進行用例評審?
主要是避免責任不清，出現(xiàn)扯皮，誤工等現(xiàn)象。
所以，必須參加測試用例評審。首先要清楚內部評審的定義，是測試組內部的評審，還是項目組內部的評審。
評審的定義不同，內容也不會相同。 如果是測試組內部的評審，應該著重于： 1.測試用例本身的描述是否清晰，是否存在二義性； 2.是否考慮到測試用例的執(zhí)行效率.往往測試用例中步驟不斷重復執(zhí)行，驗證點卻不同，而且測試設計的冗余性，都造成了效率的低下； 3.是否針對需求跟蹤矩陣，覆蓋了所有的軟件需求； 4.是否完全遵守了軟件需求的規(guī)定。
這并不一定的，因為即使再嚴格的評審，也會出現(xiàn)錯誤，應具體情況具體對待。 如果是項目組內部的評審，也就需要評審委員會來做了，角度不同，評審的標準也不同。
5.功能測試的用例評審需要關注的是哪些
用例評審主要是QA、產(chǎn)品人員、開發(fā)人員和測試人員針對測試用例能否用于項目的測試而做的，我在TestBird從事了多年的項目測試，測試用例是給測試人員執(zhí)行用的，所以要求盡量的詳細而不冗余，精湛而不紕漏，至于一些覆蓋率的問題還是測試內部評審時要考慮的問題，與項目的用例評審沒有關系。
主要分為4個環(huán)節(jié)：需求評審、需求實現(xiàn)流程圖評審、測試大綱評審、測試用例檢查
每個環(huán)節(jié)都包含很多內容，比如說需求評審主要是：檢查需求理解無偏差、檢查需求講解思路清晰、檢查需求討論會議提出需求建議、需求討論的問題都有體現(xiàn)，并且記錄的詳細、檢查需求講解時存在問題的記錄，跟進結論。
流程圖評審，包括要檢查實現(xiàn)邏輯的深度與仔細程度。例如：軟件升級實現(xiàn)邏輯--什么時候獲取服務器版本信息？版本信息有什么？ 版本信息獲取失敗的處理？獲取的版本信息版本比對策略是什么？比對后的下載邏輯策略是什么？下載的文件保存在哪里？下載過程的失敗處理？下載成功后的安裝策略是什么？安裝失敗的處理邏輯是什么？安裝成功后的數(shù)據(jù)加載時機以及加載哪些數(shù)據(jù)？等等
建議你還是找找相關刊物，有很多具體的內容。
6.測試分析測試用例的注意事項
當然應該是你的測試用例的步驟，要讓別人能看懂，不然別人怎么執(zhí)行你的用例呢
什么樣的用例是好的用例？
一.質量屬性
Quality Attributes
1.正確性：確保測試標題描述部分的內容正確性。
2.經(jīng)濟性：只為確定需要的目的設計相應的測試步驟
3.適應性：既能適應短期需要，又能考慮長遠需要。
4.可追蹤性：用例能追蹤到一個具體的需求。
5.自我清理性：單個用例不會影響整個測試環(huán)境，即用例執(zhí)行完了可以恢復原有的測試環(huán)境。
二.結構化和可測試性
Structure and testability
1.含有規(guī)范的測試標題和編號。
2.含有一個確定的測試某一個特定需求的目的。
3.含有關于測試方法的描述。
4.指定條件信息-環(huán)境、數(shù)據(jù)、預置的條件測試、安全入口等。
5.含有操作步驟和預期結果。
6.陳述任何輔助證據(jù)，例如截圖報告并確保這些東西妥善保存。
7.確保測試環(huán)境的干凈（即用例不會影響整個環(huán)境）。
8.描述時使用主動語氣結構。
9.操作步驟不要超過15步
10.確保單個用例測試執(zhí)行時用時不超過20分鐘。
11.自動化腳本用例添加必要的注釋，比如目的、輸入和期望結果。
12.如果可能，建議提供可選擇性的預置條件測試。
13.用例之間的先后順序是否跟業(yè)務流程一致，即用例在業(yè)務流程中的彼此順序關系是否合理。
三.配置管理
Configuration management
1.采用命名和編號規(guī)范歸檔。
2.保存為特定的格式，文件類型。
3.用例版本是否與當前被測試軟件版本一致（對應）。
4.包含用例需要的相應測試對象，如特定數(shù)據(jù)庫。
5.存檔閱讀。
6.存檔時按角色控制訪問方式
7.測試用例應該注意什么
一、首先測試需求分析要全面。
測試需求分析分兩步：1、測試需求的獲取 需求的來源：顯式需求：（1）原始需求說明書 （2）產(chǎn)品規(guī)格書 （3）軟件需求文檔 （4）有無繼承性文檔 （5）經(jīng)驗庫 （6）通用的協(xié)議規(guī)范 隱式需求：用戶的主觀感受，市場的主流觀點，專業(yè)人士的評價分析2，需求的分析 ，產(chǎn)生測試需求文檔 將不同的需求來源劃分成一個個需求點，針對每一點進行測試分析：（1）界定測試范圍 （2）利用各種測試設計的方法產(chǎn)生測試點 在測試方法方面，可做如下注意：其一，分析出口入口。從入口分析，將可能出現(xiàn)的環(huán)境，條件，操作等內容分類組合，然后根據(jù)各位測試達人的方法進行整合，逐一驗證。
從出口分析，將可能出現(xiàn)的結果進行統(tǒng)計，根據(jù)結果的不同追根溯源，再找到不同的操作以及條件等內容，統(tǒng)計成文檔，逐一驗證。其二，多種測試手法的學習和使用。
大家可能更多的關心測試方法，但是具體操作的手法也是需要注意的。畢竟測試方法比較容易找到，各位達人都很熟悉。
如果將每個人不同的測試手法總結出來并在自己的測試實施中加以使用，可能會收到意想不到的成果。在測試流程方面，可作如下注意：其一，初期要做好需求分析。
將需求逐漸細化到小功能點，針對每個功能點進行測試設計。對于完成的測試設計文檔，經(jīng)過項目相關人員的檢查評審，做成所需要的初稿。
其二，在測試過程中，根據(jù)需求變更和具體測試執(zhí)行過程中遇到的問題完善測試設計文檔。其三，測試執(zhí)行結束后，對于出現(xiàn)的問題進行總結。
其中包含自己本身發(fā)現(xiàn)的問題，也可能會有客戶提出的問題。將總結出來的結果融合到測試設計當中去，進一步完善測試設計文檔。
對于一次測試，是不可能有覆蓋度全面的測試的。需要多次去總結積累，才會使測試越來越全面。
在測試流思維方面，可作如下注意：其一，測試全面不等于全面測試。不同階段對于軟件測試有不同的要求，比如在0.8版本以前，對于不重要的畫面問題或是細小的功能問題就不需要關心。
但是在驗收階段，這些內容可能更需要注意。其二，學無止境，只有不斷的去學習不斷的去思考，才能使自己測試的能力更強，測試對象的全面性也更完整。
二、當測試需求分析完成，并且形成文檔后，要進行測試需求評審，保證需求的準確性以及完整性。三、測試需求完成以后，可以根據(jù)測試需求設計測試用例。
要保證測試用例能夠全面覆蓋測試需求，要包含所有的情況。測試用例設計上劃分為單功能測試用例和測試場景設計，單功能測試覆蓋的需求中的功能點，測試場景覆蓋需求中的業(yè)務邏輯。
在設計測試用例的時候，可以使用多種測試用例設計方法?！袷紫冗M行等價類劃分，包括輸入條件和輸出條件的等價類劃分，合理設置有效等價類和無效等價類，這是減少工作量和提高測試效率最有效的方法。
● 必須使用邊界值分析，經(jīng)驗表明，這種方法設計出的用例能發(fā)現(xiàn)很多程序錯誤。● 可以使用錯誤推測法追加一些測試用例，這需要依靠您的智慧和經(jīng)驗。
● 對照程序邏輯檢查已設計出的測試用例的邏輯覆蓋度，如果沒有達到覆蓋標準應當再補充足夠的測試用例?！?如果程序的功能說明中含有輸入條件的組合情況，一開始就可選因果圖和判定表驅動法。
●對于參數(shù)配置類的軟件，要用正交試驗法選擇較少的組合方式達到最佳效果。● 對于業(yè)務流清晰的系統(tǒng)，可以利用場景法貫穿整個測試方案過程，在案例中綜合使用各種測試方法。
當測試用例設計完成后，要組織測試用例的評審，這樣可以吸取別人的意見，減少遺漏，補全測試用例。四、測試用例編寫完成后，就是測試執(zhí)行，● 測試用例執(zhí)行100%覆蓋。
●在測試執(zhí)行過程中，要繼續(xù)對測試用例補充完善，確保提高測試覆蓋率。五、在整個測試過程中，需求都是不可能不變的，所以要及時的更新測試需求、測試用例。
六、要將測試需求、測試用例以及發(fā)現(xiàn)的bug關聯(lián)起來，便于管理和跟蹤，同時也便于查看覆蓋率。
