测试方案制定

前言

任何一个完全测试和穷举测试的工作量都是巨大的，所以在实际测试中不可能保证不遗漏任何缺陷。为了以最少的资源、人力投入发现更多的错误，保证项目质量，就需要结合实际项目为依托制定详细完整的测试方案，达到精准测试的目的。

1. 引言

1.1 编写目的

为软件开发项目管理者、软件工程师、运维工程师、测试工程师提供关于项目系统整体功能和性能的测试指导，同时明确测试的对象、针对这个测试对象制定的测试方法和希望通过测试手段达到的质量目标，确定软件完整测试的依据。

1.2 项目背景

根据真实项目去介绍。

1.3 测试参考文档

项目计划
需求文档
接口说明书
开发详细设计文档
软件测试规范

1.44 术语和缩写语

本文使用的术语、定义，主要是针对项目软件设计说明书中提及的属于进行解释和说明，确保日后开会测试人员能明白讲的是什么。

2. 测试范围

针对项目进行的功能测试，列出项目所包含的主要功能模块

3. 测试资源

项目人力资源：相关方确认（已确认相关关、待确认相关方、需协调相关方），如需性能人员协同
测试环境：SIT环境、隔离环境（如数据升级需要提前申请生产隔离环境数据导出）
硬件要求：（如项目需要性能测试，独立申请测试环境）
服务器：生产服务器申请等
测试工具：效能提升工具（如mock挡板工具）
测试数据：第三方提供数据或者自动化造数、手动准备数据
缺陷管理：禅道
用例管理：excel

4. 测试策略

测试策略的目的：以最少的软、硬及人力资源投入而获得最佳的测试效果。测试策略可以体现在需求分析、用例设计、测试执行、测试方法等阶段。

4.1 需求分析

需求分析采用需求跟踪矩阵、思维导图

4.2 测试类别

单元测试（类、方法）、集成测试（接口测试）、系统功能测试、用户界面测试、兼容性测试、数据升级测试、配置测试、异常测试、性能测试、安全性测试、回归测试、验收测试，根据需要可进行裁剪。

4.2.1 单元测试

单元测试代码级别的测试，首先依照系统、子系统和模块进行划分名单时最终的单元必须是功能模块（类），或者面向对象过程中的若干类，单元测试是对功能模块进行正确性验证的测试工作，也是后续测试的基础。目的在于发现各模块内部可能存在的各种差错，因此需要从程序内部结构出发设计测试用例，着重考虑以下五个方面：
（1）模块接口：对所测模块的数据流进行测试。
（2）局部数据结构：检查不正确不一致的数据类型说明、适用尚未赋值或者尚未初始化的变量、错误的初始值或者缺省值
（3）路径：虽然不能做到穷举测试，但是设计测试用例查找由于不正确计算（算法错、表达式的符号不正确、运算精度不够等）不正确的比较或者不正常的测试流（包括不同数据类型的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等）而导致错误
（4）错误处理： 检查模块有没有对于常见的条件设计比较完善的错误处理功能，即异常捕获，保证异常捕获后逻辑上的正确性（如异常后事务回退机制）。
（5）边界：注意利用边界值设计数据流、控制流中刚好等于、大于或小于的用例

4.2.2 集成测试

集成测试也叫组装测试、联合测试。通常在单元测试的基础上需要将所有的模块按照设计要求组装系统

4.2.3 系统测试

系统测试目的在于验证软件功能和性能及其他特性是否与用户的要求一致

4.2.3.1 功能测试

目标：验证系统功能是否符合其需求规格说明书，核实系统功能上是否完整，没有冗余和遗漏功能。
工具和方法：黑盒测试、边界值、等价类、场景法等
工具：手工测试和自动化结合

4.2.3.2 用户界面（UI）测试

测试用户界面是否具有导航性、美观性、行业或者公司规范性、是否满足设计中客户要求的执行功能、详细介绍如下边UI测试。
其中，Web 测试通用方法可以参考《Web 测试检查点总结》
目标：核实各个窗口的风格(包括颜色、字体、提示信息、图标、高度等) 均与需求保持一致，或符合可接受标准，能够保证用户界面的友好性、易操作性、且符合用户操作习惯。
工具和方法：手工测试，Web测试检查点
完成标准：UI 符合可接受标准，能保证用户界面的友好性，易操作性，而且符合用户操作习惯

4.2.3.3 性能测试

测试相应时间、事务处理效率等，以及服务器资源使用率。
目标：核实系统在大流量的数据与多用户操作时软件性能的稳定性，不造成系统用溃或者相关。
工具和方法：手动测试和自动化测试结合
完成标准：系统满足用户需求的性能要求。

