软件测试方案

目录
一、概述 (3)
1.1编写目的 (3)
1.2读者对象 (3)
1.3项目背景 (3)
1.4测试目的 (4)
1.5参考资料 (4)
二、测试配置 (6)
2.1测试依据 (6)
2.2测试范围 (6)
2.3测试通过准则 (10)
三、测试计划 (11)
四、测试策略 (12)
4.1功能测试 (12)
4.2流程测试 (12)
4.3界面UI测试 (13)
4.4性能测试 (13)
4.5安全性测试 (14)
4.6兼容性测试 (14)
4.7可靠性测试 (15)
4.8易用性测试 (15)
4.9回归测试 (16)
4.10发散测试 (17)
五、交付文档 (18)
六、测试进度 (19)
七、测试资源 (20)
7.1人力资源 (20)
7.2环境资源 (20)
7.3测试工具 (21)
八、发布标准 (22)
8.1B UG等级定义 (22)
8.2测试完成标准 (22)
8.3产品发布标准 (23)
九、风险说明 (24)
9.1测试范围风险 (24)
9.2测试进度风险 (24)
9.3测试环境风险 (24)
9.4风险应对措施 (25)
一、概述
1.1 编写目的
本文档是完成全自动化学发光免疫分析仪Davin180软件测试的指导性文件，主要用于规划本次测试的工作流程及工作安排，验证Davin180是否满足《需求规格说明书》明确的软件需求及隐含条件，也是本测试项目中其他文档编写及结果评价的基础。

本文档撰写目的如下：
1、为软件产品提供测试依据、测试方法、测试保障，进而提高测试效率；
2、判定Davin180全自动化学发光免疫分析仪功能是否按照需求说明书进行实现；
3、确定本次测试所需要的材料，并对测试工作量进行说明；
4、列出本次测试的可交付元素；
1.2 读者对象
读者对象为：项目经理、软件设计开发人员、测试人员以及接受调阅的其他人员。

1.3 项目背景
项目名称：全自动化学发光免疫分析仪
项目编号：S09-2201
仪器型号：Davin 180
全自动化学发光免疫分析系统是一种目前在医疗领域中广泛应用的诊断设备，其通过对动物血液、尿液、体液等样本进行检测，检测出目标物质的含量，从而对疾病进行诊断和治疗，为医疗行业的发展做出了巨大的贡献。

1.4 测试目的
1、功能点是否完善；
2、业务逻辑是否符合要求；
3、数据传输是否完整、正确，性能是否优越；
4、系统是否具有良好的兼容性；
5、系统是否具有良好的易用性和可操作性；
6、系统是否具有良好的安全性；
7、UI界面是否简洁明了，用户体验是否良好；
8、系统实用性。

1.5 参考资料
二、测试配置
2.1 测试依据
1、软件需求规格说明书
软件需求规格说明书是站在用户的角度来描述软件需要实现的功能、各个模块、系统重要性以及业务流程等。

测试软件系统的功能是否正确，其依据就是软件需求规格说明书。

2、开发设计文档
开发部门的设计文档，比如架构设计图、算法设计图、模块的详细设计说明书，接口定义文档，数据库设计说明书、界面设计图等。

基于这些文档提供的信息，就可以更深层次的确定测试所需要覆盖的范围和内容。

3、测试用例
测试用例是执行测试的依据，其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

4、行业标准和惯例
引用行业标准和惯例的时候，需要测试人员有足够的经验。

大部分情况没有需求支持，则会用现存的成熟标准来实现测试。

2.2 测试范围
2.3 测试通过准则
在此规定本系统通过测试的准则：当依据测试用例执行，测试结果与预期结果相符，或测试结果与预期结果虽有不符但不可归咎于应用程序时为测试通过，反之则为测试失败。

三、测试计划
四、测试策略
4.1 功能测试
4.2 流程测试
4.3 界面UI测试
4.4 性能测试
4.5 安全性测试
4.6 兼容性测试
4.7 可靠性测试
4.8 易用性测试
4.9 回归测试
4.10 发散测试
五、交付文档
六、测试进度
七、测试资源
7.1 人力资源
7.2 环境资源
7.3 测试工具
八、发布标准
8.1 Bug等级定义
注：对应禅道类型严重程度1、2、3、4
8.2 测试完成标准
1、测试计划里所有测试类型都已经完成；
2、功能性测试用例通过率达到100%，非功能性测试用例通过率达到
95%；
3、功能上、兼容性上没有影响用户使用的bug；没有严重级别及以上的bug；
4、允许遗留小部分影响不是很大的bug，但这个数量应该小于讨论后的某个值。

8.3 产品发布标准
1、产品需求都已完成；
2、符合交互设计规范，符合视觉要求，设计已通过评审；
3、遗留的一定比例一般及以下级别的bug通过了项目组的风险评估，都认可且问题不大；
4、产品使用说明或用户手册都已完备。

九、风险说明
9.1 测试范围风险
1、可能会存在部分隐藏软件故障，由于隐藏较深，用户使用无法触发缺陷，导致软件测试不全面；
2、对产品质量需求或产品特性理解不准确，造成测试范围分析误差，出现测试盲区或验证标准错误；
3、开发bug修复时可能引入新的问题，回归测试时影响未分析到位；
4、部分测试用例设计时忽略了边界条件和深层次的逻辑关系，用例没有完全覆盖需求。

9.2 测试进度风险
1、软件测试时间、成本风险造成不能对软件进行全面测试，导致产品质量存在风险；
2、由于需求不明确，导致系统开发后期频繁修改，严重情况将影响系统交付时间延迟；
3、开发时间的缩短导致某些测试计划无法执行；
4、用户需求发生重大变更或设计计划的大幅度调整压缩了测试时间；
9.3 测试环境风险
1、测试人员、测试环境、测试资源的不能准时到位，造成测试进度延后；
2、测试环境无法与用户使用环境一致，导致测试结果存在偏差；
3、测试人员对业务理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；
4、存在偶现bug，测试及开发均无时间定位，导致问题延后处理；
5、不能及时准备相关测试工具，测试人员对新工具无法熟练运用；
9.4 风险应对措施。