我们做软件测试的，往往都是以Bug量多为衡量标准。测试的目的是为了发现更多的Bug，这点永远都不会错，但我们经常会为追求更多的Bug而忽略了软件测试的更本质的东西，个人认为软件测试的终极目标是提供给一个让客户满意的产品和服务。所以说，我认为只有真正去理解客户所关注的业务，才能从本质上更好的改善我们的工作。
目前的问题或许有过这样的经历，一个软件（项目），在测试过程中往往会发现几百个甚至几千个Bug，可是客户依然对我们所提供的质量保障喋喋不休。从我经历的一些项目和产品来说，感觉不外乎三个原因：
1. 我们测试的力度和深度依然不够。
我感觉主要是人力资源和时间上的紧缺造成的。人力资源，通常一个产品测试，往往都是一个人负责好几个模块，项目上更是一个人既负责环境搭建，又要负责测试用例的编写，还有负责功能测试以及最后的报告编制，很难做到面面俱到。加之一些项目客户要求的时间紧张，所以最后测试即便能够达到通过标准，在客户那里依然会有很多问题，当然，这其中的原因也包括需求设计的不确定以及后期的变更。
2. 环境的不同，包括硬件环境和软件环境。
在我们内部测试，不仅需要一个干净高效的系统环境，我们的个人电脑，也就是通常意义上的客户端，往往都是比较高的配置。而在客户现场，这些几乎都很难一致。加之客户现场的一些突发事件，都会造成一些低级但很严重的Bug。
还有一个比较重要的问题，就是数据环境。因为我们测试往往都是在一个干净的系统里新建一套帐，再手动或自动化初始一些简单的数据，然后再分配职责进行测试。而客户现场的情况则要复杂的多，很多都是在原有数据的基础上进行安装、升级或者移植，这些案例我们实际考虑的并不是很多或很全面。
3. 也就是我感觉最重要的一点，就是测试过程没有真正以客户关注为焦点。
测试有时遇到这样的情况，拿来一个模块可能知道一些业务流程知识，或者是一点不知。测试主要就是通过自己的操作和理解，加上一些与开发人员的交流来进行。测试过程大都通过菜单一级一级的往下进行，数据都是通过自己的经验来组织出来的，感觉主观性比较大。所进行的测试，大多应该称为功能测试，而不是业务测试。最后能够确保所测的功能点不出错误，但是却没有真正的站在客户的角度去理解这个软件、这个功能。
建议个人认为最重要就是测试尽量全面的模拟客户现场。感觉可以通过一下几点来进行改善。
1. 制定比较完善的测试周期。
大体可以分为三个阶段：
1) 单元测试。这个测试可由开发人员或设计人员自行完成。主要是验证所写的功能和设计的一致性，当然前提是设计最好是能确定以及肯定。
2) 集成测试。这个测试阶段主要的目的是能够确保整个功能流程能够走通，无严重错误。
3) 真实业务测试。严格按照客户的业务流程、数据和职责进行测试。这个感觉目前实现起来还是比较困难，主要是对真实业务的理解需要深入。但如果能有一套完善的测试用例，相信这个阶段还是可以实现的。
2. 测试环境搭建尽量模拟客户现场。
可搭建多种测试环境，或者分Build搭建不同的测试环境。可有新建帐套，也有旧帐套基础上进行升级测试。感觉这个我们目前开展的还是比较多的，也是蛮有效果的，以后可重点再关注一下升级后原有数据的验证和操作。
3. 测试过程要真正以客户关注为焦点。
我们可以通过与各方面人员交流和自己的学习，首先要弄明白一点，客户想用我们的软件实现什么，也就是客户使用我们软件的目的，包括各个职责的，例如系统管理员想通过我们软件实现什么，经理想实现什么，出纳、会计、审计他们分别想实现什么。因为很可能会有这种情况：我们测出了成百上千的个Bug，但是客户最为关注的东西我们所涉及的却不多，而把太多的测试工作都投入到客户并不是特别关注的功能上来了。
等这些明确后，再去进一步分别了解这些目的是怎么实现的，实现过程中需要分步骤分别操作那些功能（业务）。如果这些都明确后，我们就可以组织一些具体详细的数据，严格按照客户的实现方法进行走查，这个过程最好能与客户或者熟知客户业务的人员一同进行。当然，这只是测试的一个阶段，之前的全方面集成测试还是必不可少的（主要用来发现影响流程的严重Bug）。
再就是一点，测试过程中，一定要充分利用需求设计和数据结构，应该会对功能点业务测试以及数据验证起到很大的作用。
以上文字都是根据个人的工作经历所总结，肯定会有很多不足或欠妥之处，希望大家多多批评指正。