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

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

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

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

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

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

　　伙伴测试（Buddy Test）

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

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

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

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

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

　　在开发软件的过程中，开发团队希望让用户直接接触到新版本的软件，以便从用户那里收集反馈，这时开发团队会在开发过程中让特定的用户（Alpha/Beta用户）使用正处于开发过程中的版本，用户会通过特定的反馈渠道（E-mail、BBS）与开发者讨论使用中发现的问题，等等。这种做法成功地让部分用户心甘情愿地替开发团队测试产品并提出反馈。

　　从惯例上说，Alpha Test一般指在团队之外，公司内部进行的测试；Beta Test指把软件交给公司外部的用户进行测试，与之对应地，软件有Alpha、Beta1、Beta2版本。在网络普及之前，做Beta Test是很花费人力物力的事情，现在由于网络的传播速度很快，与外部用户的联系渠道很畅通，很多外部用户都想先睹为快。因此近开发团队增加了反馈的密度，不必再局限于Alpha或者Beta发布，而是不断地把一些中间版本发布出去以收集反馈，美其名曰“技术预览版本”（Technical Preview Release）或“社区预览版本”（Community Preview Release）。

　　易用性测试（Usability Test）

　　小燕：作为测试人员，我们是不是也要做易用性测试？

　　答：测试人员，以及其他的团队成员都可以对软件的可用性提出意见，包括以Bug的形式放在TFS中。软件的可用性并不神秘，是让软件更好用，让用户更有效地完成工作。

　　但是我觉得“易用性测试”似乎更多地用来描述一套测试软件可用性的过程，这个过程一般不是由测试人员来主导的，而是由对软件设计及对可用性有很多研究的“可用性设计师”来实行。网络上有许多关于这方面的文章，大家可以参考。

　　为了弄清软件的可用性，并了解用户的需求，移山公司的员工特地进行了一个易用性测试——

　　小飞学了很酷的Web“WPF/我佩服”界面技术，然后做了一个小游戏——3D挖雷。大家用了之后，都觉得不错，用鼠标单击/双击，左键/右键都可以进行各种不同的操作。于是他们迫不及待地找一个“典型用户”来做易用性测试。

　　王屋村的村民，石头他爹刚好路过，他被移山公司的小伙子们拉了进来，成为第一个“典型用户”。

　　大家七嘴八舌地介绍了游戏的功能，让石头他爹试一试。石头他爹看到鼠标，说，这个怎么和俺家里的不一样？小飞说：这是光电鼠标，好用得很！

　　三分钟过去了，游戏还没有开始；

　　五分钟，十分钟过去了，游戏还是没有进展。

　　阿超走过去看看到底怎么回事——