Android App SDLC中的测试组件？

Question

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

在Android app proejcts中,我们使用Retrofit和Content Provider/SQLite,dagger实现了MVP,Rx.每个Android应用程序将始终具有服务器通信,将数据存储在本地数据库中,复杂的ui如naviagtion抽屉和回收器视图等,以及难以导航的应用程序流程.

我们想要实现什么？

• 在我们将apk发送到客户端或在Play商店发布之前,每次都应测试几个测试用例？(20-30%自动化测试)
• 业务逻辑的测试用例列表,由于复杂的ui,导航流等原因无法自动测试(40-60%手动测试)
• 持续集成

基于上述,问题很少,

• 在汽车和手动测试什么,如何决定？
• 在自动化测试中,在MVP - Model-View-Presenter层中测试的位置？
• 什么样的通用业务逻辑应该自动测试移动应用程序 - 如注册,登录,忘记密码,更新配置文件等？
• 什么类型的测试应该为Android应用程序执行 - 单元测试,功能测试,集成测试,手动测试,性能测试,回归测试
• 使用哪个工具 - android测试支持库,espresso,uiautomator,Robotium,roboelectric,appium,selendroid,mockito,JUnit

(随意改进检查清单,因为我们不知道在Android移动应用程序的SDLC中测试模块的最佳实践.)最初在这里问.

Answer 1

您的问题的一些答案:

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

• MVP层测试 ...单元测试您的演示者和UI测试您的视图.这几乎涵盖了不起作用的模型中的任何内容,因为模型更改很少独立于这两个层完成.演示者中的高单位覆盖率有助于平衡编写的UI测试量.请参阅此文章以获得深入的教程.

• 业务逻辑:至少,用户为实现关键目标(即您的收入流,基本采用)而采取的关键路径上的所有任务.所以是的,这包括注册,登录和密码功能......但可能不会涵盖所有首选项/配置及其效果.

• 测试类型:每种类型测试应用程序的不同层/方面,因此请问自己"我应该关注的应用程序层中的哪些细节"？

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

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

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

我今年协助了两项研究,我认为这将有助于这次对话:

1. 将质量扩展到构建周期
2. 在构建时提高应用程序质量

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