🎉 🎂 🍰 TesterHome 创立 6 周年纪念日 🍰 🎂 🎉

  • 步履不停 at 2018年10月16日

    总感觉专栏的node title还是要和topic的分类有区分,比如前面加一个 "栏" 的badge;另外有几个微调的dom地方,直接PR还是?

  • 这比较蛋疼 compile (":xxx") 实际build时候流程和gradle层面复杂度太高,真 组件化应该是真的git repo分离,每个子项目有自己的中间产物(jar/aar),自己的unittest,在自己的unittest里面有接入jacoco,有基本的library级别的覆盖率数据,然后在apk层面,总的包含所有aar/jar,然后保证jacoco agent不重复冲突,exclude掉一些类,有一个整app级别的测试用力的覆盖率数据

  • 以场景(业务)为第一指导,设定几个通用指标,比如恒温说的启动场景,这个是一个重要的场景;此外就是一些最主要的流程,商城app就是购买,工具app就是主要几个功能;场景有了,去找重要的指标,也就那么几个;最后再来考虑万一环境不单纯性能会有什么影响(这个一般也不太会做到这么深),启动上你可以用Appetizer;指标上,启动时间已经测了,cpu利用率和耗电挂钩,分每个细分阶段里面的UI卡顿,HTTP请求,还有主线程上面忙等等给开发比较具体的优化点

  • 能有专人管理的完整的rancher/k8s那当然好啦

  • VM早就过时,体积大,启动慢,内存耗费大,数据抠不出来

  • 操作步骤yml还好 无非做好默认搜索方式然后多次猜测来简化用户表达 不过验证逻辑yml就蛋疼了
    想到还有用excel写步骤的 其实和yml差不多
    这种case描述最好大家能协作模块化 这对无论什么ui自动化工具都是类似的 是前端 比如u2和appcrawler统一一个格式
    验证要考虑考虑 嵌入yml就意味着咬死一个语言了 可能无法跨工具通用

    appcrawler总算要有新版本了
    @seveniruby u2包了一个jsonrpc的东西 那个本来也是java写的 应该可以直接调

  • docker方案已经在路上

  • 主要问题是aar好像不太能插桩,因为jacoco是在 javac的时候,用asm.jar插桩的,一种方法是exclude掉aar的代码,这样统计主干,然后aar自己测自己

  • 是的,从无到有是必要的,因为 没覆盖的分支 == 该分支上的任何错误肯定都测不到,注意错误不限于Exception,要确保大回归有比较高的覆盖率;但是只看覆盖是不够的,覆盖只是基本款