测试架构支撑商业成功(第二部分)
上一篇 / 下一篇 2010-06-04 20:58:27 / 个人分类:测试技术
测试架构支撑商业成功(第二部分)
作者:架构师Jack51Testing软件测试网^JhUu%W
联系方式:TestArchitectJie@gmail.com51Testing软件测试网G(wPw;g&|8b0~!f
上期测试架构支撑商业成功(第一部分)回溯:51Testing软件测试网q:rh re C9l5o8`j4m&x
什么是测试架构?商业成功的关键是什么?测试仅仅是找bug吗?经过多年商业环境中测试工作的经验和实践,我将在本文分享心中的——测试架构支撑商业成功。
hKfM*uAD-v0首先,请大家看图一,后续的内容将是对图一的一个全面阐述,告诉大家测试架构,测试活动的执行对商业成功的价值和意义。51Testing软件测试网y5L!p C$c&]if(O
图一
K9X#S2c%[,|{0 三、测试的输出
测试计划
测试计划与一个产品商业项目计划没有太大本质的区别。
测试计划主要包含内容有:
测试范围;测试入口和出口标准;测试用例集;测试用例开发;测试预算;测试进度;测试工具和其他测试资源;用于测试的风险管理;测试状态报告。
测试计划本身至少需要考虑包含如下核心要素:
测试范围——测试计划所要达到的商业目标的范围,也可以理解成需要为多少商业目标提供检测服务,这是决定项目成本,项目进度,项目质量的源头。如果测试范围的制定过于主观,脱离现有资源的现实或工程科学性,那么可以说这个测试计划就只会是一个“无限通用”但又没有实际指导意义的计划。而好的测试范围则能帮助阅读测试计划的项目经理,开发经理,测试工程师们清晰明白的知道在后续的测试活动中,我们测试团队将会对哪些商业目标进行检测活动,测试工程师明白测试的商业目的,项目经理和开发经理知晓是否本计划的测试活动最终与项目目标对齐,有无对商业需求的遗漏。
测试项目的大小和资源——有经验的测试经理会根据测试范围的内容,预估本测试计划项目的大小(项目需要多少测试人力来执行),需要多少相关测试工具等资源。
测试进度——依据测试范围和测试项目的规模(大小和资源)来制定,完成测试范围所需要的里程碑。
风险管理——在测试计划中,测试计划的制定者需要依据项目的情况预先进行项目的质量风险预测,并针对预先识别出来的质量风险进行风险管理,针对不同的风险值制定不同的测试策略。
总体测试策略——将为整个测试计划确立不同的测试阶段,为测试范围选择不同的测试技术和测试活动。
测试计划本身的内部冲突:
当公司所要求的测试进度与测试质量要求发生冲突时,如何处理呢?为了保障测试本身的质量水准,应该在制定测试计划时通过减少测试范围的内容来应对。这样既能保障公司所需要的进度,又不失质量。
测试计划本身的成本:
1年左右的项目,可考虑用几周时间来制定;
1个月左右的项目,可考虑用1-2天的时间来制定;
1周左右的项目,可考虑用几个小时制定;
1天左右的项目(敏捷story),在早上的站立会议上需要1个小时即可;
测试策略
测试策略的制定可大可小,依据测试策略制定者自己的经验和能力来把握。经验丰富的测试策略设计者可以制定整个项目的总体测试策略,此类测试策略甚至能指导和影响后续每个测试计划的制定,确立整个项目测试资源的投入重点,确立整个测试项目会拥有的各类测试阶段和测试活动,应该使用的测试技术,每个测试阶段的测试技术组合。经验稍少的测试策略设计者可以针对每个测试阶段来制定测试策略,确立在该测试活动中测试技术选取,测试资源投入的缘由。在测试策略设计时最重要的输入就是项目的质量风险预测,整个测试策略应该围绕如何充分利用现有测试资源来规避项目的重大质量风险来开展,可以这样来概括:质量风险是测试策略的指南针。而测试策略将会让项目经理明白项目的测试资源会被如何科学的利用,项目经理也可通过测试策略的清晰度,逻辑关联性,科学性了解测试团队是否为测试的明白人。
测试方案
常见的测试方案有性能测试方案,压力测试方案,自动化测试方案,安全性测试方案,XX场景测试方案,XX可靠性测试方案等。测试方案是测试计划和测试策略向测试用例转化过程中的重要测试设计中间件。一个测试方案至少应该包括:特定测试场景需求分析和场景风险分析,并从中提取出测试需求,在测试方案中考虑如何通过哪些测试工具或测试技术,测试用例来覆盖到这些测试需求。有时在时间非常紧急的情况下,甚至可以直接利用测试方案来进行测试需求的验证。
一个好的测试方案能很好的回答项目经理这样一个问题:“测试用例到底覆盖了多少测试需求?每条测试需求在哪个用例被覆盖了。”
测试用例
测试用例不仅仅只有功能测试用例,还有性能测试用例,压力测试用例,安全性测试用例,XX可靠性测试用例。测试用例是测试计划,测试策略,测试方案一系统测试分析和设计活动落地实施的最小测试设计单位。它们将是测试项目进度管理和资源管理的最小计算单元。好的测试用例集设计能够很好的回答哪些测试需求被覆盖到了。但是测试用例的设计不可能是一次性的,一次性设计的测试用例只能是用于基本verification的用例。如果希望能发现系统潜在的更多的深入缺陷,需要对测试用例进行多次补充,依据探索性测试活动或是随机测试活动来补充testing 测试用例。关于什么是好的测试用例,在互联网上已有足够多的资源了,大家尽可到网上获取。但在这里我仍要特别强调测试用例的设计一定要考虑避免出现用例理解的二义性,提高用例学习的易用性,这些将是保障后续测试用例执行质量和测试执行进度的重要支撑。
测试报告