• 我给一些差异点吧,仅供参考。利弊的话,需要结合团队实际说才有意义。

    语言:RF是 python ,Jmeter 是 java + JavaScript(写 beanshell 要用到)
    编程语言能力要求(特指语法熟悉度):RF 有一些,Jmeter 基本可以没有。
    灵活度:在不做二次开发(即改动到库函数或者框架源码)前提下,RF 比 Jmeter 高一些。
    泛用性:RF 除了做接口,还可以做其它形式的自动化,例如 UI 自动化。Jmeter 除了做接口,还可以做后端性能。
    生态圈:个人感觉 RF 相对活跃一些。

  • 瞬时弹窗指的是 toast ?

  • 剪烛进平安了?

  • 如何量化测试覆盖率 at 2017年09月14日

    我理解的覆盖率有两类:白盒角度的(代码/配置项执行层面)、黑盒角度的(需求要求的覆盖、需求以外补充场景的覆盖)。一般情况下,测试覆盖率说的是后者。

    单元测试的代码覆盖率是白盒角度覆盖率的一种,也是代码覆盖率的一种最常见的应用。不过,前提是你们有单元测试,否则没什么卵用。

    除了单元测试的代码覆盖率外,还有集成测试(你也可以理解为手工测试)的代码覆盖率,即直接获取一个正在运行中程序的代码覆盖情况。这种方法核心工具用的还是和代码覆盖率一致的覆盖率收集工具(java 用 jacoco,javascript 用 instanbul ),不过一般要配套平台来自动收集和生成报告(我所在的组现在就在做这个),否则使用步骤太复杂了,落不了地的。

    这方面以前调研的时候写过一篇文章,有涉及到单测覆盖率和手工覆盖率获取方式的区别,你可以参考下,也许能够有些启发:
    React Native 代码覆盖率获取探索 (一)
    React Native 代码覆盖率获取探索 (二)

    代码覆盖率如果没有足够的代码能力去好好分析和增加代码覆盖(比如你从报告看到第100行没有覆盖,有没有能力分析出这一行对应什么功能,评估通过什么样的用例可以覆盖,以及是否有覆盖的价值),其实就只是一个指标而已了。集成测试的变更覆盖率目前没有现成开源工具可用,必须自研(核心点在于如何把代码变更集融入到覆盖率报告的生成中),不过一些思路或者方法分享倒是有不少,你可以在社区找下,之前美团在他们的公众号好像也分享过一个。

    建议你考虑清楚,你需要这个覆盖率到底是为了应付老大们的需要,还是真的为了精细地衡量好每次测试的情况,并逐步根据覆盖率情况去改进测试方法,提高覆盖率。如果是后者,才值得投入。前者的话,给个黑盒角度的大致覆盖率就足够了。

  • 不行具体是什么?

    你这个问题是比较特定的问题,说实话我没有遇到过,所以很难给出完整的解决方案,只能根据经验和了解给你指一下方向。需要你提供足够齐全的信息。单纯的 “不行”、“失败” 很难帮你定位问题。

  • 如何量化测试覆盖率 at 2017年09月11日

    公式我觉得没啥问题,但可行性建议你考虑下:

    1. 产品设计的所有功能点这个比较难量化,需求的形式千变万化,很难统计。
    2. 自动化测试的覆盖率,从你的理解上看应该是代码覆盖率中的行覆盖率了。初期用这个确实可以,但要收集覆盖率,你需要衡量好现有的工具使用难度,以及自动化水平是否已经到达可以统计这个覆盖率的程度。

    这些覆盖率如果收集起来非常费事且难以统一,最后还是没啥用的。建议先找下,老大们想要的是怎样的覆盖率。说不定只是作为一个参考值,那只需要用例里体现就好,比如开始阶段全用例执行,覆盖率90%,后面主要执行高优先级,覆盖率是 高优先级用例/全用例 。

  • 我们是筛选了一套规则,分好优先级,新增代码有严重级以上问题不能提测。目前是提测邮件截图说明,有pipeline自动检查会更方便。

  • INSTRUMENTATION_FAILED: selendroid.com.kuparts.service/io.selendroid.server.ServerInstrumentation

    顺着这个方向 stackoverflow 一下吧。

    另外,除非是要在 android 4.3 以下或者其它特殊需求,automationName 建议不要设为 selendroid 。

  • 你的内测需求是什么?也许你想的内测和现在大部分人理解的内测不大一样?

    如果是想大规模内测(例如数千人),我觉得更接近灰度测试了,可能用灰度测试的方法更合适。

  • 视频链接貌似挂了?