本书是以使读者熟悉微软产品、微软工程师、微软测试人员、测试的作用和对软件工程的通常做法作为开始。书的第二部分讨论许多在微软常用的测试实践和工具。 书的第三部分探讨某些我们工作中使用过的工具和系统。书的最后一部分探讨在微软测试和质量的未来方向，以及我们打算怎么创造未来。

“一本了不起的书——所有软件测试人员必备的书。你会从中学到微软的软件测试方法和他们对软件测试未来的展望。”
—— Siemens AG首席工程师　Peter Zimmerer
“多么激动人心的组合，杰出的测试工程师讲述软件测试故事，而这些都发生在一家要应付世界上最困难的软件测试问题的公司。”
—— 《How to Break Software》 作者 James Whittaker
“微软在测试和测试工程师上的投入是惊人的。本书讲述了成功和挑战，所有软件测试机构都应该学习。”
—— 《A Practitioner’s Guide to Software Test Design》作者 Lee Copeland
微软雇佣的软件测试人员和软件开发人员一样多。这个事实也许会让你吃惊。但你不会惊奇微软对测试流程，以及这个流程在微软多种多样的超过150种的产品的质量管理中所起的作用的强调。
本书由微软的三位卓越的专业测试人员撰写，分享了被全公司约9000测试工程师所应用和使用的最佳实践、测试工具和测试系统。微软的从业者讲述如何设计和管理软件测试，他们的培训和职业发展方法，以及他们是如何看待未来的挑战。最重要的是，你可以获得实用的见解，并应用到你的工作中，得到更好的结果。
设计有效的测试用例，并在整个的产品开发周期中运行。
最小限度地减少功能测试的花费和风险，知道何时应用结构性的技巧。
衡量代码复杂性来发现软件缺陷和可能的维护问题。
用模型来产生测试用例，发现软件意想不到的表现并管理风险。
知道何时采用自动测试用例，为长期使用来设计自动测试用例和怎样接入自动测试的基础架构。
观察杰出测试工程师的特征——和他们所应用的运行测试用例，探查系统以及有效跟踪进度的工具。
探查由于测试软件服务与测试盒装软件不同所带来的挑战。

作者简介：
微软测试卓越工程总监。管理微软的测试技术培训并对微软的测试工程师提供咨询。他是微软最早的测试架构师之一，曾经参与Windows和Windows CE多个版本的测试开发工作。

微软Office在线平台和运营总经理。他曾担任微软测试主管，测试经理以及测试卓越工程总监。

卓越工程的测试架构师。他曾参与过多种产品的测试开发工作并担任过测试总监。他还经常参与软件杂志的写作和学术会议的演讲，并在大学里讲授软件测试。
Alan Page
Ken Johnston
BJ Rollison

