软件测试在很多人看来就是在一间黑屋子里抓黑猫，而且不知道是否真的有猫。而在微软看来，猫一定是有的，但测试不只是为了抓猫，而是要不断改进软件工程，使将来的猫越来越少，也就是今天解决明天的问题。
《微软的软件测试之道》向我们展示了微软软件测试的方***、工具和实践。
事实上，在微软软件测试早已成为软件工程的一部分。然而当年的微软就像我们今天的一些小型软件公司一样，没有测试工程师，没有本地化工程师，没有程序（
Program Manager
），也没有可用性工程师。
好的设计与好的执行是软件开发项目成功的关键。
测试设计与好的软件设计有很多相似之处。测试设计要求规划和解决问题以确定运行哪类测试以及那些类型测试最有效。如同设计模式，测试模式解决共性问题并且为测试人员设计测试提供指导和策略。微软内部测试人员一般采用简化的
Robert Binder
测试设计模式模板作为通用格式进行沟通。
确
定测试模式后，需要估计测试时间。估计测试所需时间是非常困难的，一个粗略的规则是测试时间与开发的时间相同。另外一个问题是何时开始测试。一般我们会认
为编码完成后开始测试。实际上，理想状况是在开发的起始阶段就介入。开始测试设计的一个时间点是软件需求或功能规范审查。当然开始测试之前，我们还需要一
个测试策略为测试团队提供愿景，帮助每个人确定哪个测试活动最重要并帮助他们确定何时、何地应用不同测试类型。
在微软，测试工作包括功能性测试、结构化测试、利用代码复杂性分析风险和模型化测试。测试人员采用等价类分区、边界值分析和组合分析技术进行软件功能测试。结构化测试则采用组块测试（
block testing
）、决定测试（
decision testing
）、条件测试（
condition testing
）和基础路径测试（
basis path testing
）的方法。代码复杂性对于识别哪里可能存在缺陷（
bug
）
是必不可少的度量，对于识别可能导致维护问题的代码同样有价值。利用代码复杂性分析风险有助于我们把有限的测试资源集中在最恰当的区域。模型能帮助我们理
解复杂事物如何工作。将从模型中产生的测试与测试模型配合是最有威力的。基于模型的测试比随机游走更加有效。微软测试团队已经采用模型化测试连同传统的测
试自动化有效地测试了很多功能和应用。
在方法论外，测试还需要工具和系统。微软当然拥有自己的缺陷和测试用例管理系统。《微软如何测试软件》不仅向我们介绍了微软缺陷和测试用例管理系统，还向我们介绍了基于多年的使用而产生的经验教训和实用的建议。
在软件测试中似乎总有另一个障碍需要克服。微软的测试工作也是如此。微软正尝试采取一些措施解决明天的问题。具体方法包括自动失败分析、机器虚拟化、代码审查等。
