①重要的单元测试：有效解决程序员对模块功能的误解、疏忽或不了解模块的变化之类的问题，使自己负责的模块功能定义尽量明确，模块的质量得到稳定的、量化的保证。
②好的单元测试的标准：
在最基本的功能/参数上验证程序的正确性
单元测试必须由最熟悉代码的人（程序的作者来写）
单元测试过后，机器的状态保持不变
单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）
单元测试应该产生可重复、一致的结果
独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性
单元测试应该覆盖所有代码路径
单元测试应该集成到自动测试的框架中
单元测试必须和产品代码一起保存和维护
③单元测试的基础上能够建立关于这一模块的回归测试，目的是：
（1）验证新的代码的确改正了缺陷
（2）同时验证新的代码有没有破坏模块的现有功能，有没有Regression
2.2 效能分析工具
效能分析方法：抽样和代码注入
2.3 个人开发流程
个人开发流程PSP（Personal Software Process）
特点：（1）不局限于某一种软件技术，而是着眼于软件开发的流程，这样，开发不同应用的软件工程师可以互相比较。
（2）不依赖于考试，而主要靠工程师自己收集数据，然后分析、提高。
（3）在小型、初创的团队中，很难找到高质量的项目需求，这意味着给程序员的输入质量不高。在这种情况下，程序员的输出（程序/软件）往往质量也不高，然而这并不能全部由程序员负责。
（4）PSP依赖于数据（工程师输入数据的时间代价、数据可能遗失或者不准确的风险、可能会出现一些数据不利于工程师本人的情况）
（5）PSP目的是记录工程师如何实现需求的效率，而不是记录顾客对产品的满意度，工程师有可能很高效地开发出一个顾客不喜欢的软件。
个人感受：
我过去写代码，尤其是写类的函数，都是全部写完之后进行测试，然后大概率会出现很多bug。
书中说的是首先要吧一个问题分为多个单元，比如一个函数分为多个板块，例如链接数据库的读操作，
如果一下子全部写完出现问题根部不知道是链接错误还是读函数错误等等。在解决bug的时候就很费劲。
根据书中所说，每写完一个单元就进行测试，测试结果满意后在进行下一单元的编程，这样看似很慢，
但是一旦进入大量的工程项目，这样是会节省很多时间的，这也是一个很好的编程习惯。
标签：01,测试,工程师,代码,单元测试,笔记,程序员,构建,模块 From： https://www.cnblogs.com/2351920019xin/p/17233377.html