缺陷管理

　　测试执行过程中发现的任何问题以及与需求不一致或者在某种程度上不能满足用户的需要的地方，都需要由测试工程师递交缺陷记录到缺陷管理系统进行统一跟踪和管理。缺陷本身不仅可以根据常规的严重等级进行分类，也可以根据缺陷的内容分为功能未实现或实现错误缺陷和程序缺陷。通常而言，缺陷管理需要解决以下两个问题：一是确保每个被发现的缺陷都能够被追踪并且最终被解决，二是收集缺陷数据并根据缺陷趋势曲线识别和预防类似缺陷的频繁发生。在谈到缺陷管理时，首先想到的是如何修正缺陷，而对根据缺陷分析进行有效预防缺陷却很容易忽视。事实上，在一个CMMI等级较高的项目团队中，缺陷数据的收集和分析是必须的，可以从缺陷数据中得到很多与软件质量度量的相关数据。

　　任何一个软件团队或组织都必须建立完善有效地软件缺陷跟踪与管理流程。没有完善的缺陷管理机制，将会使软件项目陷入失控状态，使测试人员递交的缺陷无法全面地追踪和管理，甚至会被遗漏，或没有人知道在新的软件版本里究竟纠哪些缺陷被修正了以及如何修正的，还有哪些缺陷未被纠正以及没有在该版本中修正的原因。更重要的是修正过程是否引入了新的缺陷以及新的缺陷是由那部分修正引入的也无法追踪。一个相对完备的缺陷管理过程通常会包括如下几个方面：

　　● 提交缺陷报告

　　● 评审缺陷分类并最终确定严重等级

　　● 分析和定位缺陷

　　● 评估影响范围并确定待修正版本

　　● 修正方案的同行评审以及评估可能的影响

　　● 执行软件修改

　　● 软件修改的代码评审

　　● 代码递交

　　● 缺陷修复验证

　　● 影响范围验证

　　测试总结

　　这个阶段的工作每个公司的差异会很大，不同软件能力成熟度的公司的关注点差别也很大，这里我就不想一一去举例了。只是简单提两点共性的目标，首先，需要汇集组织内部以前项目的经验教训，收集测试度量数据，制定组织级的量化度量指标。其次，一切工作需要围绕测试流程的持续性改进，从而使过程能力得到不断的提升。

　　测试维护

　　测试维护包含几方面的工作，第一是当软件正式发布后，在上线使用过程中难免还会有遗漏的缺陷暴露出来，这时候就需要修正这些问题，修正后再次对软件进行验证测试和有限的回归测试。第二是软件版本的升级会引入新的测试需求。第三是软件版本升级后自动化测试用例的维护与扩展。

　　51Testing：是否大公司的测试流程都是好的、完善的测试流程？如何合理的制定软件测试流程？

　　茹炳晟：在讨论这个问题前，想先谈论一下我对流程的理解。流程是在某个特定上下文环境下固化下来的行事规则与经验，因为曾经已经取得过成功，并且也吸取了一定的经验教训以规避失败，因此在相同的情况下，流程会带来更大的成功概率，并形成权威，使后来者有效应用先前的成功经验，少走弯路提高效率。适合的流程能够指导人们正确地完成各种开发活动；而不合适的流程，则会把软件项目推入无底深渊。但是，就流程本身而言，我个人认为并没无好坏优劣之分，或者说衡量流程的度量指标不应该是好与不好，而应该是流程对当前组织或者项目的适用程度，只有真正适合自己团队的测试流程才是好的测试流程。有些重量级的流程固然有其权威和周全的考虑，但是对于小规模团队或者敏捷团队却完全不适用，靠行政手段强行推广只会适得其反，而有些看似很粗超简陋的流程却非常适合一些极具创新的研究型团队。所以说流程不能被神话，更不能被滥用。世界上不存在放之四海而皆准的流程，而只有因地制宜、因人制宜地选择合适的流程，并在执行过程中不断地加以改进和完善，才有可能取得成功。具体到测试流程的制定和完善，我想这也是一个非常庞大的话题，这里我就想简单提几条我个人认为比较好的最佳实践吧。

　　1、切记，不要盲目拷贝大公司的测试流程，而是要吸取他们的经验教训，取其精华去其糟粕，这样的测试流程对于我们来说才是有价值的，有改进意义的。

　　2、测试流程需要尽可能使得被测系统尽早地，频繁地进行测试，使问题在项目的早期尽可能多的暴露

　　3、流程需要能够有效加强各个团队间的交流与沟通，让每个项目干系人都有明确的渠道了解项目的测试状态和完成情况

　　4、流程上保证整个测试活动必须被计划，被控制，并且必须提供必要的时间与资源