软件测试规范如写诗一样有多重要？《论测试人员的自我修养》

流程和规范，是控制软件质量不可或缺的一种手段。在现在复杂的软件产品开发流程中，任何一个环节如果没有做好，其引发的质量风险就像地雷一样，随时可能被下游团队引爆。

下面是血淋淋的例子：

搜狗某产品在进行通知栏消息下发时，没有严格遵守“先测试环境，后线上环境”的验证流程，直接将通知信息发布在线上环境，致使下发的通知存在异常无法打开落地页的问题，最终导致市场推广计划告吹。

搜狗某产品，开发没有提交测试验证，私自打包上线，致使上线的数据存在异常，导致用户大面积出现崩溃问题，崩溃率成倍飙升。

好了，现在开始正题。

Bug管理规范

bug提交规范

Bug的报告要求描述内容清晰、简介、易懂，让用根据简要描述就可以大致了解问题所在：

在提交BUG时，提交人可根据提交BUG的紧急程度，选择对应的“优先级”，同时建议开发人员在处理BUG的时候能够根据优先级进行处理，优先级别较高的可以最先进行处理。

在BUG详细描述中，可在从BUG产生的前提条件、操作的步骤、实际结果、预期结果等方面进行描述：

1. 前提条件： 有些BUG的产生是需要在一定条件下才会出现，例如浏览器、分辨率、Office版本等，所以就要求在描述时描述清楚前提条件；

2. BUG的操作步骤： 详细的、有次序的、每一步的操作步骤，包括输入的数据，尽可能的重新操作的步骤；

3. 实际结果： 指的我按照以上的操作步骤，最后得出的结果是什么， 例如我点击“增加”按钮后出现白页，这就是实际结果；

4. 预期结果： 指的我按照以上的操作步骤，我想要得到的结果是什么，例如我点击“增加”按钮想要得到的预期结果是提示我“增加成功”提示；

5. 图文描述： 在必要的情况下可上传截图并注释文字，这样更便于确认错误的表现形式和错误位置等。

一般情况下，开发人员在提交BUG时，“分派人”可指定对应的处理人员，如果无法确定“分派人”，可分派给项目的负责人，然后由项目负责人进行二次分派给对应的开发人员进行处理。在分派时可以添加一些对应的批注信息。

bug级别定义

具体的优先级别有以下几种

• 致命问题(一级bug)

致命问题： 不能完全满足系统正常的功能操作要求，系统停止运行，系统的重要部件无法运行，系统崩溃或挂起等导致系统不能继续运行。

1. 常规操作下因程序问题导致系统崩溃，迫使整个系统无法使用（其中非程序问题有：系统配置、数据结构变动、session超时、网络中断、人为变更数据库中的数据、系统缺少相应文件或目录等）。

2. 常规操作下因程序问题导致程序重启、死机或非法退出。

3. 常规操作下系统出现死循环。

4. 数据丢失或异常。

5. 模块间数据传递及取值错误（如：输入A，预期结果应该是B，但实际结果不是B等）。

6. 流程输出错误（包括业务流程和事件流程。如：输入流程A，但实际流程处理中未能按A流程处理数据；点击某按钮，应跳转增加页面，结果跳转成修改页面等）。

7. 按照需求文档，功能未在程序中体现出来，即系统无此功能（据项目经理及相关负责人确认此功能必须具备的）；功能不符合用户需求，功能实现不正确（由项目经理及相关负责人确认此功能必须具备的）。

• 严重问题(二级bug)

严重问题： 严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免（不能用其他操作修复问题）的主要问题，系统无法满足主要的业务要求，性能、功能或可用性严重降低。

1. 数据计算错误。

2. 因程序问题迫使正在操作的流程无法继续且无其他操作可以修复问题的（其中非程序问题有：系统配置、数据结构变动、Session超时、网络中断、人为变更数据库中的数据、系统缺少相应文件或目录等）。

3. 常规操作下功能异常，如：结果与实际查询条件不一致、页面按钮点击没反应等。

4. 功能项的某些项目（可为所有控件）使用无效（对系统非致命的）。

5. 因程序问题迫使正在操作的流程无法继续且有其他操作可以修复问题的（其中非程序问题有：系统配置、数据结构变动、Session超时、网络中断、人为变更数据库中的数据、系统缺少相应文件或目录等）。

6. 多余功能，且该功能影响了程序的正常使用（需项目经理及相关负责人确认），如客户名称录入项需要录入汉字和英文，但程序限制了只能输入汉字等。

7. 常规操作下，程序打印、导出的内容错误。

8. 在程序安装配置无误的情况下相关功能js报错，且该功能影响业务流的正常进行。

9. 在1024*768分辨率下，页面严重变形，使数据无法浏览。

10. 在Session超时，无友情页面提示

• 中级问题（三级bug）

系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题，另外，还包括系统健壮性方面的测试。

1. 对于一些重要数据的操作、重要环节的变动且相关的操作和变动不可挽回时，系统应给出相应的操作确认提示，防止误操作，如数据删除、审批等。

2. 常规操作下页面跳转至错误友情提示页面，且操作其他模块，程序可正常运行（其中非程序问题有：系统配置、数据结构变动、Session超时、网络中断、人为变更数据库中的数据、系统缺少相应文件或目录）。

