自动化测试

由于前期三个月公司的项目一直在改需求阶段，一直是手动测试，现在项目雏形以及基本页面功能都确定下来，为了不让自己陷入天天测同一功能的无限循环中，故开始自动化测试的学习之路，也为自己以后的发展铺铺路。 一.自动化测试介绍 自动化测试使用情况： 软件需求变动不频繁 项目周期足够长 自动化测试脚本可重复使用 需要大量时间和人力（性能测试，配置测试，大数据量输入测试） 目的：主要用于回归测试：检验修复bug后确保好的功能没有被破坏，并不是为了找新bug。 下面从四个方面来说明： 测试类型/流程/框架/工具 1.自动化测试类型： API testing：webservice测试，接口测试，输入参数，看服务端数据是否正确 UNIT testing：单元测试，测试代码测试方法输入的参数与return返回值 GUI testing：自动化方式驱动浏览器实现手动模拟的方式，如下面的selenium自动化，用脚本驱动浏览器 performance testing：性能测试，产生大的并发，负载，多线程方式产生并发，节省成本。 2.自动化测试流程： 设计测试用例-设计测试脚本-运行测试脚本-获取测试结果-分析测试报告 分析case的可能性，计划评估，做测试用例，测试环境搭建（测试数据准备），自动化脚本书写，执行脚本，查看测试的脚本。 3，测试代码结构 配置：测试对象，测试环境，输入参数 src:类库

在自动化测试过程中，经常会遇见有验证码的场景，例如：用户登录，用户支付，用户注册，用户重置密码，身份确认等场景。 验证码主要分为以下几种： 1.图文验证码（普通验证码） 基本由数字，中文，英文等组合而成，用户在文本框中输入验证码进行校验。如下图： 2. 短信验证码 输入手机号，点击获取验证码，将手机上获取到的验证码输入到文本款中进行验证。如下图： 3.滑动验证码 根据提示绘图或者拖动图片完成拼图 或者： 4.识物点击验证码 根据目标（电饭锅）选中图中相关的物体 自动化测试遇到验证码，处理过程： 1.第一种处理办法：修改代码，直接绕过去，取消前后端代码对验证码的校验 适用于场景：主要是 测试需求功能 是否正确，这里暂时对验证码需要不高，可屏蔽。这几种验证码都可以采用这个办法 2.第二种处理方法：万能验证码 适用于场景：主要是 测试需求功能 是否正确，这里暂时对验证码需要不高。相较于第一种而言，不需要隐藏代码，只需要在测试环境中对于所有使用验证码的地方给与通过：图文验证码和短信验证码可设定一个万能验证码，其他两种行为验证码返回true。这几种验证码都可以采用这个办法 3.第三种处理办法：sleep.time(等待时间)，设置等待时间，测试人员手动完成验证码校验。这几种场景都可以使用。优点：不需要修改代码也不需要屏蔽任何代码，同时可以进行验证码与功能联合起来的测试。缺点：不是完全的自动化

参考链接 https://blog.csdn.net/songlh1234/article/details/84317617 来源： https://www.cnblogs.com/wangdadada/p/12238780.html

本人主要做一个知识的归类与记录，如是转载类文章，居首都会备注原链接，尊重原创者，谢谢！ 此文转载原链接：https://www.cnblogs.com/bianfengjie/p/9210311.html 一、前言 功能测试是测试工程师的基础功，很多人功能测试还做不好，就想去做性能测试、自动化测试。很多人对功能测试的理解就是点点点，如何自己不用心去悟，去研究，那么你的职业生涯也就停留在点点点上了。在这里，我把我对功能测试的理解写下来。 二、功能测试所需要掌握的技能 2.1 熟练使用SQL 1、常用的 sql 语句一定会写。比如说增删改查之类。 2、了解数据库的事务、会编写存储过程、熟练常用的系统函数。 3、了解并可以进行数据库的备份、迁移、还原、镜像等操作 4、对 sql 语句进行调优，并对可以对运行的语句监控查看性能 5、了解数据库集群等操作。 2.2 Linux Linux是测试人员的基础功，不需要掌握太难或者很不常见的Linux命令，正常能做到查看日志，定位问题就可以了。 1、基本命令 常用的Linux基本命令，面试经常会问的，或者给出一种场景，问你用什么命令。 具体请看：https://www.cnblogs.com/bianfengjie/p/9213180.html 2、查看日志 初级测试人员在工作时经常遇到，发现bug，开发不承认或者不愿意解决的情况

