首页手记投稿008期|从软件质量管理谈“踩坑&rd...

投稿008期|从软件质量管理谈“踩坑”的认识

标签：

征文测试

俗话说“前人栽树，后人乘凉”，当今在程序猿群体中也广为流传着“前人挖坑，后人填坑”的故事。那么这次我们就来谈谈软件代码上“踩坑”的那些事。所谓的“踩坑”有部分情况是新接手软件的人发现在他维护的阶段，前人埋下的BUG爆发了；有部分情况是开发中调用了第三方库函数，发现那个库里居然有“坑”；还有很多很多种…

在我看来，软件代码中存在BUG是一件再正常不过的事情了，即使是微软这样的大公司，他们的核心产品windows操作系统也一直需要补丁来修复存在已久的BUG，再比如Linxu发行版中也埋藏着很多“坑”，之前我使用LEDE17.01.4版本时遇到了联发科MT7688芯片的以太网驱动存在网口识别的问题，排查了将近一周时间，最后我是通过更改驱动源码来解决的。这里给各位看下发行版PandoraBox 16.10号称稳定正式版的修改日志，我们可以感受到软件BUG的存在数量之多。

有人会说软件代码经过各种测试怎么还会有BUG呢？这里E.W.Dijkstra的一句名言对测试的不彻底性作了很好的解释：“程序测试只能证明错误的存在，但不能证明错误的不存在”。那么下文中我们会谈到为什么会出现这种情况？

话说软件里面的每个BUG存在的条件都有它的独特性，或是依赖于软件本身代码的逻辑而存在，比如进程中某个堵塞的函数导致另一个函数无法接收信息，或者是外部输入变化而存在，比如配置界面输入了程序无法识别的字符信息…既然每个BUG的存在都不太一样，并且我们也没法完全清除软件的BUG，那么如何保证软件的质量呢？项目管理中质量管理的作用就是保证软件产品的质量可控，再拿微软的windows、linux发行版来说吧，虽然它们的软件一直存在BUG，但是他们的软件质量是处于一种可控的状态。

其实每个公司开展项目都会或多或少的涉及到项目质量管理流程，我在和一些同行聊天的时候了解到，很多公司的项目团队对质量管理的理解存在着误区，比如认为质量管理是应付质量部的检查，补充下质量体系要求的文档就好了，比如认为后面还有测试部门，在进度压力下先完成任务交差，比如认为质量部是不懂业务，只会找茬的对立部门。其实好的产品质量是质量管理过程管出来的，质量管理主要由质量计划、质量保证、质量控制这三个过程组成：
（1）编制质量计划：识别与项目相关的质量标准以及确定如何满足这些标准，确定需要对那些过程和工作产品进行质量管理；
（2）质量保证：所有的有计划地、系统地为保证项目能够满足相关的质量标准而建立的活动，主要是确保过程质量的；
（3）质量控制：采取措施，监督项目的具体实施结果是否符合有关的项目质量标准，并确定消除产品不良结果的原因。

目前国内外比较流行的用于过程改进的模型是CMMI（Capability Maturity Model Integration）能力成熟度集成模型，主要用于帮助企业增强开发能力，能够按时、不超预算地制造出高质量的系统，也就是说它所要达到的过程改进目标有三个，分别为保证产品或服务的质量，控制项目时间，以及用最低的成本。CMMI覆盖了从立项、策划、需求、设计、实现、测试、批量、输出、试用…整个项目的生命周期，它是一个大而全的模型，因此针对特定的软件项目我们可以根据实际情况选择适合本项目的软件生命周期模型，并且对过程活动进行裁剪和优化。软件生命周期模型主要包括瀑布模型、螺旋模型、增量模型、快速原型模型、迭代模型、V型模型等等，不同的模型有它的优点和缺陷，适用于特定的场合，比如迭代模型适用在事先不能完整定义产品所有需求，计划多期开发的项目。在选定的生命周期模型中，我们可以有针对性的选择各种活动来保证软件产品的质量，比如概要设计、详细设计、代码评审、单元测试、集成测试、系统测试、验收测试…像软件测试过程按各测试阶段的先后顺序可分为单元测试、集成测试、确认测试、系统测试和验收测试5个阶段。

接下来我们谈下质量管理活动中很重要的一个环节——“测试”。很多人对软件工程开发的常规认识中，认为开发程序是一个复杂而困难的过程，需要花费大量的人力、物力和时间，而测试一个程序则比较容易，不需要花费太多的精力。这其实是对软件工程开发过程理解上的一个误区。在实际的软件开发过程中，软件测试正扮演着越来越重要的角色。在国外，很多著名企业早已对软件测试工作十分重视。比如著名的微软公司，其软件测试人员与开发人员的比例已经达到2:1。随着软件规模的不断扩大，如何在有限的条件下对被开发软件进行有效的测试正成为软件工程中一个非常关键的课题。因此设计测试用例是一项细致并且需要具备高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。

在实际的软件测试工作中，不论采用什么方法，由于软件测试情况数量极其巨大，都不可能进行完全彻底的测试。所谓彻底测试，就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。由于穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的，也就不能够保证被测试程序在理论上不存在遗留的错误。这也解释了刚才说的“程序测试只能证明错误的存在，但不能证明错误的不存在”。

那么如何把测试数据量巨大的软件测试减少到可以控制的范围，如何针对风险做出最明智的选择是软件测试人员必须能够把握的关键问题。从最优测试量示意图可以观察到，随着测试量的增加，测试成本将呈几何数级上升，而软件缺陷降低到某一数值之后将没有明显的变化，最优测量值就是这两条曲线的交点。