自动化测试的一点看法

　　现状：自动化的推广困难;自动化模式不成熟，测试人员编写的脚本效率低下、移植性差。脚本代码量大不易于维护;如果开发和测试的过程中页面或者某个应用发生变化，原先写的自动化脚本不符合新的情况，于是测试再对同一个功能点重新编写脚本。

　　实际情况是“好的测试人员并不一定是好的程序员”。如果产出的代码维护时间>手工测试时间,就失去它的意义。以前，是在回归的时候写自动化脚本，回归结果的特点是bug数量特别少、遇到的bug基本上是前些轮测试曾经发现过的、bug的修复比较紧急。这个时候编写自动化脚本，重用性和重要性都没有早期编写来的明显。而项目上线后，就不再进行自动化测试了，除非有一期二期或者其他情况。这样，自动化的长期价值体现不出来。

　　自动化测试的特点应该是前期投入多，后期收入大。根据现状，测试轮数多、重复测试多、一个TC需要海量数据，前期编写的脚本在中期就能为我们节省时间。项目前期，测试人员要了解需求、理解UC、编写测试用例，时间很少，这个时候是进行测试数据准备，最重要的是TC，并非自动化。

　　经验丰富的测试工程师对bug有着敏锐的嗅觉，TC的质量至关重要;如果开发的模式是瀑布模式并非迭代式的，随着项目开发的进行，我们测试需要不断完善自己的脚本。问题是，测试的时候要编写自己不擅长的脚本程序，自动化未必就赶得上手工测试，测试工程师没有看到实际的好处，抵触就很大。所以现在将人员分层，一层是传统手工测试，另一层支持自动化，来解决这个矛盾。

　　现在的自动化测试模式还不成熟。理想太大，短期内就不容易实现。如果选择一个主线作为试验田，投入相当人力和测试人员重视，吸取过程中的经验教训，分享其中的好处。当人人都看到通过自动化，不用手工测试到一半才发现环境换了，bug的检测方便了，测试们不再加班了，肯定有更多的人加入。

　　下面我们了解一下什么是自动化软件测试

　　自动化软件测试的定义包括了所有测试阶段，它是跨平台兼容的，并且是进程无关的。一般来讲，当前作为手动测试程序部分的各种测试(如功能、性能、并发、压力等测试)都可以自动化。大家经常问这个问题：“手动测试和自动化测试有什么不同呢?”答案如下：

　　自动化测试可以完成手动测试难以完成的工作，可以提高手动测试的工作效率。

　　自动化测试也是软件开发。

　　自动化测试不是要取代手动测试人员所需要的分析技能、测试策略知识和对测试技术的理解。手动测试人员的经验会作为AST的蓝图。

　　自动化测试不可能完全和手动测试分开。相反，自动化测试和手动测试是相辅相成的。

　　尽管开发软件将今天已有的手动软件测试全部转换成自动化测试是有可能的，然而我们的经验表明，为了适应自动化，大多数手动测试都必须经过修改。手动测试技术、实践和知识与AST是相互交织的，所以也会在本书中对其进行讨论，以对AST技术提供支持。而自动化是否可以产生合理的ROI(Return On Investment，投资回报率)是另外一个问题，这需要通过评估。经验表明，即使可以将所有测试自动化，但并不是所有测试都值得自动化。当决定是否要自动化时，我们需要考虑各种准则。如何确定哪些测试应该自动化会在第6章进一步探讨。要将ROI铭记在心，我们对AST的高层次定义是：

　　以改进软件测试生命周期(Software testing lifecycle，STL)的效率和有效性为目标，贯穿整个STL的应用程序和软件技术的实施。

　　AST是指跨越整个STL中的自动化工作，以及关注自动化集成测试和系统测试的工作。AST的总体目标是设计、开发和交付自动化测试，并通过重复测试来提高测试效率。若成功实施，那么它可以大幅度减少针对软件密集型系统的传统测试和评估方法、过程相关的成本、时间和资源。

原文转自：http://www.ltesting.net