目录
1 目的 ........................................................................................................................................ 1 2 适用范围 ................................................................................................................................ 1 3 职责 ........................................................................................................................................ 1 4 工作流程 ................................................................................................................................ 1
4.1 测试依据 .................................................................................................................... 1 4.2 制订《测试方案》 .................................................................................................... 1 4.3 单元测试 .................................................................................................................... 1 4.4 API测试 ...................................................................................................................... 2 4.5 契约测试 .................................................................................................................... 2 4.6 系统测试 .................................................................................................................... 2 4.7 编写测试文档 ............................................................................................................ 3
4.7.1 测试点 ............................................................................................................ 4 4.7.2 输入数据 ........................................................................................................ 4 4.7.3 测试描述 ........................................................................................................ 4 4.7.4 预期输出数据 ................................................................................................ 4 4.7.5 实际输出 ........................................................................................................ 4 4.7.6 正确与否 ........................................................................................................ 4 4.7.7 测试结论 ........................................................................................................ 4 5 缺陷管理 ................................................................................................................................ 4
5.1 缺陷的定义及其基本属性 ........................................................................................ 4 5.2 缺陷分类 .................................................................................................................... 5 5.3 文档缺陷分类 ............................................................................................................ 5 5.4 代码缺陷分类 ............................................................................................................ 6 5.5 系统测试缺陷分类 .................................................................................................... 6 5.6 缺陷等级定义 ............................................................................................................ 6 5.7 缺陷优先级定义 ........................................................................................................ 7 5.8 缺陷状态定义 ............................................................................................................ 7 5.9 缺陷完成度 ................................................................................................................ 8 5.10 缺陷管理流程 .......................................................................................................... 8 6 处理机制 ................................................................................................................................ 9
6.1 退回机制 .................................................................................................................... 9 6.2 异常情况处理机制 .................................................................................................... 9 6.3 报告机制 .................................................................................................................. 10 7 测试完成的标准 .................................................................................................................. 10
7.1 被测试出的、在软件错误级别分类中定义的： .................................................. 10 7.2 用户可以接受未修改的软件错误 .......................................................................... 10
7.3 测试超过了预定时间表，由项目经理决定是否停止测试 .................................. 10 7.4 测试结论及评价标准 .............................................................................................. 10 7.5 输出 .......................................................................................................................... 10 8 记录 .......................................................................................................................................11
1 目的
为了确保软件产品质量，使产品能够顺利交付和通过验收，特编写本文档，以作参考。
2 适用范围
本文档适用于项目开发过程中的单元测试、API测试、契约、系统测试。
3 职责
➢
项目测试负责人组织编制《测试计划》、《测试方案》，指导和督促测试人员完成各阶段的测试工作。 ➢
项目组测试人员按照《测试计划》、《测试方案》完成所承担的测试任务，并按要求填写《单元测试跟踪表》及缺陷库。 ➢
测试经理依照确认规程和准则对工作产品进行确认，提出对确认规程和准则的修改意见 ➢ ➢ ➢
项目负责人组织测试环境的建立。
项目经理审核负责控制整个项目的时间和质量。 研发人员确认修改测试人员提交的缺陷。
4 工作流程
4.1 测试依据
详细设计是模块测试的依据。因此设计人员应向测试人员提供《系统需求规格书名书》、《详细设计》、《概要设计》等有关资料。测试人员必须认真阅读，真正弄懂系统需求和详细设计。
4.2 制订《测试方案》
在测试之前，由项目负责人根据《测试计划》的要求，组织人员编制相应的《测试方案》，《测试方案》应包括以下内容：
➢ ➢ ➢ ➢
测试目的；
所需人员及相应培训要求； 测试环境、工具和测试软件； 测试用例、测试数据和预期的结果。
4.3 单元测试
项目开发实现过程中，每个程序单元（程序单元的划分视具体开发工具而定，一般定为函数或子程序级）编码调试通过后，要及时进行单元测试。
单元测试由单元开发者自己进行，使用白盒测试方法，根据程序单元的控制流程，争取达到分支覆盖。对于交互式运行的产品，不便于进行自动测试的，可以采用功能测试的方法进行。
单元测试针对程序模块，从程序的内部结构出发设计测试用例。多个模块可以独立进行单元测试。
1
➢ 单元测试内容包括模块API测试、局部数据结构测试、路径测试、错误处理
测试等；
➢ 单元测试组织原则一遍根据开发进度安排对已开发完成的单一模块进行测
试；
➢ 单元测试停止标准：完成了所有规定单元的测试，单元测试中发现的缺陷已
经得到修改。
4.4 API测试
编码开发完成，项目组内部应进行API测试。
API测试由项目负责人组织策划（编写测试计划、测试用例）并实施。API测试着重对各功能模块之间的API进行测试，验证各功能模块是否能协调工作、参数传递及功能调用是否正常。测试采用交叉方法，即个人开发的软件应由其他的项目组成员进行测试。
API测试过程应填写《单元测试跟踪表》，测试结果应形成《测试报告》。
4.5 契约测试
主要工作是项目组通过对外开放接口设计说明书的变更进行分析列出需要修改的契约测试案例，及是否需要更新契约文件，评估契约测试工作量，项目经理在制定代码实现计划的同时，制定契约测试计划（交叉测试）。
服务消费方开发人员按照详细的契约测试计划在开发环境中，依据对外开放接口说明书和需求规格说明书，执行契约测试，生成契约文件。
服务提供方开发人员按照详细的项目计划在开发环境中，依据对外开放接口说明书和需求规格说明书，契约文件，执行契约测试。
契约测试工作过程中，将发现的缺陷登记在缺陷跟踪管理系统，测试结果应形成《测试报告》。
4.6 系统测试
在项目开发完成之后，应对整个系统软件和硬件进行系统测试。对性能、可靠性、健壮性、压力承受力等方面分别进行评价，以验证系统是否满足规定的需要。
系统测试由测试负责人组织策划（编写测试计划、测试用例）并实施，系统测试中发现的缺陷应及时提交至缺陷库。
系统测试一般进行如下几种情况的测试： ➢ 正常情况 ➢ 非正常情况 ➢ 破坏性测试 ➢ 边界情况 ➢ 非法情况 ➢ 强度测试
2
➢ 性能测试 ➢ 兼容性测试 ➢ 用户友好性测试 界面设计规范测试： ➢ 光标的初始位置 ➢ 字体是否统一 ➢ 字号是否符合规定 ➢ 标题颜色
➢ 按钮的名称是否规范
➢ 界面布局是否合理，整体效果如何 输入值测试： ➢ 数据类型 ➢ 数据长度
➢ 约束条件是否满足，是否完整 ➢ TAB和Enter键是否起作用 ➢ 键盘操作能否全部代替鼠标操作 ➢ 输入（光标）是否按照顺序前进 按钮测试：
➢ 将按钮放开和封闭是否严格、准确，不能使用的按钮必须封闭 ➢ 检查“退出”、“取消”等具有共性按钮的功能 异常情况测试：
在完成正常功能测试后，安正常处理的相同操作顺序，执行与正常处理不同的动作例如
➢ 正常处理中要求输入日期的字段，这时输入字符或数字 ➢ 正常处理中输入字段有范围要求，这时输入超过范围的值 ➢ 正常处理中用两个值限定范围，这时用一个值或不限定 ➢ 正常处理中要求用“Tab”键，这时安“Enter”键或其他键 ➢ 正常处理中单选框、多选框、下拉框等，十一偶那个非指定键操作 ➢ 使用不同于指定的按钮操作
4.7 编写测试文档
3
4.7.1 测试点
将测试模块分解成多个功能点，测试点应涵盖功能点，也涵盖了正常测试和异常测试。
4.7.2 输入数据
输入数据包括界面输入数据、数据库的初始数据及其他外部输入数据。特别是数据库的初始所需属性一一列出，全面是指：数据能达到模块所涉及的全部功能，典型是指这个数据能充分反映功能特点。
4.7.3 测试描述
描述测试步骤，包括：操作员所执行的动作（包括鼠标、键盘、加载外部数据等操作）；系统的反应，包括：光标定位、光标聚焦、显示字段值、按钮的封闭和放开、功能键的封闭和放开、系统提示和系统消息等。
4.7.4 预期输出数据
按准备的输入数据和设计要求的处理过程，模块应输出的数据。
输出数据包括：屏幕输出数据、输出到数据库的数据、输出到其他外部介质上的数据，并指出断点结果或最终结果。
4.7.5 实际输出
填写本测试点程序运行后的实际输出。
4.7.6 正确与否
程序运行后，实际输出结果和预期输出结果一致时，为正常，否则为不正常。
4.7.7 测试结论
填写本次测试的结论，是合格或不合格。若不合格时，应总结存在的问题，可以让修改者一目了然。
5 缺陷管理
5.1 缺陷的定义及其基本属性
缺陷是指在软件开发过程中的针对软件产品和开发过程中的问题，这些问题已经影响或可能会影响软件产品的质量。缺陷应该具备以下属性，也就是往缺陷管理库或者缺陷列表中提交的缺陷应该具备以下属性： 属性名称 缺陷标识 缺陷类型 缺陷验证程度 缺陷所处的模块或子描述 标记某个缺陷的一组符号，每个缺陷必须有一个唯一的标识 根据缺陷的自然属性划分的缺陷种类 因缺陷引起的故障对软件产品的影响程度 缺陷分步的模块或子系统 4
系统 缺陷出现几率 指发现错误的几率 缺陷的重现步骤 附件 备注 详细的缺陷重现步骤 与缺陷相关的附件（截图、附件、用例等） 对缺陷的其他描述 5.2 缺陷分类
根据缺陷的定义，将缺陷分为如下列：
➢ 文档缺陷：是指对文档的静态检查过程中发现的缺陷。检查活动包括同行评
审、产品审计等。评审的缺陷要根据被评审对象的类型来确定，被评审的对象包括最终出产物和中间过程产出物，比如需求文档、设计文档、计划、报告、用例等
➢ 代码缺陷：是指对代码进行同行评审、审计或代码走查过程中发现的缺陷 ➢ 测试缺陷：是指由测试活动发现的测试对象（被测对象一般是指可运行的代
码、系统，不包括静态测试发现的问题）的缺陷，测试活动包括单元测试、API测试、契约测试、系统测试、性能测试等
➢ 过程缺陷：有称为不符合项问题，是指通过过程审计、过程分析、管理评审、
质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是测试人员、项目经理等
5.3 文档缺陷分类
缺陷分类 描述不完整 不一致 描述 文档内容缺失，或文档应该包括的范围没有涵盖 一致性问题有两类： 一是与源头说明书不一致，比如需求和客户业务需求不一致、设计与需求不一致等 二是上下文或者与前提不一致 描述错误 功能问题 不清楚或有歧义 逻辑错误 API问题 输入输出问题 不细化 性能问题 文档描述是错误的，不可实现或导致错误的输出或结果 该缺陷将会导致用户功能的错误、不满足、不可用 内容的描述不清楚、不能准确表达、或表达的意思有歧义 内容组织逻辑不清楚、逻辑错误 与最终用户API问题、与外部系统的API问题、内部子系统或模块的API问题 输入输出不完整、不正确、不可测试或验证 内容还需要进一步细化 文档的设计或实现方式存在性能问题
5
安全性问题 文档的设计或实现方式存在安全性问题 5.4 代码缺陷分类
缺陷分类 常量变量定义问题 不满足设计或需求 编写代码不符合规范 条件判断处理 循环处理错误 异常处理 算法逻辑问题 注释问题 代码冗余 性能问题 描述 5.5 系统测试缺陷分类
缺陷类型 功能错误 描述 影响了重要的特性、用户界面、产品API或全局数据结构，并且设计文档需要争取的变更。如逻辑、循环、递归、功能等缺陷 Web应用程序结构化页面无法显示，或者显示错误 Web应用程序当中出现脚本错误，包括客户端对数据进行校验和运算的各种情况下产生的错误 Web应用程序页面出现空链接、错误链接、死链接 Web应用程序页面出现的中外文拼写、使用、以及不同语种页面的编码错误 Web应用程序页面出现图片内容使用不当，或者无法显示 Web应用程序页面当中超文本标识语言、文本标签解释错误 Web应用程序页面排版不符合要求或者不符合使用习惯 应用程序的实现流程和规定业务流程不一致，或者实现流程无法正确完成。包括流程数据的部分并行、争用、同步等操作，引起的流程断裂、死锁、以及其他异常情况 应用程序实现流程在实际情况下虽然可以完成，但是存在不必要的反复、等待、冗余等影响使用效率的情况 其他未分类错误 系统改进建议 结构错误 脚本错误 页面链接错误 页面文字错误 页面图形错误 ALT错误 排版错误 业务逻辑不合理 业务逻辑不方便 其他错误 建议 5.6 缺陷等级定义
缺陷的严重程度对以上所述的缺陷类型都是适合的，缺陷的严重程度反映的是对
6
缺陷的发现对象可能造成的影响或后果来定义的。 等级 描述 系统死机 5-致命 数据损坏 功能失效 异常退出 功能缺少 功能错误 计算错误 4-非常高 精度错误 交互错误 性能缺陷 说明 系统、环境及应用崩溃死机。 软件发生故障数据毁坏或丢失。 软件发生故障导致功能失效。 软件发生故障异常退出。 用户需求未实现。 实际提供功能与用户需求不一致。流程或接口中，数据未做关联。 结果计算错误。 精度与用户需求不一致。 与其他软件或系统交换数据出错，包括导出文件后内容丢失。 未达到需求说明书中所规定的性能指标，例如响应时间过长。 输入未控制和未判断导致功能异常、信息缺失，或界面显示、提示信息异常等；如必输项、重复、数据约束、数据长度；删除未确认；屏蔽判定；正常逻辑错误。 界面显示错误，页面刷新问题，提示信息不准确，错别字，打印内容格式错误。可修改字段与不可修改字段中字体颜色标示未区别； 界面风格不一致，术语不统一，对话框颜色不一致，按钮大小不统一，提示信息不一致；未使用默认值，默认值使用不便或不正确。 需求说明书、用户手册中未说明，但影响用户对软件使用的方便性等。 3-高 控制错误 显示错误 2-一般 不易操作 1-低 建议意见 5.7 缺陷优先级定义
缺陷优先级 紧急 极高 高 中 低 描述 如果故障妨碍开发人员的进一步开发活动，应立即修复。 如果阻塞测试，应立即修复。 必须修改，版本发布前必须修正 必须修改，不一定马上修改，但需确定在某个特定版本发布前必须修正 缺陷需要正常排队等待修复或列入软件发布清单 留到组后解决，如果项目的进度跟紧张可以在产品发布以前不解决 5.8 缺陷状态定义
7
缺陷状态 初始状态 驳回 已分配 已解决 关闭 重新打开 遗留 描述 测试或开发人员提交一个新的缺陷，等待开发人员或项目经理分配修改负责人 要求缺陷的提交者再次对缺陷进行说明 已分配给开发人员，待修改状态 缺陷已被开发人员修复，等待测试人员验证 测试人员验证已修复的缺陷 测试人员验证，缺陷没有修改正确 经项目负责人验证此缺陷在本版本中不用修改 5.9 缺陷完成度
缺陷完成度 打开（Open） 描述 缺陷没有被解决 已解决（Fixed） 缺陷已经修改 遗留（Suspended） 重新打（Reopen） 开此缺陷步骤本阶段解决 重新打开某个缺陷 不做修改（Won’不对这个缺陷进行修改 t fix） 重复（Duplicate） 与某个缺陷重复 需求如此 不可重现 经理和开发人员经过需求和设计的核实后决定不需要修改 被指派的开发人员想要再现缺陷进行修改个时候，发现缺陷始终不能再现 5.10 缺陷管理流程
8
6 处理机制
6.1 退回机制
若在测试过程中发生如下情况，将系统退回到申请部门：
➢ 经过测试后，发现与需求说明规格说明书中定义的功能项存在较大的差异 ➢ 单一模块，测试过程中发现缺陷输了较多或者无法继续进行系统其它功能
模块的测试，继续测试无意义 ➢ 测试过程中，频繁死机或系统崩溃 ➢ 主业务流程出现断点
6.2 异常情况处理机制
9
非正常情况下，需要进行特别处理的情形，此情况需要主管领导签字确认： ➢ 上线时间紧急的情况下，未经测试部充分测试就需要部署到用户现场 ➢ 作为总包时，子商进度明显延迟，尚未进行验收测试就需要上线
6.3 报告机制
若出现以下情况，需要及时向部门领导和项目经理汇报的情况： ➢ 测试后期出现重大逻辑错误，修改测试影响上线时间 ➢ 测试过程中用户需求出现重大变更 ➢ 测试负责人定期汇报测试情况
7 测试完成的标准
7.1 被测试出的、在软件错误级别分类中定义的：
➢ 一级缺陷，5-致命错误，100%得到修改并且复测通过 ➢ 二级缺陷，4-严重错误，100%得到修改并且复测通过 ➢ 三级缺陷，3-高错误，95%得到修改并且复测通过
➢ 四级缺陷，2-一般及1-建议错误，95%得到修改并且复测通过
7.2 用户可以接受未修改的软件错误
7.3 测试超过了预定时间表，由项目经理决定是否停止测试 7.4 测试结论及评价标准 测试结论 评价标准 拒绝发布 遗留了一级、二级缺陷 测试通过版本 不能遗留以一、二类缺陷 三类缺陷95%得到修改并且通过复测 四类缺陷85%得到修改并且通过复测 不能遗留以一、二类缺陷 三类缺陷95%得到修改并且通过复测 四类缺陷90%得到修改并且通过复测 不能遗留以一、二类缺陷 三类缺陷97%得到修改并且通过复测 四类缺陷90%得到修改并且通过复测 推荐使用版本 可以证实发布版本
7.5 输出
《阶段性测试报告》 《性能测试报告》 《测试总结报告》 《测试问题列表》
10
8 记录
序 号 1 2 3 4 5 名 称 测试计划 测试方案 单元测试跟踪表 缺陷库 测试总结报告 编 号
11
因篇幅问题不能全部显示，请点此查看更多更全内容