后端服务器集群测试需要注意什么

㈠ 分布式系统的分布式系统的测试

· 在测试执行过程中，对测试结果的分析是一个需要进行深入思考的重点问题。分布式系统测试的重点在于对后端服务器集群的测试，而判定系统中是否存在Bug则是我们需要解决的重要问题。那么应该如何确定是否存在Bug呢？
对于测试结果的分析，我们通常观察下面几种情况。
观察前端应用的返回结果。这里需要分两种情况来考虑：第一，按照前端应用业务功能点及流程进行操作，观察返回结果是否符合业务方的需求预期；第二，操作后端的服务器（通常是重启、宕机、断网等操作），观察前端应用的返回结果是否符合系统的设计需求。
分析服务器日志。在功能测试过程中，当我们在启动服务器的时候，需要将日志级别定义为Debug级别（最低级别）。这样做的主要目的是为了能便于测试工程师来分析日志和定位问题。为了能更好地定位问题，常常需要在服务器程序代码中进行日志打桩，把程序中的一些重要数据通过日志的方式展现出来。通常情况下，我们需要对日志的格式进行约定，在日志行中增加一些关键字来进行分类，这将便于测试工程师进行日志分析，也有利于开展分布式系统的自动化测试。另外，值得注意的是，我们尽可能地将打桩代码放在Debug代码中，避免影响系统代码，引入新问题。
分析操作系统的一些重要信息。我们测试的分布式系统绝大多数是基于linux操作系统开发的，在测试的过程中，除了详细分析程序日志以外，还需要对操作系统的一些重要数据信息进行分析，从而来诊断服务器程序是否存在异常。以Linux操作系统为例，我们常常会使用top命令、netstat命令及sar命令来查看操作系统的一些数据信息。例如，可以通过netstat命令检查服务器程序是否正确地监听了指定的端口等。
借助其他分析工具。例如，如何判断服务器程序是否产生了内存泄漏？通常需要借助于内存检测工具来进行分析。在Linux环境下，我们常用Valgrind来进行内存检测。这是一款非常好用、功能强大的分析工具，可以帮助测试或者开发工程师快速发现很多隐藏的程序Bug，尤其是在内存检测方面（同时它还具有很多其他优秀的功能，读者可以自己查看官网中的使用手册）。 对于分布式系统而言，压力测试和性能测试非常重要。在进行压力测试和性能测试的时候，可能会碰到下面一些难点。
数据准备。如何准备海量的测试数据并保证模拟数据的真实性？以一个分布式的文件系统为例，预先存入100GB的数据还是存入100TB的数据、存入的文件是大小基本一致差别不大还是各不相同甚至差异很大（例如，从几十字节至几十兆字节不等），这些因素对于分布式系统的性能影响是有很大差异的。另外，如果需要预先存入100TB的数据，若按每秒写入100MB数据来计算，写入100TB数据需要100×1024×1024/100=1048576秒=291.27小时=12天。我们是否能忍受这么长时间的数据准备工作？为了解决这样的问题，我们需要对系统架构设计进行深入分析，设计好测试场景，并提前进行测试用例的设计，以尽早开始准备测试数据。
性能或压力测试工具。通常来说，分布式系统的测试需要开发一些测试工具来满足性能测试的需求。如果可以的话，建议这样的测试工具最好由测试工程师自己来实现，因为测试工程师更清楚自己的测试需求。当需要自己开发测试工具的时候，有两个关键问题需要重点关注：第一，一些关键数据的收集方式与计算将成为性能测试工具的关键，例如，TPS（每秒请求数）、Throughput（吞吐量）计算的准确性；第二，要保证性能测试工具的性能，如果工具本身的性能不好，将无法给予分布式系统足够强大的压力来进行测试。另外，当考虑到多并发（例如有10万客户端同时并发连接）时，如果性能测试工具在一台测试机器上只能运行50个或者更少的话，那么需要的测试机器数量也将会很庞大（例如2000台测试机），这个成本或许是许多公司不能承受的。因此，性能测试工具本身的性能必须要足够好才能满足需求、降低测试成本。 自动化测试是测试行业发展的必然趋势，对于分布式系统测试而言也不例外。在实施分布式系统自动化测试的过程中，我们可能会碰到下面两个难点问题。
涉及平台多且硬件杂，测试流程控制困难。在实施自动化测试的过程中，测试脚本需要控制的操作系统和应用程序很多，而且存在跨平台的特性，同时还有可能需要控制一些网络设备。因此，选择一个优秀的自动化测试框架成为了非常重要的工作之一。以我们的实践经验来看，STAF是一个不错的选择，它的平台（Windows及Linux各版本）支持及开发语言的支持都很全面。
测试结果验证复杂。对于分布式系统的自动化测试来说，我们需要通过测试脚本来收集各种测试结果数据以验证测试结果的正确性。在实施自动化测试的过程中，我们可以将测试结果数据收集部分模块化，通过各子模块来检测各项数据是否正确。例如，我们会设计一个日志分析模块，主要负责从服务器应用程序的日志中收集相应数据进行对比验证（本文前面提到的在打桩日志中增加关键字部分就显得格外重要）。
随着互联网的发展，大型分布式系统也越来越多、越来越复杂、越来越重要。如何有效地保证大型分布式系统7×24小时全天候持续稳定地运行也就成为了一个重要课题。

