具支持这些功能。例如,BuildBot 开源项目正在为之而努力,至少 在不久的将来可以实现这个目标。 3.出现 bug 时,分析原因比修正错误更耗时间 当开发人员修改好代码,并把它提交到代码库里的时候,你必须反应迅速,及时地测试 他(她)提交的代码,这样,如果测试不通过,开发人员就还记得他(她)刚刚修正过的地 方,也很容易找到 bug 的原因所在。 时间一长,他可能就忘了,Bug 出现时不得不查看代码历史,比较不同版本的代码,直 到代码原因分析出来。很有可能光找原因就白白的耗费了几个小时,太不值得了! 4.开发人员在转换项目过程中花费了太多的时间 通常来说,搭建一个项目的开发环境是不容易的。如果对项目没有很好的了解,不具备 一定的专业知识, 要搭建好环境几乎是不可能的。 如果仅仅是搭建环境就花费很 长的时间, 开发人员往往更希望长期呆在同一个项目环境中。 比较理想的状况是: 开发人员有能力毫不 费力的从一个项目转到另一个项目,不存在技术难题,“项目 文化”已经不是个难题了。 对此,我有个建议:使用项目管理工具,比如 Apache Maven。用 Maven 描述的项目一 般很容易在 Eclipse 中搭建起来。对于
Java 项目来说,只需要要从 SVN 下载代码,键入 “maven eclipse”,刷新,它就可以工作了。所有与代码对应的测试代码也可以运行!哇, 简
直是太神奇了!整个项目不到 30 秒就建好了。 很可惜,这项技术目前还只支持 Java。至于其它的语言,如 Python、C,等等,仅仅 Maven 还是不够的。
5.随着开发人员的增加,Bug 也增加 如果方法不得当,一般来说,开发人员增加的同时,程序的 bug 数目也会增多;随着程 序的复杂性的增大,软件的质量也会下降。而我们必须与之作斗争。那采取什么方法呢?很 简单的理论:透明、代码审查和自动测试。 透明能够确保每个人都能得到代码,决定谁去修改它,何时修改,或者是为什么要修改 它。透明能够确保团队的每个人都会因为自己的代码质量而感到压力,并由此而产生动力。 而代码审查呢?开发人员对别人的代码进行审查,不仅能够从别人的代码中学到东西, 而且它还确保开发人员有效地发现代码的问题,对提高代码质量功不可没。 至于自动测试,我们在下面进行详解。 6.分层测试 不可否认,写出好的测试代码的确是个很大的挑战。例如,代码写好后,对它们进行单 元测试就很困难,单元测试不可能测试到程序运行的方方面面。功能性(质量保证)测试对 程序测试相当有效,不过它通常运行慢,对问题发生的原因给出的信息往往很不够。 因此,你不得不对测试进行拆分以克服这种情况。如果简单的基础测试都无法通过,那 么运行更大的测试显然是无意义的。分层测试的目的就是让测试从易到难。 ——第 0 层:开发人员在自己本地环境中进行的单元测试。 ——第 1 层:构建服务器上的单元测试,(几乎每个)代码提交之后开始。 ——第 2.1 层:集成测试,在几个模块整合到一起之后进行的测试。 (用真正的模块代 替掉原先的模拟模块。例如,使用真正的 XML 解析器换掉原先的那个替代品) ——第 2.2 层:集成测试,通过入口访问系统(接口、磁盘等等,到这儿,你可以测试 访问真正的系统) ——第 3 层:功能性测试,测试程序可见的部分。(用户能够看到的实实在在的功能, 当然,这一层还不够) ——第 4 层:性能测试。 ——第 5 层:客户体验。(OK,这并不是一个测试层,但是这个环节的确会发现不少意 料之外的 bug) 这个方法的理念是同一个 bug 决不会再次重现。因而,对于每个你发现的 bug,你都应 该创建测试用例以保证它不会重现。这个测试可能是单元测试(这样最好),也有可能是集 成测试。
总之,
问题发现得越早越好,这意味着我们可以更早修复它。