欢迎光临
梦想从学习开始!

功能测试测试用例设计与编写原则| 小熊测试

本文主要介绍 功能测试测试用例设计与编写原则| 小熊测试,小熊希望对大家的学习或者工作具有一定的参考学习价值,在测试领域有所提升和发展。

  测试种类繁多,针对不同类型的测试,测试用例的设计方式完全不同。如:性能测试的测试用例中,需设计大量的测试运行场景,准备相应的性能指标表格供测试人员填写,并进行数据分析。

  本章着重探讨的是功能测试中使用的测试用例,为避免混淆,方便叙述,后续未说明的测试用例均指功能测试的测试用例,有特殊需要之处将进行特别说明。

  如前文所述,测试用例是测试人员执行测试时的重要参照标准。因此,测试用例必需使测试人员能够明确理解,并能够依据测试用例的描述执行测试。为此,一个设计良好的测试用例应当包括如下几个关键字段:

  1.用例编号(testcaseIndex),一个软件项目可能拥有数量庞大的测试用例。应根据项目设计一个良好的用例编号体系,那么通过用例编号,便可对测试用例进行快速定位,查询时事半功倍。

  2.用例名称(testCaseName),用例名称的编写应使用最精简的文字,描绘出用例的全貌。编写良好的用例名称如同书籍的目录,能够帮助阅读者整理思路,定位用例。

  3.前置条件(precondition),复杂工作流软件自动化测试方法的研究第二章软件测试理论与技术基础前置条件指测试执行者在执行测试用例的操作步骤前,必须完成的准备工作。常见的前置条件有:系统的配置、权限的设置、数据的准备、前置工序的执行等。

  4.测试步骤 (Teststep),测试用例中,每个操作均可设计为一个步骤。一个测试用例由一个或多个测试步骤组成。常见可将测试步骤分为正常步骤和容错步骤。正常步骤指普通用户为了实现正常功能,进行的普遍的、正确的、系统期待的操作。正常步骤描述的操作通常在需求文档中会有明确的说明,也是程序需要实现的主要功能。

  容错步骤指用户有意或无意进行的一些错误的、甚至于有破坏性的操作。对此类错误操作,系统应有足够的容忍性,进行一些友好的提示、阻止或处理,而不是产生异常。

  需求文档中,通常会对正常步骤进行明确定义。因此,正常步骤是严谨的,甚至是唯一的,编写者的发挥空间非常狭小。容错流程恰恰相反。一个思维活跃、经验丰富的测试人员在编写容错步骤时,能够考虑到各类不同的容错步骤,其编写出的测试用例也是全面、广泛而又犀利的。容错流程的编写深度与广度能够很好的反映编写者的技术实力。

  综上,一个编写良好的测试用例中应该包括两部分内容:描述准确的正常步骤,以及广泛深入的容错步骤。

  5.步骤描述(Deseription),步骤描述是测试步骤的主体,是测试人员执行测试时的重要阅读对象。因此,测试步骤必须表述详细,描述清晰,用语必须规范、严谨而又客观。最基本的要求是能够使其他人理解,并能正确的执行编写者期望的操作。

  6.期望结果(〔 xpeetedRes川ts),期望结果是执行测试时,测试者所进行比对的标尺,是一个测试步骤是否通过的标准答案。期望结果必须要保证其正确性。错误的期望结果带来的后果是严重的,不在此赘述。

  7.实际结果 (ActualResultS)实际结果供测试人员在运行测试时填写观察到的实际结果。填写的内容同样需做到规范、严谨与客观。

  8.测试结论 (TestResult)与实际结果类似,测试结论供测试人员运行测试时填写。若实际结果与期望结果两者一致,或虽然不一致,但在可接受范围内,则可以认为该步骤是通过的,测试结论应置为passed;若两者不一致,且无法接受,则应将结果置为Failed。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小熊分享邦(www.xxfxb.com),希望大家能坚持软件测试之路,谢谢。

赞(0) 打赏
未经允许不得转载:小熊分享邦 » 功能测试测试用例设计与编写原则| 小熊测试

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