记得在2007年秋天的一个早晨，我当时的经理肯·约翰斯顿(Ken Johnston)冷不丁地说出这5个字：“你应该写书”。
当时他刚从某行业测试会议作了个演讲(巧合的是他的题目就是“微软的软件测试之道”)回来，还在为得到听众的一致肯定而兴奋。肯很爱演讲，但他突发奇想地认为我应该是那个写书的人。
我打趣地回复他说，“行，为什么不呢。 ”我接下去说，这书可以包括很多我们在微软讲授软件测试课程的内容，以及在微软流行的其他测试实践和方法。它可能很有趣，但我知道已经有很多很多关于测试的书籍，我至少就看过几十本。其中有些写得确实很好。再写一本这样的书能对软件测试界提供什么有价值的东西呢？
我原本打算否定肯的写书想法，但我突然意识到了很关键的现实：在微软，我们具有很多世界上最先进的软件测试培训。培训的课程内容和结构都无懈可击，但这些并不是最绝妙的地方。我们的教员在讲课中穿插的轶事、成功故事，以及在测试过程中的一些小琐事、小花絮才是对听众影响最大和让他们印象最深的。如果我们能把这些故事、插曲，以及微软怎样在实践中应用等内容写在书里，那该书一定会是很有趣的。我开始超越了我们的教学去思考，去考虑更多的能和世界各地的测试同行分享的测试想法和成功故事。我还意识到我喜爱的一些编程的书都把所有纯技术的讲解，穿插入有趣的故事。
下一步要做的是写一个提案。书的框架和大纲逐步成形了。主要体现在4个主题。首先通过谈论微软一般员工和工程实践来引入上下文是有道理的，第二部分和第三部分将集中谈谈在微软怎样做测试和使用的工具，最后的部分将探讨微软未来的测试。我把该提案送到了微软出版社(Microsoft Press)。虽然我对于本书的潜力一直很兴奋，但我也希望微软出版社将告诉我说：这想法挺傻的，应该趁早放弃。 可是，那个结果并没有发生，紧接着，我发现自己凝视着计算机屏幕,开始思考这本书第一个句子会是什么样。
一开始，我就认定让肯写前两个章节。肯是在微软任职多年的一位经理，写关于微软“人(people)”的方面很拿手。就在我递交写书提案的那段时间里，肯离开了我们部门去管理微软Office的一个在线产品部门。很快，事情变得明朗了，肯应该写本书中关于怎样测试“软件+服务”的章节。他从此成为公司决定微软怎么测试Web服务的关键人物。让他写第14章是最合适的。 稍后，我又找了我的同事BJ·罗里森（BJ·Rollison），他是微软公司中最有资历的测试人员之一，让他写本书中关于功能和结构测试技术的章节。 BJ是我们部门设计微软核心软件测试课程的主要负责人。他比我认识的了解这些测试方面知识的其他任何人都了解得更多。 他也是我知道的惟一一位比我读了更多有关测试书藉的人。 于是肯、BJ和我3个人成了本书的作者团队。我们完成任务和写资料都有相当不同的风格，但最后，我们不同的写作风格和材料使我们感到，我们正好反映出了微软多元化的测试团队。 我们经常开玩笑说，BJ是教授，肯设法成为史学家和讲故事者，而我却是吸收信息，并且陈述事实。 虽然我们每个人都分别负责几章的写作，但是我们都对另外两个人的章节有所贡献，所以，本书融合了我们3位作者的风格。
ⅩⅪ当“写书”任务的重担压在肩上时，我不可能描述出每个生活中小挫折怎么会变得硕大。 从编写这本书开始，我接手了肯的老工作，担任微软测试卓越部门的总监。我自己都不知道为什么会决定在写书过程中，还承担这样一个全新的、极具挑战性的工作。 然而，事实上，承担的这个角色迫使我深入了解一些微软测试领导的内幕，对这本书的写作帮助极大。
在写这本书时，最大的担心是，我知道有很多可写的内容，但是必须要省略。微软有9000多个测试人员。 这本书里谈到了微软测试人员做的大多数事情，但也有很多微软的测试人员做的很“酷”事，不可能全部包括在这本书里。此外，这本书谈到的几乎每个主题都可能有大大小小的变异。当讲我们认为是最重要的有关测试的故事时，我们尽量设法捕捉许多不同的想法。我也要承认对于这本书的书名，我有点紧张。“微软的软件测试之道”表面意义可能蕴含着在这本书写的一切，都是每一位微软测试人员做到的，那可是不切实的。微软公司有着许么多测试人员和多种多样的软件产品，我们根本不可能确切地写出能代表每一位微软测试人员的测试方法和实践。所以，我们不得不妥协。这本书只包括微软多数测试人员使用的、普遍的测试实践、工具和技术。并非每个团队都实际做了我们书里写的一切，但是多数还是适用的。我们选择写在这本书里的，都是成功地用在测试微软产品实践的，因此这本书的内容是我们所知道的、微软实践中可行的信息汇总。
最后，我认为我们成功了，但是作为测试人员，我们知道我们可以做得更好。可惜的是，已经到发布的时间了，不过我们已经有了产品发布后的支持计划。如果您对与这本书作者谈论的任何主题感兴趣，欢迎访问我们的网站：wwwhwtsamcom。 我们乐于听取您的想法。

