第3章微软测试之道

第3章工程生命周期阿伦·培智我喜欢做饭。

对我来说，做饭的过程很有趣，你需要协调处理不同的菜肴，还要保证它们都能按时做好。

从我的“天才厨师”母亲那里我学到了自己的一套方法——边做边补。

简而言之，就是“跟着感觉走”。

我已经做过很多菜了，因此，我可以很自如地打开橱柜看看哪些原料合适。

菜谱只是我的参考，从菜谱上可以得到一些基本概念，比如需要些什么材料，要煮多久，可以从菜谱上得到新的灵感。

我的方法非常灵活，不过也有一定的风险。

我也许在选择替代品的时候出错（例如，制作strata的时候我建议你一定不要用豆奶代替牛奶） 。

strata，可加入蛋、肉、蔬菜等佐料的烘培奶酪食品。

就像软件测试一样，我做饭的方式也是根据情况灵活调整的。

例，如果有客人来吃晚饭，我会比只为家人做菜时对份量多做考虑，还会减少使用替代品。

为了减少我的意大利烩饭味道不好的风险，我会在做的时候稍微正式些。

对于那些负责为上百人准备晚宴的大厨，我只能去想象他们是如何完成任务的。

当你为这么多人做饭的时候，用量和均衡变得更加重要。

此外，为了满足不同客人的要求，大厨的挑战是做出符合客人们各种口味的菜。

当然，最后所有的菜品都要按时做好，并且在端上桌的时候保持新鲜。

在这个例子中，“出货时间”是没法改变的。

做软件和做饭有许多相似之处。

按部就班有按部就班的好处，灵活机动有灵活机动的好处。

当然，一旦用户多了，不管做什么东西都会带来新的挑战。

本章将介绍一些微软所使用的开发软件产品的方法。

3.1微软的软件工程在微软，并没有一个单一的软件开发模式适用于所有的产品部门。

根据产品的规模和应用范围、市场条件、部门大小以及过往经验，每个组都会决定最适合自己的模式。

一个新产品的开发可能会由产品从构思到市场销售的时间（Time to market，TTM）来推动，这样能在该类软件出现领头羊之前抢得先机。

现有的产品可能更注重以创新来撼动领先的对手，或保持住领先地位。

每种不同的情况都需要用不同的方式来设计、实现和发布软件产品。

尽管有时也要有变通，但很多实践方法已经被广泛采用，同时也可以在工程实践中进行显著的实验和创新。

对软件测试人员来讲，理解这些常用工程模式的区别、所在组使用的模式，以及所在组正工作在该模式的哪一阶段，不仅有利于产品的规划（了解将要做什么），也有利于计划的实施（了解该模式现阶段的目标）。

理解软件开发的整个过程以及自己所扮演的角色对整个产品的成功至关重要。

3.1.1传统软件工程模型很多模式都是用于软件开发的。

有些模式已经存在了几十年，而新的模式几乎每个月都在不断涌现。

有些模式非常正式和结构化，而有些模式却非常灵活。

当然，没有任何一个单一的模式适合所有的软件开发部门，但是，遵循一些已有的模式可以帮助工程部门创造出更好的产品。

理解了在产品开发周期的哪些阶段需要做哪些开发和测试，可以帮助整个部门预期可能出现的问题，并且提前了解设计和质量问题可能会影响到产品的按时发布。

1.瀑布模式瀑布模式是最常见（也是经常滥用）的软件开发模式之一。

如图3.1所示，在“瀑布”这种软件开发模式中，每一个阶段的结束同时也是下一个阶段的开始。

工作流程按照指定的顺序进行。

工作的实现从一个阶段“流动”到另一个阶段，就像瀑布从山上流下一样。

图3.1瀑布模式这个模式的好处是，当你开始一个新的阶段的时候，前一阶段的所有工作都已完成。

例如，在需求阶段的工作没有完成之前，设计阶段就根本不会开始。

