自动化测试开展自动化测试的过程

Posted 2021-05-20 黑黑白白君

文章目录

• 1）自动化测试需求分析
• • 1.1 如何确定系统是否适合做自动化测试？
  • • 周期较长：
    • 稳定系统：
    • 脚本可复用：
  • *被测系统适合怎样的自动化测试？
• 2）调研测试工具、测试框架
• • 2.1 框架的选择
  • • 2.1.1 TestNG
    • • 主要特点：
      • TestNG的使用方法：
    • 2.1.2 unittest
    • 2.1.3 pytest
    • 2.1.4 Robot Framework
    • • 特点：
    • 2.1.5 框架对比
  • 2.2 工具的选择
  • • 2.2.1 UFT（QTP）
    • • 特点：
      • 测试流程：
    • 2.2.2 Selenium
    • • 它的优势：
      • 它的组成：
      • • Selenium IDE：
        • Selenium Grid：
        • WebDriver：
    • 2.2.3 Appium
    • 2.2.4 工具的对比
• 3）搭建自动化测试框架并实施
• • 3.1 确定开展自动化需要的资源
  • 3.2 开发自动化测试脚本
  • 3.3 测试结果分析
• 4）总结自动化测试的实施过程
• • 可以看作一个项目：
  • 看作软件开发的过程：
  • 依然是一个测试过程：

---

如果自动化测试过程是不合理的，引入自动化测试只会给软件组织或者项目团队带来更大的混乱。我们应该建立正确的自动化测试目标，制定有效的测试策略，有计划、有步骤地实施合理的测试过程，这样才能确保自动化测试获得所期望的效益。

1）自动化测试需求分析

当接受一个新的项目时，必须针对测试项目的具体情况进行具体可行性分析，确定一个软件系统测试中哪些范围、哪些任务是适合自动化测试的而哪些是不适合的。如果对不适合的测试任务实施自动化工作，不仅耗费过多的人力，而且效果也不一定好。

1.1 如何确定系统是否适合做自动化测试？

• 周期较长：

  如果被测项目是在今后一年或者几年间要不断进行开发维护的，那么就需要重复的进行大量的回归测试，这种情况下如果有自动化的回归测试体系就可以节省成本投入。

• 稳定系统：

  已上线运行的稳定系统，开发过程中需求变动较少。

• 脚本可复用：

  脚本可复用以降低维护成本。
  
  

• *被测系统适合怎样的自动化测试？

  自动化测试覆盖的范围很广：单元测试、集成测试、接口测试，GUI测试等等都可以实现自动化执行。
  • 不同的系统情况是不一样，有的适合或是可以做GUI的自动化测试，有的可能只适合做接口的自动化测试，所以需要针对不同的被测项目，考虑具体在哪一个环节作自动化测试。
    • 比如说针对搜索引擎，前端往往比较简单，只是一个文本框和提交按钮，大部分的逻辑处理都是在后端完成的，这种情况做自动化的接口测试就可以达到事半功倍的效果。
    • 如果是被测系统有很多的页面操作，那么可以考虑GUI的自动化测试。
    • 以上这两种情况都不是绝对的，如果测试资源足够，那么在各个环节都是可以开展自动化测试的。
  • 还有一点需要考虑的是自动化测试的可行性，比如说对一个系统而言，做GUI测试是最合适的，也是最有效，但是有可能通过各种工具或者是脚本很难实现GUI的自动化测试，那么就需要考虑变通，考虑是否可以将自动化测试调整到接口测试或是集成测试等环节。

2）调研测试工具、测试框架

2.1 框架的选择

时下比较主流的自动化测试框架，有TestNG、unittest、pytest、Robot Framework。第一个框架基于Java，后三者基于Python，Java和Python是编写自动化测试脚本最常用的两种语言。下面就简单介绍这四款框架。

2.1.1 TestNG

Test NG是一款基于Java的自动化测试框架。

说到TestNG就不得不提到JUnit，两者都是基于Java的测试框架，功能差异不大，但是TestNG底层调用的是JUnit，因此TestNG的使用对于测试人员来说更友好。而JUnit更偏向白盒测试，所以开发人员用来做单元测试比较多，而且测试结果可读性对测试人员也有一定难度。

