软件测试规范标准

软件测试规范

1、 测试目的

为了确保软件产品的质量，使产品能够顺利交付和工程验收。

2、 测试职责

（1） 编写《测试计划》&《测试方案》，指导测试。

（2） 搭建测试环境。

（3） 完成所承担的测试任务，并按要求填写问题报告。

（4） 测试出现bug及时与研发人员进行沟通确认，确认是bug的情况下提缺陷报告单记录bug，并在下一版本中返测该问题单。

3、 工作流程

（1） 测试依据：详细设计是测试的依据。因此设计人员需向测试人员提供《系统需求规格书》、《详细设计》、《概要设计》等相关材料，测试人员需仔细阅读相关材料，弄清系统的功能需求和详细设计。

（2） 测试方案的制定：在测试之前需要编写《测试方案》，《测试方案》包含：

① 测试目的;

② 所需人员及相应培训要求;

③ 测试环境、工具及测试软件;

④ 测试用例、测试数据及预期结果。

（3） 单元测试

软件产品在开发过程中，每个功能模块开发完成代码调试后都要尽快的进行单元测试，测试出的bug应立即进行修改。

（4） 集成测试

在单元测试的基础上，在代码开发完成后进行的组装测试，将每个单元组合成一个软件系统进行集中测试，此时需要进行编写测试计划和测试用例。集成测试着重验证各功能模块之间能否协调工作，参数传递及功能调用是否正常。集成测试中出现问题应提交缺陷报告单，记录缺陷，待下一版本中进行验证，也就是接口之间的测试。

（5） 系统测试

在项目开发完成后，应对整个系统软件进行系统测试，对功能、性能、可靠性、压力承受能力等方面进行评价，以验证系统是否满足需求规定。系统测试由负责人组织编写测试计划和测试用例，测试用例中应覆盖绝大部分测试点。

★系统测试一般测试方法如下：

① 有效等价类及有效边界值;

② 无效等价类及无效边界值;

③ 非法情况;

④ 性能测试;

⑤ 场景的测试找出基本流和备选流，基本流是模拟用户正确的操作；备选流是模拟用户错误的操作;

⑥ 因果图法，找出输入组合和输出组合，根据输入和输出组合进行测试用例的编写。 ★界面测试一般测试如下情况：

① 光标的初始位置；

② 字体的统一性；

③ 符号是否符合规范；

④ 字体颜色是否符合需求；

⑤ 按钮名称是否规范；

⑥ 标题颜色。

★输入参数的规范：

① 数据类型；

② 数据长度；

③ 约束条件是否满足；

④ 快捷键是否可用（键盘操作是否可完全替代鼠标操作）；

⑤ 输入光标是否按顺序推进。

★按钮测试：

①按钮的可用性与置灰是否明确；

②检查“确认”与“取消”功能键是否实现功能。

★异常情况测试

在完成按正常操作顺序测试后，按照与正常顺序不同的测试动作进行测试

① 需求说明中要求输入数字的地方输入字符串，查看结果；

② 需求说明中有范围要求的，超出范围很多或者边界值附近取值；

③ 需求说明中有按键要求的，我们更改按键操作，查看结果；

④ 不同于指定的按钮操作。

（6） 交付版本的要求：

① 集成版本满足设计定义的各项功能、性能要求；

② 按照集成测试用例完成整个系统的集成测试；

③ 在集成测试中的bug已经解决，缺陷的修复率达到标准；

④ 《系统需求规格书》中提到的各项功能均已实现，性能指标全部达到要求；

⑤ 提交阶段性测试报告，功能和性能；

⑥ 所有文档齐全。

（7） 软件发布要求

① 软件产品通过了单元测试、集成测试、系统测试和性能测试。

② 测试部门提交：测试计划、测试方案、测试用例及结果报告。

③ 各功能模块需符合以下标准：

◆致命错误：无

◆严重问题：无

◆功能缺陷：部门人员进行评审，认为该缺陷不影响客户正常使用情况下可留待下一版本解决

◆界面缺陷：部门人员进行评审，认为该缺陷不影响客户正常使用情况下可留待下一版本解决

在产品交付和用户验收之前，通过验收测试来确认在规定的环境中整个产品的运行情况是否满足规定的要求

4、 编写测试文档

（1） 测试点：将测试模块分解成多个功能点，测试点应涵盖功能点，也涵盖正常功能点和异常功能点。

（2） 输入数据：测试数据的输入应覆盖软件正常功能的测试点和异常功能的测试点。

（3） 测试描述：描述测试步骤，包括：测试员所执行的动作（鼠标、键盘、加载数据等操作）；系统的反应，包括：光标定位、显示字段值、按钮的置灰与否、功能键的实现与否和系统提示、消息等。

（4） 预期输出数据：按照准备的数据和设计要求的处理过程，模块应输出的预期数据，输出数据应包括：屏幕输出的数据、输出到数据库的数据和输出到其他外部的数据。

（5） 实际输出数据：程序运行后输出的数据。

（6） 正确与否：预期结果与实际数据之间是否一致，若不一致则判定为缺陷。

（7） 测试结论：填写测试结论，是合格还是不合格，若不合格时，应提单进行阐述，在提单的时候应该详细叙述操作过程和操作步骤，让开发人员能清楚的看到缺陷在哪一个模块哪一步中产生，便于研发人员修改代码。

5、 缺陷管理

（1） 什么是缺陷？

① 软件未实现产品所要求的功能；

② 软件实现了产品未提及的功能；

