背景

针对近半年的测试经验进行简要的总结，部分内容参考了网络上的一些文章

有哪些服务端测试

我们公司有哪些服务端的应用：

1、web端的服务，onsite直播平台、云导播、云轮播、拆条、收录等等
2、客户端相关的服务：无

针对以上的这些服务，总结归纳了一下，划分了两种类型：

1、B\S结构，即浏览器\服务器结构，也就是各种web应用，这些web应用只与浏览器有关，他的web页面以及各种后台逻辑均运行在各种服务器上。
2、C\S结构，即客户端\服务器结构，这种产品的客户端需要与服务器端通过接口进行通讯，同时服务器端还有自己的功能逻辑，在接收到客户端发送的请求之后会进行处理，然后返回给客户端。

准备工作

针对以上这两种不同结构的服务器端程序，如何进行测试呢？

首先，制定一套完善的测试流程，通过该流程，指导测试、开发、产品、OP运维等同学的工作。在这个流程中，有三个关键的环节：

准备会议

产品需求评审会

在这个评审会上，产品会对提出的需求做出详细的讲解，如果各方涉及的人员比较多，还会确定产品负责人、开发负责人、测试负责人。各负责人的职责如下：

1、产品负责人：是这个项目的总负责人，负责各配合方之间的沟通。
2、开发责任人：包括客户端和服务端，原则上由客户端开发为开发的总负责人。
3、测试负责人：包括客户端和服务端，原则上由客户端测试为测试的总负责人。

开发设计实现讲解会

在这个环节，开发会在接到需求后，组织一次设计评审，在这里主要由开发（包括前端和后端）和测试参加，在会上我们会做以下几件事情：

1、由开发详细的讲解功能得到设计思路，包括客户端和服务器端的功能实现
2、后续的计划排期
3、在设计阶段就会增加线上的监控机制

经过这两个评审会之后，测试会给出大概的测试方案，待开发提测后，测试就可以展开后续的测试工作。

准备环境

测试服务器

我们的开发会将编写完成的代码上传到SVN上，所有测试环境中的代码均来自SVN，这样可以保证被测试的代码与SVN上的代码是一致的，与此同时，我们也要不断的关注开发开发SVN上的改动，以便确认测试的范围和后续的验证。

待上线服务器

待服务器端的功能测试完毕后，会将被测试完成的代码部署到待上线服务器上，待上线环境的配置与线上环境完全相同。我们会在这台机器上进行性能相关的测试。

线上服务器

待性能测试与功能测试均完毕后，测试会将开发提交的代码进行冻结，开发会给OP运维部门提交上线申请单，然后由OP运维部门将SVN中测试完毕的代码部署到线上。待部署完成后，测试会针对线上环境进行上线验证。

准备监控

我们会针对线上提供的服务进行监控，主要是该服务的接口功能正确性。

而服务器运行的稳定性是由OP运维部门负责监控。

当发生线上问题时，测试、产品、开发、OP均会收到包括邮件和短信的通知。

测试先进行问题确认，并及时给出结果反馈。

如果有问题，开发和OP会对问题进行排查，并由测试进行验证。

如果没有问题，会查当时通知时发生了什么，以便确认问题是被自动修复了，还是线上监控脚本出现了问题。

如何开展

有了上面的测试流程之后，那么在开发提测后，我们是如何进行测试的呢？针对之前提到的两种不同的产品类型，我们会进行以下两方面的测试：

功能测试

针对功能测试，我们有两种不同的测试方法：

基于用户层面的黑盒功能测试

1、根据产品提出的需求文档，划分功能，拆分需求点，根据需求点，进行对应测试用例的编写；
2、在这个过程中，基本上忽略了客户端与服务器端或前台页面与后台逻辑是如何进行交互的，完全通过客户端或前端页面的行为进行功能测试。

基于代码逻辑和服务器配置的白盒测试

服务器端配置的正确性与合理性

1、服务器是否有缓存机制；
2、服务器对连接数是否有限制；
3、服务器的负载均衡是否合理；
4、服务器连接的是否有超时设置；
5、各种网络请求是否使用的是内网IP。

接口测试

