我有一个“疯狂”的想法：在理想的情况下，如果自动化软件测试方面的知识积累足够丰富，自动化测试工具足够先进，如果我们可以把软件测试中积累的知识，完全应用到软件的构建过程中去，那么，我认为，很多持续型项目不一定需要进行软件测试（核弹等高危行业的软件除外）。

    在逻辑世界里，不会有机器故障，软件测试只是严格地重复那些足够充分的可行性测试而已。

在大自然中，狮子的攻击技能世代相传，这使它们可以长期站立于食物链的顶端。而在软件开发实践中，很多软件开发组织却缺乏软件测试技能的积累。

    我经常看到这样的场景：在软件开发完成之后，软件测试人员根据自己的经验，搭建测试环境、编写测试用例、反馈测试结果。这些工作总是从头开始，仅有的一些可以重用的经验，也只是存在于测试人员的大脑中。比方说，在测试用例中指定可以输入的边界值、尝试各种特殊字符等。

    在理想的工作模式下，很多攻防的方案（例如，边界值和特殊字符的处理，安全漏洞的防御方法等），都应该是自动化测试的一部分，根本不需要从头建立。

    换句话说，对于自动化软件测试来说，软件测试中的模拟攻击不应该总是新鲜事物。在软件构建的过程中，我们应该对以往自动化软件测试的成果进行总结，并把测试成果应用到软件的构建过程中去。比方说，不是在测试阶段才考虑边界值和特殊字符，而是在构建时就有针对这些问题的解决方案。安全和性能的问题也是如此。

    致远服软认为：http://www.soft8.com.cn/仅仅在软件生产结束后才进行某些系统特性（例如，安全和性能）的测试是错误的，这种“测试驱动”（驱动缺陷修复的生产后测试）会带来高昂的返工成本。

容易犯错的“人的活动”，可以通过另一些容易犯错的“人的活动”来避免吗？不，我不这样认为。只有自动化才能避免出现设计之中意料之外的问题。

    很多大连在线预订软件开发组织对于自动化测试有一些误解。我曾经碰到过一家软件公司，他们把LoadRunner录制的脚本作为自动化测试的唯一方案。一般来说，LoadRunner录制的脚本基于常规的正确逻辑，这无助于帮助软件测试人员发现逻辑节点上的缺陷。基于正确逻辑的测试是需要的，但它不是软件测试的全部，甚至不是软件测试的主要内容。

另一种自动化测试工具，AppScan，则符合软件测试的本质要求。