自动化测试

一.什么是CI,CD ​ 当我们在谈论现代的软件编译和发布流程的时候，经常会听到CI 和CD这样的缩写短语。CI很容易理解，就是持续集成。 ​ 但是CD既可以指代码持续交付，也可理解为代码持续部署。CI和CD之间有很多相似的部分，但是也有很大的区别。 它们之间的区别和联系。 1. 持续集成（CONTINUOUS INTEGRATION） 在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。 这样做是基于之前持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。 2. 持续交付（CONTINUOUS DELIVERY） 持续交付就是讲我们的应用发布出去的过程 。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。通过持续交付， 您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。 但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。 3. 持续部署（CONTINUOUS DEPLOYMENT） 如果我们想更加深入一步的话，就是持续部署了。通过这个方式

转载本文需注明出处：微信公众号EAWorld，违者必究。 引言： 随着敏捷软件研发过程的引入，敏捷测试也开始成为研发团队的重点关注对象。在行业内，有些企业正在做敏捷测试的尝试，有些也取得了不错的效果。 随着普元研发管理体系（iPALM）的不断演进，敏捷的开发过程加速了产品的市场响应。在普元DevOps平台的助力下，开始把质量构建进产品而不是在生产出来之后再进行测试。在软件产品部整体团队的群策群力下，敏捷的软件测试模式在研发过程中运行非常成功，测试团队也积累了一些宝贵的经验，很高兴有机会拿出来与大家一起分享。 目录： 1.对敏捷软件测试的理解 2.敏捷软件测试的核心价值 3.敏捷软件测试的经验分享 4.总结 1.对敏捷软件测试的理解 敏捷测试的定义 Wikipedia对敏捷测试的定义： Agile testing is a software testing practice that follows the principles of agile software development.1 译文：敏捷测试是一种遵循敏捷软件开发原则的软件测试实践。 这是通过一种敏捷的做事方法，可以让团队协作更紧密、工作效率更高，确保以可持续的速度频繁地交付客户所期望的业务价值。 敏捷测试与传统测试的区别 传统模式是把软件开发分为软件需求、软件开发（设计&编码）、软件测试、软件发布等阶段

人类只需创造，计算机可以做剩下的工 作 近年来，随着世界变得更加多样化，我们需要利用自动化测试来处理日益复杂的应用程序开发工作。测试工具的有效性是毫无疑问的，但是如果您刚刚起步，会面临一个选择：付费的，还是开源的？ 如果您的测试已经自动化，可能还会遇上一些其它的问题。如：在自动化测试框架和脚本这些技术上的支出比它们所创造的价值更多；又或者是你想提升自动化测试的处理速度。自动化测试的覆盖范围和职责是什么？团队负责的任务是什么？最重要的问题是：如何整合自动化测试到软件开发周期中来提升质量和效率？ 与信必优合作，我们的自动化测试解决方案会帮助您获得最大的价值。 我们的特 点 我们对您需要的工具有深刻的认识，能帮您挑选哪种才是最适合您的。在此之上，我们开发了一整套工具并对开源框架进行扩展，它们提供了更完整和更特色的体验，可以更快速地实现市场价值。 我们提供灵活的交互模式来满足您的需求。如果您需要咨询，一个专注的团队或者团队支持，我们会针对您的需求提供解决方案。 为客户带来的价值 减少手工化的工作 更专注于总体测试 提升测试覆盖率 加快软件系统的发布流程 我们的自动化测试方 法 我们采用敏捷测试金字塔作为我们敏捷测试策略的基础。它展示了各个测试层次所需要的工作量。传统来说，大多数工作都集中在GUI这个层面上。在GUI这层上，测试要非常小心，而且维护起来是很昂贵的。在这种模式下

