本人在测试项目实践中经过总结，制定了一份供测试人员提交BUG时给BUG的严重程度定级的参考标准。

这里首先强调缺陷的严重程度与优先级的区别。严重程度是测试人员提交BUG时给BUG定性，以便给开发组一个参考。而优先级则是项目经理根据项目进度和缺陷的严重程度来决定缺陷处理的先与后。

我曾经在测试论坛看到过一份传播较广的缺陷严重程度定级标准，感觉不太规范，因为其中的描述太过于具体，不够抽象。比如文中这样描述：出现XXXX情形时，将严重程度定为“致命”。XXXX描述的是一些很具体的情形，不具有概括性和抽象性。所以我在定制这份《软件缺陷严重程度定级标准》时，尽量使描述具有抽象性。

有的软件公司，将软件缺陷的严重程度定了4个级别：致命、严重、一般、较小。我觉得没有必要。因为致命和严重之间的差距不会太大，且无论是致命还是严重的缺陷，肯定都得让开发组修复，这些缺陷往往影响用户使用系统。在这两者间再做细分，感觉没必要。所以，我只将缺陷的严重程度划分为三级：严重 、中等、轻微。

1、  严重(urgent)：

 

①    用户需求未实现（影响到用户完成业务）；

 

②    用户需求实现错误（影响到用户完成业务）；

 

③    导致被测软件响应明显很慢（假死）、死机、非法退出、崩溃；

 

④    用户使用频繁的功能，响应时间超出忍耐限度（不影响其他功能模块）；

 

⑤    导致后台数据受损或丢失

 

2、  中等(medium) ：

 

①    用户需求未实现（不影响用户完成业务、用户使用不频繁) ；

注：用户执行删除操作时系统应弹出确认提示将固定视为用户需求，无删除确认提示的缺陷归属本类

 

②    用户需求实现错误 （不影响用户完成业务、用户使用不频繁) ；

 

③    用户操作过程中系统出现异常报错，但不影响系统功能的使用。

 

④    用户使用不频繁的功能，响应时间超出忍耐限度；

注：忍耐限度根据实际软件系统的特点而定

 

⑤    UI上存在错误引导用户的信息。

 

⑥    UI上信息缺失、无法显示完整或出现乱码从而给用户造成疑惑的。

 

⑦    用户频繁使用的功能易用性差（操作起来麻烦、复杂、效率低）

 

 

3、  轻微(low)：

 

①    UI控件不符合界面规范。 

 

②    影响UI友好性。

 

③    用户不频繁使用的功能易用性差

这套标准启用后，我所在的测试团队成员反映不错 ，基本上能覆盖测试项目中可能遇到的各种性质缺陷。但本人发现还有一种情况：开发人员实现了需求说明书里未规定实现的功能，即多余的功能，这也属于软件BUG 。但如何对其严重程度进行定性，无法一概而论。倘若这个多余的功能，给系统带来不好的影响，比如使得系统死机、响应很慢，崩溃等导致用户无法继续操作的现象，那严重程度就归属为严重；倘若对系统毫无影响，但无法正常使用、提示出错，那严重程度可以归属为中等；倘若对系统无影响，也能正常使用，仅相当于一个摆设，那严重程度可以归属为轻微。

在软件需求分析阶段，测试人员评审需求文档目的主要有三方面：

1、及时检测出软件需求文档中具有不可测试性的需求点。
不可测试：某功能模块输入可见，输出不可见，无法验证模块功能是否正确；或是该功能模块的输出无参考标准

来衡定。

2、及时发现软件需求文档的不完整性，从而提醒需求分析人员弥补描述。

3、熟悉业务需求，保证与需求人员保持理解一致，及时发现中文档中有歧义、二义性、模糊的描述，从而提醒

需求分析人员以精确的文字来描述需求点。

在这三个评审目的的指导下，测试人员的评审行为包括：

1、找出不可测试的需求点
2、找出用户提出的、但未被完整描述的需求点
3、找出描述有歧义、二义性、模糊的需求点

