发布时间: 2009-12-07 14:38    作者: 天彤    来源: Taobao QA Team

　　缺陷跟踪过程是软件工程中的一个极其重要的过程。本文介绍了如何使用两个经典的分析模型，来控制缺陷跟踪的过程。这两个模型叫做《活动bug走势图》、《bug打开关闭图》。

　　另外，在文章中还会提到两个概念：“bug收敛”、“零bug反弹”，具体含义会在介绍中说明。

　　先看张图片，这就是两个模型的分析图片，集成在一个坐标里面了。活动bug走势是一条线，bug打开关闭是柱图，X轴是时间。下面我们详细说说这两个模型的含义。

　　先要说几个名词解释：

　　1、活动bug数。状态不是closed的所有bug的总数。活动bug指在项目中还需要大家去关注的bug，有的bug管理工具还有invalid、duplicate状态，这些是不属于活动bug的，但是later的bug，属于活动bug。

　　2、打开bug次数和关闭bug次数。每新增1个bug或者是reopen一个bug，打开次数都会被记加一。每close一个bug，关闭次数会加一。

　 　说明了这些概念，上面两个模型就比较好理解了。活动bug走势曲线上的每个点，表示当天软件中还存在多少个活动bug。这个数字越大，说明软件的质量越 差。而bug打开关闭图中，每天都会有红色、蓝色共两根柱子，表示当天打开、关闭bug的次数，如果当天这两个数字都很高，说明bug的处理非常活跃，软 件非常不稳定。注意，活动bug的单位是“个”，而打开关闭的单位是“次”，因此我们用线图和柱图分别表示。

下面讲一下模型的用法。一般的软件测试过程，都有3个阶段，从上面的图中能清楚的看出来。

　　阶段1：测试组对系统开始进行全面测试，打开bug的速度明显高于关闭bug的速度，活动bug数急速上升，当完成了全部测试用例的执行时，活动bug数达到最大；

　　阶段2：开发组全力修复bug，测试组一边验证bug，一边小范围的回归测试，验证bug的周边功能。这时，关闭bug的速度高于打开 bug的速度，活动bug数回落。当活动bug数刚开始回落的时候，称为“bug收敛”。最终，活动bug会降到一个很低的位置，有时，会达到“零bug ”，不过，这并不说明项目可以发布。

　　阶段3：测试组再次对软件系统进行一次完整的回归测试。在这个过程，还会打开一些bug，但是，数量很少，这称为“零bug反弹”。完成了这一轮回归之后，软件才真正稳定下来，进入发布候选过程。

　　所以，我们可以通过这两个模型，来检查项目的测试进展是否正常，软件的质量是否稳定，检查方法如下：

　　* 如果第二阶段已经开始，但是活动bug仍在继续上升，没有回落，说明打开bug速度仍很高，可能是第一阶段用例执行还没有完成，或者开发组修复bug速度较低；

　　* 如果第二阶段结束，活动bug没有回落到低水平，说明大量的bug还需要修复，软件质量低；

　　* 如果第三阶段，打开、关闭bug的次数很多，说明bug活动频繁，系统稳定性差。

　　因此，正常的项目测试应该是，活动bug先上扬，再回落，最后在低位小幅振荡，并且打开关闭次数很少。有了这两个分析模型，我们对项目进度得控制，就更有把握了。

其实这句话我已经不止一次看到了，每次看到这一思想，我就想把它宣导给我们老板，让他有个正确的认识。但我没有这样做，因为我没有想到好的阐述方式并找到合适的机会，而且对于独裁的老板，他会认为他的思想境界远高于你，就像他的口头禅：“我不想听你解释，你只要按照我的意思去做就可以了”

　　那些没有认识到“通过测试并不能保证质量”的主管们，在软件出了问题时，第一个想到的就是测试的问题，我对他们的这个条件反射表示理解，但也非常的忧虑，因为这会直接导致最终测试人员的绩效不好，而这也容易形成一个恶性循环。