㈡ web测试中对客户端和服务器的性能测试都涉及到什么

这种就类似于云计算等后端基础服务的测试，对于一些大的公司，会有一个专门的团队来开发这种后端基础服务，这种服务当然也需要测试人员来保证质量。

这类服务一般都是通过HTTP接口的方式提供给刚才讲的WEB／APP的后端使用，所以，第一个要做的也就是接口测试，也就是用Postman等工具做手工测试、用TestNG＋HttpClient或者Python的Nose框架做自动化测试。

不过，对于这类后端服务来说，接口只是暴露给外用的部分，内部逻辑通常是非常复杂的，所以，除了针对接口做测试之外，测试人员还需要细致地了解这些服务端产品的技术框架及技术实现，需要了解到模块的级别，对于系统框架图、时序图等都有很好的理解。针对这些理解去设计用例，再跟开发一起讨论如何实现用例。

如果这种基础服务用了某一个开源软件，那通常也需要测试人员能关注社区的进展，并把我们发现的Bug及解决方案等推到社区，为社区做贡献。

除了接口测试之外，在我们公司，异常测试、稳定性测试、性能测试也是服务端测试必备的测试类型。
异常测试会模拟各种异常情况，比如硬件异常－机器挂掉的情况下能否启动备机、硬盘挂掉的情况下是否会丢失数据；网络异常－网络忽然断掉、或者网络流量变小的情况；系统异常－操作系统忽然挂掉的情况。这些极端的情况出现的时候，我们需要验证数据有没有丢、能不能尽快启动备机对外提供服务、系统状态有没有异常等。我们会采用各种方式或者工具来模拟这些异常，比如用TrafficControl工具来控制网络流量。

稳定性测试，就是模拟系统在7*24的运行下会不会出问题，一般会用接口测试或者性能测试用例不断地跑，在运行期间，我们会模拟各种情况，比如说负载的变化、系统的各种干扰等。可以用ChaosMonkey等工具来进行这类测试。

性能测试，其实细分起来会有各种类型，比如负载测试、压力测试、配置测试、甚至还有线上压测、容量规划等。最常规的性能测试，一般是先规定一个系统需要承受的压力，比如说，某一个系统，1个小时之内会有1W单的单子，那基于这个需求我们分析服务器后端需要承受的压力，分析出来以后，就写性能测试脚本，然后逐渐增加压测的力度，直到超过这个预定的压力。通常在这个测试过程中会发现各种问题，比如数据库索引没有建、线程池太小、系统异常等。需要解决了之后再加大压力测试。也是用Grinder／JMeter等工具来进行性能测试，不过难的不是这些工具的使用，而是发现问题以后的定位。

对于这种后端服务的测试人员来说，技术上的要求是挺高的，需要有较好的编程能力，需要对数据库、操作系统等机制有很好的了解才行。

㈢ 什么是服务器集群服务器集群的缺点和优点是什么

出现任何故障，如：硬盘、内存、CPU、主板、I/O板以及电源故障，运行在这台服务器上的应用就会切换到其它的服务器上。

