生命周期半年的项目需求是否有必要写用例?(51Testing论坛话题PK)

发表于:2009-3-04 13:41

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

 作者:Jackc    来源:51Testing论坛

分享:

背景描述:对于稳定客户的项目类测试,经常会遇到需求三天一变,两天一变,由于时间周期不是太长,客户需求经常变动,导致BA/PM等都未能及时更新需求,从而给测试组的需求经常是非最新版本,且测试阶段的需求也经常有小变动,导致用例效果不大甚至失效。(可能是针对需求说明书失效,更多情况是针对实际需求-即系统实现方式失效)。

精彩答案:

会员Jackc:

  敏捷性测试团队才是王道

  1、LZ的题目中缺少两个关键属性:项目的规模(包括需求变更规模)和测试资源

  2、浅析项目规模和测试资源的影响

  其实LZ这个题目最大的争议点就是在这里,如果这两个属性可以确定,相信大家的思路会清晰很多。下面偶只分两类进行简单的分析:

  A、项目规模大(需求变更规模大),测试资源少:按照CMMI 5中测试用例的编写标准来说,限定6个月的时间。测试团队需要完成测试策略/计划的拟定和评审、测试用例的设计/评审/修改、变更需求的评审/修改、新需求测试用例的设计/评审/修改...

  显而易见,剩余还有多少时间完成测试执行的跟踪和改进?即使前期能勉强跟进,偶相信在后期也只能疲于奔命,敷衍了事,什么“测试驱动开发”也只是梦中花而已。

  国内很多企业都是这样的情况,相信N多测试同仁对此是深有体会。

  B、项目规模小(需求变更规模小),测试资源多:人多好办事,只要Test Manger不是个草包,将测试工作进行有条理的细分,责任到人,在测试准备阶段选择有利于修改的测试流程(包括简易需求和测试资源变更流程以及便于变更的测试用例模板等等),在测试执行阶段,注意需求收集已经各部门以及客户之间的信息交流,还是很容易搞定的。

  本文出自51Testing软件测试论坛话题PK活动,感谢会员Jackc的精彩分析。

  3、浅析正方观点的风险:

  A、如正方wuyu702 所说:“先会把大概的用例写出来,测试的过程中,不停的添加用例。最后测试完了,用例也出来了……”。

  什么叫大概的用例?

  用例最基本的要求就是任何测试人员都可以操作,敢问你如果写出这样缺斤少两的用例,当你临时有其他更重要的任务,然后把这块测试工作交付给其他人来做,能够保证别人肯定能看明白?

  B、又如正方Okayde、wuyu702、jessies、兆隆8032等提出的:用例是用来保障测试的质量,以及对测试执行的指引。

  测试用例是唯一的保障产品/测试质量的手段?没有测试用例就无法指导和跟踪测试执行了?

  本文出自51Testing软件测试论坛话题PK活动,感谢会员Jackc的精彩分析。

  当然不是,这里偶引用一个只有部分公司在用的一个概念“测试规程(test procedure)”。它是个提供详细的测试用例执行指令的文档。测试规程更注重测试的流程、方法等比较泛的内容,以方便对测试用列的编写有一个整体的概念和把握。不同的公司规范、要求和详尽程度可能不同。

  测试规程与测试用例的区别:理想化的测试用例确实需要很多测试数据集合,但是现实中对某一软件进行测试时,由于涉及的面太广,无法一一列举出所有数据,所以要根据公司的规范来做相应的调整。所以,测试规程的文档编辑量较轻,但是只适合熟练的测试人员执行,而测试用例的执行者可以使任何人。

  楼上很多同仁谈到的根据实际情况写简化用列的做法实际就是将设计测试用例变为设计测试规程,然后以测试规程来指导测试执行,提供测试质量(比如测试覆盖率)的评估。但是楼上的同仁没有对简化测试用例提出标准?如果一个测试团队里有3、4个简化标准,大家的测试用例简化的“度”都不一致,岂不乱套?

  C、2A中描述的项目情况,仍采用设计常规的测试用例的方法,那么只能有两种结果:a、披着“测试用例”的外套,却是到处缺胳膊少腿,敷衍了事,难以达到测试用例的覆盖标准;b、忙于测试用例的编写,无法在测试执行中完成测试的跟踪与改进,每天都疲于奔命,最终完成N个项目后,测试团队的水平仍然停滞不前,经常受到项目组的“鄙视”。

  4、偶的观点:敏捷性测试团队才是王道,项目不同测试流程不同。针对LZ的项目,选择测试规程代替测试用例是明智之举。下面偶只针对与设计测试规程有关的部分提出一个简单的方案。

  A、前提:测试团队组成基本由熟练测试人员组成(就软件黑盒测试来说,加入团队半年以上的就可以叫做熟练了)。统一规范的测试流程(相信这个只要是稍微正规点的公司都有)PS:此流程只适用于2B的情况,并且可以进行裁减。有些公司是将标准流程做成checklist形式,方便项目组选择。

  B、策划:测试负责人根据项目实际情况在测试准备阶段裁减出适用于该项目的测试流程,并进行评审。其中有两点必须说明:测试执行依据采用测试用例还是测试规程或者两者皆用;测试用例(测试规程)设计的标准。

  本文出自51Testing软件测试论坛话题PK活动,感谢会员Jackc的精彩分析。

  C、变更:满足以上两个条件,如若遇到实际需求被迫变更,则修改相应测试规程,并评审即可。修改测试规程和修改测试用例在工作量上存在很大的区别,偶举一个例子:

  为了简单,用例和规程的格式就忽略了,只写具体输入步骤一部分,书写格式也比较随意。

  原需求:编辑框A中允许输入最多20个中文

  规程的输入步骤:

  只输入0~20个中文,点击确定,检查结果。备注:其中0、20必须测试

  输入21个中文,检查结果

  输入非中文字符,检查结果。备注:包括英文/特殊符号...

  混合输入中文与非中文字符,检查结果。备注:中文字符在第一位的情况必须测试

  ...

  测试用例的输入步骤:

  不输入任何字符,点击确定,检查结果

  输入10个中文字符,点击确定,检查结果

  输入20个中文字符 ,点击确定,检查结果

  输入21个中文字符,点击确定,检查结果。

  ....(不写了,N多)

  假如修改需求:编辑框A中允许输入最多20个中文或数字

  规程的输入步骤:

  输入0~21个中文或数字,点击确定,检查结果。备注:数字/中文混合输入、0/20/21位字符输入必须测试。

  ....

  假如换成测试用例,那就只有....慢慢写了~

  D、跟踪/评估:其实从4C中的例子可以看出,测试规程是可以对测试质量进行跟踪和评估的。当然还有其他很多测试质量评估方法,比如缺陷分析技术,详细信息请看

  http://bbs.51testing.com/thread-117496-1-2.html

  小结:综上,LZ所说的问题可以使用测试规程代替测试用例来解决。

  建立敏捷性测试团队,不“墨守成规”的进行测试活动,才是测试的王道。

版权声明:原创作品,转载时请务必以超链接形式标明文章原始出处作者信息本声明,否则将追究法律责任。

查看更多软件测试话题:http://bbs.51testing.com/forum-208-1.html

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

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号