在Android应用程序SDLC中测试组件？

“自动化测试是开发生命周期中不可或缺的一部分。”

在android应用程序项目中，我们已经实现了MVP、Rx和改装以及内容提供商/SQLite、dagger。每个安卓应用程序都会有服务器通信，将数据存储在本地数据库中，导航抽屉和回收器视图等复杂的用户界面，以及应用程序难以导航的流程

我们想要实现什么

• 在我们向客户交付apk或在play store上发布之前，每次都应该测试的测试用例很少？（20-30%自动化测试）
• 业务逻辑的测试用例列表，由于复杂的ui、导航流等原因无法自动测试（40-60%手动测试）
• 连续积分

基于以上，有几个问题

• 自动和手动测试什么，如何决定
• 在自动化测试中，在MVP-模型视图演示器层中的何处进行测试
• 什么样的通用业务逻辑应该自动测试移动应用程序-如注册、登录、忘记密码、更新配置文件等
• android应用程序应该执行什么类型的测试-单元测试、功能测试、集成测试、手动测试、性能测试、回归测试
• 使用哪种工具-android测试支持库、浓缩咖啡、uiautomator、Robotium、roboelectric、appium、selendroid、mockito、JUnit

---

（请随意改进检查列表，因为我们不知道针对android移动应用程序的SDLC中测试模块的最佳实践。）最初被问及。

您的问题的一些答案：

• 自动与手动的对比：一旦设计/开发周期结束，在发布之前，自动测试应该是代码交付的一部分。这里一个好的触发点就是在发布之前将UI测试包含在故事的定义中。对于Android来说，这可以像一些涵盖新功能的浓缩咖啡测试一样简单

• MVP层测试…单元测试演示者，UI测试视图。这几乎涵盖了模型中不起作用的任何内容，因为模型更改很少在这两个层之间单独进行。演示者中的高单元覆盖率有助于平衡编写了多少UI测试。有关详细教程，请参见

• 业务逻辑：至少，用户为实现关键目标（即您的收入流、基本采用）而采取的关键路径上的所有任务。因此，是的，这包括注册、登录和密码功能……但可能不包括所有首选项/配置及其效果

• 测试类型：每种类型都测试应用程序的不同层/方面，因此问问自己“我应该关注应用程序层中的哪些细节”
  • 该单元用于基本代码验证，所以始终是这样。这只是基本的开发效率101。高代码覆盖率有助于及早发现bug
  • 集成：是的，这取决于你的应用程序有多复杂，但测试应用程序是否具有依赖关系有助于在测试失败时找出谁有错
  • 功能测试（UI测试）：是的，简单的交互或完整的工作流程，但它是关于用户如何使用应用程序的。如果不经过一系列其他步骤，就无法测试应用程序的某些功能。同样，要与实际使用情况和业务期望保持一致。将您的工作量映射到现实、使用指标、对收入的影响等
  • 表现：这很难，有不同的学派。我们看到，一路上的性能“检查”是必要的，但是完整的性能测试周期通常会阻碍开发，除非团队/组织中有高度的成熟度和流程
  • 回归：不要把回归留给即将结束的巨大任务！由您所做的更改通知的较小的回归集有助于减少在后期周期回归测试中捕获的缺陷数量。早期意味着更小，不要忘记，我们正在处理一个非常分散的Android生态系统，因此回归策略中需要包括多个设备/平台/条件
• 工具：您已经基本确定了当前的工具链。对于Android用户界面测试，浓缩咖啡/匕首/莫基托是一个巨大的胜利。保持这些类型的测试小型化和集中化。对于端到端测试，Appium仍然是您最好的朋友，但有些事情即使是它也做不到（如视觉验证和某些弹出窗口），您需要在它们之外寻求自动化

另外，虽然我完全理解你的说法“无论什么原因都无法进行自动测试”，但我认为这是一个巨大的危险信号，细节非常重要。选择自动还是手动应该是关于如何实现速度目标的业务决策，而不是技术限制和不足。我一直从客户那里听到这句话，直到他们意识到正确的技术能够使他们达到适合他们的自动化水平

今年我协助进行了两项研究，我认为这将有助于这次对话：

---

希望这和我上面的研究能对你的工作有所帮助。

谢谢你的详细回答。MVP是一个模型视图演示器，是一个特定于技术的架构，你能看到它吗。