功能测试设计框架

测试用例的编写需要按照一定的思路进行，而不是想到哪写到哪，一般测试机制成熟的公司都会有公司自己自定义的测试用例模板，以及一整套的测试流程关注点，当然我们自己在测试生涯中也应当积累一套自己的测试框架，所有功能性的测试都可以依据框架的思路来进行，达到事半功倍的效果。

功能测试设计框架 = 业务逻辑（功能需求） + 软件产品质量 + 真实的用户使用场景

 

1）业务逻辑

即覆盖需求文档中的所有业务逻辑内容，所见即所得的思想：

1. 所有的需求文档描述的文字信息，转化为用例。
2. 所有的示意图、流程图、状态图等信息，直接转化为测试用例。
3. 所有项目需求达成的口头共识，需求确认的邮件沟通信息，直接转化为测试用例。

 

2）软件产品质量

• 可用性/易用性/用户体验：评估最终用户在使用软件并与软件交互时的可用性问题。
• 容错性/健壮性：用于测试系统在出现故障时，是否能够自动恢复或忽略故障继续运行。
• 安全性：避免出现SQL注入、XSS、泄密等相关安全风险。
• 性能：评估程序在不同并发用户数和不同数据量下的响应时间以及吞吐率/量。
• 可维护性：评估系统是否拥有良好的数据处理和日志机制，以备技术支持和调试之需。
• 可扩展性：解耦、参数配置或代码写死。
• 兼容性：不同的硬件、软件（操作系统、浏览器）等。
• 可靠性：是否能达到规格说明中的运行时常和 MTBF（平均无故障工作时间），避免影响用户的本身业务（内容、过程）。
• ...

软件产品质量——功能测试用例设计框架：

https://www.processon.com/view/link/610932b21e0853337b18d5f4

 

3）用户使用场景

业务流程，一般会涉及到多个模块的数据，所以在对业务流程测试时，首先要保证单个模块功能的正确性，其次就要对各个模块间传递的数据进行测试，这往往是容易出现问题的地方，测试时一定要设计不同的场景进行测试。

案例：如某一功能模块具有最基本的增删改查功能

测试思路：

1. 单项功能测试（如增删改查）

2. 多项功能的组合操作测试

测试方法（步骤测试法）：

1. 取消步骤
2. 插入步骤
   • 增加——>删除——>增加 （新增加的内容与删除内容一致）
   • 修改——>增加（新增加的内容与修改前内容一致）
   • 修改——>删除——>增加 （新增加的内容与删除内容一致）
3. 删除步骤
4. 替换步骤
5. 重复步骤
   • 增加——>增加——>增加 （连续增加测试）
   • 修改——>修改——>修改 （连续修改测试）
   • 删除——>删除——>删除 （连续删除测试）
6. 替换数据
7. 替换环境

测试用例：