阿伦·培智 (Alan Page)　
本书的目标读者
这本书是为所有对微软测试方式感兴趣的、或为那些想知道更多关于微软怎样进行测试的人写的。这本书不是替代任何其他关于软件测试的写作。相反，它描述了微软怎么运用很多已知的测试技术和方法改进软件产品及质量。
微软的测试人员可能会对本书很感兴趣，因为它描述了微软公司的实用方法和技术。想知道关于微软测试的非测试人员也会对本书感兴趣。
本书的组织方式
这本书是以使读者熟悉微软产品、微软工程师、微软测试人员、测试的作用和对软件工程的通常做法作为开始。第二部分讨论许多在微软常用的测试实践和工具。第三部分探讨某些我们工作中使用过的工具和系统。书的最后一部分探讨在微软测试和质量的未来方向，以及我们打算怎么创造未来。
ⅩⅫ第一部分关于微软
第1章微软的软件工程
第2章微软的软件测试工程师
第3章工程生命周期
第二部分关于测试
第4章软件测试用例设计的实用方法
第5章功能测试技术
第6章结构测试技术
第7章用代码复杂度分析风险
第8章基于模型的测试
第三部分测试工具和系统
第9章缺陷和测试用例管理
第10章测试自动化
第11章非功能测试
第12章其他工具
第13章用户反馈系统
第14章测试软件加服务
第四部分关于未来
第15章今天解决明天的问题
第16章构建未来
网上的更多内容
当这本书有补充作用的新增或更新材料出现时，我们会张贴在微软新闻在线软件开发者和工具的网站上。 这类材料也许包括更新的内容、文章、内容的链接、勘误表、样章和其他信息。 这个网站的地址是wwwmicrosoftcom/learning/books/online/developer，并且会周期性地更新。
更多微软测试的故事和花絮将张贴在wwwhwtsamcom。
本书提供的支持
如果您有关于这本书的评论、疑问或者想法，却在查询网站过程中得不到答案，那么请通过电子邮件与微软出版社取得联系：
mspinput@microsoftcom.
或邮寄到：
Microsoft Press
Attn: How We Test Software at Microsoft Editor
One Microsoft Way
Redmond, WA 980526399
请注意以上提供的地址并非微软提供软件产品支持的联系地址。ⅩⅩⅢ

待补

（美）Alan Page; Ken Johnston; Bj Rollison 著：暂无简介

张奭 高博 欧琼 赵勇 等译：暂无简介

