软件测试工作总结编写规范
文件修改控制
目录
1. 目的
2. 适用范围
3. 术语和缩略语
4. 规范要求
5. 引用文件
6. 质量记录
1. 目的
本文件规定了测试工作总结编写时应考虑的事项，通过测试工作总结来不断地积累测试经验，提高测试工作的整体水平。并对软件产品测试过程中发现的问题进行分析，为开发人员以后的修改、升级提供一个预防问题的依据。
2. 适用范围
本规范适用于软件项目与软件产品的功能测试与系统测试。
3. 术语和缩略语
本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。
4. 规范要求
4.1 测试小组在完成软件产品测试后，要对整个测试工作进行总结，分析本次测试工作的得失，为以后的测试工作积累经验。
4.2 在测试工作总结中，全部测试人员在充分分析测试过程中发现问题的基础上，完成《软件问题倾向分析表》，该表中指出该类型软件产品容易导致问题的模块及操作。该表将用于该产品或该类产品的升级、开发工作中为开发人员提供预防错误的依据。
5. 引用文件
本程序采用NQ402100《质量手册》中的术语和缩略语及其定义。
6. 质量记录
（无）
附录：测试工作总结模版
项目名称（项目编号）
（测试种类）测试工作总结
（部门名称）
目录
1. 引言…………………………………………………………………………………………… 3
2. 项目测试结果………………………………………………………………………………… 3
2.1 软件产品………………………………………………………………………………... 3
2.1.1软件产品名称及综合评价 3
2.1.2 提交项目管理部门物品 3
3. 测试工作评价 3
4. 软件问题倾向
4.1 问题解决情况总结与分析
4.2 问题类型统计与分析
附录一：软件问题倾向分析表
附录二：测试结束检查表
1. 引言
说明参加本项目测试的负责人、参加人员、起止时间及实际工作量。
2. 项目测试结果
2.1 软件产品
2.1.1 软件产品名称及综合评价：给出该软件产品的产品名称及对该软件产品的综合评价。
2.1.2 总结测试工作内容并向项目管理部门提交测试结果
填写“测试结束检查表”，列出在测试执行阶段所完成的全部测试工作和软件测试结束后应向项目管理部门提交的全部物品及其数量，内容包括测试文档、源代码、执行程序等。
3. 测试工作评价
3.1 测试进度：对照测试计划的安排，总结测试效率及相应的原因分析。
3.2 发现问题数量：比较测试人员提出问题总数及经确认后提交开发人员的问题数量。
3.3 测试总次数：列出本次测试实际次数，并对多次测试产生原因进行分析。
3.4 经验教训：总结测试过程中获得的经验及纠正错误或缺陷等问题的教训。
4. 软件问题倾向
4.1 问题解决情况总结与分析
列出本次实际发现问题数量、解决问题数量、残留问题数量。并对残留问题对系统功能的影响情况进行分析。
4.2 错误类型统计与分析
在对软件产品测试过程中发现的问题进行充分分析、归纳和总结的基础上，由全体参与测试的人员完成软件问题倾向分析表，对该类型或该系统软件产品在模块、功能及操作等方面出错倾向及其主要原因进行分析。软件问题倾向分析表将为该类型或该系统软件产品以后开发工作提供一个参考，使开发人员根据软件问题倾向分析表明确在开发过程中应注意和回避的问题。该表也可为以后的测试工作明确测试重点提供依据。
附录一：
软件问题倾向分析表
1. 本页不足记述结果时，可以增加附页，格式自定，总页数包括本页与所有附页。
第 页/共 页
附录二：
测试结束检查表
1． 在□内，打“√”表示进行了该测试或提交该物品。
2． 表中内容不足时可在空白处添加。
第 页/共 页
第二篇：软件测试规范
软件测试规范
1 目的
确保软件产品质量，使产品能够顺利交付和通过验收的一项重要措施。
2 适用范围
适用于项目开发过程中的单元测试、集成测试、系统测试、业务测试、验收测试以及一些专项测试。
3 职责
Ø 项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。
Ø 项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《问题报告及维护记录》。
Ø 测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见
Ø 项目负责人组织测试环境的建立。
Ø 项目经理审核负责控制整个项目的时间和质量。
Ø 研发人员确认修改测试人员提交的bug。
4 工作流程
4.1 测试依据
详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。
4.2 制订《测试方案》
在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容：
Ø 测试目的；
Ø 所需人员及相应培训要求；
Ø 测试环境、工具和测试软件；
Ø 测试用例、测试数据和预期的结果。
4.3 单元测试
项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。
单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。
单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。
Ø 单元测试内容包括模块接口测试、局部数据结构测试、路径测试、错误处理测试等；
Ø 单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测试；
Ø 单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的bug已经得到修改。
4.4 集成测试
编码开发完成，项目组内部应进行组装测试。
集成测试由项目负责人组织策划（编写测试计划、测试用例）并实施。集成测试着重对各功能模块之间的接口进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。
集成测试过程应填写《问题报告及维护记录》，测试结果应形成《测试报告》。
4.5 系统测试
在项目开发完成之后，应对整个系统软件和硬件进行系统测试。对性能、可靠性、健壮性、压力承受力等方面分别进行评价，以验证系统是否满足规定的需要。
系统测试由测试负责人组织策划（编写测试计划、测试用例）并实施，系统测试过程应形成《问题报告及维护记录》。
系统测试一般进行如下几种情况的测试：
Ø 正常情况
Ø 非正常情况
Ø 破坏性测试
Ø 边界情况
Ø 非法情况
Ø 强度测试
Ø 性能测试
Ø 兼容性测试
Ø 用户友好性测试
界面设计规范测试：
Ø 光标的初始位置
Ø 字体是否统一
Ø 字号是否符合规定
Ø 标题颜色
Ø 按钮的名称是否规范
Ø 界面布局是否合理，整体效果如何
输入值测试：
Ø 数据类型
Ø 数据长度
Ø 约束条件是否满足，是否完整
Ø TAB和Enter键是否起作用
Ø 键盘操作能否全部代替鼠标操作
Ø 输入（光标）是否按照顺序前进
按钮测试：
Ø 将按钮放开和封闭是否严格、准确，不能使用的按钮必须封闭
Ø 检查“退出”、“取消”等具有共性按钮的功能
异常情况测试：
在完成正常功能测试后，安正常处理的相同操作顺序，执行与正常处理不同的动作例如
Ø 正常处理中要求输入日期的字段，这时输入字符或数字
Ø 正常处理中输入字段有范围要求，这时输入超过范围的值
Ø 正常处理中用两个值限定范围，这时用一个值或不限定
Ø 正常处理中要求用“Tab”键，这时安“Enter”键或其他键
Ø 正常处理中单选框、多选框、下拉框等，十一偶那个非指定键操作
Ø 使用不同于指定的按钮操作
4.6 业务测试
在组装测试与系统测试结束后，均可由最终用户或测试人员对系统进行测试。业务测试着重测试业务流程，功能、用户界面等方面。
项目、测试负责人负责组织相关人员制定测试方案和测试用例，并进行测试。
测试的结果应形成《问题报告及维护记录》。
4.7 验收测试
4.7.1 验收测试的条件
Ø 按照项目计划规定的验收测试进度安排进行测试准备
Ø 在验收测试前，各项内部的测试活动都受到监控并争取执行
4.7.2 交付版本的要求
Ø 按照集成测试用例完成了整个系统的集成测试
Ø 集成版本满足设计定义的各项功能、性能要求
Ø 提交的数据库脚本样本需要完整，没有冗余数据
Ø 在集成测试中发现的bug已经得到解决，各级缺陷修改率达到标准
Ø 软件需求分析说明书中定义的所有功能都已经实现，性能指标全部达到性能需求指标
Ø 提交阶段性测试报告，包括功能和性能测试报告
Ø 所有文档齐备完整
4.7.3 版本发布的准则
Ø 软件产品通过了单元测试、集成测试、业务测试、系统测试、性能测试
Ø 测试部提交文档：测试计划、测试方案、测试用例、测试分析报告
Ø 所有测试项必须符合以下标准
n 致命错误：无
n 功能错误：无
n 功能缺陷：项目经理、技术经理、测试负责人审核通过
n 界面缺陷：项目经理、技术经理、测试负责人审核通过
n 建议：项目经理、技术经理、测试负责人审核通过
Ø 以上几项其中之一不满足要求，视为不合格
在产品交付和用户验收之前，通过验收测试来确认在规定的使用环境下整个产品的运行情况是否满足规定的要求。
在产品交付之前，由指定的验收负责人组织制定测试方案和测试用例，主持验收。
验收测试过程应形成《问题报告及维护记录》。
4.8 用户现场测试
将软件部署到用户实际生产环境后，由于环境差异，需要在用户现场进行确认测试，保证系统功能、性能完备，可正常运行。测试内容：
Ø 根据软件系统规模，准备现场测试用例，涵盖所有重要功能点，若规模小，需要将全部功能点全部测试一遍
Ø 对于后台已定义好的工作流、功能栏目路径以及用户信息等数据，不可进行修改和删除操作，新增的测试数据也需要在测试完成后给予清楚
Ø 重点检查上传、下载的数据是否可以正常的打开或保存
Ø 确认界面美观，基本信息和链接无错误
Ø 考虑用户实际的软件环境和网络环境，以客户端最为复杂的软硬件环境作为测试机器，检查有无异常情况出现
Ø 针对前期发现的bug进行回归测试，以保证发布版本为最新版本
4.9 编写测试文档
4.9.1 测试点
将测试模块分解成多国功能点，测试点应涵盖功能点，也涵盖了正常测试和异常测试。
4.9.2 输入数据
输入数据包括界面输入数据、数据库的初始数据及其他外部输入数据。特别是数据库的初始所需属性一一列出，全面是指：数据能达到模块所涉及的全部功能，典型是指这个数据能充分反映功能特点。
4.9.3 测试描述
描述测试步骤，包括：操作员所执行的动作（包括鼠标、键盘、加载外部数据等操作）；系统的反应，包括：光标定位、光标聚焦、显示字段值、按钮的封闭和放开、功能键的封闭和放开、系统提示和系统消息等。
4.9.4 预期输出数据
按准备的输入数据和设计要求的处理过程，模块应输出的数据。
输出数据包括：屏幕输出数据、输出到数据库的数据、输出到其他外部介质上的数据，并指出断点结果或最终结果。
4.9.5 实际输出
填写本测试点程序运行后的实际输出。
4.9.6 正确与否
程序运行后，实际输出结果和预期输出结果一致时，为正常，否则为不正常。
4.9.7 测试结论
填写本次测试的结论，是合格或不合格。若不合格时，应总结存在的问题，可以让修改者一目了然。
5 缺陷管理
5.1 缺陷的定义及其基本属性
缺陷是指在软件开发过程中的针对软件产品和开发过程中的问题，这些问题已经影响或可能会影响软件产品的质量。缺陷应该具备以下属性，也就是往缺陷管理库或者缺陷列表中提交的缺陷应该具备以下属性：
5.2 缺陷分类
根据缺陷的定义，将缺陷分为如下列：
Ø 文档缺陷：是指对文档的静态检查过程中发现的缺陷。检查活动包括同行评审、产品审计等。评审的缺陷要根据被评审对象的类型来确定，被评审的对象包括最终出产物和中间过程产出物，比如需求文档、设计文档、计划、报告、用例等
Ø 代码缺陷：是指对代码进行同行评审、审计或代码走查过程中发现的缺陷
Ø 测试缺陷：是指由测试活动发现的测试对象（被测对象一般是指可运行的代码、系统，不包括静态测试发现的问题）的缺陷，测试活动包括单元测试、集成测试、系统测试、性能测试等
Ø 过程缺陷：有称为不符合项问题，是指通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是测试人员、项目经理等
5.3 文档缺陷分类
5.4 代码缺陷分类
5.5 系统测试缺陷分类
5.6 缺陷等级定义
缺陷的严重程度对以上所述的缺陷类型都是适合的，缺陷的严重程度反映的是对缺陷的发现对象可能造成的影响或后果来定义的。
5.7 缺陷优先级定义
5.8 缺陷状态定义
5.9 缺陷完成度
5.10 缺陷管理流程
6 处理机制
6.1 退回机制
若在测试过程中发生如下情况，将系统退回到申请部门：
Ø 经过测试后，发现与需求说明规格说明书中定义的功能项存在较大的差异
Ø 单一模块，测试过程中发现缺陷输了较多或者无法继续进行系统其它功能模块的测试，继续测试无意义
Ø 测试过程中，频繁死机或系统崩溃
Ø 主业务流程出现断点
6.2 异常情况处理机制
非正常情况下，需要进行特别处理的情形，此情况需要主管领导签字确认：
Ø 上线时间紧急的情况下，未经测试部充分测试就需要部署到用户现场
Ø 作为总包时，子商进度明显延迟，尚未进行验收测试就需要上线
6.3 报告机制
若出现以下情况，需要及时向部门领导和项目经理汇报的情况：
Ø 测试后期出现重大逻辑错误，修改测试影响上线时间
Ø 测试过程中用户需求出现重大变更
Ø 测试负责人定期汇报测试情况
7 测试完成的标准
7.1 被测试出的、在软件错误级别分类中定义的：
Ø 一级缺陷，致命错误，100%得到修改并且复测通过
Ø 二级缺陷，严重错误，100%得到修改并且复测通过
Ø 三级缺陷，一般错误，95%得到修改并且复测通过
Ø 四级缺陷，轻微错误，95%得到修改并且复测通过
7.2 用户可以接受未修改的软件错误
7.3 测试超过了预定时间表，由项目经理决定是否停止测试
7.4 测试结论及评价标准
7.5 输出
《阶段性测试报告》
《性能测试报告》
《测试总结报告》
《测试问题列表》
8 其他约束
9 记录
