|
这是我最钟爱的一个预测，THUD( THUD 是Tester's Head UP Display的缩写，测试人员的平视显示器，平视显示器(HUD)是将资讯投射于飞行员正前方玻璃上的飞行辅助仪器)是我们正在积极建造的一个工具。项目管理者联盟
这是我们对于软件测试未来预测的第三部分，它要讨论的主题是信息的未来，测试人员在未来如何利用信息使他们的测试做得更好。项目管理者联盟
预测1：测包项目管理者联盟
预测2：虚拟化项目管理者联盟
预测3：信息项目管理者联盟
你使用哪些信息来帮助自己测试软件?测试规范?用户手册?在此之前(或与之竞争)的版本?源代码?网络协议分析器?进程监控器?这些信息是否有用?它们拿来就可以直接使用吗?talent.mypm.net
信息是所有软件测试工作的核心。作为测试人员，对软件应该有哪些功能，它是如何实现的，了解的越多，我们的测试就会做的更好。如果测试人员对于他们测试的软件知之甚少，并且了解到的信息都不是专门针对测试工作的，让它做的更加容易，这样的情况是不能接受的。我可以高兴的说，这样的局面正在迅速地发生改变……并且在短期内，我们一定会实现在正确的时间，获得正确的信息。项目管理者联盟
我从电子游戏中获得了测试信息的这些想法。在电子游戏中，我们在桌面上显示着相关信息并近乎完美地运用着它们。关于游戏、玩家、对手和环境的资料，你了解得越多，你就会玩得更好，获得更好的分数。在电子游戏中，它们都显示在一个叫HUD或者成为平视显示器的玩意儿里。一个玩家的能力、武器和健康值都显示在一个迷你地图中，对手的类似资料也可能会有(我儿子过去玩Pokemon时，他可以在游戏中通过访问Pokedex，了解他可能遇到的所有Pokemon怪物)。这些游戏的思想很简单：你拥有并且可以使用的信息越多，你就越有机会在游戏中通关。项目管理者联盟
我非常想把这个思想原封不动地转给软件测试人员，给他们更多的信息来增加他们成功的机会。但是，在测试世界里，由于缺乏这种丰富的信息基础构造，所以大部分测试都陷入黑盒测试，哪里是我们的迷你地图，可以指出当前正在测试哪一个屏幕，它是如何使系统其它部分连接起来的?为什么我不能将鼠标悬停在一个图形用户界面控件上以看到源代码，设置这个控件所包含的(以及我们可以测试的)属性列表?如果我在测试一个API，为什么我不能看到我和我的测试伙伴们已经测试过的参数组合呢?我需要迅速得到所有这些信息，并以简洁易用的格式来帮助我进行测试，而不是去某些SharePoint站点或是数据库中乱翻一气，因为那些地方充满了其他项目中的各种人为产品，与我的测试毫无关联。它们只会让我分心，我需要一个平视显示器。项目管理者联盟
我在微软的同事乔艾伦穆哈尔斯基(Joe Allan Muharsky)把我渴望的这些信息称为THUD——测试人员的平视显示器——将测试人员找出软件缺陷并验证功能所需要的信息格式化，使之成为向其服务的一种即时可用资料。你可以讲THUD看作是一层表皮，它将正在进行测试的应用程序包裹起来，随着应用程序的上下文环境，浮现出对其测试有用的资料和工具。目前，THUD用的很少，甚至有的THUD没有包含正确信息。正如在游戏中，没有玩家会想着不用THUD就穿越不可预知的危险世界一样，到了将来，没有测试人员会想着不用THUD就进行测试。项目管理者联盟
如果这听起来有点像作弊的话，就随便你怎么向了。玩家通过HUD进行欺骗，相对那些没有这样做的，的确可以给他们带来更大的优势。由于内部测试人员可以访问源代码、协议、后端、前端和中间件，所以我们确实可以进行这样的“欺骗”。我们可以利用这些欺骗获得的巨大优势，比普通黑盒测试人员和用户更好地寻找软件缺陷。这正是我们想要的情形：比其他任何人更快、更有效地找到自己的软件缺陷。这是我全心全意认同的欺骗，可是目前，我们却没有利用这些欺骗所需要的信息。项目管理者联盟
在未来我们会这样做，与我们现在的信息饥渴相比，那样的未来将完全不同。blog.mypm.net
回顾过去，显示世界并不是完美无缺的，我们无法预测未来是美好的，所以，这个预测显得令人迷惑不解。但是，由于这是对未来的预测，我们不知道未来会怎样，就还算过得去。许多人谈论着软件开发周期里的测试前移。据我所知，我们使测试人员参与规范审查等等已经几十年了。这是测试人员前移，而不是测试前移。我们真正应该做的是，在软件开发周期中，尽早获得可测试的东西，使我们尽快开始测试。项目管理者联盟
测试前移www.mypm.net
在测试中存在一个鸿沟，它在整个软件开发周期中蚕食着软件的质量、生产效率和其他可控特性。这个鸿沟就是从软件缺陷产生直到它被发现的时间鸿沟。这个鸿沟越大，软件缺陷在系统中停留的时间就会越长。显然，这是很糟糕的，但是，我们过去所做的，仅仅是指出软件缺陷在系统中待的时间越长，清楚它的代价也就越大。项目管理者联盟文章
在将来，我们要做的是：消除这个鸿沟。项目管理者联盟
但是，消除这个鸿沟意味着对我们目前测试方式的根本转变。在2008年，一名开发人员，完全是处于偶然，就可以引入一个软件缺陷，这一现象提醒着你——我们的开发环境没有什么办法阻止它发生，直到二进制代码构建好以后，开发h饿测试人员很少会协调一致的努力寻找软件缺陷。我们引入软件缺陷并让它们自由蔓延，直到在开发周期的最后阶段，依靠那些善于在软件开发后期寻找软件缺陷的英雄们，将我们带出困境。项目管理培训
作为软件测试人员，我们提供了宝贵的软件缺陷寻找和分析技术，所以在今后，我们所要做的是，在软件开发周期中尽早应用这些技术，远远早于我们目前所处的阶段，我预见有两种主要的方法会帮助我们达到这个目的。一个是不等二进制运行代码构建好，直接将测试应用于软件开发周期的早期开发阶段。第二个是尽早地构建二进制运行代码，使我们能够尽快地测试。项目管理者联盟
下面让我们从’早期开发阶段测试‘开始，就这两种方法逐个进行讨论。在开发周期的后期英雄主义阶段里，我们运用所有的软件缺陷寻找方法，在可运行的二进制代码中根据发布的接口寻找软件缺陷。我们把编译好的二进制代码、程序集合和字节代码等拿来放到测试沙袋中，用数据和输入反复击打它，直到我们挖出足够的软件缺陷病确定待测目标的质量足够好(在将来的博客里，我也许会介绍测量和发布标准)。但是为什么要等到二进制代码准备好呢?为什么我们不能应用这些测试技术在产品架构阶段?……或是分析用户需求和场景阶段?……或是规范和设计阶段?莫非在过去半个世纪积累起来的所有测试技术，测试工艺和测试智慧，只能用于软件运行阶段?为什么系统架构不能用同样的方法进行测试呢?嗯，答案是没有好的理由让我们不这样去做。事实上，我认为微软有很多先进的团队的确将测试技术应用到早期开发阶段，在将来我们会找到这样做的系统方法。测试将会开始于，不像现在这样，当某样东西可测的时候，而是当某样东西出现了而需要测试的时候。这是一个微妙但是重要的区别。项目管理者联盟文章
“尽早构建二进制运行代码”是要讨论的第二部分，但是这样做代表我们需要克服一个技术上的障碍。在2008年的时候，我们一个接一个的编写软件模块，如果缺乏所有模块中的其中之一，我们就不能构建出一个整体。这意味着，测试工作必须等到所有的模块完成到某种程度才能进行。软件缺陷可以存活几天或者几周，知道测试开始并发现它们。我们可以用虚拟的模块来替代哪些部分完成的模块吗?或是用适配器来模仿外部的行为?我们能够构建通用的变色龙组件，让它改变自己的行为去配合它们(暂时)嵌入的系统?我预测会的……因为我们必须这样做。虚拟组件和变色龙组件将可以使测试人员，在紧接着一个软件缺陷产生出来后，就施展它们的检测手艺。这些软件缺陷将很少有机会在露面之后还能劫后余生。PgMp.mypm.net
测试工作相当重要，不要等到开发周期结束才开始进行。是的，目前交互式开发和敏捷开发较早地创建了可测试代码(尽管功能较小，功能不完整)，但是发布软件后，我们仍然有很多的软件缺陷。我们现在所做的远远不够。未来必定会将测试应用到软件开发的早期阶段，使我们在代码完全建立之前就搭建好可行的、可测试的环境。项目管理者联盟
（本文摘自James Whittaker所著《探索式软件测试》附录3）项目管理者联盟 项目管理者联盟
|
