自动化测试

待补充 来源： https://www.cnblogs.com/guizang/p/11694404.html

待补充 来源： https://www.cnblogs.com/guizang/p/11694407.html

https://testerhome.com/topics/15440 来源： https://www.cnblogs.com/Ray-2019/p/11686353.html

Selenium是一个开源的用于Web应用的自动化测试工具，支持多平台（Windows、Lniux等）、多浏览器（Chrome、Firefox、IE等）、多语言（Python、Java、C#等），目前使用越来越广泛 Selenium到底是怎么工作的？ 实际上在Selenium工作的过程中有三个角色，其一便是跟我们最近的自动化测试代码：自动化测试代码发送请求给浏览器的驱动，其二便是浏览器的驱动：它来解析这些自动化测试的代码，解析后把它们发送给浏览器，其三便是浏览器：执行浏览器驱动发来的指令，并最终完成工程师想要的操作。 从技术角度对应这三个角色 WebDriver API（基于Java、Python、C#等语言），对于Python来说就是我们使用命令“pip install selenium”来安装的selenium模块，其二便是浏览器的驱动（browser driver）每个浏览器都有自己的驱动，均以exe文件形式存在，比如谷歌的chromedriver.exe、火狐的geckodriver.exe、IE的IEDriverServer.exe，其三便是浏览器，浏览器当然就是我们很熟悉的常用的各种浏览器。 对于每一条Selenium脚本，一个http请求会被创建并且发送给浏览器的驱动，浏览器驱动中包含了一个用来接收这些http请求的HTTP Server

为什么要用excel存储数据？ @data(*users)所以数据是哪种形式无关紧要：列表 excel 数据库 txt文件 ini yaml配置文件# 写道excel?不合适，非得这样，过滤下咯 测试数据的分组 分组的依据：操作步骤是否一致，定位表达式是否一致 # 接口自动化的步骤都是一样的，所以用excel保存，读取excel，获取测试 # 接口自动化区别：测试数据的不同 ui自动化测试比接口自动化测试要写很多代码，每个项目的业务逻辑不通 ui测试本质决定了这种工具很难做出来：图像识别,AI 关键字驱动==》RF==》自动化UI 测试效率： web自动化测试效率很低，那么少启动浏览器 提升效率的前提是保证用例的独立性和稳定性 页面元素定位方式的选择： 第一种： 通过页面属性来配置，元素是属于页面的行为，可以放到类属性中 # 页面元素定位表达式，可以作为类属性，这些事不变的 当需求放生变化时，改的地方尽量少，可维护性强 第二种： 放到单独文件中 来源： https://www.cnblogs.com/ella-li/p/11639263.html

原文首次发布与 flow.ci Blog >> 链接 ，转载请联系:) 准备了很久，CI Weekly 第一期终于来了。 CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享，包括国内外关于持续集成、持续交付，持续部署、自动化测试、devops、敏捷开发等实践教程、资源与工具，以及一些工程师文化相关的程序员 Tips。 同时，CI Weekly 会坚持每周发布一期精选文章，每一期的文章尽量围绕 CI 相关的 topic 展开，在 flow.ci 微信公众号、官方微博，知乎专栏，简书等同步更新，欢迎关注或投稿:) 第一期篇幅有点长，内容丰富，请准备好开启新的技术旅途~ 『 持续集成相关实践教程 』 ## 使用GitLab来实现IOS项目的持续集成CI 这篇文章讲述了持续集成和交付/部署（CI/CD）方面的一些基础知识，集合APP开发中遇到的一些问题，优化产品打包、测试过程。（via : 简书cjzhao ） ## Jenkins+GitHub+Xcode+fir搭了一个持续集成环境 使用Jenkins+GitHub+Xcode+fir搭建持续集成环境，过程记录很详细。（via :简书 宣X_x ） ## Android CI with docker *develop -> commit -> build -> test -> ( deploy) -> repeat

前言： 怎么设计自动化测试用例？是不是所有的手动用例都适合转成自动化测试用例？ 设计自动化测试用例需考虑的方面： 1、并不是所有的手工用例都要转为自动化测试用例。 考虑到脚本开发的成本，不要选择流程太复杂的用例。如果有必要，可以考虑把流程拆分成多个用例来实现脚本。 2、选择的用例最好可以构建成场景。 例如，一个功能模块，分多个用例，多个用例使用同一个场景。 3、选择的用例可以带有目的性。 例如，这部分是用例做冒烟测试，那部分用例是做回归测试等，当然，会存在重叠的关系。如果当前用例不能满足需求，那么唯有修改用例来适应脚本和需求。 选取的用例可以是主体流程，这部分适用于冒烟测试。 4、选取的用例可以是你认为是重复执行，很烦琐的部分。 例如，字段验证、提示信息验证这类，这部分适用于回归测试。 5、自动化测试也可以用来做配置检查、数据库检查。这些可能超越了手工用例，但也算用例拓展的一部分，项目负责人可以有选择地增加。 6、平时在手工测试时，如果需要构造一些复杂的数据或重复一些简单的机械式动作，则告诉自动化脚本，让它来帮你，或许你的效率会因此而得到提高。 在编写自动化测试用例过程中应该遵守以下几点原则： 1、一个用例为一个完整的场景，从用户登录系统到最终退出并关闭浏览器。 2、一个用例只验证一个功能点，不要试图在用户登录系统后把所有的功能都验证一遍。 3、尽量少的编写逆向逻辑用例

