软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果,下面逐一介
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件测试经过几十年的发展,测试界提出了很多软件测试的基本原则,为测试管理人员和测试人员提供了测试指南。软件测试原则非常重要,测试人员应该在测试原则指导下进行测试活动。
软件测试的基本原则有助于测试人员进行高质量的测试,尽早尽可能多的发现缺陷,并负责跟踪和分析软件中的问题,对存在的问题和不足提出质疑和改进,从而持续改进测试过程。
原则1: 测试显示缺陷的存在
测试可以显示缺陷的存在,但不能证明系统不存在缺陷。测试可以减少软件中存在缺陷的可能性,但即使测试没有发现任何缺陷,也不能证明软件或系统是完全正确的,或者说是不存在缺陷的。
原则2: 穷尽测试是不可能的
穷尽测试是不可能的,当满足一定的测试出口准则时测试就应当终止。考虑到所有可能输入值和它们的组合,以及结合所有不同的测试前置条件,这是一个天文数字,我们没有可能进行穷尽测试。在实际测试过程中,测试人员无法执行“天文”数字的测试用例。所以说,每个测试都只是抽样测试。因此,必须根据测试的风险和优先级,控制测试工作量,在测试成本、收益和风险之间求得平衡。
原则3: 测试的尽早介入
根据统计表明,在软件开发生命周期早期引入的错误占软件过程中出现所有错误(包括最终的缺陷)数量的50%~60%。此外,IBM的一份研究结果表明,缺陷存在放大趋势。如需求阶段的一个错误可能会导致N个设计错误,因此,越是测试后期,为修复缺陷所付出的代价就会越大。因此,软件测试人员要尽早地且不断地进行软件测试,以提高软件质量,降低软件开发成本。
原则4: 缺陷的集群性
Pareto原则表明“80%的错误集中在20%的程序模块中”。实际经验也证明了这一点,通常情况下,大多数的缺陷只是存在测试对象的极小部分。缺陷并不是平均而是集群分布的。因此,如果在一个地方发现了很多缺陷,那么通常在这个模块中可以发现更多的缺陷。因此,测试过程中要充分注意错误集群现象,对发现错误较多的程序段或者软件模块,应进行反复的深入的测试。
原则5: 杀虫剂悖论
杀虫剂用得多了,害虫就有免疫力,杀虫剂就发挥不了效力。在测试中,同样的测试用例被一遍一遍反复使用时,发现缺陷的能力就会越来越差。这种现象的主要原因在于测试人员没有及时更新测试用例,同时对测试用例及测试对象过于熟悉,形成思维定势。
为克服这种现象,测试用例需要经常的评审和修改,不断增加新的不同的测试用例来测试软件或系统的不同部分,保证测试用例永远是最新的,即包含着最后一次程序代码或说明文档的更新信息。这样软件
中未被测试过的部分或者先前没有被使用过的输入组合就会重新执行,从而发现更多的缺陷。同时,作为专业的测试人员,要具有探索性思维和逆向思维,而不仅仅是做输出与期望结果的比较。
原则6: 测试活动依赖于测试内容
项目测试相关的活动依赖于测试对象的内容。对于每个软件系统,比如测试策略、测试技术、测试工具、测试阶段以及测试出口准则等等的选择,都是不一样的。同时,测试活动必须与应用程序的运行环境和使用中可能存在的风险相关联。因此,没有两个系统可以以完全相同的方式进行测试。比如,对关注安全的电子商务系统进行测试,与一般的商业软件测试的重点是不一样的,它更多关注的是安全测试和性能测试。
原则7: 没有失效不代表系统是可用的
系统的质量特征不仅仅是功能性要求,还包括了很多其他方面的要求比如稳定性、可用性、兼容性等等。假如系统无法使用,或者系统不能完成客户的需求和期望,那么,这个系统的研发是失败。同时在系统中发现和修改缺陷也是没有任何意义的。
在开发过程中用户的早期介入和接触原型系统就是为了避免这类问题的预防性措施。有时候,可能产品的测试结果非常完美,可最终的客户并不买帐。因为,这个开发角度完美的产品可能并不是客户真正想要的产品。