2008年5月里一个阳光明媚的中午，我去找在微软的职业指导Anu进行一个月一次的会面。她是微软杰出工程团队（Engineering Excellence Group）负责测试工程师技能培训、指导等工作的非常有经验的首席测试经理。当时我和几位华裔同事正在写第二本书《微软360度：成功与成长》，她上来就问我写完了没有？我说还没有。她说她上司Alan Page他们的关于微软测试的书就要写完了，我一听眼睛顿时一亮，一拍桌子说，太好了，我要经得他同意把这本书翻成中文！因为业界对微软软件测试的重视和投入早有所闻，很多人都想知道微软到底是怎么做测试的。这本书如果出版不就是雪中送炭么。
我回到办公室就给Alan发了邮件征求他的许可。他马上就回复说同意，不过版权是微软出版社的，还要经他们同意。在和微软中国负责出版物的有关人员沟通了一段时间以后，我就盼着英文版原著赶快出来，因为亚马逊图书网站已经登出了书的消息，可以预订11月才出版的书。可是到了2008年11月了，已经看到英文书在网上可以现购了，我还是没收到出版社或微软负责翻译书的负责人的消息。这样又过了一周，突然12月底的一天想起查查垃圾邮箱，才发现我等的同意出版的邮件一周前就到了。
马上行动！按照出版社陈编辑的要求，要先试译几个部分（总共不到6页）。我两天内就翻译好了，感觉良好。马上就把文档发给出版社了。等了两天，收到出版社编辑修改过的版本。一打开那文档，整页全是红色批注。第一反应就是：我这英文翻译水平有这么差吗？仔细看过后，才知道原来我的翻译没有按照整句、甚至几句的意思翻译，而是字面翻译。应该是按意思、按我们的经验翻译。我的灵感来了，马上把编辑改过的版本又痛痛快快地改了一次。这一次的翻译版本很顺利地通过了“考试”，也成为了这本书翻译质量的“样本章节”。于是出版社就同意和我签合同，由我主持翻译这本书。
领导这本书的翻译过程和在微软管理一个测试项目一样，我先制定了时间表、里程碑阶段完成目标、工作量估计等。接下去是建立团队。本打算让和我合作写《微软360度：企业和文化》或《微软360度：成功与成长》的微软总部的伙伴做助手的，但因为机械工业出版社和微软出版社在中国的负责人建议我当项目经理, 由中软公司的高博做副手，因为他有很多英文书籍翻译的经验。于是我就和高博一同负责这个译书项目了。高博负责在中国的团队成员，我是总负责并负责在美国的团队。
我首先创建了专门网点，邮箱地址，还准备了一个PPT，把想让大家知道的要点全放在里面，包括背景信息，划分的阶段里程碑要求、参加译书团队成员应该遵守的规定等等。2009年1月14日，《微软的软件测试之道》译书项目正式启动了。我先发邮件给两本微软360度系列书的作者，共30人左右。但因为这本是测试专业书，能参加的只有几个人。于是我又打电话邀请了我认识的搞测试的朋友。其中朱建俊当时是微软在上海一个测试团队的经理，他说他的团队可以负责一两章的翻译工作。其他愿意参与的人有的也介绍微软华协的测试人员参加。就这样，我们一共有近30人参加了本书翻译工作。
这本书有16章。第一里程碑完成3章，我指派了三位又有写书经验，又非常认真负责的人做“主编”。他们是钟颂东、欧琼和郑洪流。每一章的主编“招聘”自己的队员。他们认真负责地带领近15个队员一起翻译了前3章，其中多数还是第一次参加翻译书。第二里程碑有10章，大家可以挑选一章做主编。我们每个月有一次碰头会，安排在晚5点半至7点，用以交流进度，讨论出现的问题。特别是这么多人翻译，背景和水平都不同，有很多翻译的词语存在一致性的问题。为此常常热烈讨论。因为大家都是没来得及吃晚饭就来的，所以我每次还会带一些水饺和点心让大家垫垫饥。
三十几人中，有些有突出贡献的。比如赵勇是我们的“明星”，他翻译文章又快又好，而且非常热心帮助有需要的章节和其他另外的任务。最后阶段所有翻译章节归总、整理、审阅都有他很大的功劳。欧琼是我的替补，我不在美国时，她全权负责。特别在我离开微软调到iConnect公司以后，有几周时间没法进微软的内网，也收不到内部的邮件。欧琼和赵勇就负起责任把最后阶段的翻译工作协调好。所以到后来，这本书的领导班子自然地明确了除了我还包括高博、欧琼和赵勇。由于我的工作变更，而且要常回中国工作，大家都想早点完成，所以原定于第三个里程碑翻译的两章第二个里程碑就开始了。赵勇积极帮助这两章的主编钟颂东、王文婧、顾广宇一起提前完成了任务。就这样经过几个月的辛勤努力，本定于5月23日发布的最后版本提早在5月5日就寄给机械工业出版社了。
从1月14日启动项目到5月5日交付整个译稿，只有短短的三个多月！我们这本书翻译工作的顺利和提前交付，是微软华协员工和朋友团队协作、集体智慧和努力创造的又一个典型！比如我们这本书的书名就是经过几次发邮件提议，讨论，评论，投票之后的定名。我们都觉得虽然翻译图书用的都是下班以后或周末时间，挺辛苦，但我们每一个参与的人，都学到很多新知识，对微软测试更加了解。这是一本将对软件测试领域产生深远影响的图书，我们也对能成为这本书的翻译团队的一员而感到自豪！以下的列表是我们团队成员对不同章节不同贡献的一个总结。章节章节主编章节副主编第1章微软的软件工程 郑洪流王文婧、 顾广宇、贾劲、张帜第2章微软的软件测试工程师欧琼陈思清、蒋晓华、于国军、冯志强第3章工程生命周期钟颂东赵勇、张奭、吕灵第4章软件测试用例设计的实用方法蒋晓华，刘俐第5章功能测试技术高博第6章结构测试技术吕灵张奭、顾广宇、王文婧第7章用代码复杂性分析风险高博、林俊彦邱扬、杜彬、李晶、邓安桐第8章基于模型的测试朱健俊、高博、林俊彦常小红、李晶（续）
章节章节主编章节副主编第9章缺陷和测试用例管理梁梅、周仲哲张奭、张帜第10章测试自动化孙展波韩雪灵、鲍臣礼第11章非功能测试钟颂东赵勇、郑洪流、高博第12章其他工具贾劲方敏、欧琼、张胜第13章用户反馈系统方敏、钟颂东第14章测试软件加服务欧琼贾劲、于国军、陈思清、冯志强第15章今天解决明天的问题赵勇钟颂东第16章构建未来王文婧、顾广宇赵勇、鲍臣礼中英文对照术语表朱健俊、高博林俊彦、邱扬、李晶、邓安桐、常小红
亲爱的读者们：希望大家通过研读这本书，能够更加深入了解微软的软件测试理念和流程，并从中找出适合各自软件项目、产品或服务的最佳方法和实践，以提高软件测试技能和效率。让我们一起为我国软件测试人才培养和整体水平的提高而共同努力吧！
在本书即将付梓之际，我谨代表译书的全体团队成员再一次感谢原著者精彩的论述，使我们得到了进一步学习的机会，也向微软出版社及机械出版社同仁们表示诚挚的谢意！

