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

Question

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

我是初级开发人员，要实现新功能，何时应该设计并记录我的测试用例？

我发现在完成实施后测试所有案例并不实际。这是因为一旦案件失败，我必须更改代码并重新测试所有案例。还有另一种方法可以克服并避免这种情况吗？我知道自动化睾丸是解决方案之一，但不知何故，自动化睾丸无法刺激所有测试用例，尤其是涉及不同方的集成测试用例。

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

非常感谢。

Answer 1

你的问题并不容易回答，因为正如你所说，“这实际上取决于你得到多少时间。”以下是一些意见：

实施后测试： 否

作为一名程序员，你是一个昂贵且稀缺的资源，多个截止日期相互叠加。如此有效，这意味着“永不测试”。在实现了一大块代码之后，您将继续使用下一段代码，并且意味着“当您有时间”时（“您没有时间”）回来编写测试。

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

实施时进行测试： 是

一旦你获得节奏，这种方法实际上非常有用。你写了一个类，然后写了一些单元测试，并不断修改你的测试和你的代码，直到你完成。我相信它实际上比没有测试编写代码更快。

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

测试内容： 尽可能

100％的测试覆盖率可能永远不会实用。但绝对要测试程序的关键部分，执行数学计算的事情或许多业务逻辑。尽可能地测试剩下的所有东西。没有理由测试“toString（）”函数，除非它恰好对业务逻辑或其他东西至关重要。

此外，让您的测试尽可能简单，只需输入和输出。我的大部分测试功能都是两三行。如果您的功能难以测试，因为组合太多，则表明您的功能可能需要稍微分解。确保测试边缘情况和“不可能”的情况。

Answer 2

我的经历：

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

  

或者它实际上取决于你有多少时间？

通过不测试节省的时间永远不会支付您在项目后期花费时间来解决错误的时间。一个合适的测试装置总是在路上付出很多。