自动化测试思路是什么？

自动化测试介绍

自动化测试(Automated Testing)，是指把以人为驱动的测试行为转化为机器执行的过程。实际上自动化测试往往通过一些测试工具或框架，编写自动化测试用例，来模拟手工测试过程。比如说，在项目迭代过程中，持续的回归测试是一项非常枯燥且重复的任务，并且测试人员在每天重复劳动的工作之下，也丝毫得不到成长。此时开展自动化测试就能够帮助测试人员从重复、枯燥的手工测试中解放出来，提高测试效率，缩短回归测试时间。一般来说，自动化测试通常都会跟持续集成系统（比如Jenkins）配合使用。

但在自动化实践过程中，往往会发现理想和现实之间的差距很大。自动化测试的劣势，主要体现在以下几方面：

1. 相对手工测试，自动化测试对测试人员的要求相对较高；
2. 测试用例需要根据版本迭代进行更新，有一定维护成本；
3. 不能指望自动化测试去发现更多新的BUG，自动化测试能发现的缺陷远远比手工测试少；
4. 自动化测试的产出价值往往在于长期的回归测试，短期内发挥的作用可能不明显；

【B站最通俗易懂】Python接口自动化测试从入门到精通，超详细的进阶教程，看完这套视频就够了

希望借助自动化流程解决的问题

1. 测试时间紧张，手工测试可能覆盖不全，容易错过某些边界情况；
2. 模块间强耦合时，单纯从页面进行测试时，比较难深入的发现问题；
3. 回归测试时，需要投入较大的人力/工时；
4. 实现手工测试无法达成的测试任务；
5. 通过编写测试用例，加深对业务/数据的认知，有助于下阶段迭代中发现隐藏的问题；

引入自动化测试的前提条件

项目周期长，需求变动不频繁
测试用例的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁，测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本，而脚本的维护本身就是一个代码开发的过程，需要修改、调试。如果所花费的成本不低于利用其节省的测试成本，那么自动化测试便是失败的。

项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。

自动化测试脚本可重复使用
如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便毫无意义。

测试任务手工测试难以实现
比如压力测试，大数据或者大量重复数据测试，必须有自动化工具的支持。

做自动化测试需要具备的能力

• 拥有编码能力
  至少要熟悉自动化工具/框架的代码语言，最好有一定的编码能力，同时代码逻辑要清晰，否则不仅不能保证用例的逻辑性、业务性与健壮性等要素，也不能保证效率；
• 熟悉被测系统；
  熟悉被测系统对任何测试人员来说都是最起码的要求；
• 掌握一个自动化测试框架/工具；
  可以根据所掌握的代码，学习一门自动化测试的框架，如 Selenium/Appoum/Robot Framework/Nunit/TestNG等；
• 不断学习，善于学习，知其然知其所以然；
  “落后就要挨打。”

自动化用例一般在哪个阶段完成

一般落后于新功能的手工测试阶段，可以在手工用例执行完成或功能上线后，再去补充自动化的用例。
自动化不是跟着新需求走，而是测变化的东西对不变东西的影响，一定不要做为了自动化而自动化的工作。

分层自动化测试

在理解分层自动化之前，我们先看一下经典的测试金字塔。

• UI层：界面自动化测试。可以看出它的价值最小，它最接近用户真实场景，也容易发现问题，但它的实现成本最高且太容易受外部依赖，容易影响脚本成功率。总体来说，适当的界面自动化测试是有必要的，但是没有必要在UI层投入太多；

• Service层：接口自动化测试。它的价值居中，覆盖大多数主要的接口是比较合适的。这一层要求测试人员对系统的结构和系统间的调度非常清楚，同时要了解接口逻辑关系，否则接口测试代码很容易遗漏一些异常场景；

