16. 质量管理

由于周末经常外出自驾游，途中会经过东莞、惠州、观澜、大鹏等工业区，哪里的工厂给过一个很深的印象，每个工厂楼顶会有一个巨大的牌匾“已通过ISO 9001”。这让我开始思考以往的质量管理。

传统劳动密集型产业可以采用考察过程（例如ISO9001），制定产生规范，产生预期结果。这种方法对于资本密集型产业或知识密集型产业并不适合。所以另一种检验结果的质量管理办法孕育而生。

这种管理的方法存在很多弊端，工作中你会遇到下面这些问题：

举一个例子，国家检验奶粉有一个标准，一些不法企业在奶粉中添加三聚氰胺，可以通过检测，最终酿成惨剧。

无论是考察过程的质量管理还是检验结果的质量管理，这两种管理方式仅仅能做出合格的产品，无法做出精品。

丰田公司的一位高级管理人员说：“我们不应使用全面质量管理，因为这种管理充其量只能让缺点减至10%。如果我们生产400万辆汽车的话，便会有40万人购得一辆带毛病的车，这是生产与用户之间的最大危机，而推行无缺点管理则会消除这种现象。”现在，领先的日本公司逐渐由全面质量管理转向无缺点管理。

无缺点管理的范围已经超出了产品质量范畴

软件压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。软件压力测试的基本思路很简单： 不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。 通常要进行软件压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽。

压力测试涵盖，性能测试，负载测试，并发测试等等，这些测试点常常交织耦合在一起。

如果在软件设计阶段都将这些问题元素都考虑进去，同时开发阶段严格执行。那么开发出些软件几乎不用做这个劳人伤神的压力测试。

所以在软件设计阶段就要考虑，灵活性，扩展性，可靠性与性能，还要考虑高可用与负载均衡。

同时软件优化伴随开发，持续集成，持续测试，持续部署。

有些软件需要封闭的环境测试，不能在共享资源的环境中做测试。所以你有必要做Vlan隔离，甚至独立的路由器与交换机在封闭网络中测试。

任何时间都可能做压力测试，为什么我将“时间”重点提出呢？目前受地球自转影响，经常闰秒，你不的不考虑这个问题。

下面我们举一些例子，讲述压力测试方法，限于篇幅不可能面面俱到，我仅仅是给你提供思路。

测试前你需要一些监控工具，事实监控服务器的资源变化。

例如 Web 服务器压力测试，测试场景是 nginx ：

    
    worker_processes  8;            处理器数
    worker_rlimit_nofile 65530;     允许最多打开文件数
    worker_connections  4096;       最大连接数数为
    keepalive_timeout  65;          开启复用连接
    gzip  on;                       压缩传输数据
    
			

怎么测试呢？你要活得最大化性能吗？还是相对性能？我们通常需要的是满足需求就好的相对性能，而不是最大化性能。为什么呢？因为要活得最大化性能是要做出很多配置牺牲的，例如关闭日志，禁止访问时间等等。

按照上面的配置你的测试用例应该是，每次并发4000 请求 8000~10000 次， 你不能并发8000 请求 4000 这样测试。很是很多人常常犯的错误，所以测试者需要连接系统的配置参数，不能盲目使用数字实验。

上面我说过线程的开启时随着请求，逐渐增加的，所以首次发起测试数据是不准确的，通过pstree命令可以看到线程数量。等第三次以后线程逐渐增加到4096个，并且之前开启的TCP可以复用，这时测试的结果比较有说服力。

延伸阅读《Netkiller Web 手札》《Netkiller Testing 手札》《Netkiller Linux 手札》

自动化测试仅仅被认为是替代人工，所以我们看到很多企业实施自动化测试仅仅是将现有的 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服务器->缓存->数据库，中间会经过各种代理，负载均衡，分布式文件系统等等。

我们测试要涵盖：

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

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

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

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

      
\------------------/
 \    Web server  /
  \   App Server /
   \ Cache / MQ /
    \ Database /
     \ Disk IO/
      \      /
      
				

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

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

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

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

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