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