软件测试的未来-测试软件probe测试不出手机的信号强度

在这篇文章发表后，我接到了一个电话，是我们从事隐私保护的伙计打来的。微软正在克服各种困难，尽力保护客户的隐私，并且处处留意，不给盗窃个人信息身份的人留下任何可乘之机。但是，我仍然认为需要通过软件将测试深入到这个领域当中。这种软件应当是自我测试和自我诊断的软件。的确，这涉及到未来关于用户隐私的问题，但我们肯定可以克服它们。

软件发布后的测试

这是“软件测试的未来”系列的最后一部分。我希望你喜欢它。在这篇文章里记录着也许是我的预测中较有争议的一部分：即在将来推出产品的时候，我们会随之附上可以远程运行的测试代码。读到这里，我看到黑客露出了奸笑，也听到隐私倡导者们大发雷霆，但接下来我将针对这些关注做出自己的回应。

当Vista发布时软件测试的未来，我在Windows部门。记得一天晚上，我在家里向8岁的儿子展示Vista。他在计算机上玩了（并写作业了，如果你愿意相信的话）很长时间，他真的很喜欢Aero界面，炫酷的边框小工具，并且他喜欢的那些游戏（在当时是“线条滑雪”和“动物园大亨”）在运行速度上给他留下了深刻的印象。我记得那时就想，“他不去写计算机这一行的博客真是太可惜了”，但这是题外话。

在演示的最后，他问了我一个让每位测试人员都害怕回答的问题：“老爸，这里面哪部分工作是你做的？“

我一时无语，这对我来说十分罕见，然后我就结结巴巴，语焉不详。你怎样向一个8岁的孩子讲清楚自己干了几个月的工作（那时我刚加入微软，仅涉及Vista开发末期部分）却没有真正创造出任何东西？我试图用干巴巴的常规答案来回答这个令人恐惧的问题（答案必须是以感叹号结尾……这样可以帮助我说服自己软件测试的未来，让我觉得自己所说的有一定道理）：

“我让它更好！”

“现在它运行的这么好……嗯，就是因为我！”

“如果不是我们测试人员，这个东西就是对社会的威胁！”

我特别喜欢最后这一句。然而，所有这些都是空洞的。我怎么会这样，致力于一个产品这么长时间，所做的贡献只是“让它少一些软件缺陷”，而不是其他什么值得夸耀的东西。

我觉得，在这个时候我灵感迸发：测试代码应和二进制代码一起发行，它应该在产品发布后仍然有效，依旧做着它应该做的工作，即使没有测试人员。这不是一个蹩脚的企图，不是用来让我和我的同胞们拥有指着软件产品夸耀的权利，而是提供持续不断地测试和诊断，使它不断的提高。让我们直面这个现象吧，产品发布时我们的测试并没有完成，为什么要停止它呢？

我们已经在这方面做了一些工作。正在推广中的Watson技术（著名的“发送或不发送”错误报告的Windows应用程序），可以让我们错误发生时，当场捕获它们。下一个合乎逻辑的步骤就是对这些错误采取相应的补救措施。

目前，Watson捕获到故障后，就记录下相关调试信息的即时场景。然后，某些处在管道另一端的可怜虫就得在所有这些数据中奔波，试图找到解决方案通过Windows Update来解决它。这在2004年是一项革命，目前仍然是。但在2~5年内，它将成为明日黄花。

如果这个可怜虫可以利用在软件发布前就已经有的测试基本测试基本体系结构来运行更多的测试，情况又会怎样？如果这个可怜虫可以安装一个实际修复程序，并且在真实的环境中运行一个回归测试套件，情况又会怎样？如果这个可怜虫可以安装一个实际修复程序，并且让应用程序自己进行回归测试，情况又会怎样？

他将不再是一个可怜虫，这是肯定的。但是，由于测试和测试产品在最终产品构建和发布时被遗忘了，所以这种情形根本不可能发生。

