首页 > 软件测试

再论纯软件测试方法 

作者:顾翔
前言:
2009年,我在网上发布了一篇文章《浅谈纯软件测试方法》,参见http://www.51testing.com/html/03/n-112703.html。这些日子我对这个想法有了更深入的理解。
大家都知道李小龙吧,他汇集了各路武林高手,并向他们学习,最后结合武术、柔道、摔跤、拳击、泰拳…的精华,并且结合武术的本质“攻”和“防”创建了自己的拳术截拳道, 达到了武术的最高境界,成为一代宗师。
在软件测试领域,软件测试一直是被开发牵着鼻子走的,虽然产生了各种软件测试模型(V模型、X模型、H模型)和方法(基于传统、基于质量、基于风险和基于经验)也解决不了提高质量的本质。另外,最近Scrum敏捷方法被各大公司使用。首先我的确认为Scrum是个好东西,尤其是ATDD, BDD, TDD摆脱了测试被开发牵着鼻子走的形式,然而Scrum给测试带来了很大的工作量,尤其是在Sprint后期,随着老功能越来越多,回归测试的工作量越来越多。有人提出了想法,让开发人员帮助测试,可是大家都知道,测试需要有一定发现Bug天赋的,有些人善于做测试,而有些人不善于。
于是我们又回到了软件测试的本质,“测”与“试”。所谓“测”就是检测软件系统是否按照用户显性需求的运转,比如功能;“试”可以理解为试错,尝试。比如找到系统最大负载点,系统对错误输入,异常环境是否可以适应,一旦程序发生错误多久可以修复。我们也可以把“测”理解为证“真”,“试”理解为证“伪”。
下面我们来讨论在一个Sprint中如何运用软件测试的本质“测”与“试”来进行测试工作。我们假设一个Sprint为1个月,即22个工作日,我们把这22个工作日分成前、中、后三部分。前(第1个工作日到第7个工作日),中(第7个工作日到第14个工作日),后(第15个工作日到第22个工作日)。
在Sprint前期测试人员的主要工作为书写这个Sprint 新功能的测试用例,这些测试用例可以是自动化,也可以是手工的,并且在这些测试用例中,以证“真”的“测”的方法为主,证“伪”的“试”的方法为辅。我把这种测试方法叫做纸上谈兵式测试,在这里测试用例没有具体的格式,目的只要可以给相应的开发人员看懂就行,关键需要关注的是对新特性的覆盖度。从第二个工作日开始,在每日站会后,测试人员把他们前一天写的测试用例交给相应的开发人员,与他们进行一对一的评审,由于测试用例是每日提交的,所以评审的时间不会很长。一旦通过评审后,这个测试用例就交给开发人员了。开发人员在开发期间需要100%达到这些测试用例所希望的结果,并且根据开发人员的自身需求,在适当的时候执行测试用例。
在Sprint中期,测试人员主要工作专向基于经验的探索式测试和非功能性测试,在这个阶段,主要运用证“伪”的试的方法。而开发人员的主要责任在重新运行一遍交给自己的测试用例,以及对缺陷的修改。
在Sprint后期,开发人员协助测试人员一起完成回归测试,开发人员按照以前的测试用例执行测试,测试人员仍旧以探索式方式来测试,以保证整个Sprint结束是一个高质量可交付的产品。一旦发现缺陷,开发人员优先回去修改缺陷。
我们在日常测试工作中仍旧需要抓住软件测试的本质,“测”与“试”,发挥测试人员的经验优势,同时邀请开发人员来协助产品测试,从而提高产品的质量。

软件测试

  

   

投稿关闭窗口打印