• TestNG使用更便捷，例如并发测试JUnit需要调用第三方库，TestNG则不需要。
• 一般TestNG主要是测试人员使用。

• 主要特点：

  • 涵盖单元测试、功能测试、集成测试等。
  • 基于Annotation（注解）机制，测试方法更灵活：
    • 当我们想执行一部分测试脚本的时候，就可以使用xml配置文件进行配置，在xml配置文件里，可以选择某些需要执行的测试脚本，排除不需要运行的测试脚本。
  • 支持多线程测试。
  • TestNG还可以自动生成html、xml格式的测试报告：

    • 测试报告位于 “test-output” 目录下，只需要执行测试用例时使用TestNG执行即可自动生成，无需配置，使用便捷。

    • 还可以对报告内容的详细程度进行设置：

      • 可以说是比较完善的测试报告了，测试报告的样式如下图所示，展示比较直观、简明，可以直接看到共执行了多少个用例，成功/失败分别是多少个，设置级别更高的报告，还可以查看具体的失败情况。

      

• TestNG的使用方法：

  • 将测试用例生成测试套件，通过执行测试套件来执行测试用例。
  • 常用的组件如下图所示：
    
    • @Test表示一个测试用例。
    • @BeforeMethod/@AfterMethod表示在每一个方法执行前/后执行一次。
    • @BeforeTest/@AfterMethos表示在每个测试用例执行前/后执行一次。

例如，在使用TestNG框架时，就可以将“启动浏览器”的操作步骤封装在@BeforeTest中，“关闭浏览器进程”的操作封装在@AfterTest中，这样就提高了代码复用性。

2.1.2 unittest

unittest是一款常用的单元测试框架。它更偏向底层，二次开发方便，因此对于测试人员来说，就具备一定的难度了。

它的优势是Python自带框架，可生成html测试报告，使用的是HTMLTestRunnerNew库。由此，若基于Python开发的测试代码，就非常适合采用unittest测试框架。只需要使用自带的方法生成测试套件，执行测试套件，即可完成多种组合方式的测试。因此，针对Python的自动化测试，unittest可谓是最佳拍档，可以轻松完成大部分的测试功能。

• unittest也可以将浏览器启动、关闭等通用方法封装，生成测试用例，再将测试用例生成测试套件来执行，如下图所示：
  
  

• unittest也可以自动生成测试报告，报告形式如下图所示：

  

  • 报告的内容与TestNG生成的报告内容相似，展势执行用例的数量、结果等信息，也可以设置详细等级、标题等信息。

2.1.3 pytest

pytest是基于unittest扩展的第三方测试框架，比unittest更简洁高效。

• pytest可以执行unittest风格的测试用例，无须修改unittest用例的任何代码，有较好的兼容性。
• pytest插件丰富，比如returnfailures插件，可用于用例出错重跑。
• 还有xdist插件，可用于设备并行执行测试用例。
• 可使用pytest-HTML插件生成测试报告。
• pytest也可用来进行验收测试，适合复杂度不是很高的系统。

2.1.4 Robot Framework

Robot Framework也是一款功能强大的自动化测试框架，基于Python的关键字驱动测试框架，自带报告生成，功能完善。因此它易用性更高，测试人员使用成本低，但灵活性就偏低了。一般多用于验收测试和验收测试驱动开发的自动化测试框架。支持跨平台（Windows/Linux/MacOS）。

• 特点：

  • 关键字驱动测试（KDT），简化自动化过程，对测试人员来说更易读，测试数据语法也简单易用，扩展性高。
  • 例如支持Selenium第三方类库可进行Web UI自动化测试，支持Selenium Grid执行并发测试，并且可生成html测试报告但操作较麻烦。
  • 表格式的测试数据语法和关键词驱动测试使得易用性较高。

2.1.5 框架对比

TestNG是基于Java的测试框架，unittest、pytest、Robot Framework是基于Python的测试框架。其实测试框架的选择，更主要还是根据系统的特性，选择适合的框架。

