面对用户反馈的缺陷: 我们能做些什么

面对用户反馈的缺陷：我们能做些什么

穷尽测试是不可能的，这是软件测试的一条基本原则。通过测试并不能发现和修改测试对象中的全部的缺陷和问题，因此，不可避免有一些缺陷会遗漏到客户的使用现场，从而触发软件产品产生令用户不满意的失效或者各种问题。那么，测试人员在面对用户反馈的缺陷的时候，我们能够做些什么？本文将从几个方面来回答该问题。

1）DDP

首先，测试人员可以根据用户反馈的缺陷数目，来判断和分析测试人员在测试过程中的测试有效性。通常来说，在测试过程中判断测试人员的测试有效性是很困难的。但是通过用户反馈的缺陷数目，却可以直观的说明测试人员是否遗漏了比较多的问题，从而反映测试人员的测试有效性。
缺陷检测百分比DDP（Defect Detection Percentage）就是基于这样的目的进行定义的，它可以用来评判软件测试生命周期内某个阶段的测试有效性，它以百分比的形式进行计算[1]。其计算公式为：
DDP = [R1 / (R1 + R2)] * 100%

其中：
°         R1指的是被评估阶段发现所发现的缺陷数目；
°         R2是被评估阶段之后所发现的所有的缺陷数目；
注意：DDP计算公式的分母并不是发现的总的缺陷数目，而是指该阶段之后所有发现的缺陷数目（包括该阶段的缺陷数目）。另外，采用DDP作为测试有效性的评估指标，存在的一个问题是需要在产品发布一段时间之后才能进行，例如：产品发布之后3个月。
表1是计算DDP的一个例子（主要针对动态测试而言的）：

 

 

