前阶段将UI自动化测试框架已搭建完成，现把自动化测试应用到产品中进行使用，并对测试框架进行验证及优化。在正式应用之前，大体梳理了一下自动化测试思路。有不成熟或者有误的地方，请大家多多指教，谢谢！
一、需求分析
需求分析是整个自动化测试工作展开的基础，如果需求都没梳理清楚，后面无法执行自动化测试。
在需求分析阶段，测试人员需要与产品相关的人进行沟通，收集产品相关资料，对产品进行全面分析，熟悉产品的整个设计，从而转换为自动化测试的设计思路。
从哪几方面进行分析呢？
1、产品设计：作为自动化测试设计的输入。
2、产品业务：了解产品的整体业务及测试场景。
通过需求分析，我们得出哪些结论：
1、明确产品是否需要做自动化测试。
2、哪些功能，在什么测试场景下适合做自动化测试，为什么？哪些不适合做，为什么？
3、明确产品的前端页面设计、业务数据流转（哪些页面是多个功能公用的）。
二、自动化测试设计
依据对产品的业务分析，对公共方法、公共元素和公共页面进行提取封装。
三、测试规划及测试策略
1、测试规划：将需要做自动化测试的功能分为几个迭代完成，并制定详细的计划方案。
2、测试策略：根据每个迭代要测试的功能，制定相符的测试策略方案（比如执行失败重跑N次等）。
四、测试用例设计
写自动化测试用例需要考虑的问题：
1、需要什么样的测试数据，怎么得到这些测试数据（通过UI自动化测试去创建；通过API创建；直接操作数据库）
2、测试步骤是什么样的。
3、用什么样的校验才能确定这个功能是通过的。
五、测试执行及错误分析
可通过定时或手动触发的方式执行测试脚本。执行结束后，需要对测试结果进行分析。
测试结果为了4种：
1、执行成功：是指测试用例通过。
2、执行失败：是指测试用例校验失败。
3、执行退出：是指测试用例执行中断，说明测试脚本编写有问题。
4、执行跳过：是指测试用例有依赖关系，当被依赖测试用例执行失败或中断时，后面的测试用例跳过执行，未被执行。
六、测试报告及总结
迭代结束后，需要整理过程的测试报告及总结，包括以下内容：
1、数据统计
a、每日执行用例时间
b、每日执行用例数
c、每日发现缺陷数：包括产品缺陷和脚本缺陷
d、执行用例总时间
e、执行用例总数
f、缺陷总数：包括产品缺陷和脚本缺陷
g、节省手工测试时间
