主题：【原创】乱侃软件工程师的素养 1 -- poorfat

我们那时候整个学期就两个作业，一个是个人完成的，读取两个位长很大（大约是填满半个9吋屏幕）的自然数，完成加减法，输出结果。另一个是由3-4人的集体完成，读取一个文件，用海明码压缩，生成新文件，再解压缩。最后解压缩的没做完。

90年代初，上机时间少，大部分工作是在纸上完成的，用的PASCAL，加上解释行的语句，简直就是写作文。

这个系列基本上写的都是我在工作中遇到的另我痛恨的事情。所以免不了我要骂人。这个贴继续开骂。

我曾经接手过一个测试文档，其中有一条测试案例是这样写的：（大意）

“ 请确认某某功能是好的。（verify function XYZ works.）”

诸位，如果你被分派去执行这条测试案例，你会不会骂人？我是涵养很好的人，所以我只是默默地在心里把文档作者骂了几遍。然后我虚心地向作者请教以下几个问题：

1 - 到底什么叫做“是好的”？ 你到底要我达到什么测试目的？

2 - 我应该执行什么步骤来测试该功能？

3 - 什么情况下我可以认定该项测试成功了？

4 - 什么情况下我可以认定该项测试失败了？（由于众所周知的原因，你最好保证3 和4是互斥的， 否则我还要继续踢你屁股）

5 - 如果测试失败了，我应该向谁举报？由谁负责订正错误？

以上都是一些最最基本的测试问题。这些问题不搞清楚，没有人可以执行测试的。写这个测试案例的人一定已经有丰富的执行该测试的经验了。所以他一看这些字眼就知道该怎么做。 可是其他人不一定是这方面的专家。 所以你如果想要其他同事能够顺利执行你写的测试案例，你最好花点功夫，把你的文档写清楚。不要假设人人都能看懂你写的文档。

一个完整的测试案例，不仅要有以上提到的几条，还至少要有以下几点：

- 执行该项测试的人员需要哪些预备知识？背景知识？

- 前期准备工作有哪些？

- 测试环境是什么？如何认定测试环境是有效的？如果测试环境不正确，那么你得到的测试结果就是无效的，无论是成功了，还是失败了。

- 需要哪些硬件电脑？

- 需要哪些软件工具？

总之写文档的时候，一定要把问题的来龙去脉都搞清楚了，别人才有可能看得懂。 记住，文档是要让别人看懂的， 不是用来卖弄你的水平的。

Code Complete 这本书我看过一遍，很粗略的通读了一下，没有细看，不过其基本观点我是完全同意的。

我在这里举的所有例子，都是我在实际工作中遇到的。有些例子看似很简单，也许你认为不会有人写这么傻的程序，但是我确确实实遇到了。这些也许是程序员无意之中犯的错误，但经常对产品会是致命的。所以我们不妨经常检查我们的程序。