百度测试经理，对自动化测试初学者的一些忠告

• 并不是所有手工测试用例都要转为自动化测试用例
• 考虑到脚本开发成本，不要选择流程太复杂的用例，如果有必要，可以考虑把流程拆分成多个用例来实现脚本
• 选择的用例最好可以构建场景。例如，一个功能模块，分成多个用例，多个用例使用同一个场景，这样的好处在于方便构建关键字测试模型。
• 选择用例可以带有目的性。例如，这部分用例作冒烟测试等，当然，会存在重叠关系，如果当前用例不满足需求，那么唯有修改用例来适应脚本和需求
• 选取的测试用例可以是你认为重复执行，很猥琐的部分。例如字段验证、提示信息验证之类，这部分适用于回归测试
• 自动化测试也可以用来做配置检查、数据库检查。这些可能超过了手工用例，但也算用例拓展的一部分，项目负责人可以有选择的增加
• 平时在手工测试时，如果需要构造一些复杂的数据或重复一些简单的机械式动作，则告诉脚本，让它来帮你，或许你的效率会因此提高

• 尽可能少的编写逆向逻辑用例。一方面因为逆向逻辑的用力很多（例如，手机号输错有几十种情况），另一个方面自动化脚本本身比较脆弱，复杂的逆向逻辑用例实现起来比较麻烦且容易出错。
• .一个用例只验证一个功能点，不要试图在用户登录系统后把所有功能都验证一遍
• 一个用例为一个完整的场景，从用户登录系统到 最终退出并关闭浏览器
• 用例与用例之间尽量避免产生依赖
• 一条用例完成测试之后需要对测试场景进行还原，以免影响其他用例的执行

很多自动化测试工具包含一个特性，就是可以自动记录一系列动作，然后回放。尽管这样的记录/回放功能在创建测试时容易驾驭，但是单纯的记录/回放动作会导致不良测试。具体而言，记录/回放测试并不会检测应用中操纵元素后的应用状态。

点击、键入、选择以及其他的功能都会以某种方式改变应用的状态。好的测试会在应用中操作元素后检查本身的结果。如果自动化测试跟随一个链接，就要让测试检查结果页是否正确。如果测试生成一个报告，就要检查报告内容是否正确。

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群：1150305204，里面有各种测试开发资料和技术可以一起交流哦。

总之自动化测试学起来并不是很难，但是需要注意的细节却很多，希望大家在软件测试的道路上越走越好，薪资越来越高，如果觉得这篇文章对你有帮助，不妨给我个三连支持我一下！