讲师：袁华松

　　时间：12月4日13：15-14：15

　　地点：教室二

　　欢迎大家来参加这个培训，我叫袁华松，来自微软总部SQL Server产品事业部，是软件设计与测试工程师。大家听了栾跃的讲课以后，也知道我的任务是做什么。我主要是做测试工具的开发，我们这个小组里，也做了一些测试，因为我们是做产品API使用的测试，可以说是微软API第一个用户，在用户API出版前第一个用户。今天讲的是单元测试，我在整个系列里一共要讲三个方面，单元测试从测试角度来说是一个测试的开始的一部分。我将讲一个(Bata)测试，怎么样搜尾的部分。还要讲测试自动化的问题，怎样利用这些自动的测试，来达到你搜尾的一些指标。

　　我是复旦大学1988年进校，92年毕业。在浙江大学96年读完硕士去美国留学，98年进入微软公司，差不多已经有五年半的时间。我进入公司还是挺幸运的，我经历了微软最核心的一些产品的开发和测试过程，我经手所有的产品包括“SQL Server7.0”，然后是Windows2000等等，现在我们在进入下一代的开发。

　　我会提到微软研发各个部门的分工，微软产品开发和测试规划的问题，微软单元测试的流程问题，还有微软产品测试包含的单元测试内容。不会包含各种各样理论的问题，各种测试理论上怎么做，大家随便去外面买一本书，可能比我讲的更透彻。我不会讲某个具体测试的利用，比如说有些先生或者女士，用到某个具体的测试工具有一些问题，我还没有接触过那些测试工具，没法回答你具体的问题。而且我知道，外面软件公司使用的测试工具和应用，和微软内部的不是很一样，如果没有接触的话也没有办法回答你具体的问题。也不会讲其他测试工具的评价，也不会讲具体测试的单元。大家来这的主要目的是想听一下微软总体测试是怎么样的步骤。

　　微软研发分工与流程简介。正像早上栾跃提到过的，微软所有的角色在研发部门分为四大部分，除研发部门以外还有产品知识部门，还有销售部门，我是着重讲研发部门是怎么样分角色来做整个产品设计。首先研发部门需要有产品程序经理，主要功能是设计产品，编写产品功能规格书，我们叫Spec，应该说是比较粗一级的规格说明书，是产品应该做什么，用户干什么事情的时候，我们应该有什么样的反应等等这些说明。程序经理还有别的角色，比如说是跟踪产品总体项目的进程。有的进度如果比较大的话，可以由另外一个人单独控制项目进程，如果这个产品进度比较小的话，有可能采取经理兼任的职务。他最主要的是设计产品，程序经理会参加各种各样的开发会议，包括对手的开发会议，看他们下一步做什么，我们这个版本怎么做超过他们。程序经理还会参加用户访问，一般是由上级经理和程序经理参加的，主要听取用户对我们产品的各种各样的意见、建议，下一版本我们可以采用哪些设计，可以改进我们的产品。可以参加大型技术发布会，比如PDC，微软教育会议，参加PDC的人员编程人员比较多，选择未来几年内需要做什么东西，这些人知道预先的消息后可以知道这些新的技术，用于他们产品开发，可以跟微软同步发行他们的产品。TechEd主要是做应用产品的教育，用户比较多。程序经理都会参加这些会议，有时候跟用户交流，教育用户，我们会有什么新产品出来，我们的产品怎么样使用等等。

　　开发小组就是开发经理、开发组长、产品设计工程师，他们主要是语言开发的细节，产品程序经理设计产品的时候，所有开发小组都是在做语言的功能，产品经理说我要设计某一个产品，我这个产品怎么样实现，产品经理只知道用户什么动作，怎么实现用户的动作，是用什么样的功能来做，可能细节上并不是很清楚，这是由开发小组做语言，会告诉产品经理，你这样的设计我们无法实现，或者说我们实现起来非常难，可能要六个月才能实现，我们这个产品只能三个月，可能就不行，我们要赶产品设计。当然他们也会编写产品设计规格书，包括的是怎样实现这些细节的问题。