本文字数约810字，阅读约为3分钟 在手工测试几个小项目之后，为了保证后期维护，开始写了一些接口的自动化，因为测试对象主要是小程序，并没有很成熟的用于小程序的自动化工具，就使用了一些框架写的脚本，主要框架使用的是testng，选择好使用的框架，就要完成自己的自动化测试代码，完成的case还是一些主流程和常见会出现bug的case，这些case都是测后端接口返回，而现在负责业务变更频繁，没有做ui相关的自动化，前端展示还是依靠手工来测。 如何将本地写的自动化case能最大化的发挥测试的功能，就是我们这里要说的 在持续集成环境上跑自动化测试 。 因为持续集成，会强制测试通过才能合并代码，在合并代码之前就能知道测试是不是都通过了，可以帮助程序员获得最直观的反馈，知道哪里可能存在问题，这样才能做到防患于未然，吧bug杀死在摇篮里。 但这样说也不是绝对，因为我在之前写自动化case的时候，需要指定一个人的身份id，后来自动化挂掉的原因，是这个人从数据库改了通过id更改了他自己的身份，所以后续我们也将自动化测试和手工测试数据分离，尽量不影响自动化测试。 下面流程描述的是自动化测试配合持续集成的一个标准流程 在提交代码前，先本地跑一边单元测试，这个过程很快，失败了需要继续修改 我的操作一般是，每写完一个@Test都运行一遍，有问题就及时更改，都保证没问题后，运行一遍xml文件

什么是Appium？ 第三方自动化框架（工具），扩充了selenium webdriver 协议，在原有的基础上添加了移动端测试API selenium webdriver 指定了客户端到服务端的协议 appium 是一个开源的、跨平台的自动化测试工具，用于app的自动化测试 appium 是跨平台的，支持android，ios，firefoxos等操作系统下的app测试 什么是selenium？ 用于web应用程序测试工具，直接运行在浏览器，模拟用户操作，覆盖Windows、Linux、Mac，覆盖 IE、Chrome、firefox等浏览器，Java、Python多种语言进行脚本编写 官网： https://docs.seleniumhq.org/download/ 版本： http://selenium-release.storage.googleapis.com/index.html 什么情况适合做自动化： 周期比较长的、需求比较稳定的、迭代周期比较长的 使用appium 做APP自动化测试的原理： 1）appium 的核心其实是一个暴露了一系列rest api的server 2）这个server的功能其实很简单：监听一个端口（4723），然后接受由client发送的command 3）然后翻译 这些command，把这些command

前言： Jmeter是目前最流行的一种测试工具，基于此工具我们搭建了一整套的自动化方案，包括了脚本添加配置、本地配置和运行、服务器配置等内容，完成了自动化测试闭环，通过这种快捷简便高效的方式，希望可以解决自动化测试上手难的痛点。下面闲言少叙，我们直接切入实战： 一、准备自动化测试物料 1、开发运行工具Jmeter，（下载地址： http://jmeter.apache.org/download_jmeter.cgi ） 2、开发环境为已发布ready； 3、测试脚本已准备ready； 4、脚本运行环境已准备（fat或者uat）； 二、自动化测试通过标准 1、成功Status 返回200 ； 2、失败返回404、500等； 3、每个脚本专用断言； 三、自动化脚本存储 脚本全部存储在Gitlab仓库中，（脚本的存储规范请参考：GitLab Jmeter测试包通用设计1.0版） 项目根目录新建文件夹，前面文件夹名和项目名保持一致，后缀加“-test”，如下图文件夹： 四、自动化测试Script Rules 1、脚本命名为接口名 2、存储类型为后缀jmx的文件 3、线程数设置为1（冒烟测试无需多线程并发） 4、必须包含断言判断，状态检测设定为200 五、自动化测试Script Steps 1、添加线程组，脚本命名为接口名，点击存储 为后缀jmx的文件 2、将线程数设置为1，其他设置为默认