2）过程改进
用户反馈的缺陷，是进行过程改进的重要输入。通过收集和分析从用户使用现场反馈的缺陷，可以回答“为什么这些缺陷会遗漏到用户现场”这样的问题。假如测试人员可以找到这个问题的答案，那么就可以将该分析结果应用到下个项目的测试过程中，以尽量减少此类问题再次遗漏到用户现场，从而达到过程改进的目的。
下面是笔者在对用户反馈的缺陷进行分析过程中，对遗漏到用户现场的原因进行的分类。对用户反馈的缺陷进行分类，可以更好的帮助测试人员查找遗漏该缺陷的原因，从而为过程改进提出更加明确和直接的建议和方案。缺陷遗漏到用户现场的主要原因可以是多样的，例如：
（1）需求的原因
通常来说，软件产品或者系统开发和测试的基础是需求，因此需求定义的质量直接决定了测试对象的质量。而测试人员经常面对的需求是不全的、模糊的，甚至是不正确的。
在分析某个产品用户反馈的缺陷过程中，发现用户针对系统R1.0版本配置的数据库，并不能直接在升级之后的R2.0版本中使用，用户认为这极大的浪费了客户的配置时间，也对该产品的易用性产生了某些怀疑。项目利益相关者对该类型的缺陷分析之后，发现测试人员并没有针对这样的场景进行测试，而更深层次的原因是系统的需求中并没有定义可移植性的非功能特性。
分析了该类用户反馈的缺陷之后，项目团队将可移植性非功能特性作为评审软件工作产品的检查表的一个检查点，以避免在将来的项目开发过程中遗漏该质量特性。
（2）测试设计问题
有些缺陷遗漏到用户现场的原因，是由于测试人员在测试设计技能方面的欠缺。测试设计技术和方法是有效开展测试用例设计的基础，测试人员掌握的技术和方法越多，就越有利于他们设计更好的测试用例。
在分析某个产品用户反馈的缺陷过程中，发现IGMP协议在有些情况下不能和其他产品的IGMP功能协调工作，并且最后定位是由于我们产品的IGMP协议方面存在问题。后来在系统人员、开发人员和测试人员的共同努力之下，分析得知是由于IGMP的状态转换存在问题，特别是状态在进行连续几个转换之后容易出现问题。主要的原因是测试人员在设计IGMP状态转换测试用例的时候，由于没有掌握状态转换测试技术，导致其测试覆盖率偏低，从而使得该类问题遗漏到用户现场。
对于这样的问题，测试团队需要经常的进行合适的测试技术和方法的培训，例如：针对上面的案例，测试团队后来开展了状态转换测试的深入的学习和培训，并在后续的类似状态转换测试中，每个测试人员都可以熟练的应用0-Switch和1-Switch的状态转换技术。
（3）测试资源问题
有些用户反馈的问题，既不是需求定义的遗漏或者不明确，也不是测试人员没有合适的测试用例设计，而是由于测试资源方面的问题导致的。
用户在实际的网络使用环境中，发现并不能达到2000个IGMP用户同时进行视频点播的性能要求，从而提交了一个严重程度比较高的缺陷。在分析该缺陷的过程中，发现该产品的需求定义中有明确的规定要求达到2000个用户同时点播的要求，而在测试用例规格中，也有相应的测试用例存在。但是由于测试资源的限制，测试人员无法执行该测试用例，使得该产品发布的时候，该用例还是处于block状态。
对于此类测试资源的问题，一个解决方案是购买能够模拟2000个IGMP用户的测试仪表，另一个可行的方案是测试团队自己开发IGMP用户的模拟器。
（4）回归测试问题
有些用户反馈的问题，是由于修改某些缺陷之后新引入的，或者由于修改某些缺陷触发了其他潜在的缺陷。导致此类问题的主要原因是，在选择回归测试用例的时候，其修改的影响分析和风险风险做的不仔细和不完善。
对于这些问题，也就要求测试人员更加深入的学习和理解被测对象的内部结果，以及对失效模式和影响分析、风险分析等技术提出了更高的要求。通过学习和培训，可以逐步提高测试人员在这些方面的能力。
（5）测试环境和使用环境的不同
用户反馈的缺陷是由于测试环境，和用户实际的产品使用环境存在较大差距而引起的。例如：测试人员在测试产品的图形化用户接口GUI的时候，一直采用的浏览器是IE7.0。而在用户的使用环境在有FoxZilla、IE5.0等，导致产品的兼容性出现问题。
因此，在高级别的测试执行中（比如系统测试和验收测试），要求测试环境能够尽量贴近用户的使用环境。尽量模拟用户使用环境，一方面可以在我们的测试执行过程中，发现我们的软件产品和其他协同工作的产品之间的兼容特性，避免软件发布给用户之后才发现这些问题；另一方面，也可以用来检验我们的产品是不是用户真正需要的产品。
为了达到这些目标，测试团队必须了解用户的软件产品使用环境，比如用户使用该软件产品的操作系统、和我们软件产品对接的产品是什么、用户使用该产品可能的网络拓扑结构是什么（用户使用该软件产品的主要用户场景等）。因此，我们的测试团队在了解和熟悉我们的系统需求和实现之外，也需要去掌握和发现用户可能的使用场景，以及其他竞争对手产品的一些功能和特征属性。另外，在可能的情况下，邀请产品的潜在用户参与我们测试环境的搭建，或者征询用户在环境搭建方面的一些要求和建议，帮助我们来模拟用户的使用环境，从而减少可能和用户使用环境背离太多而导致的风险，提高我们的测试效率和测试质量。
（6）穷尽测试是不可能的
穷尽测试是不可能的，因此，测试团队在有限的时间、资源的情况下，无法发现测试对象中的所有缺陷，也就是说遗留到客户现场的缺陷是不可避免的。而我们能做的是，如何不断完善我们的需求、背景知识、测试技术、测试环境等，从而不断提升我们的测试能力，不断提高我们的DDP。
上面是我们分析用户反馈的缺陷过程中，经常采用的缺陷分类。但该缺陷分类并不是全面的，需要我们在测试过程中不断的修改和更新，从而不断完善我们的缺陷分类。

假如读者有什么好的建议，请不吝赐教。
 

参考资料：
[1] Dorothy Graham, Grove Consultants, www.grove.co.uk

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Wenqiang_Zheng/archive/2010/10/17/5947299.aspx