判定表驱动分析方法

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

　　条件桩（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键相互切换。

　　只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。

　　3．对测试脚本除错（debug）

　　在WinRunner中有专门一个Debug TOOlbar用于测试脚本除错。可以使用step、pause、breakpoint等来控制和跟踪测试脚本和查看各种变量值。

　　4．在新版应用程序执行测试脚本

　　当应用程序有新版本发布时，我们会对应用程序的各种功能包括新增功能进行测试，这时当然不可能再来重新录制和编写所有的测试脚本。我们可以使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工作。可以使用一个call命令来加载各测试脚本。还可在call命令中加各种TSL脚本来增加批量能力。

　　5．分析测试结果

　　分析测试结果在整个测试过程中最重要，通过分析可以发现应用程序的各种功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中我们能发现应用程序的功能性缺陷，能看到实际结果和期望结果之间的差异，以及在测试过程中产生的各类对话框等。

　　6．回报缺陷（defect）

　　在分析完测试报告后，按照测试流程要回报应用程序的各种缺陷，然后将这些缺陷发给指定人，以便进行修改和维护。

　　常用的功能测试方法

　　功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：

　　1、页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

　　2、相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

　　3、检查按钮的功能是否正确：如update， cancel， delete， SAve等功能是否正确。

　　4、字符串长度检查： 输入超出需求所说明的字符串长度的内容， 看系统是否检查字符串长度，会不会出错。

　　5、字符类型检查： 在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型），看系统是否检查字符类型，会否报错。

　　6、标点符号检查： 输入内容包括各种标点符号，特别是空格，各种引号，回车键。看系统处理是否正确。

　　7、中文字符处理： 在可以输入中文的系统输入中文，看会否出现乱码或出错。

　　8、检查带出信息的完整性： 在查看信息和update信息时，查看所填写的信息是不是全部带出。，带出信息和添加的是否一致

　　9、信息重复： 在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理。

　　10、检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按”delete”，看系统如何处理，会否出错；然后选择一个和多个信息，进行删除，看是否正确处理。

　　11、检查添加和修改是否一致： 检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型。

　　12、检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理，报错。同时，也要注意，会不会报和自己重名的错。

　　13、重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

　　14、检查多次使用back键的情况： 在有back的地方，back，回到原来页面，再back，重复多次，看会否出错。

　　15、search检查： 在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确。如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确。

　　16、输入信息位置： 注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。

　　17、上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

　　18、必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

　　19、快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

　　20、回车键检查： 在输入结束后直接按回车键，看系统处理如何，会否报错。