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…我们完全没有记录……我以前甚至没有想到需要记录。
作者指出，保留测试记录可以用来查看容易出问题的部分，查看整体趋势，并且方便分析处理错误的开销。
但是这个让我们组的人去记录可能会被打……应该大家都不愿意写的……
应该保留个人测试记录，从而记录自己的常见错误与开销。
后记
以前总是觉得写读书笔记写不出很多个人感想，现在写了不少团队项目，才发现个人感想真的多了很多，反而读书看起来像是配角了。
结果整个读书笔记看起来全是碎碎念……