测试手段之探索性测试(7)

　　大家都喜欢在实践中看看效果，那么现在大家都理解了ET了，就很希望在一个项目过程中来实践ET，实践的具体流程是什么呢?需要考虑什么异常情况呢?接下来就说说ET实践的总体流程(这个流程是非常官方且标准的ET实践流程，曾由James Bach 写给微软做windows产品兼容性测试任务的官方证据)：

　　这个流程大体上包括3个部分：

　　—-Working with Functions

　　—-Testing Functionality and Stability

　　—-Test Procedure

　　这里面就说下前面2个大点：

　　1.1 Working with Functions

　　这个流程是围绕着功能来组织的。所谓功能就是一个软件所要假定要做的事情。这就包括任何显示的，改变内部或外部数据的，或影响环境的任何结果。当然功能一般都包含子功能。比如：在微软word里面”打印”功能就包含”复制几份”和”页面范围设置”2个子功能.

　　由于我们需要测试所有东西，就必须通过制定基本风险的决策来简单化哪些功能需要花费多少精力。我们把所有的功能分为2大类：主要的，贡献性的。大部分情况，我们需要记录和测试主要的功能。至于这些功能该怎么样的分类和组合是根据情况来定的。你也许会认为一组贡献性的功能可以作为一个单独的主要功能，或一个单独的主要的功能能够分解为主要的和贡献性的子功能。

　　如果可能的话，我们想去测试所有的主要功能，但可能没有足够的时间去做。这种情况，需要对你将测试的和不会测试的主要功能做一个文档的记录。

　　如果只看用户反映的话，就很难识别出一些功能。有些功能是与操作系统，其他程序，或修改文件进行直接交互，而这些在显示上并不能直接看到效果。需要重视那些重要的且有可能是部分隐藏的功能。

　　如下定义功能的分类的方式：

　　1.2 Testing Functionality and Stability

　　我们测试大部分是测试功能性和稳定性的问题，那我们就必须有通过测试的标准，如下是定义的标准：

　　Test Coverage

　　测试覆盖率就是将要测试什么?如下的测试覆盖率是需要的：

　　在时间允许下合理的测试所有的主要的功能。让lead知道有哪些主要的功能没有时间测试或没有能力测试?我们可以对一个有趣的贡献性的功能进行测试。也有可能在探索和测试主要功能时接触更多的贡献性的功能。

　　选择一些潜在的不稳定因素进行测试和选择一些有可能触发不稳定的功能的数据进行测试。一般情况下，选择5到10个。Lead会决定对于这个功能性和稳定性的测试需要多长时间，一般是花80%的时间在主要的功能上，10%在贡献性的功能上，10%在不稳定的方面。

　　Sources and Oracles

　　我们在做ET过程中，是怎么知道这个产品就是应该这样做的呢?我们是怎么知道它什么时候不该这样处理的呢?这里如果我们需要回答很好的话，并使得lead满意，必须考虑下面2个方面：

　　Sources：就是做ET过程中需要的信息的来源。有时是你自己的灵感或经验。但更多的是我们已经了解了相关的产品文档。而且大部分情况，我们需要经常与相关人员确认该产品的目的和功能。

　　Oracles：就是做ET过程中确定所看到的产品的行为是否正确的策略。也就是回答：你怎么知道它就是这样工作的?’

　　一般使用下面几个方式去确定Oracles(ET的过程分析里面也讲过):

原文转自：http://www.ltesting.net