最近在论坛看到一些有关项目复盘的分享，有不少的收获，所以决定也把以往的项目总结分享出来，希望对同行能有所帮助，也期待能看到更多的分享。
一、项目简介
如图1-1，展示了笔者参与项目业务流程的简化模型，业务可以简化为两个流程：用户信息认证流程和额度评估流程。在用户信息认证流程里，用户在App端进行信息认证项的认证，传递用户信息数据到额度评估系统，在额度评估流程里，额度评估系统对用户提交的数据进行处理和复杂运算，返回用户认证后可贷款的额度。
图1-1 业务流程_爱测角
二、项目成员
如图1-2所示，除了App端测试人员，项目的成员还包括产品人员、UI设计人员、App端开发人员（Android和iOS）、App服务端开发人员、上游服务端开发和测试人员。从项目成员组成我们可以看出，此项目涉及多岗位、多端以及跨部门的协作，作为下游端测试人员，如果只是了解和关注App端的测试工作，在这个项目中，不管是项目排期还是协作过程，测试人员就会处于极其被动的地位。如何解决这种困境呢？这就需要我们在了解其他岗位工作内容的前提下，在项目中发挥出桥梁作用，与各方紧密协作，保证各方对项目需求、进度以及风险等信息的理解是一致的，并推动各方逐步完善协作流程。
图2-1 项目团队成员_爱测角
在与不同的团队成员协作时，我们不仅需要从其他成员那里获取项目信息，也需要及时反馈信息给对方。在与产品人员的协作中，我们需要向他们了解本次需求的业务背景，明确需求范围和产品方案，同时我们需要及时和他们同步项目进度和项目风险。在与UI设计人员的协作中，我们需要与他们了解设计稿的交互逻辑和展示逻辑，同时我们需要及时反馈设计中的遗漏点和疑问点，保证设计稿覆盖全部功能点。在与App端开发人员的协作中，我们需要和他们了解App页面展示的逻辑（数据来自哪个接口哪个字段），功能实现的逻辑（数据如何转化），同时要及时组织App端开发和App服务端开发进行联调。在与App服务端开发人员的协作中，我们需要从他们那里了解接口设计，数据库设计，数据处理逻辑，日志查询方法等，同时，我们需要对他们的设计进行评估并提出疑问。在与上游服务端开发和测试人员的协作中，我们需要了解上游服务的开发和测试排期，需要了解App服务与上游服务的调用方法，同时我们需要提前与他们沟通并确认联调时间。
三、测试要点
项目测试要点的设计可以概括为两类：通用测试要点和专项测试要点。
通用测试要点指的是所有功能测试都可以采用的方法。首先，笔者借鉴MVC框架将项目拆解为测试MVC模型。V即View视图是指用户看到并与之交互的界面，这个项目中V即App端，在图3-1中即App端-界面测试模块；C即controller控制器是指控制器接受用户的输入并调用模型和视图去完成用户的需求，控制器本身不输出任何东西和做任何处理，该项目中C既包含了App端的逻辑处理，也包括了App服务端的逻辑处理，同时还包含了上游服务的逻辑处理，在图3-1中即App端-转化逻辑模块和服务端-转化逻辑模块；M即model模型是指模型表示业务规则，也可以理解为业务数据的逻辑模型，在项目中体现在为数据库的设计，在图3-1中即服务端-数据库模块。
专项测试要点指的是对测试的端需要有针对性的测试内容。如图3-1中App端-兼容测试模块所示，本项目的客户端是App，包括Android端和iOS，需要进行相应的兼容测试测试。当然还有性能等模块，本文暂不展开介绍。
图3-1 项目测试要点_爱测角
四、测试方法&测试工具
对于此项目的测试方法，本文将借鉴文章《漫谈软件系统测试——通信节点识别》的思路展开讨论。如图4-1所示，我们将额度评估系统划分为App客户端、App服务端和上游服务三层，两个层级之间即为一个通信节点。
对于App客户端，我们通过网络代理软件Charles代理App端的网络请求，并对特定接口的响应数据进行篡改或者映射到本地数据文件，从而实现不依赖服务端就能验证不同业务场景下App端的展示和交互逻辑是否正确。如图4-1所示，我们可以通过篡改【10.认证状态及额度信息】的接口响应数据，验证不同认证状态以及不同额度信息场景下App端的交互和UI是否符合预期。
对于App服务端，如图4-1所示，我们可以通过网络请求模拟软件Postman模拟接口请求，并根据业务场景设置对应的入参【1.认证项信息】，同时我们可以使用数据库操作软件，例如Navicat for Mysql直接构造或者修改MySQL数据库数据，从而实现不依赖在App端重复操作业务流程就能验证不同场景下App服务端的数据处理逻辑是否正确。除了要关注接口的输入和响应结果，在服务端测试中，服务日志也是非常重要的数据，通常在结果出现异常的时候，我们可以观察请求的相关日志辅助定位问题。如果存在上游服务，如图4-1所示，我们也可以通过代理服务Mock上游服务的响应数据【3.认证数据获取结果MQ（一种异步消息）】和【8.认证项额度变更结果MQ】，从而实现不依赖上游服务完成App服务端相关模块的测试。
对于上游服务，因为有对应部门的测试人员进行测试，所以我们并不需要对上游服务逻辑进行测试。但是由于上游服务依赖下游服务的真实输入，所以作为下游测试人员，我们需要协助构造真实测试数据，构造数据的方法除了端操作外，依然可以通过修改数据库数据覆盖同等测试场景。
图4-1 系统通信节点_爱测角
五、项目收获&&问题复盘
图5-1 Frice项目收获_爱测角
项目的收获主要从与人协作、业务知识、技术能力和项目管理四个方面来总结，具体内容因人而异本文暂不展开分享，大家可以参考几个方面去进行总结。
图5-2 Frice问题复盘_爱测角
项目中的突出问题主要包括：多部门协作难和测试深度不足。由于项目设计多部门团队且各团队成员是初次合作，所以在第一次迭代版本中频繁出现信息沟通不明和排期不一致等问题，为了解决这些多部门协作出现的的问题，如图5-2所示，基于风险前置的思路，采取了提前了解外部团队的工作内容，提前制定联调计划，及时跟进进度以及暴露风险和项目排期预留缓存期等措施，有效地提高了后续合作的效率。由于项目的复杂性比较高，所以仅仅从下游端（App端）进行测试是很难保障整个项目的质量。为了保障整个项目的质量需要加强对端及服务实现逻辑的理解并探索对应的测试方法，包括将UI、接口和数据库测试相结合，学习开发调试方法，了解功能的具体实现逻辑，探索和自研自动化测试工具等等。
针对App测试项目总结，本文分别介绍了项目简介、项目成员、测试要点、测试方法与测试工具和项目收获与问题复盘五个模块，希望对大家有所启发，也欢迎留言交流。
