>自动与手动：一旦设计/开发周期结束,自动化测试应该是发布之前代码交付的一部分.这里的一个很好的触发器就是简单地在故事定义中包含UI测试.对于Android而言,这可能与一些涵盖新功能的Espresso测试一样简单.
> MVP层测试…单元测试您的演示者和UI测试您的意见.这几乎涵盖了模型中几乎没有任何功能,因为模型更改很少在隔离这两层的情况下完成.演示者的高单位覆盖有助于平衡UI测试写的多少.请参阅this article深入教程.
>业务逻辑：至少,用户完成关键目标(即您的收入来源,基本采用)的关键路径上的所有任务.所以是的,这包括注册,登录和密码功能…但可能不涵盖所有首选项/配置及其效果.
>测试类型：每种类型测试应用程序的不同层次/方面,所以问问自己“我应该关心哪些应用程序的细节”？

>单位是用于基本代码验证,所以是的,总是.那只是基本的开发效率101.高代码覆盖率可以帮助您早日捕获错误.
>集成：是的,并且取决于应用程序的复杂程度,但是使用/不依赖测试应用程序有助于在测试失败时隔离出错的人.
>功能测试(UI测试)：是的,简单的交互或完整的工作流程,但它是关于您的用户如何使用您的应用程序.应用程序的某些功能无法通过一系列其他步骤进行测试.再次,符合实际使用和业务预期.将您的工作量映射到现实,使用指标,对收入的影响等.
表现：这很难,有不同的思想.我们所看到的是,一路上的性能“检查”是必要的,但是完整的性能测试周期往往阻碍开发,除非团队/组织中有高度的成熟度和过程.
>回归：不要让回归到一个巨大的任务结束！您所做的更改通知的较小套回归有助于减少后期循环回归测试中遇到的缺陷数量.早期意味着更小,不要忘记,我们正在处理一个非常分散的Android生态系统,因此需要将多个设备/平台/条件纳入回归策略！

>工具：你几乎确定了当前的工具链.对于Android UI测试,Espresso / Dagger / mockito是一个巨大的胜利.保持这些类型的测试小而集中.对于端到端测试,Appium仍然是您最好的朋友,但有些事情甚至无法做到(比如视觉验证和某些弹出窗口),您将需要寻求超越它们的自动化.

另外,虽然我完全理解你的声明“不能因为任何原因自动测试”,但我认为这是一个很大的红旗,细节很重要.汽车与手动的选择应该是关于如何实现速度目标的业务决策,而不是技术限制和不足.我一直听到客户的意见,直到他们意识到正确的技术使他们能够达到适合他们的自动化水平.

今年有两件研究,我认为会帮助这个对话：

> Expanding Quality into the Build Cycle
> Improving App Quality at Build-time

希望这个和我上面的研究有助于你的工作.