自动化测试

1 初识自动化测试 如果以前没有做过自动化测试，那么就不了解自动化测试，可能会觉得自动化测试比较神秘，但是，我们在日常的计算机操作中，可能会碰到一些自动化处理的过程，这些过程和自动化测试比较接近。 例如， Windows操作系统的控制面板中，有一项功能： 任务计划向导 。 DOS批处理文件，直到今天的Windows Vista还在使用它。它更接近自动化测试。 上述的自动化处理过程还不是测试，因为 测试的重要一点是须要验证 ，将实际执行的结果和用户期望的结果进行比较。没有这个比较，就不是自动化测试。 2 自动化测试和手工测试有什么不同 亲手做过自动化测试之后，我们对自动化测试就有了一个感性的认识，至少有下列几点感觉： 　　l 机器人从来就不会感觉累 　　l 自动化测试的速度，是手工测试无法比的 　　l 测试结果准确。例如搜索用时即使是0.33秒或0.24秒，系统都会发现问题，不会忽视任何差异。 　　l 一旦脚本完成，可以一劳永逸地运行很多遍，重复使用。 从这里就可以初步体会到自动化测试的优越性―― 高效率、准确可靠 和 复用性 。同时，自动化测试也有不利的一面，即在 创造性、发现新缺陷 等方面能力不足。 有资料显示，即使自动化测试实施良好，也只能发现软件系统中30%的问题，而70%的问题还要靠手工测试发现。所以 自动化测试更适合于负载测试、性能测试和回归测试 。 概括起来

几款具有代表性的自动化测试工具汇总简介 一、传统自动化测试工具/商业工具（传统工具较多仅介绍两款，基本都是国外的） 1、QTP，全名HP QuickTest Professional software ，最新的版本为HP QuickTest Professional 11.0QTP是quicktest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。 因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以及现在越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。 其中包括：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。 2、IBM Rational Functional Tester（简称RFT）是一款先进的、自动化的功能和回归测试工具，它适用于测试人员和GUI开发人员。使用它，测试新手可以简化复杂的测试任务，很快上手；测试专家能够通过选择工业标准化的脚本语言，实现各种高级定制功能。 通过IBM的最新专利技术，例如基于Wizard的智能数据驱动的软件测试技术

简介 selenium录制器是最近刚流行起来的一个WEB自动化测试工具，由多测测团队开发。 Selenium录制器采用关键字驱动的理念以简化测试用例的创建和维护，它让用户可以直接录制屏幕上的操作流程，自动生成功能测试或者回归测试用例。 专业的测试者也可以通过提供的内置脚本和调试环境来取得对测试和对象属性的完全控制。 适用于Web、PC软件系统的功能测试、回归测试及客户测试。 自动化脚本录制、一键回放、报告查看，轻而易举实现自动化测试流程，自有编辑器一站式解决目前支持的浏览器包括IE(8、9、10、11)，支持Chrome及Firefox版本已经在开发中。 该工具支持不同级别的测试技能。 非程序员可以轻松地启动自动化测试项目，而程序员和高级自动化测试人员可以节省构建新库和维护脚本的时间。 工具的主要功能： 录制功能——创建回归测试检验软件功能和用户需求，支持IE系列浏览器所有HTML元素的快速录制、回放 对象属性参数化——通过工具提供的识别设置和数据输入，能随意改变对象的属性和数据。 测试报告功能——完成回归测试后，生成全面质量报告测试的结果。 原因诊断功能——出现查找错误地方，可以主动分析定位错误位置，可以通过调整查找策略（xpath、全路 径、属性集）准确查找到对象。 selenium+python脚本——专业的测试人员也可以通过工具提供的基于selenium框架来编写脚本。

2019年度十大自动化测试工具 1、Appium 官网： http://appium.io AppUI自动化测试 Appium 是一个移动端自动化测试开源工具，支持iOS 和Android 平台，支持Python、Java 等语言，即同一套Java 或Python 脚本可以同时运行在iOS 和Android平台，Appium 是一个C/S 架构，核心是一个 Web 服务器，它提供了一套 REST 的接口。当收到客户端的连接后，就会监听到命令，然后在移动设备上执行这些命令，最后将执行结果放在 HTTP 响应中返还给客户端。 License：免费 2、Selenium录制器 官网： http://www.aitestor.com/web/ WebUI自动化测试 Selenium录制器是多测测公司研发一款用于Web应用程序测试的工具，Selenium录制器未来将成为Web自动化测试工程师的首选。Selenium录制器采用关键字驱动的理念，简化测试用例的创建和维护，可以直接运行在浏览器中，就像真正的用户在操作一样。目前支持的浏览器包括IE(8、9、10、11)，这个工具的主要功能：测试系统功能——创建回归测试检验软件功能和用户需求，支持自动录制动作和自动生成 。对象属性的随意更改——通过工具提供的识别设置和数据输入，能随意改变对象的属性和数据。

