我应该什么时候设计和记录我的测试用例？

Question

在SDLC中，测试程序应该在实施后立即进行。然而，测试驱动开发鼓励我们在实现的同时进行测试。在我的讲座中，教授说测试用例应该是设计的一部分。

我是一名初级开发人员，为了实现一个新功能，我应该什么时候设计和记录我的测试用例？

我发现实现完之后再去测试所有的案例不太实际。因为一旦某个case失败了，我就得改代码，重新测试所有的case。还有其他方法可以克服和避免这种情况吗？我知道自动化测试是解决方案之一，但不知何故，自动化测试无法刺激所有测试用例，特别是涉及不同各方的集成测试用例。

另外，在我的测试用例中，我应该测试代码的所有部分吗？或者只是测试该功能请求的功能？或者这实际上取决于你有多少时间？

非常感谢。

Answer 1

你的问题不太容易回答，因为正如你所说，“这实际上取决于你有多少时间。”不过，这里有一些意见：

实施后进行测试否

作为一名程序员，您是一种昂贵且稀缺的资源，并且有多个截止日期相互叠加。实际上，这意味着“从不测试”。实现了一段代码后，您将继续执行下一段代码，并意味着“当您有时间时”（您永远没有时间）回来编写测试。

还有你提到的问题。如果您在编写代码后进行了所有测试，并且您的测试发现了根本性错误，那么您必须返回并修复所有代码以及所有测试。

边实施边测试： 是的

一旦你掌握了节奏，这种方法实际上非常有帮助。您编写一些类，然后编写一些单元测试，并不断修改您的测试和代码，直到完成。我相信它实际上比在没有测试的情况下编写代码更快。

在处理大型项目时它也特别有帮助。运行单元测试来查看一个小模块是否正在工作是即时的。构建并加载整个应用程序以查看某个小模块是否正常工作可能需要几分钟的时间。它还可能会干扰您的注意力（至少需要 10 分钟）。

测试什么： 尽可能多

100% 的测试覆盖率可能永远不切实际。但一定要测试程序的关键部分，即执行数学计算或大量业务逻辑的部分。尽可能测试剩下的一切。没有理由测试“toString()”函数，除非它恰好对业务逻辑或其他东西至关重要。

另外，让你的测试尽可能简单，只有输入和输出。我的大多数测试函数都是两三行。如果您的函数由于组合太多而难以测试，则表明您的函数可能需要进行一些分解。确保测试边缘情况和“不可能”的场景。

Answer 2

我的经验：

1. 如果代码不言自明，或者正在测试的情况是一个“棘手”的极端情况，乍一看并不明显（尽管代码可能是），请记录您的测试。
2. 不要为您的测试创建单独的文档。如果您使用 Java，请将所有内容都放在注释和 Javadoc 中。换句话说，让这些信息靠近代码。这就是需要它的地方。
3. 关于设计和实现：迭代即可。编写一些实现，然后编写一些测试代码，然后编写更多实现代码，等等......直到完成实现和测试代码。它比编写所有实现、然后测试、然后重写失败的实现代码要快。您无法预期在设计时要实现的所有测试，这是不可能的。所以，如果您没有全部掌握，也不必担心。
4. 如果您覆盖了 80% 以上的代码，那么您就已经很好了，越多越好。有时，代码无法测试。我建议使用测试覆盖率工具，例如 Emma for Java。

或者这实际上取决于您有多少时间？

不进行测试所节省的时间永远无法弥补项目后期解决错误所花费的时间。一个合适的测试集总是会带来很大的回报。