3. 功能实现不完整，如删除时没有考虑数据关联。

4. 因错误操作且因程序问题导致系统崩溃，迫使整个系统无法使用（其中非程序问题有：系统配置、数据结构变动、Session超时、网络中断、人为变更数据库中的数据、系统缺少相应文件或目录等）。

5. 数据添加、修改、查看界面中控件没有一一对应或对应控件长度、格式、验证性提示信息内容等不一致，但又不影响程序功能的进一步的操作（最终以需求规格说明书中内容规定为准）。

6. 响应时间较慢。（不可超过1分钟）

7. 功能性建议。

8. 操作界面错误（包括数据窗口内列名定义、含义是否一致）。

9. 简单的输入限制未放在前台进行控制。

10. 虽然正确性不受影响，但系统性能和响应时间受到影响。

11. 常规操作下，程序显示、打印、导出的内容格式错误，如页面变形、金额类数据未加货币符号等。

12. 在程序安装配置无误的情况下相关功能js报错，且该功能不影响业务流的正常进行。

13. 页面验证提示信息位置或内容错误，如空值验证对应位置或内容错误、提示对话框内容错误等（最终以需求规格说明书中内容规定为准）。

14. 在1024*768分辨率下，页面变形，但不影响数据的浏览。

15. 输入超长数据或特殊字符导致程序报黄页或跳转到友情提示页面等影响程序进一步的操作（需跳转友情页面）。

16. 在Session超时（需友情页面）、网络中断时，出现浏览器卡死、报黄页等异常情况，且没有对应的错误捕获机制并给出友情提示。

17. 滚动条无效，但不影响数据的显示与浏览。

18. 界面不规范，页面表现形式、样式与其他类似功能模块不一致，且差异明显的。

19. 必填项与非必填项应加以区别。

• 轻微问题

轻微问题： 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题。

1. 页面表现建议。

2. 功能操作建议。

3. 非程序代码导致黄页（如：手动删除、修改、增加数据库中的数据；缺少相应的系统配置；项目缺少目录或文件、因不明操作导致数据库中数据不符合正常逻辑关系）。

4. 辅助说明字体大小、颜色明显与页面整体表现形式不协调或者文字描述不清楚。

5. 长时间操作未给用户提示（不可超过1分钟），但程序一直在正常运行的，没有出现卡死等情况，如给出旋转的loading图标或程序后台操作进度条或显示进度百分比等。

6. 提示窗口文字未采用行业术语。

7. 可输入区域和只读区域没有明显的区分标志，如只读区域置灰显示等。

8. 键盘支持不好，如在可输入多行的字段中不支持回车换行，输入查询条件后不支持回车触发查询。

9. 界面不能及时刷新，如需要重新执行查询或加载页面等（最终以需求规格说明书中内容为准）。

不用说谢谢，请叫我红领巾

以上就是产品的测试规范，囊括了从需求到测试计划、测试准备、测试执行、结果分析、上线准备、跟踪测试到项目总结的整个流程，规范了产品测试流程。

以上文档是我从事测试行业多年以来，一些是自己亲身实践、一些是自己平时在各位牛人的博客、网页、论坛中看到的觉得很有用的资料所以保存了下来，积累编制成测试规范文档，希望能给大家在测试上带来一些帮助。

《软件测试规范文档》PDF电子书

最后给大家分享一份最新开源的《软件测试规范文档》，里面的测试规范示例堪称全网最全！并且基本通用。篇幅原因，下面以展示部分目录及内容，完整PDF点击我的学习、摸鱼群免费下载

产品测试规范纲要

目 录

第一章 产品测试规范

1.1 产品测试流程

1.1.1 测试流程图

1.1.2 测试流程说明

1.2 需求梳理

1.2.1 需求梳理

1.3 测试计划

1.3.1 测试工具选取

1.3.2 测试人员分配

1.3.3 测试业务场景选取

1.3.4 测试环境梳理

1.3.5 测试数据梳理

1.4 测试准备

1.4.1 代码管理

1.4.2 测试环境搭建

1.4.3 测试数据脚本编写

1.5 测试用例编写(功能测试框架)

1.5.1 界面友好性测试

1.5.2 功能测试

1.5.3 业务流程测试(主要功能测试)

1.5.4 链接测试

1.5.5 容错测试

1.5.6 稳定性测试

1.5.7 常规性能测试

1.5.8 易用性测试

1.5.9 兼容性测试

1.6 测试执行

1.6.1 接口自动化测试

1.6.2 探索式测试

1.6.3 传统测试用例测试

1.6.4 Bug跟踪

1.7 测试结果分析

1.7.1 结果收集

1.7.2 结果分析

1.7.3 测试分析报告

1.8 上线准备

1.8.1 版本发布

1.8.2 数据准备

1.9 上线测试跟踪

1.9.1 跟踪测试

1.10 BUG预防体系

1.10.1 web常见产品问题及预防

1.10.2 app常见产品问题及预防（1）

1.10.2 app常见产品问题及预防（2）

1.11 BUG管理规范

1.11.1 bug提交规范

1.11.2 bug级别定义