• Unit层：单元测试。最有价值的测试，但是对测试人员要求比较高，一般由开发人员完成，否则只能采用结对编程。
  通常来说，手工测试是最基本的，可以做到接近100%,而对于自动化测试来说，它更像是一件"防弹衣"，用来防护身体的主要部位。有人认为自动化率提高了，就可以节省人力，这实际是非常片面的，因为提高自动化率，意味着需要投入更大的人力在维护的成本上。因为系统的需求是在不断变化的，每一个变化都会导致自动化测试用例需要更新调整。

  所以，自动化测试做到什么样才算好，也要结合上面的测试金字塔来分析。对于UI层面的自动化测试，保证少量必要的主流程即可，切勿在这一层面将自动化测试的"防弹衣"变成臃肿的"宇航服"；Service层面的接口自动化测试，可以考虑覆盖大部分的流程；Unit层面的单测，做到100%是最好的，即使有需求变化，一般也很少影响到已有的用例。一般来说，单元测试可以发现80%的缺陷。

设计自动化用例的原则

基本原则

• 自动化测试用例的范围必须是相对核心的业务流程，即覆盖主体功能的核心测试点和重复执行率较高的模块；
• 在测试脚本和被测代码都保持不变的情况下，测试用例的结果应该是稳定的，这一点非常重要；
• 除非是必要的情况，否则任何用例都应当避免做持久化的操作，以保证环境始终是干净的；
• Once Written, Run Anytime as Desired ；
• 不是所有的手工测试用例都可以使用自动化测试来实现，自动化测试替代不了手工测试，两者的有效结合是保证项目质量的关键。
• 回归测试场景中，测试用例的选择一般以正向为主，逆向为辅；

用例设计原则

保持Case的独立性

通常来说，一个Test Suite下包含了一组相近的或者有关联的Test Cases。而每一个 Test Case 应该只测试一种场景，根据case复杂程度，不同场景同样可大可，可以是某个单元的测试，也可以是端到端的测试(E2E)，当然也有特殊的写法比如工作流测试和数据驱动。

Case的独立性有哪些需要关注的点呢?

首先Test Suite内的Cases在执行时不应该相互影响，意思是说当我们有随机的跑其中某个Case或乱序的跑这些Cases时，测试的结果都应该是准确的。Suite level和Directory level同样要注意独立性的问题。系统较为庞杂时，可能会将数百上千的Cases放在一起跑，Robot本身不会规定Case执行的顺序，所以从某种程度上来说同一层级的Cases是随机执行的。很典型的情况就是，测试用例在本地调试时怎么跑怎么过，放到Server上所有Cases一起跑的时候就会Fail,还可能是偶发的，这种情况下就很可能是由于其他Case的痕迹影响到了它，查找问题的根源往往比较耗时。

保持Case的可迁移性

Case的可迁移性主要考虑三点 : Case对执行环境的依赖 ; Case对外部设备的依赖;Case对测试对象的依赖。

Case对执行环境的依赖
尽量减少对执行环境的依赖。举一个例子，你在本地PC上使用rf框架编写、调试用例后，上传到Git，然后你的领导可能会拉取你的用例在他的本地运行，随后又被部署到持续集成服务器上。所以你编写的用例时就要尽量避免使用不同平台的库或者shell命令。

再举个例子，如果你因为业务需要而修改了测试库源码的话，此时不管是组内其他人还是CI服务器，肯定都会运行失败，这种情况该怎么解决呢？这里提供两个解决方法：

1. 将修改后的库做成测试库，上传到Git或者Pypi，对方可以通过pip安装更新；
2. 使用robotremoteserver做一个共享库放在远程主机上

Case对外部设备的依赖
有时为了业务测试需要，我们会引入一些外部设备来辅助测试，外部设备可能会持续升级或者更换，在编写用例时我们就需要考虑如何用一套Case更好的兼容这些测试设备。比如可以将外部设备的操作从测试用例中抽离出去，封装成测试库或关键字；

Case对测试对象的依赖
如果测试对象是一个软件平台，软件平台通常需要适配多种的设备，而设备的硬件配置可能是多种多样的：CPU、内存、组件的性能和数量都可能不同。对测试对象的依赖不仅要考虑在不同设备上的可执行性，重点还要考虑测试覆盖率。由于设备组件的增多你的用例可能无法覆盖到这些组件，或者捕捉不到某个性能瓶颈，这样测试结果的可靠性也大打折扣。