评审需求文档后填写评审记录，反馈给需求分析人员，双方可在需求评审会上做讨论，随后需求分析人员在评审记录表中填写处理结果。

    今天，看到一个测试同行发表了一篇文字，题目叫《淘宝质量组三轮测试的感想》。作者在文中提倡“当天发现的bug，开发人员尽量在当天解决，而测试人员尽可能的验证完毕”的做法。我也想谈谈自己的看法。

    这种工作模式不一定适合所有的软件开发项目。关键在于：开发组提交修复版本的紧迫程度。有的开发项目的进度非常紧迫，项目经理要求开发人员在测试人员开始测试的当天就提交修复版本，测试人员也在当天验证完所有修复的BUG。但这种情况实属特殊，实际上对项目进度掌控力好的项目经理是不会让这样的状况发生。毕竟这样高效的工作模式可能会让开发人员和测试人员过于焦虑及劳累，开发人员的修复速度远远赶不上测试人员提BUG的速度，在要求尽快修复的压力下，开发人员会很紧张，重现BUG现象到准确定位原因然后修复，这都需要一定的时间，特别是一些棘手的深层次BUG，显然这样的工作强度很高。如果修复花费很长时间，那测试人员也要陪同等待，然后验证修复。长此以往恐怕双方都会吃不消。我就经历过全体组员封闭开发的软件项目，老板为了拉单给客户许下早早交付的承诺，实际上也很难为项目经理，但这样的现象在国内的软件企业比比皆是。我们当时的做法是：开发组按计划在某日下晚班前提交修复版本，测试人员做冒烟测试验证修复版本的可测试性，然后加班做回归测试或在第2日上班时先过滤出状态=fixed的BUG优先做处理，处理完后再进行新的测试。

    但我后来换了一个项目组，情况就完全相反，进度不那么紧迫，大家都是不紧不慢的。一般是测试人员提交BUG后几天才修复，测试人员的回归测试也留足时间。当天测试当天提交修复当天验证的情况仅是偶尔几次。

    说了那么多，就想总结一句：当天测试当天提交修复当天验证的高强度工作模式只适合特定情况的项目，即特别紧迫那种，但不适合推广到所有的开发项目中去。

测试管理工具TestDirector（简称TD）可以在同类型或不同类型的数据库之间完成项目数据移植。移植操作完全可在客户端界面进行,无须对后台数据库进行任何操作。但目前仍有很多同行对TD数据移植多少存在些误解，认为唯一的方案是在后台数据库进行表间复制等繁琐的操作，其实不然。现在我想给大家推荐一种简单易行，而且很安全的方法。这个方法在我1年前尝试搭建测试管理平台时屡试不爽……

因附图，详情请看附件文档。

09年伊始，公司领导要求规范本公司现行的软件测试过程，并要求制定考核项。我作为任务完成者，整理出一套软件测试过程实施细则。本公司的软件产品开发现状：采用迭代式开发模式，针对每一次迭代开发的功能模块/子系统，软件测试模型参考V模型，成熟度接近TMM 4级。整理软件测试过程实施细则的意义在于指导今后的软件测试活动。

注：过程包括流程及相关的过程文档

《软件功能测试篇》

     1.    测试计划阶段

测试项目立项后指定一个测试负责人制订功能测试计划, 测试计划的文档命名和内容严格按照《项目功能测试计划模板》规范来制订。测试负责人在预计的工作日内完成计划编写并提交给项目测试计划评审成员评审（成员包括测试负责人、项目经理、项目开发人员），并收集所有评审成员的意见。在预计的工作日内完成项目测试计划的修订，定稿后分别发予项目经理和项目开发人员。

 2.    功能需求评审阶段

需求组提交软件需求说明书后，项目测试负责人参加《软件需求说明书》评审会，评审前在预计的工作日内填写完《功能需求评审记录》并发给需求分析人员（需求分析组应在评审会召开前3天提前通知质量组）。监督需求分析人员提交定稿后的需求说明书。

 3.    测试设计阶段

项目测试人员根据定稿后的软件需求说明书设计功能测试用例。指定的同行测试人员在预计的工作日内完成功能测试用例评审，项目测试人员在预计的工作日内根据内审意见完成修订，并提交需求组评审。项目测试人员收集需求组评审意见在预计的工作日内完成修订，形成功能测试用例正式稿。

 4.    测试准备阶段

开发组在预计的工作日提交可测试的软件系统和测试记录表，项目测试人员在进行功能测试之前对软件做冒烟测试，检查软件的主要功能是否正常。如果软件不通过冒烟测试，则没有进一步测试的必要，须要求开发组重新提交可测试的软件系统。同时检查开发人员是否正确填写测试记录表-《报告页》标签中的“开发填写内容”。

项目测试负责人在缺陷管理系统为新的测试项目做好相关配置工作，并对项目组相关人员进行缺陷管理工具使用培训。

5.    首次执行测试阶段

项目测试人员在预计的工作日内完成首次测试用例执行，提交功能缺陷报告至缺陷管理系统，同时填写测试记录表-《报告页》标签中的“测试填写内容”和《任务明细》标签中的“执行结果” ，并提交给项目测试负责人做测试总结。测试总结完提交给项目经理审阅功能测试执行结果，项目经理在预计的工作日内参照《缺陷管理工具使用指南》对缺陷报告进行预处理。（见《开发组处理缺陷流程》章节）

