一、单元测试
单元测试的作用：让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证。
1.1 好的单元测试的标准
- 单元测试应该在最基本的功能/参数上验证程序的正确性。
- 单元测试必须由最熟悉代码的人（程序的作者）来写。
- 单元测试过后，机器状态保持不变。
- 单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。
- 单元测试应该产生可重复、一致的结果。
- 独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
- 单元测试应该覆盖所有代码路径。
- 单元测试应该集成到自动测试的框架中。How？
- 单元测试必须和产品代码一起保存和维护。
1.2 回归测试
１．定义：从正常工作的稳定状态退化到不正常工作的不稳定状态。
２ 目的：验证新的代码的确修改了缺陷和同时验证新的代码有没有破坏模块的现有功能。
回归测试对我来说时很陌生的，我好像以前很少或者几乎不适用，我认为这个在以后可能会用到，我也会在编程的过程中去有意识地想这个。
二、效能分析工具
效能分析工具可以测试代码运行的效率，让程序员有针对性的对程序代码进行优化升级。常用的方法有两个：
- 1.抽样。
- 2.代码注入。
抽样就是当程序运行时 效能分析工具时不时的看看程序运行在哪一个函数里，程序运行结束就会得出一个程序运行时间的大致印象。抽样的有点是不需要改动程序运行较快可以很快找到瓶颈但是不能得出精确数据也不能准确得表示出代码中得调用关系树。
代码注入就是将检验代码加入到每个函数中，这样程序得一举一动都会被记录下来，程序得各个效能数据可以被精准的测量，但是缺点也很明显，他会让程序运行的时间大大加长，还会产生大量得数据文件也增加了数据分析得时间，同时注入的程序代码也影响了程序真实得运行情况。所以一般常用先抽样找到效能的瓶颈所在让后对特定的模块用代码注入的方式进行详细得分析。
三、个人开发流程
| PSP2.1 | |
|---|---|
| Planning | 计划 |
| *Estimate | 估计这个任务需要多少时间 |
| Development | 开发 |
| *Analysis | 需求分析 |
| *Design Spec | 生成设计文档 |
| *Design Review | 设计复审（和同事审核设计文档） |
| *Coding Standard | 代码规范（为目前的开发制定合适的规范） |
| *Design | 具体设计 |
| *Coding | 具体编码 |
| *Code Review | 代码复审 |
| *Test | 测试（自测，修改代码，提交修改） |
| Reporting | 报告 |
| *Test Report | 测试报告 |
| *Size Measurement | 计算工作量 |
| *Postmortem & Process Improvement Plan | 事后总结，并提出过程改进计划 |
PSP有如下的特点：
-
不局限于某一种软件技术（如编程语言），而是着眼于软件开发的流程，这样，开发不同应用的软件工程师可以互相比较
-
不依赖于考试，而主要靠工程师自己收集数据，然后分析，提高
-
在小型、初创的团队中，很难找到高质量的项目需求，这意味着给程序员的输入质量不高。在这种情况下，程序员的输出（程序/软件）往往质量也不高，然而这并不能全部由程序员负责
-
PSP依赖于数据
- 需要工程师输入数据，记录工程师的各项活动，这本身就需要不小的时间代价
- 如果数据不准确或有遗失，怎么办？让工程师编造一些？
- 如果一些数据不利于工程师本人（例如：花很多时间修改缺陷），我们怎么能保证工程师愿意如实地记录这些数据呢？
-
PSP的目的是记录工程师如何实现需求的效率，而不是记录顾客对产品的满意度