既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
• 拥有编码能力 至少要熟悉自动化工具/框架的代码语言,最好有一定的编码能力,同时代码逻辑要清晰,否则不仅不能保证用例的逻辑性、业务性与健壮性等要素,也不能保证效率;
• 熟悉被测系统; 熟悉被测系统对任何测试人员来说都是最起码的要求;
• 掌握一个自动化测试框架/工具; 可以根据所掌握的代码,学习一门自动化测试的框架,如 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
参数命名
参数的命名规范和方法的命名规范相同,请在尽量保证参数名称为一个单词的情况下使参数的命名尽可能明确。
如:{investorName}
使用Tags
RF提供了通过在Settings中设置tags来管理用例的方法。Tag的应用非常的广泛和灵活,比如可以用来做用例筛选、版本管理、统计策略等。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!**
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新