Monthly Archives: December 2006

无论是在传统的瀑布流还是敏捷开发方式中，必要的流程都是项目成功的关键因素。这边小文是我在微软一年半的时间里，观察身边项目的一些心得总结。 项目中，最根本的就是源代码管理。源代码管理需要处理好以下问题：一，访问权限的控制；二，版本控制；三，满足协同开发的需求，包括冲突解决等；四，能够与Build环境良好地集成。满足以上要求的源代码管理系统有开源的CVS和微软的VSTS（Visual Studio Team System）。 微软中保证软件项目进度和质量的一个重要环节就是日构建（Daily build）。日构建就是每天都把整个软件项目编译成目标文件。像Windows这样大的一个软件项目，都是要完成日构建这样一个例行工作的。Windows的Build号记录了该版本Windows构建的次数，在项目开发的过程中一般来说都是每日加一。日构建的意义将在下文中逐步展现出来。 要完成日构建，第一个必要条件就是源代码管理能够和Build环境集成在一起。开源和老版本的Visual Studio的解决方案是利用make及其脚本来完成这样的集成工作。如果采用了VSTS，那么自带的MS Build将很好地和源代码管理系统集成在一起。对于整个Solution而言，构建的工作只不过是对这个Solution运行一次MS Build，而不需要程序员手动地配置依赖关系和添加源文件。 如何保证日构建能够运行成功？如何保证日构建出来的二进制文件就是项目最终需要的程序呢？当目标程序满足什么样的条件，测试人员才可以开始测试呢？这就要讲到日构建的两个重要的步骤。首先是运行Unit Test，其次就是运行BVT Test。Unit Test可以保证dev的代码不会破环整个构建过程；BVT Test则表明日构建的目标程序满足了该程序所需要完成的最基本的功能，测试人员可以对这个目标程序进行后续的测试工作。由于日构建一般都是在晚上自动完成，这也就要求Unit Test和BVT Test本身能够自动化运行。 前面我们由日构建引出了两个基本的测试概念，Unit Test和BVT Test，那么接下来将把这两个概念稍作展开。 一般而言Unit Test是由dev完成的，它是dev对自己编写的代码进行的最初步的功能性测试。Unit Test需要保证dev编写的代码能够满足文档描述的功能。它的一个附加的效能，就是能够保证dev的代码不会编译失败，这个对于日构建而言是至关重要的前提。因此，没有通过Unit Test的代码，dev是不能够check-in到源代码管理系统的。这里也就暗示了Unit Test首先是在dev的开发机上运行的。编写Unit Test一般有以下一些原则可以遵循：一，KISS principle: one test should verify only one intent. (Keep It Simple, Stupid)；二，Each test … Continue reading →

李贺的诗，很久没有读了。   李贺的这首诗，是我最喜欢的诗词中的一首。