一、单元测试：
单元测试作为一种解决方案，让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定、量化的保证。
1.1写单元测试
1.2 好的单元测试的标准
一个好的单元测试，应该准确、快速的保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准：
- 单元测试应该在最基本的功能/参数上验证程序的正确性。
- 单元测试必须由最熟悉代码的人（程序的作者）来写：代码的作者最了解代码的目的、特点和实现的局限性。
- 单元测试过后，机器状态保持不变：这样即可保证单元测试不断的运行，如果创建了临时的文件或目录，应该在Teardown阶段删掉。
- 单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。
- 单元测试应该产生可重复、一致的结果。
- 独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性：程序中的各个模块是相互依赖的，一般情况下单元测试中的模块可以直接引用其他的模块，如果其他的模块很不稳定，或者其他的模块运行比较费时，而且对于本模块的正确性并不起关键作用时，可以认为的构造数据，以保证单元测试的独立性。
- 单元测试应该覆盖所有代码路径。
注意:100%的覆盖率并不等于100%的正确性。 - 单元测试应该集成到自动测试的框架中，这样每个人都能随时、随地运行单元测试。
- 单元测试必须和产品代码一起保存和维护。
1.3 回归测试
- 回归是指模块出现了一个退化，从正常状态回归到以前不正常的状态。能避免遗漏bug，以及确保bug都已解决。
- 例如，上一个版本中所有的单元测试都通过了，在新版本中某个测试未通过，我们就说发生了“倒退”。所以是为了验证新的代码没有破坏模块的现有功能。
- 回归测试最好要自动化，因为这样就可以对于每一个构建快速运行所有回归测试，以保证尽快发现问题。单元测试是回归测试的基础。
- 针对一个bug修复，也要进行回归测试，目的是：
1.验证新的代码的确改正了缺陷。
2.同时要验证新的代码有没有破坏模块的现有功能，有没有regression。
二、效能分析工具
通过效能分析工具，尽快找到程序的效能瓶颈，从而进行程序的改进。通过“效能测试，分析，改进，再效能测试”的流程，逐渐提高程序的效能和我们的编程水平。
可以选择两种分析方法：
Performance Tools 有两种方法，抽样（Sampling）和代码注入（Instrumentation）。前者基于统计，不太准确但是不会影响原有程序的运行。后者注入代码统计准确但是会影响原有程序的运行。
- 抽样：当程序运行时，时不时看一看这个程序运行在哪一个函数内，并记录下来。抽样的运行较快，可以很快的找到瓶颈，但是不能得到精确的数据，也不能准确表示代码中的调用关系树。
- 代码注入：将检测的代码加入到每一个函数中，这程序的一举一动都被记录在案，程序的各个效能数据都可以被精确地测量。但运行时间大大加长，还会产生很大的数据文件，也相应增加了数据分析的时间。
一般的做法是，先用抽样的方法找到效能瓶颈所在，然后对特定的模块用代码注入的方法进行详细分析。
三、个人开发流程
通过大学生和工程师的psp数据比较，我们可以看到从学生到职业的程序员，花在写代码上的时间反而少了许多，更多时间用在“需求分析”和“测试”这两方面。
psp特点：
- 不局限于某一个软件技术（如编程语言），而是着眼于软件开发的流程，这样开发不同应用的软件工程师可以相互比较。
- 不依赖于考试，而主要靠工程是自己手机数据，然后分析，提高。
- PSP依赖于数据，需要工程师输入数据，记录工程师的各项活动，再加上数据不准确或者有遗失。
- PSP的目的记录工程师如何实现需求的效率，而不是记录顾客对产品的满意度。
总结：
通过本章的学习，我学会了一种思想，在学好代码的同时，要运用好单元测试和效能分析，有效的优化代码，提高效率，并保证模块的质量更加的稳定和量化。但是具体如何进行单元测试和效能分析，还需要进一步的学习体会。
标签：测试,个人,效能,程序,代码,单元测试,软件工程,模块,流程 From： https://www.cnblogs.com/jy-211/p/17204526.html