今天我们公司刚入职一小伙，听说是00后，今天在办公室交流了一下，他问我会不会自动化测试，我直呼好家伙，直接问了他3个开展自动化测试问题....一问3不知.....还有待加强呀

我们在制定自动化测试实施策略时，首先应该考虑其中可能存在的风险。

自动化测试时间不充足
对自动化测试期望过高
缺乏自动化测试实施的经验
自动化测试工具更新过于频繁
自动化测试工具对软件测试本身没有起到帮助作用

我们有了针对自动化测试实施风险的准备后，就可以开始考虑：

需要在什么阶段开始自动化测试？

在何时启动自动化测试，每个公司的情况都不同。有的公司是在测试用例都手工执行过并且测试用例不再修改时，再开发相应的自动化测试脚本；

而有的公司则是在开发测试用例的同时，就进行脚本的开发。如果团队中测试用例的设计者是一个有着丰富测试用例设计经验的工程师，他所开发的测试用例是高效的，未来改动较少，则可以考虑在开发测试用例的同时，同步开发自动化测试脚本。

如果团队中测试用例的设计者是一个测试用例设计经验不丰富或是设计的测试用例质量不高效的人，其开发的测试用例需要在后期经常进行许多的改动，则还是考虑等到测试用例本身稳定后，再开始脚本开发。

自动化测试的人力投入方式如何？

大部分公司是由专人进行自动化测试脚本开发的，少部分大公司则是全民开发自动化测试脚本。这两种方式都各有利弊：专人进行脚本开发，优点是开发脚本的专业技能可以不断地得到强化，开发效率大大提高；缺点是由于对开发模块的测试用例了解并不深入，有可能开发出的自动化测试脚本只是“翻译”测试用例，发现bug的概率较小。

而有的大公司，由于员工的整体素质较高，通常都具备一定的开发能力，则由每个模块的手工测试者自行开发自动化测试脚本。虽然，手工测试者脚本开发的熟练程度没有专门的脚本开发者熟练，但是由于手工测试者是最了解测试用例真谛的人，因此他开发出的测试脚本就不仅仅是“翻译”，而可能是对测试用例的“升华”，其测试脚本发现bug的概率会更大。

如何执行测试脚本才更高效？

（1）N个测试环境同步并行执行测试脚本，可以将自动化测试脚本执行的总时间成本降低为1/N。

（2）由专门的自动化测试执行工程师来执行批量的自动化测试脚本。自动化测试脚本运行失败的前3大因素大致为：

测试环境问题
脚本错误
被测目标出现bug

由于专门的自动化测试执行工程师对大量失败的脚本分析经验的积累，通常可以非常高效地定位脚本失败的原因，提高自动化测试脚本执行的效率。

（3）独立的自动化测试环境供脚本执行团队使用。如前所述，测试环境问题是测试脚本失败的原因。而测试环境影响测试脚本执行的两大杀手：一个是测试环境被前一个失败脚本破坏而未还原；另一个则是测试环境被其他项目的同事给破坏了。

对于第一种情况，我们可以在测试脚本的代码结构中加入足够的系统恢复代码来解决；对于第二种情况，则只有依赖于公司领导的政策支持，是否愿意腾出足够的测试环境给自动化测试执行小组专用。

（4）在测试脚本中加入丰富的脚本失败的定位信息。自动化测试脚本一旦失败，我们就只有依靠脚本自身打印的信息进行定位了，定位问题的速度快慢除了依赖脚本执行人员自身的经验外，更依赖脚本中是否有着丰富的脚本打印信息。

（5）使用自动化测试基线软件版本。当出现大批量测试脚本失败的情况时，可以在排除了测试环境问题后，直接把这些失败的测试脚本在基线软件版本中运行。

如果在基线版本中运行全通过了，则证明脚本失败原因是产品新bug引起的，而不用逐个地去阅读这些失败测试脚本的源代码来分析脚本自身原因。

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】

这些资料，对于想进阶【自动化测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助……这些都在我创建的学习交流群里，群里不仅有免费的资源获取，也有同行大佬一起技术交流....