自动化测试框架

前段时间由于公司测试方向的转型，由原来的web页面功能测试转变成接口测试，之前大多都是手工进行，利用postman和jmeter进行的接口测试，后来，组内有人讲原先web自动化的测试框架移驾成接口的自动化框架，使用的是java语言，但对于一个学java，却在学python的我来说，觉得python比起java更简单些，所以，我决定自己写python的接口自动化测试框架，由于本人也是刚学习python，这套自动化框架目前已经基本完成了，于是进行一些总结，便于以后回顾温习， 有许多不完善的地方，也 遇到了许多的问题，希望大神们多多指教 。 下面我就进行今天的主要内容吧。（初学者的成功之路，哈哈哈~~） 1、首先，我们先来理一下思路。 正常的接口测试流程是什么？ 脑海里的反应是不是这样的： 确定测试接口的工具 —> 配置需要的接口参数 —> 进行测试 —> 检查测试结果（有的需要数据库辅助） —> 生成测试报告（html报告） 那么，我们就根据这样的过程来一步步搭建我们的框架。在这个过程中，我们需要做到业务和数据的分离，这样才能灵活，达到我们写框架的目的。只要好好做，一定可以成功。这也是我当初对自己说的。 接下来，我们来进行结构的划分。 我的结构是这样的，大家可以参考下： ​​​​​​ common：存放一些共通的方法 result：执行过程中生成的文件夹，里面存放每次测试的结果

有时间研究下，先记录 httprunner 是一款面向 HTTP(S) 协议的通用测试框架,只需编写维护一份YAML/JSON脚本 anjular web 前端框架 anjular+java前端主要写UI和交互，后端主要写接口和逻辑 类似于postman，编写用例，然后调试用例 接口报警监控----监控QPS、返回码，cpu、内存、业务 来源： https://www.cnblogs.com/qq909283/p/11492959.html

自动化测试一些问题 什么是自动化测试？ 自动化测试，顾名思义，自动完成测试工作。通过一些自动化测试工具或自己造轮子实现模拟之前人工点点/写写的工作并验证其结果完成整个测试过程，这样的测试过程，便是自动化测试。自动化测试，看上去很美，感觉好像是第一次工业革命，它开创了以机器代替手工劳动的时代，实则不然.因为每一个自动化测试的case都是从手工测试做起的，如果没有手工测试的基础，是没法进行自动化测试。 为什么要进行自动化测试 为什么进行自动化测试，答案要从自动测试的收益和人肉测试的成本说起： a. 自动化测试节约成本(根据项目) 毕竟自动化测试确实解放了一批人力（人力成本才是IT公司最大的成本），可以让机器没日没夜的执行一些重复劳动. b.有些测试项目手工很难实现(手工成本较高) 比如12306的压力测试、负载测试，同时找那么多人去测试不现实可以通过机器去模拟. c.项目质量流程需要 比如版本管理需要build verify，以保证check in的code不会影响版本库。类似于smoke test 自动化测试的优缺点 优点 　 避免测试人员因重复劳动产生厌倦 提高测试效率 保证每次测试地一致性和可重复性 更好的利用无人值守时间 进行一些手工无法进行的测试 维护成本相对比较高 缺点 系统开发时间不一定能缩短 没有手工测试发现缺陷多 UI layout issue 不容易发现

