《代码大全2》读书笔记(八)

时间:2021-09-21 16:06:29

22.4 典型错误

更清晰地了解典型错误有助于我们更高效地查错。

错误同样遵循二八原则,80%的错误存在于项目的20%类或者子程序中,50%的错误存在于5%的类或者子程序中。
在编程过程中要对出现的错误进行归纳。(这个提醒很好,我以后可以时不时整理一下近期错误,太久远就忘记了)

书中给出了一个可供参考的错误分类,由于该分类不是结论性的,在此不加摘抄。但这个分类提示我们:

  • 大多数错误影响范围有限,可以通过小幅修改改正。
  • 许多错误并非源于构建。常见的其他错误来源:应用领域知识缺乏(如做一个数学软件却不够了解数学知识)、频繁更改需求、沟通和协调失效。
    作者提出,小型项目中,构建的错误占了绝大多数。就算在大型项目中,构建错误也占了至少35%。对于软件的应用领域了解越清晰,越容易减少错误。
  • 笔误居然是很常见的错误。
    这种错误真的是,如果不是IDE会自动提示笔误,我肯定有一堆笔误……之前还有一个智障的错误,因为一个问题查了一个多小时,结果发现有两个类同名,而我不小心import了错误的类……

期望发现多少错误?

通常而言,平均1000行有1 ~ 25个错误。这提醒我们不要抱有侥幸,认为自己的代码完美无缺。
微软部门的经验是,内部测试程序大约每1000行有10 ~ 20个缺陷,已发布的程序大约1000行有0.5个缺陷。不过我们水平当然不是微软,所以1000行可能有个20个错误吧……

测试本身的错误:测试甚至比生产代码更容易出错,因为书写时可能不那么仔细。
可以用来减少测试的错误的一些方法:检查、开发软件时就要使用测试用例、保留使用过的测试用例、常用单元测试。
就我个人,其实经常发生测试用例写错了的情况,不过幸好现在的代码都不难,所以修改起来也比较简单。这个似乎也没有万能的解决办法,只能多检查了。

22.5 测试支持工具

常用工具

测试脚手架:书中的内容没太看懂,所以我查了一下这个概念。其实就是用户只需要写最少的测试代码,脚手架自动生成其他的代码进行测试。有许多已有的测试框架提供脚手架功能,如Junit(我们这次就用了Junit)。
我在网上查到有一些人自己写了测试脚手架,感觉是真的勇士……自从我开始用测试框架之后就不想再自己写这种代码了,自己写又容易错又麻烦,还要考虑各种乱七八糟的因素。

Diff tool:用来比较文件。这似乎是unix下的一个命令行工具?我知道的另外一个很好的工具有beyond compare(可以用来比较文件,甚至递归比较,图形化界面也很好)。git也有diff功能。

测试数据生成器:这个通常只能自己写了,因为不同的代码的测试数据模式不同,。这个策略似乎常常用于对拍,我试过类似的策略。

分析工具

覆盖率工具:分析哪些代码被测试覆盖了,哪些还没有。
日志记录器:可以自己写,不过我们的Android studio有自带的(IDE大法好
调试器:这个一般的IDE都有吧,我们的当然也有,不过因为AVD debugger太慢了所以我们经常直接用日志调试,emmmmm…感觉不太好但是也不知道怎么处理。
系统干扰器:模拟一些常见的内存问题,比如说内存抖动、内存访问失败。另外也可以用来检查是否内存越界,对内存进行垃圾值填充。(这么高级的东西我们还没用到……)

整体来说,很多作者推荐的功能已经集成到IDE里面去了,或者有其他现有框架,不需要自己写。IDE大法好。

22.6 改善测试过程

有计划的测试:计划代码时就应该考虑测试。按照我的经验,写测试的时间几乎是写生产代码时间的三分之一到二分之一。每次我写测试队友不写测试我就很烦躁,因为这样我进度就显得特别慢……
不过确实测试是有意义的。而我们组在测试这方面不太规范,一方面因为测试套件不那么熟悉,另一方面因为很多人负责用户界面,这个实在写测试很麻烦。下次开会的时候讨论一下测试的事情。

回归测试:每次修改后检查和上次运行结果是否一致。我并没有有意进行回归测试,而只进行了单元测试。这够不够呢?单元测试每次都运行正常,不就说明运行结果一致么?我也不知道有没有这种操作。不过单元测试有已有框架,回归测试则少有框架。

自动化测试:好处已经提过很多了,就略去了。我们的测试框架可以自动化测试,但我们没有设置。也许设置隔一段时间自动运行所有测试样例会好?

22.7 保留测试记录

应该保留:行政记录(我们几个学生行政记录个什么……)、问题的完整描述、严重程度、复现步骤、绕过问题的建议、相关缺陷、问题根源、问题分类(我们对错误了解太少了根本没法正确分类啊QWQ)、修正错误所改变的类和子程序、查找与修正的开销
感觉这个记录有点像github体系中的issue。

emmmm…我们完全没有记录……我以前甚至没有想到需要记录。
作者指出,保留测试记录可以用来查看容易出问题的部分,查看整体趋势,并且方便分析处理错误的开销。
但是这个让我们组的人去记录可能会被打……应该大家都不愿意写的……

应该保留个人测试记录,从而记录自己的常见错误与开销。

后记

以前总是觉得写读书笔记写不出很多个人感想,现在写了不少团队项目,才发现个人感想真的多了很多,反而读书看起来像是配角了。

结果整个读书笔记看起来全是碎碎念……