自动化测试

原文首发于 flow.ci Blog >> 链接 ，转载请联系:) CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享，包括国内外持续集成、持续交付，持续部署、自动化测试、 devops 等实践教程、工具与资源，以及一些工程师文化相关的程序员 Tips 。同步于 flow.ci Blog、微信公众号、 官方微博 ， 知乎专栏 ， 简书 ，欢迎关注或投稿:) 说到创业团队的项目研发和管理实践，有很多很有价值的『经验之谈』。本期收集了一些团队的持续集成、部署、自动化测试相关的工具与实践分享，来看看吧~ 『 持续集成相关实践 』 聊聊创业团队的项目管理如何面向开发人员优化 这篇文章涉及开发环境搭建，代码管理，需求生命周期管理，项目进度管理，研发阶段的产品测试和反馈，持续集成和持续发布等等，分享了其中的一些管理经验和工具分享，非常实用！（ via : @wangchao0721 ） 浅谈GRAB的持续集成和持续部署 作者zhchang在gopher china 2016大会上面做了个关于 GRAB 的持续集成和持续部署(CI/CD)的分享。（via: zhchang ） Continuous Integration & Deployment for iOS Projects 关于 iOS 项目的持续集成与管理，中文翻译版见 这里 .（via: Twitter[

2016年苹果发布会如期而至，新一代的 iPhone 7， Apple Watch 同时亮相，可惜大家期待的 MacBookPro、AR、VR产品并未出现。不论大家对新产品是“买买买”还是“黑黑黑”，苹果是否保有创新活力，每个人心里都有自己的答案。 本期 fir.im Weekly 推荐下 @袁峥Seemygo 的这一系列文章，教你 如何快速的开发一个完整的iOS直播app 的实践系列，还有 @陈利人 的 如何搭建一个属于自己的直播平台 ，其中解释了直播平台后面的技术和实现原理，分享给有需求的同学。 除此之外，还有一些微博热转 Github 项目、iOS/Android 开发实践等技术分享～ 打造心目中理想的自动化测试框架（AppiumBooster） 由 DebugTalk 分享。 "AppiumBooster基于 Appium 实现，更简单和易于使用；测试人员不用接触任何代码，就可以直接采用简洁优雅的方式来编写和维护自动化测试用例。" 对于 自动化测试用例有疑惑的，请点击 这里 看看作者的解决方案。 CI Weekly #1｜带你了解 CI/CD 、DevOps、自动化测试 CI Weekly 围绕『 软件工程效率提升』 进行技术内容分享,收录了关于 iOS/Android 的自动化测试，持续集成、部署等技术干货，感兴趣的可以关注订阅。 传送门 . Android-Dev

自动化测试调试 对于重复性的工作，使用自动化工具可以有效提升效率。但是自动化测试也会因为开发人员对页面的改动而经常需要去修改里面的代码。 页面更新调试 前几天就发现有一个地方没有通过，因为同事改了页面的代码，想起以前调试的过程，心里还是有点不耐烦，但是为了工作，这个还是得做。 因为前面调试时，有些logging写得不明不白的，这次先是加上调试代码，一步一步写logging，最后找到了原因之所在。 仔细分析了一下代码，发现现在方法更简单，原来写的三步if... else,这下全部不需要了，只用一个取值就可以搞定。 刚开始还对这个要调试的地方特别地紧张，一直拖了好久才去做的。真正静下心来做，发现其实也蛮容易的。 调试心得 我使用Sublime Text配置了SublimeREPL插件，按F5就可以启动。在调试过程中，有几点心得，在此分享，希望能对你有用。 我使用了大量的logging来调试。 在进入函数前使用logging 打印当前进入了哪个函数的消息；退出函数前，打印退出消息 经常使用logging来打印里面的取得的或是将要传入的参数值，同时一定要写清楚这是哪个参数的调试结果，光打印一个值，最后自己都看不明白，是哪个一值，可以写一句话，把这个值当成参数跟着句子同时打印出来。 鉴于本人有些函数不是特别熟的情况，本人经常是将部分代码，重新复制了，放在一个新的文件里面，调试其中的逻辑。

传统java项目开发都会利用maven、ant在hudson、jenkins中持续集成，开发、测试、每日构建，保证代码质量。maven默认不支持android，但是我们可以利用 maven-android-plugin 插件来让maven支持android。 环境 jdk 1.6及以上 Android sdk(r21及以上),最好是最高版本，最好也安装一下ndk Maven 3.0.3及以上，貌似3.1.0不好使，最好使用3.0.5版 设置ANDROID_HOME环境变量，将$ANDROID_HOME/tools、$ANDROID_HOME/platform-tools加入到环境变量中 测试环境 下载示例程序，通过跑这些程序，可以检测环境是否OK，并且下载maven需要的jar包。 示例程序 使用Maven进行Android开发 新建Maven Android项目 具体命令参考 此处 手动创建Maven Android项目 有些是历史项目，也可以手动将其改成maven项目，方法如下： 新建pom.xml文件，拷贝其他maven项目的也可。 修改<groupId>,<artifactId>,<name> 修改<version>,默认是 <version>0.1.0-SNAPSHOT</version> 增加android jar包依赖： <dependency> <groupId

CI：持续集成（CONTINUOUS INTEGRATION） 基本概念 CI的全称是Continuous Integration，表示持续集成。 在CI环境中，开发人员将会频繁地向主干提交代码。这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证。 持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。 需要具备的条件 团队需要为每个新功能、代码改进、或者问题修复创建自动化测试用例。 你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。 研发团队需要尽可能快的提交代码，至少每天一次提交。 带来的效益 通过自动化测试可以提早拿到回归测试的结果，避免将一些问题提交到交付生产中。 发布编译将会更加容易，因为合并之初已经将所有问题都规避了。 减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。 测试成本大幅降低，你的CI服务器可以在几秒钟之内运行上百条测试。 你的QA团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量文化的提升上面。 CD：持续部署（CONTINUOUS DEPLOYMENT） 基本概念 CD的全称是Continuous Deployment，表示持续部署。 在CD环境中，通过自动化的构建、测试和部署循环来快速交付高质量的产品

CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享，包括国内外持续集成、持续交付，持续部署、自动化测试、 DevOps 等实践教程、工具与资源，以及一些工程师文化相关的程序员 Tips 。同步于 flow.ci Blog、微信公众号、 官方微博 ， 知乎专栏 ， 简书 ，欢迎关注或投稿:) 嗨，上周我们对 iOS/Android 项目持续集成做了比较多的功能优化，同时恢复了对 GitLab 的支持，修复了一些常见问题，详情见 flow_ci changelog ，如有问题可通过「在线消息」或去 Gitter群 及时反馈 :) 下面递上一份新鲜的 CI Weekly，这期收录了关于Docker/CI/CD实践、自动化测试、DevOps相关的国内外技术文章，希望对你有用~ 『 Docker/CI/CD实践 』 Docker容器化应用持续交付实践 本文百度质量部以 网盟合一（零号DSP）项目过程中建立起来的通用容器化交付系统 EMC 为案例，分享了基于Docker的容器化应用持续交付实践经验。（via: 百度质量部 ） 项目DevOps研发云CI实践之路 笔者所在项目在敏捷推进过程中，已经建立了一套以Jenkins为核心的CI持续集成系统，并分享了相关的实践情况经验。（via :中兴开发者社区） 部署流水线搭建小记：Docker、Jenkins

