一步步实施 DevOps （二）

2021-12-02 00:26:42

请首先阅读：

一步步实施 DevOps （一）

为什么自动化测试难以推广

2005 第一次接触自动化测试，十年已经过去了，着眼身边的企业，真正实施自动化测试的企业非常少。 大部分企业，测试仍然处在，点鼠标阶段。测试人员通常是验收交付，而没有参与整个软件开发周期。

为什么自动化测试难以实施

为什么自动化测试难以实施，我想有几个问题，阻碍了自动测试普及。 其实懂得自动化测试工具的人还是很多的，自动化测试难以实施，并不是缺乏技术人才。Load Runner, QTP 等等很多测试人员都会使用，为什么他们放弃这些工具，改用手动测试呢？

  1. 90%测试仍然处在功能测试
  2. 很多测试人员没有开发背景
  3. 测试角色，没有贯穿整个软件开发周期
  4. 各种问题阻碍了自动化脚本
  5. 在中国测试人员人力成本太低

随着技术发展，软件的多样性，已经不局限于基于CS结构的GUI, 基于BS浏览器WEB UI。例如目前的安卓系统，苹果IOS系统，微软的 Windows Mobile 系统等等。 还有一些非人机交互界面，各种协议/接口，例如json,bson,xml-rpc,soap,mq(message queue)我认为这些都应该纳入自动化测试范畴。 这就需要测试人员具有一定的开发能力，且测试上述内容速要广泛的技术知识支撑。

我认为高级测试工程师，需要具备以下能力

  1. 嗅探器使用
  2. gdb 使用
  3. 了解各种协议族
  4. 渗透于注入
  5. HTML/CSS/Javascript
  6. 数据库 等等

就WEB测试而言，涉及的内容就太广泛了，从浏览器->WEB服务器->APP服务器->缓存->数据库，中间会经过各种代理，负载均衡，分布式文件系统等等。

配置这样一个测试环境都已经非常不容易，幸好我们可以采用自动化运维干这件事。

是什么阻碍了自动化测试

  1. 各种UI特效
  2. 验证码
  3. 浏览器支持
  4. 第三方插件(Flash,ActiveX...)
  5. 技术封闭

互联网的快速发展 Load Runner, QTP 等等软件，我认为已经跟不互联网的快速了，他们仍然按照传统周期发布软件更新。 而互联网需要的是快速变化，互联网应用程序开发者，需要体验更多的创新功能，软件软件发布周期至少一年一个版本。真的太慢了。

互联网不断加入的新技术成为了自动化测试障碍，传统软件无法支持这些新技术，甚至向微软这样的企业技术跟进都显得不给力。

Windows Automation 3.0 是非常高大上玩意，但是你在Microsoft官网能找到的资料，少之甚少，我不知道微软的目的何在。

只有 Load Runner, QTP 这些功能与微软又合作，才能拿到Windows Automation API。

中国测试人员的人力成本

测试人员的薪水在开发团队中应该是处于中下等的。与高级程序员，软件架构师是有很大差距的。这也造成了自动化测试难以实施的原因。

我们需要从高级程序员，软件架构师转测试的高级测试人员。

我们需要黑客级的测试人员！！！

打破软件自动化测试的格局

自动化测试的误区

自动化测试仅仅被认为是替代人工，所以我们看到很多企业实施自动化测试仅仅是将现有的 Test Case 转换成自动化脚本。

这样做既没有提高测试整体水平，也没有改善测试结果。结果是通过手工能测试出来的问题自动化测试可以测试出来，手工测试不出来的问题自动化测试也没有测试出来。

因为测试的观念仍停留在已有 Test Case 阶段，而 Test Case 停留在业务流程测试的阶段。

最终自动化测试仅仅是按照测试用例走一边业务流程，完成业务流程的检验。

分层与部署带来的问题

随着技术发展，软件的多样性，测试已经不局限于基于CS结构的GUI测试, 基于BS浏览器WEB UI测试。例如目前的安卓系统，苹果IOS系统，微软的 Windows Mobile 系统等等也加入到自动化测试领域。

应用软件也越来越复杂，例如：

  1. 分层的变化：界面层，接口曾，业务逻辑曾，实体模型层
  2. 部署的变化：从单机运行到双机热备份再到负载均衡，最近进化到分布式系统。
  3. 存储的变化：关系型数据库，非关系型数据库，缓存数据库，搜索引擎数据库

从下面的金字塔架构可以看出软件展示给用户的只有UI界面层

            /\
           /  \
          / UI \
         /------\
        /   API  \
       /----------\
      /   Service  \     
     /--------------\
    /    Component   \
   /------------------\  
  /      Database      \
 /______________________\

上面是软件的分层，一个软件经过部署后结构将会更复杂。

            /\
           /  \
          /CDN \
         /------\
        / WEB SER\
       /----------\
      / APP Server \     
     /--------------\
    / Message Queue  \
   /------------------\  
  / Cache|SearchEngine \
 /   Database| NoSQL    \ 
/________________________\

就WEB应用测试而言，涉及的内容就太广泛了，从浏览器->WEB服务器->APP服务器->缓存->数据库，中间会经过各种代理，负载均衡，分布式文件系统等等。

