有大量用例的单元测试

Question

我正在研究一个有很多用例的java应用程序.对应用程序的输入是在不同时间发生的不同类型的事件.这种输入引发了数百个测试用例.有人遇到过这种情况吗？在向QA团队发布之前,您是否确保涵盖所有测试用例？所以我的问题是:测试具有大量测试用例的程序的最佳方法是什么？

Answer 1

不要试图从一开始就覆盖整个应用程序的单元测试.以小的增量步骤进行.设置一个小里程碑,在一两周内到达,然后开始为该里程碑的第一个功能编写测试.然后开始实现该功能.它应该是这样的:

小的,渐进的步骤

1. 将应用程序细分为您可以在那一刻看到的较小的功能里程碑
2. 选择最紧迫的功能,有实现的那一刻
3. 将该功能分解为较小的任务
4. 为其中一个任务编写测试
5. 运行测试.它应该失败(RED).如果它通过你的测试被打破.
6. 开始编写最少量的代码,以便通过该测试.允许使用硬编码值.
7. 运行测试(绿色).它们应该通过(特别是在使用硬编码值时).现在你知道你有一个安全网用于未来的重构.
8. 如果需要,请开始重构(REFACTOR)您的代码,否则请转到步骤4.

准备改变

这种方法的优点是将一项巨大的任务分解为可管理的部分,它使您有机会在一两周内完成一些任务.稍后,管理层可能会重新考虑他们的优先级,您必须从上面的第一点重新组织列表.另一个优点是,每一步都有一个支持你的单元测试让你有信心,你实际上已经完成了某些事情,而且你实际上可以比你想象的更快地向你的管理层提供一些东西,因为你在每一步都有一个(有点)你的程序的工作版本.他们可以看到进步,这对你和他们都非常重要.他们看到工作实际上已经完成,并且您获得了应用程序所需的反馈(需求总是在变化,让我们尽可能地保持变化).

正如Gren所说,你可能会将用例与单元测试混淆.用户可以对应用程序执行的操作也可以由域模型中的单个方法处理.所以情况可能不像看起来那么糟糕.

没有前期设计,即使是单元测试

无论如何,不​​要试图从头开始编写所有测试.这就是我这样做的方式,这是一个很大的失败.一旦你做了小的迭代(测试方法/方法实现),你就会变得更有效率和自信.在预先编写所有测试时,你可能会注意到由于你的第一次测试通过所需的因素分析,你需要重新思考你在编写测试时想象的整个API,而写一个测试,然后执行,测试,然后执行,你最终得到它所谓的紧急设计.这是最好的设计.这就是设计模式的出现方式.设计模式并非出自一整天站着的人,并想出了解决问题的方法.

Answer 2

如果您有数百个测试用例,我认为这是因为它反映了输入的可变性和应用程序的要求？

如果您没有为所有这些(已知)案例编写测试,那么您将如何知道您是否已提供所需的功能？

自动化测试的替代方案是手动测试,我无法看到与自动化测试相比,手动测试数百个测试用例将如何为您节省时间.