导语：”在国外，资深的软件测试人员大多是手动测试，他们厉害之处在于测试用例的设计，但在国内，很多测试人员都把自动化测试当成很厉害的资本，为什么？” 偶然在知乎上看到一篇关注度很高的话题，标题如上。 作为一名从业8年有余的软件测试工程师，并且一直在外企做测试的我， 忍不住想发表一些自己的看法和见解。 我觉得在国内，很多公司或者个人把自动化测试当成一个了不起的资本，根本是源于国内大家对代码的无上崇拜，这也造就了国内现在IT互联网行业内一个鄙视链： 开发---> 测试开发--->自动化测试--->纯手工测试。所以，在这个鄙视链中，纯手工测试属于底端被碾压的生物。 实际上，我觉得这是一种严重的偏见，并且体现了其对测试行业认知的极其不专业。 首先，我们不能否认自动化测试的作用，他肯定是将来软件测试发展的一个大方向。自动化测试将QA从繁重的重复劳动中解放出来，优化测试资源，提高测试效率，对产品质量保证起到积极的作用；另外，一个有自动化测试脚本、框架、工具开发能力的QA，更有竞争力也是一件毋庸置疑的事情。 但是，但凡做过测试工程师的朋友都知道，一些逻辑非常复杂的场景是很难用自动化脚本实现的，就算要强行实现，也性价比很低，因为太费时费力了。所以用手工测试来执行一些奇葩的场景更灵活方便并且可以发现很多问题；而且，从事过测试的人应该很清楚，同样的一个测试任务，交给不同的测试人员是会有特别不一样的结果

自动化:由机器设备代替人为自动完成指定目标的过程 自动化测试:由程序代替人为去验证程序功能的过程 为什么要进行自动化测试? 解决-回归测试 压力测试 兼容性测试 提高测试效率,保证产品质量 什么阶段开始自动化测试? 功能测试完毕(手工测试) 手工测试:就是由人去一个个输入测试用例,然后观察结果; 自动化测试所属分类(代码可见度) 黑盒测试 灰盒测试 白盒测试 提示: Web 自动化测试属于黑盒测试(功能测试) 优点: 较少时间内运行更多的测试用例 自动化脚本可重复运行 减少人为的错误 测试数据存储 缺点: 不能取代手工测试 手工测试比自动化测试发现的缺陷更多 测试人员技能要求 3. 自动化测试分类 Web(UI)自动化测试 接口-自动化测试 移动(app)-自动化测试 单元测试-自动化测试 什么Web 项目适合做自动化测试? 需求变动不频繁 项目周期长 项目需要回归测试 如何进行 Web 自动化测试? QTP(收费) Selenium (开源) Jmeter(开源,Web,接口,性能) LoadRunner(收费.Web,性能) Robot framework 基于Python 可扩展的( 关键字驱动 ) 自动化测试框架 主流工具-汇结: Web 自动化测试:selenium,robot framework App端:Appium MonkeyRunner,UIautomation

本文已经首发于 InfoQ中文站 ，版权所有，原文为《XXX》，如需转载，请务必附带本声明，谢谢。 InfoQ中文站 是一个面向中高端技术人员的在线独立社区，为Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如 QCon 、线下技术交流活动 QClub 、免费迷你书下载如 《架构师》 等。​ 在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：“到底什么是敏捷软件测试？”，“敏捷软件开发还需要测试工程师吗？”。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。 确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的“频繁交付”，还是对“可工作的软件”的度量

一、用户关键字 1、定义 其实就是将python中的一个功能封装成一个函数，然后在rf中使用一个特定的名字来调用这个函数。 2、创建用户关键字的流程 ①创建一个测试套件，右键后选择new user keyword，命名后创建，出现以下标志 ，即代表成功创建用户关键字circle ②点击circle后进入该关键字，开始编写关键字内容（即完成函数的功能），这里我们编写了一个循环打印指定次数的函数，传参为${times} ③建好之后就可以在该测试套件下新建一个test case，然后通过用户关键字的名称引用该方法，传入该方法需要的参数（函数内没有参数可以不传）后即可使用（注意：若用户关键字创建成功，那么引用时关键字会是深蓝色） 3、有返回值|多个参数的用户关键字创建 返回值在用户关键字的Return Value中设定，多个参数之间用|隔开 二、创建资源包并调用 在项目文件下右键，新建Resource 给资源包命名并将其设置为robot 将要用到的用户关键字拖拽到该资源包里 点击要用到该资源包的测试套件，引入Resource，在path中输入资源包的正确路径（同一项目内只需要输入资源包名即可） 随后就可以使用了 三、setUp/treatDown 分别是在执行测试用例之前和执行完成之后运行的方法/关键字 点击测试用例，随后点击Settings

