#40 楼 @cpfeng0124 新浪的对外云测?

推荐用 selendroid 模式. 另外在测试用例的初始化中要自己控制 appium. 这样更稳定.

官方太激进了, 这么快就不对老版本的 ios 做支持了. 这对做兼容性测试的人来说, 是个坑啊.

#2 楼 @monkey 今天在 testerhome 人脉群讨论的话题. 放到论坛来讨论了

#13 楼 @fiona 别讨论这个事情啊 不然我要吃不了兜着走 我原文已经删了八卦了

别搞的太有压力. 我单独开一个帖子. 把我总结的 ppt 也放上来吧. 没有你的疑问, 我也不会写这些.

#8 楼 @fiona 别直说名字. docker 他是支持的. 他希望是 docker 之上更高层的封装 vagrant. vagrant 是最合适的工具. 在 docker 不支持 windows 的时候, 只有 vagrant 支持全平台. docker 目前也只是刚刚开始支持 windows. 还没真正的用起来, 只是半个月前才发布. 我当时推的时候是在半年前, 那个时候 docker 还不成熟. 他现在已经接受了 docker 应用在测试环境了.

#7 楼 @chenhengjie123 你能听说到 ELK 已经算不错了.这几个关键词是我最近一两个月开始念叨和忽悠的

我们公司用到了 docker. 说下我的感受吧.

目前测试环境是用 docker 构建的. 除了 docker 环境外, 也同时编写了一部分的自动化控制脚本搭建. 两者并行是因为历史原因. 在组内我是推荐用 docker 的. 也受到了质疑. 说下我的感受吧.
docker 最大的特点

虚拟化.

这个虚拟机技术会为未来的运维和云中心节省很大一笔收入. 因为他没有了虚拟机 OS 这个很大的负担. 节省的资源很大. 这个肯定会被所有的云计算服务商重视.
容器技术是工作于进程. 是内核进行了资源隔离. 他的性能接近原生. 如果是单纯当成一个虚拟机软件. 那还不如 virtualbox 方便.. 他的这个性能提升对我们 QA 基本是没太大收益的. 对运维和全球的节省那可很大了. 所以几乎所有的云计算中心都在尝试或者已经使用容器技术. 未来更多可能是跟虚拟化融合.主体计算肯定会在容器中.

面向交付.

docker 基于进程. 他发布出去后用户面对的也是进程入口. 这样的交付方式革命性的变化. 举个例子. 我要安装 jira. 传统的方法是安装服务器, 安装 tomcat, 下载 jira. 配置 jira,启动 jira. 而在 docker 中. 所有过程就是一个 docker run xxx/jira 一行命令即可搞定. 其他软件也是如此. 它是面向交付的.比如复杂的 ELK, 也只是几个命令就可以搭建起来. 很多细节都被封装起来了.

环境版本化管理.

新老版本更新的时候, 对于一家公司同时维护一套环境我觉得已经很吃力了.更别提是维护两套新老版本的环境. 这在测试中是很需要的. 但是维护起来却复杂. 环境大家要抢着用. 用坏了还得修复. 新老版本重新搭建费时费力. 架构复杂等都在制约 QA. 而 docker 把持续交付变成了现实, 而且还大大的扩展了概念. 利用 docker. 同时维护起来很多套完全不同环境不同分支的环境.

压力

在推动 docker 使用的过程中 我收到了很多的压力和动力. COO 研发总监和测试经理都曾经提出过质疑, 但是后来都给予了不少支持. 得以让我有机会可以继续改进 docker 在测试中的应用. 新的技术会带来新的收益, 并同时带来新的坑. 我也在磕磕绊绊中一路路的走过来了. 不过没有这些坑. 我估计 3 个月前就分享给大家了.

收益

前面介绍的 docker 后两大优点让我们公司受益很大. 我们的研发模式是分支开发主干发布. 这就意味着同时会有很多分支在进行开发测试. 共用一套环境很容易出错. 也存在资源争抢. 就是部署多套更新维护也很费劲.我的做法如下

