场景/集成/系统测试（Scenario/ Integration / System Test）

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

　　问：有一种测试叫Scenario Test，是什么意思？

　　答：就是以场景为驱动的集成测试，关于“场景”，大家可以看专门的介绍。这一方法的核心思想是：当用户使用一个软件的时候，他/她并不会独立使用各个模块，而是把软件作为一个整体来使用的。我们在做场景测试的时候，就需要考虑在现实环境中用户使用软件的流程是怎样的，然后模拟这个流程，看看软件能不能达到用户的需求。这样，能使软件符合用户使用的实际需求。

　　以一个数字照片编辑软件为例，这个软件的各个模块都是独立开发的，可是用户有一定的典型流程，如果这个流程走得不好，哪怕某个模块的质量再高，用户也不会满意。用户的典型流程是：

　　（1）把照相机的储存卡插入电脑。

　　（2）程序会弹出窗口提示用户导入照片。

　　（3）用户根据提示导入照片。

　　（4）对照片进行快速编辑。

　　a）调整颜色；

　　b）调整亮度，对比度；

　　c）修改红眼。

　　（5）选择其中几幅照片，用E-mail发送。

　　这里面哪一步出了问题，都会影响用户对这一产品的使用。如果这里面各个模块的用户界面不一致（即使是“确认” 和 “取消” 按钮的次序不同），用户使用起来也会很不方便。这些问题都是在单独模块的测试中不容易发现的。

　　问：什么时候做集成测试？是不是越快越好？

　　答：原则上是当一个模块稳定的时候，就可以把它集成到系统中，和整个系统一起进行测试。在模块本身稳定之前就提早做集成测试，可能会报告出很多Bug，但是这些由于提早测试而发现的Bug有点像汽车司机在等待绿灯时不耐烦而拼命地按喇叭——有点像噪音。我们还是要等到适当的时机再开始集成测试。

　　问：但是开发人员也想早日发现并修复所有的Bug，软件工程的目标不就是要早发现并修正问题么？总是要等待，听起来好像没有多少效率。

　　答：对，这就要提到在微软内部流行的另一种测试——Buddy Test伙伴测试。

　　伙伴测试（Buddy Test）

　　如上所述，在开发一个复杂系统的过程中，当一个新的模块（或者旧模块的新版本）加入系统中时，往往会出现下列情况。

　　（1）导致整个系统稳定性下降。不光影响自己的模块，更麻烦的是阻碍团队其他人员的工作。

　　（2）产生很多Bug。这些Bug都要被输入到数据库中，经过层层会诊（Triage），然后交给开发人员，然后再经历一系列Bug的旅行，才能最后修复，这样成本变得很高。

　　如何改进？一个方法当然是写好单元测试，或者运用重构技术以保证稳定性等，我们要讲的伙伴测试是指开发人员可以找一个测试人员作为伙伴（Buddy），在新代码签入之前，开发人员做一个私人构建（Private Build），其中包括了新的模块，测试人员在本地做必要的回归/功能/集成/探索测试，发现问题直接和开发人员沟通。通过伙伴测试把重大问题都解决了之后，开发人员再正式签入代码。

　　在项目的后期，签入代码的门槛变得越来越高，大部分团队都要求Bug fix必须得到了伙伴测试的验证后才能签入到代码库中。