敏捷测试理论以及实践(7)

发表于:2011-11-22 10:52

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:softerwarer    来源:51Testing软件测试网采编

分享:

  5、传统测试阶段

  当开发完成了所有的功能点,测试那个时候也差不多完成了这些功能点的测试,我们就会有一个阶段性的最终版给客户评估,让客户看看需要的功能是不是都已经可以了,如果觉得没什么问题,一般情况下就不进行功能添加与更改了。(当然,真的要更改我们还是会欢迎的,不过一般客户也知道,频繁的更改不能保证产品的质量,所以到最后他们一般有不紧急的更改也会要求放在下一个版本里的)

  到目前为止,真正意义上的敏捷测试阶段其实已经完成了,要开始进入一些传统的测试了,比如系统测试性能测试,压力测试等。这些就会用到之前说的DevTest里管理的测试用例,通过这些测试用例,我们会生成测试任务,然后通过手工和自动的方式,把这些任务完成,当然,可能要进行几轮,第一轮测试最仔细,覆盖面最大,所以时间也最长,第二轮主要是对开发修Bug的确认以及可能影响到的功能的测试,最后还有一轮验收测试,主要对基本的功能进行测试,确保不会出现明显的问题。

  这些测试都完成以后,差不多产品也就可以发布了,当然能不能发布,领导们还是会有一个会议研究通过的,不过也就是通过 DevTrack 和 DevTest 来导出一些报表看看测试情况来了解产品质量。

  以上差不多就是我们公司现在的一个流程,从严格意义上来说,不是完全的敏捷测试,只是算一部分,但是如果从以前的瀑布来看看,已经算很敏捷了。而且,从现在这个流程分析,如果把那些传统意义上的测试继续敏捷化,我们觉得对产品的质量没法保证,所以基本上,目前这个模式,可以算是我们公司特色的敏捷测试了,之后应该不太会有大的更改了。

  接下来我再总结一下我们公司的模式,以及补充一些之前没提到的,因为之前写得太急,有时候很难想得太全。

  我们公司测试模式按照顺序主要有以下这么几步组成:

  1)需求阶段测试研究设计方案是否符合要求

  2)开发编码期间完成测试用例

  3)开发完成一个功能的编码,测试就需要开始测试,并且确保能在一个迭代周期中完成测试,并且确认严重Bug的修复

  4)所有迭代周期完成后,开始进入集成测试,系统测试,验收测试以及压力测试,性能测试

  差不多测试需要参与的工作就是这几步了,下面就是有一些细节点讨论一下,我会以问答形式来介绍:

  (1)问:发现了很多Bug,测试人员怎么知道哪些Bug要马上修,哪些可以推迟修呢?

  答:首先,我们会规定什么样子的Bug需要什么样的优先级,比如报错优先级就会比较高,每个测试人员都有这么一个文档让他们来判断这个 Bug 是什么级别。其次,我们会有专门的人员对这些Bug进行二次过滤,由他们来觉得这个Bug是否需要在这个迭代周期中进行修复,这种专门的人员的能力需要很高,因为他们需要能了解这个Bug的重要性以及这个Bug修复起来所需人力物力是否能在这个迭代中解决,所以一般这个角色会有测试主管或者项目经理来承担。

  (2)问:整个测试期间,就专职的测试人员参与测试就行了吗?

  答:不是的,首先开发肯定需要进行单元测试;然后设计人员和项目经理也要参与测试,因为只有他们最清楚这个功能设计的初衷,才能真正知道现在做完的是不是真的符合当初的初衷;再次,客户也会参与测试,因为产品说到底最终是给客户使用的,他们当然想拿到一个他们满意的产品,所以我们会定期给客户版本,让他们对做好的功能点进行简单的试用,让他们来看看产品是否符合他们的需要,这样就是最直接的用户体验了,发现的问题也是最真实的。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号