软件测试和VSTS 测试工具

发布: 2009-5-31 10:56 | 作者: 不详 | 来源: 测试时代采编 | 查看: 339次 | 进入软件测试论坛讨论

这样我们就能很快地报告“功能测试56%通过”等等。如果所有场景都能通过，（有些情况下可以把此标准从100%降低到90%左右）则这个构建的质量是“可用”，意味着这一个版本可以给用户使用。这种情况下，客户，合作伙伴可以得到这样的版本–这也是所谓“技术预览版”，或“社区预览版”的由来。

但是，有一个重要的问题要大家注意“可用”，并不是指软件都没有bug，而是指在目前的用户场景中，按照场景的要求进行的操作，都能得到预期的效果。

1．目前还没有定义的用户场景中，程序质量如何，还未得而知。

a. 场景中没有考虑到多种语言设置

2．不按照场景的要求进行的操作，结果如何，还未得而知。

a. 如：在某一场景中，场景规定用户可以在最后付款前取消操作，回到上一步，如果一个测试人员发现在反复提交/取消同一访问多次，然后网页出现问题，这并不能说明用户场景失败，当然这个极端的bug也必须找出原因并在适当的时间改正。

这种测试有时也被称为“acceptance test”,因为如果构建通过了这样的测试，这一个构建就被测试团队“接受了”。同时，还有对系统各个方面进行的“接收”测试，如测试系统的全球化，或者针对某一语言环境做的测试。

1.7 Ad hoc Test, Exploratory Test “探索式”的测试

“Ad Hoc”原意是指“特定的，一次性的”。

什么叫“特定”测试？或者“探索式”的测试？

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

比如：测试人员阿毛拿到了一个新的构建，按计划是进行模块A的功能测试，但是他灵机一动，想看看另一个功能B做得如何，或者想看看模块A在某种边界条件下会出现什么问题，于是他就“ad hoc”一把，居然在这一功能模块中发现了不少小强。

“ad hoc”也意味着测试是尝试性的，“我来试试，在这个对话框中一通乱按，然后随意改变窗口大小，看看会出什么问题…”，如果没问题，那么以后也不会再这么做了。

一般情况下，测试人员不会花很多时间进行特定测试，但是在一些缺乏管理的团队中，很多时候测试人员不知道自己此时应该做什么，只好做一些看似“ad hoc”的测试，比如随机测试各个功能的各个方面。这些测试理论上都应该由测试管理人员规划好属于各个功能模块的测试用例中。

在一个团队中，“ad hoc”太多是一个管理不好的标志，因为“ad hoc”是指那些一时想到要做，但是以后也没有计划经常重复的测试计划。

问：我听说有人是“ad hoc”测试的高手，这是什么意思？

答：有很多测试人员会按部就班地进行测试，但是还有一些人头脑比较灵活，喜欢另辟蹊径，测试一些一般人不会想到的场景，这些人往往会发现更多的小强。开发人员对这样的“ad hoc”高手是又爱又恨。