二、集群系统可解决软件系统问题，我们知道，在计算机系统中，用户所使用的是应用程序和数据，而应用系统运行在操作系统之上，操作系统又运行在服务器上。这样，只要应用系统、操作系统、服务器三者中的任何一个出现故障，系统实际上就停止了向客户端提供服务，比如我们常见的软件死机，就是这种情况之一，尽管服务器硬件完好，但服务器仍旧不能向客户端提供服务。而集群的最大优势在于对故障服务器的监控是基于应用的，也就是说，只要服务器的应用停止运行，其它的相关服务器就会接管这个应用，而不必理会应用停止运行的原因是什么。

三、集群系统可以解决人为失误造成的应用系统停止工作的情况，例如，当管理员对某台服务器操作不当导致该服务器停机，因此运行在这台服务器上的应用系统也就停止了运行。由于集群是对应用进行监控，因此其它的相关服务器就会接管这个应用。

集群系统的不足之处在于：

我们知道集群中的应用只在一台服务器上运行，如果这个应用出现故障，其它的某台服务器会重新启动这个应用，接管位于共享磁盘柜上的数据区，进而使应用重新正常运转。我们知道整个应用的接管过程大体需要三个步骤：侦测并确认故障、后备服务器重新启动该应用、接管共享的数据区。因此在切换的过程中需要花费一定的时间，原则上根据应用的大小不同切换的时间也会不同，越大的应用切换的时间越长。

㈣ 服务器配置选择需要注意哪些方面

服务器配置选择需要注意的有：

1、可扩展性

服务器必须具有一定的“可扩展性”，这是因为企业网络不可能长久不变，特别是在当今信息时代。如果服务器没有一定的可扩展性，当用户一增多就不能胜任的话，一台价值几万，甚至几十万的服务器在短时间内就要遭到淘汰，这是任何企业都无法承受的。为了保持可扩展性，通常需要在服务器上具备一定的可扩展空间和冗余件（如磁盘阵列架位、PCI和内存条插槽位等）。

可扩展性具体体现在硬盘是否可扩充，CPU是否可升级或扩展，系统是否支持WindowsNT、Linux或UNIX等多种可选主流操作系统等方面，只有这样才能保持前期投资为后期充分利用。

2、易使用性

服务器的功能相对于PC机来说复杂许多，不仅指其硬件配置，更多的是指其软件系统配置。服务器要实现如此多的功能，没有全面的软件支持是无法想象的。但是软件系统一多，又可能造成服务器的使用性能下降，管理人员无法有效操纵。所以许多服务器厂商在进行服务器的设计时，除了在服务器的可用性、稳定性等方面要充分考虑外，还必须在服务器的易使用性方面下足功夫。

服务器的易使用性主要体现在服务器是不是容易操作，用户导航系统是不是完善，机箱设计是不是人性化，有没有关键恢复功能，是否有操作系统备份，以及有没有足够的培训支持等方面。

3、可用性

对于一台服务器而言，一个非常重要的方面就是它的“可用性”，即所选服务器能满足长期稳定工作的要求，不能经常出问题。其实就等同于Sun所提出的可靠性（Reliability）。

因为服务器所面对的是整个网络的用户，而不是单个用户，在大中型企业中，通常要求服务器是永不中断的。在一些特殊应用领域，即使没有用户使用，有些服务器也得不间断地工作，因为它必须持续地为用户提供连接服务，而不管是在上班，还是下班，也不管是工作日，还是休息、节假日。这就是要求服务器必须具备极高的稳定性的根本原因。

4、易管理性

在服务器的主要特性中，还有一个重要特性，那就是服务器的“易管理性”。服务器虽然在稳定性方面有足够保障，但也应有必要的避免出错的措施，以及时发现问题，而且出了故障也能及时得到维护。这不仅可减少服务器出错的机会，同时还可大大提高服务器维护的效率。其实也就是Sun提出的可服务性（Serviceability）。

服务器的易管理性还体现在服务器有没有智能管理系统，有没有自动报警功能，是不是有独立与系统的管理系统，有没有液晶监视器等方面。只有这样，管理员才能轻松管理，高效工作。

(4)后端服务器集群测试需要注意什么扩展阅读：

服务器维护保养：

1、注重机房环境的建设

