软件测评流程及实施方案
软件测试流程
一、需求调研
1. 委托方提供资料
A. 填写测试委托申请表
B. 操作手册
C. 开发需求规格说明书
D. 开发合同及招标文件等
2. 双方技术沟通确定测试具体内容，如功能性测试、性能效率测试、信息安全性测试、兼容性测试、可靠性测试等。
3. 我方给出测试方案及报价，达成合作意向
二、合同签订
我方根据确定的测试内容分配项目编号拟定测试协议，双方无异议后签订合同。
三、测试过程安排
1. 测试人员安排
测试人员我方根据测试工作量进行调整，测试开始前委托方须部署测试环境，准备测试会用到的软硬件资源，包括不限于测试软件、测试数据、配合测试的人员等。
表格1 人员安排
人员 | 角色 | 职责、任务 |
1 | 项目负责人 | 评审并批准测试计划及有关报告；组织并确保团队工作；控制项目进度；评估测试绩效；与有关人员进行沟通。 |
1 | 测试组组长 | 测试计划编制；协调实施项目计划中确定的活动；识别测试环境需求；负责设计测试用例；为其他人员提供技术支持。 |
3 | 测试工程师 | 执行测试活动；提交测试日志和测试记录报告。 |
1 | 系统及配置管理员 | 负责制定项目的配置管理计划；负责项目过程的配置管理活动的落实和管理；负责项目电子数据的变更管理、版本控制和备案入库工作。 |
1 | 质量管理员 | 对测试过程、测试记录、测试结果进行监督。 |
1 | 委托方开发工程师 | 熟悉被测系统，配合测试工程师 |
2. 测试活动安排
表格2 测试活动安排
活动名称 | 时间（天） | 内容 | 评审时间与内容 |
测试需求分析与测试策划 | 2 | 根据软件需求和样品及其资料，项目负责人组织编制《测试计划》 | 测试计划评审 |
测试设计与实现 | 2 | 根据《测试计划》中人员安排，相关测试人员进行测试用例设计、编码，编制《测试说明》，并建立测试环境 | 测试说明评审和测试就绪评审 |
测试执行 | 5 | 根据《测试计划》和《测试说明》，执行测试，产生《测试记录》 | / |
2 | 回归测试 | / | |
测试总结 | 2 | 编制《测试问题报告》和《测试报告》，并通过评审 | 测试总结评审 |
3. 测试环境
表格3 测试环境
测试客户端1 | ||
硬件环境 | 设备型号： | / |
CPU： | i7-4790 | |
内存： | 8GB | |
硬盘： | 500GB | |
软件环境 | 操作系统： | Windows10 |
应用软件： | Chrome89.0 | |
应用服务器1（255.255.255.255） | ||
硬件环境 | 虚拟机软件： | / |
CPU： | i7-4790 | |
内存： | 32G*16 | |
硬盘： | 960GBSSD*2 | |
软件环境 | 操作系统： | Linux |
应用软件： | JDK1.8 | |
交换机1 | ||
硬件环境 | 设备型号： | / |
网络类型： | 有线局域网 | |
带宽： | 1000Mbps |
4. 测试策略
测试状态准则
测试启动准则 | 正常情况下，测试启动需要具备以下条件：1) 测试环境设备安装调试完毕；2) 测试数据已经准备完毕，初始数据量满足测试要求；3) 应用服务器安装配置成功，待测应用版本已正确部署；4) 测试客户端机器到位，系统软件安装完毕；5) 网络配置正确，连接通畅，可以满足测试需求；6) 测试方案评审完毕，甲方签字确认。 |
测试结束准则 | 将以下条件完成作为本次测试完成的结束条件：1) 按测试计划完成测试任务；2) 提交测试报告并评审通过；3) 测试相关输出物提交并归档完毕；4) 或经特殊批准延长测试周期后完成项目目标、提交测试报告并评审通过。 |
测试暂停准则 | 测试暂停准则:1) 测试任务、方案、计划等发生重大变更；2) 系统测试重大问题发现：影响测试执行的重大缺陷，需要修复的；3) 测试环境受到干扰，比如服务器被临时征用，或服务器其它使用会对测试结果造成干扰；4) 需要调整测试环境资源，如加减CPU数目、加减存储设备等；5) 不能提供相关用于测试的数据。 |
测试再启动准则 | 再启动准则：1) 相关方案、计划等变更完毕，并满足测试要求；2) 测试中发现的重大问题得以解决；3) 测试环境恢复正常；4) 环境调整完毕；5) 相关的性能测试数据已提供。 |
4.2测试用例设计方法
4.2.1功能性
功能测试用例主要采用等价类划分法、错误推测法、边值分析法与因果图法进行设计：
Ø 等价类划分法的原则：
对业务流程进行等价类划分，测试用例应是业务主流程和流程主分支的最小集，所有的判别分支都能被覆盖，在流程覆盖的同时，完成等价功能的测试。
Ø 边值分析法的原则：
针对功能说明中的输入输出域，进行边界值和极限值的设计和测试。
Ø 错误推测法的原则：
采用逆向思维方式，结合以往测试经验和直觉设计软件在功能和流程上可能存在的 各种错误，进行容错性测试。
Ø 因果图法的原则：
因果分析图是以结果作为特性，以原因作为因素，完成测试的方法。
4.2.2性能效率
性能效率测试主要分为价基准测试、负载测试、压力测试、配对测试、并发测试和可靠性测试。
Ø 基准测试：
基准测试是基于一定规模的数据量上进行单业务或按实际用户操作同比例组合业务的测试，目的在于量化响应时间、吞吐率的指标，便于后续比对。
Ø 负载测试：
通过在被测系统上不断增加压力，直到性能指标，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。
Ø 压力测试：
测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。
Ø 配对测试：
通过对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。
Ø 并发测试：
通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
Ø 可靠性测试：
通过给系统加载一定的业务压力（例如资源在70%~90%的使用率）的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能稳定运行。
本次性能测试主要采用并发测试和负载测试，模拟用户执行业务操作，用户执行登录，依次访问党建模块首页，访问综治模块并查询一条数据，访问网格首页并新增一条数据。
5. 质量保证
由质量监督员进行监督记录，若项目负责人为该质量监督员，由质量负责人进行复核，由技术负责人审批。（至少保证每周一次对正在执行的项目进行跟踪）
监督项 | 监督内容 | 监督时间 |
设备与软件 | 记录使用的设备与软件名称、测试人员等。 | 及时 |
设施与环境 | 测试时的实验室内的环境和设施是否符合项目实际情况。 | 及时 |
需求分析 | 根据被测样品分析，查看测试需求是否考虑全面；需求是否100%覆盖客户所提供的需求文档；需求是否符合项目实际情况；需求分析是否合理；测试方法是否选择恰当；测试需求分析文档内容是否完整、合理、规范。 | 及时 |
测试大纲 | 查看测试大纲文档是否完整、正确、规范；进度计划是否符合合同约定；计划是否符合项目实际情况；项目工作量估计是否合理；测试项是否选择完整、合理。 | 及时 |
测试工具与环境 | 查看测试环境是否合理并满足测试要求；环境选择是否满足客户需求；测试环境是否满足实验室要求；测试环境运行是否正常；设备是否经过授权。 | 及时 |
测试设计 | 根据需求分析，编制测试用例是否覆盖全部功能点；文档是否完整、正确、规范；用例是否100%覆盖测试需求；用例是否正确追踪需求；用例设计是否合理；用例设计步骤是否正确；用例设计量是否满足测试大纲的活动安排；用例是否可行、充分。 | 及时 |
测试执行 | 是否按照测试用例和测试要求逐条执行；用例执行后的数据是否正确记录到文档里；测试执行步骤是否按照作业指导书执行 | 及时 |
报告书写 | 报告书写和结论是否合符规范。 | 及时 |
项目跟踪 | 查看测试步骤是否符合CNAS、CMA项目管理规范。 | 每天 |
项目跟踪频次 | 当天 | 每天 |
其他 | —— | —— |
6. 沟通保证
为了保障测试过程顺利进行，测试方、委托方和开发方等均应保持沟通的畅通，以便快速定位和解决问题。沟通手段包括但不限于以下：
Ø 会议沟通：在整个测试活动中，应当召开首次会议和末次会议；
Ø 现场交流：主要是测试人员和软件开发人员现场沟通交流；
Ø 电话沟通：较快捷的描述问题和原因；
Ø 聊天工具：可通过截图、传输方式，形象的描述问题和原因；
Ø 其他。
7. 测试风险分析
序号 | 风险 | 应对措施 |
1. | 由于软件文档中软件功能描述不明确，导致测试人员对被测软件的理解、对功能的要求理解有偏差。 | 加强与软件开发人员的交流与沟通；加强测试过程评审及审查，保证测试质量。 |
2. | 由于一些特殊原因，导致某些用例（异常用例）无法执行，导致测试的不充分性。 | 设计测试用例时，尽可能多的考虑到测试用例的异常终止情况。 |
3. | 由于各种原因，项目的开发人员可能没有足够的时间和精力配合测试工作，给测试工作的质量和进展带来影响。 | 尽量将需要开发人员配合测试的测试项集中安排。 |
4. | 其他 | - |
四、测试输出
a) 测试方案
b) 测试大纲
c) 测试说明
d) 测试记录
e) 测试报告
f) 其他（测试截图、脚本等）
标签：软件测试流程、方案