为了实现这些功能，应用程序必须记住它先前的测试结果，并且无论在任何情况下，都得一直将它保存下来，这就意味着，自我测试能力将会成为未来软件的一个基本功能。我们的工作将会使找出如何把测试魔力嵌入到应用程序本身中去。我们的奖励将是愉快地看见自己的孩子在看到我们设计的这些最酷的功能时，眼睛闪闪发亮！

哦，担忧黑客和隐私问题的伙计们：不用怕！对于二进制运行代码中包含测试代码会出现的问题，修汤普森（Hugh Thompson）和我早就警告过，（参见《如何破坏软件安全》一书中“第10次攻击”的章节）。如果我们知道如何攻破应用程序，我们也就可以更好地修复它。

本文摘自James Whittaker所著《探索式软件测试》附录3

相关链接：

软件测试的未来

33/33

可视化技术是我们在工具的世界中取得最大进展的领域之一。这是一个只需要短短几年就可以实现的领域。再过两到五年将会变成像玩电子游戏一样。

可视化。

软件是什么样子的？如果在构建软件或测试软件时就能看出它的使用情况，对我们岂不有益？如果能做到这样，只要瞟一眼，我们就能看到软件中没有完成的部分。我们也将很容易看出其中的关联、接口和数据，正如我们所希望的那样，它在测试过程中是如何通过输入同上下文环境进行交互的。

其他工程学科都有这样的可视化效果。比如制造汽车的伙计们。在装配生产线上的每一个人都能够看到汽车。他们可以看到，车上还没有安装保险杠或方向盘。他们可以看到汽车在生产线上的整个装配过程，从一个空壳直到所有功能完备，可以径直开到经销商那里。汽车下线后还要等多久才算是装配完毕呢？嗯，从生产线的末尾开始四十英寸吧！

所有参与制造汽车的人们都共享产品的视觉效果，这对汽车的生产很有帮助。生产者使用所有人都能够理解的术语，这是因为每一个部件，每一个连接，每一个接口再他们共享的汽车效果图中，都在它们应该在的地方，不可能产生歧义。

不幸的是，测试世界并不是这样的。前面问到的问题，诸如“等多久才算装配完毕呢？”或“哪些任务还没有完成？”都在困扰着我们。这是21世纪测试人员要解决的问题。

架构师和开发人员已经在解决可视化这个问题。Visual Studio 充满了图例和可视化元素，从执行序列图到依赖关系图都有。测试人员也正在解决这个问题。在帝国的城墙内，已经出现了可视化的解决方案，比如通过观察看Xbox标题中的代码改动（修改过的代码对象会呈现绿色，测试完之后才变成正常），来判断未测试代码在代码库中的复杂行（代码覆盖的热图与代码复杂性热图的比对，将以三维的形式表现出来，供测试人员直接找到问题区域）。这种可视化的效果是惊人的、优美的，它使测试人员一眼就看出那些地方需要测试。

我们需要更多这样的东西来解决可视化问题，但是我们需要认真地对待他们。我们不能简单的接受UML和模型生成器提供的试图。那些图画是用来解决其他问题的，他们不一定适合我们面临的问题。现有的很多视图是为架构师和开发人员的不同要求服务的。我们需要从测试人员的角度看待可视化。我们需要的视图要能够映射软件需求到对应到代码、到对应的接口、代码改动到对应图形用户界面，以及代码覆盖到对应的控件。如果我们在测试环境下执行应用程序时，能够看到控件闪烁着不同程度的光，这些光的强度反映了代码覆盖的程度，或者是与之相关的测试用例的数量，这难道不好吗？如果我们可以把网络利用率或是通信的实际时间，用图形动画的方式显示出来，这难道不好吗？为什么我们不应当看到即时发生的网络流量和查询？在应用程序的表面下隐藏了许多看不到的东西，现在是时候把他们挖掘出来并加以利用了，他们将有助于我们提高代码质量。

这是一个可以短期解决的问题，很多聪明人正在努力解决它。这是具有生动色彩的软件测试。

