1. 单元测试
一般情况下一个软件是由多人合作完成的。 尽可能的让自己负责的模块独立化，在保证自己稳定的同时，还不要影响其他功能模块。单元测试就是一个解决方案。
1.1 写一个单元测试
可分成如下几步
- 新建一个项目，如控制台项目console
- 在该项目下添加一个类Email，类中包含要测试的方法
- 选择当前解决方案，新建项目->测试->单元测试项目
- 给单元测试项目添加引用，将console添加进来
- 通过测试->运行->所有测试，来查看测试结果
单元测试简单举例
https://blog.csdn.net/chr23899/article/details/53035062
1.2 用以验证的Assert类/断言
除去异常类exception，还有断言的Assert类
| 方法 | 含义 |
|---|---|
| AreEqual | 主要功能是判断两个值是否相等；如果两个值不相等，则测试失败 |
| AreNotEqual | 如果两个值相等，则测试失败 |
| AreSame | 如果两个输入内容引用不相同的对象，则测试失败 |
| AreNotSame | 如果两个输入内容引用相同的对象，则测试失败 |
| Fail | 断言失败 |
| Inconclusive | 表示无法证明为 true 或 false 的测试结果 |
| IsFalse | 指定的条件是否为 false；如果该条件为 true，则测试失败 |
| IsTrue | 指定的条件是否为 true；如果该条件为 false，则测试失败 |
| IsInstanceofType | 测试指定的对象是否为所需类型的实例；如果所需的实例不在该对象的继承层次结构中，则测试失败 |
| IsNotInstanceofType | 如果在该对象的继承层次结构中，则测试失败 |
| IsNull | 测试指定的对象是否为非空，空则测试通过 |
| IsNotNull | 不为空则测试通过 |
1.3 如何写好单元测试
- 应该能准确的、快速的保证程序基本模块的正确性
- 测试的应该是一些底层的基本单元，在此基础上再测试其他功能
- 对API的每一个方法及参数都要涉及
- 代码的目的特点以及局限性，作者是最熟悉的，模块单元测试由该模块作者来写最合适
- 单元测试测试的是单元，单元测试要快（一个测试时间应为几秒，而不是几分钟）
- 有了模块化的功能，对每个功能都有对应的单元测试，这样在更改某个功能时，只需找到对应的单元测试运行查错即可。
- 单元测试的运行、通过、失败不依赖于其他测试，应保证独立性。
- 要做到对代码的全覆盖，保证覆盖率，必须测试公开的和私有的函数、方法
- 即使是通过也存在一些异常情况。另外还有代码效率低下等诸多问题
- 单元测试代码应与源程序一起妥善保管加以维护，争取将其自动化。否则会浪费多余的时间在寻找哪里出错上，额外增加负担
1.4 回归测试
如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那么这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。
回归测试的目的很明显：
- 验证新代码是否改正了缺陷
- 验证新代码有没有破坏模块现有的功能
回归测试就可以理解为回归到以前不正常的状态。这样把以前记录的bug找出来，并一个个验证，一个个修复，这样是一个不断修复bug的过程。
2. 效能分析工具
当编译和执行一个工程时,可以在Debug和Release两种配置下执行。
- Debug模式又称调试版本。用于调试程序，这是个受保护的运行环境，它将告诉你程序是否有泄露，在运行时也能对特定函数的结果进行检查。然而它生成的可执行文件运行较慢。我们Debug过程中为什么可以打断点，为什么鼠标放在变量上就显示值，因为编译器背后加了很多测试代码。
- Release模式又称发布版本。当你的应用经过测试准备投入使用时，你应该在Release模式下进行编译，这将生成供最终用户使用的可执行文件。虽然Release下也可以打断点，但是有时候有些变量的值在Release下是看不见的。调试的话应该用Debug。它往往进行了各种优化，以期达到代码最小和速度最优。
VS 提供了自带的分析工具：performance tool (性能分析)
VS菜单栏->调试->性能探查器，在这里可以诊断程序的性能问题、识别应用程序中最常见的高开销方法。常用工具如下所示：
- 这样可以方便的很快定位到一些效率低下反复调用的无用代码，将程序进行改善，提升运行速度。