论文部分内容阅读
一个Web应用的新搜索功能的模块细化样本通过查看活动图表，QA分析人员可以初步了解需要多少个测试案例组合才能全面测试一个子模块。
在上期栏目中我们给大家介绍了应对挑战的新方法，本期我们将详细介绍UML图表和美科利质量中心的详细解决方案，并对WeightWatchers.com公司在UML和美科利质量中心集成中所获的体验和结果进行陈述。
WeightWatchers.com使用UML活动图表和美科利质量中心的详细步骤如下：
1.确认模块：小组首先应该对系统进行分析，把系统细化成逻辑分类、模块和子模块。子模块应该是一些小型的、可管理的组成部分，可以便捷地添加入活动图表中。每个子模块都分配有一个特定ID。
2.描绘活动图表：使用Visio，为每个子模块创建一个详细的UML活动图表。每个活动图表显示用户和系统的系列行为，如“用户做了x”，接下来“系统做了y”，并且显示各类判断点。由于在美科利质量中心里创建和维护测试案例(TC)和测试包(TS)所依照的主要文档是活动图表，因此在任何数据输入到美科利质量中心之前，必须确保活动图表的正确性和完整性。接着围绕每个逻辑测试案例画一个虚线框，并标以TC01、TC02、TC03，依此类推。这些测试案例为步骤4中的测试包(测试场景)提供构建模块。
在活动图表中定义的测试案例和在美科利质量中心的TestDirector中创建的测试案例之间存在一对一的对等关系。为了避免错误，需要将Visio活动图表中的内容复制和粘贴到美科利质量中心内。在活动图表中，每个测试案例可以由若干验证点所组成。在美科利质量中心内，每个验证点都以独立的测试步骤输入，从而确保通过/失败可以互为分离。
3.输入测试案例：一旦在活动图表中确定了测试案例，就在美科利质量中心的测试计划树型图中为每个测试案例创建节点。这些测试案例节点应该显示在他们各自的子模块节点下。接着通过复制和粘贴活动图表中的内容，为每个测试案例输入测试步骤。
4.集合测试案例，形成测试包：在美科利质量中心的测试实验室树型图中，为每个处于相应模块节点下的测试包创建节点。一个测试包—或测试场景由两个或多个测试案例所组成，他们被联系在一起用于测试某个子模块的特定区域。通过查看活动图表，QA分析人员可以初步了解需要多少个测试案例组合才能全面测试一个子模块。
例如，如果图表显示TC01紧随其后是TC02，接着分叉至TC03、TC04和TC05，那么分析人员将要创建一个数据包，把TC01、TC02和TC03联系在一起，另外一个数据包把TC01、TC02和TC04联系起来，依此类推。这种测试包创建过程要涵盖所有的合理组合。通过这种方式，才能用测试案例库开发足够多的测试场景，从而确保全面、有效和系统的展开测试。
5.为测试包安装数据文件：在每个测试包中，有些测试案例可能需要数据文件，如用户输入的或系统检测的数据值。根据要求将这些值输入美科利质量中心的测试实验室。
6.执行测试包：无论从Execution Grid tab，还是从Execution Flow tab中，点击“运行”按钮来执行整个测试包或者单单执行测试包中的某些测试案例。在每个测试案例实现自动化之前，WeightWatchers.com建议使用美科利TestDirector，对每个测试案例至少执行一次成功的手动测试。
7.为每个测试案例编写自动化脚本：一旦测试案例至少经历了一次手动运行，就要为测试案例创建一个自动化脚本。由介于测试案例层面上的美科利TestDirector来生成自动化脚本。WeightWatchers.com使用了美科利QuickTest Professional。当然，任何美科利TestDirector支持的自动化工具都可以被使用。
由于创建各种测试包组合需要多次使用测试案例，每个测试案例和自动化测试脚本都是可重复使用的组件。这样不仅理顺了测试包的开发过程，也提高了维护工作的效率。对测试案例所作的任何变更都会自动反映在使用该测试案例的所有测试包中，从而避免了在多个方位更新相同的信息。
美科利TestDirector架构的客户定制
WeightWatchers.com实施了美科利TestDirector的客户定制，下面是变更的详细过程：
测试包的创建和脚本的选择
WeightWatchers.com 测试包的结构如下所示 ：
Initialize Environment
Test Script Instance_1
Test Script Instance_2
Test Script Instance_N
InitializeEnvironment是一种特殊的脚本，用于处理测试包执行时的所有初始化需求。使用脚本的确切方位由设定在美科利QuickTest Professional中的执行参数决定。当创建测试包、并且还没有相关测试数据时，使用美科利TestDirector OTA APIs可以自动将脚本加入测试包。
测试包创建完成后，测试人员可以根据需要添加测试案例。在添加每个测试案例时，用已经编写的工作流代码来验证该测试案例是手动的还是自动的。如果是自动测试案例，就执行工作流代码，确定在测试包中加入什么测试。工作流代码还能连接自动化脚本所在的美科利TestDirector服务器，并将默认数据表格附加到测试实例中(test instance)。默认数据表格确定某个特定测试需要执行哪些条目，但是它不包含任何测试数据。
在脚本开发的同时，文档定义也完成了。在默认数据表格附加到测试实验室中的测试实例上时，用户可以打开该文档，为该测试实例添加所需的任何测试数据。这样，该机构可以增加既简单又灵活的框架——每个测试包将拥有多个测试脚本实例，但是这些实例可以单独执行，给出独立的测试数据。当测试人员增加数据包，并且添加测试数据时，可以使用美科利TestDirector中的附件数据表格，输入数据，保存文件，并再次上传。如果增加的是手动测试，以上这些步骤都不需要。
测试实例
测试包中其它所有的脚本都是测试案例的实例，可以分成四个部分：
初始化和预处理
由于WeightWatchers.com是一家大型网站，业务遍及多个国家，需要通过一种方法来创建一套可以让位于不同国家的小组成员都能使用的脚本。由于美科利QuickTest Professional中的内置数据库检查不允许联结字符串的参数化，WeightWatchers.com无法实现在多个方位展开数据库验证任务。但是，公司通过内置的对象存储库(object repository)，在用户端界面上实现了这个目标。
小组通过在使用ADO的VBScript中创建定制等级，以及通过使用测试包中的用户定义域来说明联结字符串的组件，很好地解决了这个问题。小组将它们作为其全球变量，因为美科利QuickTest Professional不允许跨脚本实例的全球变量。这些用户定义域是DatabaseChecks、DBDataSource、DBSchemaName、DBPassword和Country。 在执行测试包中的测试实例时，首要任务就是调用内部库中的一个功能，将这些变量值读入OTA中，并存储在Dictionary object中。小组就可以给这些全球变量加上可读的注释(如：GlobalVariables.Item (“DatabaseChecks”))。该阶段还有一个任务就是导出附件数据表格，当该特定测试案例的测试数据在美科利QuickTest Professional中上传并在测试中使用后，就可以导出数据表格。
测试脚本主体
在该测试阶段执行测试步骤。
后端数据库验证
脚本的这个阶段中，执行所有需要的数据库验证。在测试脚本初始化和预处理阶段所读入的记号和联结字符串组件都在该阶段被使用。此外，测试检查DatabaseChecks定义域是否被设定成“TRUE”。如果是的话，就知道存在需要执行的数据库检查任务。接着，测试可以例示数据库等级，从数据表格中读入预期的结果，并验证这些值。所有这些在数据库等级中都被定义成可重复使用的方法。
整理和后期处理
测试已执行完成，在对测试包中的下一个测试实例进行测试之前，应该对前一测试进行整理。WeightWatchers.com需要一种方法来巡视AUT中的适当方位，因此小组在内部库中创建了一个功能，使用美科利TestDirector OTA API’s来观测数据包中下一数据实例的名称。测试名称的前三位字母决定了测试人员应该巡视的具体方位。如果下一个测试案例名称的前三位字母和当前的不一样，那就执行代码将AUT移入合适的方位。如果相同的话，无需进行任何操纵，因为在用户界面的正确方位上测试已经展开了。
总结：业务案例成果
WeightWatchers.com开发小组通过采用了UML方式——由美科利质量中心提供支持，从需求阶段直至部署阶段，更好地定义、衡量、管理和提升应用的质量，在降低质量风险的同时，缩短了应用的上市时间。
由于实施了UML活动图表和美科利质量中心，WeightWatchers.com能够在QA阶段前发现更多的缺陷，极大地降低了后期发布的数量，在投入生产环境之前修复问题。开发小组可以从容的展开更为全面的QA测试，实现更高的服务水平。这些优势使企业在QA阶段之前定位缺陷，降低了成本。同时也缩短开发周期时间，为企业获取更具竞争力的ROI。不仅如此，他们还提高整体应用发布的质量，统一了网站的风格。
在上期栏目中我们给大家介绍了应对挑战的新方法，本期我们将详细介绍UML图表和美科利质量中心的详细解决方案，并对WeightWatchers.com公司在UML和美科利质量中心集成中所获的体验和结果进行陈述。
WeightWatchers.com使用UML活动图表和美科利质量中心的详细步骤如下：
1.确认模块：小组首先应该对系统进行分析，把系统细化成逻辑分类、模块和子模块。子模块应该是一些小型的、可管理的组成部分，可以便捷地添加入活动图表中。每个子模块都分配有一个特定ID。
2.描绘活动图表：使用Visio，为每个子模块创建一个详细的UML活动图表。每个活动图表显示用户和系统的系列行为，如“用户做了x”，接下来“系统做了y”，并且显示各类判断点。由于在美科利质量中心里创建和维护测试案例(TC)和测试包(TS)所依照的主要文档是活动图表，因此在任何数据输入到美科利质量中心之前，必须确保活动图表的正确性和完整性。接着围绕每个逻辑测试案例画一个虚线框，并标以TC01、TC02、TC03，依此类推。这些测试案例为步骤4中的测试包(测试场景)提供构建模块。
在活动图表中定义的测试案例和在美科利质量中心的TestDirector中创建的测试案例之间存在一对一的对等关系。为了避免错误，需要将Visio活动图表中的内容复制和粘贴到美科利质量中心内。在活动图表中，每个测试案例可以由若干验证点所组成。在美科利质量中心内，每个验证点都以独立的测试步骤输入，从而确保通过/失败可以互为分离。
3.输入测试案例：一旦在活动图表中确定了测试案例，就在美科利质量中心的测试计划树型图中为每个测试案例创建节点。这些测试案例节点应该显示在他们各自的子模块节点下。接着通过复制和粘贴活动图表中的内容，为每个测试案例输入测试步骤。
4.集合测试案例，形成测试包：在美科利质量中心的测试实验室树型图中，为每个处于相应模块节点下的测试包创建节点。一个测试包—或测试场景由两个或多个测试案例所组成，他们被联系在一起用于测试某个子模块的特定区域。通过查看活动图表，QA分析人员可以初步了解需要多少个测试案例组合才能全面测试一个子模块。
例如，如果图表显示TC01紧随其后是TC02，接着分叉至TC03、TC04和TC05，那么分析人员将要创建一个数据包，把TC01、TC02和TC03联系在一起，另外一个数据包把TC01、TC02和TC04联系起来，依此类推。这种测试包创建过程要涵盖所有的合理组合。通过这种方式，才能用测试案例库开发足够多的测试场景，从而确保全面、有效和系统的展开测试。
5.为测试包安装数据文件：在每个测试包中，有些测试案例可能需要数据文件，如用户输入的或系统检测的数据值。根据要求将这些值输入美科利质量中心的测试实验室。
6.执行测试包：无论从Execution Grid tab，还是从Execution Flow tab中，点击“运行”按钮来执行整个测试包或者单单执行测试包中的某些测试案例。在每个测试案例实现自动化之前，WeightWatchers.com建议使用美科利TestDirector，对每个测试案例至少执行一次成功的手动测试。
7.为每个测试案例编写自动化脚本：一旦测试案例至少经历了一次手动运行，就要为测试案例创建一个自动化脚本。由介于测试案例层面上的美科利TestDirector来生成自动化脚本。WeightWatchers.com使用了美科利QuickTest Professional。当然，任何美科利TestDirector支持的自动化工具都可以被使用。
由于创建各种测试包组合需要多次使用测试案例，每个测试案例和自动化测试脚本都是可重复使用的组件。这样不仅理顺了测试包的开发过程，也提高了维护工作的效率。对测试案例所作的任何变更都会自动反映在使用该测试案例的所有测试包中，从而避免了在多个方位更新相同的信息。
美科利TestDirector架构的客户定制
WeightWatchers.com实施了美科利TestDirector的客户定制，下面是变更的详细过程：
测试包的创建和脚本的选择
WeightWatchers.com 测试包的结构如下所示 ：
Initialize Environment
Test Script Instance_1
Test Script Instance_2
Test Script Instance_N
InitializeEnvironment是一种特殊的脚本，用于处理测试包执行时的所有初始化需求。使用脚本的确切方位由设定在美科利QuickTest Professional中的执行参数决定。当创建测试包、并且还没有相关测试数据时，使用美科利TestDirector OTA APIs可以自动将脚本加入测试包。
测试包创建完成后，测试人员可以根据需要添加测试案例。在添加每个测试案例时，用已经编写的工作流代码来验证该测试案例是手动的还是自动的。如果是自动测试案例，就执行工作流代码，确定在测试包中加入什么测试。工作流代码还能连接自动化脚本所在的美科利TestDirector服务器，并将默认数据表格附加到测试实例中(test instance)。默认数据表格确定某个特定测试需要执行哪些条目，但是它不包含任何测试数据。
在脚本开发的同时，文档定义也完成了。在默认数据表格附加到测试实验室中的测试实例上时，用户可以打开该文档，为该测试实例添加所需的任何测试数据。这样，该机构可以增加既简单又灵活的框架——每个测试包将拥有多个测试脚本实例，但是这些实例可以单独执行，给出独立的测试数据。当测试人员增加数据包，并且添加测试数据时，可以使用美科利TestDirector中的附件数据表格，输入数据，保存文件，并再次上传。如果增加的是手动测试，以上这些步骤都不需要。
测试实例
测试包中其它所有的脚本都是测试案例的实例，可以分成四个部分：
初始化和预处理
由于WeightWatchers.com是一家大型网站，业务遍及多个国家，需要通过一种方法来创建一套可以让位于不同国家的小组成员都能使用的脚本。由于美科利QuickTest Professional中的内置数据库检查不允许联结字符串的参数化，WeightWatchers.com无法实现在多个方位展开数据库验证任务。但是，公司通过内置的对象存储库(object repository)，在用户端界面上实现了这个目标。
小组通过在使用ADO的VBScript中创建定制等级，以及通过使用测试包中的用户定义域来说明联结字符串的组件，很好地解决了这个问题。小组将它们作为其全球变量，因为美科利QuickTest Professional不允许跨脚本实例的全球变量。这些用户定义域是DatabaseChecks、DBDataSource、DBSchemaName、DBPassword和Country。 在执行测试包中的测试实例时，首要任务就是调用内部库中的一个功能，将这些变量值读入OTA中，并存储在Dictionary object中。小组就可以给这些全球变量加上可读的注释(如：GlobalVariables.Item (“DatabaseChecks”))。该阶段还有一个任务就是导出附件数据表格，当该特定测试案例的测试数据在美科利QuickTest Professional中上传并在测试中使用后，就可以导出数据表格。
测试脚本主体
在该测试阶段执行测试步骤。
后端数据库验证
脚本的这个阶段中，执行所有需要的数据库验证。在测试脚本初始化和预处理阶段所读入的记号和联结字符串组件都在该阶段被使用。此外，测试检查DatabaseChecks定义域是否被设定成“TRUE”。如果是的话，就知道存在需要执行的数据库检查任务。接着，测试可以例示数据库等级，从数据表格中读入预期的结果，并验证这些值。所有这些在数据库等级中都被定义成可重复使用的方法。
整理和后期处理
测试已执行完成，在对测试包中的下一个测试实例进行测试之前，应该对前一测试进行整理。WeightWatchers.com需要一种方法来巡视AUT中的适当方位，因此小组在内部库中创建了一个功能，使用美科利TestDirector OTA API’s来观测数据包中下一数据实例的名称。测试名称的前三位字母决定了测试人员应该巡视的具体方位。如果下一个测试案例名称的前三位字母和当前的不一样，那就执行代码将AUT移入合适的方位。如果相同的话，无需进行任何操纵，因为在用户界面的正确方位上测试已经展开了。
总结：业务案例成果
WeightWatchers.com开发小组通过采用了UML方式——由美科利质量中心提供支持，从需求阶段直至部署阶段，更好地定义、衡量、管理和提升应用的质量，在降低质量风险的同时，缩短了应用的上市时间。
由于实施了UML活动图表和美科利质量中心，WeightWatchers.com能够在QA阶段前发现更多的缺陷，极大地降低了后期发布的数量，在投入生产环境之前修复问题。开发小组可以从容的展开更为全面的QA测试，实现更高的服务水平。这些优势使企业在QA阶段之前定位缺陷，降低了成本。同时也缩短开发周期时间，为企业获取更具竞争力的ROI。不仅如此，他们还提高整体应用发布的质量，统一了网站的风格。