您应该测试的内容取决于应用类型、开发团队、旧版代码的数量和使用的架构等因素。以下各部分概述了新手在规划在应用中测试哪些内容时可能需要考虑的事项。
测试目录的组织方式
Android Studio 中的典型项目包含两个目录，用于存储测试的执行环境。请按照说明，在以下目录中整理测试：
androidTest目录应包含在真实或虚拟设备上运行的测试。此类测试包括集成测试、端到端测试，以及仅靠 JVM 无法验证应用功能的其他测试。test目录应包含在本地计算机上运行的测试，如单元测试。与上述方法不同，这些测试可以是在本地 JVM 上运行的测试。
基本单元测试
在遵循最佳实践时，您应确保在下列情况下使用单元测试：
- 针对 ViewModel 或 Presenter 的单元测试。
- 针对数据层（尤其是代码库）的单元测试。大部分数据层都应独立于平台。这样做可让测试替身替换测试中的数据库模块和远程数据源。请参阅有关在 Android 中使用测试替身的指南
- 针对其他独立于平台的层（例如网域层），针对用例和交互器进行单元测试。
- 针对实用程序类（例如字符串操作和数学）的单元测试。
测试极端情况
单元测试应同时关注正常情况和极端情况。极端情况很少见，真人测试人员和大型测试不太可能发现。示例包括：
- 使用负数、零和边界条件的数学运算。
- 所有可能的网络连接错误。
- 数据损坏，例如格式错误的 JSON。
- 保存到文件时模拟已满存储空间。
- 在进程过程中重新创建的对象（例如旋转设备时的 activity）。
应避免的单元测试
应避免某些单元测试，因为它们的价值较低：
- 用于验证框架或库（而不是您的代码）能否正常运行的测试。
- activity、fragment 或 service 等框架入口点不应具有业务逻辑，因此不应将单元测试视为优先事项。针对 activity 的单元测试几乎没有什么价值，因为它们主要涵盖框架代码，并且需要进行更复杂的设置。插桩测试（如界面测试）可以涵盖这些类。
界面测试
您应该采用以下几种类型的界面测试：
- 屏幕界面测试检查单个屏幕中的关键用户互动。它们可执行点击按钮、在表单中输入内容和检查可见状态等操作。不妨先为每个屏幕创建一个测试类。
- 用户流测试或导航测试，涵盖大多数常见路径。这些测试会模拟用户完成导航流程的情况。这些是简单的测试，可用于检查初始化过程中的运行时崩溃。
其他测试
还有更多专门的测试，例如屏幕截图测试、性能测试和 Monkey 测试。您还可以按用途（例如回归、无障碍功能和兼容性）对测试进行分类。
深入阅读
为了单独进行测试，您经常需要将受测对象的依赖项替换为虚构或模拟依赖项（通常称为“测试替身”）。请继续阅读在 Android 中使用测试替身。
如果您想了解如何创建单元和界面测试，请参阅测试 Codelab。