随着信息技术在国内不同行业应用的开展，人们已经不再怀疑软件对于社会运转的巨大作用。但是，随着人们对软件作用期望值的提高，已经有越来越多人将关注点转移到软件的可靠性上，因此，国内软件测试公司或测评中心如雨后春笋般出现。

软件测试并非万能药

我们在进行软件测试市场开发的过程中，发现了这样的一个问题:不少企业认为软件测试确实很重要，于是提出:我将执行程序(或者还有没有写完整的用户手册)给你，你给我测吧(“对不起，代码不能给，因为涉及产权问题”);如果测完通过了，用户就不应该再可能提出问题了。如果最终用户提出了问题，企业就会找到软件测试公司:“看，你是怎么搞的，用户提出了问题，你们为什么不能通过测试找到问题？”。

我们也遇到这样的情况，某地软件开发商与用户多次出现因软件质量引发的纠纷。于是该公司找到我们说:“既然你们是软件测试的行家，你们来做测试吧，只要测试费用一个软件控制在2万元以内，我们给你们介绍生意。”最终我们没有敢承担这样的业务，因为我们担心会陷入进退维谷的境地。因此也可以看到，人们对软件测试的理解存在一些误区。

对于航空工业之中最高级别的软件，为了保障其可靠性，进行测试的工作内容包括语法规则检查和程序分析、条件覆盖、边界覆盖、语句分支覆盖、需求覆盖、强壮性、功能性及输入输出的测试，最终全部通过，也只能保证10-9的缺陷概率。

因此，软件测试是提高软件质量与可靠性的重要一环，但并不意味着有了软件测试，软件就不存在问题了。如果仅仅是模拟用户进行一下简单的试用，则对于软件质量的验证效用就更差了。

不妨做一个类比，如果一个工程验收时，外部装修极为符合标准，给人的感觉十分良好，我们是不是可以断定这个工作是质量优良的好工程呢？实际情况经常是，里面豆腐渣外面金钢玉。当然你打开水龙头、打开灯泡不会有问题，如果出现了火灾、大风，这个工程还行吗？不知道。为什么不知道？因为没有看到施工过程是否符合规范;施工过程即使合格，不知道材料是否合格。

因此，软件测试并不是保障软件可靠性的万能药。

软件测试要分层

如果仅凭用户手册，做出来的用户验收测试仅仅是以偏概全的特例测试。有经验的测试者不过是将测试用例设计得更科学些系统些，另外就是增加一些强壮性测试及压力测试。对于一个安全性可靠性要求不是很高的软件，这样做也许就够了。

但是，我们知道，目前我们国家在搞以“十二金”为代表的电子政务工程。这些工程中涉及财税的部分以及电信、金融、保险、航空、航天等高科技领域或对软件可靠性要求高的领域，他们的对软件的测试仅仅如此是远远不行的。不妨简单地想象一下，航空机载嵌入式软件要求出现缺陷的概率是10-9，仅凭前面的测试能够满足要求吗？

而进行如此严格要求的测试，投入的人力与财力将是十分巨大的。一般来讲，至少是开发费用的3~5倍，而且要求开发过程十分规范。

总体来讲，我们不赞成简单地进行用户模拟测试的方式，因为这种做法欠系统和完整。

我个人认为，进行验收测试要完成如下工作:功能遍历、链接测试、界面测试、稳定性测试、数据接口测试、安全性测试、性能测试、负载测试、压力测试、平台测试、浏览器测试、强壮性测试等等。

如果在测试过程中发现问题，则要根据相关的设计文档，将问题隔离到部件进行部件测试。对于核心模块，如功能核心或主要的控制部分，则要进行模块一级的白盒测试。

测试应与开发过程控制相配套

许多开发商或用户关注软件质量也重视软件测试，但是由于其开发过程尚不规范，往往导致测试，尤其是模块级的黑盒与白盒测试难以正常开展。原因很简单，就是缺少详细的设计文档以及对应于各模块代码的流程图与接口关系。其结果测试就如盲人摸象——仅靠读程序是不能看出程序本身是否与设计思想一致、软件的输入输出的正确性的。

因而，要进行软件测试，特别是严格的软件测试，软件的开发过程不要仅符合一般的规范;不仅如此，文档的完备、细致化程度也应相当高才行。为保证测试效果及回归测试的顺利开展，开发过程的配置管理也应该严格有效。

“巧妇难为无米之炊”。作为专业的软件测试公司，我们希望通过我们的努力也通过开发商和用户的共同努力，完善并改进开发流程的过程控制和开发文档，使测试工作能更好地提高软件的可靠性。