自动化测试思路
学习+总结+记录=成长！html
自动化测试介绍
自动化测试(Automated Testing)，是指把以人为驱动的测试行为转化为机器执行的过程。实际上自动化测试每每经过一些测试工具或框架，编写自动化测试用例，来模拟手工测试过程。好比说，在项目迭代过程当中，持续的回归测试是一项很是枯燥且重复的任务，而且测试人员在天天重复劳动的工做之下，也丝毫得不到成长。此时开展自动化测试就可以帮助测试人员从重复、枯燥的手工测试中解放出来，提升测试效率，缩短回归测试时间。通常来讲，自动化测试一般都会跟持续集成系统（好比Jenkins）配合使用。shell
但在自动化实践过程当中，每每会发现理想和现实之间的差距很大。自动化测试的劣势，主要体如今如下几方面：编程
- 相对手工测试，自动化测试对测试人员的要求相对较高；
- 测试用例须要根据版本迭代进行更新，有必定维护成本；
- 不能期望自动化测试去发现更多新的BUG，自动化测试能发现的缺陷远远比手工测试少；
- 自动化测试的产出价值每每在于长期的回归测试，短时间内发挥的做用可能不明显；
但愿借助自动化流程解决的问题
- 测试时间紧张，手工测试可能覆盖不全，容易错过某些边界状况；
- 模块间强耦合时，单纯从页面进行测试时，比较难深刻的发现问题；
- 回归测试时，须要投入较大的人力/工时；
- 实现手工测试没法达成的测试任务；
- 经过编写测试用例，加深对业务/数据的认知，有助于下阶段迭代中发现隐藏的问题；
引入自动化测试的前提条件
项目周期长，需求变更不频繁 测试用例的稳定性决定了自动化测试的维护成本。若是软件需求变更过于频繁，测试人员须要根据变更的需求来更新测试用例以及相关的测试脚本，而脚本的维护自己就是一个代码开发的过程，须要修改、调试。若是所花费的成本不低于利用其节省的测试成本，那么自动化测试即是失败的。服务器
项目中的某些模块相对稳定，而某些模块需求变更性很大。咱们即可对相对稳定的模块进行自动化测试，而变更较大的还是用手工测试。并发
自动化测试脚本可重复使用 若是费尽心思开发了一套近乎完美的自动化测试脚本，可是脚本的重复使用率很低，导致其间所耗费的成本大于所创造的经济价值，自动化测试便毫无心义。框架
测试任务手工测试难以实现 好比压力测试，大数据或者大量重复数据测试，必须有自动化工具的支持。工具
作自动化测试须要具有的能力
- 拥有编码能力 至少要熟悉自动化工具/框架的代码语言，最好有必定的编码能力，同时代码逻辑要清晰，不然不只不能保证用例的逻辑性、业务性与健壮性等要素，也不能保证效率；
- 熟悉被测系统； 熟悉被测系统对任何测试人员来讲都是最起码的要求；
- 掌握一个自动化测试框架/工具； 能够根据所掌握的代码，学习一门自动化测试的框架，如 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服务器，确定都会运行失败，这种状况该怎么解决呢？这里提供两个解决方法：
- 将修改后的库作成测试库，上传到Git或者Pypi，对方能够经过pip安装更新；
- 使用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。