在手动测试阶段，为项目输出测试用例。如果在版本迭代过程中需要对这些测试用例进行回归测试，手动重复执行测试用例会消耗大量时间。人手很多。为此，自动化测试应运而生。通过使用自动化工具，将根据测试用例做一点点运维验证的工作交给代码程序执行，测试工作变得省心省力。划重点：测试用例是自动化测试脚本的基础，凡是不基于测试用例编写的自动化脚本都是耍流氓。关于UI自动化测试UI自动化的本质：定位元素、操作元素、模拟页面动作、断言结果、生成报告基于以上五个本质，自动化测试的整体流程如下。下面举一个百度登录功能的测试用例：对于这个测试用例，需要找到它的定位元素：用户名输入框，密码输入框，登录按钮操作元素：这三个定位有两种操作元素，即“input”和“click”，模拟页面动作，即测试用例的步骤：输入用户名，输入密码，点击登录按钮4.判断结果：比较预期结果在具有实际结果的用例中。如果它们一致，则表示成功，否则表示失败。对于这个测试用例，登录成功的标志是用户的头像和用户名出现在页面的右上角。然后，就可以获取网页中用户名的文本信息，与登录账号的用户名进行比对。如果一致，就说明这个用例通过了。根据执行结果，自动生成报告。常用的第三方模块：HtmlTestRunner、Allure2等，适用于UI自动化测试场景。当然，并不是所有的测试场景都适合自动化测试。对此，可以参考以下标准辅助判断：项目的需求不会频繁变化页面的UI已经进入稳定阶段项目周期足够长，有大量的回归测试任务其中，有些项目明显不适合做UI自动化测试，比如视频播放器（暴风影音、腾讯视频、爱奇艺等）、音乐播放器（比如网易云音乐、QQ音乐等）等交互性强、依赖性强的软件。原因是这类软件很难判断视频内容是否正确，音乐声音和歌词是否正确。另外，延伸一个话题：关于自动化测试的覆盖率，面试会问的一个点。国内大部分互联网公司的项目迭代周期都比较短，所以自动化覆盖率普遍不高。具体应该按照项目迭代周期来描述。参考标准是：迭代周期半年或一年以上，每次需求变化不大。自动化测试的覆盖率一般在60%-70%，主要是覆盖前面的。对于老功能和核心场景迭代周期为一个月的项目，覆盖率在25-30%左右，主要覆盖P0（非常重要）级别的大部分用例，以及部分1~2级别的用例P1（重要）级别每周迭代一个项目，覆盖率在10%左右，主要覆盖P0（非常重要）级别，可能严重影响用户的核心场景。其次，UI自动化测试主要有两个时间切入点：冒烟测试阶段回归测试阶段UI自动化测试设计原则一个测试用例完成一个功能点测试（常用）：一个手动用例对应一个自动化测试用例一个脚本是一个完整的场景脚本是独立的，不能有依赖关系（脚本之间是相互隔离的）：比如登录状态相关的用例：个人中心，订单详情，订单购物等。如果脚本不独立并且相互依赖，如果登录测试脚本失败，会导致个人中心、订单详情、下单等，购物测试脚本全毁，后续修复维护成本高。4.设置适当的检查点：通过断言判断用例是否成功。并对共享测试模块进行封装，减少自动化测试脚本维护的工作量
