2.1单元测试
1.软件的很多错误来源于程序员对模块功能的误解，疏忽或不了解模块的变化。单元的测试可以让自己负责的模块功能定义尽量明确，模块功能的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证。
2.创建单元测试的主要步骤：
- 设置数据
- 使用被测试类型的功能
- 比较实际结果和预期的结果
3.一个好的单元测试应当准确快速的保证程序基本模块的正确性。一个好的单元测试应该满足以下标准：
- 单元测试应该在最基本的功能/参数上验证程序的正确性
- 单元测试应该由最熟悉代码的人（程序的作者）来写
- 单元测试过后机器的状态应保持不变
- 单元测试要快
- 单元测试应该产生可重复、一致的结果
- 独立性-单元测试的运行/通过/失败不依赖别的测试，可以认为构造数据，以保持单元测试的独立性
- 单元测试应该覆盖所有代码路径(100%的代码覆盖率不等于100%的正确性)
- 单元测试应该集成到自动测试的框架中
- 单元测试必须和产品代码一起保存维护
4.回归测试：从正常工作的稳定状态退化到不正常工作的不稳定状态。 回归测试最好要自动化，这样可以对每一个构造快速运行所有的回归测试，以保证尽量早的发现问题。单元测试是回归测试的基础。
2.2效能分析工具
1.效能分析工具可以测试代码运行的效率，让程序员有针对性的对程序代码进行优化升级。
2.常用的方法有：
- 抽样：当程序运行时 效能分析工具时不时的看看程序运行在哪一个函数里，程序运行结束就会得出一个程序运行时间的大致印象。不需要改动程序，可以很快找到瓶颈，但是不能准确表示代码中的调用关系树
- 代码注入：将检验代码加入到每个函数中，这样程序得一举一动都会被记录下来。程序的各个效能数据都会被精准的测量，但是程序的运行时间会大大将长，还会产生很大的数据文件，增加了数据分析的时间，同时注入的程序代码也影响了程序真实得运行情况
3.先抽样找到效能的瓶颈，然后对特定的模块用代码注入的方式进行详细分析。
2.3个人开发流程
1.个人开发流程：软件工程师开发软件的工作流程
2.PSP特点：
- 不局限于某一种软件技术，而是着眼于软件的开发流程
- 不依赖考试，而是要靠工程师自己收集数据，然后分析提高
- 依赖于数据
- PSP的目的是记录工程师如何完成实现需求的效率，而不是记录顾客对产品的满意度。
在此之前，写完代码就结束了，从未做过单元测试，也未考虑过代码效能优化问题。书上调用次数的例子让我明白了代码上的一个微小的改变可以大幅度提高效率。不写单元测试的坏处目前没有体会到，但我知道了亡羊补牢，在每一个模块中把本部分问题解决，否则最后的大窟窿是没办法补上的。编程只是软件开发中的一个部分，从个人开发流程可以看到，需求分析、对方法的使用、总结等都非常重要。