留一下你们的联系方式吧

#163 楼 @huangke 新版本我打包了一个 jar 文件. 只要安装了 java 就可以了. 报错也是 java 的版本不对应而已. 解决了就可以了

#161 楼 @jusnic 已经解决了, 新版本正在朋友圈内测 .还没发出来.

用 adb 是可以读取短信的. 直接调用 adb 读取短信就行了吧. 用不着大费周章. 或者自己简单写个读短信的脚本或者 app 都行.

写的不错. 好久没写 一上来就要惊艳下啊.
你们的工具原理是什么 是基于 findbugs 封装? 是如何分析语法树抽取规则的?

#30 楼 @skytraveler 能进化的都是好同学.

#25 楼 @monkey 早些年的确出现了因为测试部管理层是业务测试出身而导致对测试开发工程师不重视的情况.

因为重业务测试必然会带来大 QA 的局面, QA 本身对质量提升的作用会随着队伍的增加衰减, 而人员队伍成本和项目的工期却在递增.
这自然是导致了公司管理层的不满意. 后来出现几波行业变革才扭转了局面.
第一个是创业浪潮. 这带来的思潮是速度与质量的平衡, 快速迭代和快速反馈.
第二个推进作用是中大型公司对 QA 或者测试队伍的调整. 算是对国外公司的跟随.
第三个浪潮是移动互联网, 导致了传统型的业务测试人员要面临转变和跳槽.
第四个是敏捷. 敏捷迎合了创业浪潮, 得以大放异彩. 他侧面辅导了创业浪潮的崛起. 敏捷的方法论也是倡导快速迭代, 弱流程重沟通, 这必然也冲击了大 QA 模式.

大环境最后注定了大 QA 模式的瓦解. 但是业务测试的地位和作用仍然还是有的. 基本只会停留跟用户有交互的产品部分. 传统的后端测试工程师已经逐渐式微甚至是消失. 会逐渐只剩下少数业务模式比较重的行业比如金融, 电商等.
问题是当 QA 或者业务测试的总量下降到一定 level 后, 就会快速的坍塌. 当有一天人们不再像提研发和产品那样提测试的时候. 业务测试的未来就没有了.
当然这个过程可能并不快.

小产品的测试体系可以参考微博 id 纯银发布的产品测试经验. http://www.jianshu.com/p/9f3041818702?utm_campaign=maleskine&utm_content=note&utm_medium=writer_share&utm_source=weibo

行业的发展要求 QA 满足如下的需求

1. 速度
2. 质量

这必然会导致了新兴的服务模式模式 比如灰度测试, AB 测试. 众测, 云测, 质量监控, APM 数据分析等. 未来还会很精彩.
不过我相信, 质量保证行业只有自身能迎合时代的发展, 就自然会再度崛起. 这就是一个适者生存的环境.

#23 楼 @monkey 业务测试的 KPI 主要是挖掘 Bug 测试活动工作量和收集分析产品问题.

因为技术受限, 他们大多无法认识到问题的深层根源, 但是用基础工具是可以的, 这个时候要考借助于其他团队打造的工具或者开源的方案来做事.

以前他们的工作是没法量化的. 现在借助于一些监控可以统计这部分的大概工作量和测试能力. 所以就会变的可量化可管理了.
技术受限会导致与研发团队的沟通会有障碍, 也无法快速的应用新的解决方案.
这波人只有一条路, 就是管理. 不然就会被新人逐渐代替. 靠改造他们已经不现实. 只能招聘优秀新人.
他们自身也面临着质量压力, 因为人力的限制, 他们无法做到更深入的问题发现. 以及更广的测试范围. 同时又面临新解决方案和众测, 灰度, AB 测试以及全员内测等各种新思潮模式的制约. 发展已经是困难重重了.
从管理层面来说, 整个大行业都在逐步的精简业务测试. 大的质量部门也逐渐被取消, 从管理层面也已经没有了上升空间了.
这几年业务也在快速的变化, 而且 BAT 已经都开始面试开发能力了. 这类人也几乎已经到了无法跳槽的地步.
未来会很凶险.

业务测试是根基

产品测试的需求跟人的需求一样, 也是分层次的.
业务测试肯定是第一位的. 是产品基础. 围绕业务会有很多的衍生需求, 比如性能 安全 稳定性 兼容. 但是首要的还是业务功能.

与其他需求一样 业务功能也是存在可被模型化和技术化的. 产品的衍生需求大多都已经是实现了现代化的检测. 而唯独业务正确性未实现. 这是有很大的历史原因在里面. 我觉得限制主要来自于两个方面.
第一个是业务的正确性无法被很精细化的模型化. 这种复杂性就算是 alphago 也搞不定, 而且每个领域的模型还不尽相同.
第二个是做业务测试的人大多没技术属性. 导致业务测试的技术发展不足.