敏捷和DevOps开发模式下，产品要具备随时可发布的能力，本文介绍如何应用测试金字塔和CI/CD持续自动化测试实现高效的测试反馈，保障随时发布产品的质量。 测试金字塔 自动化测试金字塔 最早是由Mike Cohn在2009年的著作《Succeedingwith Agile: Software Development using Scrum 》（《Scrum敏捷软件开发》）中提出。最早提出来的时候是一个三层的金字塔，从上到下分别是UI界面/Service服务/Unit单元测试，随着敏捷测试的不断推进，测试金字塔出现一些变种。实际使用中不用太拘泥于每层的名字，在服务化软件架构中Service层也可以理解为 API测试。 这种下宽上窄的三角形结构，代表在各层自动化的建议投入分配比例，越接近底层的单元测试建议的投入最多，接口测试居中，界面层建议的投入最少。 测试金字塔 Martin Flower关于测试金字塔有这样一段评论。“GUI测试用例还很脆弱，如对系统的一些修正可能导致很多用例的失败，这时候你需要重新录制。你可以放弃录制的方法来解决这个问题，通过写GUI测试代码，但是这样效率非常低。就算你已经很精通了GUI测试代码的编写，端到端的GUI测试用例也很容易出现不可预期结果的问题－一些用例成功一些用例失败，因此，基于GUI的自动化测试是脆弱、耗时（包括用例维护和执行）的

先来讲下相同点： 1、都需要理论知识，相同的用例设计方法：边界值，等价类，错误推导法，场景法 2、同样的测试方法 验证功能是否满足需求 3、都需要检查UI 界面设计是否合理 4、性能检测 并发 吞吐率的检测 以及应用的稳定性测试，没有卡死闪退等验证BUG 5、二者后台都是一致的 都调用访问一样的后台 ResultApi 简短聊下移动APP的测试 1、业务相对简单点，移动app实质是一个简化的WEB程序，屏幕小注重用户体验 2、移动端支持多种网络制式 2G 3G 4G WiFi 断网 网络信号差之间的切换界面显示，对了还需要测试信号差时APP运行情况 3、移动端需要测试中断测试 电话 短信 通知 断电等中断时软件的运行情况 当然也包括其他中断：蓝牙，闹钟，插拔数据线， 手机锁定， 手机断电， 手机问题(系统死机， 重启) 4、手机屏幕的限制对软件的影响 图片及文字的显示；上传不同的图片尺寸显示是否正常；图片和文字一起显示时，效果如何。 页面及按钮会受到屏幕大小的限制，再加上用户都是通过手指进行操作，一些按钮、选择框 等是否容易点击，多个可点区域位置较近时，点击部位稍微偏移，也许就会造成不同的结果，这种情况下是否可以达到预先的效果。 5、最后说下移动端安装卸载测试 升级测试 安装方式分为许多种： 用应用市场安装 用apk文件安装。 完全卸载（用户的profile文件） 部分卸载

CI/CD 是一种通过在应用开发阶段引入 自动化 来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：“ 集成地狱 ”）。 具体而言，CI/CD 在整个应用生命周期内（从集成和测试阶段，到交付和部署）引入了持续自动化和持续监控。这些关联的事务通常被统称为“CI/CD 管道”，由 开发和运维团队 以敏捷方式协同支持。 CI 和 CD 之间（以及不同 CD 之间）有什么区别？ 缩略词 CI / CD 具有几个不同的含义。CI/CD 中的“CI”始终指持续集成，它属于开发人员的自动化流程。成功的 CI 意味着应用代码的新更改会定期构建、测试并合并到共享存储库中。该解决方案可以解决在一次开发中有太多应用分支，从而导致相互冲突的问题。 CI/CD 中的“CD”指的是持续交付和/或持续部署，这些相关概念有时会交叉使用。两者都事关管道后续阶段的自动化，但它们有时也会单独使用，用于说明自动化程度。 持续 交付 通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库（如 GitHub 或容器注册表），然后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，持续交付的目的就是确保尽可能减少部署新代码时所需的工作量。 持续 部署

