深度细考业务架构与特点，直击质量保障方案

测试同学通常的工作方法是，当产品提出需求后，进行需求宣讲；在完成需求评审，需求测试后，开发做技术系分，测试同学编写测试用例；用例编写完成后组织产品，开发进行用例评审；然后等着开发提测，在测试环境下部署代码，按用例进行测试，提交发现的bug，进行Bug跟踪和项目管理；最后就是做仿真环境的验证和上线回归测试等。期间会借助于一些技术手段辅助测试，如自动化测试，测试工具，或是测试平台来提高测试效率。其实随着工作年限的增加，测试同学应该更加主动一些，将测试向前迈一步。

一，深度分析产品架构和特点

对被测试业务做深入的了解是测试的基础，但是大多同学是对业务逻辑比较熟悉，而对产品的架构及特点是没有做过了解的。比如说，你负责测试的产品实现架构是什么样子的?这种业务架构有什么特点，而公司的产品在这种架构下的业务逻辑实现又有什么特点？可以不必了解代码实现的具体细节 ，但是整体架构，各个功能模块之间如何交互的，这种交互方法有什么特点，了解之后对测试的提升还是非常重要的。一般情况下，开发的技术文档，架构设计或是需求的技术系分都能找到相关的内容，架构图等信息。曾经测试过一个App应用，这个应用的整体是Native和H5相结合的方式来实现的，依赖大量的第三方SDK，同时对后端接口依赖很重，整体代码结构图就不在此展示了，这就是这个应用的特点。

二，深挖测试环节痛点和难点

针对自己产品的特点，深挖一下在平时测试过程中存的问题。平时测试的时候，能否正常执行测试流程，有没有开发延期提测的现象，测试环境不稳定，测试用例漏测，测试数据很难构造的现象呢？虽然经过仔细的测试，还是会发生现上问题？交给开发自测的内容是否可信呢？针对我上面举例的应用，是否存在H5页面加载缓慢，多机型的兼容性问题；第三方SDK升级或是与其他SDK,引用的库产生冲突，引起Crash或是影响业务流程的现象？对于所依赖的后端接口，后端服务能否保持高可用性？有没有对异常情况做处理，或是对异常情况做兜底处理？在如此复杂的结构下，如何保证应用的性能，如何保证良好的用户体验呢？如果要完全测试上面的问题，应该采用什么样的测试方案？静下心来，好好梳理一下现在测试的难点，痛点，列的越细越好，先不用考虑有没有解决方案。

三，对标现有知识体系和成熟方案

平时要对业界的测试技术方案，公司内部的技术方案有一定的了解，虽然可能你当时用不到。然后结合第二步分析的测试环境中的痛点，可以利用哪些现有的技术方案去解决？如果H5页面加载，SDK升极影响业务流程，可以利用AppUI自动化测试，回归核心业务流程，检测页面加载时间。对于SDK版本冲突问题，可以借助于Monkey测试来检测Crash问题；应用是否对后端数据异常情况进行处理，可以借助于mock方案构造后端数据返回的异常场景，检测应用的处理结果等等。这只是一个示例，如环境综合治理，持续化集成的推进，全链路压测试的引入，接口或是服务的全面回归和监控；产品性能或是其他指标的监控等，业界都有成熟的方案。根据自己产品的特点，测试中的痛点，与具体的业务方案进行一一对标，罗列出来进行头脑风暴。

四，针对性发起专项治理行动

在将测试痛点和业界或是公司内部成熟的方案对标后，组织分析一下现在业务的优先级，将高优先级的问题，或是最痛的痛点提取出来，成立专项治理方案来进行解决。注意，既然需要专项来解决问题，就需要通过正式的项目管理的方法来进行，通过公司项目管理平台创建正式的项目。组织相关参与同学，进行项目宣讲，任务拆分，各个参与同学给出具体的排期，关键节点的产出及验证方法，项目负责人等。及时进行项目信息同步，代码Review, 安排项目使用培训，组织业务同学进行使用和测试，解决使用中遇到的各种问题。切实保证所发起的专项能实实在在地解决问题，而不是走个形式或是没有结果。

五，实践检验效果，数字化考核成效

在公司所有的技术项目都是要以实用为主，比如说作为测试开发，在公司启动了一个项目，虽然这个项目技术很先进，但是如果不能在实际工作中使用，提高测试效率，还是一无事处的。所以我们发起的专项治理项目，也要在日常测试中进行检验效果，通过发现了多少Bug，减少了多少测试时间？协助开发做了多少自测的项目等可以量化的方式来进行衡量。如果有专门的工具或是平台收集和展示这样数据更好，如果没有，可以考虑开发相应的平台来进行度量。然后对比启动专项治理初期的预期结果，分析一下专项的效果，如果没有达到效果，哪个地方出现了问题，再去做优化，通过数字化考核的方式进行迭代。

六，由点及面，体系化流程化提高质量和效率

在进行多个解决测试痛点的专项治理后，就需要考虑一下如何将现在的专项方案进行体系化流程化，从而在整个测试流程中进行全面引入。比如说，先前进行了接口或是AppUI自动化测试的专项，测试环境专项治理，Monkey测试Crash问题，就可以考虑引入持续集成，将整个流程串联起来。在开发提测后，自动部署测试环境，触发接口自动化测试，检测提测代码是否影响原来的功能；如果原功能没有问题，服务端部署完成。鉵发端上打包功能进行打包，打包完成后，启动Monkey测试，先检测新打的包是否存在闪退现象。如果Monkey测试通过，触发AppUI自动化测试，检测应用的主流程交互是否有问题。如果没有问题，业务测试同学就可以去测试新功能，而不用担心新的项目是否影响原来的功能。这只是一个例子，你可以分析公司的技术专项，借助于Jenkins或是公司测试平台，进行相关流程的串联，从而形成流程进行体系化测试，关键节点卡口，防止因流程问题产生Bug。

上面是我听到一个测试大佬的一段讲话，引起的一些思考，当然这只是比较笼通的介绍，具体的要结合你们公司的具体业务来实施。向开发同学寻求帮助，搜索公司内部的文档，平时也需要时时关注业界的技术发展，以便在需要的时候随时能找到可行的方案。当然，你如果有不同的思考或是看法，欢迎与我讨论沟通哟！