carandcat 2013-06-04
互联网软件测试设计感悟
今天部门小组内,一同学就软件测试设计进行分享,分享过程中大家有各种讨论和吐糟,颇有感悟。在此记录和写点自己的看法。
软件测试设计,单从狭义上讲,指的是软件测试用例的设计。是从需求转化到测试用例的过程。几点需要探讨的是:
一、测试测试用例是否要写?写的粒度如何?
目前就我个人测试的项目来看,测试用例都还是有写的必要性,即使项目再紧,时间再不够时,测试同学也要花一定的时间来进行测试设计,理清需求,理清测试的思路。当然,如果一个大牛,对此业务相当熟悉,或者业务非常简单,简单到不用设计也知道如何测的话,那就另当别论了。我目前的项目基本上都是会做测试设计,编写测试用例或者是画思维导图的。
但是,每个项目的测试用例的粒度会有所不同。对于之前测试的店铺业务,刚开始入职时,对于新人,测试用例都写的很规范,各种前置条件和校验点都很细致。此时对于业务的全面细致都很有好处。另外,这样的测试用例,业务沉淀的积累,更便于他人对此业务的了解,当有其它同学来测试此业务时,上手会更快。
后来对于此业务比较熟悉,业务也相对稳定,测试的校验点能评估的更全面,此时的测试用例,写的相对会比较粗,更多在校验点的覆盖,花在TC编写的时间会短一些。
之前接触的创新业务,项目处于探索阶段,需求变化比较频繁,测试用例的复用及参考价值不大。我更多的是以思维导图的方式,理清思路,对于TC更多的是写明测试的校验点,相对粒度比较粗。更多的是细节的确认,和产品,开发之前的沟通和需求变动的同步。保证测试用例的正确性和覆盖是否全面。
二、怎样的方式能更好的进行测试用例的设计?
测试用例的设计过程:在编写用例时,细化需求,产出测试的校验点。 测试时,一方面要以用户的角度去体验测试产品,另一方面,需要以开发的思维去分析功能。在黑盒测试编写功能时,可以走查代码,以白盒测试来辅助补全用例场景,各种异常流等,或去掉一些无意义的用例。
三、测试设计时要考虑的点有哪些?
广义上讲在做测试设计时,也是在做测试方案的设计,测试计划的制定。包括测试的手段,是手工测试还是自动化,可测性如何?是否会有性能,安全测试,是否要做兼容性测试,测试的重点等。但在有限的时间和人力资源的情况下,如何能提高收益和产出比? 需要对不同的测试点分优先级,重点放在主要的风险点上。
四、测试角色的价值?未来的职业发展方向?
个人认为的软件测试角色的价值:在快速发展的互联网,需要的是更敏捷,更快速的响应和发布产品。测试的角色,是更好的保证产品的质量。
测试的义务,是发现问题,抛出问题和风险,持续跟进问题。一方面需要提升自己的技能,提升定位问题的能力。控制风险,评估影响(可与开发一起评估),对各种风险的识别的抛出。更高的境界,慢慢成为一个测试开发,测试辅助开发去执行测试,测试更多的是去开发工具,来帮助开发去测试。另一方面,测试要站在用户角度,熟悉业务,成为一个业务的专家。
一个正交法设计测试用例的案例研究1992年AT&T发表了一篇讲述在测试过程中使用正交表一个案例研究。据测试负责人估计,如果AT&T采用1000个测试用例的 测试计划,可能仅仅只发现这些缺陷中的32个。