编码人员进行单元测试
设计人员验证单元测试；进行组合测试
需求人员验证组合测试；进行系统测试
测试部进行α测试
市场中心组织用户进行β测试
递交产品管理部/用户
二、说明
1、 编码人员进行单元测试工作，以规范的格式提交可运行的程序模块；单元测试结果由设计人员进行核实和验证；
2、 设计人员确认移交产品各项功能完备和稳定性之后，进行组合测试；组合测试结果提交需求人员进行核实和验证；
3、 需求人员确认移交产品各项功能完备和稳定性之后，进行系统测试；系统测试结果经产品/项目经理核实和验证后，提交测试部进行测试；
4、 各项测试未通过或验证不合格，重复上一步工作；
三、测试计划
主要描述测试工作的工期、人员安排、设备和测试环境的建立、测试记录统计、问题反馈、纠错处理、接口状态描述、测试用例及其数据描述等。
四、测试准备
根据测试计划，在进行各项测试之前，应准备和配备相应资源、硬件环境、网络环境、运行环境、测试数据、参数设置、测试准则、人员及人员培训。
五、测试依据
主要包括：测试计划、需求说明书、OOA文档、OOD文档、上阶段测试记录、上版本用户反馈意见记录等等。
六、OOT描述
在测试过程中继续运用OO技术，以OO技术为中心进行软件测试，以更准确地发现程序错误并提高测试效率：
单元测试：由实现人员在编码结束时进行测试
1． 以对象的类作为基本测试单位，查错范围主要是类定义之内的属性和服务，以及有限的对外接口（消息）所涉及的部分；
2． 对父类测试完成后，子类的测试重点只是那些新定义的属性和服务；
3． 组合测试、系统测试和测试部测试
通过捕捉OOA和OOD模型信息，检查程序和模型不匹配的错误。
七、测试记录
参见附录《测试记录表》
1、测试问题记录要求
1) 问题描述正确
2) 错误过程记录完整
3) 界面提示记录完整易懂
4) 错误出现操作步骤详细
2、判别错误种类
可重复错误、不可重复错误、死机性错误、系统数据被破坏性错误、数据流程错误、打印错误、需求错误、设计错误、逻辑性错误、控制性错误、帮助或提示错误、菜单术语错误、计算错误、安装错误、其他错误等等
3、问题记录原则
1) 一次性原则
运行错误出现一次必定有错误。
2) 三次性原则
测试人员应尽量保证记录的问题出现三次。
八、测试反馈和处理
描述测试的处理流程：
1） 处理安排
立即修改的问题
暂缓修改的问题
最后改正错误
2） 测试记录传递
要求：
测试人员将测试记录分类后传递给程序员、项目经理、部门经理（项目/产品经理、测试部经理）。
九、测试总结报告
格式：见附录
十、紧急放行规定
紧急情况下，处于开发阶段，测试中出现的某项“不通过”，在不影响下一阶段开发、不影响产品结构的情况下，经批准后，可以放行进行下一阶段开发。但测试部必须做好记录，并采取措施进行跟踪和处理。
十一、其它
与测试有关的须说明的其它问题。
附录
F.1 测试记录表
产品/模块名称： 版本号： 时间： 负责人： 编号：
错误编号 功能号 错误种类 现象 测试人员 开发人员反馈 备注说明
发现人 发现日期 备注说明 解决日期 解决人
F.2 测试项目登记表
测试项目登记表
(开发人员填写部分)
待测项目名称：( )
申请人： ( )
申请时间： ( )
测试要求： 单机版测试( ) 网络版测试( )
测试环境----WIN95/98（中文）( ) win2000/NT4.0（中文）( )
WIN95/98（英文）( ) win2000/NT4.0（英文）( )
测试重点----功能测试( ) 稳定性测试( ) 产品测试( )
保留测试数据 是（ ） 否（ ）
预计测试所需时间（ ）天
预计测试所需人员（ ）人
备注：（详细要求）
产品/项目经理（签字）：
F.3 测试总结报告
产品/项目名称：
产品/项目经理：
测试工作安排和实施情况
测试时间：
测试负责人：
测试人员：
测试人员分工安排
测试人员负责安装、加密、系统功能、系统性能方面的部分测试。
本次测试实施部分
安装：
加密：
系统功能：
系统性能：
测试准备工作
应提供的文档资料 是/否提供 应提供的部门
需求说明 研发中心
设计说明 研发中心
功能列表 研发中心
产品质量检测规范（试用版） 产品管理部
测试环境：
测试工具：
测试方法：
测试人员工作情况总结（详见功能列表和测试记录表）
产品状况和测试数据统计分析情况
测试数据：
产品状况：
产品综合评价
稳定性：
运行效率：
一致性（例如显示和打印是否吻合等等）：
操作简洁性：
专业化程度等方面：
测试错误统计
一般按模块进行错误统计
测试用例（演示数据）：
测试记录统计：
产品检测结果：
附录：测试记录表、功能列表
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