　　而团队中也并非仅仅主管会不理解，客服人员最先埋怨的对象往往也是测试人员，因为表象显示的就是客服电话多，客户的问题没有测出来，那责任就应该是测试人员的了。当然对于他们的不满还是比较容易转移的，只要合理的解释说明，那么他们也会理解的。

　　而要扭转测试员的这一尴尬境地，解释或者自我检讨只能治标，就像作者所说的质量保证要来自整个项目团队，建制、建全软件开发过程，保证每一个节点、每一个阶段的质量，才是治本之道。

　　附注：

　　有一篇名为《需求与测试》的文章里有这么一段话：“其实我们有时候会抱怨需求为什么会考虑不周全，可是换个角度想想，我们认可程序会存在bug，那么需求同样也会有。这就像是一场接力赛，需求是第一棒，开发是第二棒，测试是第三棒，每一棒的交接都有上一棒的辛苦付出，也只有彼此信任和共同的努力，才能最终传递胜利。”

本文出自souchy的51Testing软件测试博客：http://www.51testing.com/?200708

　一、为什么做接口测试

　　目前的BS结构的软件层级体系大致如下，对此的功能测试也主要是针对表现层的内容，下图灰色的部分是未测试的内容（占80%的比例）。

　　

　　对于较小型的网站，通过表现层的测试，路径会大致渗透到下面各个层级。但是一个超大型的网站，其层级会有4层甚至更多，每一个层级又可能包含相互关联的不同业务。如同一个城市的自来水系统，如果只测试水龙头里面是否有水，水质是否优良，这显然远远不够。要想点办法对此进行改进，设想如下图。

　　

　　对于底下几层，采用单元测试，持续集成；对于表现层，采用QTP和类似的工具，编写测试代码，设计测试条件，做到大部分的自动化测试。这样以来，测试的覆盖率会大大提升（灰色部分占20%左右）。如此测试，从技术上来看并没有太大的障碍，从成本上来讲，就是需要大批的能写测试代码的技术人员，这些人员的技能丝毫不逊于开发人员，他们需要完成的测试代码量要高于软件本身的代码量。而一旦自动化的功能测试体系建立起来，在软件的重构和发展的过程中，测试的效率会大大提高。一个成熟的测试体系运转起来就像下图所示了。前图是测试的几个纬度，后图是功能测试的几个组成部分。

　　

　　

　　而整个测试的流程大致如下：（其中安全测试是功能测试的一部分）

　　

二、选用什么样的测试工具

　　基于Java技术的软件代码，有一些比较成熟的测试框架，Junit、Dbunit等等。Junit已经有了很长时间的应用，在JDK1.5之后，其推出了基于annotation的Junit4.4版，使单元测试的代码更加简洁，开发人员可以更加专注于对接口中业务逻辑的校验。Dbunit是一个测试数据的框架，它能够使用excel或xml文件里的数据来对数据库做插入，对比，删除等逻辑，可以完成数据的生成和校验。Junit和Dbunit结合使用就可以完成业务逻辑和数据方面的校验。

　　当一个项目的测试代码编写完毕的时候，我们需要对此进行持续集成，业界总是有一些慷慨无私的人来帮助可爱的开发人员，CruiseControl是一个不错的持续集成工具。每当有代码提交到版本管理工具的时候，它都不知疲倦的执行测试代码，通过邮件和IM软件告诉我们，哪些通过测试了，哪些发现问题了。这个时候你可以相当有自信的说“一切尽在掌握”，这神情会比刘德华都要帅。