测试文化

几个月前我参加了一个讲座，它由一名技术院士（也许是一名杰出工程师，我觉得这两者之间没什么不同）主讲，他是微软帝国里为数不多的精英之一。就像所有的技术院士一样，这个家伙聪明得有些邪门，在介绍他和他们的团队正在构建的某个新产品的设计时，我突然觉得自己领悟到了什么。

很明显，这个顿悟使我的面部表情像正在排肾结石。这名技术院士注意到了（坐在我前面的女孩也一样，但我不想岔开话题），然后他就在讲座结束后找到我。以下是我们谈话的原文：

“詹姆斯，”（他知道我的名字！）“你看起来像是对我的设计或是产品有些问题。我很乐意听听你的意见。”

“不，我对你的产品或是设计没有问题。我的问题在于你自己本身。”

“哦？”

“像你这样的人把我吓到了。“我告诉他，”你把时间都集中于构思系统功能，实现用户场景和设计用户界面和协议。你处在一个重要的位置，人们会听你的话去构建你所设想的东西。但你做的所有这些都没有从测试的基本角度考虑一下。”

在那个时候他开始试图做正确的事情……把注意力转移到测试上来。他邀请我审查讲座里涉及到的设计。这正是你期望他做的。

但是对于测试而言，这也正是错误的反应。

让测试人员参与设计肯定要好的多。但是这样做的好处也有限。测试人员只寻找可测试性（testability）问题。开发人员寻找应用方面的问题。谁兼顾这两个方面呢？谁能决定这两者之间的正确取舍？测试人员和开发人员都无法做到，让测试人员参与设计仅仅表明有所改善；让设计者（以及其他的周期里的角色）参与测试才是我们的将来。

31/3123>

说真的，怎么会出现这种情况，构建软件的人为什么会对测试了解得这么少？为什么我们以前没有试图解决这一问题？作为测试人员，我们是不是过于执着于当前的角色，以至于小心翼翼地守护着通向软件测试智慧王国的钥匙？测试是否过于隐秘和晦涩，以至于开发人员无法找到他们所寻求的答案？开发人员是否过于习惯将这一“无聊”的阶段交付给我们，以至于他们认为这些是理所当然的？

添加测试人员是没有用的。让他们更早参加开发周期也没有用。在我们的产品中，开发人员和测试人员的比例是1：1，但是这些产品本身却没有体现出高可靠性。我们有些产品在开发时有着更加糟糕的开发人员测试人员之比，但是他们的质量很明显高于其他产品。我认为，在未来，我们会看到开发周期的角色分工没有什么好处。这种角色的分工甚至必然导致测试在开发工程中的延迟，从而不能发挥出它应有的潜能。

目前的测试文化和软件开发周期中的角色分工有问题，解决它的方法是合并开发周期中的角色。质量必须是人人有责。套用托尔金的话：“One role to rule them all！”

请你想象一下这样一个世界，每一个软件开发周期的人都掌握了测试知识。系统架构师知道测试，设计人员知道测试，开发人员知道测试，并且他们不停地将测试知识应用到他们所做的任何一件事中。这样做并没有让我们取消单独的测试人员角色，因为我们要确定某些测试的独立性，好让我们进行更好的测试。如果在整个产品开发过程中的每一个决策都问到了正确的测试问题，那么最终系统测试的完整性将达到一个我们目前梦寐以求的水平。如果项目中的每个人都理解测试，想象我们需要很少测试人员就可以达到这一水平。

实现这样一个测试乌托邦需要大规模的文化变革。测试必须要延伸到学术界，或者其他有程序设计课程的地方。开发人员在他们事业上取得进步的同时，这样的教育也必须持续下去，并变得更先进、更强大。我们需要促使这种教育达到一定程度，即软件开发项目的所有利益相关者都理解测试并且潜移默化地将测试应用到他们所做的任何一件事情中。测试工具终有一天也会支持这点。有一天我们会处于这样一种情况，即永远不编写不可测试的软件，这不是由于某些强势的测试人员造成的，而是开发项目中的每一个都自觉这么做。