本文介绍企业在敏捷和DevOps的逐步转型过程中，测试如何应对挑战，有的放矢进行测试，建立适合产品自身发展阶段、产品特点的敏捷测试能力。 敏捷和DevOps 敏捷和DevOps转型始终是被业务目标和客户需求驱动的。市场竞争环境越来越激烈，新商业模式的创新和变现时间窗口越来越短，催生更多的企业采取精益创业的方式，捕捉市场需求后，尽量缩短TTM产品面世时间，快速推出MVP产品并快速响应客户需求迭代产品。 以华为为例，在2008年左右的时候，华为的项目还是采用传统的交付方式，例如在年初开始一个项目，在项目立项之初就会把客户的需求全部收集好，包括一些用户的反馈，并把需求做了全年的排序。年中的时候发布产品给用户，两个月之后再出一个补丁，最终年底出一个正式的版本。当时版本交付的节奏还是比较慢的，但是对质量要求比较强。因为产品发布给客户以后，下一个补丁需要两个月，如果用户在这个期间发现产品问题，他们只能再等两个月，而在这期间如果用户不接受我们的产品，会导致项目前功尽弃，所以就对产品的质量有严格的要求。 产品逐渐向敏捷方向发展，这时有一部分研发工具平台已经陆续转到云上去了，一些测试类的工具也需要转型。之前产品的交付是半年、两个月发一次，转型之后变成一个月，甚至两周发一次，但这时的转变并不彻底，与客户的交付过程仍然存在一些问题。后来越来越多的工具向平台化、服务化方向转型

在做性能测试的过程中，我写了两个虚拟类 ThreadLimitTimeCount 和 ThreadLimitTimesCount 做框架，通过对线程的标记来完成超时请求的记录。旧方法如下： @Override protected void after() { requestMark.addAll(marks); marks = new ArrayList<>(); GCThread.stop(); synchronized (this.getClass()) { if (countDownLatch.getCount() == 0 && requestMark.size() != 0) { Save.saveStringList(requestMark, MARK_Path.replace(LONG_Path, EMPTY) + Time.getDate().replace(SPACE_1, CONNECTOR)); requestMark = new Vector<>(); } } } 其中我用了 synchronized 关键字同步，但是在匿名类的单元测试中出现一个BUG，匿名类中没有实现 clone() 方法，也不能直接使用深拷贝方法，导致无法直接复制对象，所以我创建了多个功能相同的匿名线程类。问题来了，在代码执行过程中，偶然会出现记录 markrequest

单元测试或是最好的项目文档。 很早之前在学习使用Java做测试的时候，得到过一个神秘大佬的帮助，在一起聊过单元测试，基本结论就是：单元测试大概率没啥鸟用。 众所周知，自动化测试相比手动测试一个比较明显的特点就是见效慢，需要积累一定的时间所产生的的价值才能超过手动测试，这还是在比较理想的情况下。某些时候可能永远也超不过。而单元测试更甚，据大佬和吹牛逼的群聊中判断：好的单元测试代码大概是被测代码的2-3倍，这种工作量对于开发人员来讲是不可接受的。单元测试见效比自动化测试更慢，这一点也是大家的共识，甚至到不了见效的时候就黄了。 之前对单元测试进行过一些尝试，写过一点文章： Maven和Gradle中配置单元测试框架Spock Groovy单元测试框架spock基础功能Demo Groovy单元测试框架spock数据驱动Demo 人生苦短？试试Groovy进行单元测试 使用WireMock进行更好的集成测试 如何测试这个方法--功能篇 如何测试这个方法--性能篇 单元测试用例 JUnit 5和Selenium基础（一） JUnit 5和Selenium基础（二） JUnit 5和Selenium基础（三） 近几日一直在对之前的性能测试框架进行优化，在这个过程中，我之前利用Groovy单元测试框架spock写过的两个性能测试框架的单元用例起到了非常大的帮助