6.    回归测试阶段   

开发人员在预计的工作日内提交软件修复版本和测试记录表，项目测试人员在预计的工作日内根据测试记录表中提交的功能缺陷修复记录来验证软件缺陷的修复情况（原则上需遍历所有测试功能点），并填写测试记录表-《报告页》标签中的“测试填写内容”和《任务明细》标签中的“执行结果”，同时检查指定的缺陷解决人是否正确处理缺陷状态（参照《缺陷管理工具使用指南》-“开发组处理缺陷流程”章节）。项目测试负责人检查测试人员在预计的工作日是否及时做回归测试，是否正确处理缺陷状态（参照《缺陷管理工具使用指南》-“质量组处理缺陷流程”章节）。

7.    发布测试阶段

项目经理决定要修复的所有功能缺陷被修复后方可提交给测试人员做发布测试。要求开发组搭建发布测试环境与用户现行的使用环境必须一致，并提交发布测试记录表。测试人员在预计的工作日内完成发布测试并提交测试记录表。项目经理根据发布测试结果决定是否将软件发布到用户方。若不能发布，则在本次发布测试版本的回归测试通过后再次组织发布测试。

8.    测试总结阶段

软件通过发布测试后，由项目测试负责人撰写功能测试报告，测试报告文档名称及内容符合《测试报告模板》规范。项目测试负责人在预计的工作日内完成撰写后发予项目经理。

9.    软件维护阶段

软件发布给用户使用后，项目组收集用户反馈的修改意见，安排专人将那些开发组接受的修改意见录入缺陷管理系统以便统一管理。同时通知项目测试负责人安排测试人员做回归测试和发布测试。测试人员在预计的工作日内完成软件的回归测试和发布测试，相关的工作规范参照第6、7点。

《软件性能测试篇》

     1.    测试计划阶段

测试项目立项后指定一个测试负责人制订性能测试计划, 测试计划的文档命名和内容严格按照《项目性能测试计划模板》规范来制订。测试负责人在预计的工作日内完成计划编写并提交给项目测试计划评审成员评审（成员包括测试负责人、项目经理、项目开发人员），并收集所有评审成员的意见。在预计的工作日内完成项目测试计划的修订，定稿后分别发予项目经理和项目开发人员。

 2.   性能需求评审阶段（与功能需求评审为同一时间）

需求组提交软件需求说明书后，项目测试负责人参加《软件需求说明书》评审会，评审前在预计的工作日内填写完《性能需求评审记录》并发给需求分析人员（需求分析组应在评审会召开前3天提前通知质量组）。监督需求分析人员提交定稿后的需求说明书。

 3.    测试设计阶段

项目测试人员根据定稿后的软件需求说明书设计性能测试用例。指定的同行测试人员在预计的工作日内完成性能测试用例评审，项目测试人员在预计的工作日内根据内审意见完成修订，并提交给评审组（项目需求分析人员，项目开发人员）。项目测试人员收集评审组意见在预计的工作日内完成修订，形成性能测试用例正式稿。

 4.    测试准备阶段

本阶段完成性能测试工具的安装、配置工作，并根据性能测试用例设计的测试数据准备好测试数据。

 5.    首次执行测试阶段

测试负责人根据软件的功能性缺陷的修复情况安排首次测试执行时间。原则是软件功能确保实现正确后方可进行性能测试，否则不予开展。测试人员在预计的工作日内完成首次测试用例执行，并提交性能缺陷报告至缺陷管理系统，同时填写测试记录表-《报告页》标签中的“测试填写内容”和《任务明细》标签中的“执行结果” ，并提交给项目测试负责人做测试总结。测试总结完提交给项目经理审阅性能测试执行结果，项目经理在预计的工作日内参照《缺陷管理工具使用指南》对缺陷报告进行预处理。（见《开发组处理缺陷流程》章节）

 6.    回归测试阶段   

开发人员在预计的工作日内提交性能调优后的软件版本和测试记录表，项目测试人员在预计的工作日内根据测试记录表中提交的性能缺陷修复记录来验证软件性能缺陷的修复情况，并填写测试记录表-《报告页》标签中的“测试填写内容”和《任务明细》标签中的“执行结果”，同时检查指定的缺陷解决人是否正确处理缺陷状态（参照《缺陷管理工具使用指南》-“开发组处理缺陷流程”章节）。项目测试负责人检查测试人员在预计的工作日是否及时做回归测试，是否正确处理缺陷状态（参照《缺陷管理工具使用指南》-“质量组处理缺陷流程”章节）。

