测试未来的预测
我的主要预测就是，将来的软件测试与现在的软件测试看起来很不一样。原因很直接：今天的软件测试很大程度上是臭名昭著的：软件测试参与到项目中的时间太晚、贡献太少、花费太高。如果我们关心我们产品的质量以及我们的账本底线的话，我们就需要重新思考测试和质量的方法。即使遭到一致反对，我也要说：更好的方法，对测试人员更好的培训、更好的欣赏将改革软件产业。具体地说，诸如可执行的说明书、基于模型的测试产生、BUG预防、系统模拟这些技术，将在这场演变过程中扮演重要的角色。下面就是我们在将来的几年里可能看到的情形。事实上，某些趋势已经开始了。测试人员，需求撰写人员和开发人员，都将看到自己是其中的一份子。测试人员帮助需求撰写人员测试人员与需求撰写人员共同工作，在需求完成以后，审查以及理解需求。早期的审查以及建模可以暴露很多关于一致性、完整性和模糊性的BUG，这个时候修补这些BUG付出的代价还十分小。需求撰写人员帮助测试人员测试小组建造模型，用于产生对其产品行为的测试。需求撰写人员审查模型，以确保他们充分覆盖了产品特征集。这样产生的测试模块将成为一个“可执行需求”。测试人员帮助开发人员因为需求清楚，毫不含糊，开发人员更好的理解了他们的代码将要完成什么。在正式的将代码提交做测试之前，测试人员提供给开发人员一些模型，以便开发人员可以在自己的代码中实现它们。开发人员帮助测试人员基于”特征对特征”这样的方式(防止以往的“后期才介入开发,一股脑找出产品问题”的方式),开发人员和测试人员共同保证代码易于实施自动测试.开发人员的代码中处处都是易测试性的开关,使得错误检测更加容易. 测试人员帮助测试人员测试用一种高级语言来模拟,因此别的特征的测试小组(甚至别的产品的测试小组)可以复查和改进测试模型.这就形成了一个测试专家的共同体. 方法日趋完善BUG预防和早期检测因为现在把重点放在产品交付的质量上来了(而不是在于找到了多少BUG), 预防实践和静态分析仪这样的检测工具将成为主流. 仿真测试仿真工具变得很普遍,使得仿造计算机环境变得容易起来.在开发过程的早期就可以进行意外和错误流程的测试.代码稳定后,再用真实环境验证仿真是否准确无误. 及时的测试用例庞大的测试用例管理系统将成为昔日的东西,大量的测试用例生成了却没有被使用.测试用例将不再像腐烂的存货一样被收藏起来,因此,让测试用例保持最新变得容易起来. 积极的方法误导人的方法,比如计算BUG的数量、计算测试用例的数量,将不复存在.有用的方法,比如需求覆盖、模型覆盖、代码覆盖将驱动项目开发. 更少更精的测试人员机器将代替测试人员做大部分他们以往创建测试所做的繁琐工作,测试小组需要比以往更少的测试人员,留下来的测试人员将是经过更多高度培训过的.他们所做的工作将更加有趣,因为在测试中他们将致力于更大的问题,而不是在抱怨中艰难地开展工作. 更多更好的测试测试人员将可以在一天中进行成千上万的测试,所以,如何首先运行最有用的测试将成为一大挑战.相关的工具将允许测试人员为他们的测试区分优先级,以及将测试目标放在那些最易出现重大BUG的地方. 测试人员的角色更换测试中界限模糊在测试领域工作使得专职测试的人员和专职创建测试工具的人员界限模糊,一个既是“通过程序破坏事物的测试员”又是”创建程序用于破坏事物的程序员”的专业出现了,――关于如何称呼这个新的专业，新闻圈内的人们还在进行着无休止的争论。测试与开发界限模糊测试人员与开发人员一前一后，共同创造可测试的、高质量的代码。测试人员帮助开发人员消除需求中的问题，使得开发人员的工作更易完成，同时，开发人员写出更清晰、可测性更高的代码，使得测试人员的工作更易完成。顾客反馈与测试合为一体交付的产品质量更高。测试人员进行根本原因的分析，我们会问比如“我们怎么会遗漏了这个BUG呢？”或者“我们将来如何防止这类BUG？”这些问题，我们的工作就是使顾客满意。新的挑战出现复杂和相互关联的计算机世界使得了测试安全这一类的新问题让测试人员不断努力工作，但这没关系――因为这些挑战使测试人员精力充沛。测试人员获得尊重测试人员将不再是在最后时刻才被叫来“对产品狂轰烂炸”，他们将在整个软件开发过程中提供一个可见的、重要的、增值的服务。人们意识到，测试是有益的、有趣的甚至富有乐趣。 | |