我们测试要涵盖：

  1. CDN测试，域名解析测试，
  2. WEB UI测试，包括HTML,Ajax
  3. API 服务器测试，api 是非人机交互界面，它是通过特定协议与API服务器交互通信。
  4. 代码单元测试
  5. 配置测试，配置管理过程中配置变更后的测试，含系统与应用
  6. 安全测试，接口安全，认证，权限
  7. 注入测试，JS注入，SQL 注入，Shell 注入
  8. 缓存测试，命中率测试，包括CDN，WEB服务器，缓存服务器，搜索引擎
  9. 压力测试，健壮性测试
  10. 扩展性测试，水平扩展测试，垂直扩展测试
  11. 高可用测试，集群测试

 压力测试存在的问题

请参考我的另一篇文章《压力测试中存在的问题》

这里我要再单独强调压力测试，很多人的测试方法是有问题的。

压力测试不是准备一台机器安装压力测试软件就可以开始测试的。 压力测试的环境非常重要，很多工作多年的测试人员都没有意识到这个问题。

压力测试有两个重点，一是压力测试环境的建设，二是压力测试顺序。

 压力测试环境

压力测试无论是单机还是网络，都需要一个好的压力测试环境，例如网络好比高速公路，如果公路成为瓶颈，你能测试出准确的数据吗？

首先准备测试环境，如单机测试要考虑CPU速度，磁盘IO速度，RAID卡的速度，RAID卡缓存大小，内存速度，PCI—E总线速度，甚至会涉及多对称CPU相关配置，内存与CPU通道的问题......等等

如果是测试分布式系统，除了上述单节点的注意事项，还要考虑到路由器/防火墙的包转发与连接数限制，交换机的背板带宽以及吞吐能力，负载均衡器的转发能力。

操作系统要考虑内核参数优化，TCP/IP栈优化，各种服务器的配置。

 测试顺序

压力测试顺序的切入点非常重要，测试顺序上多数人是从UI（人机界面）切入，即由UI驱动业务逻辑，这种测试顺序是错误的，例如用户->浏览器->WEB服务器->APP服务器->缓存->数据库等等，这就带来很多问题。

\------------------/
 \    Web server  /
  \   App Server /
   \ Cache / MQ /
    \ Database /
     \ Disk IO/
      \      /

软件的性能平静通常是沙漏型的，最大的瓶颈莫过于数据库，其他服务器的瓶颈我们都能从架构的角度去解决性能问题。

所有我们应该先从数据库测试，首先确认数据库的配置优化是否能达到我们预期值。然后是缓存，消息队列，搜索引擎等等.....

至此我们已经知道数据库，缓存，消息队列，搜索引擎不会成为我们压力测试中的瓶颈。接下就可以测试应用服务器和应用软件了。

如果你的测试格局能够放大一点要考虑的远不止上述那些。 你还需考虑硬件，网络，操作内核参数优化，TCP/IP栈优化，验证运维配置是否能满足我们需求等等.....。

瓶颈分析

我们需要有一套监控解决方案，能够监控到硬件的性能，软件的性能。

测试目的不是为了得出一个结果，告诉开发人员你的软件能支撑XXX并发，而是在我们测试中监控每项操作，计算出每个功能所用的时间，分析出性能的平静，指导开发人员改进软件。

监控分为外部监控与内部监控。

外部监控是最容易实现的，有成熟的工具以及解决方案，CPU,内存，磁盘IO，网络流量等等。

内部监控是指软件运行加载到内存中之后的变化状态，例如内存地址，变量，函数调用，动态链接库载入，打开文件句柄，Socket地址和数据包等等。

指导开发

通过数据，图表，快速定位软件存在的问题点，指导开发完成软件的改进

持续集成形同虚设

持续集成，自动化构建几乎么个测试团队都会实施，但实际境况并不理想，仅仅停留在工具配置的阶段。几乎没有人在生产环境上使用自动化构建。

为什么持续集成无法应用到生产环境？

测试的终极目标

我认为测试不仅仅是完成按照测试用例完成软件验收，如果仅仅测试用户可见的UI(人机接口)是不能满足现代软件的测试需求的。

测试者应该站在更高的角度看问题，测试者是有能力指导开发人员，改善软件的性能，健壮性，安全性，以及影响软件架构的设计。 测试者需要有广泛的跨界知识支撑，要不断学习提高，打破现有格局。

压力测试中存在的问题

 (What) 什么是压力测试

软件压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。软件压力测试的基本思路很简单： 不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。 通常要进行软件压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽。

压力测试涵盖，性能测试，负载测试，并发测试等等，这些测试点常常交织耦合在一起。

30.2.1.1. 压力测试存在那些问题

我归纳一下又几点：

  1. 操作系统默认安装，在未做任何优化的情况下实施压力测试
  2. 未考虑磁盘IO对软件的影响
  3. 未考虑网络带宽对软件的影响
  4. 网络软件测试，没有考虑到TCP特点
  5. 各种超时参数优化
  6. 测试客户端未优化
  7. 并发理解有误
  8. WEB服务器，数据库，等等服务器未优化

