How We Test Software at Microsoft 读书笔记 （一）

 

 

第一次听说这本书是一位同事的推荐，然后去amazon.cn上找了找，居然发现有原版（不是影印版啊，拿到手上感觉完全不一样啊），才100多块，于是 就买了。看了前面几章，觉得很不错，关于测试的很多疑惑他们给出了微软的答案，是很好的参考。建议读一下第一部分，关于微软的软件测试，if you plan to take software testing as a profession seriousy, 因为很难找到更好的参考了。
其 实个人不是很认同MS想一统天下什么都做的产品策略，但是就engineering而言，MS还是很值得敬佩的。在软件测试领域也是如此，本书的三位作者 （Alan Page， Ken Johnston和Bj Rollison）都是这方面的牛人，还有跳去Google做测试总监的James Whittaker，还有维护pair-wise网站和PICT工具的Jacek，也是MS的engineer，可见一斑啊。大家只看到他们的产品，而忽 视了他们背后强大的工程团队，那个10K+的developer和10K+的SDET（like tester）。
 
首先来说说关于Test Design的部分吧，关于Chap 4，属于第二部分，"About Testing"。
Alan Page已经升任test director，所以这一章写得比较high level一些，后面两章Bj Rollison关于具体测试方法的部分就比较detail了。

就像写code先要做design一样，做测试也先要design，这一部分做得好不好直接决定了后面工作的效果和效率，因而是很重要的。这一章更像是抛出了很多问题，很多需要在test design的时候考虑的问题。例如，

1. 该什么什么样的测试模式 （test pattern）
做 OO的开发大家都知道Gang of 4写的design pattern，测试也一样有pattern，称为模式吧。这里的模式包含等价类划分，边界值分析等常用的设计方法。做测试设计的时候需要了解业界这样被 证明有效的模式，然后结合自己的项目和产品特性来看哪些是适合的，可以应用的。模式还有一个好处就是便于团队内部的沟通，提到等价类划分大家马上就知道是 怎么回事，大概要怎么做，不用解释半天。

2. 测试时间的估计
对于测试团队，这一直是个问题。项目经理会问team需要多久，manager或者Team lead会问某个team member你测这个模块需要多久。这个问题大概不会有什么标准答案，但是我们可以从一些方面来思考，包括，
历史数据 ： 有没有前面项目的经验可以参考？
复杂度 ：    看看被测的产品或者功能的复杂度如何，这个可以从相关的设计文档来看，也可以和对应的开发人员沟通，听听他们的意见。
业务目标 ：  我们要做的产品时一个prototype（原型）还是一个正式的商业产品，又或者是一个mission critical的产品，比如人命关天的设备。对于这几类不同的产品，测试的要求是不一样的。相信很多公司都有些预研性的项目，这些项目的业务目标是尽快 的做出原型，以便验证这样的产品会不会有市场，有没有可能发展成成熟的产品。通常而言，这样的产品测试的力度要比成熟的产品小很多，有些测试类型甚至都不 用考虑，比如兼容性测试和安全性测试。这个可能也导致在不同部门工作的同事对测试的类型和方式会有不同的理解。
兼容性 ：    如果一个产品需要符合一些标准，或者需要认证，那么这一部分的测试时间也要考虑进去。有些时候，标准要求的测试和我们平常做的功能测试着眼点不同，可能有些场景对于我们来说意义不大，但是标准要求，也得去测。

书上提到上面四点，不过我想，实际中还有很多的因素需要考虑，比如团队的成熟度，还有大家对产品所用的新技术的了解程度和学习时间。其实估计测试时间是一 件很难的事情，因为有一部分是依赖于产品的质量，这里面包含两层意思，一是在测试执行的过程中，如果问题比较多，那么花在提bug，和开发人员确认，以及 fix了之后的verification的时间就会比较多。另一方面，问题很多，regression的时候范围通常要更广，测试也可能会更多。还有一点 是如果有一些blocking的case，对时间还会有影响。关于这样的问题，需要和开发团体密切的配合，及时的沟通和调整，当然在制定测试计划之初就要 留出一些时间来做bug的讨论和验证。