　　但对于一个大型的网站来说，其单元测试也非测试“helloWorld”一样如此简单，最大的难题是解决代码之间的依赖性。淘宝网主演主要的架构是基于 Spring的，一般的系统分至少三层，业务层、逻辑层、持久层。spring架构下这三层通过配置文件来装载起来，持久层依赖于自己的配置文件、逻辑层依赖于自己的和持久层的、业务层依赖于三种配置文件。如果有发送邮件，调用外部接口等，还需要相应的配置文件和接口服务器。这种情况下，要做一个单元测试，需要配置很多东西，任何一个配置有误都无法启动spring容器，而且这些配置都在xml文件里面，内容是否正确无法自动检测。要做业务层的测试，不是一个容易的事情。其中持久层的东西相对固定，需要配置的文件也较少，相比较而言，这一层测试很容易完成，逻辑层和业务层的测试难度成指数性增长。

　　三、需要什么样的工作流程

　　我们不要提测试驱动开发，或者TDD之类的名词，适合我们的就是最好的，或许我们可以成为测试开发并驾齐驱。接口测试的工程师我们叫做测试开发工程师，在项目启动的时候就要参与进来，要做需求的分析，系统设计，在开发人员编写功能代码的同时，我们在编写测试代码，无所谓谁快谁慢，写好功能代码就测试，或者写好测试代码就写功能实现。当编码完毕的时候，也是接口测试完毕的时候，然后测试开发工程师写一份测试报告，送给功能测试工程师，告诉他们哪些东西我们测试过，哪些东西需要重点关注。

　　

　　当系统发布运行之后，功能修改的时候我们修改测试代码，平时我们就重点关注CruiseControl，一旦它报错，那一定是有些代码出问题了，Just fix it！

　　四、需要什么样的规范

　　Java编码规范想必都比较清楚，OK，去做好它。另外请在注释里面写清楚测试的场景，输入输出，异常情况。测试代码的可读性一定要高于功能代码。

　　五、到底是单元测试还是接口测试

　　OK，看这么多想必都搞糊涂了，我们测的是接口，写的是单元测试的代码，爱叫什么是什么吧。

快捷键的使用是否正常：

　　1. TAB 键的使用是否正确

　　2.上下左右键是否正确

　　3.界面如果支持 ESC键 看是否正常的工作

　　3.ENTER 键的使用是否正确切换时是否正常。

　　布局美感

　　界面的布局是否符合人的审美的标准

　　具体因人而依

　　输入框的功能：

　　输入合法的用户名和密码可以成功进入

　　输入合法的用户名和不合法密码不可以进入，并给出合理的提示

　　输入不合法的用户名和正确密码不可以进入，并给出合理的提示

　　输入不合法的用户名和不正确的密码不可以进入，并给出合理的提示

　　不合法的用户名有：不正确的用户名，，使用了字符大于用户名的限制

　　正常用户名不允许的特殊字符 空的用户名，系统（操作系统和应用系统）的保留字符

　　不合法的密码有：空密码（除有特殊规定的），错误的密码，字符大于密码的限制

　　正常密码不允许的特殊字符，系统（操作系统和应用系统）的保留字符

　　界面的链接：

　　对于界面有链接的界面，要测试界面上的所有的链接都正常或者给出合理的提示

　　补充

　　输入框是否支持 复制和黏贴 和移动

　　密码框显示的不要是具体的字符，要是一些密码的字符

　　验证用户名前有空格是否可以进入，一般情况可以。

　　验证用户名是否区分大小写。（有的软件是区分大小写的）

　　验证必填项为空，是否允许进入。

　　验证登录的次数是否有限制。从安全角度考虑，有些安全级别高的软件会考虑这方面的限制。

随着软件系统应用环境的复杂性，软件出错的机率越来越大了，软件面临着一个非常关键的需求就是在系统出错后能进行恢复。我是公司软件开发测试组负责人，今天老板在测试会议上批评我说，目前用户最大的抱怨是我们的系统缺少自动恢复功能，出现错误后许多的恢复过程都要人工干预来完成，说明我们的可恢复测试仍然很混乱，而且可恢复测试是完全失败的。

　　不容忽视的软件可恢复测试

　　（1）什么是软件可恢复性

