从CT技术想到的软件测试

年前的时候被体内一颗短径4.8mm的小石头折磨，还提前休了几天病假，并第一次被要求去做了个CT。第二天拿到了报告，完全看不懂，咨询了当外科医生的高中好友，他打了一个简单又有点恶心的比方，就像在自助餐厅里服务员拿一大块牛肉用机器切成几毫米的薄片，每一张图就是一片。嗯，话糙理不糙，大概懂了。

因为好奇，后来在网上查了下CT相关的技术，觉得很有意思，有兴趣的可以看看。

http://zh.wikipedia.org/wiki/CT

http://wenku.baidu.com/view/0e4fa922bcd126fff7050bc5.html

这篇文章也比较适合于技术爱好者

http://yx.yangning.net/showtopic-627.aspx

CT涉及到很多计算机图形学的东西，或者可以说没有计算机技术的发展，CT技术也很难实用。CT现在已经变成了一种标准的医学检测手段，不过做一次价格还是不菲，要好几百。

联想到自己一直从事的软件测试工作，觉得有很多的启发。

姑且我们把检测作为测试的一个部分，简单来说其目的大致有两类。

- 检查有没有问题，比如体检

- 试图确定问题在哪儿，比如不舒服之后去做某些项目的检查

其实我们的测试工作很多时候也是做这样的事情。拿到一个新的版本或者改动，去检查有没有问题，觉得有些地方不太对劲的时候，试图去获得更多信息来帮助判断问题可能出在哪里。

和软件测试一样， CT并没有直接的改变被测对象，问题还是在哪里；另一方面，它也没有直接给出如何修复或者说是治疗的方法。但是它们有一个共同点，那就是能发现问题，并且提供有价值的信息！

当然，做到这些还有一些重要的前提，比如：

1. 结果的准确性。

这一点毋庸置疑，错误的结果会误导，甚至延误重要的时机。这个也是一项新技术出现的根本。

2. 侵入性

一项测试手段对被测的对象的影响。这也是CT技术超越动脉造影、气脑造影、开颅探查等传统检测手段的一个重要原因，它对人体的伤害和影响要小很多，当然X光本身也是有伤害的，只不过不常做的话影响不是很大。

对于软件测试也是一样，如果一项测试技术会干扰到产品本身的运行，就会影响到测试的效果或者适用范围。例如coverage test是一个很好的帮助测试人员判断测试的范围和程度的手段，但是因为它比较具有侵入性，不仅是影响性能，有时甚至会影响到功能，所以使用受到限制，一般也不会放入production的代码中。

3. 检测的速度和效率

在前面关于CT的文章中也可以看到，从第一代的机器到后面的改进，很重要的一个指标就是扫描的速度，这其实也是检测的效率的问题。能及时的判断有没有问题或者发现问题是很重要的，对于软件测试也是一样，特别是对于互联网产品，发布的周期非常短，很多产品平均每周都有好几次发布，如果一项测试需要花到几天的事情，基本就很难广泛使用。而速度和效率很多时候需要依靠新的更先进的技术。比如CT的扫描速度的依赖于更多的探测器和更强的计算机处理能力。

4. 成本

成本也是一个很重要的因素，因为太昂贵的东西难以普及。可以参见上面第三个link中CT早期因为成本也是一个政治话题。成本包括很多方面，初次购买设备、运营维护（耗材，电力等）、工作人员的成本。对于一个新的测试手段也是，需要的工具和平台（软硬件）、初次开发的成本、日常维护的成本等。

这里顺带有一些关于自动化的思考，还是来自于医学检查的启发。

医学的检查有很多的方面，包含最简单的身高、体重和血压。这些通常是用手工的方法，后来有了简单的自动化的工具，用来提高效率，如果条件不够的地方，还是可以退回到人工的方式来做。但是很多检测的手段，手工是没有办法做的，必须借助于先进的技术和工具，比如我们这里提到的CT，除了弄一台CT机通常也没什么办法。

这就好像如果计算机只是用来算数字，比如传统的计算器，那么它起到的作用就只是加快速度，提高效率。理论上来讲在这种情况下还是可以手动来做的，只是时间可能长得无法接受。但是如果它用来做视频的解码和播放，那就有质的变化了，这个时候已经完全无法用手工来做了。

我想对于我们的测试手段也是一样，有些模拟用户操作的手工测试可以被自动化，但是有时也可以退回来手工，但是有些测试，比如性能测试，压力测试以及fuzzing test等则很难不借助必要的工具来完成。更进一步，前面的手工测试一旦可以自动化以后，也会带来质的变化，因为我们可以在每次稍大的改动之后就把所有的自动化用例完整的跑一遍，但是如果是手工的，这样做起来就不太现实。

对比医学检查，目前的软件测试显然还没有达到这样的程度，粗浅的想了一下，可能有下面的一些原因：

1. 人类身体各器官的构造，即便考虑年龄、种族等因素，其差别也是很小的。

  但是软件的差别则很大。不过我在想，对于同一类的软件是不是有一些共性，比如Windows桌面版的应用，一个用来处理大量客户端请求的Linux daemon，一个Android App？

2. 比较容易判断有没有问题

  其实和第一条也有一些关系，因为已经有大量的经验值，比如大家看到的体检报告上常会给出某个检测指标的参考值，比如白细胞计数，血压和血糖的正常范围。有了这些数据之后就比较容易判断正常和异常。而对于软件而言，这些相对比较困难，或者说目前目前只能做到一些相对外围的比较粗略的，比如crash，比如mem leak，或者CPU使用过高等。但是对于内部逻辑是否正确，当前状态是否正常就比较难以判断了。

就目前的状况来看，还需要一些针对性的定制来解决这个问题。

3. 标准的检测手段

   CT借助了X光来进行成像。X光是一个很核心的检测方法。

   那么对于软件，我们有没有什么比较标准的检测方法？性能测试中有一些标准的指标，对于CPU,内存，网络，文件系统或者进/线程本身，但是这些还不够。

对于很多公司的软件测试部门或者团队，大家常会提到一个问题，就是如何推动开发自测，很多情况下这都是一个比较难的问题。

这是一个提了很久的话题，除了协作和配合以及人的观念的问题，我觉得另外两个方面也值得考虑：

1. 没有标准改进就无法进行。

  如果有一套比较针对性的标准的检测方法，其实也是一个改进的指导。

2.如果能有一套简洁高效的测试方法，比如一套稳定高效的自动化测试集，那么推动开发自测就不是一个问题。

- 能高效快速的知道有没有问题，并在失败时给出必要的信息

- 上面这一条做到了，而且自动化程度很高，这个时候就可以把这个作为一个内部的标准，开发人员做出来的东西如果不能pass这些测试，就不需要提交给测试人员做进一步的测试。这样这些验收测试慢慢就不需要测试人员来做了，相当于也提高了提测的门槛。

如果能达到类似的程度，我相信就不会有人质疑测试这项工作本身的价值和技术含量，因为“1979年10月，由于Hounsfield和Cormack在该领域的开拓作用，获得了当年的诺贝尔医学奖”。就好比会有病人或者医生质疑CT和MRI等检测手段的价值和技术含量吗？

手工的测试是有价值的，但是个人的观点，我觉得测试作为一个专业领域，方向还是应该逐渐的把一些通用的技术和方法通过工具和系统的方式固化下来，依靠先进的技术，变成可以更便利和更大范围收益的东西，而更有经验的人，去改进现有的东西，或者再去探索新的技术和方法。

嗯，最后想提醒自己和大家要多喝水，多注意身体！