软件比人可靠——错误管理软件TestDirector

最近在公司进行项目的第一轮测试，感觉公司的这个bug管理做的很不错，在平台上跑了几天之后，觉得有必要分享给大家，在这里，我仅仅是个解说员，带领大家先认识这个老朋友！

简介：

TestDirector 是业界第一个基于Web的测试管理系统,它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。 

　　电子商务正影响着许多公司制定计划和建立自己的IT系统。很快，一个Web应用软件就能被创建，开发并立即展现在您的客户、供应商或合作伙伴的面前。然而，由于紧凑的开发计划和复杂的系统基构，Web应用软件的测试经常是被忽视的。为了与新经济同步， 您必须开发经过系统测试的高品质的网络应用软件。

　　您需要设立一个中央点来管理测试过程。一套基于Web的测试管理系统提供了一个协同合作的环境和一个中央数据仓库。由于测试人员分布在各地，您需要一个集中的测试管理系统能让测试人员不管在何时何地都能参与整个测试过程。IT部门增长地会非常快，人员也会不断流动。您必须以最快的速度培训新的测试人员，教会他们所有与测试有关的知识技术。重点在于管理复杂的开发和测试过程，改善部门间的沟通，加速您测试的成功。 

　　TestDirector能消除组织机构间、地域间的障碍。它能让测试人员、开发人员或其它的IT人员通过一个中央数据仓库，在不同地方就能交互测试信息。TestDirector将测试过程流水化——从测试需求管理，到测试计划，测试日程安排，测试执行到出错后的错误跟踪——仅在一个基于浏览器的应用中便可完成，而不需要每个客户端都安装一套客户端程序。

分类：

　　需求管理 

　　程序的需求驱动整个测试过程。TestDirector 的Web 界面简化了这些需求管理过程，以此您可以验证应用软件的每一个特性或功能是否正常。通过提供一个比较直观的机制将需求和测试用例、测试结果和报告的错误联系起来，从而确保能达到最高的测试覆盖率。

　　一般有2 种方式可将需求和测试联系起来。其一，TestDirector 捕获并跟踪所有首次发生的的应用需求。您可以在这些需求基础上生成一份测试计划，并将测试计划(?)对应与您的需求。例如，您或许有25 个测试计划(?)可对应同一个应用需求。您一定能方便地管理需求和测试计划(?)之间可能存在的一种多配多的关系，确保每一个需求都经过测试。其二，由于Web 应用是不断更新和变化的，需求管理允许测试人员加减或修改需求，并确定目前的应用需求已拥有了一定的测试覆盖率。它们帮助决定一个应用软件的哪些部分需要测试，哪些测试需要开发，是否完成的应用软件满足了用户的要求。对于任何动态地改变Web 应用，必须审阅您的测试计划是否准确，确保其符合最当前的应用要求。 

　　计划测试

　　测试计划的制定是测试过程中至关重要的环节。它为整个测试提供了一个结构框架。TestDirector的Test Plan Manager 在测试计划期尖，为测试小组提供一个关键要点和Web 界面来协调团队间的沟通。 

　　Test Plan Manager 指导测试人员如何将应用需求转化为具体的测试计划。这种直观的结构能帮助您定义如何测试您的应用软件，从而您能组织起明确的任务和责任。Test Plan Manager提供了多种方式来建立完整的测试计划。您可以从草图上建立一份计划，或根据您用Require-ments Manager所定义下的应用需求，通过Test Plan Wizard 快捷地生成一份测试计划。如果您已经将计划信息以文字处理文件形式，如Microsoft Word 方式储存，您可以再利用这些信息，并将它导入到Test Plan Manager。它把各种类型的测试汇总在一个可折叠式目录树内，您可以在一个目录下查询到所有的测试计划(?)。例如，你可以将人工和自动测试，如功能性的，还原和负载测试方案结合在同一位置。 

　　Test Plan Manager 还能进一步的帮助您完善测试设计和以文件形式描述每一个测试步骤，包括对每一项测试，用户反应的顺序，检查点和预期的结果TestDirector 还能为每一项测试连加附属文件，如Word ，Excel ，HTML ，用于更详尽的记录每次测试计划。

　　Web 网络应用日新月异，您的应用需求也随之不断改变。您需要相应地更新您的测试计划，优化测试内容。即使频繁的更新，TestDirector 仍能简单地将应用需求与相关的测试对应起来。TestDirector 还可支持不同的测试方式来适应您公司特殊的测试流程。

　　多数的测试项目需要一个有人工与自动测试的结合，包括健全，还原和系统测试。但即使符合自动测试要求的工具，在大部分情况下也需要人工的操作。启用一个演变性的而非革新性的自动化切换机制，能让测试人员决定哪些重复的人工测试可转变为自动脚本以提高测试速度。

总结：

        通过半个月的使用，发现，软件的确比人可靠，而且更有意义的事情是，我们看人有了更多元化的一面，以前我们看人的能力，看他的知识积累，看他面试的临场表现，看他的工作经验，那么有了TD之后我们可以从另一个角度看问题，一个系统，平均这个人被踢了几次BUG，每个BUG被驳回的次数，以及修改bug的间歇时间，通过这些，我们既掌握了人编码技术程度的一个方面也方便我们对系统做一个预期的评估，通过代码行和bug数目的对比知道整个系统的出错率，通过这样那样一组组的数据，让我们的团队更可靠，让系统更健壮！