提升Case执行效率

不同的case执行时间相距甚远，短则数秒长则持续数天。数秒钟的简单功能测试用例和耗时数天的稳定性测试用例本身是没有什么可比性的。但是我当我们放眼某一个或者某一组case时，我们就需要重视Case的执行效率。不论是敏捷流程还是持续集成都讲究快速的反馈，开发人员能在提交代码后快速的获得测试结果反馈，测试人员能在最短的时间内执行更大范围的测试覆盖，不仅能提高团队的工作效率，也可增强团队的信心。

以使用rf为例，在编写用例时可以通过以下方面来提高用例的执行效率。

1.如果有对执行条件的检查，若检查失败，则尽快退出执行；
2.将数据准备或环境清除等工作抽取成关键字放到更高的层级中,，抽取时可能需要做一些组合, 但不允许出现重复的建删操作；
3. 用例中尽量少的出现sleep，建议用"wait until ..."来代替；
4. 可以采用并发执行用例的方法来提升效；

自动化用例编写规范

命名规范

Keyword命名

第一个单词应以小写字母作为开头，后面的单词则用大写字母开头。 如：getProjectId, connectDB

常量命名

常量的名字应该都使用大写字母，并且指出该常量完整含义。如果一个常量名称由多个单词组成，则应该用下划线来分割这些单词。 如：MAX_CHAR_LENGTH

参数命名

参数的命名规范和方法的命名规范相同，请在尽量保证参数名称为一个单词的情况下使参数的命名尽可能明确。如：${account} , ${investorName}

使用Tags

RF提供了通过在Settings中设置tags来管理用例的方法。Tag的应用非常的广泛和灵活，比如可以用来做用例筛选、版本管理、统计策略等。

怎么打tag看起来会更便捷？

• 可以在各个文件夹下打文件夹名字的tag，这样就可以根据tag单独的跑该文件夹下的用例，查看测试报告也更好看些;
• 在一些重要的用例上打上tag，可以单独跑关键用例;
• 某些用例如果不想执行，可以打上tag，设置不执行。

让case具有文档性

在考虑Coding Style时我们可以设置一些固定的规则,大家只要按照这个规则来做,实践几次之后Coding Style就会趋于统一. 而考虑将Case写的如同文档一般则需要更多的主观能动性。

敏捷开发(Agile Development)在国内的发展已经越完善，伴随之而来的便是敏捷测试(Agile Testing)。敏捷思想强调以人为核心，在整个开发流程中，只写有必要的文档或尽量少写文档，这也是它与传统的瀑布模型的差别。

为了不造成误解，这里有必要插入的说一下敏捷测试的几个特点：

• 敏捷测试应该是敏捷开发的一部分；
• 敏捷测试具有鲜明的敏捷开发的特征，如测试驱动开发(TDD),验收测试驱动开发(ATDD)。也就是说，单元测试是敏捷测试的基础，如果没有足够的单元测试，就无法应对将来需求的快速迭代，也无法实现快速而稳定的持续交付；
• 优秀的敏捷测试是基于自动化测试的；
• 敏捷测试无时不在，无处不在。

需求设计不断的更新，而文档往往不能被很及时的更新，那这样的话怎么才能让测试人员如何快速的掌握某个功能或者产品的需求和当前状态呢?

"Tests as Documentation."

清晰易懂的用例名

在实际的工程中，我们可能会新建一个目录来存储测试点相近的测试用例。每一个Case都对应一个测试点，而用例名则应该概括总结对应测试点的核心内容，这样当我们在浏览一组用例时,仅仅通过用例名就能大致了解里面的测试内容,也方便寻找某个Case。

清晰易懂的用例名

在实际的工程中，我们可能会新建一个目录来存储测试点相近的测试用例。每一个Case都对应一个测试点，而用例名则应该概括总结对应测试点的核心内容，这样当我们在浏览一组用例时,仅仅通过用例名就能大致了解里面的测试内容,也方便寻找某个Case。