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