4.2.3.4 安全测试

测试软件系统对于非法侵入的防范能力，涉及用户、管理员密码管理、应用程序级别的安全性、核实用户只能操作其所有权限操作的功能，系统级别的安全性、核实只要有具备系统

4.2.3.5 兼容性测试

测试软件在不同平台上的使用的兼容性
1.使用不同版本的浏览器（谷歌、火狐等）、分辨率、操作系统分别进行测试
2.不同操作系统（安卓、IOS、鸿蒙、linux、Windows、MACOS）、浏览器、分辨率和运行软件等各种条件的组合测试

4.2.3.6 升级测试

测试软件在不同平台上的使用的兼容性
1.服务端升级（服务升级和数据库表结构升级）
数据库表完全迁移：如oracle一张表迁移到mysql表
数据库表字段升级：已有表新增字段升级
数据库表旧表废弃升级到新表：如多张旧表升级到一张表或者升级到多张表
重点：分析源数据库表的数据量、业务状态、升级的唯一性、在途数据的处理业务的正确性、数据库表状态、源数据库表多条数据对目标表单条数据的升级情况（优先升级逻辑的考虑）

2.客户端版本升级测试
安卓、IOS系统版本升级，必须兼容低版本

4.2.3.7 配置测试

测试在不同网络、服务器、工作站的不同软硬件配置条件下，软件系统的质量，主要验证系统的可扩展能力、灾难应对能力。

4.2.3.8 回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
回归策略
全量回归测试：回归全部测试用例，时间长，成本高
非全量回归测试：重点模块回归，使用测试用例优化技术，提高测试效率，减少资源投入。
自动化回归测试：自动化测试框架回归

4.2.3.9 验收测试

验证软件系统是否达到了需求规格说明书的功能和特性。

4.3 测试设计

测试用例设计方法：用例设计体现了对代码对功能的理解程度，也一定程度上决定了测试功能覆盖，也会很明显的体现出软件质量。功能测试运用黑盒测试中的等价类划分、边界值分析、错误推断、场景法、因果图、正交法。
测试用例的颗粒：若用例设计的维度较细那么用例设计投入的时间和测试执行投入的时间势必也会增长，但若项目较紧急或项目反馈给我们的效益很低，那么就需考虑是否有必要投入大量的时间和人力，即用例设计的目的需达到精准测试
用例裁剪：用例执行过程中根据模块bug分布对各模块用例进行精准裁剪

4.4 测试方法

系统的功能测试：采用手工测试方法，运用黑盒测试中的等价类划分、边界值分析、错误推断、场景图法。
系统的UI测试：采用手工测试方法，界面友好性、易用性测试、规范性测试。
系统的安全测试、兼容性测试、安装卸载测试、配置测试：采用手工测试
单元测试：采用方法是白色测试
集成测试：执行接口测试，采用postman、Charles
回归测试：手工测试和自动化测试结合，采用python的pytest框架，执行接口自动化测试、UI自动化测试、app自动化测试

5. 测试计划

测试计划的目的：根据经验评估项目需求量和投入项目所需人力从而制定出大体的测试计划，一方面为明晰测试完成结点，另一方面能更好的协调人力，工作量的评估、开始日期与结束日期。
数据升级测试
冒烟测试
SIT详细测试
回归测试
验收测试
预发测试
生产验证

6. 测试通过标准

1、系统实现的功能和流程与需求文档的一致。
2、功能测试用例执行率100%
3、不存在bug等级1，2 的缺陷
4、bug等级为3，4的bug不得多于n个。
5、bug解决率90%
在实际情况中，如果存在的bug超过了bug等级所规定的数量，测试是不通过的。如果测试执行通过率不达标，需要部门经理、测试经理、测试负责人、开发负责人对测试结果进行评审，决定测试结论是否为通过。

7. 测试风险

根据风险类型完成风险系数评估和影响分析，且执行风险应对措施(降级处理)

7.1风险类别

需求风险：需求分析遗漏需求风险、需求变更风险等；
进度风险：开发修改bug导致延期风险、计划评估不准导致测试周期滞后风险
资源风险：人员休假或离职
关联风险：内部项目改造重构或者上线代码合并对当前项目影响风险
环境风险：测试环境不稳定风险和外部环境不稳定风险
外部风险：外部系统或者公司不支持，计划调整风险
业务风险：需求上线后存在的业务风险

7.2风险应对方案

项目运行周期内的结点风险、人力风险等都有对应的规避措施

8. 测试输出

软件测试方案（测试方案评审）
软件测试用例（测试用例评审）
缺陷列表（bug清单）
软件测试报告（上线封板会议）