测试人员与TDD

2020-06-26 04:10:20

测试驱动的开发应该消除对独立测试的需要。唉,这还不够深入。

测试驱动开发(TDD)赢得了使软件更健壮的声誉。这是不是意味着你可以解雇所有的测试员?剧透:不。

测试驱动开发是一种以小块编写软件的方法。您从测试开始,然后编写功能代码以使测试通过,最后重构功能代码以清理它。TDD的想法是由Kent Beck在20世纪90年代早期提出的,作为极限编程(一种敏捷软件开发方法)的一部分。

TDD有时被概括为“红色、绿色、重构”。许多测试工具上的接口,比如JUnit(用于Java)和NUnit(用于.NET),在测试失败时显示红灯,在测试通过时显示绿灯。然而,还有另一个步骤需要考虑。您需要考虑所需的行为,并划出一小段代码(通常为5行)来实现下一步。

正如Beck所建议的,在TDD中,除非测试失败,否则永远不会编写功能代码。然而,学习首先(而不是事后)编写测试是需要练习的;开发人员经常难以改变他们习惯的工作方式。在编写功能代码之前编写测试感觉是错误的。你确实会习惯它,尽管这可能需要几个月的时间;到那时它就会开始感觉对了。

TDD的最大好处是消除了破坏代码的恐惧。在添加单元测试和功能代码时,您还构建了一个经常运行的回归测试库。当您添加新特性、修复bug或重构以清理代码时,再次运行测试可以确保您没有破坏任何东西。或者至少可以确认您没有破坏您编写的任何测试。

当程序员采用TDD时,软件经理有时会想要取消或减少软件QA部门,理由是程序员也在编写测试。这个决定通常是错误的,因为测试人员在开发人员的单元测试之外提供了价值。

单元测试只是充分覆盖现代代码所需的测试类型之一。TDD开发人员很少编写端到端集成测试。他们可能会避免编写需要大量设置或依赖于其他软件组件(如填充的数据库)的单元测试。

专门的测试人员比程序员更有可能花时间执行探索性(特别)测试,这可以发现在代码开发过程中没有想象到的错误。与长时间沉浸在软件中的程序员相比,测试人员使用产品时也会有新的视角。

此外,软件开发人员通常对设置CI/CD工具或将团队的测试组织到主回归测试中不感兴趣。测试人员认为所有这些都是工作的一部分。开发人员可能不会参与实现超出TDD的左移测试。对于左移测试,测试人员可以在单个测试或一行功能代码完成之前收集信息,帮助进行需求管理,并帮助定义验收标准。

安全性是一个很大、很重要的测试领域,通常不会通过编写单元测试来解决。测试人员使用自动化漏洞测试工具、手动安全评估、渗透测试、安全审计和安全审查来查找安全缺陷。

开发人员很难编写单元测试来测试GUI。相反,测试人员使用特定于支持的应用程序环境的自动化工具,例如浏览器、桌面应用程序和移动应用程序。

开发人员可能很难处理与硬件相关的错误,因为主要的工作方式是让编码器在一台机器上工作。QA部门经常收集装满各种计算机和设备的房间,以及许多操作系统版本的图像。在许多不同型号的设备上进行测试的另一种方法是使用众包测试服务。

虽然理论上TDD可以在边缘情况下捕获错误,但它们被称为“边缘情况”是有充分理由的。当编码器为功能点设计测试时,模糊的边缘情况可能在瞬间不会引起注意。测试人员比编写软件的程序员更有可能找到这些。

同样,跨模块缺陷有时可以在单元测试中逃脱检查。当一个程序员误解了另一个程序员模块的接口或边界条件时,很容易出现这种情况。在端到端测试和临时测试期间,经常会发现跨模块错误。

总之,尽管TDD作为一种开发实践有很多话要说,但它通常不会提供代码的完整测试覆盖。为此,您仍然需要测试人员。

无论谁编写测试用例,遵循既定的指导原则都是有意义的。这些可能会有帮助。

马丁·海勒是一名自由撰稿人。他以前是一名Web和Windows编程顾问,在1986到2010年间开发了数据库、软件和网站。最近,他曾担任阿尔法软件公司的技术和教育副总裁和图比菲公司的董事长兼首席执行官。