软件测试大神教你如何做好需求管理和用例设计逻辑映射（三）

目录

1. 测试用例设计的步骤

1.1 明确原始需求

1.2 拆分原始需求

1.3 梳理业务逻辑

1.4 划分测试类型

1.5 划分测试用例等级

1.6 选择测试方法

2.?测试用例设计的的原则

3. 测试用例设计注意事项

---

1. 测试用例设计的步骤

1.1 明确原始需求

?????? 原始需求是软件的使用者（客户）的需求，在需求文档基础+本质理解才能真正理清楚需求要实现什么样的目的，以此为出发点才能不偏离需求本质；

1.2 拆分原始需求

在需求测试阶段，如果按照需求测试策略对需求梳理一遍之后，对于所有的需求点应该都已经很清楚了，将这部分的需求点罗列出来，就可以作为需求粗的测试点；

1.3 梳理业务逻辑

在理解了业务逻辑后，补充对应需求点的业务逻辑测试点。

1.4 划分测试类型

一般来说，会通过如下类型进行考虑测试点：

1. 功能性
2. 兼容性
3. 易用性
4. 可靠性
5. 性能
6. 安全性

1.5 划分测试用例等级

在考虑好测试点之后，需要按照不同的测试深度，对测试用例进行等级的划分，测试用例分级将会为后面的分层测试、回归测试、验收测试和自动化测试在如何选择测试用例方面，带来莫大的方便。

1.6 选择测试方法

?????? 在输出测试点之后，按照第一章中描述的策略选择测试方法，设计对应的测试用例。

2.?测试用例设计的的原则

?????? 测试用例设计应遵循以下原则：

1. 全面性
   1. 测试用例中的测试点应保证只是覆盖需求规格说明书中的各项功能
   2. 应尽可能的覆盖系统的各个业务
   3. 应尽可能全面的考虑系统中的各功能或业务的异常情况
2. 正确性
   1. 用户输入的数据应与测试文档所积累的数据一致，预期结果应与测试数据发送的业务吻合
   2. 用户验证系统输入的实际数据应当满足需求规格说明书的需求
3. 可操作性
   1. 测试用例中应写清楚测试的操作步骤，不同的操作步骤对于的结果
4. 规范性
   1. 所有测试案例的编写要求规范，对于所有被测的功能点，应用程序均应该按照需求说明书和相关技术规范中的给定形式，在规定的边界值范围内使用相应的工具、资源或数据执行其功能
5. 符合正常业务的惯例
   1. 测试数据应符合用户实际工作业务流程
   2. 兼顾各种业务变化的可能
   3. 要符合当前业务行业规定
6. 连贯性
   1. 对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确
   2. 对于模块业务流程来说，统计模块以及上下级模块如何构成一个系统，其内部功能接口是否连贯
7. 容错性
   1. 程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理，尽量站在用户角度进行操作

3. 测试用例设计注意事项

?????? 测试用例的设计过程复杂而浩大，是一项耗时费力的工作，基于用例的重要性，我们必须认真耐心的完成。由于它的复杂性，设计测试用例时我们必须注意以下几点：

1. 设计测试用例时，用户经常使用、关系到系统核心功能、优先级别较高的功能点，测试用例应该达到100%的覆盖率。
2. 针对各个系统端到端的功能以及其他系统的接口的测试应该达到100%覆盖率。
3. 测试用例包括正常输入和正常业务流程测试，也包括对非法数据输入和异常处理的测试，且对系统非正常操作的测试用例占到总数的20%-30%。
4. 测试用例中应包括中文特性及系统本地化测试，如中午信息的显示、录入、查询、打印和报表显示测试等。
5. 功能测试用例设计首先考虑等价类划分、边界值共用，并用错误推测法补充；如果业务流程清晰可采用场景设计法；若程序有详细的因果关系，应该一开始就采用因果图法；如果是文件配置类型的测试，考虑功能图法；
6. 集成测试用例设计要点按照详细设计说明书来设计，测试用例数据来源于UC，内部逻辑结构分析按照单元测试进行；
7. 系统测试用例根据需求分析来建议软件是否满足功能，行为、性能、系统协调性等方面的要求。使用的数据应具有代表性，并与真实数据的大小和复杂性相当。
8. 验收测试用例设计应该在研发阶段测试用例基础上重新编写，而不能直接拿来使用。需要与客户需求项对应、面向客户，把握客户的关注度并适当展示软件的独特性。
9. 回归测试用例设计不需要重复设计，只需要选择以前的测试用例，针对最重要或最频繁使用的功能测试用例。