1.  测试遇到的困惑与挑战

随着飞信活跃用户、同时在线数量的不断增加,互联网的快速发展,以及微信等新一代IM产品的上线，客观上对飞信的发展带来了巨大的挑战。作为飞信的开发运营支撑商，必须产品运营模式和开发流程进行变革才能使飞信产品更好的发展。而这些变化必然对原有的测试流程和体系带了很大的挑战。

互联网转型：互联网时代的到来，最直接的变化就是快，产品需要快速迭代，快速发布版本，原来需要半年时间发布一个客户端，而现在需要2个月甚至一个月发布一个客户端。如何在最短的时间提高更高质量的产品是摆在我们面对的一个首要问题。

多架构共存：为了适应互联网产品的快速发展以及更好的满足客户需求，需要对原有的架构进行升级，而在升级的过程中存在多系统架构并存，在测试过程中既要满足系架构的稳定正常运行，又要保证对老的系统架构的兼容性，这些无论是在工作难度还是工作量上都对测试工作提出了一个很大的挑战。

多种开发模式共存：为了适应互联网的开发节奏和保持原有系统的稳定，在开发过程中敏捷开发模式与传统开发模式交替共存，测试怎么样实现在传统模式中的“稳”和敏捷模式中的“快”，对测试来说这是一个巨大的挑战。

分省运营、灰度发布

在互联网产品中常常使用灰度发布这一策略，灰度发布能够及早获得用户的意见反馈，完善产品功能，提升产品质量 让用户参与产品测试，加强与用户互动降低产品升级所影响的用户范围。 另外，随着移动互联网公司的成立，对飞信的运营模式进行了改革，要求支持飞信分省运营模式。灰度发布和分省运营的变化对测试来说，工作量成指数增加。如何在测试成本可控的条件下进行测试是我们每个人必须考虑的一个课题。

另外随着移动互联网的快速发展，飞信需要支持的客户端越来越来越多，用户场景越来越复杂，对测试的难度和工作量剧增。

2.  各种接口方案分析及实施

如何解决上面提到的几个问题？要解决这些问题按照常规的测试模式，肯定不能满足；经过分析（见下图）我们认为在客户端的皮下层进行测试。也就是接口测试，可以很好的解决上面的问题。

经过对业务和接口的详细梳理，发现在所有的系统中，其接口测试无非就是需要对以下集中种接口进行测试：

客户端模拟接口测试

随着无线互联网的飞速发展，越来越的手机厂商加入，越来越多基于开源手机操作系统开发的系统的增加，以及多种网络的接入，采用传统在UI进行测试的方法成本越来越高，实施分层测试，进行模拟客户端测试势在必行，对于一般的系统来说，各种客户端连接服务器端的接口都是相同的，或者根据版本不同会有略微差异。那么在接口测试时，就可以把UI要测试的几十种版本分类抽象出一个或者几个版本接口测试，而客户端的测试仅仅需要在UI上进行核心功能验证和适配测试，从而大大提高测试效率。如在飞信测试过程中大概会有15个以上客户端需要测试，在测试过程中又会根据情况选择1-3个版本的客户端进行测试，那么在一个大的版本测试中累计测试客户端达到30个以上，其工作量可想而知；如果进行接口测试，通过对各个客户端和不同版本分析，其接口后台通信协议只有三种（如下图所示），那么在测试过程中只需要模拟三个客户端，即可完成对所有客户端模拟测试，大大节省了测试时间。另外测试前移也使得在开发过程中尽早尽快的发现问题成为可能，从而加快版本迭代速度。

多系统集成项目接口测试

在互联网时代，任何一个系统都不能孤立存在，需要和其它系统进行交互。而在大部分情况下， 这种多系统之间的集群测试，很难等到所有项目都配置部署完成才进行测试，那么就需要模拟被测系统与其他系统的交互（如下图所示）。在模拟测试前，现需要整理分析其被测系统前置条件和被测系统发送的请求信息；在模拟系统接收到请求信息后，按照预先约定的信息下发通知给被测系统，被测系统接收到下发通知后，继续执行被测系统，完成一次测试模拟。通过多系统集群的模拟测试，提高系统的测试覆盖率。

通用接口（比如web services等）测试和自定义对象格式接口测试

