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

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

自动化测试的误区

自动化测试仅仅被认为是替代人工,所以我们看到很多企业实施自动化测试仅仅是将现有的 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地址和数据包等等。

指导开发

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

持续集成形同虚设

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

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

(待续,敬请关注作者微信公众号,现在已经是早上6点中了,要去睡觉了)

测试的终极目标

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

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

2016-12-03 06:30 AM

原文发布于微信公众号 - Netkiller(netkiller-ebook)

原文发表时间:2016-12-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT笔记

关于架构优化和设计,架构师必须知道的事情

近几年来随着互联网的飞速发展,新的架构实践方式不断涌现,但是有一件事情是永恒不变的,那就是-“架构之道”;关于如何设计出灵活、高可用性以及能够快速适应变化的系统...

3427
来自专栏恰同学骚年

《大型网站技术架构》读书笔记二:大型网站架构模式

此篇已收录至《大型网站技术架构》读书笔记系列目录贴,点击访问该目录可获取更多内容。

612
来自专栏逸鹏说道

数据库高可用实战案例

原文链接:http://www.cnblogs.com/double-K/p/5803956.html 说到高可用,看官们会想到很多方案,也许是自亲身经历过系统...

3177
来自专栏JAVA烂猪皮

分布式、服务化的ERP系统架构设计

曾几何时,我混迹于电商、珠宝行业4年多,为这两个行业开发过两套大型业务系统(ERP)。作为一个ERP系统,系统主要功能模块无非是订单管理、商品管理、生产采购、仓...

351
来自专栏存储

建设分布&服务ERP系统

纯手工打造每一篇开源资讯与技术干货,数十万程序员和Linuxer已经关注。 曾几何时,我混迹于电商、珠宝行业4年多,为这两个行业开发过两套大型业务系统(ERP...

2345
来自专栏鬼谷君

运维与自动化运维发展概括

1444
来自专栏about云

Hadoop 2.x与3.x 22点比较:3.x将节省大量存储空间

1.Hadoop3.x通过什么方式来容错? 2.Hadoop3.x存储开销减少了多少? 3.Hadoop3.x MR API是否兼容hadoop1.x?

1122
来自专栏运维平台规划

巧妙的CMDB设计,减少告警对运维的轰炸

本文主要介绍运维CMDB的设计思路,恰当的CMDB设计,对运维效率的提升,如收敛告警和故障自愈等,有着意向不到的效果。

2444
来自专栏云计算爱好者

云计算技术原理

由于云计算分为IaaS、PaaS和SaaS三种类型,不同的厂家又提供了不同的解决方案,目前还没有一个统一的技术体系结构,对读者了解云计算的原理构成...

2319
来自专栏DevOps时代的专栏

干货 | 基于 DevOps 的微服务生态系统与工程实践(三)

往期回顾: 第一部分:微服务与 DevOps 干货 | 基于 DevOps 的微服务生态系统与工程实践(一) 第二部分:微服务生态系统 干货 | 基于 Dev...

18110

扫码关注云+社区