良好的测试用例管理对测试执行的益处
2014-02-22 19:20
295 查看
偶然看到一篇关于测试用例管理的文章,总的来说有4个方面:
1). 迭代周期中测试用例的范围
2). 测试用例编写的规范。这个问题之前文中有简单提到过,即要在项目kickoff前定义好测试用例的编写方式,做到简洁、统一
3). 每轮测试中应该关注的是什么?是测试的执行率,还是真正有效的测试
4). 测试覆盖率是否足够
这几个问题深入讨论的话会发现相互依托。第一个问题,要先在测试开始之前考虑好执行测试的范围,对于不同的测试制定不同的测试计划。以Scrum来说,每个Sprint都会有可交付的功能需要测试,那么测试的范畴就应该是本轮需要交付的功能;当然,每个Sprint之间也会相继开发相关或业务上有所关联的功能,就需要在关联功能完成之时进行相关测试;另外,在项目上线前的一些特殊测试,要准备的测试用例也会有所不同,例如,有需要串接不同业务流程、关键业务的测试,那执行的测试用例的重点就在串接测试部分(E2E)。为了应对不同测试类型、测试范畴的情况,那么在测试用例的开发之时,就要定义好如何区分不同类型的测试用例,例如,Functional(为单一功能,Form
validation层面的测试用例),UI(界面),Integration/Business Logic(偏重业务逻辑,业务逻辑串接层面的测试用例)。那么这也就谈到了第二个问题,测试规范定义的问题,这是测试的框架。
第三和第四个问题一起来讨论。针对测试后的产出物,想必测试执行率、通过率、Bug率是显而易见被大家关心的。但回想我去年的经历,有种为了测试覆盖率而覆盖率的感觉,想必QA们也被我催着要这些东西而头晕脑胀吧,又由于Tester们至死不渝的怀疑精神。那么我们如何保障测试的有效性呢,执行了100条用例就保证相应模块的功能是通过的呢。想想看,定义有效的规范是首当其冲。测试用例的评审review也可以帮上大忙。最后,挑选合适的用例进行测试也是保障措施之一。最后的最后,对于不同类型测试用例的类型(Function,UI,Business
Logic,E2E),组合在一起符合测试范畴的测试用例,这样来尽量满足足够大的测试范畴。就像白盒测试,可以有最小单元、针对每个方法的测试,也可以有针对业务逻辑的测试。黑盒测试而言同样,既要包括覆盖了基本功能的用例,也要包括业务流程、业务交互的测试用例。这样,无论从黑盒、白盒都可以满足测试覆盖率的要求。作为Leader自然对测试的结果会充满信心了。
目前想到了这些方面,后面如果想到再补充进来吧。
1). 迭代周期中测试用例的范围
2). 测试用例编写的规范。这个问题之前文中有简单提到过,即要在项目kickoff前定义好测试用例的编写方式,做到简洁、统一
3). 每轮测试中应该关注的是什么?是测试的执行率,还是真正有效的测试
4). 测试覆盖率是否足够
这几个问题深入讨论的话会发现相互依托。第一个问题,要先在测试开始之前考虑好执行测试的范围,对于不同的测试制定不同的测试计划。以Scrum来说,每个Sprint都会有可交付的功能需要测试,那么测试的范畴就应该是本轮需要交付的功能;当然,每个Sprint之间也会相继开发相关或业务上有所关联的功能,就需要在关联功能完成之时进行相关测试;另外,在项目上线前的一些特殊测试,要准备的测试用例也会有所不同,例如,有需要串接不同业务流程、关键业务的测试,那执行的测试用例的重点就在串接测试部分(E2E)。为了应对不同测试类型、测试范畴的情况,那么在测试用例的开发之时,就要定义好如何区分不同类型的测试用例,例如,Functional(为单一功能,Form
validation层面的测试用例),UI(界面),Integration/Business Logic(偏重业务逻辑,业务逻辑串接层面的测试用例)。那么这也就谈到了第二个问题,测试规范定义的问题,这是测试的框架。
第三和第四个问题一起来讨论。针对测试后的产出物,想必测试执行率、通过率、Bug率是显而易见被大家关心的。但回想我去年的经历,有种为了测试覆盖率而覆盖率的感觉,想必QA们也被我催着要这些东西而头晕脑胀吧,又由于Tester们至死不渝的怀疑精神。那么我们如何保障测试的有效性呢,执行了100条用例就保证相应模块的功能是通过的呢。想想看,定义有效的规范是首当其冲。测试用例的评审review也可以帮上大忙。最后,挑选合适的用例进行测试也是保障措施之一。最后的最后,对于不同类型测试用例的类型(Function,UI,Business
Logic,E2E),组合在一起符合测试范畴的测试用例,这样来尽量满足足够大的测试范畴。就像白盒测试,可以有最小单元、针对每个方法的测试,也可以有针对业务逻辑的测试。黑盒测试而言同样,既要包括覆盖了基本功能的用例,也要包括业务流程、业务交互的测试用例。这样,无论从黑盒、白盒都可以满足测试覆盖率的要求。作为Leader自然对测试的结果会充满信心了。
目前想到了这些方面,后面如果想到再补充进来吧。
相关文章推荐
- 使用TestDirector管理测试用例和评估测试用例执行状况
- 使用testng+xml编写、执行自动化测试用例
- Instruments-Automation: 通过命令行执行测试用例
- Python单元测试框架之pytest---如何执行测试用例
- fitnesse - 用例创建编辑、管理、执行和日志
- 【selenium】python+selenium+unittest,关于每次执行完一个测试用例都关闭浏览器等时间较长的问题之解决方案
- Python - 用协程并发执行测试用例
- 测试用例执行态度
- Maven 打包时不执行测试用例
- 如何有效地管理测试用例
- robotium:tearDown中使用solo.finishOpenedActivities()会导致执行测试用例crash问题
- 实施高效测试:测试用例设计与执行的敏捷化
- JUnit4:在测试用例中用FixMethodOrder指定测试方法的执行顺序
- Coded UI Test 同时执行多个测试用例不必每次都关闭浏览器
- appium自动化测试实践之python利用unittest进行测试用例执行的几种方式(转载)
- Junit框架使用(3)--按照顺序执行测试用例
- Python-unittest---测试用例批量执行
- JUnit4多线程执行测试用例
- 在设计和执行测试用例的时候的几点心得和经验
- TFS2010中管理测试用例等测试对象的那些表