测试用例设计思路

Posted 2021-10-27 拜托拜托

职场新人对测试用例的困惑无非有以下几点：

1. 什么是测试用例，为什么要写测试用例？
2. 不知道怎么写，写了也不知道写的是否完整。

一、什么是测试用例？

百科的释义：

测试用例是对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。

其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。

简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

二、为什么要设计测试用例？

1、指导测试工作的进行

测试用例可以把产品需求转换为可操作的步骤【步骤、操作、输入、输出、优先级等】，

从而指导测试人员按部进行测试。

2、验证产品的需求是否合理

产品的逻辑关系会在用例设计时得到推敲验证，从而得出相应结论。

3、帮助评审需求，补充需求细节

编写测试用例时会考虑各种正常异常测试场景【逆向思维】、数据【边界值等】以及兼容性、性能等测试，

会对这些细节部分的处理进行一定的补充与完善。

4、加深测试人员对产品的认识和印象

需求评审时可能用两个小时，讲了一个需要两百个小时投入的需求。

大部分内容只是泛泛的讲解一遍，真整编写用例时，测试人员对需求一句一句的解读，从而转化成可执行的用例，这个阶段才是测试对需求认识更彻底的时刻。

5、便于测试负责人跟进测试进度

负责人根据用例的多少、复杂程度来评估相应的测试用例执行工时；以测试记录来评判测试过程的输出；从而跟进相应的测试进度与输出。

6、帮助发现拓展测试范围

用例设计是可以结合测试方法，从而拓展测试范围，不局限于双眼所看到的表面内容。

7、方便回归测试，复查BUG是否还会出现

回归测试时可以根据一轮测试的结果，重点复测出问题的用例以及功能，从而避免无序、无重点的回归测试。

8、测试结果可以体现测试通过率，作为产品质量评估

可以对测试结果进行统计，统计维度可以有：用例执行率、缺陷发现率、一轮测试通过率

9、培训新人，提高新人测试效率，节省对新人的指导时间

产品指导新人可以看PRD，开发指导新人可以看代码，测试指导新人看什么呢，当然是用例了。用例作为测试人员的核心输出，也是测试人员对产品知识的。

三、如何进行测试用例设计

测试用例设计分析是一个发散的过程，我们要考虑各种各样的场景、数据。

测试用例编写是一个收敛的过程，我们要把发散的思维转化为一条一条可执行的用例。

为了避免用例冗余、多、乱、无效、重复等问题，通常遵循以下原则进行用例设计。

从左到右，由上而下：

元素的布局，用户的操作，都是习惯“从左到右，由上而下”，设计用例时同样遵循这样的原则。

面对一个需求或一个全新的功能模块，在进行用例设计时，为了避免测试对象丢失，用例设计混乱无序，我们遵从“从左到右，由上而下”的原则。

依次对看到的测试对象进行用例设计，测试点发散，最终输出完整的测试用例。

按照上述原则编写的用例，覆盖所有可测对象，基本不会出现测试对象缺失，遗漏等现象。

但容易遗漏多测试对象组合的场景以及应用型测试场景。

从外到内，由点及面：

对于测试路径较深，链路较长的测试场景，我们遵循“从外到内”的设计思路，针对每一层测试路径上的对象，逐个进行设计。

再“由点及面”将路径整合，测试对象整合，以此来丰富场景型、应用型、组合型用例。

这样，遵循上述原则设计出来的用例，就包含了每一层级上的所有测试对象、每个路径上的所有测试对象、对象与对象的组合、路径与路径的组合，相对完善的覆盖了所有可测对象。

另外，再结合头脑风暴、用例评审等手段，不断促使用例的完整性与覆盖率达到相对较高的水平。

 

常见的编写测试用例的工具有Excel和Xmin，相应的模板，供参考：

 

 

 

 

 

集成测试用例设计思路

• 集成测试是介于白盒测试和黑盒测试之间的灰盒测试，因此在该测试的用例设计方法中会综合使用两类测试中的测试分析方法

• 为系统运行起来而设计用例

• 集成测试第一个需要关注的问题是接口能用并且不会阻塞后续的集成测试执行

• 可使用的测试分析技术

• 规范导出法

• 等价类划分

• 为正向测试而设计用例

• 假设过程是良好的，接口设计及模块功能设计需求是明确和无误的，那么集成测试的一个重点就是需要验证这些接口需求和集成后的模块功能需求被正确无误的满足了。基于这个原则，可以根据概要设计文档导出相关的用例

• 可使用的测试分析技术

• 规范导出法

• 输入域测试

• 输出域覆盖

• 等价类划分

• 状态转换测试

• 为逆向测试而设计用例

• 在集成测试中的逆向测试包括分析被测接口有没有实现规格没有要它实现的功能，规格中可能出现的接口遗漏或接口定义错误，分析可能出现的接口异常情况，包括接口数据本身的错误，接口数据顺序错误等。

• 对于面向对象系统和基于有限状态机的系统还需要考虑可能出现的状态异常，包括丢失的或不正确的状态转换；一个有效的消息被忽略；不可预测的行为；一个可能的潜行路径；一个不期望的消息引起的失败；接受没有定义的消息等；

• 可使用的测试分析技术

• 错误猜测法

• 基于风险的测试

• 基于故障的测试

• 边界值分析

• 特殊值测试

• 状态转换测试

• 为满足特殊需求而设计用例

• 以前的观点中，类似安全性测试，性能测试，可靠性测试等主要在系统测试阶段进行，但是目前通过在软件设计过程中细化了这些特殊的需求，一些产品开始在模块设计文档中就明确了接口的安全性指标、性能指标等，这种情况下应尽早开展接口相对于这些特殊需求的测试，以便最终保证系统整体特殊需求的满足。

• 可使用的测试分析技术

• 规范导出法

• 为高覆盖设计用例

• 不同于单元测试，在集成测试中最关注的覆盖是功能覆盖和接口覆盖。通过分析集成后模块的哪些功能没有被测试到，哪些接口没有被覆盖（尤其对于消息接口，所有可能的正常消息，异常消息都应当被验证）来设计测试用例

• 可使用的测试分析技术

• 功能覆盖分析

• 接口覆盖分析

• 测试用例补充

• 不可能在一开始就完全完成所有集成测试用例的设计，由于随着可能的功能增加，特性修改，缺陷修改等原因，还需要在集成测试的执行阶段不断更新和补充集成测试用例

• 注意事项

• 测试重点要突出，关键的接口必须被覆盖到，同时用例设计要考虑充分的可回归性和执行的自动化