微软的软件测试之道(Microsoft核心技术丛书)
点此进入淘宝搜索页搜索分類: 图书,计算机与互联网,软件工程及软件方法学,软件工程理论,
品牌: 培智(Page.A.)
基本信息·出版社：机械工业出版社
·页码：313 页
·出版日期：2009年09月
·ISBN：9787111277538
·条形码：9787111277538
·包装版本：第1版
·装帧：平装
·开本：16
·正文语种：中文
·丛书名：Microsoft核心技术丛书
产品信息有问题吗？请帮我们更新产品信息。
内容简介《微软的软件测试之道》是以使读者熟悉微软产品、微软工程师、微软测试人员、测试的作用和对软件工程的通常做法作为开始。书的第二部分讨论许多在微软常用的测试实践和工具。 书的第三部分探讨某些我们工作中使用过的工具和系统。书的最后一部分探讨在微软测试和质量的未来方向，以及我们打算怎么创造未来。《微软的软件测试之道》结构清晰，内容详实，可作为广大软件测试人员的参考用书。
作者简介Alan page，微软测试卓越工程总监。管理微软的测试技术培训并对微软的测试工程师提供咨询。他是微软最早的测试架构师之一，曾经参与Windows和Windows CE多个版本的测试开发工作。
Ken Johnston，微软Office在线平台和运营总经理。他曾担任微软测试主管，测试经理以及测试卓越工程总监。
BJ Rolllson，卓越工程的测试架构师。他曾参与过多种产品的测试开发工作并担任过测试总监。他还经常参与软件杂志的写作和学术会议的演讲。并在大学里讲授软件测试。
译者简介：
张奭，美国iConnect公司卓越工程与管理总经理，中国软件行业协会培训中心执行主任，南京一通美公司执行总裁。曾是微软经验丰富的测试主管。有近12年微软软件测试、发布、项目管理、内训和团队管理经验。两次获得微软员工杰出贡献奖（Gold Star Award）。曾任微软卓越管理领导团队的成员、微软华协理事会成员、微软第一届亚太地区员工领导和发展大会职业发展委员会主席、西雅图地区IEEE理事会成员。张奭在北京师范大学获硕士学位，美国纽约州立大学获博士学位。
媒体推荐“一本了不起的书——所有软件测试人员必备的书。你会从中学到微软的软件测试方法和他们对软件测试未来的展望。”
——Siemens AG首席工程师 Peter Zimmerer
“多么激动人心的组合，杰出的测试工程师讲述软件测试故事，而这些都发生在一家要应付世界上最困难的软件测试问题的公司。”
——《How to Break Software》作者James Whittaker
“微软在测试和测试工程师上的投入是惊人的。本书讲述了成功和挑战，所有软件测试机构都应该学习。”
——《A Practitioner's Guide to Software Test Design》作者Lee Copeland
编辑推荐《微软的软件测试之道》由机械工业出版社出版。
微软雇佣的软件测试人员和软件开发人员一样多。这个事实也许会让你吃惊。但你不会惊奇微软对测试流程，以及这个流程在微软多种多样的超过150种的产品的质量管理中所起的作用的强调。
本书由微软的三位卓越的专业测试人员撰写，分享了被全公司约9000测试工程师所应用和使用的最佳实践、测试工具和测试系统。微软的从业者讲述如何设计和管理软件测试，他们的培训和职业发展方法，以及他们是如何看待未来的挑战。最重要的是，你可以获得实用的见解，并应用到你的工作中，得到更好的结果。
探索怎样：
设计有效的测试用例，并在整个的产品开发周期中运行。
最小限度地减少功能测试的花费和风险，知道何时应用结构性的技巧。
衡量代码复杂性来发现软件缺陷和可能的维护问题。
用模型来产生测试用例，发现软件意想不到的表现并管理风险。
知道何时采用自动测试用例，为长期使用来设计自动测试用例和怎样接入自动测试的基础架构。
观察杰出测试工程师的特征——和他们所应用的运行测试用例，探查系统以及有效跟踪进度的工具。
探查由于测试软件服务与测试盒装软件不同所带来的挑战。
目录
献辞
业界专家的评论
微软内部专家的评论
致谢
译者序
译者介绍
前言
第一部分 关于微软
第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 本章小结
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.1 Halstead度量
7.3.2 面向对象的度量
7.3.3 回路复杂度高并不表示缺陷累累
7.4 如何利用复杂度度量
7.5 本章小结
第8章 基于模型的测试
8.1 采用模型测试
8.1.1 设计模型
8.1 一模型化软件
8.1.3 建立有限状态模型
8.1.4 模型自动化
8.2 不带测试的建模
8.2.1 贝叶斯图解模型
8.2.2 Petri网
8.3 微软的基于模型的测试工具
8.3.1 SpecExplorer
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 f用性测试
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.3 Windows错误报告(WER)
13.3.1 WER的工作原理
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 业务重心向Intenet服务迁移
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 为未来创新
中英文对照术语表
……[看更多目录]
序言2008年5月里一个阳光明媚的中午，我去找在微软的职业指导Anu进行一个月一次的会面。她是微软杰出工程团队（Engineering Excellence Group）负责测试工程师技能培训、指导等工作的非常有经验的首席测试经理。当时我和几位华裔同事正在写第二本书《微软360度：成功与成长》，她上来就问我写完了没有？我说还没有。她说她上司Alan Page他们的关于微软测试的书就要写完了，我一听眼睛顿时一亮，一拍桌子说，太好了，我要经得他同意把这本书翻成中文！因为业界对微软软件测试的重视和投入早有所闻，很多人都想知道微软到底是怎么做测试的。这本书如果出版不就是雪中送炭么。
我回到办公室就给Alan发了邮件征求他的许可。他马上就回复说同意，不过版权是微软出版社的，还要经他们同意。在和微软中国负责出版物的有关人员沟通了一段时间以后，我就盼着英文版原著赶快出来，因为亚马逊图书网站已经登出了书的消息，可以预订11月才出版的书。可是到了2008年11月了，已经看到英文书在网上可以现购了，我还是没收到出版社或微软负责翻译书的负责人的消息。这样又过了一周，突然12月底的一天想起查查垃圾邮箱，才发现我等的同意出版的邮件一周前就到了。
马上行动！按照出版社陈编辑的要求，要先试译几个部分（总共不到6页）。我两天内就翻译好了，感觉良好。马上就把文档发给出版社了。等了两天，收到出版社编辑修改过的版本。一打开那文档，整页全是红色批注。第一反应就是：我这英文翻译水平有这么差吗？仔细看过后，才知道原来我的翻译没有按照整句、甚至几句的意思翻译，而是字面翻译。应该是按意思、按我们的经验翻译。我的灵感来了，马上把编辑改过的版本又痛痛快快地改了一次。这一次的翻译版本很顺利地通过了“考试”，也成为了这本书翻译质量的“样本章节”。于是出版社就同意和我签合同，由我主持翻译这本书。
文摘插图：
第1章微软的软件工程
肯·约翰斯顿
本书的第一部分，也就是第1章到第3章，将介绍微软的基本情况，包括微软的目标、微软如何组织软件产品开发，以及微软如何推出产品。本章的大多数内容都广为公众所知，但也提供了一些微软的内部信息。
已经有很多书籍、文章和网站都详尽地介绍了微软的历史，本书将着重介绍微软的软件工程，这将有助于读者更深入地了解微软的软件测试技术和方法。我们介绍的微软的历史、愿景以及企业目标，对于我们在以后章节里讨论的所有软件测试方法和工具有重要的影响。
1.1 微软的愿景和价值观，为何我们“爱微软"
除了足球世界杯或者板球赛事，让理性的工程师表现得热情奔放是比较难的。微软的工程师也是如此。不过，有一件事可能例外。
在每年的十月初前后，位于美国华盛顿州雷德蒙德（Redmond）市的微软总部，都召开全体员工会议。届时，将有近两万名员工乘坐几十辆大客车前往Mariners棒球队的主场Safeco体育馆出席会议，此外，还有数万名员工在线参加该年会。
年会上，最后一个演讲者总是微软的执行总裁斯蒂夫·巴尔默（Steve Ballmer）。在雷鸣般的欢呼声和响亮的摇滚音乐声（比如《洛奇》电影里的“虎眼”的音乐）中，斯蒂夫快速跑上主席台，他热情奔放，陈词激昂，把与会者的情绪推向高潮。然后，他跑下主席台，到观众席和大家互动。当穿过观众席中的人群时，他不停地做出象征胜利的手势，时不时和大家击掌相庆，受到很多员工热情的回应。他在途中会多次停留，继续激发大家的热情。回到主席台后，平复一下呼吸，他会带领大家一起齐声呼喊：“我爱微软！”可以很容易地在’www.live.com网站找到这类录像，只要搜索“Steve Ballmer公司会议”就可以了。
