|
|
服务器端测试主要包含什么？
本人是自动化测试工程师， 一直做得是功能方面自动化，我拿到的测试需求是保证产品的功能良好，于是我会用各种方式模拟用户操作，很好奇服务端测试都要测试什么…
关注者
194
被浏览
155,928
8 个回答
这可是一个很大的话题，呵呵。
一般来说，服务端测试有两种：一种是直接对WEB或者APP的服务端进行测试；另一种是对更后端的数据库、缓存系统、中间件、文件系统等进行测试。
一、先来说第一种吧：直接对WEB或者APP的服务端进行测试。
一般来说，这种服务端的开发人员就是WEB／APP产品团队的开发人员，当然，测试人员跟WEB／APP的前端测试人员也是一个团队的。这种服务端就是为WEB／APP端提供一些后台的接口，比如说，用户个人信息、交易记录的读取和存储等，一般都是用HTTP接口的方式提供。这种后台的测试从流程上来说是跟随着WEB／APP产品的发布节奏来的，在后端开发完成接口以后，测试人员就直接用TestNG＋HttpClient写接口测试用例、或者用Postman等工具手工测试。如果项目紧张，一般会先用Postman等工具先手工测试，等版本发布完以后，再用TestNG＋HttpClient把自动化用例补上去，或者用Python的Nose框架。
对于这种服务端后台的测试人员，除了需要掌握上述的自动化测试技术之外，还有一个沟通、协调的工作，因为后台的接口一般是同时提供给iOS／Android／WEB三个端，所以需要跟三端的测试人员协调测试进度、测试环境等事项。
如果遇到后端服务大的重构、或者是第一次上线预计有大流量的，那还需要对后端服务做一个性能测试，用JMeter／Grinder等工具编写脚本并进行压测，看看后端服务能不能撑住大流量。有些版本性能风险小的，不必要每次都做性能测试，可以根据实际版本的情况具体分析。
二、第二种：对更后端的数据库、缓存系统、中间件、文件系统等进行测试。
这种就类似于云计算等后端基础服务的测试，对于一些大的公司，会有一个专门的团队来开发这种后端基础服务，这种服务当然也需要测试人员来保证质量。
这类服务一般都是通过HTTP接口的方式提供给刚才讲的WEB／APP的后端使用，所以，第一个要做的也就是 接口测试 ，也就是用Postman等工具做手工测试、用TestNG＋HttpClient或者Python的Nose框架做自动化测试。
不过，对于这类后端服务来说，接口只是暴露给外用的部分，内部逻辑通常是非常复杂的，所以，除了针对接口做测试之外，测试人员还需要细致地了解这些服务端产品的技术框架及技术实现，需要了解到模块的级别，对于系统框架图、时序图等都有很好的理解。针对这些理解去设计用例，再跟开发一起讨论如何实现用例。
如果这种基础服务用了某一个开源软件，那通常也需要测试人员能关注社区的进展，并把我们发现的Bug及解决方案等推到社区，为社区做贡献。
除了接口测试之外，在我们公司，异常测试、稳定性测试、性能测试也是服务端测试必备的测试类型。
异常测试 会模拟各种异常情况，比如硬件异常－机器挂掉的情况下能否启动备机、硬盘挂掉的情况下是否会丢失数据；网络异常－网络忽然断掉、或者网络流量变小的情况；系统异常－操作系统忽然挂掉的情况。这些极端的情况出现的时候，我们需要验证数据有没有丢、能不能尽快启动备机对外提供服务、系统状态有没有异常等。我们会采用各种方式或者工具来模拟这些异常，比如用TrafficControl工具来控制网络流量。
稳定性测试 ，就是模拟系统在7*24的运行下会不会出问题，一般会用接口测试或者性能测试用例不断地跑，在运行期间，我们会模拟各种情况，比如说负载的变化、系统的各种干扰等。可以用ChaosMonkey等工具来进行这类测试。
性能测试 ，其实细分起来会有各种类型，比如负载测试、压力测试、配置测试、甚至还有线上压测、容量规划等。最常规的性能测试，一般是先规定一个系统需要承受的压力，比如说，某一个系统，1个小时之内会有1W单的单子，那基于这个需求我们分析服务器后端需要承受的压力，分析出来以后，就写性能测试脚本，然后逐渐增加压测的力度，直到超过这个预定的压力。通常在这个测试过程中会发现各种问题，比如数据库索引没有建、线程池太小、系统异常等。需要解决了之后再加大压力测试。也是用Grinder／JMeter等工具来进行性能测试，不过难的不是这些工具的使用，而是发现问题以后的定位。
对于这种后端服务的测试人员来说，技术上的要求是挺高的，需要有较好的编程能力，需要对数据库、操作系统等机制有很好的了解才行。
你好，我是测试开发臻叔。
服务端测试有两种：
一种是 直接对 WEB 或者 APP 的 API 接口进行测试；
另一种是 对更后端的数据库、缓存系统、中间件、文件系统等进行测试 ，核心就是输入输出是否符合服务设计。
必备的测试手段包括：
- 接口测试
- 性能测试
- 稳定性测试
- 异常测试
其中稳定性测试中涉及：异常、超时、重试幂等、性能等
1）基于 API 的服务端测试
这种服务端就是为 WEB／APP 端提供一些后台的接口，一般都是用 HTTP、HSF、MTOP 接口的方式提供。这种后台的测试从流程上来说是跟随着发布节奏来的，根据时间、提测以及持续集成目标，可以采用不同的测试方法：
- 手工接口测试
根据接口设计，测试人员可以借助中间件平台，自有工程，第三方工具进行接口测试了。接口测试过程中，特别需要关注异常场景测试，单接口异常测试主要包括输入异常、操作异常、依赖服务异常，测试验证时关注 「容错逻辑」 以及 「异常返回码是否符合接口约定」 。
- 输入异常：包括入参为特殊字段类型、非法长度、边界值等
- 操作异常：例如操作为特殊业务流程、非法修改数据等非正常业务操作
- 依赖服务异常：包括访问超时、服务挂掉、异常返回码等场景
- 手工集成测试
待需求的前端和上下游都交付之后就可以进入集成测试阶段，在这个环节测试人员除了协调各涉及端的测试进度、测试环境和自己域的业务验证之外，同样需要关注异常测试，集成阶段的异常主要包括输入异常、接口异常、操作异常，测试验证时关注 「异常文案交互是否符合业务预期」 。
- 输入异常：包括入参为特殊字段类型、非法长度、边界值等
- 接口异常：例如接口超时、非约定返回码等
- 操作异常：业务流程中高频导致的并发、乱序等非法操作场景
「异常测试」 主要分为功能异常、服务端异常
功能异常主要通过各种入参模拟进行验证，接口测试目前可用自建平台、postman 以及其他任意接口测试平台
测试常用功能介绍：
- 保存参数、导入参数：平台支持保存当前参数模板，方便下次导入调用，但需注意仅支持保存一套参数
- 自定义 Timeout：可以自定义时间，越过接口原超时限制，mock 超时场景下接口返回
- 指定 Provider 调用：指定 IP 进行调用，便于调试和问题定位
- 活用执行结果信息：接口执行失败需要上下游配合排查定位时，traceId、Provider 是关键排查参数
注意事项：
- 特定角色才能在控制台进行 hsf 接口测试（例如测试负责人）
- 入参输入建议切换到 Code 模式下编辑，以免类型转换错误
服务端异常目前主要可通过一些强弱依赖平台进行验证，很多平台支持对线上流量自动进行分析并生成用。
- 持续集成
借助类似 Jenkins 工具平台完成手工测试的自动化持续集成，实现接口级别的回归和链路级别的回归。
2）对更后端的数据库、缓存系统、文件系统等中间件进行测试
对于这类后端服务来说，接口只是暴露给外用的部分，内部逻辑通常是非常复杂的，所以，除了针对接口做测试之外，测试人员还需要细致地了解这些服务端产品的技术框架及技术实现，需要了解到模块的级别，对于系统框架图、时序图等都有很好的理解，针对这些理解去设计用例和执行。下面介绍几种常见中间件的测试思路和方法：
- 模拟消息发送，验证消费消息后的代码逻辑
打开消息控制台，找到对应的 topic 点击发送，输入 body 消息后确定发送
- 验证 metaq 消息是否按照约定发送
打开 metaq 控制台，点击进入“消息查询”，查看消息体和轨迹，验证是否符合期望
- DTS 任务的调试
schedulerx 分布式系统调度任务的调试和排查可以使用控制台
- 编辑：输入 job 运行参数
- 触发一次：手动触发
- 指定机器：可以勾选指定 job 运行的服务器
作者：麒烨；原文链接： 多面手之服务端测试
我是专注分享测试干货的臻叔，喜欢的可以 关注 哦~
其他精华文章——
软件测试高薪的真相：
臻叔自己转行到测试开发的经验总结（精华）
软件测试必看书单：
❤既然都看到这里啦，请你帮个忙：
1、点赞，让更多小伙伴看到；
2、关注我，持续更新测试干货。
最后，感谢您的阅读。
你的盛赞就是对创作者最大的支持！