如果上面几项没有做优化，压力测试数据基本没有任何参考价值，任何一项没有优化，都会导致你的压力测试数据出现偏差。 下面我来逐条说明：

  1. 操作系统问题 操作系统是大众化软件，出厂优化都是面向大众，不可能为某个领域做单独优化。所以我们第一步需要优化操作系统。 Linux 系统优化内核参数，Windows 系统优化注册表等等。
  2. 磁盘IO 这是最容易出现瓶颈的地方，常常是CPU还没有达到极限，磁盘已经不堪重负。
  3. 网络IO 与磁盘IO相同
  4. TCP连接 几乎所有 B/S, C/S 软件都是采用多线程，或者多进程技术。这种技术有个特点，开发者将程序设计为线程可自动伸缩模式，开启进程后会启动少量线程，当连接不断提高后，线程数逐渐增加，随着线程运行结束后，线程逐渐减少。 这样的设计会更有效地利用硬件资源，在程序空闲时将硬件资源让给其他进程。少有软件设计为开启服务独占资源。 这样测试软件做压力测试，不能一次并发很多请求，而是要采用逐渐增加的方式，否则第一次测试会有一部们并发不能及时响应，导致测试数据偏差。另外也你可以多做几次压力请求（让多线程工作起来），从第三次开始记录测试数据，忽律前面两次的测试数据。

提示：另一个问题是TCP连接复用，这也是一个重要配置项。如果这项没有配置，我想测试出的数据也会有偏差

  1. 超时参数 超时参数在压力测试中是非常重要的参数，例如从WEB到数据库连接超时是60秒，如果有一个SQL查询超过300秒，那么后面的请求会持续排队等待，当连接数达到数据库的最大连接时，接下来的所有请求都是失败的。 通常我们的WEB服务器超时不会超过30秒，有时我设置为10秒，一旦出现超时，宁可让该连接Timeout，不要让他影响整体服务。
  2. 客户端 很多网络软件需要从客户端发出压力测试请求，所以客户端的优化也是必须的，否则客户端压力出不去，服务端压力进不来。
  3. 并发 很多人认为并发，就是同一时间内的最大连接数，这是错误的。如果你写过多线程程序，就会发现多线程运行时又规律的。是顺序排队运行的，根本不是同时运行的。 所以并发是指，相对时间内能完成的连接总和，例如，每秒并发，每分钟并发等等，通常我们已秒为单位。 我们目前使用的操作系统叫分时操作系统，这种系统的特点就是可能实现多用户，多任务。操作系统将进程排队（优先级）轮询运行，只不过这个操作太快了，使你认为多个进程在同时运行。
  4. 服务器优化 主要B/S软件压力测试，WEB，缓存，数据库等等服务器，都需要逐一优化到最佳状态

 (Why) 为什么做压力测试

如果在软件设计阶段都将这些问题元素都考虑进去，同时开发阶段严格执行。那么开发出些软件几乎不用做这个劳人伤神的压力测试。

所以在软件设计阶段就要考虑，灵活性，扩展性，可靠性与性能，还要考虑高可用与负载均衡。

同时软件优化伴随开发，持续集成，持续测试，持续部署。

 (Where) 在哪里做压力测试

有些软件需要封闭的环境测试，不能在共享资源的环境中做测试。所以你有必要做Vlan隔离，甚至独立的路由器与交换机在封闭网络中测试。

(When) 什么时间做压力测试

任何时间都可能做压力测试，为什么我将“时间”重点提出呢？目前受地球自转影响，经常闰秒，你不的不考虑这个问题。

(Who) 压力测试过程参与人员

  1. 运维部门
  2. 开发部门
  3. 测试部门

 (How) 如何做压力测试

下面我们举一些例子，讲述压力测试方法，限于篇幅不可能面面俱到，我仅仅是给你提供思路。

测试前你需要一些监控工具，事实监控服务器的资源变化。

例如 Web 服务器压力测试，测试场景是 nginx ：

怎么测试呢？你要活得最大化性能吗？还是相对性能？我们通常需要的是满足需求就好的相对性能，而不是最大化性能。为什么呢？因为要活得最大化性能是要做出很多配置牺牲的，例如关闭日志，禁止访问时间等等。

按照上面的配置你的测试用例应该是，每次并发4000 请求 8000~10000 次， 你不能并发8000 请求 4000 这样测试。很是很多人常常犯的错误，所以测试者需要连接系统的配置参数，不能盲目使用数字实验。

上面我说过线程的开启时随着请求，逐渐增加的，所以首次发起测试数据是不准确的，通过pstree命令可以看到线程数量。等第三次以后线程逐渐增加到4096个，并且之前开启的TCP可以复用，这时测试的结果比较有说服力。

延伸阅读《Netkiller Web 手札》《Netkiller Testing 手札》《Netkiller Linux 手札》

版权声明

转载请与作者联系，转载时请务必标明文章原始出处和作者信息及本声明。


上一篇：【读书笔记《Bootstrap 实战》】1.初识Bootstrap


下一篇：三款典型国产分布式数据库的对比评测