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

发表于:2010-11-12 11:43

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

 作者:未知    来源:51Testing软件测试网采编

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

精彩评论

  • 盼盼2010
    2010-12-14 16:01:33

    非常好  语言简练又明确  受益匪浅啊

  • jlsxz
    2010-12-09 17:39:18

    学习了

  • 静之泪
    2010-11-29 11:16:20

    谢谢了大哥

  • lvyunxiadou
    2010-11-15 16:21:46

    很受启发。
    有个问题,步骤描述中是不是需要写类似实际系统的操作步骤呢?

关注51Testing

联系我们

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

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

沪ICP备05003035号

沪公网安备 31010102002173号