浅谈测试观

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

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无处不在，那么我们只能尽可能的多测一点，这样起码心里会舒服一些。

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

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

怀有敬意

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

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

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

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

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

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

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

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