3. 问问题
Alan提到了一个很重要的建议，那就是当测试人员发现对要测的产品或者模块 还不够了解的时候，要多提问题。测试某种程度上是一种评判，除了crash或者弹出异常这种明显的问题，很多时候如果测试人员不了解产品的细节的功能，甚 至是一些内部实现，就很难判断当前的行为是正常的还是有问题。这对高效的测试时很不利的，遇到这种状况就应该停下来，先搞清楚，当然，包括提问题，问对的 问题和问对人也是很重要的。

4. 关于可测性 Testability
这是一个大家都知道但是又常常忽视的问题，因为很多情况下测试设计是在产品设计之后的，那么不管能不能测，都要测了。这里给出了可测性的几种模式，简称SOCK。
S imple：组件和应用越简单越便于测试，复杂了的话可能需要划分。
O bservable：如果能看到一些内部的数据和结构，会利于准确的判断测试的成功和失败。
C ontrol： 如果应用有一些threshold（阈值），如果能设置和改变这些值会使得测试更加容易
K nowledge：如果被测产品有详细的文档，包括spec，design，帮助文档等，将会对判断对错很有帮助。

5. 测试设计文档
关于这一部分不用多说，在设计测试用例之前，一定要有文档化的测试设计，并且邀请相关的team member做review，这已经被证明了是一个good practice。不过exploratory（探索性）测试是不是不需要呢？目前我的了解是不需要，不过也许以后的想法会变。

6. 黑盒、白盒，还是灰盒。
这几个词大家已经很熟悉了，面试实习生的时候问他们关于软件测试的东西， 有很多人都能讲出这些。关于这个问题，不同的组织的做法可能也不太一样，黑盒的测试我想基本都会做，因为产品最后要给用户用，所以把自己当成用户来使用一 下肯定是有必要的。白盒的测试则会有些争议，有些人会认为如果读代码，沿着代码的流程测试可能会禁锢测试人员的思维。后面章节里关于结构性测试的部分Bj 也提到这个问题，他不认为这是个问题。因为黑盒有时候会比较盲目，可能在一个路径上反复的测试，也可能漏掉一些没有UI的路径。灰盒是一种鉴于之间的方 法，至少看起来是这样，我的理解，灰盒大概包括，了解某个功能所用的数据库的schema，还有配置文件的信息，还有它的debug log，这个可以通过设置和监控这些来完成测试。不过这样看起来，灰盒应并不是白盒的折中，因为它还是没有touch到代码的细节。就我目前所在的团队来 看，黑盒和灰盒（如果按我的理解的话）的方法用得比较多，白盒的方法很少，developer做unit test的时候应该用的是白盒的方法。
所以白盒的部分靠dev的unit test就可以cover了吗？也许吧？测试人员需要去读代码，来覆盖所有的测试路径吗？对我而言，这些都是open question。不过看了这本书之后，我倒是想更多的尝试些白盒的方法。

7. Exploratory test
这个topic在业界应该有些年头，不过看起来还是有模糊的部分，以至于James Bach和James Whittaker这两位这方面的牛人也还会在blog里面掐架。关于这一块的讨论也不少，Starwest上面常有关于这个话题的演讲。从这本书看 来，MS内部用这个方法的也不少。对我来说，就是要花些时间去读读这方面的书，试一下这样的方法。

8. pair testing
这个叫法是受到了pair programming的启发（没办法，testing比programming出来要晚，所以很多方面要借助他们的方法）。据本书上讲，他们在MS内部 尝试的结果还不错，而且大部分人是拥护的。我们目前还没有尝试过这样的方法，不知道agile testing里面是不是包含这样的practice，等我看了另一本书再来想想这方面的事情。

好了，第一篇就写到这里。总的来说，我觉得这是一本很好（他告诉你很多经验，然后引发你的思考，你还能从一本书期望什么呢？）的书，做测试的应该去看看，中文版也出来了，好像是MS中国的几个人翻译的，内部的人翻译的应该不会太难，至少术语不会瞎翻。


Ricky
Nov 15， 2009