以客户关注为焦点看软件测试

　　软件测试的终极目标是给客户提供满意的产品和服务。因此，只有真正去理解、熟悉、分析客户所关注的业务，才能给客户提供高质量的产品。本文从包括客户的使用目的、客户的使用预期、客户的部署环境、客户的数据甚至客户的使用习惯除非，讲解如何才能从本质上更好的改进测试的重点与方向，抓住测试的精髓，给客户提供高质量的产品。

　　众所周知，在软件测试行业，往往都是以软件 Bug 数量来衡量软件的质量。一个软件被测试团队发现有大量 Bug 时，该软件的质量被认为处在不高的水平。当较少的 bug 被发现时，软件则被认为是具有较高质量的。测试的目的是为了发现更多的 Bug，然而测试人员经常会为追求发现更多的 Bug 数量而忽略了软件测试更本质的东西。软件测试的终极目标是给客户提供满意的产品和服务。因此，只有真正去理解、熟悉、分析客户所关注的业务，包括客户的使用目的、客户的使用预期、客户的部署环境、客户的数据甚至客户的使用习惯才能从本质上更好的改进测试的重点与方向，抓住测试的精髓，给客户提供高质量的产品。

　　当前的问题

　　软件测试人员一般都会遇到这样的问题。一个软件(项目)，在测试过程中往往会发现几百个甚至上千个 Bug，测试团队的经理以及所有测试人员认为发现如此多的缺陷，软件应该已经被严格把关，最终交付给客户的软件应该是比较合格，至少不会有高级别的或者严重影响客户使用的缺陷被客户发现。然而当软件被客户部署投入生产线后，大量的缺陷被客户报出来，而这些缺陷是测试团队在测试中忽略掉的。仔细分析，主要由下列原因造成。

　　测试的力度和深度不够。

　　首先是人力资源和时间上的紧缺造成的。通常一个产品测试，往往都是一个测试人员负责好几个模块。项目上测试人员要负责环境搭建，测试用例的编写，测试的执行以及最后的报告制作。测试的每一个环节都非常耗时，而且很难做到并行工作，最终导致测试在力度以及深度上很难面面俱到。有时一些项目客户要求的交付时间紧，所以最后测试即便能够达到通过标准，在客户那里依然会暴露出很多我们在测试中忽略的问题。其次是遇到一些特殊情况。当一个新版本产品正在紧张的测试准备按时交付时，而客户在使用上一版本的软件时遇到紧急问题，需要测试团队进入 7*24 小时解决状态，这时候必然会连带影响到新版软件的测试质量。另外，需求设计的不确定以及后期的变更也会导致此类问题。

　　某项目开发与测试团队在解决某客户因为软件缺陷导致的紧急问题，该紧急问题严重影响阻碍客户的正常工作，因此被要求在短期内给出解决方案。由于该问题的复杂性，开发团队用掉了大部分时间才解决了该问题。由于交付的时间已定，留给测试团队的时间已经不可能完成一定力度和深度的测试，人力匮乏的测试团队只能保证原软件缺陷本身被解决，同时产品的大功能保证可用，非常重要的扩展测试由于时间问题被省略。可以想象，在客户的环境中，解决该缺陷所引起的回归问题被客户发现。如果时间和人力充足的测试团队完成了扩展测试，这个回归缺陷就不会出现。所以只有充分的测试时间以及充足的测试人员才能保证测试的力度和深度，从而提高软件质量。

　　环境的不同，包括硬件环境和软件环境。

　　大部分测试团队在测试时，模拟测试的硬件环境都非常优良。客户端主要用笔记本电脑来模拟，服务端用台式机或者一些虚拟机等等。这些设备往往都是比较高的配置，而且电脑之间通讯所用的网络基本是有线网络，速度也非常高。而在客户现场，部署我们产品的所用的设备环境很难与测试团队优良的测试环境相一致。客户的客户端有的配置很低，网络也比较慢，有线网络以及无线网络等如图 1：客户测试团队环境对比图。另外客户环境的一些突发事件，例如无线网络不稳定，有线网络突然断网，设备断电等都会造成一些低级但很严重的软件缺陷。

　　某客户部署软件的环境属于客户端低配、网络是慢且不稳定的无线网络。在优良测试环境测试通过交付的产品在客户的部署环境上，当客户端与服务端进行上传下载交互时，客户端的软件崩溃，数据不能正确传输到服务端。同时在服务端的日志里，记录了大量交互的出现的错误。

　　还有就是模拟软件环境，主要是数据环境。测试团队的测试往往都是在一个干净的系统里新建一套账号，再手动或自动化初始一些简单的数据，然后再分配职责进行测试。而客户环境的情况更复杂，所用的数据也更复杂。客户习惯在原有数据的基础上进行安装、升级。

　　某客户在使用先前版本的软件时，创建了一些项目，存储了一些数据。当升级安装了新版的软件时，某些功能会出现不可用，或者客户的数据丢失，这将是很严重的问题。客户建立的复杂逻辑数据往往能发现产品的缺陷，而这是测试团队用简单数据无法发现的。

　　所以要模拟客户的硬件环境和软件环境来发现一些在测试中被忽略的问题。

　　图 1. 客户测试团队环境对比图

　　整个测试进程没有站在客户角度上，以客户关注为焦点进行软件测试。

　　测试人员在进行软件测试之前，首先会按照被测模块的 FDD(功能设计文档)和 TDD(技术设计文档)，通过自己对对该模块的理解以及与相应开发人员的讨论，最终形成一份被测模块的测试用例文档。测试时，按照测试用例，和测试人员自己准备的测试数据，通过菜单逐级向下进行。测试人员的经验在这样主观性很大的测试中占据了很大比例。这样的测试，可称为功能测试，而不能完全称为业务测试。它能够确保所测的功能点正常，然而没有真正的站在客户的角度上，去理解、分析客户所关注的业务，包括客户的使用目的、客户的使用预期、甚至客户的使用习惯等。测试人员在这个模块的某功能点测出了很多缺陷，但是在客户的业务中，一个经常使用的功能点却没有被测试人员重视。某客户的业务是使用业务分析中数据收集的产品进行某项目的电话采访，该项目主要是获取世界一些国家像美国、印度、马来西亚等的市民对信用卡业务的满意度。客户在美国的采访项目，产品正常。因为软件的默认语言为 English(UnitedStates)，所以软件在交付前被仔细深入的测试过。然而在印度的采访项目，由于访员都是印度人，当软件语言被设置为 English(India)时，客户发现很多软件功能不可用。如果测试团队认真分析过客户的业务，就会知道客户在印度有机构分布，大量的业务在印度的机构运行。所以软件语言被设置成印度英语后的功能的正确性将是一个非常重要的测点。

原文转自：http://www.ibm.com/developerworks/cn/rational/r-cn-customerperspecttesting/index.html