软件测试和VSTS 软件测试工具的使用

发布: 2009-4-03 12:18 | 作者: 网络转载 | 来源: 测试时代采编 | 查看: 103次 | 进入软件测试论坛讨论

1.6 功能测试（functional test）

测试团队拿到一个“可测”等级的构建，他们就会按照测试计划，测试各自负责的模块和功能，这个过程可能会产生总共10来个bug，也可能产生100个以上的bug，那么如何保证我们有效地测试了软件，同时我们在这一步怎样衡量构建的质量？

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

在“基本场景”的基础上，我们把所有系统目前理论上支持的场景都列出来，然后按功能分类测试，如果测试成功，就在此场景中标明“成功”，否则，就标明“失败”，并且把失败的情况用一个（或几个）“小强”/bug来表示。

当所有的测试人员完成对场景的测试，我们自然地就得出了一个表：

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

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

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

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

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

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

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

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

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

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

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

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

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

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