一、定义变量 在第一列用${变量名}创建一个变量，在第二列用Set variable设置变量（Set Global /Suite/Test Variable分别代表变量的可用范围是所有测试套件/当前测试套件/当前测试用例中有效），在第三行输入变量的值 二、打印 在第一列中输入关键字log，随后打印变量${a}，输出正确的变量值，证明创建变量和赋值的语句正确，打印的语句也正确 三、定义列表/数组 在第一列输入${abc}，第二列Create List，第三列及后续依次输入列表中的元素，注意${abc}只是数组名，并不是与后续的元素值对应的 输出结果： 其中robotframework会在打印时将数组中的元素转换成字符串，在打印的时候回在列表元素前加一个u，意思是将此元素转换成了Unicode编码 四、字符串连接 第一列定义变量，第二列输入关键字Catenate，后续输入想连接的单个字符串，连接相当于两步动作，一是连接三个词，二是将连接后的词赋值给${abc} 输出结果： 五、时间类关键字 主要是gettime关键字用于获取时间并赋给变量，然后是sleep，输入时间（单位为秒）后执行休眠操作 输出结果： 六、分支语句 通过robotframework来实现if分支语句，关键字是run keywork if，随后输入判断语句，还可以通过ELSE IF+判断语句和ELSE来继续判断，注意点

本文技术难度★★★，如果前编内容顺利执行，请继续。 如果Selenium尚无法灵活运用的读者，本文可能难度较大。 “理论联系实惠，密切联系领导，表扬和自我表扬”——我就是老司机，曾经写文章教各位怎么打拼职场的老司机。不记得没关系，只需要知道：有这么一位老司机， 穿上西装带大家打拼职场！ 操起键盘带大家打磨技术！ 上一篇IT老司机带着各位已经成功安装了Cypress，并且让Cypress成功运行起来了。上篇任意门☛ (后Selenium时代，网页自动化测试用Cypress) 本篇，IT老司机教你写第一个Cypress测试用例。 · 正 · 文 · 来· 啦· 首先，回忆一下，怎么运行cypress？用npm命令安装cpress。新建一个web工程的目录，执行npx cypress open，然后稍等一会儿。命令成功返回，则当前目录出现一个cypress目录。同时，一个对话框出现，cypress执行界面出来了。 点开“examples”前面的三角图标，里面是示例test cases. 点击里面的具体js文件，就开始执行测试用例了。 当然，可以点右上角的“Run all specs”，执行全部用例。 Cypress界面出来了，就别关了。 起码在读者阅读完本文前，都不要关！ 然后，我们可以学习今天的内容了。先写一个最近简单的test case。 在 cypressintegration

一般具有如下几个特征的项目，就被叫适合做自动化。 1）任务测试明确，不会频繁变动 2）每日构建后的测试验证 3）比较频繁的回归测试 4）软件系统界面稳定，变动少 5）需要在平台上运行相同的测试案例、组合遍历型的测试，大量的重复测试任务 6）软件的维护周期长 7）项目的进度压力不大 8）被测系统开发较为规范，能保证系统的可测性 9）具备大量的自动化测试平台 10）测试人员具备较强的编程能力 当然并不需要都满足以上10中情况才能开展自动化测试工作。一般满足以下三点就可以对项目开展自动化测试。 1.软件需求不频繁变动 自动化测脚本的变化的大小与频率决定了测试脚本维护的成本。如果软件需求变化过于频繁，那么测试人员需要根据变动的需求不断的更新自动化测试用例，从而适应新的功能。脚本的维护本身就是一个开发代码的过程，需要扩展，修改，调试，有适合还需要对架构做出调整。如果花费的维护成本高于其节省的测试成本，那自动化测试就失去了它的价值与意义了。 适当的做法，就是先对系统中相对稳定的模块与功能进行自动化测试，变动较大的部分用手工进行测试。 2.项目周期较长 由于自动化测试需求的确定，自动化框架的设计，脚本的开发与调试都是需要时间完成的，而这个过程本身就是一个软件开发的过程，如果项目周期较短，没有足够的时间去支持这样的一个过程，那自动化必然是行不通的。 3.自动化测试脚本可以重复使用