一步步实施 DevOps （二）

时间  2019-11-11
标签 步步 实施 devops 繁體版
原文   原文链接

Netkiller Management 手札

 

Mr. Neo Chan, 陈景峯(BG7NYT)



中国广东省深圳市望海路半岛城邦三期
518067
+86 13113668890

<netkiller@msn.com>nginx

Copyright © 2010-2018 netkillergit

 

版权声明程序员

转载请与做者联系，转载时请务必标明文章原始出处和做者信息及本声明。github
http://www.netkiller.cn
http://netkiller.github.io
http://netkiller.sourceforge.net
微信订阅号 netkiller-ebook (微信扫描二维码）
QQ：13721218 请注明“读者”
QQ群：128659835 请注明“读者”

 

请首先阅读：数据库

一步步实施 DevOps （一）json

为何自动化测试难以推广

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

为何自动化测试难以实施

为何自动化测试难以实施，我想有几个问题，阻碍了自动测试普及。 其实懂得自动化测试工具的人仍是不少的，自动化测试难以实施，并非缺少技术人才。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 ：

worker_processes  8;            处理器数
    worker_rlimit_nofile 65530;     容许最多打开文件数
    worker_connections  4096;       最大链接数数为
    keepalive_timeout  65;          开启复用链接
    gzip  on;                       压缩传输数据

怎么测试呢？你要活得最大化性能吗？仍是相对性能？咱们一般须要的是知足需求就好的相对性能，而不是最大化性能。为何呢？由于要活得最大化性能是要作出不少配置牺牲的，例如关闭日志，禁止访问时间等等。

按照上面的配置你的测试用例应该是，每次并发4000 请求 8000~10000 次， 你不能并发8000 请求 4000 这样测试。非常不少人经常犯的错误，因此测试者须要链接系统的配置参数，不能盲目使用数字实验。

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

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

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程