软件测试之测试用例，一篇足矣

一、介绍

测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。

二、基本格式

用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果等。

用例编号：编号有一定的规则，如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称+测试阶段类型（系统测试阶段）+编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

测试标题：对用例描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

重要级别：定义测试用例的优先级别，可以笼统的分为 四个不同的等级。
前置条件：

输入限制：提供测试执行中的各种输入条件。根据需求中的输入条件，确定输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

操作步骤：提供测试执行过程的步骤。对于复杂的用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

预期结果：提供测试执行的预期结果，预期结果应该根据需求说明书中的输出得出。如果在实际中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

同时，在这我也准备了一份软件测试视频教程（含接口、自动化、性能等），需要的可以直接在下方观看就行，希望对你有所帮助！【公众号：互联网杂货铺】

软件测试视频教程观看处：

软件测试工程师大忌！盲目自学软件测试真的会毁终生，能救一个是一个......

三、示例

四、测试用例设计方法

常见的有：等价类划分法、边界值分析法、错误推测法、流程分析法、判定表法、正交实验法。

等价类法：就是将测试的范围划分成几个互不相交的子集，他们的并集是全集，从每个子集选出几个有代表性的值作为测试用例。如：密码长度6-10位，则划分1-5位 、6-10位、10位以上三类。 

边界值法：软件大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。选出的测试用例，应选取正好等于、刚刚大于、刚刚小于边界的值，例如：成年人年龄假定 X 为整数, 18≤X≤100,那么 X 在测试中应该取的边界值为：17，18,19，99，100，101。

错误推测法：在测试时，根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。这方法没有固定的形式，依靠的是经验和直觉，有针对性地设计。只能作为一种补充。

流程分析法：又称为场景法，是根据不同的业务场景来编写测试用例，需要把所以可能产生分支的地方考虑到。流程分析主要包括三个流程：基本流、备选流、异常流。

基本流：也就是正向流程，通过业务流程输入都为正确的，能够最终达到目标的流程。如：经典的ATM机取款流程，插入银行卡—输入正确的密码—输入正确的金额-取钱-取卡。

备选流：通过实现业务流程时，因错误操作或异常输入，导致流程存在反复，但最终能够达到预期的操作流程，如：ATM机取款，插入银行卡—输入错误的密码—重新输入正确的密码—输入正确的金额-取钱-取卡。

异常流：实现业务流程时，因操作错误或异常输入，导致没有完成业务流程，如ATM机取款，插入银行卡—输入错误的密码3次—吞卡。

正交实验法：就是在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例。

状态迁移法：根据测试对象和测试数据之间的关系。测试对象的输出行为不仅仅和当前的输入数据有关，而且和测试对象当前的状态有关。状态迁移图是设计状态转换测试用例的基础，基于状态迁移图进行的测试就是状态迁移测试。例如：订单状态：未支付、超时取消、已取消、已支付、已收货、已完成等。步骤：画出状态迁移图、通过状态迁移图画出状态转换树、从状态转换树推导出测试路径、根据测试路径编写合法测试用例   

五、缺陷报告

报告内容：标题、描述（简洁、准确、完整、反映缺陷本质）、重现步骤、严重程度（致命、严重、一般、较小）、优先级（紧急、高、中和低）、截图、编号、缺陷状态、指派人、测试环境、版本、所属模块等。

编写测试报告要做到以下几点：

1、对错误的描述要做到简洁、准确、完整，揭示错误实质        

2、每个软件问题报告只书写一个缺陷或错误

3、明确指明错误类型和严重程度

4、每一个步骤尽量只记录一个完整操作

5、复现的操作步骤要完整，准确，简短

6、可以附加必要的错误特征图像

7、可以附加必要的测试用例

严重等级划分：

致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机等。

严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响。

一般：系统的次要功能没有完全实现，但不影响⽤户的正常使用。例如：提供信息不太准确或用户界⾯差、操作时间长等一些问题。

较⼩：是操作者不⽅便或遇到⿇烦，但它不影响功能的操作和执⾏，如个别不影响产品理解的错别字、⽂字排列不整齐等⼀些⼩问题。