今天我们就来说说移动测试的测试策略和测试架构。首先，我们将移动应用的范围限定为智能移动操作系统（如Android、iOS、WinPhone等），包括手机应用、智能设备应用等。智能手机和智能设备的普及需要大量的支持的应用程序数量。随着应用数量的增加和业务复杂度的增加，移动应用越来越需要各种测试来保证应用和设备本身的正确稳定运行。因此，对移动应用测试的需求也越来越大，涌现出一大批移动应用测试书籍，如《Android移动性能实战》、《腾讯iOS测试实践》、《移动APP性能评测与优化》、《深入理解Android自动化测试》、《精通移动App测试实战：技术、工具和案例》等。这些。书籍介绍了大量的移动应用测试实践，但是无论你读了多少书，学习了多少测试方法、测试技术，或者学习了多少测试工具和框架，你还是需要先学习和使用测试策略和测试框架。如果一开始没有很好的测试策略和测试结构，而是盲目地进行各种测试，很可能会事倍功半。对于移动应用来说，首先，它本质上也是一个软件系统，所以可以采用通用的软件测试方法和技术。其次，它具有嵌入式特性，比如开发需要交叉编译、远程调试、硬件资源相对不足等。因此，移动应用的测试也有其特殊性，如交叉编译、远程测试、各种硬件相关的测试等。相应的移动应用的测试策略和测试架构也有其特殊性。为了制定测试策略，我将移动测试分为三种类型，即基础测试、高级测试和产品测试。基础测试是产品正确快速交付的基本保障，扩展测试主要是增强软件系统的健壮性，而产品测试主要是从产品和用户的角度进行测试。下面列出了三种常见的测试类型。1.基本测试功能测试（FunctionTest）1集成测试（IntegrationTest）单元测试（UnitTest）契约测试（ContractTest）22。AdvancedTest兼容性测试（CompatibilityTest）UI可视化测试（UIVisualTest）PerformanceProfile（性能剖析）SecurityTestExceptionTest3MonkeyTestInstallation,UpgradeandUninstallTestEnduranceTestPowerConsumptionTestTrafficTest(NetworkTrafficTest)其他硬件功能专项测试43.产品测试可用性测试（UsabilityTest）A/B测试（A/BTestProductVerificationTestorProductOnlineTest（CustomerTest）Test）5对于中小型项目，资源往往非常有限，并且很难做全面类型的测试，尤其是大型项目，更难有足够的资源做所有类型的测试。并且也可能由于团队成员技术能力的不足，或者自身拥有的测试相关技术栈的局限性，以及开发测试环境和软件系统架构的局限性，一些类型的测试无法进行。因此，制定测试策略的重点是根据质量需求的优先级，并参考团队的各种约束条件来指定。首先与PO、PM等商讨得到产品质量需求的优先级，然后根据优先级指定相应的测试类型。然后根据团队的资源、项目周期、技术能力和各种约束制定相应的测试方法和测试技术，包括是使用自动化测试还是手动测试，使用什么测试工具和测试框架，测试的范围和程度等.下表是一个典型移动应用的测试策略表示例（这只是一个模拟项目的示例表，实际项目中应该会有更多的信息，可以根据具体情况增加新的列。并且注意这些测试不一定要由测试人员或QA来完成，而应该由整个团队一起完成）：表中质量需求优先级的获取是一个比较繁琐的过程，需要与各个stakeholder进行讨论通过协商获得。根据这个测试优先级表，您知道资源应该首先投入到高优先级的测试中。当高优先级的测试达到团队可以接受的水平后，再根据优先级进行下一类测试。此表中的优先级在开发过程中并非绝对不变。如果PO、PM等干系人的优先级改变了产品质量需求，需要在团队同意后更改本表中的测试优先级。因此，需要经常与团队更新测试进度，及时获取团队各角色对测试和产品质量要求的反馈和更新。其次，可以根据测试金字塔等模型来思考不同类型测试之间的关系和工作量，但是很多时候不需要参考这些测试模型，因为移动应用的复杂度一般不是特别的高高，而且目前大多数情况下，移动应用中复杂的业务逻辑会尽可能在服务器端处理，所以移动应用往往只是一个用户交互系统，所以应该完成对用户有影响的E2E流程测试尽可能多，然后继续做其他类型的测试。但是，对于在移动应用中实现复杂服务的项目，测试策略应该尽量考虑测试类型之间测试用例的重复，尽量避免重复用例，降低测试成本。制定测试架构通过测试优先级表，我们得到了一个简化版的测试策略，接下来我们应该制定测试架构。由于嵌入式软件的特殊性，其测试框架也不同于常规的桌面系统和服务器系统。下图为上述示例测试策略对应的功能测试架构：图中仅对功能测试进行了更详细的架构设计，未对集成测试、兼容性测试等其他测试进行详细的架构设计和稳定性测试，有兴趣的读者可以根据自己项目的实际情况自行尝试。通过这个架构图，可以比较系统，直观的了解各类测试的分布和关系，以及测试系统的架构。然后配合测试优先级表更好的指导团队进行有效的测试，比如制定更好的测试计划，制定更适合的自动化测试系统等。而且还能更有效的评估产品质量，比如什么类型测试没有做，那么在那些具体方面有更高的风险。但是，任何软件系统都有缺陷和风险。关键是看这些缺陷对开发者和用户的影响有多大，风险是否在可控范围内。永远不要试图找到所有的缺陷并消除它们，而是综合考虑风险、影响等方面来增加团队对产品质量的信心，不要对客户造成严重和大规模的影响。注：1、后台常驻应用测试也是功能测试。2.单机应用不需要考虑契约测试。3、异常测试包括弱网测试，如网络信号低速、网络断断续续、网络切换、无网络等、突然断电等。4、其他硬件功能专项测试包括硬件功能关机、硬件功能异常等5.用户测试包括收集用户使用信息，生成用户实际使用的测试用例来测试系统。【本文为专栏作家《ThoughtWorks》原稿，微信公众号：Thinkworker，转载请联系原作者】点此阅读更多本作者好文