这个模式的另一个潜在的好处是，它能够强制你在动手写程序之前尽可能多地进行思考和设计。

按照字面意义理解，瀑布模式不灵活，因为它看上去不允许阶段的重复。

例如，如果测试的时候发现了一个由于设计而导致的缺陷，你该怎么办呢？设计阶段已经“结束”了。

这个明显的不灵活性使瀑布模式饱受批评。

因为每个阶段都有可能延迟整个产品的周期，特别是对于长周期的产品，早期的某些设计很可能在实施时已经是可有可无的了。

Winston Royce，“Managing the Development of Large Software Systems，”Proceedings of IEEE WESCON 26 (August 1970).有趣的是，瀑布模式的设计者Winston Royce，的本意是把它设计成一种迭代的过程。

Royce在关于这个模式的原始论文 中讨论了至少进行两次迭代，以及使用先前迭代中获得的信息改进后面迭代的必要性。

瀑布模式的发明，是为了改进已沿用了几十年的基于阶段的模式。

其改进是通过对不同阶段之间反馈链的认识和对减小返工影响提出的指导来实现的。

可不管怎么说，现在瀑布模式已经在某种程度上被许多软件工程师所取笑，尤其是对于敏捷开发的支持者而言。

在软件工程界的许多圈子中，“瀑布”已经成为用来描述“任何”具有严格流程要求的工程系统的通用术语。

2.螺旋模式1988年，Barry Boehm提出了软件开发的螺旋模式 。

如图3.2所示，“螺旋”是一个包含确定目标、风险评估、工程实现和下一迭代规划4个主要阶段的迭代过程。

Barry Boehm，“A Spiral Model of Software Development，”IEEE 21，no. 5 (May 1988): 61.72. 确定目标。

为项目的当前阶段确认和设定特定的目标。

风险评估。

确认主要风险、减少风险及应急计划。

风险可能包括超支或资源问题。

工程实现。

工程实现是完成工作的阶段，包括需求、设计、开发和测试等。

下一迭代规划。

对项目评估，并开始计划下一轮的“螺旋”。

图3.2简化的螺旋模式重复使用原型来让风险最小化是螺旋模式的另一个重要概念。

初始模式构建于早期设计之上并接近最终产品的特性。

在后续迭代过程中，原型可以帮助我们评估工程系统的优缺点和风险。

软件开发团队可以通过初始规划、设计，以及创建产品的原型的方式来实现螺旋模式。

接着收集用户对已经完成部分的反馈，分析数据以评估风险，并决定下一步的工作。

这个过程持续进行直到产品完成或者项目因风险过高而取消。

3.敏捷开发在上一迭代成功或失败的基础之上，使用螺旋开发模式的团队能以迭代的方式开发软件。

螺旋模式的规划和风险评估环节对于许多大型软件产品来说是至关重要的，但对很多其他软件项目来说却太过繁琐。

有别于上述两种严格的开发模式，敏捷开发模式侧重于轻灵和小步递进的开发方法。

敏捷开发当前在软件界非常流行。

很多不同的开发模式都可以归类到敏捷开发，它们大致具有以下特征：频繁而短暂的迭代。

敏捷团队致力于快速发布软件，并且有做到这一点的纪录。

强调面对面的交流和协作。

敏捷团队注重队员相互之间和与用户之间的交流。

对产品要求变化的适应力。

敏捷团队灵活机动，他们擅于应对在产品开发周期中的任何环节用户要求的变化。

短暂迭代允许他们频繁地对变化区分优先次序和及时应对。

贯穿始终的质量责任制。

在敏捷开发团队里，单元测试广泛地为开发人员所用。

很多人使用测试驱动的开发方法（Test.driven Development，TDD）。

这是一种开发人员先写单元测试程序，然后再实现产品功能以通过该测试的开发方法。

在软件开发中，敏捷意味着团队能够快速地按需要调整前进的方向。

以通过小改动随时提供可用软件为目标，积少成多就能取得可观的成果，而且工程团队几乎总能知道产品的当前状态。