测试方法的划分 一般的，从看不看代码来划分黑、白盒测试。看代码和内部接口称为白盒测试，否则是黑盒测试方法。 而从软件是否运行的角度来划分静态和动态测试。不运行代码是静态测试，反之就是动态测试。 那么从我们人来参与的角度来看人工测试和自动化测试的。 黑、白、灰盒测试 刚才说了，我们从看不看代码来划分黑、白盒测试。 那黑盒测试可以有静态测试和动态测试，也可以有人工测试和自动化测试。 当然，白盒测试也是一样的。 比如我们要测这个自动售货机。 我们投币然后得到饮料；或者刷卡、扫码等都能得到想要的饮料。 我们做黑盒测试就是测试投币相关的逻辑、选择饮料相关的逻辑，找零或其他的逻辑。 这是我们不管内部结构，只是根据一些数据测试输入输出，比如投币5毛钱，却能得到一瓶2.5的饮料，这就是bug了。 等等等..... 除此之外，我们还需要看内部代码的逻辑，比如如何处理银行和第三方支付的接口逻辑，本地的饮料存储、统计等，看看相关关联的数据之间的交互。这些都是白盒测试范畴。 在测试之前，我们要搞清楚被测对象应该是什么样的，然后实际做出来的和预期进行比较，这样就能及时的发现缺陷；根据被测对象不同，而采用不同的测试方法。 白盒测试 白盒测试是依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况。 白盒测试是基于程序结构的逻辑驱动测试。

自动化测试，作为软件测试的一种提高工作效率的方式，是一种由机器代替人工执行测试行为的过程。由于接触自动化测试也有一段时间了，就想从整体上来谈一谈自动化测试的学习心得： 自动化测试与功能测试 自动化测试从根本上并没有脱离功能测试而存在，它依托于功能测试的基础实现。 从自动化的产生原因看，既然自动化测试是为了提高执行效率，由机器去替代人力执行测试用例，那么对于自动化测试用例是从功能测试的测试用例中挑选具备自动化条件，可以进行自动化的用例，将其以代码的形式固定下来并定时执行代码也变得理所当然。 从使用场景来看，自动化测试的实行通常是在功能测试模块相对稳定、改动频率较小时才进行的，且引入自动化测试的项目周期都比较长，若是在只有一两个月的项目中使用自动化，最终只会浪费人力、时间和精力，其效果还不如纯手工来得明显。同样的，对于变动非常频繁（如：UI自动化的页面样式、接口自动化的接口参数及地址）的项目而言，使用自动化的的和成本也会是极高的，而当实施自动化的投入产出比过高，那么自动化测试不仅没有意义，反而会给项目的实施带来负担。 自动化测试的优势 1.方便进行回归测试,当软件的版本发布比较频繁的时候,自动化的效果很明显。 2.自动处理原本烦琐、重复的任务，提高测试的准确性和测试人员的积极性。 3.具有复用性和一致性，可以在不同的版本上重复运行，保障测试内容的一致性。 自动化测试的分类

作为被冠以敏捷名称的测试，敏捷测试同样以快为目标。在敏捷测试中，快有三个方面的含义： 团队能够通过测试快速获知系统当前所处的状态，了解距离可工作的软件还有多远； 能够在一个迭代周期中快速完成回归测试和对新功能的测试； 开发工程师能够从持续的测试中得到快速的关于提交代码反馈。 　　简而言之，敏捷测试要求测试能够测试在短的时间间隔内持续发生且能够在短时间内完成。考虑到纯粹的依赖人工测试基本不可能达到短的时间间隔内持续发生和短时间内完成这两个目标，而自动化测试在执行效率方面具有天然的优势，在敏捷测试中使用自动化测试技术应该是自然而然的选择。 　　考察敏捷开发中的一个迭代周期： 在迭代周期开始的时候，团队与客户一起定义本迭代周期内需要完成的功能； 团队建立验收测试验证标准； 开发工程师开始实现新功能，使用TDD为产品建立安全网，使用持续集成尽可能保证每一次代码提交不引入新的缺陷； 所有新功能被添加后，在RC上运行回归测试保证原有功能的正确性；针对新功能运行测试保证新功能的正确性； 执行验收测试验证系统是否达到可交付的标准。 　　除1和2外，剩下的3个项目都与测试执行密切相关，如果依靠手工测试来进行这些项目，毫无疑问，测试会成为整个敏捷开发的瓶颈。而如果把这些项目中的测试建立在合适的自动化测试基础上的话，测试就可以和开发一起敏捷起来。从这个角度来说，把自动化测试描述成敏捷测试的基石毫不夸张。