张奭
2009年8月

献辞
业界专家的评论
微软内部专家的评论
致谢
译者序
译者介绍
前言


第一部分关于微软
第1章微软的软件工程
11微软的愿景和价值观，为何我们
“爱微软”
12微软是大型的软件工程公司
13拓展大型且高效的业务
14在“大”公司中做 “小”项目
15聘用多种类型的工程师
16全球化的软件开发公司
17本章小结第2章微软的软件测试工程师
21职位名称的含义
22微软测试工程师的职称并非一直
都是SDET
23我需要更多的测试工程师，立刻
就要
231校园招聘
232业界招聘
24学习如何成为微软的SDET
25微软工程师的职业发展
26测试职种的发展道路
261测试架构师
262测试独立贡献者
263成为管理者并不意味着升职
264测试经理
27本章小结第3章工程生命周期
31微软的软件工程
311传统软件工程模型
312里程碑模式
313微软的敏捷开发
314宏观视野
32流程改进
33从“作战室”发布软件
34本章小结


第二部分关于测试
第4章软件测试用例设计的
实用方法
41实践良好的软件设计和测试设计
42使用测试模式
43估计测试时间
44从测试开始
441搜出问题
442制定测试策略
45考虑可测试性
46同时用好数据和坏数据进行测试
47测试用例设计中应考虑的
其他因素
471黑盒测试、白盒测试和灰盒
测试
472微软的探索性测试
48本章小结第5章功能测试技术
ⅩⅩⅤ51功能测试的需求
52等价类划分
521变量分解
522等价类划分实战
523参数子集分析
524等价类划分测试
525等价类划分小结
53边界值分析
531定义边界测试
532边界值分析：一个全新
的公式
533隐性边界
534边界值分析小结
54组合分析
541组合测试的途径
542组合分析实践
543组合分析的有效性
544组合分析小结
55本章小结第6章结构测试技术
61块测试
62判定测试
63条件测试
64基础路径测试
65本章小结第7章用代码复杂度分析风险
71风险行业
72复杂问题
73测量回路复杂度
731Halstead度量
732面向对象的度量
733回路复杂度高并不表示
缺陷累累
74如何利用复杂度度量
75本章小结第8章基于模型的测试
81采用模型测试
811设计模型
812模型化软件
813建立有限状态模型
814模型自动化
82不带测试的建模
821贝叶斯图解模型
822Petri网
83微软的基于模型的测试工具
831Spec Explorer
832语言和引擎
833建模提示
84本章小结
85推荐资料和工具


