qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          談測試用例的評審

           從網上搜索測試用例的評審,也能搜出好多,我這里把自己能想到的或是借鑒于他人的都在這里進行總結和歸納。

            測試用例的設計很重要,無論你采用的是敏捷測試還是傳統的開發模式,測試用例都應該要文檔化,并且根據項目的schedule,把握好粒度。而QA lead要根據項目的實際情況,先定好模板,制定好測試用例的編寫規范。測試用例設計出來,質量如何?這就需要對測試用例進行評審,這個過程非常重要,對測試人員的能力提高,測試效率的提高都有很好的作用。如果公司流程沒有這個硬性要求,項目再忙,也要抽出一定時間,召集相關人員開個哪怕是非正式的評審會議,大家一起討論用例并給出意見和建議,及時發現問題,并完善測試用例的設計。

            何時進行用例的評審,一般情況下是在用例的初步設計完成之后進行評審,如果需要或時間允許,在整個詳細用例全部完成之后還會進行二次評審,三次評審等。

            大體分文三個級別的評審:

            a)部門評審,測試部門全體員工參與的評審。

            b)公司評審,這里包括了項目經理,需求分析人員,架構設計人員,開發人員和測試人員。

            c)客戶評審,包括了客戶方的開發人員和測試人員。

            測試用例的評審檢查單(Checklist for Test cases):

            1)Has the correct template been used?(是否使用了正確的模板?)

            2)Have all the scenarios specified in the requirement –explicit, implicit, nonfunctional and  been converted into test conditions?(是否覆蓋了需求規格說明,包括內在需求和外在和非功能需求?)

            3)Have the related areas that include possibly be affected by the implementation of the requirement been identified and included in the test cases?(case是否對需求變更的部分進行對應的調整和增加?)

            4)Have the following details been filled up correctly? Requirement references, test procedure, expected result, priority, author’s name, date created…(測試用例是否正確填寫了測試對應的需求,測試步驟,預期結果,優先級,作者姓名,創建日期等..)

            5)Has the test date set, if required been generated appropriate? (測試用例是否包含測試數據,測試數據的生成是否正確?)

            6)Have the required negative scenario between identified in the test conditions? (是否包含了負面測試用例?)

            7)Have the testing techniques—equivalence partitioning, boundary value analysis be used? (是否使用了等價類劃分和邊界值分析的測試方法?)

            8)Have the steps been correctly given in appropriate sequence for each test scenario? (測試步驟是否被闡述清楚?)

            9)Have the expected result been identified correctly? (預期結果是否表達正確?)

             ● Expected results should respond to the user actions given in each step/action.(每個步驟都應給出相應的測試結果)

             ● Ensure that too many things are not included to be verified under one expected output.(給出一個預期結果的驗證步驟不要太多)

             ● Ensure that separate cases are written for multiple verifications of the application’s behavior. (每條case最好驗證一個問題)

             ● Vague statements like “Appropriate message/value/screen” etc. should not be part of expected result. Every detail should be clearly spelt out. (預期結果中不要使用模糊的語言)


          posted on 2011-10-21 15:16 順其自然EVO 閱讀(522) 評論(0)  編輯  收藏 所屬分類: 測試學習專欄

          <2011年10月>
          2526272829301
          2345678
          9101112131415
          16171819202122
          23242526272829
          303112345

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 江津市| 九龙县| 顺昌县| 图木舒克市| 金塔县| 揭阳市| 泽库县| 宜阳县| 织金县| 女性| 厦门市| 垫江县| 镇远县| 富宁县| 三穗县| 南雄市| 德钦县| 通榆县| 达拉特旗| 宣化县| 吉木萨尔县| 贞丰县| 南乐县| 万荣县| 玉门市| 祁门县| 大厂| 宜都市| 中卫市| 海口市| 武清区| 滨州市| 昌吉市| 富阳市| 台前县| 景宁| 永年县| 河东区| 东光县| 阿巴嘎旗| 阿拉善右旗|