　　随着软件应用的日益普及，对软件质量的要求也不断提高。软件质量是指软件产品中能满足给定需求的各种特性的总和。ISO/IEC 9126中规定了软件的6个质量特性，即功能性(Functionality)、可靠性(Reliability)、易用性(Usability)、效率性(Efficiency)、维护性(Maintainability)和可移植性(Portability)，每个特性包含若干子特性。

　　可靠性是指在规定的一段时间和条件下，软件产品维持规定的性能水平的能力。3个子特性分别为：成熟性（Maturity）、容错性（Fault tolerance）、可恢复性（Recoverability）。其中容错性是指与在软件错误或违反指定接口的情况下，维持指定的性能水平的能力有关的软件属性。而可恢复性是指在故障发生后，重新建立其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需的时间和努力有关的软件属性。

　　一般来说，许多基于计算机的软件系统必须在一定的时间内从错误中恢复过来，然后继续运行。也就是说在某些情况下，一个软件系统应该是在运行过程中的出现错误时能自动或人工进行恢复，不能使整个系统的功能都停止运作，否则就会造成严重损失。因此，软件可恢复失败包括两个方面：一是软件系统没有自动的恢复到原来的性能，这意味着恢复需要人工干预；二是即使是人工干预后，也不能恢复到原来设计性能，例如软件所涉及的数据出现某种程度的失效和损坏。

　　（2）什么是可恢复测试

　　软件测试是发现软件中的大部分缺陷的一种技术。软件测试大体上划分为三大阶段：单元测试、集成测试、系统测试。系统测试是检验整个系统是否满足《需求规格说明书》所提出的所有需求。其中系统测试的非功能性测试包括可靠性测试、容错测试和恢复性测试等。

　　可恢复测试（Recovery testing）是测试一个系统从灾难或出错中能否很好地恢复的过程，如遇到系统崩溃、硬件损坏或其他灾难性出错。可恢复测试一般是通过人为的各种强制性手段让软件或硬件出现故障，然后检测系统是否能正确的恢复（自动恢复和人工恢复）。简单的说，可恢复测试是一种对抗性的测试过程。在测试中将把应用程序或系统置于极端的条件下或是模拟的极端条件下产生故障，然后调用恢复进程，并监测、检查和核实应用程序和数据能否得到正确的恢复。

　　可恢复测试通常需要关注恢复所需的时间以及恢复的程度。例如，当系统出错时能否在指定时间间隔内修正错误并重新启动系统。对于自动恢复需验证重新初始化（Reinitialization）、检查点(Checkpointing mechanisms)、数据恢复(Data recovery)和重新启动 (Restart)等机制的正确性；而对于需要人工干预的恢复系统，还需估计平均修复时间，确定其是否在可接受的范围内。

　　因此，随着网络应用、电子商务、电子政务越来越普及，系统可恢复性也显得越来越重要，可恢复性对系统的稳定性、可靠性影响很大。但可恢复性测试很容易被忽视，因为可恢复测试相对来说是比较难的，一般情况下是很难设想得出来让系统出错和发生灾难性的错误，这需要足够的时间和精力，也需要得到更多的设计人员、开发人员的参与。

　　（3）容错测试与可恢复测试的区别

　　容错测试一般是输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统会给出提示或内部消化掉，而不会导致系统出错甚至崩溃。而可恢复测试是通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能很快恢复。因此，可恢复测试和容错测试是互补的关系，可恢复测试也是检查系统的容错能力的方法之一，但不能只重视其中之一。

　　（4）故障转移测试和可恢复测试的关系

　　故障转移测试(Failover)指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统可以正常运行，这对于电信，银行等领域的软件是十分重要的。因此，故障转移是确保测试对象在出现故障时，能成功地将运行的系统或系统某一关键部分转移到其它设备上继续运行，即备用系统将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务，不影响用户的使用。

　　故障转移测试和可恢复测试也是一种互补关系的测试，它们共同可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。因此，他们两者的关系一个是测试备用系统能否及时工作，另一个是测试系统能否恢复到正确运行状态。