注：性能测试过程中可省去发布测试。软件发布到用户现场之前须验证所有功能点是否正常，因为在软件修复的过程中可能存在一种现象：就是修复旧的缺陷可能引入新的缺陷。而软件系统若通过性能回归测试（测试环境和测试数据务必接近用户环境），可省去性能发布测试。

 7.    测试总结阶段

软件通过发布测试后，由项目测试负责人撰写性能测试报告，测试报告文档名称及内容符合《测试报告模板》规范。项目测试负责人在预计的工作日内完成撰写后发予项目经理。

 8.    软件维护阶段

软件发布给用户使用后，项目组收集用户反馈的修改意见，安排专人将那些开发组接受的修改意见录入缺陷管理系统以便统一管理。同时通知项目测试负责人安排测试人员做回归测试。测试人员在预计的工作日内完成软件的回归测试，相关的工作规范参照第6点。

 

    网上提供的测试过程相关文档模板内容大同小异，如何定制性能测试过程文档的内容？以下模板是本人参考了软件国标GB相关文档和一些测试前辈的经验后所建，不追求天马行空虚无缥缈的内容，只需把该交代的信息传达给文档的读者即可。

    系统性能测试过程文档包括性能测试计划、性能测试用例、性能测试报告。下面按过程中的环节顺序展示文档模板

 

测试的时间	测试对象
单元测试阶段	算法复杂的核心模块
集成测试阶段	组合模块
系统测试阶段	子系统(应用服务器/数据库/中间件)或整个系统
验收测试阶段	整个系统

 

 

 

 

 

 

 

 

 

性能测试类型	含 义
压力测试	对被测系统施加压力，监测系统运行情况
负载测试	找出系统处理极限的临界点（通常有参考对象）
大数据量测试	针对系统的存储、传输、统计查询等业务进行大数据量测试
配置测试	通过改变各项资源参数进行测试，为系统调优提供依据。如调整oracle的内存参数，操作系统的虚拟内存等等
疲劳测试(强度测试)	让系统在特定压力下运行较长的一段时间(通常以天为单位)，检测系统运行是否稳定，是否出现异常。主要用于系统稳定性评估

 

 

 

 

 

 

 

 

6．测试资源

6.1    环境资源

搭建性能测试环境所需要的软、硬件资源

 

6.2    人力资源

描述性能测试团队的人员安排和职责

7．    测试启动与结束准则

7.1  启动准则

描述性能测试执行的进入准则，必须满足哪些预备条件

7.2  结束准则

描述性能测试执行结束的标准

①  有明确的、强制的性能需求：直到系统性能满足预期性能指标

②  无明确、强制的性能需求：所有测试用例执行完毕

8．进度安排

描述性能测试的进度安排，包括各项子任务的日期和内容，包括编写性能测试用例、准备测试环境、工具培训、编写性能测试报告等。

建议：插入project 甘特对象

 

 

测试环境与开发环境分离的必要性

1、搭建独立的测试环境有利于重现开发环境无法重现的BUG。这样说也许会显得抽象，我们不妨举个简单的例子来说明：某个软件系统由模块A、B、C组成（对应开发人员A、B、C）。起初开发人员比较偷懒，不想重新搭建独立的测试环境（特别是搭建过程比较复杂的情况下），而是让测试人员连到他们各自的开发机器上分别测试他们各自负责的模块。各自的模块功能很正常，但一旦整合作为一个系统向用户提供功能时，就不一定正常了，有可能在模块A录入的数据在模块B查询不到，或是模块间的接口有问题等。除此以外，还可能有其他因素妨碍开发环境重现BUG。总之，搭建一个与典型用户环境配置一致的测试环境是有效测试的重要前提。

2、搭建独立的测试环境便于开发人员并行地修复BUG。如果对开发环境进行测试，开发人员要修复BUG必须先重现BUG，然后修改相关代码，并进行程序调试。而在测试人员还未测试完系统前，开发人员是不能对程序进行修改、更新。只有等测试人员测试完后才能进行BUG修复。现实中也有这样的情况：测试员还未测试完开发人员就更新修复部份BUG的程序。这种做法比较危险，开发人员若修复得不好可能会导致程序无法运行，势必影响测试进度。此外，有可能导致上一个版本发现的缺陷无法追溯。而串行的工作方式也很耗费时间，甚至影响进度。正确的做法应该搭建独立的测试环境，测试人员提出BUG后开发人员在开发机上重现并修复，并验证修复后的效果，两种环境互不干扰。

