数据驱动测试(2)

　　因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

　　利用因果图生成测试用例的基本步骤:

　　(1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

　　(2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

　　(3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.

　　(4) 把因果图转换为判定表.

　　(5) 把判定表的每一列拿出来作为依据,设计测试用例.

　　从因果图生成的测试用例(局部,组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

　　前面因果图方法中已经用到了判定表.判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

　　判定表通常由四个部分组成.

　　条件桩(Condition Stub):列出了问题得所有条件.通常认为列出得条件的次序无关紧要.

　　动作桩(Action Stub):列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

　　条件项(Condition Entry):列出针对它左列条件的取值.在所有可能情况下的真假值.

　　动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作.

　　规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.

　　判定表的建立步骤:(根据软件规格说明)

　　①确定规则的个数.假如有n个条件.每个条件有两个取值(0,1),故有 种规则.

　　②列出所有的条件桩和动作桩.

　　③填入条件项.

　　④填入动作项.等到初始判定表.

　　⑤简化.合并相似规则(相同动作).

　　B. Beizer 指出了适合使用判定表设计测试用例的条件:

　　①规格说明以判定表形式给出,或很容易转换成判定表.

　　②条件的排列顺序不会也不影响执行哪些操作.

　　③规则的排列顺序不会也不影响执行哪些操作.

　　④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.

　　⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

　　黑盒测试的优点

　　1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了

　　2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因

　　黑盒测试的缺点

　　1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴

　　2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作

　　3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。

　　黑盒测试(功能测试)工具的选择

　　那么，如何高效地完成功能测试?选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。

　　目前，用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。

　　WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。

　　WinRunner的特点在于: 与传统的手工测试相比，它能快速、批量地完成功能点测试; 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差; 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成; 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用; 它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。

　　WinRunner的工作流程大致可以分为以下六个步骤:

　　1.识别应用程序的GUI

　　在WinRunner中，我们可以使用GUI Spy来识别各种GUI对象，识别后，WinRunner会将其存储到GUI Map File中。它提供两种GUI Map File模式: Global GUI Map File和GUI Map File per Test。其最大区别是后者对每个测试脚本产生一个GUI文件，它能自动建立、存储、加载，推荐初学者选用这种模式。但是，这种模式不易于描述对象的改变，其效率比较低，因此对于一个有经验的测试人员来说前者不失为一种更好的选择，它只产生一个共享的GUI文件，这使得测试脚本更容易维护，且效率更高。

　　2.建立测试脚本

　　在建立测试脚本时，一般先进行录制，然后在录制形成的脚本中手工加入需要的TSL(与C语言类似的测试脚本语言)。录制脚本有两种模式: Context Sensitive和Analog，选择依据主要在于是否对鼠标轨迹进行模拟，在需要回放时一般选用Analog。在录制过程中这两种模式可以通过F2键相互切换。

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