对于unittest、pytest、Robot Framework这三个测试框架，都可支持跨平台，语言单一支持Python，差别并不大，主要如下表所示：

实际选用，可结合系统、框架的优势对号入座，以带来更高的自动化测试开发效率。

2.2 工具的选择

不同的测试任务会选用不同的测试工具，如单元测试须要选用单元测试工具，性能测试须要选用性能测试工具。

• 要考虑被测系统是C/S、还是B/S结构的
• 服务端和客户端都是用何种语言编写的
• 数据库的类型
• 服务器类型等等

在选择测试工具时，要清楚测试目标和需求，确定适用的技术环境及自动工具可支持的各种测试，分析测试工具与被测软件系统的互操作性和兼容性，考虑工具的易用性、工具学习曲线或培训成本，特别是要考虑工具本身所要求的测试脚本，是否支持数据驱动、关键字驱动，以及是否容易编写、调试和维护等。

2.2.1 UFT（QTP）

UFT 就是以前最常用的自动化测试工具QTP，用来进行Web UI自动化测试的。QTP实现的是独占屏幕操作，仿真实际用户操作，一般用于回归测试和新版本测试。

• 特点：

  • 支持Windows平台
  • 使用VBScript编写测试脚本
  • 相比Java/C#这类语言，显然更受测试人员欢迎。
    
    

• 测试流程：

  1、制定测试计划
  2、创建测试脚本
  3、增强测试脚本
  4、运行测试
  5、分析测试结果

QTP的脚本生成是通过轨迹录制，再进行增强优化，最后实现回放。因此VBScript脚本的逻辑比较松散，因此对于复杂页面情况的处理能力比较弱，脚本维护的成本就非常高。最重要的是，QTP是收费的，QTP11.5版本发布改名为UFT。

2.2.2 Selenium

Selenium是目前最常用的一种Web自动化测试工具，是开源的，它可并行测试，模拟用户操作，贴近用户实际操作，测试效果直观。

• 它的优势：

  • 兼容性好：兼容多平台，多浏览器，多语言编写脚本，因此它从测试脚本开发，到部署运行，都比较稳定。
  • API丰富：可以实现对浏览器、页面元素、鼠标键盘、JS窗口等几乎所有的用户操作，执行效率较高。

• 它的组成：

  当前Selenium已发展到第3代，包含三大组件，Selenium IDE + WebDriver + Selenium Grid：

  • Selenium IDE：

    Selenium IDE是Firefox中的一个组件，可以录制操作轨迹，自动生成脚本并进行回放，但它的缺点是不稳定，生成的代码效率低，定位大多采用自动的xpath方式定位，定位繁琐，回放成功率低，且不适用于复杂系统。

  • Selenium Grid：

    用于实现分布式测试。

  • WebDriver：

    是Selenium核心组件，它就是实现页面操作的组件，利用浏览器原生的API，封装成一套更加面向对象的SeleniumWebDriverAPI，直接操作浏览器页面里的元素，执行效率更高，且稳定性依赖于浏览器厂商，显然更加稳定，因此各大常见浏览器都有对应的WebDriver。
    • 例如Chrome对应chromedriver。
    • Firefox对应geckodriver。
    • IE对应iedriver。
    • 甚至比较高版本的selenium还自带了部分常用浏览器的驱动，使用起来非常方便。它的优势显而易见，使用浏览器源厂的驱动来进行自动化控制，给我们带了更高的安全感。

2.2.3 Appium

Appium是目前最常用的一款移动端自动化测试工具，是开源的，它支持Android和iOS平台的原生应用、web应用和Hybrid应用。它的优势，支持跨平台，多语言脚本编写。因此，兼容性很好，开发便捷。

• Appium是C/S架构，提供了基于Selenium WebDriver协议的统一接口。

那么这里就需要说明一下Appium与Selenium的关系了。

• Appium封装了标准的Selenium客户端类库，Appium继承了Selenium中的WebDriver，因此也是通过WebDriver实现界面的定位及操作。而Appium实现的是PC端连接移动端的桥梁作用，这样才能通过PC端对移动端进行自动化测试。

