測试未来的预测.doc

测试未来的预测 发布时间: 2007-5-18 10:31 作者: 未知 来源: 网络 字体: 小 中 大 | 上一篇 下一篇 | 打印 摘要：一年将尽，心理学家或者一些博学者们，又将对2004年或者更久的将来作出预测。在这次的周末专栏中，Harry Robinson将向我们讲述他对测试未来的预测。 “预测是件很难的事情，尤其是预测未来” —Yogi Berra 每年十二月，小报的“未来预测者”们会向大家切揭示即将到来的一年将要发生的事情：“麦丹娜将要乘坐航天飞机”，“美国将迁都 Wichita”，等等。我将加入这个潮流，对软件测试何去何从做一个我自己的预测。并且我希望，我的预测费用能够比我的那些值得尊敬的小报同事更高些。 我的主要预测就是，将来的软件测试与现在的软件测试看起来很不一样。原因很直接：今天的软件测试很大程度上是臭名昭著的：软件测试参与到项目中的时间太晚、贡献太少、花费太高。如果我们关心我们产品的质量以及我们的账本底线的话，我们就需要重新思考测试和质量的方法。 即使遭到一致反对，我也要说：更好的方法，对测试人员更好的培训、更好的欣赏将改革软件产业。具体地说，诸如可执行的说明书、基于模型的测试产生、BUG预防、系统模拟这些技术，将在这场演变过程中扮演重要的角色。 下面就是我们在将来的几年里可能看到的情形。事实上，某些趋势已经开始了。 测试人员，需求撰写人员和开发人员，都将看到自己是其中的一份子。 测试人员帮助需求撰写人员 测试人员与需求撰写人员共同工作，在需求完成以后，审查以及理解需求。早期的审查以及建模可以暴露很多关于一致性、完整性和模糊性的BUG，这个时候修补这些BUG付出的代价还十分小。 需求撰写人员帮助测试人员 测试小组建造模型，用于产生对其产品行为的测试。需求撰写人员审查模型，以确保他们充分覆盖了产品特征集。这样产生的测试模块将成为一个“可执行需求”。 测试人员帮助开发人员 因为需求清楚，毫不含糊，开发人员更好的理解了他们的代码将要完成什么。 在正式的将代码提交做测试之前，测试人员提供给开发人员一些模型，以便开发人员可以在自己的代码中实现它们。 开发人员帮助测试人员 基于”特征对特征”这样的方式(防止以往的“后期才介入开发,一股脑找出产品问题”的方式),开发人员和测试人员共同保证代码易于实施自动测试.开发人员的代码中处处都是易测试性的开关,使得错误检测更加容易. 测试人员帮助测试人员 测试用一种高级语言来模拟,因此别的特征的测试小组(甚至别的产品的测试小组)可以复查和改进测试模型.这就形成了一个测试专家的共同体. 方法日趋完善 BUG预防和早期检测 因为现在把重点放在产品交付的质量上来了(而不是在于找到了多少BUG), 预防实践和静态分析仪这样的检测工具将成为主流. 仿真测试 仿真工具变得很普遍,使得仿造计算机环境变得容易起来.在开发过程的早期就可以进行意外和错误流程的测试.代码稳定后,再用真实环境验证仿真是否准确无误. 及时的测试用例 庞大的测试用例管理系统将成为昔日的东西,大量的测试用例生成了却没有被使用.测试用例将不再像腐烂的存货一样被收藏起来,因此,让测试用例保持最新变得容易起来. 积极的方法 误导人的方法,比如计算BUG的数量、计算测试用例的数量,将不复存在.有用的方法,比如需求覆盖、模型覆盖、代码覆盖将驱动项目开发. 更少更精的测试人员 机器将代替测试人员做大部分他们以往创建测试所做的繁琐工作,测试小组需要比以往更少的测试人员,留下来的测试人员将是经过更多高度培训过的.他们所做的工作将更加有趣,因为在测试中他们将致力于更大的问题,而不是在抱怨中艰难地开展工作. 更多更好的测试 测试人员将可以在一天中进行成千上万的测试,所以,如何首先运行最有用的测试将成为一大挑战.相关的工具将允许测试人员为他们的测试区分优先级,以及将测试目标放在那些最易出现重大BUG的地方. 测试人员的角色更换 测试中界限模糊 在测试领域工作使得专职测试的人员和专职创建测试工具的人员界限模糊,一个既是“通过程序破坏事物的测试员”又是”创建程序用于破坏事物的程序员”的专业出现了,――关于如何称呼这个新的专业，新闻圈内的人们还在进行着无休止的争论。 测试与开发界限模糊 测试人员与开发人员一前一后，共同创造可测试的、高质量的代码。测试人员帮助开发人员消除需求中的问题，使得开发人员的工作更易完成，同时，开发人员写