Android应用软件SDLC中的测试组件？

Question

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

在android应用程序proejcts中，我们实现了MVP、Rx和Retrofit以及内容提供者/SQLite、dagger。每个android应用程序都会有服务器通信，将数据存储在本地数据库中，复杂的ui，如导航抽屉和回收器视图等，以及难以导航的应用程序流程。

我们想要实现什么？

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

基于以上，有几个问题，

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

(可以随意改进检查列表，因为我们不知道android移动应用程序SDLC中测试模块的最佳实践。)最初是这样问的，这里。

Answer 1

对你的问题的一些回答：

• Auto与手动：一旦解决了设计/开发周期，在发布之前，自动化测试应该是代码交付的一部分。这里有一个很好的触发器，就是将UI测试简单地包含在故事发布前的定义中。对于Android，这可能就像一些涵盖新功能的Espresso测试一样简单。
• MVP层测试...unit测试您的演示程序和UI测试您的视图。这几乎涵盖了模型中任何不能工作的内容，因为模型更改很少是孤立于这两个层进行的。演示者中的高单元覆盖率有助于平衡编写了多少UI测试。有关深度教程，请参见这篇文章。
• 业务逻辑：至少，在用户为实现关键目标而采取的关键路径上的所有任务(即收入流、基本采用)。因此，是的，这包括注册、登录和密码features...but可能不会涵盖所有的首选项/配置及其效果。
• 类型的测试：每种类型测试您的应用程序的不同层/方面，所以问问自己“我的应用程序的层中有哪些细节我应该关心”？

- unit is for basic code validation, so yes to that, always. that's just basic dev efficiency 101 there. high code coverage helps you catch bugs early.
- integration: yes, and depends on how complicated your app is, but testing the app with/without dependencies helps isolate who's at fault when test fails.
- functional tests (UI tests): yes, simple interactions or complete workflow, but it's about how your users work with your app. some functions of the app can't be tested without going through a set of other steps. again, align with actual usage and business expectations. map your amount of work here to reality, usage metrics, impact on revenue, etc.
- performance: this is hard, and there are different schools of thought. what we see is that performance 'checks' along the way are necessary, but full performance testing cycles often impede development unless there's a high degree of maturity and process in the team/org.
- regression: don't leave regression to a huge task towards the end! smaller sets of regression informed by the changes you've made help to reduce the number of defects caught in late-cycle regression testing. earlier means smaller, and don't forget that we're dealing with a very fragmented Android ecosystem so multiple devices/platforms/conditions needs to be included in regression strategy!

​

• tools：您已经很好地掌握了当前工具链。对于Android测试，Espresso/Dagger/mockito是一个巨大的胜利。将这些类型的测试保持较小且集中。对于端到端的测试，Appium仍然是您最好的朋友，但是有些事情即使是它也做不到的(比如视觉验证和某些弹出窗口)，您需要超越它们来实现自动化。

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

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

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

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