06构建之法阅读笔记04

　　过去的做法：

　　将大部分功能完成后，再进行调试测试。

　　这样做的缺陷：

　　很多Bug同时出现，无法判断是哪里出了问题。

　　解决方法：

　　将代码细块化，一一调试，分开进行bug的调试和修改。

 

　　重点记录：

　　团队统一思想要从基本名词解释开始。

  　　Bug：软件的缺陷

　　  TestCase：测试用例。测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等。

 　　 TestSuite：测试用例集。即一组相关的测试用例。 

　　Bug可以分解为：症状、程序错误、根本原因。

  　　1）症状：即从用户的角度看，软件出了什么问题。

 　　 2）程序错误：即从代码的角度看，代码的什么错误导致了软件的问题。

  　　3）根本原因：错误根源，即导致代码错误的根本原因。

　　各种测试方法：

　　单元测试

　　代码覆盖率测试

　　构建验证测试：

　　顾名思义，构建验证测试是指在一个构建完成之后，构建系统会自动运行一套测试，验证系统的基本功能。在大多数情况下，这些验证的步骤都是在自动构建成功后自动运行的，有些情况下也会手工运行，但是由于构建是自动生成的，我们也要努力让BVT自动运行。

　　验收测试：

　　在MSF敏捷建模中，建议还是采用场景来规划测试工作。

　　“探索式”的测试：

　　就是指为了某一个特定目的而进行的测试，且就这一次，以后一般也不会重复测试。在软件工程的实践中，“Ad hoc”大多是指随机进行的、探索性的测试。

　　回归测试：

　　回归测试不仅仅包括单元测试，也包括其他类型的测试。

　　场景/集成/系统测试：

　　在软件开发的一定阶段，我们要对一个软件进行全面和系统的测试，以保证软件的各个模块都能共同工作，各方面均能满足用户的要求。这类测试叫系统/集成测试。

　　伙伴测试：

　　伙伴测试是指开发人员可以找一个测试人员作为伙伴，在签入新代码之前，开发人员做一个包含新模块的私人构建，测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接与开发人员沟通。通过伙伴测试把重大问题都解决了之后，开发人员再正式签入代码。

　　效能测试：

　　1. 设计负载

　　2. 令用户满意的服务质量

　　压力测试：

　　压力测试要验证的问题是：软件在超过设计负载的情况下是否仍能返回正常结果，没有产生严重的副作用或崩溃。

　　内部/外部公开测试

　　易用性测试

　　小强”大扫荡