Test in Production: Bing主页图片与Like

为了与强大的Google竞争，Bing很强调用户体验的差异性（differentiation）。当其他搜索引擎提供与Google相似的主页时，Bing以其高质量的背景图片而特立独行。Google通过变换主页的Logo提供了一种极客的乐趣，Bing则希望其主页图片能够建立与客户的情感联系，让用户有动力每天登录Bing，哪怕只是为了欣赏当天的图片。

在与Facebook合作后，Bing允许用户使用其Facebook帐户登录Bing主页，并Like（赞）当天的图片。当用户Like当天的图片后，她的Facebook好友在Bing主页会发现此信息。利用社交网络，Bing试图建立与用户之间更强烈的情感联系。

在过去的一个多月，我连续收集了Bing主页的Like数据。方法是每天晚上23：00（太平洋标准时间）左右，登录Bing（美国），记录Bing主页图片的Like数。Bing主页可以显示过去8天的图片，我会记录每张图片的Like数。2011年9月6日，Bing对主页进行了改版，不再显示Like的详细数目，而只显示诸如3K、4K、5K等概要数字。考虑到Bing可能修改了Like的统计方法，我停止了数据收集。

我对已收集数据的进行了简单分析，将一些推论记录在本文中。

下图显示了从7月24日到9月6日发布的图片的Like数。Bing允许用户浏览过去8天的图片，这意味着一张图片可以在Bing主页显示8天。图中的Like数是各图片在第7天的数值（下文会解释为什么不选择第8天的数值）。由此图可知：

• 大多数图片的Like数在2000到4000之间。考虑到Bing（美国）的流量，如此少的Like数似乎暗示用户的参与度不高。也许，基于图片的社交网络策略可能不太有效。
• 只有一张图片的Like数超过5000。
• Like数和图片发布的日期没有明显的关联。我原本猜测休息日（周六和周日）的Like数会比较少，工作日的Like数会比较多，但是并没有找到数据支持。

如果将Like数从大到小排列，可以得到下图。

• Like数的分布有一点点像“长尾曲线”，但是第一名（5140个Like）和最后一名（1542个Like）并没有很大的差距（前者是后者的3.3倍）。
• 我原本猜测当许多用户Like一张图片时，她们的朋友会受到激励，从而也Like这张图片，这样的情感网络会使得几张图片的Like数远远高于其他。但是，下图显示这样的情况似乎没有发生过。

Like数最高的图片是谁？下面三张图从上到下是Like数的冠亚季军。

• 第一名（5140个Like）和第三名（4777个Like）都是蓝天碧水。
• 第二名（5K个Like）是9月5日Labor Day（美国的劳动节）的图片。飘扬的星条旗很适合美国人的口味，当然图片的质量确实很好。

下面三张图从上到下是Like数的倒数冠亚季军（Like数分别是1542、1808、1810）。说实话，我无法解释这几张图片为什么没人喜欢。

下图显示了8月2日的图片（Like数排名第三的图片）在8天的显示过程中Like数的变化。

• Like数每天都增长。这似乎暗示有些用户并不每天登录Bing主页（否则她们不会Like第8张图片），但是她们会偶尔登录Bing主页，浏览所有的8章图片，并Like她们的欣赏的图片。
• 从Like数的增长幅度看，第2天的增长最大，此后几天增长缓慢。
• 其他图片的Like数增长也符合此图的趋势。

在收集Like数的过程中，我发现第8天的数据常常包含错误。

• 对于8月20日发布的图片，其Like数在第8天竟然出现了下降。Like数是逐日累加所得，不应该出现下降的情况。
• 对于8月21日发布的图片，其Like数在第8天出现了大幅度增长。增长数（578）是第一天Like数（2269）的25.5%，让人怀疑其有效性。
• 我猜测Bing对于第8天的图片会做一些特殊的处理，而这些操作会导致Like数的错误修改。

以上分析所用的数据和图片可以在这里下载。

我辈再临，究极为何？

C++11这部标准，是在种种期望下进行制作的。

想要将自己真正的情感凝聚在程序上的期望。 
想要将软件开发所特有的，梦想的具现化、表现的多元化、创造的魔术化、以及构建美好事物的本真的乐趣传达给更多程序员的期望。
想要将疲弊丛生的软件业延续到未来的期望。
想要打破蔓延的闭塞感的期望。
想要拥有面对现实世界依然能继续生活下去的坚强的心的期望。

还有现在，想要再次将这些期望实现的期望。

为了这一切，此刻，我们竭尽全力，将C++再度标准化。
我们也在想，为何十多年前的语言在今天再度变更？
我们也觉得，C++已经略显沧桑。
可是，在这十三年间，并没有出现比C++更富创新精神的语言。

在我看来，对于困顿的现代而言，比起谈论技术，展示自己的决心更为重要。
在原本是支撑软件业未来的主力——高校学生——越来越远离开发的此刻，我感觉有必要为他们再创新作。
至少为如今的软件业略尽绵薄心力，我决心再次参与本次标准的制定。

身为制定者，即将构筑焕然一新的现代版C++11。
为此，我离开了熟悉的老巢Bell实验室，进入语言进化委员会，回归本原重新开始。
为了不被过去束缚，也不甘溺于现状，以不断进步的未来为目标。
幸运的是，原先的班底与新加入的强援正在不断集结。
超越C++98的目标似乎也变得越来越触手可及。

C++是个进化的故事。
主角遭遇了无数次误解、攻讦，依然全力向上。
是即使进步微不足道，仍然不断向前的，渴望的故事。
是忍受着不被理解的孤独，与伙伴携手，即使心存恐惧，也想一起奋斗下去的，觉悟的故事。
这样的故事所演化出的四种范型，希望会让程序员感到幸福。

最后，我们的工作也包含服务和教育的领域。
当然要让从未接触过软件开发的人也能轻松体验，通过C++浓缩程序的精华，重构新的世界观，
希望作出让所有的人都能乐在其中的新语言。

2011年初秋，敬请期待。

原作/总监督 Bjarne Stroustrup

借庵野秀明之笔，向ISO-WG21标准化委员会致敬！
此文写于2009年，于C++11国际标准通过之际重新发布。

 

探索式测试：肥皂剧测试（Soap Opera Testing)

肥皂剧测试（Soap Opera Testing）是Hans Buwalda（CTO, LogiGear Corporation）提出的系统级功能测试方法。其特征和方法对于基于情景（Scenario）的探索式测试很有启发性，是探索式测试者值得研究的工具。本文将简介肥皂剧测试的基本方法和特征，详细论述请参考Hans的原文。

测试用例