与此相反，我记得有一个项目用非敏捷模式开发，曾经连续3个月都是“95%完成”。

事后才发现，当时我们实际上不知道还余下多少工作量没完成，因为我们试图同时做所有的事，结果做了好几个月还是没有交出任何可用的软件。

敏捷的目标是每次做一点，而不是一次全部完成。

4.其他方法现在存在几十种软件开发模式，还有更多的模式及变体将会继续流行。

没有哪一种模式是最好的，但是充分了解所选用的模式，并且在该模式的规范内开发软件，你就有更大的机会开发出优质的产品。

3.1.2里程碑模式不清楚是否有意所为，我参与的大多数的微软产品都使用螺旋或其变体的开发模式 。

当我加入微软的Windows 95团队时，他们处在“里程碑8”（我们管它叫M8）的初始阶段。

就像它的一个前身M6一样，M8最后成了一个公共试用版。

每个里程碑都对产品功能和质量有具体的目标。

在微软，每一个我直接或间接参与开发的产品都使用过里程碑模式。

自从我2005年离开产品开发，加入卓越工程部后，很多微软开发团队开始接纳和使用敏捷开发模式。

里程碑进度计划建立了项目发布的时间表，也包含了关键的过渡安排和中期版本（例如测试版和业内预览版）的时间表。

里程碑进度计划帮助每个团队了解整个项目的期望值和现状。

如图3.3所示是一个里程碑模式的例子。

图3.3里程碑模式示例里程碑模式的优点是里程碑不仅仅是写在日历上的一个日期。

要完成一个里程碑，必须满足具体的、事先定义好的阶段结束标准，下面简称阶段标准。

阶段标准通常包括以下几条：关键功能编程完毕。

即使尚未完全测试，但关键功能已经实现。

中期测试目标达到。

例如代码覆盖目标或测试完成率目标达成。

缺陷目标达到。

例如无第一类严重(P1)的缺陷或无“当机”的缺陷。

非功能目标达到。

例如性能、压力负荷测试完成且无严重问题。

各阶段的标准随着每一个里程碑的推进而日趋严格，直到团队达到了最终发布产品的标准。

表3.1给出了一个里程碑项目的各阶段标准。

表3.1里程碑模式的阶段标准示例(不完全列表) 测试范畴里程碑1（M1）里程碑2（M2）里程碑3（M3）发布用例运行全部第一优先（P1）用例运行全部第一和第二优先用例运行所有用例运行代码覆盖代码覆盖率测量完成并生成报告65%覆盖率75%覆盖率80%覆盖率压力测试第一优先压力测试每晚运行所有压力测试每晚在至少200台机器上运行所有压力测试每晚在至少500台机器上运行且无新问题所有压力测试每晚在至少500台机器上运行且无新问题可靠性解决M1阶段中前50%的用户报告的“当机”问题解决M2阶段中前60%的用户报告的“当机”问题解决M3阶段中前70%的用户报告的“当机”问题功能产品20%拥有新用户界面产品50%拥有新用户界面，且可用性测试完成产品100%拥有新用户界面，且采纳可用性反馈意见性能完成性能测试计划，包括可扩展性目标为所有主要用户场景确立性能基准全面性能测试自动化完成，性能稳步改善所有性能测试通过，性能目标达到里程碑（或其他任何一种迭代模式）的另一个优点是，在每一个里程碑阶段中，团队都能通过一步步迈向发布而积累经验。

他们学会了怎么应对意外，如何为未达标的项目正确探寻解决方案，以及如何预估和处理缺陷出现率。

还有一个目的是，每一个里程碑发布的产品都是一个完整的产品，都可以用于大范围的试用（即使该里程碑发布的不是外部测试版）。

因为每个里程碑发布的都是软件产品的完整版本，所以产品开发团队或者微软的任何其他产品团队都可以以此为基础（尽管还很粗糙）进行后续的开发。