
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
我们在上文中给大家简单介绍了测试驱动开发的一些基础知识等内容,而本文我们就继续来学习一下,测试驱动开发与传统软件测试技术之间的区别。
精益敏捷a测试驱动开发测试驱动开发主要是一种规范技术,它的副作用是确保您的源代码在验证级别得到彻底的测试。然而,还有比这更多的测试。特别是在规模上,您仍然需要考虑其他敏捷测试技术,如生产前集成测试和调查性测试。如果您选择这样做(您应该这样做),那么大部分测试也可以在项目的早期完成。
使用传统的测试,成功的测试会发现一个或多个缺陷。测试驱动开发也是如此;当测试失败时,您已经取得了进展,因为您现在知道需要解决问题。更重要的是,当测试不再失败时,您可以清楚地度量成功。测试驱动开发增加了您的信心,您的系统实际上满足为它定义的需求,您的系统实际上工作,因此您可以满怀信心地继续。
与传统测试一样,系统的风险概要越大,您的测试就需要越全面。对于传统的测试和测试驱动开发,您并不追求完美,而是测试系统的重要性。套用敏捷建模(AgileModeling,AM)的说法,您应该“有目的地进行测试”,并且知道您为什么要进行测试,以及需要测试到什么级别。测试驱动开发的一个有趣的副作用是,您可以实现100%的覆盖率测试—每一行代码都经过测试—这是传统测试无法保证的(尽管它推荐这样做)。总的来说,我认为可以相当肯定地说,尽管测试驱动开发是一种规范技术,但是它有一个有价值的副作用,那就是它比传统技术的代码测试结果要好得多。
不管喜欢与否,大多数程序员都不阅读系统的书面文档,相反,他们更喜欢使用代码。这没什么不对的。当试图理解一个类或操作时,大多数程序员先会寻找已经调用它的示例代码。编写良好的单元测试正是这样做的——提供功能代码的工作规范——因此单元测试有效地成为技术文档的重要部分。这意味着支持文档的人群的期望需要反映这一现实。类似地,验收测试可以成为需求文档的重要部分。当你停下来思考的时候,这是很有意义的。您的验收测试准确地定义了涉众对您的系统的期望,因此它们指定了您的关键需求。您的回归测试套件,特别是使用测试优先的方法,有效地成为详细的可执行规范。
测试是否有足够的文档?很可能不会,但它们确实构成了其中重要的一部分。例如,您可能会发现仍然需要用户、系统概述、操作和支持文档。您甚至可能发现,您需要摘要文档来查看系统支持的业务流程。当您以开放的心态处理文档时,我怀疑您会发现这两种类型的测试涵盖了开发人员和业务涉众对文档的大部分需求。此外,它们是AM的单一源信息实践的一个很好的例子,也是您在文档方面保持尽可能敏捷的整体努力的一个重要部分。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。