CI Weekly 围绕『 软件工程效率提升』 进行一系列技术内容分享，包括国内外持续集成、持续交付，持续部署、自动化测试、 DevOps 等实践教程、工具与资源，以及一些工程师文化相关的程序员 Tips 。同步于 flow.ci Blog、微信公众号、 官方微博 ， 知乎专栏 ， 简书 ，欢迎关注或投稿:) 转眼一周过去了，flow.ci 的 iOS 项目持续集成正在内测邀请中，也有热情的用户写了一篇 flow.ci 初体验！记一次暖心的 iOS 持续集成 ，以供参考！ 除此之外，看看 flow.ci 上周的产品更新～ 修复编译任务编号问题； 修复 Ruby 项目 Test 插件 gem 升级引入的问题； 提高 GitHub 代码拉取、Pod 安装更新时的稳定性； 优化项目名称对特殊字符的兼容性. 详细的更新日志见 这里 ，欢迎来 flow.ci官方Gitter群 提出反馈 :) 本期 CI Weekly 整理了不同规模的团队进行持续集成的实践经验、自动化测试、工程师文化等相关的技术分享，一起来看看~ 『 持续集成/持续部署相关实践 』 初创公司应该如何做好持续集成和部署？ "最近一段时间一直在梳理项目开发流程以及自动化测试和部署规范，作为一个总结和大家分享，希望有所帮助。"(via : @高效运维 裴双才) 超大型系统的持续集成与持续交付解决方案与阿里宙斯盾

