51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3171|回复: 4
打印 上一主题 下一主题

[原创] 打破软件自动化测试的格局

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2019-3-1 16:59:43 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
本帖最后由 草帽路飞UU 于 2019-3-1 17:00 编辑

自动化测试的误区

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

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

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

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


分层与部署带来的问题

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

应用软件也越来越复杂,例如:

  • 分层的变化:界面层,接口曾,业务逻辑曾,实体模型层

  • 部署的变化:从单机运行到双机热备份再到负载均衡,最近进化到分布式系统。

  • 存储的变化:关系型数据库,非关系型数据库,缓存数据库,搜索引擎数据库


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


我们测试要涵盖:

  • CDN测试,域名解析测试,

  • WEB UI测试,包括HTML,Ajax

  • API 服务器测试,api 是非人机交互界面,它是通过特定协议与API服务器交互通信。

  • 代码单元测试

  • 配置测试,配置管理过程中配置变更后的测试,含系统与应用

  • 安全测试,接口安全,认证,权限

  • 注入测试,JS注入,SQL 注入,Shell 注入

  • 缓存测试,命中率测试,包括CDN,WEB服务器,缓存服务器,搜索引擎

  • 压力测试,健壮性测试

  • 扩展性测试,水平扩展测试,垂直扩展测试

  • 高可用测试,集群测试


压力测试存在的问题

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

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

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

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


压力测试环境

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

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

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



测试顺序

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

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

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

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

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



瓶颈分析

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

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

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

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

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



指导开发

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



持续集成形同虚设

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


测试的终极目标

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

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


分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1
回复

使用道具 举报

该用户从未签到

4#
发表于 2019-5-13 11:43:58 | 只看该作者
有成果展示吗?成本和收益比有吗?为什么很多人强调自动化率不易过高?
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2022-4-8 12:30:33 | 只看该作者

有成果展示吗?成本和收益比有吗?为什么很多人强调自动化率不易过高?
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-25 06:57 , Processed in 0.062582 second(s), 22 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表