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

 

自动化测试的误区

自动化测试仅仅被认为是替代人工，所以我们看到很多企业实施自动化测试仅仅是将现有的 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通道的问题......等等

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

测试顺序

压力测试顺序的切入点非常重要，测试顺序上多数人是从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