　　自动化测试其实是吧一个个测试点通过结构化设计串联起来，然后通过第三方模块也好，内置的模块也好，解决每一个测试点遇到的问题，以完成一个完整的自动化测试脚本。下面就完成一个自动化测试脚本。 　　............省略一万个字 　　完成了各个功能（各个模块代码省略）处理的函数，最后将其拼接起来，就可以组成一个完整的自动化测试，完整代码如下： import requests import hashlib from datetime import * import json username = '19999999999' password = hashlib.md5(b"123456").hexdigest() url = 'http://www.xxx.com/ajax/user_login/' form_data = {"uernsme":username,"password":password} login_response = requests.post(url,data = form_data) assert login_response.text == "success" c = login_response def make_oeder(): global c url = 'http://www.xxx.com/ajax/create_order/' form

在互联网的产品开发时代，产品迭代越来越频繁，“从功能开发完成直到成功部署”这一阶段被称为软件开发“最后一公里”。很多开发团队也越来越认识到，自动化测试和持续部署可帮助开发团队提高迭代效率和质量。 那么，如何更好地解决“最后一公里”这一问题呢? 一切从自动化测试开始，让自动化测试贯穿在整个项目开发-集成-部署-交付的-开发流程中。 如果你的团队还没有开始自动化测试，推荐从经典的测试金字塔开始。 自动化测试 在这个分层自动化测试金字塔中，Unit 代表单元测试，Service 代表服务集成测试，UI 代表页面级的功能测试。不同的产品层次都需要自动化测试，投入的精力和工作量会有所不同。下面我们仔细看下每个层次的测试： 1.1 Unit 单元测试 “凡是不能量化的工作都是不可考量的” 目前很多公司已经意识到了单元测试的重要性，但国内坚持写单元测试的团队并不多，其中一个难点在于没有考量，没有很好地执行单元测试覆盖率检测。 想想，如果没有单元测试覆盖率检测，单纯的只写单元测试，时间长了也许开发人员会产生惰性，比如：今天任务太紧了，就不写单元测试了，以后再补，反正写不写也没有人知道。引入单元测试覆盖率检测之后，开发人员会更主动地写单元测试，就算补写单元测试也更有成就感。单元测试覆盖率检测有现成的第三方工具，比如 code climate 、 Coveralls 等等

经常会听到持续集成，持续交付，持续部署，三者究竟是什么，有何联系和区别呢？ 假如把开发工作流程分为以下几个阶段： 编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署 正如你在上图中看到，「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」有着不同的软件自动化交付周期。 持续集成 持续集成是指软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程（XP），是 XP 最初的 12 种实践之一。 CI 需要具备这些： 全面的自动化测试 。这是实践持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要； 灵活的基础设施 。容器，虚拟机的存在让开发人员和 QA 人员不必再大费周折； 版本控制工具 。如 Git，CVS，SVN 等； 自动化的构建和软件发布流程的工具 ，如 Jenkins， flow.ci ； 反馈机制 。如构建/测试的失败，可以快速地反馈到相关负责人，以尽快解决达到一个更稳定的版本。 持续集成的优点 “快速失败”，在对产品没有风险的情况下进行测试，并快速响应； 最大限度地减少风险，降低修复错误代码的成本； 将重复性的手工流程自动化，让工程师更加专注于代码； 保持频繁部署