6月30 日，苹果开发者后台贴出一封关于广电总局的醒目通知，申报一个游戏 APP 上架AppStore，你需要文网文+ICP证+软著+版号，审批难度将越来越大，不禁让人感慨中国独立开发者的成长 “ 道阻且长 ”，更多可了解 相关知乎问题 . 谈及独立开发者，除了生存问题引人关注外，他们可能多数是优秀的远程开发先行者。如果你也向往一份 Remote 开发工作，推荐 一早一晚 远程开发社区和 @greatghoul 整理的 Github 远程工作资料库 remote-working . 除此之外，本期 fir.im Weekly 推荐 teahour.fm 的 最新一期节目 ，邀请了 Ashchan 聊了远程工作的方方面面，包括如何从头开始，如何接项目，如何找客户等如果要做远程工作必须要面对的问题等等～ 再来看下其他干货内容 ～ 『 iOS，Android， 前端开发干货分享』 iOS进阶指南试读之UI篇 由 @叶孤城___ 大神分享； “UI是一个iOS开发工程师的基本功。UI本质上就是你调用苹果提供给你的API来完成设计师的设计。所以，想提升UI的功力也很简单，没事就看看UIKit里的各个类的头文件。如果能做到烂熟于胸，相信会有很大的提升。”文章 传送门 . 25 位国内外优秀的 Swift 开发者推荐 @SwiftLanguage 有心整理了二十五位优秀的 Swift

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

作者: 殷坤 来源: InfoQ 　　在本系列的第一篇文章“我们的测试为什么不够敏捷”中，根据实例总结出敏捷自动化的两大阻碍：“脚本维护困难”、“断言条件繁琐”。本文针对如何降低脚本维护难度分享一些实践经验。 　　近几年，Web技术发展势头迅猛，浏览器市场群雄争霸、各种UI组件库也如雨后春笋。现在互联网上已经很少有仅支持一种浏览器，并且不基于任何可复用的UI组件库进行开发的应用了。开发人员基于各种优秀的UI组件库（如， JQuery 、 Dojo 、 ExtJS ）可以很容易的开发出功能强大、展现绚丽、兼容各种浏览器的页面（如下图）： 　　UI组件库的广泛采用在提高开发效率的同时，也极大的提升了用户体验。基于UI组件库之所以能快速开发出功能强大的页面，是因为UI组件库可以自动生成海量、结构类似的HTML源码（如下图）： 　　开发人员是幸福的，因为这一切对于他来说完全透明。于是只剩下自动化测试人员独自面对这样“恐怖”的页面源码。 　　如前文“我们的测试为什么不够敏捷”中所言，业界常见测试工具的脚本本质上还是针对页面源码的，因此原本就举步维艰的自动化测试在开发使用UI组件库之后变得雪上加霜： 页面DOM结构非常复杂 　　导致所录制/编写脚本的复杂度变的更大、可读性变得更差。 UI框架的升级很可能会导致DOM结构的变化 　　因此即使开发人员没对代码做任何改动

作者: 殷坤 来源: InfoQ 　测试是为了保证软件的质量，敏捷测试关键是保证可以持续、及时的对软件质量情况进行全面的反馈。由于在敏捷开发过程中每个迭代都会增加功能、修复缺陷或重构代码，所以在完成当前迭代新增特性测试工作的同时，还要通过回归测试来保证历史功能不受影响。为此我们期望： 　　测试范围足够广： 测试用例要覆盖所有功能； 要在各种可能的环境下作兼容性测试； 系统的稳定性、性能都要测试； 　　测试频率足够高： 每日构建产生的版本要保证可用； 每个迭代都需要对历史功能做回归测试； 释放前或上线后如果打了补丁，就需要回归； 　　但实际情况往往不遂人愿： 　　实际测试周期变短： 上线时间提前确定，研发进度延期，测试计划被迫延后； 最后阶段经常会临时增加测试任务； 所有人都知道还需要再经过一轮测试，但时间没有了； 　　有效测试资源稀缺： 临时从其他项目抽调的测试人员不能立刻有效的开展测试工作； “搞不清楚”本项目的研发人员到底是不会做测试还是不愿做测试； 　　因此由于客观上的资源和时间限制，完整的、及时回归测试在人工测试情况下，往往是不可能完成的任务。团队内部也会产生各种争执： 提交给测试的版本为什么研发人员不先做通过性测试？ 这次代码改动量不大，有必要再花那么多时间回归么？ 当初不是承诺这次修改肯定不会影响以前的功能么？ 怎么不早说要支持Chrome浏览器，现在哪还有时间测试啊？

