软件系统测试在什么时候,软件测试人员的时间是什么样的？

前些天看见有朋友的MSN签名档写着“unit testing”，就问了一下他们的单元测试是怎么做的。看来他们没有真正做起来，只是小范围的试一试。

一方面，他们没有cruise control之类的工具，甚至连daily build都不见得有，单元测试也不上传到版本控制里。

这样做测试的意义就不大了。

另一方面，他好像把单元测试和接收测试(acceptance testing)、集成测试(integration testing)搞混淆了。因为他说，业务逻辑很复杂，测试数据不好做……

单元测试，顾名思义，就是对一个单元的测试(好像什么也没说)。

通常这个单元是指(类的成员)函数，或者函数的一个功能。

每个测试就只针对一点，不涉及其余，还是比较好写的。函数的输入是什么，(对象当时的状态是什么)，得到的输出是什么;有几种不同的情况……

我感觉，同一个函数的单元测试加在一起，就相当于这个函数的详细设计文档。

自然，设计文档应该在实现之前写，而不是实现了以后再补。

和传统开发方法里的详细设计不同，写一个单元测试，就写一段代码让它通过。这样你就不需要在实现的时候，再去读文档，再去回忆当时是怎么想的，能提高效率;更重要的是，这个“文档”是能反复运行的，可以保证和实现的一致性。

如果你的开发环境配置的好，照我的经验，写单元测试再写代码，和直接写代码相比，不会多花什么时间。

编码过程中有相当一部分时间是花在想清楚下一步要做什么上，想到了就把它写成一个测试。这么做是要花一点点时间，不过能帮你尽快验证下面的实现跟你现在想的一致;能帮你理清思路，到底有几种情况需要考虑，就写几个测试;能让函数的功能更明确，只有功能明确，才能明确的测试;能让你的接口更合理，因为不合理的话，依赖关系太多或者接口太复杂，测试写起来会很麻烦……

最重要的是，以后你改了什么东西，破坏了现在的接口，可以马上知道。

不会在发版本的最后一天，才有人告诉你：“这个功能以前是好的，我们已经好几天没有重新测试了。现在坏了，不知道问题在哪里。全体加班吧!”

不花什么时间，还有不少好处。免费午餐，为什么不试试呢?

对于想不明白的事情总是喜欢刨根问底

世上的事，皆有因果。

软件也是一样，出现一个bug，可以说一定有原因，只能说有时我们不知道原因，但是不能说，没有原因。从这一点看，测试和医生有很大的相似之处(都是根据一些表面的症状，查找内部的原因，然后给出解决方案)。

测试人员坚信世上没有无因之果，当我们遇到bug的时候，总要考虑怎么找出bug的原因，如果找不到，寝食难安。

在生活里，碰到想不明白的事情，也总是习惯性的刨根问底，一定要获得一个答案。最常见的一个场景，就是当一样东西找不到了，我便发了疯一般的找，完全投入进去，不断的回忆和推理，一定要把它找到，真的是到了废寝忘食的程度，我的老妈老婆也是哭笑不得。

对自己和身边的事物要求尽善尽美

测试工作也是一项追求完美的工作，当我们宣布一个软件“合格”的时候，可以说几乎考虑了所有的可能性，证明了它没有问题。

可即使这样，还是会有我们考虑不到的情况，会出现bug，于是，我们会继续完善测试方案，让软件更完美。

我们最喜欢看的东西，就是一张全部标着“pass”的测试清单。如果里面有一个红色的“fail”，就会觉得浑身不爽。渐渐地，我们变成了完美主义者，对身边的人和物，都希望完美。

但是这世上的事情和人，都不是尽善尽美的，所以完美主义者活的会很辛苦。比如我家里的电脑，为了保证电脑软件系统“完美”的工作，我经常的重装xp系统。只要系统出了点问题，其实远不到需要重装的程度，但是我觉得不爽，干脆，重装!我老婆都烦了：你怎么又在装系统。

这个毛病现在已经好多了，我已经坚持半年没重装系统了。这是不是强迫症啊?

写了这么多，大家是不是觉得我似乎已经“病入膏肓”了。其实我写的时候很开心，一点没有觉得压力，反而很轻松。有时想想这些事情，着实有趣，随它去吧。

全部