第三部分测试工具和系统
第9章缺陷和测试用例管理
91缺陷工作流程
92缺陷的跟踪
921一个缺陷的生命周期
922缺陷跟踪系统的特征
923为什么撰写缺陷报告
924解剖缺陷报告
925缺陷会审
926缺陷报告中常见的错误
927数据使用
928何时不能使用缺陷数据：缺陷
作为绩效度量
929缺陷门槛
93测试用例管理
931什么是测试用例
932测试用例的价值
933剖析测试用例
934测试用例误区
94管理测试用例
941测试用例和测试点：计算
测试用例
942跟踪和解释测试结果
95本章小结ⅩⅩⅥ第10章测试自动化
101自动化的价值
102用户界面自动化
103自动化测试包括什么
104微软中的“SEARCH”
1041设置
1042执行
1043分析
1044报告
1045清理
1046帮助
105让自动化测试跑起来
1051把一切装配起来
1052大型自动化测试系统
1053测试自动化中的常见错误
106本章小结第11章非功能测试
111功能之外
112属性测试
113性能测试
114压力测试
1141分布式压力测试
1142分布式压力架构
1143多客户端压力测试的特点
115兼容性测试
1151应用软件库
1152应用程序检验器
116吃我们自己的“狗食”
117适用性测试
1171可达性角色
1172可达性测试
1173微软主动式辅助（MSAA）
测试工具
118可用性测试
119安全测试
1191威胁建模
1192模糊测试
1110本章小结第12章其他工具
121代码改动量
122一切尽在掌握
1221追踪变更
1222什么改变了
1223为何改变
1224集中型的源代码管理控制
123软件构建
124静态分析
1241本机代码分析
1242托管代码分析
1243工具只是工具
1244测试代码分析
1245测试代码也属于产品代码
125更多工具
1251解决特定问题的工具
1252服务大众的工具
126本章小结第13章用户反馈系统
131测试和质量
1311测试提供了信息
1312质量感知
132用户救援
133Windows错误报告（WER）
1331WER的工作原理
1332填入存储桶
1333清空存储桶
1334测试和WER
134微笑，微软和你一同微笑
135连接用户
136本章小结第14章测试软件加服务
141第一部分关于服务
1411微软的服务战略
1412业务重心向Internet服务
迁移
1413从大规模成长为超大规模
1414能源是成长的瓶颈
1415服务与盒装软件
1416从单机软件到多层次服务
142第二部分测试软件加服务
1421创新的浪潮
1422设计合适的软件加服务
测试方法
1423软件加服务测试技术
143另一些关于软件加服务的
重要思想
1431持续质量提高计划
1432我见过的被忽略的常见
缺陷
144本章小结


第四部分关于未来
第15章今天解决明天的问题
151自动失败分析
1511战胜分析瘫痪
1512匹配游戏
1513好的日志记录实践
1514日志文件剖析
1515集成AFA
152机器虚拟化
1521虚拟化的好处
1522虚拟机测试场景
1523当测试时发生失败
1524不建议使用的测试场景
153代码审查和检视
1531代码审查的类型
1532核查清单
1533其他考虑
1534审查的两面性
154工具无处不在
1541提炼、重用、回收
1542问题在哪
1543开放式的开发
155本章小结第16章构建未来
161前瞻性思考的需求
1611通过追本溯源进行前瞻性
思考
1612努力培养质量文化
1613测试和质量保证
1614质量该谁管
1615质量成本
1616测试的新角色
162测试领域的领导力
1621微软测试领导团队
1622测试领导团队主席
1623测试领导力在行动
1624测试架构师团队
163卓越测试
1631共享
1632帮助
1633沟通
1634关注未来
1635微软公司卓越测试主任
1636三方面的领导
164为未来创新中英文对照术语表ⅩⅩⅦ