测试用例设计
测试用例目前没有经典的定义，比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。随着中国软件业的日益壮大和逐步走向成熟，软件测试也在不断发展。其中，测试用例的设计和编制是软件测试活动中重要的，它是测试工作的指导，是软件测试必须遵守的准则，更是软件测试质量稳定的根本保障。
1、测试用例设计原则
设计测试用例时，应遵循以下原则：
1）基于测试需求的原则。应按照测试类别的不同要求设计测试用例。例如，单元测试依据详细设计说明，集成测试依据概要设计说明，配置项测试依据软件需求规格说明，系统测试依据用户需求（系统/子系统设计说明、软件开发计划等）。
2）基于测试方法的原则。应明确所采用的测试用例设计方法，为达到不同的测试充分性要求，应采用相应的测试方法，如等价类划分、边界值分析、猜错法、因果图等。
3） 兼顾测试充分性和效率的原则。测试用例集应兼顾测试的充分性和测试的效率；每个测试用例的内容也应完整，具有可操作性。
4）测试执行的可再现性原则。应保证测试用例执行的可再现性。
2、测试用例要素
每个测试用例应包括以下要素：
1）名称和标识。每个测试用例应有的名称和标识符。
2）测试追踪。说明测试所依据的内容来源，如系统测试依据的是用户需求，配置项测试依据的是软件需求，集成测试和单元测试依据的是软件设计。
3）用例说明。简要描述测试的对象、目的和所采用的测试方法。
4）测试的初始化要求。应考虑下述初始化要求：
● 硬件配置。被测系统的硬件配置情况，包括硬件条件或电气状态。
● 软件配置。被测系统的软件配置情况，包括测试的初始条件。
● 测试配置。测试系统的配置情况，如用于测试的模拟系统和测试工具等的配置情况。
● 参数设置。测试开始前的设置，如标志、第一断点、指针、控制参数和初始化数据等的设置。
● 其他对于测试用例的特殊说明。
5）测试的输入。在测试用例执行中发送给被测对象的所有测试命令、数据和信号等。对于每个测试用例应提供如下内容：
● 每个测试输入的具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）。
● 测试输入的来源（例如，测试程序产生、磁盘文件、通过网络接受、人工键盘输入等），以及选择输入所使用的方法（例如，等价类划分、边界值分析、差错推测、因果图、功能图等）。
● 测试输入是真实的还是模拟的。
● 测试输入的时间顺序或事件顺序。
6）期望的测试结果。说明测试用例执行中由被测软件所产生期望的测试结果，即经过验证认为正确的结果。必要时，应提供中间的期望结果。期望测试结果应该有具体内容，如确定的数值、状态或信号等，不应是不确切的概念或笼统的描述。
7）评价测试结果的准则。判断测试用例执行中产生的中间和后结果是否正确的准则。对于每个测试结果，应根据不同情况提供如下信息：
● 实际测试结果所需的精度。
● 实际测试结果与期望结果之间的差异允许的上限、下限。
● 时间的大和小间隔，或事件数目的大和小值。
● 实际测试结果不确定时，再测试的条件。
● 与产生测试结果有关的出错处理。
● 上面没有提及的其他准则。
8）操作过程。实施测试用例的执行步骤。把测试的操作过程定义为一系列按照执行顺序排列的相对独立的步骤，对于每个操作应提供：
● 每一步所需的测试操作动作、测试程序的输入、设备操作等。
● 每一步期望的测试结果。
● 每一步的评价准则。
● 程序终止伴随的动作或差错指示。
● 获取和分析实际测试结果的过程。
9）前提和约束。在测试用例说明中施加的所有前提条件和约束条件，如果有特别限制、参数偏差或异常处理，应该标识出来，并要说明它们对测试用例的影响。
10）测试终止条件。说明测试正常终止和异常终止的条件。
3、测试用例的设计步骤
设计测试用例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。测试用例设计一般包括以下几个步骤：
1）测试需求分析从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。
测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。
2）业务流程分析软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。为了不遗漏测试点，需要清楚地了解软件产品的业务流程。建议在做复杂的测试用例设计前，先画出软件的业务流程。如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，终画出业务流程图。业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。
从业务流程上，应得到以下信息：主流程是什么，条件备选流程是什么，数据流向是什么，以及关键的判断条件是什么。
3）测试用例设计完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试、边界测试、异常测试、性能测试、压力测试等。在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。
“黑盒”测试的测试用例设计方法有?? 等价类划分、边界值划分、因果图分析和错误猜测，“白盒”测试的测试用例设计方法有?? 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。在这里主要讨论“黑盒”测试。在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：
① 功能测试：测试某个功能是否满足需求的定义，功能是否正确，完备。
适合的技术：由业务需求和设计说明导出的功能测试、等价类划分。
② 边界测试：对某个功能的边界情况进行测试。
适合的技术：边界值划分。
③ 异常测试：对于某些功能来说，其边界情况无法简单地了解或某些操作不完全是正确的但又是可能发生的，类似这样的情况需要书写相关的异常测试。
适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试。
④ 性能测试：检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。
适合的技术：业务需求和设计说明导出的测试。
⑤ 压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说一个相当大的负荷或网络流量进行应用软件兼容测试，测试软件产品在不同的平台、不同的工具、相同工具的不同版本下功能的兼容性。
4）测试用例评审测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。
测试用例评审一般是由测试主管安排，参加的人员包括：测试用例设计者、测试主管、项目经理、开发工程师、其他相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。
5）测试用例更新完善测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。测试用例是“活” 的，在软件的生命周期中不断更新与完善。