　　功能市场某一个产品细节是怎么样实现的，我是用什么样的数据结构来实现这些功能，整个模块的流是怎么样的，设计流是怎么样的。开发小组最主要的工作是编码、开发，实现这个软件的模块，实现它的功能。最后还是要做修改，产品总会有Bug，修改Bug等等。

　　问：

　　编码之前先要写设计？

　　袁华松：

　　编码之前要写一下总体结构图模块是怎么样的，怎么样实现这个工程，具体实现的思路、数据是怎样的。他是在开发经理指导下进行的。

　　测试小组一般是测试经理，测试组长，软件测试与设计工程师，还有软件测试工程师等等。测试小组主要编写软件功能模块测试规格书，然后编写自动测试工具，最主要的是编写测试代码，还会进行运行测试，然后报告结果。这些动作实际上也是自动化的，所有运行这些测试是一个整体，由工具进行总体比较，比如说有什么区别，有各种各样新的错误出现等等，都是有自动工具的。问题是测试工程师要进去看到这些结果，要分析这些错误是怎么样造成的，然后根据这些错误汇报软件的Bug，并且修改完以后要验证Bug修改成功，如果没有修改成功，要重新激活再去修改。对于每日的Build结果或以发布产品的SP运行回归测试。

　　最后一部分是用户教育编写组，他们所做的主要是编写用户文件，还会编写用户示例。他们可以编写一个很巨大的产品的实验网站或者实验的应用程序，等于说从头到尾可以一个人完成整个程序验证你的产品，所以他们是有计算机的背景进行工作。最后一个工作是与PSS合作编写KB Article。如果用户有意见，新的错误出来以后，微软会把这些错误进行修改，修改完以后，对这个错误写一篇文章解释这些错误的原因、结果，上哪儿安装Fix等等，会变成一张KB Article。

　　微软研发流程。微软做的产品比较大，研发流程拉的比较长。比如说Windows2000差不多用了五年的时间，整个流程内部分了很多，很长。我们从内部里程碑零开始，会有1、2、3，会有Alpha，然后是Beta，RC1-2，Release Candidate会给大的厂商使用，在他们的产品线上装，是不是能够成功，一切都没有什么大的问题，如果一切都成功了，产品可以宣布发布。Milestone从0-3，或者是到4都有可能。应该说Alpha的用户技术级别比较高，对你产品整体设计可以提供建设性的建议，对于产品具体结构，需要什么样的功能有很强的建议，可以告诉你你这个产品整体模块不对。Beta一般是比较广的外部的用户来看。Milestone一般是四个月，再划分小的，有3.1、3.2、3.3等等。每个小的Milestone能够促成Milestone的条件。我们在整个小的设计上也会有小的Milestone在，具体来说整个产品的设计，如果超过两三个星期就会很明显的知道超时了，就知道你这个产品没有完成。

　　微软开发与测试规划。这张图是在讲微软在一个产品Milestone之内我们应该怎么样来做。这些Milestone是在讲设计产品的时候我们应该怎么做。在一个Milestone里四个功能，他们都在干什么，我特地排了这些顺序和同步的事情，他们同时在干什么。Milestone刚开始的时候，PM是在做产品的设计，在访问用户，访问对手的网站，产品这些会议决定我们下一步要做什么。同时Dev是在研究我们怎么样实现这些功能，我们应该用到哪些工具，同时也可以语言有点结果的时候，把大概写出来。Test一般在优化整个测试过程，测试工具，这些就是在没有测试的时候，我整个框架的设计都已经可以出来了。最关键的一点是Spec Review，当PM写出来以后，都会参加一个比较大的会议，会PM的Spec进行评判，对于所产生的问题，对于有漏洞的，据我们的经验会有什么样错误的，等等意见会提出来。这些讨论和回答的过程，比每个Spec要长很多倍。一般在Spec没有开Spec Review会议之前，整个Spec已经讨论的差不多了，大部分的问题都已经有结论了，才会开这个会议。会议结束了，PM手上还会有一个小单子，找出各种各样需要修改的地方，他回去稍微修改一下，就可以签字实现了。从此之后，大家才可以干各种不同的事情。如果SR会议结束以后，可以管理DCR。