测试在开发流程中如此重要，以至于它不能成为流程中的“扫尾工作”。在开发流程的早期，设计决策影响着测试，因为测试的解决办法在设计时就已经确定。测试如此重要，以至于不能把它交给一个独立的软件开发周期角色划分出来的角色，让他只致力于质量保证。相反，我们需要一场根本性的文化变革，让质量成为每一个人的责任，并把它的原则植根于我们所做的每一件事。

我弄砸了这篇文章的标题，我应当叫它“测试即软件”，因为我更想让它包含这层意思。日复一日的测试活动将提高到更高的层次，测试里的所有核心资产，例如测试环境，可重用的测试用例，将作为成品上架供任意取用。但这只是将来最初的形式，并且还略有瑕疵。

测试人员即设计人员

目前测试人员主要扮演着软件开发中后期的英雄角色，这种角色在业绩评估和分红时往往得不到赏识。在我们发现严重软件缺陷的时候，人们认为这是我们应该做到的……理应如此。在我们漏掉软件缺陷的时候，人们就开始提问题了。事情往往就是这样，你做了就没人理，忘了就会有人训。

这种情形将会改变，并且会很快地改变，因为我们必须改变。我的朋友罗杰？谢尔曼（Roger Sherman）——他是微软的第一个测试总监——将这种测试角色的变革比喻为毛毛虫变成了蝴蝶。这句话出自罗杰：“测试工作蜕变出来的蝴蝶就是设计工作”。

我完全赞同。当测试和测试技术转移到开发流程的早期，测试人员做的工作更类似于软件设计人员，而不仅是软件验证。我们将更多地注重设计软件质量控制的策略，它不是只适用于二进制运行代码，而是适用于软件开发周期的所有产品当中。我们将花更多的时间在确定开发流程中的测试需求，而不仅仅是执行测试用例。我们将监测和衡量自动化测试的效用，而不仅仅是构建和调试它们。我们将花更多的时间审核已有测试用例的状态，而不是构建新的用例。我们将成为设计人员，把软件测试抽象到更高层次，并在开发周期的早期进行这一工作。

在微软，这个角色称为测试架构师，我相信大多数测试工作是向着这个方向演化。如果已经读了“测试的未来”这个系列的前六部分，会赞同这一观点，在以前提到的变化中，首当其冲的应该是使以设计为中心的测试成为可能的变化。

这听起来像是一个不错的未来，但是已经有一朵乌云笼罩在这片云彩上。这朵乌云来自于软件缺陷种类和软件测试类型，对于这两方面，在2008年，我们都做的不错。没有太多夸张，目前我们善于找出结构性的软件缺陷（指的是崩溃、挂起以及同软件相关的错误，而不是和它功能相关的错误），而不是业务逻辑方面的软件缺陷。但是，在我这一系列文章里描绘出的未来，对于结构性的软件缺陷，我们将有无数的技术解决方案。这使测试人员不得不去对付业务逻辑方面的软件缺陷，可是对于这类问题，我不认为我们目前整个测试行业都在使用有组织、有目的的方式去对付它。

寻找业务逻辑方面的软件缺陷意味着我们必须要了解业务逻辑本身。理解业务逻辑远远不止包含与客户和竞争对手打交道，它意味着我们得将自己沉浸在我们软件涉及到的任何行业中；它不仅意味着在软件生命周期的早期进行测试，还要使我们自己涉足原型、需求分析、可用性等我们从未涉足的地方。

在软件生命周期早期的困难工作中，有些是测试人员从未经历过的。要想在测试一开始就有一个良好的表现，就意味着我们要面临这些挑战，并愿意通过学习新的思维方式，来看待客户和看待质量。

在软件生产线的前端，事情肯定和末端完全不同，在前端，越来越多的测试人员将发现自我的价值，就像是将来给现在让路一样，他们地位会完全颠倒过来。

32/3