android - Android App SDLC 中的测试组件？

Question

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

在 android 应用程序项目中，我们已经实现了 MVP、Rx with Retrofit 和 Content Provider/SQLite、dagger。每个安卓应用程序都会有服务器通信，将数据存储在本地数据库中，复杂的用户界面，如抽屉导航和回收 View 等，以及应用程序的困难导航流程。

我们想要实现什么？

• 在我们将 apk 交付给客户或在 Play 商店发布之前每次都应该测试的测试用例很少？(20-30% 的自动化测试)
• 业务逻辑测试用例列表，由于复杂的用户界面、导航流程等原因无法自动测试(40-60% 手动测试)
• 持续集成

基于以上，问题很少，

• 自动和手动测试什么，如何决定？
• 在自动化测试中，在 MVP - Model-View-Presenter 层中的何处进行测试？
• 应为移动应用自动测试哪种一般业务逻辑 - 例如注册、登录、忘记密码、更新个人资料等？
• 应该为 Android 应用执行什么类型的测试 - 单元测试、功能测试、集成测试、手动测试、性能测试、回归测试
• 使用哪个工具 - android 测试支持库、espresso、uiautomator、Robotium、roboelectric、appium、selendroid、mockito、JUnit

(请随时改进检查列表，因为我们不知道在 SDLC 中为 Android 移动应用程序测试模块的最佳实践。)最初询问，here .

Answer 1

您问题的一些答案:

• 自动与手动:一旦设计/开发周期确定下来，自动化测试就应该成为发布前代码交付的一部分。这里的一个很好的触发器是在发布故事之前将 UI 测试简单地包含在故事的完成定义中。对于 Android，这可能就像一些涵盖新功能的 Espresso 测试一样简单。

• MVP 层测试...单元测试您的呈现器和 UI 测试您的 View 。这涵盖了模型中几乎所有不起作用的东西，因为模型更改很少在隔离这两层的情况下进行。 Presenter 中的高单元覆盖率有助于平衡编写了多少 UI 测试。见this article获取深入教程。

• 业务逻辑:至少，用户为实现关键目标(即您的收入流、基本采用)所采取的关键路径上的所有任务。所以是的，这包括注册、登录和密码功能……但可能不会涵盖所有偏好/配置及其影响。

• 测试类型:每种类型测试应用程序的不同层/方面，所以问问自己“我应该关心应用程序层的哪些细节”？

  • unit 用于基本代码验证，因此始终如此。那只是基本的开发效率 101。高代码覆盖率有助于您尽早发现错误。
  • 集成:是的，并且取决于您的应用程序的复杂程度，但是在有/没有依赖项的情况下测试应用程序有助于在测试失败时找出问题所在。
  • 功能测试(UI 测试):是的，简单的交互或完整的工作流程，但它与您的用户如何使用您的应用有关。如果不经过一组其他步骤，则无法测试应用程序的某些功能。再次，与实际使用和业务预期保持一致。将您在此处的工作量映射到现实、使用指标、对收入的影响等。
  • 表现:这很难，而且有不同的思想流派。我们看到的是，一路上的性能“检查”是必要的，但完整的性能测试周期通常会阻碍开发，除非团队/组织具有高度的成熟度和流程。
  • 回归:不要将回归留给一个巨大的任务!根据您所做的更改通知的较小回归集有助于减少后期回归测试中发现的缺陷数量。更早意味着更小，并且不要忘记我们正在处理一个非常分散的 Android 生态系统，因此需要将多个设备/平台/条件包含在回归策略中!

• 工具:您几乎掌握了当前的工具链。对于 Android UI 测试，Espresso/Dagger/mockito 是一个巨大的胜利。保持这些类型的测试小而集中。对于端到端测试，Appium 仍然是您最好的 friend ，但有些事情即使它也做不到(例如视觉验证和某些弹出窗口)，您需要超越它们才能实现自动化。

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

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

1. Expanding Quality into the Build Cycle
2. Improving App Quality at Build-time

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