一般情况下客户端与服务器端的数据交互，均是通过http请求完成的。而服务器端通过web服务器将接收到的请求进行处理。这些处理主要围绕着，对数据的存储、运算、转发等操作，并将操作之后的结果反馈给客户端。所以接口功能的正确与否，会直接反映服务器端功能的正确与否。那么，这对接口我们是如何进行测试的呢？

1、根据该接口的功能，评估该接口定义的合理性与安全性，例如：
    1）客户端发送的网络请求是否需要带有时间戳；
    2）客户端发送的网络请求是否需要有固定的参数，比如客户端发送的请求中需要带有版本号等信息；
    3）客户端发送的数据是否需要进行加密；
    4）服务器端是否有针对请求发送来源的校验；
    5）服务器端给客户端返回的数据及状态码是否合理。
2、接口的测试方法
    通过编写测试脚本，针对接口进行测试，步骤一般是这样的：
    1）根据接口定义的参数，确认传输的参数都有哪些，可能的正常取值和异常取值；
    2）通过脚本模拟客户端发送网络请求，对接口进行单独测试，并对服务端返回的结果数据进行自动化校验；
    3）通过脚本构造用户的一系列操作，用以验证系统功能的可用性。
3、代码功能逻辑测试
    1）对服务器端的代码做静态代码走查，主要关注以下内容：
        1.定义的变量是否都被初始化；
        2.服务器是否有针对客户端发送的数据进行异常校验；
        3.对数据库的操作是否有未释放的情况；
        4.服务器端的判断逻辑是否存在功能隐患；
        5.连接的数据库环境是否正确；
        6.对数据库的操作是否有关闭操作。
    2）通过编写单元测试用例进行验证

性能测试

制定方案

依据需求，明确测试目的
围绕测试目的来制定测试方案，测试方案要明确需要关注的性能参数、测试方法，确定要使用的工具
最后要考虑到整个测试流程中可能存在的影响结果准确性的风险点（网络波动、CDN与SLB配置等非平台因素）

以下是之前进行直播平台性能测试的简单测试方案

选择压力生成工具

服务器压力测试工具有很多，也可以自己写适合性能测试场景的压力生成脚本

较为常用的压力测试工具：
    Jmeter
    LoadRunner
    ab
    st_load

以上测试工具的简单使用方法参照本博客其他文章，《ab下载与上传压测》，《st-load安装与使用》

选择监控工具

监控工具也有很多，也可以需求写适合性能测试场景的监控脚本，重点提取需要关注的性能参数

运维监控工具Zabbix等
nmon

以上部分工具的简单使用，参考本博客其他文章，《Nmon使用总结》

测试环境准备

1、明确各个模块集群内部的服务器配置：基本的有内存、CPU、磁盘以及网络带宽等等
2、部署测试环境，也可以编写自动化部署脚本（ansible）或者使用容器（docker、kubernetes）快速部署
3、系统流程调试，确保系统底层功能正确无误

测试脚本准备

考虑到压力机系统瓶颈，测试过程中可能需要多台压力机同时给出压力，为提高测试效率以及避免操作失误，需准备测试脚本

编写测试脚本可采用脚本语言亦可采用编程语言
shell
expect
python等

expect脚本在压力测试中的简单使用参考本博客中《Linux下expect脚本语言的简单使用》

执行测试

渐增加压，达到一定程度观察系统稳定性，观察资源消耗以及系统响应情况

单台

1、在一定的配置与系统环境下，得出模块单台服务器的系统性能
2、若有条件，在以上基础上对程序内部单个接口进行压测
3、定位瓶颈并给出优化意见

集群

1、在一定的配置与系统环境下，得出模块集群服务器的系统性能
2、SLB配置（带宽峰值、调度算法、会话保持等）、内网带宽等
3、定位瓶颈并给出优化意见

系统

1、在一定的配置与系统环境下，得出平台整体的系统性能
2、入出口SLB配置（带宽峰值、调度算法、会话保持等）、内网带宽与外网带宽、CDN命中率等
3、定位系统瓶颈并给出优化意见

数据库等其他模块

1、压测过程中观察系统与数据库交互情况，排查数据库是否可能是系统瓶颈点
2、硬件、操作系统、数据库配置、应用模型、引擎选择等

参考资料

http://blog.csdn.net/wlly1/article/details/51357306

https://www.zhihu.com/question/20694803

https://www.cnblogs.com/zhuque/archive/2013/03/15/2961953.html