过去的做法：
将大部分功能完成后，再进行调试测试。
这样做的缺陷：
很多Bug同时出现，无法判断是哪里出了问题。
解决方法：
将代码细块化，一一调试，分开进行bug的调试和修改。
重点记录：
团队统一思想要从基本名词解释开始。
Bug：软件的缺陷
TestCase：测试用例。测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等。
TestSuite：测试用例集。即一组相关的测试用例。
Bug可以分解为：症状、程序错误、根本原因。
1）症状：即从用户的角度看，软件出了什么问题。
2）程序错误：即从代码的角度看，代码的什么错误导致了软件的问题。
3）根本原因：错误根源，即导致代码错误的根本原因。
各种测试方法：
单元测试
代码覆盖率测试
构建验证测试：
顾名思义，构建验证测试是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。在大多数情况下，这些验证的步骤都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。
验收测试：
在MSF敏捷建模中，建议还是采用场景来规划测试工作。
“探索式”的测试：
就是指为了某一个特定目的而进行的测试，且就这一次，以后一般也不会重复测试。在软件工程的实践中，“Ad hoc”大多是指随机进行的、探索性的测试。
回归测试：
回归测试不仅仅包括单元测试，也包括其他类型的测试。
场景/集成/系统测试：
在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，各方面均能满足用户的要求。这类测试叫系统/集成测试。
伙伴测试：
伙伴测试是指开发人员可以找一个测试人员作为伙伴，在签入新代码之前，开发人员做一个包含新模块的私人构建，测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接与开发人员沟通。通过伙伴测试把重大问题都解决了之后，开发人员再正式签入代码。
效能测试：
1. 设计负载
2. 令用户满意的服务质量
压力测试：
压力测试要验证的问题是：软件在超过设计负载的情况下是否仍能返回正常结果，没有产生严重的副作用或崩溃。
内部/外部公开测试
易用性测试
小强”大扫荡