微软的软件测试之道(微软员工作人手一册实用力作，张亚勤博士写序推荐)
基本信息
- 原书名： How We Test Software at Microsoft
- 原出版社： Microsoft Press
- 作者： (美)Alan PageKen JohnstonBj Rollison
- 译者： 张奭 高博 欧琼 赵勇
- 丛书名： Microsoft核心技术丛书
- 出版社：机械工业出版社
- ISBN：9787111277538
- 上架时间：2009-9-15
- 出版日期：2009 年9月
- 开本：16开
- 页码：313
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 软件质量、软件测试及维护
推荐阅读
作译者回到顶部↑
评论交流
共有11人开贴评论 18人参与评论 6人参与打分 查看
评价等级：
发表于：2010-3-13 13:56:00
初听说此书时，心里有些抵触，的确，近年来微软，尤其是微软中国，出了许多书，但大多泛泛之谈，缺乏实质性的帮助。战略说的多而战术谈得少。作为软件测试专业的学生，作为立志于从事软件测试一生的测试工程师，从进校，工作，到现在，学习过许多经典的测试书籍。所以当时觉得，这本书也许同样是本鸡肋。
后来，无意中翻了翻别的买的这本书，感觉眼睛一亮，于是自己也买了一本，刚看完。
作为赴微软测试团队的一员，我认为初学者还是先看看《计算机软件测试》、《软件测试》等几本经典入门书，然后再看本书。
此书由三位微软大牛协作而成，几乎囊括了微软最基本的测试之道，初学者看过或许会产生没学到东西的错觉，但如果你测试基础已经扎实，测试实践很多，开始在实战中思考，总结，反思，这时候你再来看本书，来看牛人的反思和总结，对你测试思维的提升绝对可以说是质的飞跃。
作为一名测试工程师，我永远不会给谁当托，包括微软。
但凭良心说，这本书适合那些处于中级瓶颈的测试人员，相信大家都有所收获，也希望大家能多多交流！
一家之言，欢迎赐教！
后来，无意中翻了翻别的买的这本书，感觉眼睛一亮，于是自己也买了一本，刚看完。
作为赴微软测试团队的一员，我认为初学者还是先看看《计算机软件测试》、《软件测试》等几本经典入门书，然后再看本书。
此书由三位微软大牛协作而成，几乎囊括了微软最基本的测试之道，初学者看过或许会产生没学到东西的错觉，但如果你测试基础已经扎实，测试实践很多，开始在实战中思考，总结，反思，这时候你再来看本书，来看牛人的反思和总结，对你测试思维的提升绝对可以说是质的飞跃。
作为一名测试工程师，我永远不会给谁当托，包括微软。
但凭良心说，这本书适合那些处于中级瓶颈的测试人员，相信大家都有所收获，也希望大家能多多交流！
一家之言，欢迎赐教！
)
评价等级：
发表于：2009-9-22 13:06:00
该书的前三章讨论了微软的软件开发方法。相比《微软360度——成功与成长》（该书的作者也是《微软测试之道》的译者）的洋洋洒洒，该书言简意赅，某些观点更加深邃。例如，为什么Partner SDET是测试职业发展的顶端，在此之上的Distinguished Engineer不再区分具体角色；敏捷开发的特征是"quality ownership throughout the product cycle"（窃以为这是敏捷的核心基础之一）。这种观察力，也许来自对多个团队、多个项目、多种开发方法的体会与观察。作者所处的团队在微软是一种“内部的局外人”，视角较一线的工程师更开阔。
该书随后开始介绍一些基本概念与方法，如典型的功能测试技术（如等价类划分）。这也许是该书的矛盾所在，有些内容颇有深意，有经验的读者才能体会其中含义，有些内容又比较浅显，读过Software Testing (Ron Patton), Software Testing A Craftsman's Approach (Paul C.Jorgensen)（都有中文版，China-pub有售）的人都有似曾相识的感觉。不过温故而知新，而且看似简单的技术也不是那么简单。书中关于等价类测试的例子就很有趣，体现了作者的功力。
该书在美国亚马逊上有好评，也有恶评。好评多来自微软的SDET，看来微软的内部培训和交流亟待加强，许多好的经验不能快速地传播。有一个恶评很尖锐，指出该书没有回答他急切想知道的问题，如“What sort of scripting languages are used for automation testing of Office or Windows or any other MS product?”。这也是我觉得遗憾的地方：该书对具体项目的具体技术解释得太少。虽然不同的项目往往有不同的测试方法（我猜测Word和Excel就有许多不同），但是Office这样庞大的项目如何测试、如何组织测试架构、如何组织测试自动化等问题是非常重要、也非常有启发性的。
好在这本书提供了小故事，讲述了微软软件开发中的点点滴滴。在我看来，这些故事是全书的精华所在。软件测试的工程师一般都掌握大部分常见的测试技术，欠缺的是面对复杂情况的经验。他山之石可以攻玉，作者分享的故事是很好的起点。
至于书的分量，我见过微软出版社的原书。厚度只比《Code Complete 2e》薄一些。机械出版社的排版偏紧，导致中文版页码偏少。如果按照《代码大全 2e》的制作方式，相信厚度与价格都会有所增长。不过，即便是小成本运作，图书制作还是要用心。作者在MSDN上有Blog，中文版也没有介绍。
平心而论，这本书还是颇有参考价值的，理论与实践也结合得比较好。值得一读。
该书随后开始介绍一些基本概念与方法，如典型的功能测试技术（如等价类划分）。这也许是该书的矛盾所在，有些内容颇有深意，有经验的读者才能体会其中含义，有些内容又比较浅显，读过Software Testing (Ron Patton), Software Testing A Craftsman's Approach (Paul C.Jorgensen)（都有中文版，China-pub有售）的人都有似曾相识的感觉。不过温故而知新，而且看似简单的技术也不是那么简单。书中关于等价类测试的例子就很有趣，体现了作者的功力。
该书在美国亚马逊上有好评，也有恶评。好评多来自微软的SDET，看来微软的内部培训和交流亟待加强，许多好的经验不能快速地传播。有一个恶评很尖锐，指出该书没有回答他急切想知道的问题，如“What sort of scripting languages are used for automation testing of Office or Windows or any other MS product?”。这也是我觉得遗憾的地方：该书对具体项目的具体技术解释得太少。虽然不同的项目往往有不同的测试方法（我猜测Word和Excel就有许多不同），但是Office这样庞大的项目如何测试、如何组织测试架构、如何组织测试自动化等问题是非常重要、也非常有启发性的。
好在这本书提供了小故事，讲述了微软软件开发中的点点滴滴。在我看来，这些故事是全书的精华所在。软件测试的工程师一般都掌握大部分常见的测试技术，欠缺的是面对复杂情况的经验。他山之石可以攻玉，作者分享的故事是很好的起点。
至于书的分量，我见过微软出版社的原书。厚度只比《Code Complete 2e》薄一些。机械出版社的排版偏紧，导致中文版页码偏少。如果按照《代码大全 2e》的制作方式，相信厚度与价格都会有所增长。不过，即便是小成本运作，图书制作还是要用心。作者在MSDN上有Blog，中文版也没有介绍。
平心而论，这本书还是颇有参考价值的，理论与实践也结合得比较好。值得一读。
评价等级：
发表于：2009-9-21 0:59:00
我是本书的译者之一，参与了本书翻译的全过程。我想说的是，这本书无论是从原著的内容角度来说，还是从翻译团队的组织、工作和质量控制而言，都可以说是近年来的精品之作。有一些背后的东西，我写了一篇文字，请赐教：http://social.gaobo.org/topic.php?id=10
To smchinapub：
除了做产品、做测试之外，我想不明白IT人才还可以做点什么。如果说做测试让人觉得有不如做开发之嫌，我犹可以解释一番，但如果连做产品都一齐不要，那我真的是觉得不知道你想表达的重点何在了。单就测试来说，我翻译这本书的过程中感受得最深的就是差距——因为我也在各种规模的企业里面做过开发、测试和项目管理相关的工作，一个很深刻的感觉就是目前国内除了像腾讯、金山和百度这样有实力的软件企业以外，大多数的公司写出来的代码或做出来的产品甚至都还不到“可测试”（testable）的程度，一动手就缺陷百出。感觉上如果按照微软项目的要求来写测试报告，那每天可以不用做别的事了，三头六臂也不够用。所以，我的建议反而是借鉴台湾模式，从代工做起，从最基本的测试做起——踏踏实实地学习微软这样的国际型大企业的做事态度和做事方法，然后用之于自己的软件产品的开发和测试实践，真正地提高自己的研发水平，做出具有国际品质、有国际竞争力的产品。微软公司成就今天的事业，是和他的工程师文化分不开的。我记得书中翻译的有一个bug居然是“通过file bug向女友求婚”，这说明人家已经做到多么有文化的一个程度了，真正地把工作融入成了生活甚至生命的一部分，做测试也快乐无比的程度，所以他们可以做出那么棒的产品来。
To xxxxxx2：
你的批评是有道理的，事实上如果由我个人决定，我可能也会选择自己一个人来译整本书。可是那样一来，可能就意味着本书会再拖上一两年才能和读者见面。所以，我们选择了团队工作的方式，加速这个进程。正如软件开发和测试团队一样，团队工作意味着沟通成本的增加，但同时也是集思广益，互查不足。我个人译了全书的1/5左右，也就是60页左右，但我们的这个团队很多人的参与实际上就是在做测试的工作——他们读我们的文字，给出审阅意见，督促我们修改。我想说的是，出现在译者名录中的人数都是实实在在地译了至少5页的作者，参与对本书贡献的人数还远不止这些。但是，我们工作的方式也保证了风格和术语的统一是最大限度地进行了，也促使了本书很快地与中国读者见面。当然，书中必然还存在很多缺陷和错误，像软件一样，我们并非推向市场就停止了努力。可以透露的是，我们将于10月31日前统计缺陷和勘误，并争取在第2版时加以修正（service pack 1）。欢迎广大读者批评指正，提出具体的错误和意见，我们会为你们不懈努力，以最好的品质呈现给你们。希望更多的读者能够支持我们，给我们以鼓励，您在此处的好评也是我们努力的最大动力和期望的结果！
To smchinapub：
除了做产品、做测试之外，我想不明白IT人才还可以做点什么。如果说做测试让人觉得有不如做开发之嫌，我犹可以解释一番，但如果连做产品都一齐不要，那我真的是觉得不知道你想表达的重点何在了。单就测试来说，我翻译这本书的过程中感受得最深的就是差距——因为我也在各种规模的企业里面做过开发、测试和项目管理相关的工作，一个很深刻的感觉就是目前国内除了像腾讯、金山和百度这样有实力的软件企业以外，大多数的公司写出来的代码或做出来的产品甚至都还不到“可测试”（testable）的程度，一动手就缺陷百出。感觉上如果按照微软项目的要求来写测试报告，那每天可以不用做别的事了，三头六臂也不够用。所以，我的建议反而是借鉴台湾模式，从代工做起，从最基本的测试做起——踏踏实实地学习微软这样的国际型大企业的做事态度和做事方法，然后用之于自己的软件产品的开发和测试实践，真正地提高自己的研发水平，做出具有国际品质、有国际竞争力的产品。微软公司成就今天的事业，是和他的工程师文化分不开的。我记得书中翻译的有一个bug居然是“通过file bug向女友求婚”，这说明人家已经做到多么有文化的一个程度了，真正地把工作融入成了生活甚至生命的一部分，做测试也快乐无比的程度，所以他们可以做出那么棒的产品来。
To xxxxxx2：
你的批评是有道理的，事实上如果由我个人决定，我可能也会选择自己一个人来译整本书。可是那样一来，可能就意味着本书会再拖上一两年才能和读者见面。所以，我们选择了团队工作的方式，加速这个进程。正如软件开发和测试团队一样，团队工作意味着沟通成本的增加，但同时也是集思广益，互查不足。我个人译了全书的1/5左右，也就是60页左右，但我们的这个团队很多人的参与实际上就是在做测试的工作——他们读我们的文字，给出审阅意见，督促我们修改。我想说的是，出现在译者名录中的人数都是实实在在地译了至少5页的作者，参与对本书贡献的人数还远不止这些。但是，我们工作的方式也保证了风格和术语的统一是最大限度地进行了，也促使了本书很快地与中国读者见面。当然，书中必然还存在很多缺陷和错误，像软件一样，我们并非推向市场就停止了努力。可以透露的是，我们将于10月31日前统计缺陷和勘误，并争取在第2版时加以修正（service pack 1）。欢迎广大读者批评指正，提出具体的错误和意见，我们会为你们不懈努力，以最好的品质呈现给你们。希望更多的读者能够支持我们，给我们以鼓励，您在此处的好评也是我们努力的最大动力和期望的结果！
加载中...| 我要写评论 |
| 查看所有评论交流(共11条) |
