打破软件自动化测试的格局
作者：netkiller （景峰）, 微信公众号netkiller-ebook , 个人网站http://www.netkiller.cn
自动化测试的误区
自动化测试仅仅被认为是替代人工，所以我们看到很多企业实施自动化测试仅仅是将现有的 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通道的问题......等等
如果是测试分布式系统，除了上述单节点的注意事项，还要考虑到路由器/防火墙的包转发与连接数限制，交换机的背板带宽以及吞吐能力，负载均衡器的转发能力。
测试顺序
压力测试顺序的切入点非常重要，测试顺序上多数人是从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