请首先阅读:
一步步实施 DevOps (一)
为什么自动化测试难以推广
2005 第一次接触自动化测试,十年已经过去了,着眼身边的企业,真正实施自动化测试的企业非常少。 大部分企业,测试仍然处在,点鼠标阶段。测试人员通常是验收交付,而没有参与整个软件开发周期。
为什么自动化测试难以实施
为什么自动化测试难以实施,我想有几个问题,阻碍了自动测试普及。 其实懂得自动化测试工具的人还是很多的,自动化测试难以实施,并不是缺乏技术人才。Load Runner, QTP 等等很多测试人员都会使用,为什么他们放弃这些工具,改用手动测试呢?
- 90%测试仍然处在功能测试
- 很多测试人员没有开发背景
- 测试角色,没有贯穿整个软件开发周期
- 各种问题阻碍了自动化脚本
- 在中国测试人员人力成本太低
随着技术发展,软件的多样性,已经不局限于基于CS结构的GUI, 基于BS浏览器WEB UI。例如目前的安卓系统,苹果IOS系统,微软的 Windows Mobile 系统等等。 还有一些非人机交互界面,各种协议/接口,例如json,bson,xml-rpc,soap,mq(message queue)我认为这些都应该纳入自动化测试范畴。 这就需要测试人员具有一定的开发能力,且测试上述内容速要广泛的技术知识支撑。
我认为高级测试工程师,需要具备以下能力
- 嗅探器使用
- gdb 使用
- 了解各种协议族
- 渗透于注入
- HTML/CSS/Javascript
- 数据库 等等
就WEB测试而言,涉及的内容就太广泛了,从浏览器->WEB服务器->APP服务器->缓存->数据库,中间会经过各种代理,负载均衡,分布式文件系统等等。
配置这样一个测试环境都已经非常不容易,幸好我们可以采用自动化运维干这件事。
是什么阻碍了自动化测试
- 各种UI特效
- 验证码
- 浏览器支持
- 第三方插件(Flash,ActiveX...)
- 技术封闭
互联网的快速发展 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 系统等等也加入到自动化测试领域。
应用软件也越来越复杂,例如:
- 分层的变化:界面层,接口曾,业务逻辑曾,实体模型层
- 部署的变化:从单机运行到双机热备份再到负载均衡,最近进化到分布式系统。
- 存储的变化:关系型数据库,非关系型数据库,缓存数据库,搜索引擎数据库
从下面的金字塔架构可以看出软件展示给用户的只有UI界面层
/\ / \ / UI \ /------\ / API \ /----------\ / Service \ /--------------\ / Component \ /------------------\ / Database \ /______________________\
上面是软件的分层,一个软件经过部署后结构将会更复杂。
/\
/ \
/CDN \
/------\
/ WEB SER\
/----------\
/ APP Server \
/--------------\
/ Message Queue \
/------------------\
/ Cache|SearchEngine \
/ Database| NoSQL \
/________________________\
就WEB应用测试而言,涉及的内容就太广泛了,从浏览器->WEB服务器->APP服务器->缓存->数据库,中间会经过各种代理,负载均衡,分布式文件系统等等。
我们测试要涵盖:
- CDN测试,域名解析测试,
- WEB UI测试,包括HTML,Ajax
- API 服务器测试,api 是非人机交互界面,它是通过特定协议与API服务器交互通信。
- 代码单元测试
- 配置测试,配置管理过程中配置变更后的测试,含系统与应用
- 安全测试,接口安全,认证,权限
- 注入测试,JS注入,SQL 注入,Shell 注入
- 缓存测试,命中率测试,包括CDN,WEB服务器,缓存服务器,搜索引擎
- 压力测试,健壮性测试
- 扩展性测试,水平扩展测试,垂直扩展测试
- 高可用测试,集群测试
压力测试存在的问题
请参考我的另一篇文章《压力测试中存在的问题》
这里我要再单独强调压力测试,很多人的测试方法是有问题的。
压力测试不是准备一台机器安装压力测试软件就可以开始测试的。 压力测试的环境非常重要,很多工作多年的测试人员都没有意识到这个问题。
压力测试有两个重点,一是压力测试环境的建设,二是压力测试顺序。
压力测试环境
压力测试无论是单机还是网络,都需要一个好的压力测试环境,例如网络好比高速公路,如果公路成为瓶颈,你能测试出准确的数据吗?
首先准备测试环境,如单机测试要考虑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. 压力测试存在那些问题
我归纳一下又几点:
- 操作系统默认安装,在未做任何优化的情况下实施压力测试
- 未考虑磁盘IO对软件的影响
- 未考虑网络带宽对软件的影响
- 网络软件测试,没有考虑到TCP特点
- 各种超时参数优化
- 测试客户端未优化
- 并发理解有误
- WEB服务器,数据库,等等服务器未优化
如果上面几项没有做优化,压力测试数据基本没有任何参考价值,任何一项没有优化,都会导致你的压力测试数据出现偏差。 下面我来逐条说明:
- 操作系统问题 操作系统是大众化软件,出厂优化都是面向大众,不可能为某个领域做单独优化。所以我们第一步需要优化操作系统。 Linux 系统优化内核参数,Windows 系统优化注册表等等。
- 磁盘IO 这是最容易出现瓶颈的地方,常常是CPU还没有达到极限,磁盘已经不堪重负。
- 网络IO 与磁盘IO相同
- TCP连接 几乎所有 B/S, C/S 软件都是采用多线程,或者多进程技术。这种技术有个特点,开发者将程序设计为线程可自动伸缩模式,开启进程后会启动少量线程,当连接不断提高后,线程数逐渐增加,随着线程运行结束后,线程逐渐减少。 这样的设计会更有效地利用硬件资源,在程序空闲时将硬件资源让给其他进程。少有软件设计为开启服务独占资源。 这样测试软件做压力测试,不能一次并发很多请求,而是要采用逐渐增加的方式,否则第一次测试会有一部们并发不能及时响应,导致测试数据偏差。另外也你可以多做几次压力请求(让多线程工作起来),从第三次开始记录测试数据,忽律前面两次的测试数据。
提示:另一个问题是TCP连接复用,这也是一个重要配置项。如果这项没有配置,我想测试出的数据也会有偏差
- 超时参数 超时参数在压力测试中是非常重要的参数,例如从WEB到数据库连接超时是60秒,如果有一个SQL查询超过300秒,那么后面的请求会持续排队等待,当连接数达到数据库的最大连接时,接下来的所有请求都是失败的。 通常我们的WEB服务器超时不会超过30秒,有时我设置为10秒,一旦出现超时,宁可让该连接Timeout,不要让他影响整体服务。
- 客户端 很多网络软件需要从客户端发出压力测试请求,所以客户端的优化也是必须的,否则客户端压力出不去,服务端压力进不来。
- 并发 很多人认为并发,就是同一时间内的最大连接数,这是错误的。如果你写过多线程程序,就会发现多线程运行时又规律的。是顺序排队运行的,根本不是同时运行的。 所以并发是指,相对时间内能完成的连接总和,例如,每秒并发,每分钟并发等等,通常我们已秒为单位。 我们目前使用的操作系统叫分时操作系统,这种系统的特点就是可能实现多用户,多任务。操作系统将进程排队(优先级)轮询运行,只不过这个操作太快了,使你认为多个进程在同时运行。
- 服务器优化 主要B/S软件压力测试,WEB,缓存,数据库等等服务器,都需要逐一优化到最佳状态
(Why) 为什么做压力测试
如果在软件设计阶段都将这些问题元素都考虑进去,同时开发阶段严格执行。那么开发出些软件几乎不用做这个劳人伤神的压力测试。
所以在软件设计阶段就要考虑,灵活性,扩展性,可靠性与性能,还要考虑高可用与负载均衡。
同时软件优化伴随开发,持续集成,持续测试,持续部署。
(Where) 在哪里做压力测试
有些软件需要封闭的环境测试,不能在共享资源的环境中做测试。所以你有必要做Vlan隔离,甚至独立的路由器与交换机在封闭网络中测试。
(When) 什么时间做压力测试
任何时间都可能做压力测试,为什么我将“时间”重点提出呢?目前受地球自转影响,经常闰秒,你不的不考虑这个问题。
(Who) 压力测试过程参与人员
- 运维部门
- 开发部门
- 测试部门
(How) 如何做压力测试
下面我们举一些例子,讲述压力测试方法,限于篇幅不可能面面俱到,我仅仅是给你提供思路。
测试前你需要一些监控工具,事实监控服务器的资源变化。
例如 Web 服务器压力测试,测试场景是 nginx :
怎么测试呢?你要活得最大化性能吗?还是相对性能?我们通常需要的是满足需求就好的相对性能,而不是最大化性能。为什么呢?因为要活得最大化性能是要做出很多配置牺牲的,例如关闭日志,禁止访问时间等等。
按照上面的配置你的测试用例应该是,每次并发4000 请求 8000~10000 次, 你不能并发8000 请求 4000 这样测试。很是很多人常常犯的错误,所以测试者需要连接系统的配置参数,不能盲目使用数字实验。
上面我说过线程的开启时随着请求,逐渐增加的,所以首次发起测试数据是不准确的,通过pstree命令可以看到线程数量。等第三次以后线程逐渐增加到4096个,并且之前开启的TCP可以复用,这时测试的结果比较有说服力。
延伸阅读《Netkiller Web 手札》《Netkiller Testing 手札》《Netkiller Linux 手札》
版权声明
转载请与作者联系,转载时请务必标明文章原始出处和作者信息及本声明。