打破软件自动化测试的格局
2018-03-08 08:46 zouhui 阅读(114) 评论(0) 编辑 收藏 举报打破软件自动化测试的格局
自动化测试的误区
自动化测试仅仅被认为是替代人工,所以我们看到很多企业实施自动化测试仅仅是将现有的 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地址和数据包等等。
指导开发
通过数据,图表,快速定位软件存在的问题点,指导开发完成软件的改进
持续集成形同虚设
持续集成,自动化构建几乎么个测试团队都会实施,但实际境况并不理想,仅仅停留在工具配置的阶段。几乎没有人在生产环境上使用自动化构建。
为什么持续集成无法应用到生产环境?
(待续,敬请关注作者微信公众号,现在已经是早上6点中了,要去睡觉了)
测试的终极目标
我认为测试不仅仅是完成按照测试用例完成软件验收,如果仅仅测试用户可见的UI(人机接口)是不能满足现代软件的测试需求的。
测试者应该站在更高的角度看问题,测试者是有能力指导开发人员,改善软件的性能,健壮性,安全性,以及影响软件架构的设计。 测试者需要有广泛的跨界知识支撑,要不断学习提高,打破现有格局。
2016-12-03 06:30 AM
原文发布于微信公众号 - Netkiller(netkiller-ebook)
原文发表时间:2016-12-05
转载链接:https://cloud.tencent.com/developer/article/1051411