1. 用 docker 实现环境的自动化部署.
2. 搭建一个每日构建的环境. 基于要发布的 master 分支
3. 对同时在开发的各个分支分别根据需要构建特定分支的环境.
4. 研发和测试通过 jenkins 上的一个 job 自动构建环境. 构建的时候需要协商不同模块的分支. 然后一个定制化的环境就出来了

这样环境的管理就变的非常有趣了, 环境开始跟代码一样进入了版本化管理了时代..
主干版本的环境一直存在. 每日构建. 构建的时候对环境建立一个 tag 标记. 可以跟研发的 commit 保持一致.
其他人测试只需要在自己的机器上动态的生成新环境即可.
每个人都有自己的一套或者多套环境.
docker 可以随时决定启动某个老版本的环境进行验证. 也可以决定启动两个不同分支的环境进行对比.

我搭建了一个 docker distribution. 也就是原来的 docker registry. 公司内任何人都是随时利用 docker 命令直接同步完整的过去并启动使用

对于 docker,我也很开放. 我告诉所有人, 不管我们用不用 docker, OneAPM 的客户很多已经开始用 docker 了, 他们希望我们的监控产品可以支持 docker. 甚至在 docker 里面运行, 所以 docker 本身就是我们应该测试的一种场景.
最重要的是, 我们要观察 docker 和传统环境管理两条路的效果, 让组员去选择他们喜欢的技术体系. 经过不断的观察和验证, 我发现在使用了 docker 之后组内的人都倾向于用 docker. 至于研发, 则是强烈赞同用 docker. 研发还想上 Mesos 管理, 这次则是轮到我反对了, 我觉得目前整个公司都还刚用上 docker, 很多人还没概念, 不要走的太超前....
说话的时候我都感觉到我也快成了一种阻碍生产力发展的因素了.

现状

目前我仍然在不断的研究如何让 docker 跟持续交付, 环境版本化, 甚至是更多的测试技术融合在一起 ,比如新老版本的变更 diff, 问题自动定位. 数据库和接口 diff 测试. 以及新老版本的性能对比等. docker 仍旧不稳定.我们公司仍在验证和探索阶段.
我总体很看好 docker 的发展.

docker 的最新现状

1. docker 已经支持 windows, 微软已经发布了支持 IIS 的 docker
2. docker 已经在所有大公司里面都开始用起来了, 目前主要是运维.
3. 原来越多的产品在使用 docker 作为发布方式
4. jenkins+mesos+docker 已经成为新一代的架构选型.

思维导图转成列表放上来也行

我对 capybara 最近感兴趣起来了

很明显, 文件路径写错了. 这个帖子我删除了

不要限制大家上传图片 图片还是很有参考作用的 带宽的问题继续想办法 要让大家愉快的学习和分享

#4 楼 @smile_0303 是的. 这样有助于你将来做持续集成

可惜 base 上海, 不然我们就要了.

尽量别用这种 GUI 模式. 这不符合测试模式

#3 楼 @doctorq 上个星期我看了一遍官方的文档和部分的代码. 跟其他的朋友也讨论了好久, 鉴于你技术进步飞快,我加你到一个高阶的技术群.

赞. 我最近也在研究 jacoco 在 java 的覆盖率.这个工具真是不错. 文章写的也很赞.
jacoco 支持在测试执行过程中 dump 出结果. 手工测试完, 加入一些 dump 操作就可以获取到.

我的职位是测试架构师. 我属于研发团队.
在哪不重要, 重要是你做的事情是否被认可.就算做手工测试,如果可以经常帮助团队发现大的问题,那么仍然具备重要的地位.

我同事转研发的有, 继续做测试的也行. 最后的结果还是取决于个人能力.

#1 楼 @chenhengjie123 应该是不行的. Uiautomator 需要特殊的权限, 普通的 apk 没权限. 就算能调用 shell, 也调用不了 Uiautomator

#4 楼 @yangchengtest 从报文中提取数据 这个是最差的办法 但是适合基于文本的协议 更复杂的比如 jms socket mysql 这种协议有更好的工具 需要用到插桩技术 从 api 拦截并重新构造

#4 楼 @yangchengtest 接口测试中肯定有时间戳或者 session 相关的东西 需要加一些自定义的逻辑控制 因为规则每家公司都不同 所以需要自定义 我在文中第四点提到了