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



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

我是一个初级开发人员,要实现一个新功能,我应该什么时候设计和记录我的测试用例?

我发现在完成实现后测试所有的用例是不太实际的。因为一旦一个案例失败了,我就必须更改代码并重新测试所有的案例。有没有其他方法可以克服和避免这种情况?我知道自动化测试是一种解决方案,但是不知何故,自动化测试不能激发所有的测试用例,特别是涉及不同方的集成测试用例。

同样,在我的测试用例中,我应该测试代码的所有部分吗?或者只是测试功能请求的功能?还是取决于你有多少时间?

许多谢谢。

你的问题不那么容易回答,因为,正如你所说,"这实际上取决于你有多少时间。"以下是一些观点:

测试后实现: 没有

作为一个程序员,你是一个昂贵而稀缺的资源,有多个截止日期堆叠在一起。所以实际上,这意味着"永远不要测试"。在实现了一段代码之后,您将继续编写下一段代码,并打算"当有时间时"再回来编写测试(您永远没有时间)。

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

测试而实现:

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

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

测试内容: 尽可能多

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

同样,让您的测试尽可能简单,只有输入和输出。我的大多数测试函数都是两到三行。如果您的函数因为有太多的组合而难以测试,这表明您的函数可能需要稍微分解一下。确保测试边缘情况和"不可能"的场景。

个人经历:

  1. 记录你的测试,如果代码不是不言自明的,或者如果正在测试的情况是一个"棘手"的角落情况,这是不明显的第一眼(尽管代码可能是)。
  2. 不要为您的测试创建单独的文档。如果使用Java,请将所有内容放入注释和Javadocs中。换句话说,让这些信息靠近代码。这就是需要的地方。
  3. 关于设计和实现:迭代。编写一些实现,然后为它编写一些测试代码,然后编写更多的实现代码,等等……直到您完成了实现和测试代码。它比编写所有实现,然后测试,然后重写失败的实现代码要快得多。不能预期在设计时实现的所有测试,这是不可能的。所以,如果你没有完全理解,也不用担心。
  4. 如果你覆盖了超过80%的代码,你已经很好了,越多越好。有时,代码无法测试。我建议使用测试覆盖工具,比如Java的Emma。

或者这实际上取决于你有多少时间?

不进行测试所节省的时间永远永远都抵不了您在项目后期解决bug所花费的时间。一个合适的测试集总是会在未来的道路上付出很多,总是。

相关内容

  • 没有找到相关文章

最新更新