论文部分内容阅读
在第38期的专栏中，我们曾介绍过如何使用美科利?穴Mercury?雪质量中心产品——美科利TestDirector来实现全球测试管理。在本文中，我们将进一步和大家分享使用美科利TestDirector来改进软件缺陷汇报和解决流程的独到见解和宝贵经验，其中包括使用TestDirector来支持各类大型项目、支持流程的建立和管理，以及如何便捷地改变和维护流程。
当手动流程面临挑战
这是美国一家有着数十亿资产的大型金融机构，他们的QA团队正为公司的最新应用——自动化外汇交易系统——创建和运行一套复杂的缺陷跟踪和解决流程。在此之前，公司财政经理只能用电话来控制货币交易。有了该项系统，经纪人就可以通过电子手段，进行实时的货币交易。
由于要用电子手段来模拟一个手动流程，该团队认为可以通过研究手动系统来收集主要的需求。通过对经纪人的采访，查看交易者实际交易过程的录像，以及数个月来频繁召开“需求收集”会议，整体的业务需求情况逐渐形成。该系统必须做到精益求精，因为每个小失误都可能造成交易混乱，并引起上亿美元的损失。当时，质量目标还不十分明确，因为他们没有现成的电子系统作为参照，目标制定缺乏一定的基础。因此，项目小组成员间默契的交流是该项目成功的关键。由于该项目涉及的人员遍及全球，且测试需要24小时不间断地执行，项目复杂程度可想而知。面对艰巨的任务，IT小组仍不断努力，期望能将开发环节中使用的手动流程实现自动化，以实现项目的既定目标。小组当时需要一种方法，可以让小组成员间就问题、缺陷、解决方案、项目进度，以及跟踪情况等内容进行顺畅地交流和沟通。他们也需要一种系统，它不仅需要具备高度的可靠性，还可以方便地进行客户定制，且能为遍及全球的用户提供支持功能。该系统必须操作便捷，使那些习惯进行手动流程操作的用户也能习惯使用这种自动化方案。
美科利（Mercury）TestDirector：所有测试流程的基准
美科利TestDirector是一款在各个领域都能发挥强大功能的产品——特别是在跟踪问题和差异、管理缺陷解决流程等方面表现得尤为出色。小组在项目伊始使用了其他的一些自动化工具，但是却经历了数次的失败。随后，他们发现了美科利的解决方案。该金融机构的QA部门于是决定采用美科利的TestDirector来作为所有测试流程的基准。他们发现，TestDirector具备他们所需要的所有特性：
高度的可用性：美科利TestDirector不会崩溃。
优异的性能：响应快，足以应对来自亚洲、欧洲和澳大利亚的用户需求。
实用性：能便捷地根据用户需要进行客户化定制并使用。
由于小组对美科利WinRunner 工具有着良好的使用经验，因此采用美科利TestDirector来管理所有的功能和回归测试就成为一件自然而然、水到渠成的事。公司使用TestDirector来打造所有关于缺陷解决和进度安排的流程。他们把和应用有关的所有事件都在TestDirector中进行定义——公司的所有应用都被列为“项目”。货币交易项目的完成历时三年，取得了卓越的成果。
客户定制的软件质量缺陷汇报和解决流程
只有展开全面彻底地规划，才能让缺陷汇报和解决流程提供有价值的信息，使IT流程合理化。以下部分所描述的步骤是在创建汇报流程、定义缺陷安全等级、记录缺陷状态和跟踪所有修改的过程中会被采用的一些步骤(如上图)。
缺陷汇报
在SDLC中未被发现的所有和项目有关的差异及问题都将汇报到美科利TestDirector中。当在TestDirector中开放了一个缺陷问题，以下过程将随之跟上：
1.发布小组成员一旦收集到了足够的信息来重建或解释该情况，就会及时地在美科利TestDirector中登录一份缺陷报告。
2.根据该缺陷对应用和/或测试流程本身造成的影响，界定其安全性等级。
3.通过具有一定标准的缺陷描述，确保涵盖该缺陷的所有相关信息。
4.通过任务指派明确指出谁将负责展开最初的调查。在这一环节上，缺陷将指派给来自开发、环境支持、业务主管或产品经理等各方面的适当的团队主管。
5.如果发现差异的人员不是发布小组成员，该差异的具体信息将转交给测试主管，以便登录到美科利TestDirector中。
缺陷解决会议
召开缺陷解决会议能确保所有的缺陷都能涉及并得到有效解决。这种定期会议由来自开发、项目管理、产品管理、和项目相关的业务团队代表及测试主管共同参加，就缺陷问题展开讨论。
测试主管在会议期间对美科利TestDirector进行信息更新，以便更有效地利用好会议时间。会议的中心议题是对缺陷报告进行审核。TestDirector中有完备的报告，包含所有的缺陷信息，便于会议划分缺陷的透明度、严重程度，并分配给相应的人员。缺陷报告的筛选可依据其严重程度和状态情况，这样影响度高的和新生成的缺陷可以最先得到处理。
缺陷修复
缺陷解决会议后，缺陷将被分配给合适的小组主管，以便着手解决。如果该缺陷问题和需求有关，那么这个缺陷会被指派给业务团队；如果对缺陷的代码错误有怀疑的话，该缺陷将被指派给开发主管；如果缺陷存在配置和结构上的问题，则会被指派给环境支持团队解决。
重复测试缺陷
被修复缺陷如果在环境缺陷中没有代码变更，将马上展开重复测试，并立即关闭。需要代码变更的缺陷修复会涵盖在一个版本打包中，从而展开重复测试，接着将根据测试结果或者关闭缺陷，或者将缺陷重新开放。这类信息在美科利TestDirector中可以得到有效的传递。
缺陷状态定义
每个缺陷都有一个状态显示，会在整个测试周期中得到随时地更新。每次当缺陷状态有了更新，评论信息就会加入到缺陷的R
当手动流程面临挑战
这是美国一家有着数十亿资产的大型金融机构，他们的QA团队正为公司的最新应用——自动化外汇交易系统——创建和运行一套复杂的缺陷跟踪和解决流程。在此之前，公司财政经理只能用电话来控制货币交易。有了该项系统，经纪人就可以通过电子手段，进行实时的货币交易。
由于要用电子手段来模拟一个手动流程，该团队认为可以通过研究手动系统来收集主要的需求。通过对经纪人的采访，查看交易者实际交易过程的录像，以及数个月来频繁召开“需求收集”会议，整体的业务需求情况逐渐形成。该系统必须做到精益求精，因为每个小失误都可能造成交易混乱，并引起上亿美元的损失。当时，质量目标还不十分明确，因为他们没有现成的电子系统作为参照，目标制定缺乏一定的基础。因此，项目小组成员间默契的交流是该项目成功的关键。由于该项目涉及的人员遍及全球，且测试需要24小时不间断地执行，项目复杂程度可想而知。面对艰巨的任务，IT小组仍不断努力，期望能将开发环节中使用的手动流程实现自动化，以实现项目的既定目标。小组当时需要一种方法，可以让小组成员间就问题、缺陷、解决方案、项目进度，以及跟踪情况等内容进行顺畅地交流和沟通。他们也需要一种系统，它不仅需要具备高度的可靠性，还可以方便地进行客户定制，且能为遍及全球的用户提供支持功能。该系统必须操作便捷，使那些习惯进行手动流程操作的用户也能习惯使用这种自动化方案。
美科利（Mercury）TestDirector：所有测试流程的基准
美科利TestDirector是一款在各个领域都能发挥强大功能的产品——特别是在跟踪问题和差异、管理缺陷解决流程等方面表现得尤为出色。小组在项目伊始使用了其他的一些自动化工具，但是却经历了数次的失败。随后，他们发现了美科利的解决方案。该金融机构的QA部门于是决定采用美科利的TestDirector来作为所有测试流程的基准。他们发现，TestDirector具备他们所需要的所有特性：
高度的可用性：美科利TestDirector不会崩溃。
优异的性能：响应快，足以应对来自亚洲、欧洲和澳大利亚的用户需求。
实用性：能便捷地根据用户需要进行客户化定制并使用。
由于小组对美科利WinRunner 工具有着良好的使用经验，因此采用美科利TestDirector来管理所有的功能和回归测试就成为一件自然而然、水到渠成的事。公司使用TestDirector来打造所有关于缺陷解决和进度安排的流程。他们把和应用有关的所有事件都在TestDirector中进行定义——公司的所有应用都被列为“项目”。货币交易项目的完成历时三年，取得了卓越的成果。
客户定制的软件质量缺陷汇报和解决流程
只有展开全面彻底地规划，才能让缺陷汇报和解决流程提供有价值的信息，使IT流程合理化。以下部分所描述的步骤是在创建汇报流程、定义缺陷安全等级、记录缺陷状态和跟踪所有修改的过程中会被采用的一些步骤(如上图)。
缺陷汇报
在SDLC中未被发现的所有和项目有关的差异及问题都将汇报到美科利TestDirector中。当在TestDirector中开放了一个缺陷问题，以下过程将随之跟上：
1.发布小组成员一旦收集到了足够的信息来重建或解释该情况，就会及时地在美科利TestDirector中登录一份缺陷报告。
2.根据该缺陷对应用和/或测试流程本身造成的影响，界定其安全性等级。
3.通过具有一定标准的缺陷描述，确保涵盖该缺陷的所有相关信息。
4.通过任务指派明确指出谁将负责展开最初的调查。在这一环节上，缺陷将指派给来自开发、环境支持、业务主管或产品经理等各方面的适当的团队主管。
5.如果发现差异的人员不是发布小组成员，该差异的具体信息将转交给测试主管，以便登录到美科利TestDirector中。
缺陷解决会议
召开缺陷解决会议能确保所有的缺陷都能涉及并得到有效解决。这种定期会议由来自开发、项目管理、产品管理、和项目相关的业务团队代表及测试主管共同参加，就缺陷问题展开讨论。
测试主管在会议期间对美科利TestDirector进行信息更新，以便更有效地利用好会议时间。会议的中心议题是对缺陷报告进行审核。TestDirector中有完备的报告，包含所有的缺陷信息，便于会议划分缺陷的透明度、严重程度，并分配给相应的人员。缺陷报告的筛选可依据其严重程度和状态情况，这样影响度高的和新生成的缺陷可以最先得到处理。
缺陷修复
缺陷解决会议后，缺陷将被分配给合适的小组主管，以便着手解决。如果该缺陷问题和需求有关，那么这个缺陷会被指派给业务团队；如果对缺陷的代码错误有怀疑的话，该缺陷将被指派给开发主管；如果缺陷存在配置和结构上的问题，则会被指派给环境支持团队解决。
重复测试缺陷
被修复缺陷如果在环境缺陷中没有代码变更，将马上展开重复测试，并立即关闭。需要代码变更的缺陷修复会涵盖在一个版本打包中，从而展开重复测试，接着将根据测试结果或者关闭缺陷，或者将缺陷重新开放。这类信息在美科利TestDirector中可以得到有效的传递。
缺陷状态定义
每个缺陷都有一个状态显示，会在整个测试周期中得到随时地更新。每次当缺陷状态有了更新，评论信息就会加入到缺陷的R