通用接口（比如web services等）测试和自定义对象格式接口测试（如SDK接口等）这两种接口测试在本质上没有多大的区别，但其在测试实现和组织上会有一定的差异，在此不详细叙述。对于这两种测试，测试人员需按照协议规范设置需要的测试输入输出参数，然后按照约定的请求格式发送请求，然后在比对测试结果。对于这类测试，如果在接口比较少的情况向，建议使用测试代码直接测试；而对于接口较多，使用较为频繁，根据情况可以开发测试工具或者自动化工具；对于使用自动化测试来说，其难点是如何组织设置接口的前置条件，所以说对于这类测试建议最好使用测试工具而不是自动化测试。

强交互类系统接口测试

3.  接口收获与经验

通过对接口测试使用自动化后，对server的测试带来很多收获。

1.     自动化测试使得测试覆盖率提高10%，通过自动化测试实现了一些原来不能测试的用例：比如心跳，强制短信、短信回复、消息稳定率（7*24）测试、电量、内存等长时间测试。

2.     测试效率提升50%：自动化测试覆盖核心用例和单功能用例实现100%覆盖，重要功能70%以上覆盖，总体覆盖达53%；在测试执行中，BVT用例、灰度测试以及版本任务测试（版本任务实现手工测试与自动化测试统一管理，协调工作）；通过测试实践得出整体测试效率提升50%以上（说明：测试脚本在开发单模块时一次完成，对于协议测试不需要维护成本。

3.     通过自动脚本整理，自动化测试脚本描述的业务逻辑分析，其业务描述已成为公司最新最全的业务资产库。通过对业务逻辑分析，优化逻辑，大大提升了软件质量，比如会话通过业务分析优化消息成功率从99.9%提升到99.987%

在接口测试过程中，怎么像测试人员证明其测试结果是可信的，怎样才能保证实施自动化过程中不增加测试人员的工作量和不改变测试人员原有工作模式。这些都是考验自动化测试是否能够成功的最主要因素。

在自动化测试过程中，如果保证测试结果正确性，在测试实践中有几条我认为比较好的经验。

1.    测试脚本评审：在编写自动化测试脚本后，每个测试脚本必须通过评审。测试脚本评审虽然不能保证测试脚本完全正确，但至少可以查出一些比较明显的业务逻辑，同时也是使其参与评审测试人员在内心不会对测试脚本的质量感到恐慌和不信任。在评审过程中有几点要注意：1.尽可能的让评审业务相关的测试人员参与；2.每次评审时间不超过1个小时，时间过程容易流于形式；3谁提出问题，谁负责审查。

2.     定时任务检查：通过评审的信令场景加入定时任务，连续运行监测其正确性。在其定时任务执行过程中，一般会连续执行一个月，每天会安排固定人员对测试结果进行分析验证（一般会安排参与评审的业务人员，分析时间一般不超过30分钟）。对于在连续一周以上且通过率高于93%的任务，安排进行与版本同步测试验证其正确性。

3.     与测试版本同步：在版本测试任务同时，进行自动化测试，检查其脚本的正确性。

4.     测试交付：通过评审，最近两周定时任务连跑中通过率超过95%，IM基础功能和测试模块,在版本任务中测试验证过两次以上

在自动化测试过程中， 尽可能不改变原有测试流程，比如我们在飞信业务测试过程中，自动化测试时结合原有流程（如下图）

1)   自动化测试用例和手工测试用例实现一管理，在编写用例过程中，直接从测试工具中导入用例到自动化平台，同时在测试管理工具中标示出改用例已自动化实现。

2)   在有版本任务分过来后，在测试平台建立测试任务，同时自动在自动化平台生成一个测试计划。

3)   测试人员只需要测试自动化没有实现的测试用例，自动化测试执行自动化实现的用例，在执行完成后把测试结果自动导入到测试平台。

4)   测试人员根据测试结果编写测试报告

在自动化测试过程中要结合业务进行一些定制化的测试，比如在飞信测试项目中，根据其特点建立了数据池及灰度测试策略和二次连跑机制

账号池及灰度测试：：通过统一账号管理，实现对不同账号的管理（不同环境的账户、不同site的账户管理），通过执行策略，分账户实现功能之间灰度测试

二次连跑：针对协议测试的不确定情况，设置了连跑模式，可以设置不同的连跑模式（连跑、二次连跑、直到通过等）