测试代码的理想时间框架是什么

在编写函数规范后,编写测试代码不需要花费“确切”的数字。由于您已经创建了几个测试用例,并且到目前为止遇到了最小/零错误,我想说您走对了路。

当您添加更多代码或重构现有代码时,这些测试用例将充当“安全网”。

我确实记得看到一些统计数据映射了不同项目测试时间的百分比。它在总开发时间中所占的比例从30%到50%不等,较小的项目所占的百分比较小。这也符合我的经验。

此致

理想情况下,你应该花尽可能少的时间编写测试,这意味着你的代码应该可以使用简单明了的单元测试进行测试,你可以通过尝试减少 Cyclomatic complexity 你的代码。

因此,试着专注于编写需要尽可能少的单元测试的代码,简单干净的圆锥体,具有较低的圈复杂度。

对于应该花多少时间编写测试或代码,没有一个标准的时间比例,唯一的衡量标准是测试覆盖率,如果你的代码很简单,你的单元测试也会很简单,需要更少的时间,因此编写单元测试所花费的时间也会更少。

在开始测试代码变得不那么简单之前。

我通常在添加功能后立即开始测试它。

我尽量不使用自动化测试以外的任何东西来测试我的代码。当我构建我的功能时,我不是在构建过程中手动尝试,而是通过测试来尝试。这样就不会比你本来要做的工作多,而且你之后还要做测试。

之后,当我发现bug时,我会添加测试,或者偶尔会覆盖我认为可能是粗心的维护人员添加的bug。这个想法是为了让测试帮助你,而不是妨碍你!

测试上没有固定的时间。这有点像问“写任何功能需要多长时间?”这实际上取决于所写项目的复杂程度和表面积的大小。用户可以用你的工具做的越多,你就越应该测试它。

最终用户面临的任何测试都应该分为两类: 1) 自动化测试。回归测试、单元测试等。 2) 手动测试。等到你基本完成了,然后试着像用户一样完成所有的角落。您不会在自动化测试中涵盖所有内容,也可能不会注意到其中的副作用,因此您需要在发货前进行人工观察。

与其决定花多少时间进行测试,不如决定你认为需要测试什么,并花多少时间。