机房环境对服务器的正常运转有着重要的影响作用。因此，服务器维护和保养的首要环节就是做好机房环境建设。机房要保证充足的空间，用以安装和配置服务器的相关设备，机房的隔断，地板等要组好防静电等细节处理。机房的防火工作也很关键，要做好墙面和电缆等的防火处理。一旦遇到火情等，如何保障设备的安全，如何保障人员的有序撤离等都是机房建设中需要考虑的因素。机房的温度和湿度也应当操持在一定的范围，温度和湿度对于电子产品的正常工作有着非常大的影响作用。

2、做好硬件维护工作

服务器的硬件组成较为复杂，对于服务器硬件的维护应由专业人员进行。在维护和保养存储设备时，我们首先应当对其容量进行测试，看是否需要进行扩容等操作。存储容量一定要能满足任务的需求，并留有一定的冗余量。在拆卸和更新服务器设备时，务必让设备处于断电状态并进行接地处理。即便是更换最简单的部件，这些环节也不能省略。对于一些不熟悉的部件，要反复仔细的阅读说明书和参照文件，在没有十足把握的前提下切忌盲目拆解。要定期对服务器进行除尘处理。

3、维护好服务器软件

软件是服务器的重要组成部分，服务器的稳定高效运行离不开相应的软件。我们要定期对服务器的软件系统进行巡检，及时发现漏洞，及时安装官方给定的补丁程序。在扩展服务器数据库时，在条件允许的情况下，最好对原有数据进行备份，以免造成不必要的损失。

4、做好电力控制

没有稳定的电力保证，服务器就没有办法正常工作。电子控制是一个非常关键，但又非常容易被忽视的问题。在机房建设之初，我们就应当充分考虑到服务器的电力保障。要为机房设计和配置一套稳定，可靠的电力供应系统。这套系统还要有处置和应对突发事件的能力，例如，不可预知的停电、雷电等。

5、密码管理

服务器的密码管理是服务器防御能力的最关键组成部分。密码的管理和更换应当形成一套长效机制。我们要定期对服务器的密码进行更换，密码应有专人管理。选用的密码要有一定的专业性，一定的复杂度，最好是将数字和字母等结合起来，大小写也要融合进去。在日常的检查中，我们要做好登统计，关闭一些不太使用的端口。

㈤ 想做程序员做后端都需要掌握哪些知识

目前掌握的仅能：
1，研发（基本吧，产品总得有人来做）
2，调优（主要是Mysql调优，在符合业务需求的情况下尽可能提高TPS）
3，运维（小公司不会像大公司一样还标配运维，通常后端兼任运维职能）

扩展下：
研发：php入行，选个好框架（推荐Yaf），然后研发过程中多注意下性能，多用php本身的函数来解决需求，php本身函数丰富，而且都是C扩展，性能非常可靠。

调优：这个我实在不知道该放到研发还是运维，所以就单独拿出来说。因为其实对于服务器性能的调优本身两边都需要进行，一是研发时注意，二是各个软件（主要是DB）的配置项。我的调优很粗暴，用阿里云的压力测试（耗费了公司一些钱财，罪过罪过）每次压一分到5分钟，然后看看瓶颈在哪里，把配置项全部列出来，肉眼+自行判断调整哪个参数看看能不能提升性能（233），我也会在代码中把每个核心部分的消耗时间打入日志，来判断到底该进行哪里的优化。

运维：主要分三部分，
快速部署：虽然是小公司，但是老板有些资源，所以可以预计上线第一波的压力不小，如果产品良好的情况下压力只能会越来越大，所以要求如果感觉到系统有压力后，需要快速进行横向扩展系统，这里我选用的Puppet，理由很简单：老牌，使用广泛，社区强大。
监控报警：这是运维的眼睛，我选用的zabbix，理由跟上面一样：老牌，使用广泛，社区强大。
日志采集：因为是集群的原因，看日志不方便，最开始是用nfs来收集，后来随着日志越来越分散，日志越来越大，没用多久就被我抛弃了，然后在朋友的推荐下使用ELK进行日志采集和查看。理由只是因为没有别的更好选择（朋友强烈推荐这个，其他的都是没有啥强大社区，这个看着更靠谱点）

㈥ 什么是集群测试干什么用的有什么功能（请用通俗的语言说明）

比如我开发了一个软件，在正式发行前要检测其功能或可预测到的缺点。集群就是让更多的人来用好发现更多的问题。

㈦ 对linux下的一个分布式系统进行测试，报告问题时需要哪些信息