一个肥皂剧测试的测试用例是一个场景（Scenario），类似于一个小故事或肥皂剧中的一段情节。Hans的文章收录了 Brian Marick（测试专家、敏捷宣言的缔造者之一）编写的一个测试用例，十分有趣。

用例名：租用与事故

客户Marick为了三天的旅途租了一辆汽车。在租用期间，他又延长了一周（以便获得足够的租用积分来得到Preferred等级）。几天后，他打电话报告车丢了，并要求换车。他强调在更换车辆时，他理应享受Preferred等级，即便在租赁期开始时他并不位于该等级。他得到了另一辆车。两天之后，他打电话报告那辆“被偷”的车被找到了。事实证明，实情是他忘记了停车地点。他希望归还其中的一辆车，并结束相关的租赁业务。糟糕的是：发现旧车时，他的新车撞上了旧车。现在，它们都损坏了。

该情节将测试以下内容

• （在租赁期）升级到Preferred等级
• 延长租赁
• 被盗申报
• 车辆更换
• 取消车辆更换
• 取消被盗申报
• 归还受损车辆

这是一个典型的系统级的场景测试用例，用一个较长的流程覆盖了系统的多个功能。通常，测试者会遵循如下步骤来构造肥皂剧测试用例：

1. 分析系统，确定系统的功能点，并拟定测试目标。
2. 设计一条或多条肥皂剧测试用例，以满足测试目标。
3. 如果发现新的测试目标，延展已有的测试用例或增加新测试用例，以确保测试覆盖。

Hans建议测试者分享、阅读、讨论彼此的测试用例，以获得灵感，并完善故事。他认为，拥有独立的测试设计与评审阶段，是肥皂剧测试的一个优点。

四大特征

Hans用 一句话归纳了肥皂剧测试的特征：

Try  to  write  scenarios  that are (1) based on real life, (2) exaggerated, and (3) condensed into a limited number of events.

其要点与电视中的肥皂剧如出一辙：源于真实生活、浓缩、夸张，（同时要充满乐趣）。

1. 源于真实生活（based on real life）

软件要能帮助客户解决实际问题，特别是复杂的现实世界中的困难问题。《项目百态》指出：“很多项目没有真正成功，只因为缺少一个人专门负责确保最终的业务流程——从用户的角度看来——尽量顺利地开展。”肥皂剧测试通过聚焦用户的使用场景来伸张用户权益。那些看似极端、却可能真实发生的故事，往往能揭示系统的深层次错误。此外，通过编写肥皂剧测试用例，测试者可以更好地学习并理解被测试系统。当他把测试用例分享给项目涉众（特别是领域专家和开发者）时，整个项目团队都会受益。

２. 夸张（exaggerated）

肥皂剧测试用戏剧性的问题拷问软件，看它如何应对。这与James Whittaker在《探索式软件测试》中提出的“学究测试法”（Intellectual Tour）和“傲慢的美国佬测试法”（Arrogant American Tour）有些相似。测试可以像刻板的老学究，向软件提出难以回答的问题。测试也可以是骄傲的美国佬，总是发出可笑的问题，惹是生非，自以为是（好似测试用例中的Marick)。夸张的情节让肥皂剧好看，夸张的测试用例帮助软件应对现实难题。

3. 浓缩（condensed）

肥皂剧测试同时展开多个复杂的情况，看软件如何处理。软件也许可以分别处理每一项业务，但是当多个业务同时提交且相互牵扯时，软件的设计缺陷可能让用户一筹莫展。肥皂剧往往展开多个支线情节，相互交织，彼此推动，测试情景也可以如此。此外，浓缩的情节可以在较短的时间内测试多个功能，提高了测试效率。

4. 乐趣（fun）

乐趣是高效软件测试的核心因素之一。软件测试是高水平的智力活动，需要测试者全神贯注，以思考力决定成败。枯燥的测试过程会压抑测试者的创造性，使他们的精力被快速耗尽，注意力渐渐被网页和邮件所吸引。而有趣的测试过程会激发测试者的创造力，使他们始终热情高涨、思维活跃。因此，Hans强调编写测试用例一定要充满乐趣（it must be
great  fun  to  write  them）。此外，好的测试情节不但容易理解，而且能够激发审阅者、测试者的灵感，让他们发展出更好的支线和细节。

肥皂剧测试与探索式测试

探索式测试强调测试将测试设计与测试执行作为相互支持的活动并行地执行（详见Cem Kaner的定义），但是并不排斥单独的测试设计阶段。Cem Kaner说，测试有两个极端：完全的即兴测试（毫无计划）和绝对的计划测试（编写细致入微的测试计划，且严格遵循），大多数测试者都位于两极之间，有些人更靠近即兴的一端，有些人更靠近计划的一端。注重实效的测试者会根据当前项目的特征，动态地调整自己的位置。

在《探索式软件测试》的第5章，James Whittaker详细讨论了如何结合场景测试与探索式测试。他说：“场景是探索式测试的一个绝佳起点，探索可以给场景加入宝贵的变化。明智的测试人员会把这两种方法结合起来，以更好地覆盖应用程序”。肥皂剧测试用例就像是地图，给出了测试流程和一般性指导。在测试过程中，探索式测试者可以去游历更多的情节、发展更多的支线、探究更多的细节。正如James所说：“地图不是为了找到最短的路径，而是帮我们找到更多的路径”。

剧本固然要紧，但是导演和演员的现场互动和即兴发挥可能更加重要（喜欢王家卫或杜琪峰电影的人对此会有更多认同）。测试用例就是剧本，它展示了舞台；集编剧、导演、演员于一身的测试者应该发挥创造力，去演绎精彩的测试。

 

Test@Office: 每周测试会议

Office PARC负责Word和相关产品的开发。PARC测试团队大约有40~50人，有5个测试领导（Test Lead）和1个测试经理（Test Manager）。测试经理汇报给负责Word和OneNote的副总裁（Vice President），副总裁汇报给向微软商业部门（Microsoft Business Division）的总裁（President）Kurt DelBene，而Kurt汇报给首席执行官Steve Ballmer。

