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

Question

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

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

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

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

非常感谢.

Answer 1

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

实施后测试: 没有

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

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

实施时测试: 是的

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

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

测试内容: 尽可能多

100%的测试覆盖率可能永远不可行.但绝对要测试程序的关键部分,执行数学计算的事情或许多业务逻辑.尽可能地测试剩下的所有东西.没有理由测试"toString()"函数,除非它恰好对业务逻辑或其他东西至关重要.

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