· 在测试执行过程中，对测试结果的分析是一个需要进行深入思考的重点问题。分布式系统测试的重点在于对后端服务器集群的测试，而判定系统中是否存在Bug则是我们需要解决的重要问题。那么应该如何确定是否存在Bug呢？对于测试结果的分析，我们通常观察下面几种情况。
观察前端应用的返回结果。这里需要分两种情况来考虑：第一，按照前端应用业务功能点及流程进行操作，观察返回结果是否符合业务方的需求预期；第二，操作后端的服务器（通常是重启、宕机、断网等操作），观察前端应用的返回结果是否符合系统的设计需求。

㈧ 负载均衡 服务器集群 的一些基础问题

负载均衡有多种方式：对应tcp/ip协议的不同层

可以在应用层做，也可以在网络层或者链路层做

负载均衡主要作用是为了系统的扩展性和高可用性

主要目的并不是为了升级单机的配置

数据一般采取硬件存储，即多个服务器访问同一个存储设备

㈨ 服务器如何实现集群和负载均衡

很多组织机构慢慢的在不同的服务器和地点部署sql
server数据库——为各种应用和目的——开始考虑通过sql
server集群的方式来合并。
将sql
server实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。
当寻找一个备用，比如高可用性的环境，企业常常决定部署microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)sql
server实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。
什么是microsoft集群服务器
mscs是一个windows
server企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。mscs可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。
这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和ip地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。
mscs不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为mscs在相同的ip地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。
在集群服务器上的sql
server
sql
server
2000可以配置为最多4个节点的集群，而sql
server
2005可以配置为最多8个节点的集群。当一个sql
server实例被配置为集群之后，它的磁盘资源、ip地址和服务就形成了集群组来实现灾难恢复。
sql
server
2000允许在一个集群上安装16个实例。根据在线帮助，“sql
server
2005在一个服务器或者处理器上可以支持最多50个sql
server实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”
注意sql
server实例的灾难恢复阶段是指sql
server服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其他的方法，比如log
shipping和数据库镜像。
单个的大的sql
server集群还是小的集群
下面是大的、由更多的节点组成的集群的优点：
◆更高的可用新(更多的节点来灾难恢复)。
◆更多的负载均衡选择(更多的节点)。
◆更低廉的维护成本。
◆增长的敏捷性。多达4个或者8个节点，依赖于sql版本。
◆增强的管理性和简化环境(需要管理的少了)。
◆更少的停机时间(灾难恢复更多的选择)。
◆灾难恢复性能不受集群中的节点数目影响。
下面是单个大的集群的缺点：
◆集群节点数目有限(如果需要第9个节点怎么办)。
◆在集群中sql实例数目有限。
◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。
◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。
虚拟化和集群
虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。sql
server实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装sql
server实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。
在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对sql
server进行负载均衡。比如，使用虚拟机上的sql
server实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。
集群服务器可以用于sql
server的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。

㈩ 软件测试，测试环境搭建需要考虑哪些方面

构建测试环境是软件测试实现的重要阶段，测试环境是否合适将严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境。

硬件环境是指由必要的服务器、客户端、网络连接设备和辅助硬件设备（如打印机／扫描仪）组成的环境。软件环境是指被测软件在运行过程中，由操作系统、数据库等应用软件组成的环境。

(10)后端服务器集群测试需要注意什么扩展阅读：

测试环境的组成部分：

1．需要的计算机数量，以及每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡支持的速度、打印机的类型等。

2．操作系统、数据库管理系统、中间件、WEB服务器以及部署被测应用服务器所需的其他必要组件的名称和版本，以及使用的相关补丁的版本；

3．操作系统、数据库管理系统、中间件、WEB服务器和服务器存储各种测试活动中生成的文档和数据所需的其他必要组件的名称和版本，以及要使用的相关补丁的版本；

4．操作系统、数据库管理系统、中间件、WEB服务器和其他计算机执行测试所需的必要组件的名称和版本，以及要使用的相关补丁的版本；

5．被测应用程序的服务器环境是否需要专用计算机，测试管理服务器环境是否需要备份；

6．网络环境要在测试中使用。例如，如果测试结果与连接到Internet的线路的稳定性有关，则应考虑为测试环境租用单独的线路；如果测试结果与局域网内的网速有关，则应保证计算机的网卡、网线以及所使用的集线器和交换机不会成为瓶颈。