关于自动化的一点看法。

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

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

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

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

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