# 浅谈测试观




前几天看到一个关于测试的观点。

> We are capable of creating software systems that we are not cable of fully understanding.
> Therefore we test.
> We test to help us think about the design of our creations.
> We test to confirm our beliefs about our creations.
> We test to challenge our beliefs about our creations.

大意是可以创造软件系统，但是我们可能不了解我们究竟创造了什么。

因此我们需要进行测试。

测试可以让思考我们的设计，让我们确定和挑战我们对系统的认知。

第一反应是有点虚，不过仔细想想却隐含着另一层次的思考。

那就是对于软件测试，我们的测试观是什么？

不出意外，朴素的测试观点应该有以下几种吧。

### 验证

这种观点认为：因为系统是我们设计并创造的，那么测试的目的应该就是验证设计和真实的产出是否真正的一致。

比如我们需要系统实现3个功能，那么测试的时候我们就要验证这三个功能的实现是否符合预期。

另外我们还需要反向的验证。我们要实现3个功能，那么正常情况下这3个功能是要没有问题的，那么除去正常情况，异常情况会更多更复杂，这些异常情况也是需要验证的。

有经验的测试人员/开发同学往往能想到，或者是感觉到异常可能出现的地方，或者是考虑到大家都难以想象的场景。

反向验证比正向更难，而且难很多。

验证的测试观大致是相信正向的场景需要完全验证，异常的场景能够考虑和验证的越全面越好。

从更大的方面去考虑，这种异常场景的验证很像是统计学上的抽样，如果需要样本越接近整体，那么采样的数量就要越多。所以没有目的的多点点有时候反而有很好的效果，chaos monkey测试就是基于这个原理， 模拟猴子乱点从而发现一些意想不到的问题。不过通过人工方式去增加异常验证的规模会比较困难，类似于fuzz testing这样的测试工程学上的探索就显得非常重要了。


### 怀疑

怀疑的观点认为：系统肯定是有bug的，只是还没有发现而已。

稍微扩大化一点就是开发讲的我不全信，除非你能证明你说的是对的。产品的需求也不一定合理，除非你能说服我。

更扩大一点就是系统的bug不一定全是开发写出来的，也可以就是设计的时候有问题，只是这个问题在开发过程中被忠实的还原了而已。开发写bug也不是本意如此，只是大家对同一件事情的理解发生了偏差。

既然错误和bug无处不在，那么我们只能尽可能的多测一点，这样起码心里会舒服一些。

另外尽量早点测试，毕竟问题发现的越早，修改的成本越低，这就是测试左移。

实在不行产品发到线上以后严密监控，一旦有问题暴露的话就尽快响应和修复，这就是测试右移。


### 怀有敬意

我们创造了系统，但是我们可能真的不懂这个系统。上帝创造了人类，但上帝可能也没有那么了解人类，所以人类一思考，上帝就发笑。

于是我们对系统的一切怀有敬意。

我们通过测试去认知系统，不傲慢，不盲目自信，保持谦和和平常心。

就像儿童通过问题去认识这个世界一样，我们对于自己系统探索也要多多提问。

这个为什么是这样子？为什么要这么做？为什么要这样实现？这样实现是不是有问题？

如果系统是整个世界，那么测试就是生活，我们通过生活去认知这个世界。

生活可以很无聊，日复一日千篇一律，生活也可以很精彩，充满激情和挑战。因人而异，冷暖自知。


不知道大家的测试观是怎么样的？抛砖引玉，欢迎留言探讨。




原始封面

![课程图片](https://images.unsplash.com/photo-1504893524553-b855bce32c67?w=300)