　　自动化测试用例的编写是实现项目自动化的核心，合理的用例设计是保证自动化效益和实用性的关键，也直接决定了自动化脚本是否具备可扩展和可维护性。由此，本篇文章主要为大家介绍了测试用例编写的规范和注意事项。 　 　一、自动化测试用例选择 　　自动化测试主要应用于基础功能的验证和回归，对于在项目迭代过程中不断修改的功能来说，手工测试的效率是大大高于自动化测试的。因此，我们在进行自动化之前，要挑选基础功能来进行自动化。在这个过程中，我们可以从手工测试用例中进行挑选，也可以专门为自动化编写一套用例。 　　在自动化初期，建议从手工测试用例中进行挑选。一方面手工测试用例的覆盖度最为全面，可以保证测试的全面性；另一方面，也会提高测试效率。我们挑选用例的原则是：清晰、简单、基础、改动小的功能。 　　 二、自动化测试用例编写 　　挑选完合适的用例之后，就是通过代码编写自动化用例的过程。这个过程主要包括数据预置、用例编写和用例后置三个步骤。 　 　1、数据预置 　　在进行用例编写之前，我们需要准备一些数据，保证用例能够真正的执行起来。比如，我们在测试一个网页登录功能，我们需要系统的URL参数、需要一个可以登录的用户名和密码；我们需要测试删除文件的功能，就需要提前上传一个文件，这个文件可以提前预置，也可以在执行删除操作之前，执行一个上传操作；通过哪种方式预置数据，需要根据项目的实际情况选择

深圳市共创力研发咨询 杨学明/文 TSE(Test System Engineer)简称测试系统工程师,作为系统工程（SE）团队的一员，很多公司目前还没有这样的角色，导致测试部分往往处理弱势，第一，不能进行端到端开发流程的测试，第二,不能对产品最终的测试质量负责。那么，TSE整个组织架构中是什么样的职责呢？以华为公司为例，华为公司在2010开始推行TSE的角色，并与其它成员相互配合，下图可以看到，TSE是系统工程的一部分，主要负责测试领域的把关: （这是一个虚拟的组织，TSE的部门依然是测试部） 制定总体的产品策略是TSE的首要职责, 详细的活动如下： l 活动目的：根据产品需求和研发状况确定测试策略以达到最优的测试效果。 l 责任角色：TSE。 l 参与角色：系统工程师。 l 活动输入：系统需求说明书、产品包开发与验证计划、Build计划。 l 活动输出 p 总体测试策略：说明产品各层级测试活的的测试策略和退出标准。如果必要，更新Charter-TR1阶段确定的自动化测试策略。 l 活动要求 p 特性和系统需求是测试的两个不同对象，总体测试策略中定义的测试对象必须同源，不能自行新增修改删除特性或系统需求。 p 如果计划中有某个层级的测试活动，则必须制定此层级的测试策略和退出标准。 p 如果进行迭代开发，需要明确各层级测试活动在迭代内的策略。 p 如果进行迭代开发

功能测试的一些心得 　　 一、前言 　　 功能测试 是测试工程师的基础功，很多人功能测试还做不好，就想去做 性能测试 、 自动化测试 。很多人对功能测试的理解就是点点点，如何自己不用心去悟，去研究，那么你的职业生涯也就停留在点点点上了。在这里，我把我对功能测试的理解写下来。 　　 二、功能测试所需要掌握的技能 　　2.1 熟练使用 SQL 　　1、常用的 sql 语句一定会写。比如说增删改查之类。 　　2、了解 数据库 的事务、会编写存储过程、熟练常用的系统函数。 　　3、了解并可以进行数据库的备份、迁移、还原、镜像等操作 　　4、对 sql 语句进行调优，并对可以对运行的语句监控查看性能 　　5、了解数据库集群等操作。 　　2.2 Linux 　　Linux是测试人员的基础功，不需要掌握太难或者很不常见的Linux命令，正常能做到查看日志，定位问题就可以了。 　　1、基本命令 　　常用的Linux基本命令，面试经常会问的，或者给出一种场景，问你用什么命令。 　　2、查看日志 　　初级测试人员在工作时经常遇到，发现 bug ，开发不承认或者不愿意解决的情况，测试人员怎么摆脱这样的问题呢？ 　　那就是根据发现的bug根据日志级别，来查看日志，定位问题。 　　那这里首先要说一下日志级别了。 　　首先记住这一点：日志级别越高，输出的信息越少 。 　　具体的日志级别分为四级： 　　info