这是一个相对扁平的组织结构。Kurt 领导的团队非常庞大，他们的产品包括Microsoft Office（Word, Excel, PowerPoint, OneNote, Outlook, Access, Publisher, Project, InfoPath, Visio等)，Mac Office, Office Web App，SharePoint, Exchange, Lync (服务器和客户端），Office 365等。测试经理只越过一级就可以向总裁Kurt汇报，这有利于传达研发团队的意见。

测试经理的名叫Mike，是一位非常资深的管理者（其职位是Partner Test Manager）。他亲自主持每周测试会议（Weekly Test Meeting），向PARC测试团队沟通当前进度和本周重点。

周会是一项被广泛采纳的开发实践。Office PARC的测试周会有什么特点呢？以下是我连续两周观察到的内容。

第一周

会场

在周一10点，Office PARC的测试员工进入会场。在我看来，以下几点值得记录。

1. 会场的桌子被摆成U型。某个员工发言时，其他人都可以看到他的表情。
2. 测试经理Mike站在会场中间主持讨论。如果有讨论，他可以随时走到发言者身旁，近距离地交流。
3. 投影仪投射出PowerPoint文档，其内容是本次会议的议题。会后，该文档被保存在内部站点上。
4. 只有少数员工携带笔记本电脑参加会议。在中国微软，几乎所有人都携带笔记本电脑参加会议。
5. 大多数员工携带纸质笔记本参加会议，但是频繁记录者不多。

上周趣事

会议的第一项议题是上周趣事。Mike问：关于上周，大家有什么好玩的事情可以分享？于是，一些员工分享了他们在工作内外的遭遇，并引发阵阵笑声。以我观察，发言者以性格外向或资历较老的员工居多。像我这样初来咋到、性格内向的员工发言的可能性较低。但是，“无关的趣事”使得会场气氛变得轻松，让我觉得这不是一个压抑的“工作会议”。

杂项

会议的第二项议题是Misc（杂项）。议题大多是团队内务，包括欢迎新员工、年中职业讨论（Middle Year Career Discussion）、微软年度反馈（Microsoft Poll）等。

例行议题

在轻松的内容之后，是一系列固定的议题，包括：项目进度、测试自动化情况、Bug情况、本周重点任务等。在我看来，以下几点值得参考。

1. 每一个议题都有固定的负责人（Driver）。他（她）可能是测试领导，也可能是资深员工。他驱动PARC测试团队的一项具体工作，如测试自动化、Service Pack测试、Bug修复等。这使得PARC的测试实践拥有统一的风格，且促进了测试人员之间的交流。
2. 负责人往往会用带标记的表格或各种图形，来传达当前情况。明幻灯片综合了多个负责人提供的数据。
3. 对于里程碑的开发进度，其度量单位是已经完成的功能（Feature）数，而不是已经使用的开发时间。
4. 对于测试进展，其度量指标包括测试工程师的Bug数量和自动化测试通过率。
5. 依据Office的开发计划和当前进展，负责人给出本周的工作内容和重点。在会后，他们还会发送邮件，给出更详细的说明和指导。

插曲

除了例行议题，本周的会议还有两个“插曲”。

第一个插曲是演示一项刚刚开发完毕的新功能。两位测试工程师一边演示，一边回答观众的提问。当时，我的第一反应是，这与Scrum的“Sprint演示”异曲同工。Scrum以2~4周的Sprint为开发单位。每个Sprint结束后，开发团队都要向利益相关人（stakeholder）演示Sprint的成果。这有助于开发团队专注于用户价值、获得可度量的进展、增强团队信心、获得必要反馈。

Office采用的是螺旋开发模型，产品开发由几个里程碑（Milestone）组成。在每个里程碑，程序经理、开发工程师和测试工程师会组成功能小组（Feature Crew），完整的实现并测试一批端到端（end-to-end）的功能。每周例会提供了一个产品演示的固定舞台，使得功能小组能够尽快展示他们的成果，从而获得与Sprint演示相似的收益。

第二个插曲是介绍本周的一个测试活动：Test Focus Day，活动内容是用半天时间，让测试工程师一起测试Word Web App。活动组织者是Word Web App的测试工程师，她介绍了活动规则：测试工程师被分成若干个团队，每个团队各自编辑一份文档。在此过程中，工程师要尽力寻找bug，并使得整份文档美观、有趣。测试结束后，Mike作为评审，会选出最佳文档和最佳Bug。

介绍完规则，Mike接过话题。他首先感谢了组织者的工作，然后动员大家发动奇思妙想去编辑美妙的文档。他说了一句令我印象深刻的话：

We always find beautiful bugs in writing beautiful documents of the real world.

第二周

在第二周，PARC测试团队照例举行周会。会议内容是上周趣事、杂项和例行议题。除了上文所提到的内容，还有两点值得记录。

Dogfood

Mike指着投射出的PowerPoint文档说：“这是我用Dogfood Build制作的PowerPoint文档。在过去一周，我一直使用Dogfood Build。让我感到高兴的是，PowerPoint崩溃过1次，Outlook崩溃过2次，Word没有崩溃！”

Dogfood来自于俗语“吃自己的狗食”（Eating your own dogfood），意思是开发团队使用自己正在开发的产品。这是一项有许多收益的活动。

1. 开发者作为用户获得对产品的第一手反馈。这加速了产品的持续改进。
2. Dogfood要求正在开发的产品有较好的质量，不会妨碍日常的使用。这自然要求开发团队能够持续提供质量稳定的构建（Build）。Office vNext尚在开发的早期，就可以应用在日常工作中。这说明Office在每日构建和持续集成上的投入，收到了好的效果。
3. Dogfood有助于推进一些功能的完善。例如Dogfood PowerPoint崩溃，Mike不会绝望。因为Office的自动恢复（AutoRecovery）可以挽回大部分修改。不把自动恢复做好，员工很难正真使用Dogfood Build。
4. 在Dogfood过程中，不同职位、不同背景、不同习惯的员工会用不同的方式使用系统。在一个大的团队内实施Dogfood，很可能覆盖独立测试工程师不能覆盖的场景。

Mike的举动鼓励了我：连测试经理都安装并使用Dogfood Office，我也要加入这项活动！于是，我也在自己的机器上安装了Dogfood build，并每天用它处理邮件和编写文档。从这件事上，我体会到：有效的管理，有时不需要指令或劝说。作为领导，Mike的榜样作用不可低估。

最佳文档和最佳Bug

在“杂项”议题中，Mike拿出2页A4纸，上面写满了他的笔记（系手写，非打印）。他利用周末的时间，仔细阅读了Test Focus Day所产生的所有文档，并记录了每一篇文档的特色。基于笔记，他逐一点评了每篇文档，感谢撰写该文档的团队，并提点出他所喜欢的Bug。

在点评我所在团队的文档时，Mike特别摘录出一句他觉得很搞怪的话。其实，这句话是我写的，是我在文档中放的一个玩笑。这件小事说明Mike仔细地阅读了文档中的每一句话，并做足了功课。

我认为，所谓“正真”的领导重视，就是领导亲自做他声称重要的事情。Mike的言行表明，他非常重视团队协作、Test Focus Day和有价值的Bug。他在最后公布了最佳Bug的获得者和获奖理由，大家将掌声送给获奖的同事。

小结

1. 周会有助于提供稳定的开发节奏。Kent Beck在《极限编程解析（第二版）》中提出了多项实践。在这些实践中，他建议从“周计划”开始敏捷之旅。PARC测试团队的周会沟通了当前情况，并制定了本周计划。
2. 有效的周会需要仔细的准备。PARC测试周会汇聚了多个信息源的数据，绘制了图表，并以此形成行动计划。
3. 好的会议要有好的主持人。Mike的丰富经验和个人魅力提升了会议的效果。

Test@Office: 写在前边的话

在2011年2月，我加入Office Word团队，测试Office vNext（下一个版本的Microsoft Office）。为了记录和分享我的所见所感，我将在博客中开始一个新的系列：How We Test Software at Office PARC（缩写为：Test@Office）。

在开始正文之前，我有几点需要说明。

1. 我只是Office测试团队的新人。虽然我尽力避免疏漏和偏见，我难以保证博文不包含错误。希望读者不吝批评指正。
2. 我的博文只代表我的观点，不代表我所在团队、部门和公司的观点。
3. 我要遵循保密协议。我不会描述Office vNext的细节，不会讨论机密信息，也不回答相关问题。
4. 软件开发没有秘技。也许读者会发现，我所描述的技术和实践都是广为所知的“常见方法”。Office PARC只是将传统方法稍作改变、组合使用罢了。
5. 软件开发没有最佳实践（Best Practice）。语境驱动测试（context driven testing）认为：“在语境中存在好的实践，但不存在最佳实践”。Office PARC的方法具有参考价值，但是它们不适用于所有情况。
6. 我的文章很可能没能描述最重要的东西。语境驱动测试认为：“实践的价值取决于语境。在一起工作的人是项目语境中最重要的部分”。用文字描述技术和流程相对容易，描述情感、交流、气氛则困难得多。

如果您有批评、建议、疑问，请让我知晓。谢谢。

测试杂感：Windows8也许需要Account Hub

随着云计算和社交网络的快速发展，Windows用户将在多个软件中管理她的网络帐户。不幸的是，虽然这些软件都由微软开发，但是它们彼此孤立，无法提供流畅的用户体验。

Microsoft Office

• Outlook可以管理Live Hotmail邮箱，它要求用户提供Live ID。
• Word、Excel、PowerPoint、OneNote可以将文档存放在SkyDrive上，它们要求用户提供Live ID。不幸的是，虽然Outlook已经掌握此Live ID，Word等还是要求用户再次输入。
• Outlook Social Connector让Outlook显示发信人和收信人的社交网络更新，它目前支持Live Messenger、Facebook、LinkedIn等。对于Live Messenger连接，即便用户已经用Outlook管理Live Hotmail邮箱，它还是会要求用户输入Live ID。

Windows Live Essential

• Live Messenger、Live Mesh、Live Movie Maker、Live Photo Gallery可以分享彼此的Live ID。用户在某软件登录一次，其他软件就将此Live ID设为默认帐户。
• Live Mail需要用户再次输入Live ID。
• Live Writer需要用户输入WordPress或其他博客网站的帐户。
• Live Messenger与网络服务Live Services配合，可以将用户在社交网络（如Facebook、LinkedIn、WordPress、新浪微博等）的更新显示在Live Messenger和Live主页上。这自然要求用户输入Facebook、LinkedIn、WordPress的帐户。以我的使用体验，Live Movie Maker和Live Photo Gallery可以获得Facebook帐户，但是Live Writer对WordPress帐户一无所知。

Windows Phone 7

• 初始化WP7时，用户需要提供一个Live ID。
• Zune是连接Windows和WP7的桥梁。用户如果想利用Zune更新WP7，他需要再次提供Live ID。
• Windows Phone上的People Hub可以连接Windows Live Services，从而显示用户在社交网络（Facebook等）的更新。但是，当用户安装了Facebook官方App，他需要为App再次输入Facebook帐户。

在不同的软件中输入相同的帐户，既不方便也不安全。微软也许应该考虑在Windows 8上加入Account Hub，让用户统一管理各种帐户。在用户授权下，不同的软件通过Account Hub提供的编程接口获得帐户信息，从而提供流畅的用户体验。

在这方面，微软已经有所行动。

• Windows Live Services用Live ID连接了Facebook、LinkedIn、WordPress、新浪微博等帐户。使得用户在Facebook上的更新可以显示在Live Messenger和Live主页上；反之，用户在Live相册上的更新也可以显示在Facebook上。Windows Live Services可以看作是Account Hub在云上的雏形。目前，它的问题是其他软件无法从中获得这些互相连接的帐户。
• Windows Phone 7在初始化时，要求用户提供Live ID。之后，无需用户干预，它的People Hub就可以显示用户的Live联系人和社交网络更新；Email就可以管理用户的Live Hotmail；Mobile Office就可以访问用户在SkyDrive上的文档；Pictures就可以显示用户在Live相册的图片，并将拍摄的照片上传到Live相册。在多个应用之间切换时，用户始终可以访问相应的Live服务，用户体验很流畅。

这样，在Windows 8中提供Account Hub也是顺理成章的事。

• Account Hub是Windows Live Services的客户端，它们彼此同步所拥有的帐户信息。
• Account Hub管理了用户的多个网络帐户：Live、Facebook。LinkedIn、WordPress、Flickr、新浪微博等。
• Account Hub提供编程接口，供应用软件查询用户帐户。
• 当应用软件尝试访问Account Hub时，Windows以显著地方式（可以参考User Account Control的视觉模型）询问用户是否信任该软件。如果信任，用户可以将他指定的帐户共享给该软件。
• Account Hub可以要求用户提供一个Live ID作为默认帐户。之后，微软的应用软件，如Office、Live Essential、Zune、文件管理器，皆以此帐户为默认帐户。未来，“另存到SkyDrive”也许是所有Windows应用的功能之一。
• Account Hub不但可以连接帐户，还可以让应用软件分享帐户的资源。如Outlook可以访问Live Hotmail的通讯簿，Live Mail可以访问Outlook的通讯簿。当然，这必须得到用户的授权。
• Windows Live Service提供Web API，在用户授权的情况下，将帐户信息提供给其他Web程序。

各种消息都在暗示Windows8将拥抱“云计算”，模糊本地应用和网络服务的界限。而Account Hub将减少用户的重复工作，提供更平滑的用户体验。

多余的话：此篇博客看似与测试无关，却是我在测试工作中萌发的想法。于是归入“测试杂感”系列。

探索式测试：测试自动化实例分析

Harry Robinson是微软公司的首席测试工程师（Principle Software Development Engineer in Test），工作于必应（Bing）团队。他在国际会议CAST 2010和PNSQC 2010做了两次关于测试自动化的主题报告，都很有启发性。本文从中摘录了若干测试自动化实例。希望通过对它们的分析，能够获得一些可借鉴的经验。

为避免误会，在此重申：本文的素材来自Harry Robinson的主题报告，其内容皆来自他在必应的测试工作。我所做的工作是翻译和评论，并为此过程中的所有错误负责。

案例1：盖特伍德奶奶（Grandma Gatewood）

下面这张截图来自于Harry的一张幻灯片，右侧的老者就是著名的盖特伍德奶奶（Grandma Gatewood）。她曾经在67、72、75岁时，三次独自徒步走完阿帕拉契小径（Appalachian Trail）。阿帕拉契小径是美国著名的野外徒步路线，穿越14个州，全长3200公里。盖特伍德是首位独自徒步走完阿帕拉契小径的女性，耗时仅三个月。

盖特伍德是“超轻徒步先驱 ”（ultra-light hiking pioneer）。维基百科有如下描述：

1955年，67岁的盖特伍德徒步前往阿帕拉契小径，她穿着Keds运动鞋，她把一块军用毛毯、一件雨衣、一块塑料浴帘装在自家缝制的背包里，然后单肩背包徒步，由此她成了超轻背包的先驱。

1970年，时年83岁，她在弗吉尼亚州奥克顿访问阿帕拉契旅行用品商店时，有人询问她对于当时轻量背包装备的看法，她建议：“制作一个雨衣，一个单肩背包，再买双结实的Keds网球鞋。在当地杂货店买好维也纳香肠……其他吃的你可以在路边找到……”

现在，你也许感到疑惑：盖特伍德与测试自动化到底有什么关系？那么，请考虑下面这个问题

如果盖特伍德选择图片左侧男子所用的背包，她能够在67岁之后徒步走遍美国大陆地区所有的州吗？

答案显然是不能。如果选择图片左侧的双肩包，盖特伍德恐怕坚持不了一个星期就要倒下。这是一件显而易见的事情：你所选择的工具不应成为你的负担。然而，我见过一些测试团队，他们使用重量级的流程、框架、基础设施，被自己的选择所拖累，虽然天天抱怨，却不思变更。

盖特伍德的单肩包提示我们自问：

1. 测试自动化的投入产出比如何？是那些投入最多的测试在创造最多的价值吗？
2. 我们遵循了“要事第一”（First Thing First）的原则吗？我们的主要精力是投入在最有价值的事情上吗？
3. 现有的流程、框架、基础设施中，有哪些部分不是必须的？能用更轻量的方法替代吗？

程序员有时在潜意识中认为自己是无所不能的超人，但是我们真的强过盖特伍德吗？她经历过两次世界大战，见证过改变世界的经济危机，养育过11个子女（这是多么强大的管理经验），在67岁时开始新的冒险，获得成功后又迈向新的目标。不要以为超轻背包是一个虚弱老妪的无奈选择，它是一个睿智老者多年人生体验的沉淀。她知道什么是必须的（雨衣、背包、Keds网球鞋、维也纳香肠），什么可以稍后处理、随机应变（“其他吃的你可以在路边找到”）。她知道用超轻背包，她可以走得更远，远得令所有人敬佩。

如果看完本文，你只能记得一点，请不要忘记盖特伍德奶奶的单肩包。

案例2：测试自动建议（AutoSuggest）

对于搜索用户，自动建议（AutoSuggest）是一项贴心的设计。但是对于测试工程师，这不是一项容易测试的功能。

1. 手工探索式测试无法保证测试抽样可以覆盖用户输入。与必应搜索庞大的用户输入相比，手工测试的覆盖率接近于零。传统的等价类划分等测试抽样方法，对于如此海量的、无规则的输入，也无可奈何。
2. 传统的自动化测试遇到的困难是无法构建测试Oracle。自动建议的核心实现是基于海量数据的人工智能算法。算法的输出受到多个因素的影响，如当前用户的查询、近期的相似查询、自动拼写更正、关键词过滤（如去除色情内容）等。对于特定的输入，很难构造自动建议的“预期结果”。

面对困难，Harry的测试思路是构造启发式测试Oracle（Heuristic Test Oracles）。所谓启发式Oracle，就是使用规则对测试结果进行一致性检查。开始时，Harry的规则非常简单：

自动建议的结果应该以输入字符串为作为缀。

Autosuggestions should have the input string as their prefix.

Harry编写了一个简单的测试程序。它从必应的服务端日志中获得真实用户的查询，调用自动建议的Web Service API，以获得这些查询的自动建议结果，最后利用上述规则对结果进行检查。

很快，测试程序发现了不满足规则的案例。当输入是“nestb”，自动建议返回“bestbuy.com”（百思买，财富500强消费电子零售商）。这是自动建议的拼写更正（Spelling Correction）功能，它将用户的“疑似错误输入”，纠正为一个最可能的结果。该行为是可接受的。于是，Harry将规则修正为：

自动建议的结果应该以输入字符串的合理近似作为前缀。

Autosuggestions should have a reasonable approximation of the input string as their prefix.

虽然不知道Harry的具体做法，我能想到若干“合理近似”的判定方法。

1. 将单词看作向量，计算向量之间的距离。距离小于指定阈值的单词对，可以认为相互“近似”。
2. 查询Office Word的拼写更正字典，获得指定单词的所有拼写更正建议。这些建议可以视为单词的“合理近似”。
3. 调用必应的搜索API，获得搜索结果。搜索结果中的高亮关键词可以视作查询的“合理近似”。

Harry利用修正后的规则又发现了一些违规的案例。如输入“dond”，自动建议返回“nbc.com”。也许这符合某些文化上的约定，但值得进一步调查。再例如，输入“federal trust bank”，自动建议返回“floridalottery.com”。这个建议应该是错误的，需要开发者去调查哪里出了问题。在这个过程中，启发式Oracle更像一个过滤器，它处理海量的数据，过滤出需要测试者人工审查的潜在错误案例。

通过持续运行测试程序，Harry获得了以下成果。

1. 测试运行了7天，覆盖了2200万个用户查询。
2. 发现了1万个有问题的建议结果。
3. 在建议词条数据库中，发现了1.9万个从未被返回的建议词条。它们应该被剔除。

当然，真实的测试过程比上述描述要复杂一些。但是，它们都拥有相同的核心：从简单的测试Oracle开始，利用测试反馈持续完善Oracle。Harry将这种迭代式的测试开发过程称作涌现式测试（Emergent Testing）。

案例3：测试行车路线（Driving Direction）

在线地图可以给出从地点A到地点B的行车路线（Driving Direction）。那么如何测试该功能呢？

Harry的测试输入集合是全美所有邮政编码（Zip Code）的两两组合。这是一个非常庞大的集合，它提供了令人放心的测试覆盖率。

Harry的测试策略仍旧是构建启发式测试Oracle。开始时，他的规则集合包含这么一条规则：

行车路线的长度与A到B的直线距离没有数量级的差距。

这里需要对在线地图的实现稍作说明。在线地图的实现可以大致分为两层：绘制地图的Web UI和提供地图数据的Web Service API。API能够返回指定邮政编码的经纬度坐标。因此，利用其返回值，就可以算出两点间的直线距离。对于行车路线，API返回的是一系列点的坐标值，Web UI将行车路线路线绘制为贯穿这些点的曲线。计算临近两点间的距离，将结果累加，就可以得到行车路线的长度。因此，上述规则的实现并不复杂。

然而，在实际测试过程中，这条规则却产生了许多“误报”。下图就是一个例子。

于是Harry替换了检查规则。新加入的规则是：

从A到B的行车路线的长度与B到A的行车路线的长度没有明显差别。

这条规则没有产生太多的误报，而且发现了一些有趣的错误。下图就是一个例子。

对案例2与案例3的再分析

在案例2和案例3中，被测试对象有如下特点：

1. 难以构造能够给出标准结果的测试Oracle。自动建议的计算是基于海量数据的模式匹配，行车路线的搜索是典型的人工智能算法。在技术上，很难准确预测它们的输出。从业务的角度，这两个问题在现实世界也不存在“标准答案”。
2. 在这两个应用中，Web UI从Web Service API中获得数据。这意味着，测试程序可以忽略UI，直接调用Web Service API，以测试核心逻辑。良好的设计分层提供了可测试性，而可测试性简化了测试程序的构造。
3. 测试输入使用真实数据，且相对容易构造。自动建议的测试输入来自必应的服务端日志，测试程序只需要遍历文本日志就可以构造测试输入。行车路线的测试输入是全美邮政编码的两两组合，测试程序只需要读取一个记录全美邮政编码的文本文件，就可以组合出所有的测试输入。
4. 单个测试执行速度快，这有助于测试程序在较短的时间内完成大量的检查。自动建议的Web Service API的响应时间应该在毫秒级，行车路线的API可以慢一些，但也必须在1~2秒内返回结果。于是，Harry的程序能够检查2200万个输入，能够使用“全组合”策略提供充分的测试信心。

在案例2和案例3中，测试策略有如下特点：

1. 充分利用计算机的运算能力，将（与人力成本相比非常廉价）机器资源使用到极致。
2. 用简单的启发式规则构造测试Oracle。利用海量数据和启发式Oracle做数据驱动测试。
3. 迭代地构造Oracle。从简单的规则开始，利用测试结果逐步增强、修改、完善Oracle。
4. Oracle的输出不是二值的通过或失败。它更像过滤器，其输出是需要进一步人工调查的案例。
5. 与一些测试方法追求精简的测试用例集不同，测试程序运行尽可能多的测试用例。一方面，自动建议和行车路线的缺陷很难预测，需要大量的测试；另一方面，既然单个测试执行速度很快，为什么不多测试一些真实数据呢？
6. 充分利用测试工程师的智力。当计算机完成了枯燥的计算，测试工程师可以专注于改进Oracle和调查问题案例，而这些任务是计算机所不能完成的。
7. 性价比高。在微软总部雷蒙德，一个测试工程师的年薪大约是8万美元。花1万美元，就可以为他配备10台强劲的计算机，而这些计算机至少可以使用3年。因此，合理的测试策略应该是让机器全负荷运转，让人专注于富有智力挑战的任务。

Harry的幻灯片与视频

以下是本文所引用的幻灯片和相关连接：

1. Harry Robinson的主页：www.harryrobinson.net。
2. 案例1和案例2的来源：Harry在PNSQC 2010的主题演讲“using simple automation to test complex software”的视频和幻灯片。内容非常有启发性，强烈推荐。
3. 案例3的来源：Harry在CAST 2010的报告“Exploratory Test Automation”的幻灯片。

 

探索式测试：测试自动化

我发现，许多测试人员和测试经理将测试自动化等同于测试用例自动化执行。在他们的词汇中，“自动化”是“测试自动化”的缩写，而“测试自动化”就是自动地运行被测试对象、检查测试结果并生成测试报告。

如果仅仅运行计算机可执行的测试用例就可以保证软件质量，那么测试人员的生活将轻松许多。但是，在绝大多数项目中，测试者都必须完成一系列任务来提供优质的测试服务。

以上幻灯片来自Doug Hoffman和Cem Kaner的报告“Exploratory Test Automation”。他们列举了典型的测试任务，并强调这只是测试人员日常工作的一部分。

• 分析产品和它的风险
• 开发测试策略
• 设计测试用例
• 执行测试用例（测试用例的首次运行通常是手动执行）
• 评估测试结果（包括错误分析和调试）
• 管理测试环境
• 测试结果管理与追踪
• 回归测试

测试用例自动执行对回归测试很有帮助，但是对其他活动支持有限。为了更好地测试，测试者需要放宽测试自动化的视野，在测试全程合理地利用计算机的强大能力。

如果自动化能促成测试使命的完成，就利用自动化。评估利用自动化是否成功的标准，是看它多大程度上帮助测试人员完成自己的使命。（摘自《软件测试经验与教训》第5章“测试自动化”）

在探索式测试中，探索式测试自动化（exploratory test automation）是帮助测试人员完成探索式测试使命的开发与测试活动。Doug和Cem认为：

探索式测试自动化是计算机辅助测试，它支持学习被测试软件质量的新信息。

Exploratory test automation is computer-assisted testing that supports learning of new information about the quality of the software under test.

分析他们的描述，可知探索式测试自动化的要点。

1. 探索式测试自动化强调计算机辅助（computer-assisted），而不是自动化测试（automated testing）。它的目标是人尽其才（自由发挥测试者的智能），物尽其用（充分利用计算机的性能）。
2. 探索式测试自动化的一个重要目标是学习。我在“探索式测试：探索是为了学习”中提到，软件测试是一个持续学习并实践的过程，而探索式测试支持更有效的学习和实践。测试自动化也应该坚持这一方向。
3. 学习的目的是获得新知。测试专家Rex Black 在《Pragmatic Software Testing》提到了一条测试设计原则，很有启发性：“你应该设计测试用例以便你能从每个测试用例中学习到一些你还不知道的东西。当你从测试中学到了什么时，你应该感到高兴”。

下图是一个探索式测试自动化的实例。它是我开发的测试工具，以图形化的方式来展示指定时间段中所有任务（Job）的耗时：横轴是时间轴，每一个矩形对应一个任务，矩形越宽说明任务耗时越长，相同颜色的矩形对应同一种任务。

通过该工具，我可以立即理解被测试系统在产品环境或测试环境的工作负载。在特定时间窗口中，执行了哪些任务，哪些任务耗时最长，哪些任务数目最多，哪类任务在并发执行，哪类任务在串行执行，哪些时段系统繁忙，哪些时段系统空闲——这些信息界皆一目了然。虽然该工具不执行任何测试，但是它可以帮助我分析被测试系统，发掘可能的性能风险，为测试策略选择提供信息。

著名的Web调试工具Fiddler也体现了探索式测试自动化的思想。其作者Eric Lawrence在IEBlog上描述了它的诞生：

在我加入Internet Explorer团队之前，我工作于Microsoft Office Online网站。当处理大规模流量时，我们面临一些性能挑战，它们迫使我深入挖掘HTTP性能的深入细节。我的努力最终产生两个成果：Microsoft Fiddler和网络性能优化的最佳实践的文档。

Before I joined the Internet Explorer team, I worked on the Microsoft Office Online website. Handling massive amounts of traffic, we faced some performance challenges that forced me to dig into the guts of HTTP performance. The output of that effort was twofold: Microsoft Fiddler, and documentation of some best practices for web performance optimization.

可见Fiddler的原始需求是性能测试的结果分析和问题调试。为了更好地理解系统（包括服务器、客户端、网络、HTTP协议），更快速地定位问题，Eric用Fiddler捕获网络通讯的细节，并以友好的方式显示。当工具完成了枯燥、琐碎、繁杂、海量的任务，开发者能够利用他们的头脑去解决来自现实世界的难题。

在结束本文之前，我想再回顾一下我的观点。

1. 情景（context）是非常重要的。要依据当前情景，选择合适的测试任务。要根据测试任务，思考合适的测试自动化方法。
2. 测试自动化不但包括自动执行测试用例，还包括计算机辅助的测试分析、手工测试、错误调试等活动。
3. 学习是软件测试的核心活动之一。测试自动化应该更好地支持测试学习。

探索式测试：探索是为了学习

对于测试人员，软件测试是一个持续学习并实践的过程。他需要学习的内容可能包括：

• 行业知识：为什么需要这个软件？软件如何帮助使用它的人和团体去获得行业优势？
• 用户角色：目标用户是谁？他们有什么特点，有什么期望？软件如何帮助他们去获得个人成就？
• 软件产品：产品是一种解决方案。它解决了行业和用户所面临的问题吗？
• 计算平台：只有深刻理解软件所依赖的计算平台（如操作系统、中间件、网络协议等），才能更好地测试。
• 开发技能：理解项目所使用的具体技术，知晓典型的技术缺陷，具备测试开发能力。
• 测试方法：针对当前项目，选择合适的测试方法，并能够熟练地应用。
• 程序缺陷：研究当前（和相关）项目的缺陷，提炼错误模式（Pattern），制定缓解或预防方案。
• 开发团队：语境（context）决定策略和实践。在一起工作的人，是所有项目语境中最重要的组成部分。

测试者不需要在项目之初就掌握所有知识，他可以通过每天的工作去逐步理解用户、项目、技术和团队。更重要的是，他要在每天的工作中实践所学内容：规划测试方案，创建并执行测试用例，分析测试结果，编写测试报告。实践就是练习，是“学”的自然延伸。知行合一才构成“学习”的完整内核。

如果学习非常重要，那么如何才能高效地学习呢？敏捷大师Andy Hunt在《Pragmatic Thinking and Learning》中指出“一种高效的学习环境应该允许你安全地做三件事情：探索、创造和应用”。

探索就是在陌生的环境中玩（play）。你需要自由地探索才能学习。我们不仅仅接受信息，而是亲自探索和构建思维模型。

玩引入了一种新奇的感觉，也就是乐趣。用一种好玩的方式学习新资料或者解决问题，可以让这个过程变得更让人享受，也让学习变得更容易。为了更好地学习，请更好的玩。

你需要自由地创造——不介意自己的创造没有成功。通过构造来学习，而不是通过学习来构造。（这是“原型”、“曳光弹”、持续集成等方法获得成功的原因之一）

你需要在日常实践中应用到你学到的东西。你持续使用和实践的技能会（在脑皮层竞争中）占据统治地位，大脑会为它们提供更多方便。

这种探索应该相对没有风险，因为你肯定不想因担心害怕而止住探索的脚步。（安全有助于）更好地利用反馈，让失败也变得有意义。

虽然Andy讨论的是广义的学习与探索，但是他的话解释了探索式测试的成功之道。正如Cem Kaner所言：

探索式测试强调测试者的自由和责任，为了持续优化其工作的价值，将测试相关学习、测试设计、测试执行和测试结果解读，作为相互支持的活动，在整个项目过程中并行地执行。

Exploratory software testing emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work, by treating test-related learning, test design, test execution and test result interpretation as mutually supportive activities that run in parallel throughout the project.

探索式测试在本质上鼓励测试人员去自由地探索、创造和应用。

• 《软件测试经验与教训》：“探索是带着使命在某个空间中有目的的漫游，但没有预先确定的路线。探索包括不断学习和实践”。
• 在探索式测试中，测试者创造出一切有助于学习和实践的数据和工具。它们包括输入数据、结果检查脚本、数据分析报告、业务流程图表等。
• 探索式测试者持续应用他所学到的知识。所谓“学而时习之，不亦说乎”，探索式测试将学习与应用作为相互支持的活动逐步展开，为测试者的知识提升提供了平滑的学习曲线。
• 探索式测试是一项富有智力挑战的活动，充满了乐趣。如果你没有感到智力的快感，那么一定是哪里做错了。

此外，Andy也指出，为了鼓励自由的探索，我们需要“安全的”环境。

• 测试者应该拥有独立且隔离的测试环境，他的测试活动所照成的破坏性后果不会影响团队的其他成员。
• 当测试者破坏了他的测试环境，他可以快速地创建新测试环境。虚拟化技术可以提供多样的软、硬件和网络配置。版本管理系统、自动化构建和全自动安装有助于部署特定版本的软件。
• 在测试中使用产品数据甚至产品系统是有很有帮助的。这时，应该将测试环境置于某种沙箱（sand-box）中，使测试导致的产品崩溃或数据损坏不会被沙箱以外的系统所感知。
• 测试环境中内建丰富的开发、测试、调试、监控工具。它们是探索所必需的指南针、GPS、电筒、绳索、背包和帐篷。有经验的探险家不会空手上路。

最后，值得强调的是，所谓“探索”和“学习”都是隐喻（metaphor）。它们是指南针，不是规程手册。Steve McConnell在《代码大全》中用了整整第2章来讨论“用隐喻来更充分地理解软件开发”，很值得一读。通过丰富的案例和分析，他很好地论述了隐喻的威力和范围：

与其说一个软件隐喻是一张路线图，还不如说它是一盏探照灯。它不会告诉你到哪里去寻找答案，而是告诉你该如何寻找答案。隐喻的作用更像启发性方法，而不是算法。

A software metaphor is more like a searchlight than a road map. It doesn’t tell you where to find the answer; it tells you how to look for it. A metaphor serves more as a heuristic than it does as an algorithm.

探索式测试：基本概念

什么是探索式测试？

探索式测试（exploratory testing）是一种自由的软件测试风格，强调测试人员同时开展测试学习、测试设计、测试执行和测试结果评估等活动，以持续优化测试工作。考虑到它所具备的即兴发挥、快速实验、随时调整等特征，其思维方法可以追溯到软件开发的最初岁月。作为一个特定的技术术语，它是由测试专家Cem Kaner博士在1983年提出的，并受到语境驱动的软件测试学派（context driven testing school）的支持。测试专家James A. Whittaker曾是Cem Kaner在佛罗里达工学院（Florida Institute of Technology）的同事，后来担任过微软测试架构师和Google测试总监。基于在微软的工作经历和积累，他撰写了《Exploratory Software Testing》一书，进一步扩展了探索式测试的概念和方法。

探索式测试有丰富的内涵，Kaner博士用一页幻灯片的篇幅介绍了探索式测试的核心。

首先，探索式测试是一种软件测试风格（style），而不是一种具体的软件测试技术（如等价类划分、边界值分析、组合测试等）。作为一种思维方法，探索式测试强调依据当前语境（context）选择合适的测试技术，而不局限于特定的测试技术。虽然James A. Whittaker将他的书命名为《探索式软件测试》，该书所提出的方法集仍旧属于软件测试技术（基于系统化错误猜测和测试隐喻），而不代表整个探索式测试。Whittaker的工作是很有意义的，本文指出它不是探索式测试的全部，是为了强调：当你和别人讨论”探索式测试“时，你们得达成共识。你们是在讨论一种思考方法，还是在讨论这种思考方法指导下的测试技术。

然后，探索式测试强调独立测试人员（individual tester）的个人自由和责任（personal freedom and responsibility），其目的是为了持续优化其工作的价值（value）。测试人员应该为个人和团队负责，调动所有能量，发挥人的灵活性，在整体上持续优化个人和团队的产出。这段描述和精益生产（lean production）、敏捷软件开发的理念高度一致，这也是探索式测试受到敏捷团队欢迎的原因之一。

最后，探索测试建议在整个项目过程中（throughout the project），将测试相关学习（test-related learning）、测试设计（test design）、测试执行（test execution）和测试结果解读（test result interpretation）作为相互支持的活动（mutually supportive activities），并行地（parallel）执行。实际上，人脑难以并行地执行多项任务。探索式测试旨在将测试学习、测试设计、测试执行和测试分析做为一个循环快速地迭代，在较短的时间内（如1个小时）完成多次循环，以不断收集反馈、调整测试、优化价值。该思路再次与敏捷软件开发小步快跑、持续反馈的理念不谋而合。

探索式测试与即兴测试（ad-hoc testing）有何区别？

探索式测试与即兴测试的都强调”即兴发挥“，利用直觉和经验，快速地试验被测试应用，并不停地调整测试策略。开发大师Andy Hunt在《Pragmatic Thinking and Learning》中指出，直觉是非显性知识的代名词，是大脑富（Rich）模式的杰出能力。如果我们只使用大脑的线性模式（语言可表达的显性知识、逻辑思维），而漠视富模式的能量，我们将浪费自身的巨大潜力。

然而人是不完美的，某些直觉可能是认知偏见或错误。这就引出了探索式测试与即兴测试的关键不同：探索式测试是带着”反思“的学习和优化过程。在探索式测试中，测试人员不断地提出假设，用测试去检验假设，通过解读测试结果来证实或推翻假设。在这个过程中，测试人员不断完善头脑中被测试应用的模型，然后利用模型、技能、经验去驱动进一步的测试。相比即兴测试不注重测试计划和设计，探索式测试在不停地优化测试模型和测试设计。因为测试设计和测试执行的切换速度很快，许多人误以为探索式测试没有测试计划和设计。实际上，这些活动是被切分到细微的时间片中，并被反复执行。

如何实施探索式测试？

探索式测试是一种测试风格，它鼓励测试人员依据当前语境选择合适的测试实施方法。我个人认为SMART原则为探索式测试提供了一些很好的建议。

• Specific（具体的）：测试需要一个具体的目标。
• Measurable（可度量的）：有明确的度量可以评估目标是否达成。
• Achievable（可实现的）：当前的目标应该是可实现的。这潜在地要求将一个大的目标分解为多个小目标，每个小目标也是具体的、可度量的。此外，跟踪小目标的完成情况也提供了整体进度的可度量性。
• Relevant（相关的）：目标要切合当前语境，符合团队利益，且不忘企业愿景（vision）。
• Time-boxed（有时间限制的）：为每个目标设定一个合理的最后期限。这是帮助测试人员在固定的时间窗口（time window）中排除不相关干扰、专注工作。

依据SMART原则，测试人员可按如下描述逐步展开探索式测试。

1. 首先，测试人员制定测试计划。他分析被测试应用，确立若干个具体的测试任务，每个任务针对一个可能的风险。
2. 然后，他将测试任务分解为一系列子任务，每个子任务都有明确的退出条件和时间限制。
3. 在短暂的测试计划之后，测试人员根据优先级选择一个小任务，在一个固定的时间窗口中执行探索式测试。我建议时间窗口的长度是50分钟，因为这是人脑可以专注工作的极限时间。再这段时间里，他设计测试，执行测试，评估测试结果，获得知识，然后为了获得新知再设计测试。
4. 在时间窗口结束后，测试人员应该适当休息，放松思维。
5. 随后，他会反思当前的测试进展，并优化测试计划。也许他会为当前任务追加一个时间窗口；也许他会再增加一个新的任务以弥补当前测试计划的不足；也许他会精简一些任务以反映他对测试对象的最新认知。
6. 这时，他会更有自信地开始新一轮探索式测试。

再次重申，以上只是一种可能的探索式测试实施方法。负责任的测试人员一定会选择他自己的方式展开测试，因为只有作为领域专家的他，才能做出最符合语境的决策。当然，集合整个团队的能量，进行伙伴评审、头脑风暴、结对测试等活动，有助于产生更好的测试结果。