验收测试(Acceptance Test)

 
测试团队拿到一个"可测"的构建之后，就会按照测试计划，测试各自负责的模块和功能，这个过程可能会产生总共10来个甚至100个以上的Bug，那么如何才能有效地测试软件，同时在这一阶段该怎样衡量构建的质量?在MSF敏捷模式中，我们建议还是采用场景来规划测试工作。在"基本场景"的基础上，把系统在理论上目前支持的所有场景都列出来，然后按功能分类测试，如果测试成功，就在此场景中标明"成功"，否则，就标明"失败"，并且用一个或几个"小强"/Bug来表示失败
的情况。当所有的测试人员都完成了对场景的测试后，我们自然就得这样就能很快地报告"功能测试56%通过"等。如果所有场景都能通过(有些情况下可以将该标准从100%降至90%左右)，则这个构建的质量是"可用"的，这就意味着这一个版本可以给用户使用了。在这种情况下，客户、合作伙伴可以得到这样的版本，这也是所谓"技术预览版"或"社区预览版"的由来。但是，有一个重要的问题要提请大家注意:"可用"，并不是指软件的所有功能都没有问题，而是指在目前的用户场景中，按照场景的要求进行操作，都能得到预期的效果。注意以下两种情况:
1.在目前还没有定义的用户场景中，程序质量如何，还不得而知。例如:场景中没有考虑到多种语言设置。
2.对不按照场景的要求进行的操作，结果如何，还不得而知。例如:在某一场景中，场景规定用户可以在最后付款前取消操作，回到上一步，如果一个测试人员发现在多次反复提交/取消同一访问后，网页出现问题，但这并不能说明用户场景失败，当然，对于这个极端的Bug，也必须找出原因并适时修正。
这种测试有时也称为验收测试(Acceptance Test)，因为如果构建通过了这样的测试，这一个构建就被测试团队"接受了"。同时，还有对系统各个方面进行的"验收"测试，如系统的全球化验收测试，或者针对某一语言环境、某一个平台做的验收测试。