3、搭建独立的测试环境可以验证安装软件的全过程，即安装测试。用以检查安装文件是否有错漏，软件在指定的操作系统下能否都能正常安装，各种配置项是否有错漏等。

4、搭建独立的测试环境可以避免环境被破坏导致测试无法进行的意外。如果选择开发环境来进行测试，开发人员进行某项误操作后发生系统崩溃或者系统不能正常运行的意外，此时测试工作也不得不停止。

deferred-暂缓
open-打开

执行首次测试后，测试人员利用缺陷管理系统管理所有提交的缺陷，缺陷状态的转换是其中最需要关注的工作。本文讨论的是被项目经理标记为暂缓处理的BUG ，该由谁将暂缓状转变为open状？

有些测试团队的做法是不做限定，项目经理或开发人员均有暂缓->open状态转变的权限。但诸多项目实践告诉我们，极少会有开发人员再去关注标记为暂缓处理的BUG，最后均是不了了之，即使有些觉悟比较高的开发人员乐意去修复暂缓处理的BUG,但他也不清楚这些BUG修复的deadline。这个时候的“暂缓”状就等同于“拒绝修复”。这样的后果就可能致使一些缺陷遗漏处理。所以，规范的做法还是由项目经理处理“暂缓”状的缺陷，毕竟是项目经理最清楚这些缺陷应该在什么时候被处理。

   测试人员在缺陷管理工具新增缺陷报告后，开发人员修复缺陷时会被要求填写一个属性字段“预处理版本”，这个字段的含义是告诉测试人员缺陷即将被修复的软件版本，便于测试人员在相应的版本提交后验证缺陷是否修复。但有的开发人员提出疑问：此字段是否必须填写？版本提交前将缺陷状态标为fixed后，测试人员只需过滤出状态=fixed的缺陷就可以做验证了。这个不是没有道理，但从测试管理的角度来说，填写预处理版本是规范化的体现，这样做的必要性在于：

1、测试人员在缺陷管理工具里对状态标记为fixed的缺陷进行回归测试时，开发人员同时处理状态标记为oepn的缺陷，一旦完成修复的也会标记为fixed。但测试人员在现行版本不可能对开发人员刚刚标记为fixed状的缺陷进行回归测试。那这两类状态一样的缺陷如何区分开？只有通过预处理版本号来区分，后一类fixed状的缺陷会在后续版本提交。如果不做区分，测试人员去核对那些还未提交修复的缺陷，发现未修复就会将状态标记反复，打回给开发人员，如此误会太令人啼笑皆非。

2、利用缺陷管理工具进行度量时可充当过滤条件。比如统计某个版本有多少个缺陷不是一次性修复的，即缺陷反复率时，就可以设置过滤条件为：预先处理版本=XX & 实际修复版本<>XX，将过滤出的缺陷数/处理缺陷的总数就等于缺陷反复率。

但现实中会有一些开发团队采用较为特殊的缺陷处理方式，比如测试人员在缺陷管理工具提交了缺陷报告，而后项目经理标记出需要处理的缺陷，开发人员修复后提交新版本程序，并在提交说明文档里把需要验证的缺陷一一列举出来。此提交说明文档里更多的是用户反馈缺陷（来自用户反馈表），测试人员按此文档标明的BUG ID号和用户反馈缺陷来进行回归测试，而非在缺陷管理工具中先过滤出所有状态=fixed的缺陷再验证。

追溯导致这种做法的原因，就是软件在发布到用户现场之前遗漏了大量的缺陷未被发现或是未修改，所以用户在使用后会反馈大量意见，而如果把这些缺陷也输入到缺陷管理工具中是极其耗时的事（开发团队未设专门的实施人员，由开发人员身兼二职），一般用户反馈BUG会记在另外定制的表格里。提交修复时与缺陷管理工具里登记的一起写入提交说明文档。

而这样说法导致的现象又有哪些呢？经一段时间实践发现：
1、开发人员与测试人员无法在缺陷管理工具中实现交互。缺陷验证后开发人员只在提交说明文档里看验证结果，等于说这个提交说明文档已替代了缺陷管理工具成为交互平台。开发人员撰写提交说明文档会耗费更多时间，因为他们要把缺陷管理工具里的BUG ID号记录下来。
2、极有可能发生漏验。开发人员在撰写提交说明文档时有可能会漏写已修复的BUG，而由于测试人员只会验证文档里提到BUG，所以没写上但实际又修复的BUG是不会得到验证。

这样的缺陷管理流程在很大程度上脱离了工具，是一种耗时且不利于做缺陷度量统计的做法，同时也是软件在发布前未得到充分测试所导致的后果。