如何编写测试用例及测试用例的编写方法

如何编写测试用例及测试用例的编写方法        软件测试

如何编写测试用例

测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。
　　一、测试用例是软件测试的核心
　　软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
　　影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。
　　因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。
　　二、什么叫测试用例
　　测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
　　不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
　　三、编制测试用例
　　着重介绍一些编制测试用例的具体做法。
　　1、测试用例文档
　　编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
　　软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。
　　测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。
　　2、测试用例的设置
　　我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。
　　按功能测试是最简捷的，按用例规约遍历测试每一功能。
　　对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。
　　但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。
　　3、设计测试用例
　　测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
　　设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。
　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

测试用例的编写方法

首先声明这不是我写的，我只是看到了感觉不错就贴出来，希望对其他人有所帮助。向原作者表示致敬。

试用例的编写，

对于每一个Tester来说都是不可避免的，平时很一部分的工作内容就是编写测试用例，如何写一个好的用例呢？如果你的

用例只是用于ISO的审核，那没必要再这里探讨这个问题。好的Case，是Tester的劳动成果，它应该是充满智慧的，具有

可复用性，启发性，能充分体现一个Tester的水平。很多人的Case虽然写的很不错，可惜只有他自己才能看懂其中的内

容和体会Case的意思，为什么？因为它写的Case描述不清楚，只有他自己看了才明白，一个好的Case必须有良好的书

写格式与习惯，能让所有看的人都能理解，也就是说，当你离开这个项目，其他人来接受你的工作时，只要看你的Case

就能明白项目的目标与需求。如果做到这一点呢？     第一步，我想应该是Case格式的确立，拥有好的，清晰的格式，有

利于帮助Tester来组织他的Case，会让你事半功倍，反之亦然，一个结构不合理的格式，会让你觉得蹩手蹩脚，影响你

的发挥。如果选择一个良好的结构，要根据具体工作的情况，项目的结构，以及用例的目标（功能测试用例，性能测试用

例以及其他）我认为不同的测试手段要使用不同的用例结构。确定好这些因素后，在来谈谈测试用例中涉及到的一些东

西，理解Case所需要的东西，我认为这些东西是比不可少的，1：软件版本编号。2：测试用例编号，编号的格式可根据

软件版本号+用例号来确定，这样不会应为Case的日积越累或软件版本的不停升级而混乱。3：用例的优先级，在一个时

间紧凑的测试环境下，为了跟效率的完成测试用例，我们所能做的是完成那些优先级高的用例，至于优先级如何来确定，

可以根据项目需求，或者用户那边的需求来确定，也可以根据实际经验对那些很容易产生缺陷的模块设置为高优先级。

4：用例步骤。5：输入数据。 6：实际输出数据。7：期望输出数据。某个步骤下，输入了某条数据，你期望程序会输出

什么数据。可以一来可以与实际输出的数据相比较。8：备注。为什么要备注，可能你在思考这个Case的时候有一个好的

点子或者思路，可以写在备注里面。或者对这个用例还有一些必要的补充说明等。9：测试环境。10：用例编写人/日期。

11：测试执行者/日期。可能根据不同的项目还需要一些补充，可以根据具体情况具体分析。   第二步。设计测试用例，通

常情况下在你编写测试用例之前，你必须要有一个测试计划，这里我只讨论测试用例。嗯，开始设计之前还有一些准备工

作，必须熟读软件需求说明，一定要清晰的了解每一条需求，明白软件的性能指标，综合考虑测试环境，人员配置，要根

据自己的实际能力，测试工具使用状况写出符合自己测试团队的用例。用例的划分有很多种方法，根据测试的类型，比如

功能性测试，你可以按照功能模块划分用例，划分科学的模块你可以组织这些用例直接进行集成测试，组合部分模块或者

所有模块来测试。性能测试，可以根据性能指标来确定用例划分，对于用例环境的不同来划分用例等等。也可以根据测试

工具在组织测试用例，比如那些Case可以在测试工具上完成，那些需要手动去完成，划分的方法很多，但是有一点必须

保证，就是测试覆盖率，是否覆盖了所有的需求。写好一个用例，需要工作经验的积累，需要对项目需求的了解，我觉得

Tester应该是公司里最了解软件需求与功能的人。测试的技术很多，可以在Case中体现出来，比如说边界值测试，溢出

测试，等价类划分测试法，等等。按照这些来编写你的Case也可以提高你的技能。   第二步。审核你的Test Case，怎么

样才能完美你的Case呢？最好的办法就是进行同行评审，也就是让你的同事来看你的Case，同时与开发部门负责人进行

沟通，讨论你的Case。进行这两步后可能要对你的Case进行一些修改。但并不是这样一个好的Case就产生了，在执行

测试用例的过程中，你可能还会发现很多问题，这也是一个Case的完善过程。对于从一个项目中成长起来的Tester，会

随着对项目的不停理解与思考而随时修改自己的Case，我是这样理解的。

原文转自：http://www.ltesting.net