　　 先来看看功能测试如何进行的：编写测试用例，测试用例当中最主要的是测试步骤和预期结果；测试人员根据测试用例执行操作步骤，然后通过眼睛和思考判断实际结果与预期结果是否相等。如果相等，测试通过；如果不相等，测试失败。 　　自动化测试要做的事情与功能测试是一致。这里的自动化主要包含三个层面的自动化，单元测试自动化，接口测试自动化和web测试自动化。当然，不同层面的自动化关注点是不一样的。 　　单元测试自动化，调用被测试的类或方法，根据类或方法的参数，传入相应的数据。然后，得到一个返回结果。最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。所以，这里单元测试关注的是代码的实现与逻辑。元测试是测试中的最基本的测试， 也是测试中的最小单元， 它的对象是函数对象，也可以包含输入输出， 针对的是函数功能或者函数的内部逻辑方面。 并不包含业务逻辑。 　　接口测试自动化，根据接口文档，到底是传get请求呢？还是post请呢？调用被测试的接口，构造相应的数据（id=1,name=zhangsan），得到返回值，是200成功，并返回查询结果。还是10021，用户名不能为空。不管输入的参数是怎样的，我们都将得到一个结果。最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。所以，接口测试关注的是数据。只要数据正确了，功能就做成大半

题记：本文简述如何利用appium对Windows桌面应用程序进行UI自动化测试。 所谓UI自动化测试，就是模拟一个用户，对应用程序的UI进行操作，以完成特定场景的功能性集成测试。 要对Windows桌面应用程序进行UI自动化测试，目前可选的技术主要是两种：VS自带的CodedUI Test和Appium+WinAppDriver。但是，微软已经宣布VS2019将是带有CodedUI Test的最后一个版本，且在面对某些复杂场景的时候有点力不从心。而Appium作为移动应用主流的UI测试工具，已经被业界广泛采用，且相关的接口是标准化的，因此微软对其进行了扩展（即 WinAppDriver ），让Appium可以支持包括Universal Windows Platform (UWP), Windows Forms (WinForms), Windows Presentation Foundation (WPF), and Classic Windows (Win32)之内的Windows桌面应用。所以采用Appium来作为Windows桌面应用程序UI自动化测试的工具是最佳选择。 要完成UI自动化测试的大致步骤如下（你首先需要一台Windows 10的PC）： 1，准备好待测试的Windows桌面应用程序。 2，到 https://github.com/Microsoft

一 Appium 官网：http://appium.io AppUI自动化测试 Appium 是一个移动端自动化测试开源工具，支持iOS 和Android 平台，支持Python、Java 等语言，即同一套Java 或Python 脚本可以同时运行在iOS 和Android平台，Appium 是一个C/S 架构，核心是一个 Web 服务器，它提供了一套 REST 的接口。当收到客户端的连接后，就会监听到命令，然后在移动设备上执行这些命令，最后将执行结果放在 HTTP 响应中返还给客户端。 二 Selenium 官网：https://www.seleniumhq.org/download/ WebUI自动化测试 Selenium是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建回归测试检验软件功能和用户需求。支持自动录制动作和自动生成 .Net、Java、Perl等不同语言的测试脚本。Selenium 是ThoughtWorks专门为Web应用程序编写的一个验收测试工具。其升级版本为Webdriver。 三