③ 软件实现了产品指明不应该出现的错误；

④ 产品需求虽未说明，但站在客户的角度应该实现该功能；

⑤ 软件导致系统崩溃，不易使用。

（2） 缺陷报告的组成

➢ 缺陷的编号；

➢ 缺陷摘要；

➢ 缺陷的发现者；

➢ 缺陷发现的日期；

➢ 所属模块；

➢ 发现缺陷的版本；

➢ 指派给谁；

➢ 缺陷的状态；

➢ 缺陷的严重程度；

➢ 缺陷的优先级；

➢ 缺陷描述；

➢ 缺陷的出现频率；

➢ 附件的上传；

➢ 附注

上述选项都是在提交缺陷时测试人员需填写的项目，这可以很准确的记录缺陷的具体信息，以便在后续操作中进行缺陷跟踪、开发修改代码及责任划定。

（3） 缺陷的分类

➢ 文档缺陷：指对文档的静态检查过程中发现的缺陷，检查过程包括：文档的评审、产品审计等。评审的缺陷要根据被评审对象的类型来确定，被评审的对象包括：需求文档、设计文档、报告、用例等。其中软件缺陷中文档中的缺陷就达到了80%。

➢ 代码缺陷：代码走查过程中发现的缺陷。 ➢ 测试缺陷：指由测试活动发现的测试对象的缺陷（测试对象一般指可运行的代码和系统），测试活动包括：单元测试、集成测试和系统测试、性能测试。

（4） 文档缺陷分类

缺陷分类 描述

描述不完整 文档内容缺失或文档应该包括的范围没有涵盖

不一致 一致性问题有两类：

1、与源头说明书不一致，比如需求和客户业务需求不一致、设计与需求不一致等

2、上下文或者与前提不一致

描述错误 文档描述是错误的，不可实现或导致错误的输出或结果

功能问题 该缺陷将会导致用户功能的错误、不满足、不可用

不清楚或有歧义 内容的描述不清楚、不能准确表达、或表达的意思有歧义

逻辑错误 内容组织逻辑不清楚、逻辑错误

接口问题 与最终用户接口问题、与外部系统的接口问题、内部子系统或模块的接口问题

输入输出问题 输入输出不完整、不正确、不可测试或验证

不细化 内容还需要进一步细化

性能问题 文档的设计或实现方式存在性能问题

安全性问题 文档的设计或实现方式存在安全性问题

（5） 代码缺陷分类

常量变量定义问题、不满足设计或需求、代码编写不合规范、条件判断处理、循环处理出错、异常处理、算法逻辑问题、注释问题。

（6） 系统缺陷分类

缺陷类型 描述

功能错误 影响了重要的特性、用户界面、产品接口或全局数据结构，并且设计文档需要争取的变更。如逻辑、循环、递归、功能等缺陷

结构错误 Web应用程序结构化页面无法显示，或者显示错误

脚本错误 Web应用程序当中出现脚本错误，包括客户端对数据进行校验和运算的各种情况下产生的错误

页面链接错误 Web应用程序页面出现空链接、错误链接、死链接

页面文字错误 Web应用程序页面出现的中外文拼写、使用、以及不同语种页面的编码错误

页面图形错误 Web应用程序页面出现图片内容使用不当，或者无法显示

ALT错误 Web应用程序页面当中超文本标识语言、文本标签解释错误

排版错误 Web应用程序页面排版不符合要求或者不符合使用习惯

业务逻辑不合理 应用程序的实现流程和规定业务流程不一致，或者实现流程无法正确完成。包括流程数据的部分并行、争用、同步等操作，引起的流程断裂、死锁、以及其他异常情况

业务逻辑不方便 应用程序实现流程在实际情况下虽然可以完成，但是存在不必要的反复、等待、冗余等影响使用效率的情况

其他错误 其他未分类错误

建议 系统改进建议

（7） 缺陷等级定义 缺陷的严重程度对以上所述的缺陷类型都是适合的，缺陷的严重程度反映的是对缺陷的发现对象可能造成的影响或后果来定义的。

缺陷等级 缺陷性质 系统中对应的错误分类 描述

一级 致命错误

系统崩溃

系统死锁 导致对被描述的主要对象的理解错误、不可行、不可运转、对业务和整个系统造成重大损失或损害；对使用、维护或保管人员有危险或不安全，以及对产品的基本功能有致命影响的缺陷。

二级 严重缺陷 严重错误 对被描述的部分对象的理解或实现错误，部分的模块或系统不可行或不能运转或部分模块和系统缺失，对整个系统有重大影响或可能造成部分的损失或损害；严重影响使用安全。

三级 次要缺陷 次要错误

布局不合理，

文字错误 系统中部分单元模块或单个功能描述和实现有错误、有偏差、不一致或有缺失，不影响模块的正常运行，或有影响，但可以有替代的办法或避免办法。

四级 一般缺陷 不影响使用的缺陷 基本不影响系统的运行和功能的实现。但是与标准、规范和定义不一致。

五级 建议缺陷 优化建议 不在定义、标准、范围的定义和约束之内，但是从提出者来看是需要完善的建议。

（8） 缺陷的优先级定义

Urgent：紧急，立即解决

Veryhigh：加急，本版本中解决

High：急，下一版本中解决

Medium：一般，缺陷需进行正常排队进行修复，发布前解决

Low：低，允许在发布中存在一定的缺陷

（9） 处理缺陷的流程图

该图中测试人员首先提交缺陷报告，缺陷状态为New，指派给开发经理；然后，开发