超级会员免费看
服务端测试涵盖对WEB和APP后端接口的测试，以及数据库、缓存等基础服务的测试。测试工作包括接口测试、性能测试、异常测试、稳定性测试，涉及工具如Postman、JMeter等。在阿里等大型公司，还会进行模拟生产业务系统进行压测。测试人员需要具备较高的技术水平，了解数据库、操作系统等，并关注社区进展。
服务端测试做什么？
作者：钱蓓蕾 链接：服务器端测试主要包含什么？ - 知乎
一般来说，服务端测试有两种：一种是直接对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等工具来进行性能测试，不过难的不是这些工具的使用，而是发现问题以后的定位。
对于这种后端服务的测试人员来说，技术上的要求是挺高的，需要有较好的编程能力，需要对数据库、操作系统等机制有很好的了解才行。
阿里如何测试服务器性能？
阿里为双11做的压测是完全模拟整个生产业务系统。完全模拟从前端客户端（各种客户端）到服务层-到后台--数据库，所谓的端到端，涵盖了客户端性能测试+网络端性能测试+服务器性能测试，压测打通整个业务链路。所以为了模拟这样全套流程，尤其是这么大的同时并发量，需要推动参与的人就过千，压力源服务器按他当时宣传的并发在线人数应该准备了1500-2000台。 这样来看，普通的压测工具肯定是无法负担和协作的。不仅仅是阿里，像美团、饿了么都会有这样的高并发，他们都是自己开发的压测系统，服务自己的业务。 如果要问现在的云端压测系统能不能负担，HP Stormrunner，Soasta Load Cluod，阿里PTS，以及我们和腾讯云合作的WeTest压测平台WeTest服务器压力测试 高并发，实时性能报表，专家级性能优化建议【腾讯WeTest】，理论是可能满足的，但一定需要进一步的定制，因为云平台只是第一步能满足你这么大的压力，最主要的还是怎么基于这个业务去设计测试模型，需要云平台具备具有很强架构能力、丰富压测经验的攻城狮辅助客户。
作者：desuolisi 链接：如何测试服务器的性能？ - 知乎
浅谈服务器测试全周期
目前做网站压力测试： 权威的商业软件还是LoadRunner。
开源使用范围最广的是Jmeter，其他常用还有Gatling、Tsung，目前被各大电商修改的开源Grinder。
最简单的ab工具、Seige等等。
在线压测的话OneAPM的CPT比较专业的，目前真正能做到云压测百万QPS的。
压力测试需要关注三个方面：如何正确产生压力、如何定位瓶颈、如何预估系统的承载能力。
产生压力的方法 通常可以写脚本产生压力机器人对服务器进行发包和收包操作，也可以使用现有的工具(像jmeter、LoadRunner这些)，所以说产生压力其实并不难，难点在于产生的压力是不是真实地反映了实际用户的操作场景 性能问题 TPS、响应时延等性能数据，关注系统的CPU、内存、IO、网络，对比在tps、时延达到瓶颈时这些系统数据的情况，确定性能问题是系统哪一部分造成的，然后再回到代码的逻辑中逐个优化这些点。
性能测试，难点在于你确认要测什么?是压力测试还是负载测试 确定测试策略和测试指标。也就是在性能测试中常说的测试场景。 再次确认测试环境，内网，无网络问题，带宽足够，线上，线下服务器配置相同，架构同样。缓存设置，等等一系列 工具 简单的AB WB JM 复杂的LR 性能测试的实施阶段。后续还有调优，复测。。 5种协议：HTTP、HTTPS、WebSocket、Socket、MQTT 加密：AES、DES、RSA、MD5、SHA1，自有加密算法包调用。
性能指标：并发用户数、错误率 、吞吐量、每秒点击数、每秒响应数、事务平均响应时间、每秒事务数、每秒事务总数等
基础硬件指标：CPU、内存、磁盘、网络流量、网络连接等
资源细分指标：HTML、图片、JS、接口等响应时间精确详细
性能指标 访问量，响应速度、容错能力、运行状态和响应时间
微软的 Web Application Stress Tool(简称 WAST)为例进行一次 Web 压力测试 CMD 窗口中使用命令 netstat -an 用VPS或者独立服务器搭建网站 Webbench，Apache Bench，http_load是三款比较流行的网站服务器压力Web性能测试工具 (受网络等各种因素的影响，测试结果不一定很准确) apache自带的工具ab测试. 也可以试试http_load; Apache Bench又叫做AB，是Apache 附带的一个小工具， 专门用于 HTTP Server 的benchmark testing，ab命令会创建很多的并发访问线程，模拟多个访问者同时对某一URL进行访问，可用来测试Apache的负载压力，也可以测试nginx、lighthttp、IIS等其它Web服务器的压力。 Webbench是由Lionbridge公司开发出来的一个网站压力测试工具，可用于测试ASP,PHP,JAVA,CGI等服务器压力， 也可用于SSL的安全网站的负载能力进行测试，最多可以模拟3万个并发连接去测试网站的负载能力， Webbench操作简单，一行命令就可以显示出服务器压力。 http_load这是国外一个博主开发的基于linux平台的性能测试工具，主要是以并行复用的方式运行， 可以用来测试web服务器的吞吐量与负载，测试结果一目了然。Apache Bench,Webbench,http_load这三款网站服务器压力测试工具还要根据测试者的主机性能来决定参数，防止把测试主机给搞成死机了。 Siege 开源的压力测试工具， 根据配置对一个WEB站点进行多用户的并发访问， 记录每个用户所有请求过程的相应时间，在一定数量的并发访问下重复进行。
性能测试基础
jmeter监控服务端性能
测试大佬私藏的测试面试题
测试大佬私藏的性能测试岗位常见面试题，拿走拿走别客气！ - 知乎
软件测试常常测到的错误点集合
https://zhuanlan.zhihu.com/p/54360921
web测试中bug定位方法
安全测试怎么入门？
性能测试入门—loadrunner初探
高可用服务架构的优秀资料索引
基于appium的安装ui自动化测试
基于 Appium 的 Android UI 自动化测试 - 知乎
为什么Stack Overflow只需要11台IIS 服务器和4台负载均衡就可以支撑这么大的流量？
2013年还是2014年，stackoverflow第一次公布了部分数据和架构，引发了我很大的兴趣。 当时stackoverflow日UV 300W+，PV 2Y+，正好和我司当时的数据完全一样。他们使用了8台物理服务器，而我们呢，使用了400+近500台物理服务器。 我们是lamp架构，和stackoverflow的windows体系架构有区别，但是性能差异不至于到大数量级。而且一般来说lamp架构的性能更好，而我们正相反。我们采购的是戴尔低端机型，换算到stackoverflow的性能，大概是2:1，那么硬件资源的对比是250:8，性能差异是反比，8:250。 我们的架构上应该没有大问题，db分布了，缓存分布了，solr做的search，图片资源多但走的是外部的cdn，该做的调优也做了，打了google的malloc，开了大页内存，nginx mysql redis的各项参数，也做了性能测试和ab test经过n轮调整，那为什么性能差异还是这么大? 一个原因应该是业务逻辑，我们带有社交元素，交叉的各种点赞，关注，收藏等关系和查询，有更多性能开销，但是这个我觉得不是主要原因。主要的性能差异在我看来，是应用层面开发的程序员造成的。 我们处理过许多许多典型的性能坑： db查询没用到索引 联表查询太复杂性能奇差 循环里写查询一次连接变几十次 打开文件句柄 socket连接没有释放 300k文本直接存到redis里 curl请求没有加超时 不同的进程争抢同一个文件资源写日志 get_image_size()获取图片尺寸(会把图片文件整个读取到内存里，每个连接都会！) 写的扩展内存溢出 直接读取整个巨大文本文件(应该逐行方式读取) 在代码逻辑循环里直接发短信发邮件(应该扔到队列异步处理) ip黑名单和关键词过滤直接用文本查找比对(应该做成hash表)
每次看面试题都是算法，调优，架构(我们自己也是)，其实我想说90%的情况下我们需要的是能合格编写增删改查的业务需求的程序员就够了。
至于stackoverflow，我想他们也没有发明什么太多银子弹黑魔法，指数级的提高性能。他们做到的只是：找到了合格的程序员。这就够了。
1255
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
