00000646
这个 文章是写给没有接触过 自动化测试，包括刚学自动化测试或者 项目管理人员。
在工作中常常会有这种人，项目刚开始才出设计稿就要求先将自动化 测试用例写出来；既然有自动化测试，那么就不要手工测试了，全部使用自动化。
最常出现的误解，既然有自动化测试就不需要手工测试。我在世界排名前几位的公司项目文档上看到过这样的字眼“?GOAL:?NO Manual Testing”，目标没有手工测试，我认为这是个笑话。
自动化测试是否能够替代手工测试？
我们先来了解手工测试与自动化测试的概念。
手工测试是测试人员根据用例描述的测试步骤和方法，手工地一个一个执行，然后观察结果，看被测程序是否存在异常。手工测试与自动化测试相比较，手工测试能实时观察各个测试功能运行，但它的工作量大、繁琐、低效，并且出现bug需要重复的测试。
自动化测试是在预设条件下运行程序，评估运行结果，预先条件应包括正常条件和异常条件。它是把以人为驱动的测试行为转化为机器执行的一种过程，自动化测试执行速度比手工测试高很多，他的测试的准确性也相对较高。
从上面的描述能看出，自动化测试是在预设条件下运行程序，评估运行结果，它是设定固定路径来运行程序，这就造成它呆板。当运行结果出现预设条件之外异常，自动化程序就无法识别就会直接放行通过。
以现在的 技术条件，程序还无法达到人的观察力，所以对于新功能，新需求无法使用自动化测试。
自动化测试仅仅是某些条件下手工测试的一种补充，它无法全面取代手工测试。
自动化测试用例，天天在执行应该会发现大量的bug。
这个也是对前面自动化测试的概念没有理解透彻，自动化测试在预设条件下运行程序，评估运行结果。证明你在编写自动化测试脚本的时候这个功能已经正常，而你要在执行过程中发现大量的bug，这有可能吗？除非每个版本质量太差，开发每次都创造老功能的新bug。
自动化测试测试的真正用途不是用来找bug，而是解放有经验的测试工程师的生产力，让其从事新的测试方法和测试手段的研究。让测试人员的时间和精力来花费在找到更多、更深层次的新bug上，将产品质量再提高一个档次。
自动化化测试它无法发现新问题，它只适合用于回归测试。
自动化测试的人员投入不一定比手工测试少，前期的脚本编写与调试，后期的用例更新与维护，这些都是需要人力投入。尤其是前期自动化测试脚本开发耗时最多，而且自动化测试远比手工测试脆弱，后期用例维护成本也很高；
自动化测试用例的开发工作远大于单次的手工测试，产出价值往往在于长期的回归测试，短期内发挥的作用可能不明显。
实行自动化测试的初期，用例开发效率通常都很低，并且有很大概率后期在功能没有的变化的情况下需要重构用例。
自动化测试的效率很大程度上依赖用例的设计以及脚本实现质量，不稳定的自动化测试用例比没有自动化更糟糕。
自动化测试的投入成本与需求的变更频率相关，产品需求频繁变更，自动化测试工作量的投入也就相应提高。
并非所有内容都可以被自动化地测试到。不可能覆盖所有功能，有很多功能不适合使用自动化测试。如有些App的扫描二维码或条形码功能，就很难实现自动化测试。
也不是所有的测试用例和测试步骤都可以转化为自动化测试。在自动化测试投入较多的行业，领先企业的自动化测试率有的能达到80%左右，但仍有20%左右的测试用例还是需要手工来进行。在国外，通常从开发第一版测试用例时，就同步进行自动化测试脚本的开发，所以自动化测试率普遍比中国企业高。
自动化测试是为了增加手工测试的广度和深度，它无法达到100%的测试覆盖，因为没有足够的时间或资源，它的投入与收入不能成正比。
自动化测试不光只能进行性能测试和功能测试， 接口测试也会采用自动化测试。由于功能测试的覆盖率无法达到100%，所以现在能多企业将自动化测试瞄向了接口，接口测试的自动化能实现100%覆盖。
录制得到的脚本不是有效的脚本。
很多人仍然把自动化测试等同于自动化测试工具的录制和回放。而事实上，录制的脚本通常是不可重复使用的脚本，脚本中充满了不可变动的输入值，这些值应该被参数化，否则脚本仅仅适用于当前测试情况，脚本中还需要加入条件判断、循环结构等，以便增强测试脚本的灵活性。
录制的脚本维护成本高，它前期投入可能相对较少，但后期的更新与维护很高。