2.2.4 工具的对比

由于Selenium和Appium都是使用的WebDriver实现操作的，因此这里只对比UFT和Selenium。

下面这个表格，充分体现了两者之间的优势与劣势，测试人员可以根据需要选择合适的测试工具，以实现最高的测试效率：

3）搭建自动化测试框架并实施

由leader组织搭建自动化测试框架，并且在项目中逐步地实施，发现框架的问题并改善。

3.1 确定开展自动化需要的资源

确定了使用何种测试工具、测试框架，就需要确定需要的资源，如：

• 需要几个自动化测试工程师
• 需要购买的测试工具
• 测试机（服务器、客户机）
• 开发自动化框架所需要的时间

确定了需要哪些资源，就要看当前可用的资源有哪些，如果资源不足应提前申请，如招聘测试人员、购买配置测试机。甚至需要测试人员提前学习新的技术。

3.2 开发自动化测试脚本

自动化测试脚本的编写，必须要遵守编码规范，包括脚本的层次、命名等。将（测试）数据层、（系统）操作层和（业务）逻辑层分开，不仅构造结构化的脚本，而且构造程序对象映射、建立对象库和关键字函数库等，全面支持测试数据驱动、关键字驱动的脚本，有利于脚本的开发和维护。

• 测试脚本的开发，和软件产品本身的开发还有许多相似之处，例如：
  • 自动化测试代码需要跟踪和维护，因此，要采用源代码管理。
  • 测试自动化也会出现缺陷，因此，需要有计划地跟踪缺陷，并且对修改后的缺陷进行验证。
  • 用户需要知道如何使用工具和脚本，因此要提供用户使用手册。
• 在脚本开发中增加冗余设计，即使降低一定的性能，也要保证测试执行的稳定性。

脚本写完了，并不代表脚本开发工作已结束，还须要调试。只有脚本运行稳定，执行的测试结果符合测试要求，才能说明测试脚本开发工作告一段落。

3.3 测试结果分析

自动化测试结果一般被分为3种情况——通过（pass）、失败（failed）和不确定/没有被执行TBD/unexecuted）。

针对测试自动化执行结果，主要集中分析那些没有通过（failed）的结果：

• 分析是不是软件产品本身存在缺陷导致测试执行失败？
• 是不是之前某个测试执行失败而导致其他大量的测试执行没通过？
• 查看测试环境是否异常。
• 如果产品和测试环境都没有问题，就要检查自动化测试脚本，是不是测试脚本误报信息？还是脚本的验证点设置不对？

有时候，测试执行全部通过，也可能存在问题——脚本的验证点不够或太粗，从而错过许多验证点。

为了更好地进行测试结果分析：

• 一方面，尽量记录下测试过程中的重要信息，即存储好的测试执行日志（log）。
• 另一方面，提供规范的测试结果报告格式，使结果一目了然，并在失败的用例提供链接，点击链接，就能直接查看相应的测试用例和执行的log。

4）总结自动化测试的实施过程

自动化过程可以从3个角度描述其组成：

• 可以看作一个项目：

  自动化测试的过程就是一个项目的实施过程，经过计划、执行、评估与总结而不断提高的过程。

• 看作软件开发的过程：

  经过测试需求的分析、自动化测试框架的设计、测试脚本的开发和验证、测试脚本的运行等流程。
  • 而且测试脚本的管理和源代码的管理也是一样的，须要通过CVS、SubVersion等工具进行配置管理，包括版本分支和合并、变更控制等。

• 依然是一个测试过程：

  从测试需求出发，设计和执行测试用例、报告缺陷，并自动生成测试报告。

---

【部分内容参考自】

• 如何开展自动化测试：http://www.51testing.com/html/98/15165698-3716219.html
• 自动化测试的实施：https://www.jianshu.com/p/102136c1d7a1
• 常见自动化测试工具及框架的选用：https://www.cnblogs.com/ustcinfo-qc/p/12124174.html