可恢复测试主要内容和步骤

　　（1）恢复性测试的基本内容

　　通过可恢复测试，一方面使系统具有异常情况的抵抗能力，另一方面使系统测试质量可控制。因此，可恢复测试包括以下几种情况：

　　① 硬件及有关设备故障。测试对于硬件及设备故障是否有有效的保护及恢复能力，系统是否具有诊断、故障报告及指示处理方法的能力，是否具备冗余及自动切换能力，故障诊断方法是否合理和即时。例如，设备掉电后（如客户端和服务器端断电）的可恢复程度。

　　② 软件系统故障。测试系统的程序及数据是否有足够可靠的备份措施，在系统遭破坏后是否具有重新恢复正常工作的能力，对系统故障是否自动检测和诊断的功能。故障发生时,是否能对操作人员发出完整的提示信息和指示处理方法能力，是否具有自动隔离局部故障,进行系统重组和降级使用使系统不中断运行。还有，若系统局部故障可否进行占线维护,而不中断系统的运行。最后，在异常情况时是否记录故障前后的状态,搜集有用信息供测试分析。

　　③ 数据故障。是测试数据处理周期未完成时的恢复程度，例如数据交换或同步进程被中断，异常终止或提前终止的数据库进程，最后还有操作异常等情况。

　　④ 通信故障和错误。测试有没有纠正通信传输错误的措施，有没有恢复到与其他系统通信发生故障前原状的措施，还有对通信故障所采取的措施是否满足运行要求等。

　　（2）可恢复测试的基本流程

　　首先需要制定可恢复测试计划，并准备好可恢复测试用例和可恢复测试规程。其次，是要对照基线化软件等级和基线化需求分配。第三，进行软件可恢复测试。在此过程中，要用文档记录好在可恢复性测试期间所出现的问题并跟踪直到结束。然后，将可恢复测试结果写成文档，说明测试所揭露的软件软件能力、缺陷和不足，以及可能给软件运行带来的影响。最后，说明能否通过测试和测试结论，并提交可恢复测试分析报告。

　　可恢复测试经验总结与分享

　　从测试技术和测试管理的角度来看，目前对高可靠性软件测试特别是可恢复测试方案，许多测试人员还缺乏真正的认识。因此，对需要高可恢复的软件如何实施可恢复测试，在技术和经验上仍是一个颇不成熟的领域，更缺少一种体系化的方法。

　　（1）必须从认识上有足够的重视和关注

　　让人非常遗憾的是在可恢复测试上，许多测试人员还缺乏足够的重视和关注。例如，许多测试人员认为只要我们有制定可恢复测试方案，有获得所需的硬件和软件，配置了系统，然后也有测试故障转移和灾难恢复响应系统，一切按照预期计划进行就OK了。但是大多数的测试人员只会在常规环境下进行可恢复测试，并没有想尽一切可能的办法在更多的不同环境下的进行可恢复测试，结果是他们并没有确保自己进行了足够的可恢复测试。

　　（2）必须制定明确的测试计划和测试制度

　　如果没有制定明确的测试计划和需要遵循的测试制度，那么测试就会马虎了事，根本无法满足可恢复测试的要求。那么完成测试目标也成了空中楼阁，软件可恢复性质量也无从谈起了。

　　（3）必须要用真实数据进行测试

　　用真实数据进行真实测试是可恢复测试中最棘手的部份。因为在没有用真实数据测试的时候，就很难评价系统进行可恢复或故障转移过程中的各种技术指标的有效性。我在可恢复测试中得到的宝贵经验是，用真实数据进行测试会得到让人难以接受的事实，但这是提高软件测试质量的关键之一。

　　（4）确保测试过程和文档的一致性

　　软件可恢复测试工作还包括：验证应用程序不同环境下的表现、书面需求分析文档、联机帮助、界面资源等。因此，当进行可恢复测试活动时，应确保测试手册、联机帮助、测试分析报告和应用程序测试需求的完整性和一致性。