业务的建模

业务的本质是个处理流程, 你可以认为是一个巨复杂的函数. 从数学上讲是一个输入到输出的映射

class 业务{
  public 业务模型类  def 业务流程(业务输入数据){
    处理业务
    return 业务输出数据状态
  }
}

复杂度体现在两个层面.

• 业务的数据模型复杂. 典型的业务比如民航订票 股票基金交易 航天飞机. 里面的物件和物件属性很多.
• 业务的流程模型复杂. 典型的业务比如搜索引擎 机器学习算法

人脑也是一种计算. 大多数业务正确性, 人能够验证正确性是基于历史数据过多而逐渐学习出来的.
以前有人提一万小时的领域专家成长的时间理论 其实就是基于数据不断的学习进化的过程. 说明人脑的计算速度就是这个瓶颈了.
这个过程同样也适用于计算机. 前几年 Google 通过机器学习 + 数据训练也让内部的一个服务器集群成功识别出了它以前没见过的新事物. 参考猫脸识别 http://36kr.com/p/122132.html

很明显高大上的技术在十年内还是难以普及的, 不过有些简单的科学方法还是可以利用起来来改进业务测试的.

业务测试的技术化改进

业务的流程和数据模型肯定是存在的 他存在于产品的脑子里, 形成于研发的代码, 并应用于用户身上. 所以三个维度都能做到对业务的建模并识别正确性.

第一个维度是产品层面的业务建模, 这就是过去几十年我们测试行业采用的办法. 根据产品文档写用例 根据研发代码流程补充细节用例, 根据用户投诉和线上故障来补充用例. 这个几十年没变过.

第二个维度是研发的代码. 如果你把代码的演变和执行流程都统计下, 你会发现任何程序都是一种生命体. 他可以进化, 业有瑕疵. 甚至是崩溃. 对代码的建模行业里面也有人在做了. 做法是如下的几种

• 静态分析
• Code Review
• 单测

这几个层面主要是想在底层做一些基础的质量保证, 并尝试把复杂的模型分拆验证. 但是他无法很好的做到全局正确性的校验.

第三个维度是线上产品监控, 使用的技术主要是

• 代码埋点
• 字节码插桩
• 特定语言的 debug trace 和 hook 技术

典型的应用场景比如 Bugly 崩溃分析 Flurry GrowingIO 业务流程分析 友盟的运营监控. NewRelic 听云 OneAPM 性能分析产品兼具部分的业务分析.
这个层面的产品和发展非常的迅猛, 因为他迎合了业务分析 + 大数据 + 云计算多个东风. 导致已经非常成熟的应用起来了. 但是还不能完全做到质量正确性验证. 比如因为某个 bug. 用户的资产算错了. 这个这些系统都检测不出来.

第四个维度是数据建模分析, 可用的技术方案是

• 数据采集. 包括建模的各种属性
• 规则分析. 根据业务模型指定简单的规则去扫描问题
• 机器学习. 不借助于任何规则. 通过训练数据学习出哪些是 bug 和正确的功能.

实用的业务测试策略

根据产品完善测试用例仍然是第一位的. 所以你需要有一些扎实的业务测试同学.
因为业务的策略大部分都埋藏于代码中, 很多雷也埋在其中. 纯靠粗略的产品需求你很难覆盖到足够多的场景. 所以你需要用 code review 或者其他的工具作为弥补. 来挖掘代码中的业务实现.
埋点与字节码插桩. 这个技术已经是非常的成熟了. 了解用户的业务场景并完善你的用例是非常有用的. 而且还能做到精简你的测试用例

#37 楼 @jiazurongyu 会让埃隆马斯克的 spacex 邮寄的

#35 楼 @wkx101 理想还是要有的, 万一实现了那...

微信应该是有自身 hash 值检验 你得 hook 掉才行

—— 来自 TesterHome 官方 安卓客户端

移动端的 apm 监控产品有开源的吗

#11 楼 @quqing 特意在 23:50 发的

#154 楼 @darren_dp 不需要, 直接生成思维导图

#152 楼 @sundaxian first last 机制来控制顺序 没在 elementActions 定义的按钮被点击, 估计是被自动遍历到了吧. 或者 id 和 name 相同

#148 楼 @riusksk times 决定了规则被应用几次. 改成 0 表示没有限制. 你可以试试.

#104 楼 @zhangtao ELK 技术栈就足够了

脚本功底不错. 我们公司目前用的是 docker. 根据代码的 commit 直接部署环境. 测试团队没维护环境的负担了.

#3 楼 @hyddd instruments 是个好东西, mac 有个 dtrace 工具很强大. 不知道 iOS 里面能不能搞.

#1 楼 @hyddd 好久没见到这个 id 了...