测试用例怎么测试

测试用例的测试方法有：1、手工测试；2、自动化测试；3、白盒测试；4、黑盒测试。手工测试是指测试人员无需使用任何自动化工具即可手动执行测试用例，自动化测试是指使用自动化测试工具记录该测试套件并根据需要重复执行。

一、测试用例的测试方法

1、手工测试

手工测试是一种软件测试的类型，其中测试人员无需使用任何自动化工具即可手动执行测试用例。手工测试的目的是识别软件应用程序中的错误、问题和缺陷。手工软件测试是所有测试类型中最原始的技术，它有助于发现软件应用程序中的关键缺陷。任何新应用程序都必须先进行手工测试，然后才能使其测试自动化。手工软件测试需要更多的精力，但对于检查自动化的可行性是必需的。手工测试概念不需要任何测试工具的知识。软件测试基础之一是“不可能实现100％自动化”，这使得手工测试势在必行。

2、自动化测试

自动化测试是一种软件测试技术，它使用自动化测试工具来执行测试用例套件。自动化测试软件还可以将测试数据输入被测系统，比较预期结果和实际结果，并生成详细的测试报告。软件测试自动化需要大量的金钱和资源投资。连续的开发周期将需要重复执行相同的测试套件。使用测试自动化工具，可以记录该测试套件并根据需要重复执行。一旦测试套件自动化，就无需人工干预。这提高了测试自动化的投资回报率。自动化的目标是减少手动运行的测试用例的次数，而不是完全消除手动测试。

3、白盒测试

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

4、黑盒测试

黑盒测试也称功能测试，黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。

二、编制测试用例的具体做法

1、测试用例文档

编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：版本号、模块名称、用例编号、用例名称、用例级别、预知条件、验证步骤、期望结果（含判断标准）、测试结果、测试时间、测试人员等。

2、测试用例的设置

我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。演变为按功能、路径混合模式设置用例。按功能测试是最简捷的，按用例规约遍历测试每一功能。对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

3、设计测试用例

测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。可以采用软件测试常用的方法：

• 等价类划分法
• 边界值分析法
• 错误推测法
• 因果图法
• 逻辑覆盖法

视软件的不同性质采用不同的方法。如何灵活运用各种基该方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

三、测试用例设计原则

测试用例是一个文档，是执行的最小实体。测试用例包括输入、动作、时间和一个期望的结果，其目的是确定应用程序的某个特性是否可正常工作，并且达到程序所设计的结果，以便测试某个程序路径或核实是否满足某个特定需求般在进行测试用例设计前要全面了解被测试产品的功能、明确测试范围（特别是要明确哪些是不需要测试的）、具备基本的测试技术与方法等。测试用例设计一般遵循以下原则：

1. 正确性：输入用户实际数据以验证系统是否满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2. 全面性：覆盖所有的需求功能项；设计的用例除对测试点本身的测试外，还需考虑用户实际使用的情况、与其他部分关联使用的情况、非正常情况（不合理、非法、越界以及极限输入数据）操作和环境设置等。
3. 连贯性：用例组织有条理、主次分明，尤其体现在业务测试用例上；用例执行粒度尽量保持每个用例都有测点，不能同时覆盖很多功能点，否则执行起来牵连太大，所以每个用例间保持连贯性很重要。
4. 可判定性：测试执行结果的正确性是可判定的，每一个测试用例都有相应的期望结果。
5. 可操作性：测试用例中要写清楚测试的操作步骤，以及与不同的操作步骤相对应的测试结果。

延伸阅读

撰写测试用例前置条件的流程

• 说明测试环境
• 配置测试数据
• 准备测试设备
• 设置先决条件
• 构建测试环境