有效的软件测试----50种途径改进你的测试
上一篇 / 下一篇 2006-12-15 15:39:27 / 个人分类：有效的软件测试
今天读了一下Elfriede Dustin的<<Effective Software Testing:50 specific ways to improve you testing>>,现在把我的感受写在这里,供大家学习,错误的地方还请大家多多指正啊!谢谢大家提出批评!
请勿转载,谢谢合作!
有效的软件测试----50种途径改进你的测试
第一部分 需求阶段
最有效的测试开始于一个项目的开始阶段,也就是在编程的很早之前就开始做测试.需求分析第一次验证的时候,这样,在以后的项目阶段中,测试可以专注于保证程序代码的质量.在软件生命周期中,昂贵的成本可以通过与减少需求阶段的错误达到最小化,更优于详细设计和代码书写的时候发现问题.
需求说明文档对一个软件项目或者系统来说,描述其功能基本上是越详细越好.与需求的提供者之间的沟通是在需求开发阶段的最大的风险之一,需求说明文档应当把信息陈述的准确和清楚,让每一位读者都能够从同一个角度来理解.
如果需求达到一致性的程度,那就是在需求开发阶段,要尽可能的使风险承担者有效的参与需求的开发和收集.尽量使需求说明文档可视化,可以通过对风险承担者进行详细的提问来验证和阐明需求的细节.各种不同的需求测试在应用中应该保证每个细节都是相关的,而且每一个人都能理解它所阐述的意思.
第一种 在最开始阶段就确保测试人员的参与
在软件生命周期的开始阶段,测试人员就应该参与,这样可以使他们更准确的理解他们要测试的产品,可以帮助风险承担者开发出可以验证的需求说明文档.
在缺陷还没有渗透到开发的后期阶段中的时候,缺陷预测是一个常用的技术和方法来帮助我们发现和避免错误,在需求阶段,缺陷预测是最有效的,解决需求变更中的缺陷带来的影响和成本是最低的:仅仅是对需求说明文档进行修改或者可能修改测试计划.如果测试人员或者风险承担者在软件开发周期的早期阶段就参与进来,他们可以有助于发现或识别出遗漏的,矛盾的和模糊不清的地方等等,可以影响需求说明文档的可测性,正确性和其它品质.
如果一个程序或者方法的设计可能是它的功能的执行能够被测试,预期结果是可以预料,输出结果是可见的或者可验证的,那么这个需求设计的就是可测试的.
测试人员应该真实的理解需求说明文档,这样他可以更好的设计出测试计划,设计,流程和用例.在项目生命周期中,测试部门的早期参与可以减少对功能的使用的困惑.另外,早期的参与可以使测试人员获得软件的更多的方面的内容,包括对最终用户哪些是最主要的方面或者哪些地方是高风险的.这些知识应该让测试人员更早的知道,测试人员应该专注于软件的哪些方面,避免重复测试很少使用的地方或者很少测试最常用的地方.
有些测试组织认为测试人员仅仅是需求或其它软件开发工作的产品的使用者,要求他们在软件已经开发完成并交付给测试人员后去学习软件的需求和相应的领域知识,而不是在软件开发的早期阶段就让测试人员参与进来.这种做法在小型项目中也许可行,但是是大型的复杂的项目中,如果他们交付给测试人员的软件是在已经通过需求,分析,设计和其它一些软件实施后的,再去期待测试人员去发现重大的错误,这是很不现实的.拿软件的输入输出作为例子,测试人员需要更深入的知识,这些知识仅仅是通过在对使用功能说明书的过程中,运用思维能力对其的理解.这种理解不仅可以增强测试流程的的质量和深度,而且可以为测试人员提供关于需求的反馈信息.
在软件生命周期的早期发现的缺陷,修复的成本也就很低.下表可以显示出在不同阶段发现缺陷时修复的相应成本.
阶段 | 修正的相应成本 |
定义 | ￥1 |
需求设计 | ￥2 |
详细设计 | ￥5 |
编码 | ￥10 |
￥15 | |
集成测试 | ￥22 |
系统测试 | ￥50 |
交付用户使用后 | ￥100+ |
第二种 需求验证
亚历山大·克里斯多夫使用质量度量来描述需求说明:”对每一个需求说明来说都是可以用质量度量的,尽可能的把对需求的所有解决方法分成两类:一类是我们认同的内容是否符合需求,另一类是我们认同的内容是否不符合需求.换句话说就是:如果一个需求的质量度量确定后,任何的解决方法满足这个度量它就是可接受的,任何的解决方法不能满足这个度量它就是不可接受的.质量度量是常常用来对新系统的需求进行测试的.
努力去定义高水平的质量度量有助于使模糊不清的需求合理化.例如:每个人都同意类似”系统必须提供优秀的质量”,但是每个人对优秀的质量都有不同的理解.对于范围的设计就必须使用优秀的质量作为度量,那就必须去识别术语的真正意义.通常就需要风险承担者去考虑对需求定义一个大家都满意的质量度量.另一种情况是没有人同意这个需求的质量度量,那就是与其一个需求存在多个模棱两可的质量度量,不如每一个需求拥有一个属于自己质量度量.
一个基本的指导方针是在项目的早期就定义需求的开发和文档.但是在小型项目中,细心的设计需要系统的合理开发做保证.用例是需求说明书中功能文档化的一种方法,可以指导整个系统的设计和测试的流程.
在早期阶段,不仅要关注功能性的需求,非功能性的需求也是很重要的,像性能,安全等方面:它们可以确定技术的选择和风险的区域.非功能性的需求不是授予系统任何明确的功能,更不是去限制或进一步的定义系统已经给定功能的运行.功能性的需求应当和其相关的非功能性的需求相一致.
下面的清单列出了测试人员在需求阶段对进行验证需求的质量的一些事项.使用这个清单的第一步是尽可能的早的去捕捉与需求有关的缺陷,使这些缺陷在开发的后期阶段才被发现,那时候再去发现这些缺陷会更难,成本会更高.所有的风险承担者都应该对需求的可验证性负责,需求包括下面这些特性:
正确性:需求的正确性主要依据客户需要的是什么,例如:规章制度制定的正确与否?需求量是否准确的反映客户的要求?在需求阶段,软件的最终用户或者其它合适人员必须参与.正确性也可以依据标准来判断.标准是否执行?
完整性:保证了需求中没有遗漏一些必须的元素.目标是没有遗漏简单的需求,没有人会去问一些正确的问题或者检查相关的源文档.
测试人员应该坚持每一个功能性的需求是否都有相关的非功能性的需求,包括:性能,安全,易用性,兼容性和易接触.创建文档时非功能性需求通常使用下面二步:
1. 一个系统性的说明书是通过定义应用于系统的一些非功能性需求来创建的.例如:一个Web系统的用户使用界面必须Netscape Navigator 4.x和Microsoft Internet Explorer 4.x或者更高版本相一致.
2. 每一个功能性需求模块都应该包含标题为非功能性需求的段落,证明每一个指定的非功能的需求都需要一个远离系统的非功能性需求说明书的必要条件.
一致性:验证的是在软件产品中或软件产品之间的各个模块没有内部或者外部的冲突.我们可以问:我们的说明书中所定义的所有基本的子事务的术语是否可用在这个说明书中?我们可以确定需求中的元素是否定义的清楚和准确.例如:我们在需求说明书中在很多地方使用词语”观众”,在不同的语境中表达不同的意思,在后期的设计和实现阶段会不会引起争议.没有一个清晰和一致的定义,决定需求是否定义正确就成了一个个人观点的事情了.
可测试性(可验证性):需求的可测试性就是能不能使用这个需求来产生测试,预期结果是可知的,可以列举的和真实的可验证的.如果一个需求不能够经得住测试或验证,那么,要达到可测试性,事实上就要需求的风险必须是一定的,如果可能的话需求也是经过修改调整过的.
可行性:在给定的预算,时间,技术和其它可用的资源下,需求能够保证顺利执行.
必要性:对于系统而言,需求说明书中要求的每一项都是必需的.适当的和必要的测试是测试人员检查需求说明书中的是否和项目的目标相一致.这个需求能否达到项目的目标?缺少这些需求是否阻碍项目达到目标?其它的需求是否依赖这个需求?找出解决方案来解决一些不相关的需求是不是就不需要了.
优先性:允许每一个人了解风险承担者的需求的相对价值. Pardee建议使用1到5来指定收获和损失的标准,即需求的优秀的部分带来的收获和差的部分带来的损失.如果一个需求对于系统来说是非常重要的,它的收获和损失分别为5.拥有另一个需求时是很不错的和缺少这个需求也不是很严重,那么它的收获和损失分别是3和1.收获和损失的总分为10,平均为4.在系统将要进行设计的时候可以用这个标准来制定优先级或来平衡决定.这个方法可以去权衡一个用户的观点,他们会对成本的技术风险提出需求的人.
明确性:保证需求说明书的制定使用准确的和可度量的方法.下面是一个模棱两可的需求:系统必须对客户的询问做出迅速的反应.这个”迅速的”天生就是一个模棱两可和主观的词语,因此导致需求是不可测试的.客户也许认为5秒钟是迅速的,开发人员也许认为是在3分钟内是迅速的.相反,开发人员也许认为是在2秒钟内,而系统工程师却认为系统无法达到这样的性能要求.
可追溯性:确保每一个需求都能识别出与它所使用的和相关联的系统所有部分.对于需求的任何改动,它都能识别出它所影响的系统中的其它部分.
根据这点,每一个需求都应被定义为独立的可识别的和可度量的实体.理解各个需求之间的相互影响必须能够认识到需求内部之间的关联.这必须要有一个方法来处理规模庞大的需求和它们之间复杂的关联. Suzanne Robertson的建议是与其试图要同时处理每件事情,还不如把需求分成可以管理的模块.这就产生一个问题是将需求指派给子系统或者基于优先级的后续版本.如果把这样做的话,需求的关联要分成两部分了:第一个是组内部需求之间的关联,第二个是组与组之间需求的关联.如果需求使用这种方法分组后,组之间的关联会减小的,并且需求之间关联的跟踪的复杂度也会减小的.
可跟踪性能够收集关于单独的需求和受到需求变更影响的系统的其它部分,
TAG: 有效的软件测试
