自动化测试流程

1. 简介

• 为了规范自动化测试的流程，明确自动化测试各个阶段的先决条件、工作内容和工作目的，并对自动化测试中生成和使用的相关文档、脚本代码进行规范，特制定本文档。
• 本文档读者包括但不限于测试经理、自动化测试设计、脚本开发和执行人员。

1). 术语定义

涉及自动化测试工具：

• QTP(UFT）： Mercury公司生产的功能测试工具。（付费不使用）
• Selenium3 + Python：开源的web功能测试工具。
• Appium + Python: 开源的移动app功能测试工具。
• Airtest + Python: 开源的移动app功能测试工具。

使用过的自动化测试框架：

• 三合一框架：app+web+api三种不同的自动化测试合到一个框架中实现。
• Appium框架：Appium未采用unittest+htmlTestRunner，使用的是独立的log机制和html报告。
• web框架：多进程、多线程结合快速执行web页面的冒烟测试使用。

2). 自动化测试前提

1. 人机交互界面早期冻结，软件需求变动不频繁；
2. 测试脚本开发的投入可承受，项目周期足够长；
3. 测试人员对测试工具达到相应的熟练程度且具备相应的编程能力；
4. 测试脚本的设计可重用；
5. 在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等

事实证明新缺陷越多，自动化测试失败的几率就越大。发现更多的新缺陷应该是手工测试的主要目的。测试专家 James Bach 总结得出， 85% 的缺陷靠手工发现，而自动化测试只能发现 15 ％的缺陷。

2. 自动化测试过程

1. 自动化测试需求分析。

   当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。

2. 自动化测试框架的搭建。

   所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。
   而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素：
   a. 公用的对象。
   不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。
   b. 公用的环境。
   各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。
   c. 公用的方法。
   当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。
   d. 测试数据。
   也许一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。
   在该框架中需要将这些典型要素考虑进去，在测试用例中抽取出公用的元素放入已定义的文件，设定好调用的过程。

3. 自动化测试脚本的编写

   该编写过程便是具体的测试用例的脚本转化。初学的自动化测试人员均会使用录制脚本到修改脚本的过程。但专业化的建议是以录制为参考,以编写脚本为主要行为，以避免录制脚本带来的冗余、公用元素的不可调用、脚本的调试复杂等问题。

4. 脚本的测试与试运行

   事实上，当每一个测试用例所形成的脚本通过测试后，并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变，都会导致测试结果受到影响甚至失败。而如果只是一个个执行测试用例，也仅能被称作是半自动化测试，这会极大的影响自动化测试的效率，甚至不能满足夜间自动执行的特殊要求。

   因此，脚本的测试与试运行极为重要，它需要祥查多个脚本不能依计划执行的原因，并保证其得到修复。同时他也需要经过多轮的脚本试运行，以保证测试结果得一致性与精确性。