软件测试

(1) 什么是软件测试

软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。

软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。模块的编写者与测试者是同一个人。编码与单元测试属于软件生存期中的同一个阶段。在这个阶段结束之后，对软件系统还要进行各种综合测试，这是软件生存期的另一个独立的阶段，即测试阶段，通常由专门的测试人员承担这项工作。

(2) 软件测试的目的和原则

Grenford J.Myers就软件测试目的提出以下观点：

 § 测试是程序的执行过程，目的在于发现错误；

 § 一个好的测试用例在于能发现至今未发现的错误；

 § 一个成功的测试是发现了至今未发现的错误的测试。

设计测试的目标是想以最少的时间和人力系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试，就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符合。此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。

测试不能表明软件中不存在错误，它只能说明软件中存在错误。

软件测试的原则：

① 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。

不应把软件测试仅仅看作是软件开发的一个独立阶段，而应当把它贯穿到软件开发的各个阶段中。坚持在软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把出现的错误克服在早期，杜绝某些发生错误的隐患。

② 测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。

测试以前应当根据测试的要求选择测试用例（Test case），用来检验程序员编制的程序，因此不但需要测试的输入数据，而且需要针对这些输入数据的预期输出结果。

③ 程序员应避免检查自己的程序。

程序员应尽可能避免测试自己编写的程序，程序开发小组也应尽可能避免测试本小组开发的程序。如果条件允许，最好建立独立的软件测试小组或测试机构。这点不能与程序的调试（debuging）相混淆。调试由程序员自己来做可能更有效。

④ 在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

合理的输入条件是指能验证程序正确的输入条件，不合理的输入条件是指异常的，临界的，可能引起问题异变的输入条件。软件系统处理非法命令的能力必须在测试时受到检验。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能发现更多的错误。

⑤ 充分注意测试中的群集现象。

在被测程序段中，若发现错误数目多，则残存错误数目也比较多。这种错误群集性现象，已为许多程序的测试实践所证实。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。

⑥ 严格执行测试计划，排除测试的随意性。

测试之前应仔细考虑测试的项目，对每一项测试做出周密的计划，包括被测程序的功能、输入和输出、测试内容、进度安排、资源要求、测试用例的选择、测试的控制方式和过程等，还要包括系统的组装方式、跟踪规程、调试规程，回归测试的规定，以及评价标准等。对于测试计划，要明确规定，不要随意解释。

⑦ 应当对每一个测试结果做全面检查。

有些错误的征兆在输出实测结果时已经明显地出现了，但是如果不仔细地全面地检查测试结果，就会使这些错误被遗漏掉。所以必须对预期的输出结果明确定义，对实测的结果仔细分析检查，抓住征侯，暴露错误。

⑧ 妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

(3) 确认和验证的关系

确认（Validation）是一系列的活动和过程，其目的是想证实在一个给定的外部环境中软件的逻辑正确性。它包括需求规格说明的确认和程序的确认，而程序的确认又分为静态确认与动态确认。静态确认一般不在计算机上实际执行程序，而是通过人工分析或者程序正确性证明来确认程序的正确性； 动态确认主要通过动态分析和程序测试来检查程序的执行状态，以确认程序是否有问题。

验证（Verification），则试图证明在软件生存期各个阶段，以及阶段间的逻辑协调性、完备性和正确性。

确认与验证工作都属于软件测试。在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节上发生了问题都可能在软件测试中表现出来。

(4) 测试信息流

测试信息流如图5.1所示。测试过程需要三类输入：

§ 软件配置：包括软件需求规格说明、软件设计规格说明、源代码等；

 § 测试配置：包括测试计划、测试用例、测试驱动程序等；

 § 测试工具：测试工具为测试的实施提供某种服务。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的工作台等。

测试之后，用实测结果与预期结果进行比较。如果发现出错的数据，就要进行调试。对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。修正后的文档一般都要经过再次测试，直到通过测试为止。

通过收集和分析测试结果数据，对软件建立可靠性模型。          

如果测试发现不了错误，那么可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。这些错误最终不得不由用户在使用中发现，并在维护时由开发者去改正。但那时改正错误的费用将比在开发阶段改正错误的费用要高出40倍到60倍。

(5) 测试与软件开发各阶段的关系

软件开发过程是一个自顶向下，逐步细化的过程，而测试过程则是依相反的顺序安排的 自底向上，逐步集成的过程。低一级测试为上一级测试准备条件。参看图5.2，首先对每一个程序模块进行单元测试，消除程序模块内部在逻辑上和功能上的错误和缺陷。再对照软件设计进行集成测试，检测和排除子系统（或系统）结构上的错误。随后再对照需求，进行确认测试。最后从系统全体出发，运行系统，看是否满足要求。

 软件测试相关术语定义集锦

{/ o  o /}   {/ .  . /}   {/ ︿︿ /}
 ( (oo) )     ( (oo) )     ( (oo) )
  ︶ ︶︶     ︶ ︶ ︶     ︶ ︶ ︶
  标准猪       小眼猪    眉开眼笑的猪
╭︿︿︿╮    ╭︿︿︿╮    ╭︿︿︿╮
{/ $  $ /}    {/ @  @ /}  {/-■■-/}
 ( (oo) )      ( (oo) )    ( (oo) )
 ︶ ︶ ︶       ︶︶︶      ︶︶︶
财迷心窍猪    头晕目眩猪    酷酷猪

╭︿︿︿╮   ╭︿︿︿╮     ╭︿︿︿╮
{/ O  O /}  {/ X  o /}   {/ ·· /}
 ( (qp) )    ( (oo) )     ( (OO）)
  ︶︶︶      ︶︶︶       ︶︶︶ 
  生气猪     独眼龙猪    张大鼻孔猪

╭︿︿︿╮    ╭︿︿︿╮    ╭︿︿︿╮
{/ #  # /}   {/-◎◎-/}  {/ -  - /}
 ( (oo) )     ( (oo) )    ( (..) )
  ︶︶︶       ︶︶︶      ︶︶︶ 
   茫然猪      戴眼镜猪  悠闲自在猪

╭︿︿︿╮    ╭︿︿︿╮      ╭︿︿︿╮
{/-●●-/}  {/-★★-/}    {/-⊙⊙-/}
 ( (oo) )    ( (oo) )      ( (oo) )
  ︶︶︶      ︶︶︶        ︶︶︶
  墨镜猪      时髦猪      目瞪口呆猪    
祝福所有的朋友们，元旦快乐、猪年快乐！

软件测试很有用，前景也很好，让我们一步一步，努力学习，一起做好软件测试。

我的古城热线Blog（软件测试）：
http://sunxy5291.blog.xaonline.com

欢迎评论，一起学习...

也可以直接进行交流：

qq：12585990

msn:sunxy5291@hotmail.com

昔日小小

我要打开51testingblog很慢，所以的日志都发布在我们的古城热线（www.xaonline.com）上，你们一定要来看看哦！

这里有好多好东东（关于软件测试的）：http://sunxy5291.blog.xaonline.com/

西安的朋友最好了，因为打开这个blog很快的.

对了，还有一个MSN Spaces，是记录我的生活的.

http://sunxy5291.spaces.live.com/

谢谢大家光临！！！

活着添加我，我们一起进步，本人联系方式：

QQ 12585990

MSN sunxy5291@hotmail.com

linux基本命令

--------------------------------------------------------------------------------
ls
这个命令就相当于dos下的dir命令一样

ls -a

Linux上的文件以.开头的文件被系统视为隐藏文件，仅用ls命令是看不到他们的，而用ls -a除了显示 一般文件名外，
连隐藏文件也会显示出来。

ls -l（这个参数是字母L的小写，不是数字1,这个命令最常用）

这个命令可以使用长格式显示文件内容，如果需要察看更详细的文件资料，就要用到ls -l这个指令。

ls –F（注意，是大写的F）

使用这个参数表示在文件的后面多添加表示文件类型的符号，例如*表示可执行，/表示目录，@表示连结文件

cd
这个命令是用来进出目录的，它的使用方法和在dos下没什么两样

mkdir、rmdir
mkdir命令用来建立新的目录，rmdir用来删除以建立的目录，这两个指令的功能同dos下的md,rd功能和用法都是基本一样的。

cp
这个命令相当于dos下面的copy命令，具体用法是：cp –r 源文件(source) 目的文件(target)
参数r是指连同元文件中的子目录一同拷贝。

rm
这个命令是用来删除文件的，和dos下面的rm（删除一个空目录）是有区别的，大家千万要注意。rm命令常用的参数有三个： -i,-r,-f。
比如我现在要删除一个名字为text的一个文件：rm –i 123
系统会询问我们：“rm:remove ‘123’?y”，敲了回车以后，这个文件才会真的被删除。
rm –r 目录名：这个操作可以连同这个目录下面的子目录都删除，功能上和rmdir相似。
rm –f 文件名（目录名）：这个操作可以进行强制删除。
rm -rf 文件名（目录名）：这个操作可以进行强制删除带有子目录的目录，一般轻易不要操作该命令。

mv
这个命令的功能是移动目录或文件，引申的功能是给目录或文件重命名。它的用法同dos下面的move基本相同。当使用该命令来移动目录时，他会连同该目录下面的子目录也一同移走。另外因为linux下面没有rename的命令，所以如果你想给
一个文件或目录重命名时可以用以下方法：mv 原文件（目录）名 新的文件（目录）名。

du，df
du命令可以显示目前的目录所占的磁盘空间，df命令可以显示目前磁盘剩余的磁盘空间。

cat
这个命令是linux中非常重要的一个命令，它的功能是显示或连结一般的ascii文本文件。

more,less
这是两个显示一般文本文件的指令。如果一个文本文件太长了超过一个屏幕的画面，用cat来看实在是不理想，就可以试试more和less两个指令。

clear
这个命令是用来清除屏幕的，它不需要任何参数，和dos下面的clr具有相同的功能。

pwd
这个命令的作用是显示用户当前的工作路径。

man
Man实际上就是察看指令用法的help。

logout
这是退出系统的命令。

导言
        软件质量一个很重要的部分就是测试和验证软件有效性的流程。这篇文章的目的是介绍相关的概念，并提供测试管理领域常用的最佳实践。测试管理是组织和控制测试工作所需的流程和工件的实践。这篇文章探讨的是IBM® Rational® ClearQuest®, IBM® Rational® ClearCase®以及IBM® Rational® Requisite Pro®如何提高测试水平。
导言

目的

        很少人会反对提高软件开发质量的需求。使用软件的技术人员已经开始预估各种各样的故障和缺点，特别是在个人计算机世界里，我们认为频繁出现问题是完全正常的并且在意料之中。尽管如此，随着软件开发日趋成熟，我们开始对如何在质量方面作出必要改进有了进一步的理解。这篇文章的目的是介绍相关概念，并提供测试管理领域常用的最佳实践。

什么是测试管理？

        软件质量一个很重要的部分就是测试和验证软件有效性的流程。测试管理是组织和控制测试工作所需的流程和工件的实践。用于测试管理的传统工具包括：

                   笔和纸
                   字处理程序
                   电子数据表

        更大的测试工作可以使用自己开发的软件测试管理解决方案，通常建立在电子数据表或数据库或者像 IBM® Rational® ClearQuest® Test Manager 或者 Mercury TestDirector 这样的商业测试管理应用软件的基础之上。

        测试管理的整体目标是允许团队在整个软件开发工作里计划、开发、执行并评估所有的测试活动。这包括调整测试工作中包含的所有工作，跟踪测试资产中的依赖关系和相互关联，并且最重要的是对质量目标进行定义、测量和跟踪。

测试管理的各个方面

        测试管理可以被分成几个不同的阶段：组织、计划、创作、执行以及报告。这些在下面有更详细的描述。

        测试工件和资源组织是测试管理中显然必不可少的部分。这需要组织和维持测试项目的详细目录，以及用来执行测试的各类事物。这表现了团队如何跟踪测试资产中的依赖关系和相互关联。需要管理的测试资产中最普遍的类型是：

                   测试脚本
                   测试数据
                   测试软件
                   测试硬件

        测试计划是回答为什么测试、测试什么、在哪里测试和什么时间测试这些问题的全部任务设置。创建一个特定测试的原因被称作一个测试激发因素（例如，必须确定一个特定的必要条件）。为了一个项目需要被测试的内容被分成许多的测试用例。在哪里测试通过决定和记录所需的软件和硬件配置来回答。什么时间测试通过跟踪测试的迭代（或者循环，或者时间周期）来解决。

        测试创作是获得完成给定测试所需特定步骤的过程。它回答了如何测试的问题。这里是一些稍微抽象的测试用例被分成更详细的测试步骤的地方，这些步骤将变成测试脚本（要么是人工生成，要么自动生成）。

        测试执行通过将测试脚本的顺序集合成测试套件来运行这些测试。这是对如何测试这一问题的后续回答（更为准确地说，是如何管理这些测试）。

        测试报告是指如何对测试工作的不同结果进行分析和沟通。这用来决定项目测试的当前状态和应用软件或系统的质量的整体水平。

        测试工作将产生大量的信息。在这些信息里，可以提取为项目定义、度量及追踪质量目标的方法。不管使用什么沟通机制，这些质量度量方法需要被传递给其他项目作为测试度量的基础。

        测试产生的一个非常普通的数据类型是缺陷，它通常是质量度量方法的来源。缺陷不是静态的，而是随着时间在变化。此外，多种缺陷总是互相关联的。有效的缺陷跟踪对测试和开发团队来说都是十分重要的。

测试管理中的其他因素

        除了软件和硬件测试工件和资源以外，必须管理 测试团队。测试管理必须调动致力于团队工作的所有团队成员的积极性。这需要对测试人员和工件控制 用户安全和进入许可。对于那些跨越一个或更多场所或团队的项目（这将迅速成为规范）来说，这也包括组织场所和团队协调。

        一个项目的特定测试流程对于测试管理来说意义十分明显。对于一个迭代的项目，测试管理将必须提供基础并重复地指导计划、执行和测试评估。而后，测试策略也将必须遵循测试管理框架。

相关的软件开发规程

        虽然软件开发中所有的过程都与测试相关联，有几个与测试的关系尤为重要：

                    需求管理
                    变更管理
                    配置管理

        需求管理是大多数测试工作的先驱，提供了大量的测试动机和确认需求。一个项目特定的需求管理流程对测试管理流程有重要影响。这种关系类似于一场接力赛，第一个跑的人代表着需求管理，下一个接受接力棒的人代表测试管理。IBM® Rational® RequisitePro®是发现、记录、组织和跟踪需求说明的工具。更多的信息可以在 IBM® developerWorks® Requisitepro 资源页面上找到。

        变更管理影响软件开发的全部过程，但是被跟踪的与测试工作最相关的变更是缺陷。缺陷是测试与开发之间最常见的主要通信渠道。从缺陷得出的计算和方法也经常被用作质量度量方法。ClearQuest 是一种贯穿整个软件开发周期中用于管理诸多类型的变更和活动的强大的、高可配置的工具。更多的信息可以在 IBM® developerWorks® ClearQuest 资源页面上找到。

        配置管理对于测试管理来说很重要，因为在什么时候对哪一个要测试的版本进行跟踪对测试来说至关紧要。配置管理为测试执行控制着由测试管理跟踪的工作版本和环境。IBM® Rational® ClearCase® 是主要的配置管理工具。更多的信息可以在 IBM® developerWorks® Clearcase 资源页面上找到。

测试管理的挑战

        总结测试管理目标的一个方法是回答下面的问题：

                  为什么我应该测试？
                  我应该测试什么？
                  我在哪里测试？ 
                  我什么时候测试？
                  我如何指导测试？

        从高层次的角度来看，这可能十分简单，但是在典型的软件开发中总会出现许多障碍。下面详细描述这些挑战。

没有足够的时间来测试

        除了某些专门的或者任务十分重要的应用程序外，很少的软件项目在开发周期里拥有充足的时间完成高水平的质量度量。通常情况是，软件工程里本来就很短的“测试周期”总是不可避免地会被耽搁。即使是最好的项目也很有可能在测试工作上面临时间限制。在测试管理中这种障碍的影响是不断变换优先级，不断转换工作以及为测试结果和质量检测方法简化数据。

没有足够的资源来测试

        除了缺少时间外，通常在取得执行必要的测试所需的合适资源方面也面临困难。资源可能被其他工作或项目分享。虽然测试的硬件资源会带来延迟和困难，但是人力资源的缺乏可能更加难以解决。在测试管理中这种障碍的影响和时间缺乏造成的影响大致相同。

测试团队并不是总在一个地方

        这段时期更经常的情况是测试资源可能可以获得，但是它们不在同一个地方。在各地区协调人力以降低成本已成为家常便饭，但是这造成相当多的技术障碍。在另一区域的团队如何共享工件并保持协同合作，并不会造成延迟和影响整个团队的和谐？一个项目如何能将区域分布式开发的效率发挥到极至呢？

需求方面的难题

        虽然有许多的测试策略，但是确认需求是需要完成的最主要的、优先级最高的测试工作。做到这一点需要完整的、明确的和可测试的需求。不够完美的需求管理会导致测试工作中更大的问题。使用像 RequisitePro 这样的工具可以帮助极大地提高需求管理并促进有效需求的开发。

        对于有效的测试管理来说，必须有对于最新系统变更和业务需求的无缝接口。这种接口必须不只是针对需求的描述，也要针对优先级、状态和其他属性。此外，这需要开发需求说明的团队和执行测试的团队之间最大限度的协调分工和沟通。这种沟通必须在确保质量的所有方面进行。

与开发保持同步

        软件质量所需的另一种团队协作存在与测试人员与开发人员之间的。除了关键缺陷之外，软件开发中总有一个惯例，那就是测试团队的工作只有测试人员关注。尽管如此，对于每一个人，特别是对开发人员来说了解当前的质量水平以及哪些已经被测试、哪些还没有被测试是十分重要的。

        为了有效地使用他们的宝贵时间，测试团队必须跟上不断变化的代码、工作版本和环境。测试管理必须精确识别要测试的工作版本和测试的合适的环境。测试错误的工作版本（或功能）会导致时间的浪费，并严重地影响项目进度。测试人员必须也了解什么缺陷是已知的，不需要重新测试的以及哪些是需要确定的。而后测试人员必须将已发现的缺陷以及促进解决方案的充分信息提供给开发人员。

报告正确信息

        如果能够为项目传达测试状态和一些质量评定标准，测试工作只是有用的。得出报告十分简单，但是提供恰当的信息（在合适的时间，为合适的人）是更加由意义的，主要有以下的原因：

        如果只有非常少的信息，那么除了对测试团队来说减少了感知缺陷的价值外，项目涉众将不能充分了解影响质量的问题。
        如果有过多的信息，那么主要信息的意义和影响就变得模糊。
        在如何将信息与不同地方的不同角色分享上总是有技术障碍。
        报告结果的另一个需要考虑的事项是如何安排信息以及以采用什么形式（也就是说，信息是基于工具的、基于浏览器的还是基于文件的形式）。如果有技术上或者其他限制报告的安排或形式上的约束，项目涉众对于测试和质量信息的了解将被减少。数据应该以一种清晰有逻辑的设计方式呈现出来，表示适当的意义，而不是以受局限的工具或技术的方式。因此对于项目管理来说在提供宽泛的报告格式方面考虑适应性和接受力的需要是十分重要的。

什么是质量度量？

        测试团队的一个主要目标是评估并决定质量，但是如何准确地度量质量呢？有许多的方法可以实现，而且根据系统或应用软件的类型和开发项目的特殊性分为很多不同的种类。为了避免曲解，任何一个质量度量方法都是需要清晰明确的。更重要的是，测试方法必须可以获取和保存，否则它们可能不值得花费成本或者可能是不完整或者不准确的。

测试管理的建议

        下面是可以提高软件测试管理的一般建议。

尽早开始测试管理活动

        虽然这一点看起来像最显而易见的建议，但是很少软件项目真正地应用这一观念。在早期开始确定测试资源很容易而且很常见，但是许多测试分析（如识别关键的、优先的测试用例）可以而且应该尽快开始。一旦用例被充分开发产生事件流，就可以得到测试程序。如果一个项目没有使用用例需求，那么仍可以从确认初始需求说明中得到测试。尽快开发测试能帮助减轻未来不可避免的时间限制。

迭代化测试

        软件测试应该是一个反复的过程，在整个项目周期的早期生成有价值的测试工件和工作。这是遵循尽早开始测试流程的首要建议：一个迭代的测试流程应该很早就关注测试管理。测试管理通过组织迭代的各类工件和资源来指导这一点。这个基于风险的方法有助于确保以最有效的方式处理项目时间线里可能出现的变更、延迟和其他一些不可预见的障碍。

重用测试工件

        在一个项目或多个项目里重用测试工件能够极大地提高测试团队的有效性。这样可以极大地缓解时间和资源有限造成的压力。可以重用的工件不仅包括自动操作测试对象，还包括测试程序和其他的计划信息。为了有效地重用工件，测试管理必须在组织和描述给定项目的与测试相关的各种信息方面做得很好。在创建工件时，重用总是需要一些预先计划，而且这一原则通常可以应用于测试管理。

使用基于需求的测试

测试可以被分成两种常用的方法：

                      确认事情按照计划进行
                      尽力找出什么使得事情停止下来

        虽然后面的探索性测试对于发现导致错误的难以预测的场景或情形来说非常重要，但是确认基本的需求可能是测试团队执行的最重要的评估。

        基于需求的测试是确认一个应用软件或系统的主要方式，它既适用于传统需求也适用于用例需求。基于需求的测试往往没有探索性测试那么主观，它也可以带来其他的益处。软件开发团队的其他部分可能质疑或者谴责探索性测试的结果，但是他们不能怀疑直接确认需求的测试。另一个好处是它可以更容易地计算所需的测试工作（与探索性测试相反，它总是受限于可以利用的时间）。

        它也可以提供各类统计数据，他们可能是有用的度量，例如测试覆盖率。测试用例是由需求产生的，并且随着事情变化对其关系的跟踪也更为重要，这是一件复杂的工作，应该通过工具进行处理。RequisitePro 和 ClearQuest 中的测试管理能力提供了满足这一需求的结果方案。

        这一流程的局限性是它信赖于一个好的系统需求和一个十分有效的合理的需求管理计划。从另一方面来说，探索性测试可能更加特殊。它很少依赖软件开发团队的其他部分，这有时会导致测试工作很少被关注在确认需求的重要任务上。虽然较好的测试工作应该将不同的方法集成起来，但是不应该忽视基于需求的测试。

协调远程测试资源

        为了避免资源不足或者只是为充分利用人员，您应该协调可以运用的任何资源，不管它们在什么地方。这些重要的资源很可能存在于多种区域，通常在不同的地方。这需要仔细有效的协同合作使得各地区的大多数测试人员和其他人参与到测试管理中。为了使之生效可能有相当多的技术挑战，因此需要适当的处理。ClearQuest 的 MultiSite 版本的测试管理能力能够帮助简化区域分布式测试协调的复杂度。

        我应该使用 Web 客户还是自动复制的数据呢？有两种解决方案使得相距较远的参与者能够协同工作。前者简单并且相对容易，但是如果从各地进行访问，仍有网络方面的潜在约束。对于受到人员或者功能限制的远程访问来说，这是一个好的解决方案。但是，对于由许多不同地方的人组成一个测试团队的情况，您需要具有复制到本地服务器上的数据使得他们的运行速度达到最大化。这也意味着您将需要一个简单无缝的方式使得每个地方的数据自动同步。这是 ClearQuest MultiSite 对于测试管理来说十分重要的地方。

定义并执行灵活的测试流程

        一个好的、可重复的流程能够帮您了解项目的当前状态，并通过预测了解其趋势。尽管如此，不同的项目对测试工作将有不同的特定需要，因此使得工作流程自动化的测试管理流程需要是灵活的并且可以定制的。流程应该是可重复的（为了提供预测），但是更重要的是，它必须允许改进。它必须使得修正十分容易，包括在迭代项目过程中的调整，因此它可以通过改变需要使其达到最优。

        如果不能以任何方式执行，那么定义一个指导团队成员的带有工作流程的过程意义并不大。需要怎样的力度来执行根据不同的企业和项目而有所不同。许多企业的软件项目需要遵循不同的法规，如 SOX 和 HIPPA。有些需要变更审核、项目历史和其他像电子签名等严格的遵守确认。不管您的项目测试管理需要严格地执行流程还是有更多的临时选择，您都需要一个机制来定义和执行某些事情。像 ClearQuest 这样测试管理工具是能够提供测试管理所需的所有能力。

调整并整合开发的剩余部分

        从传统意义来看，软件测试与开发的其他部分是严格分开的。这样做部分源于保持评估公正和有更多的机会发现开发中可能没有察觉的缺陷的合理需要。这一需要在验收测试中尤为明显，因为在验收测试中最好的测试人员往往对设计和执行因素缺乏判断力。尽管如此，这种特定需要仅仅代表软件测试中的一个方面，不应该对最终要进行的软件质量开发制造障碍。

        软件测试必须与软件开发的其他部分结合起来，特别是像需求管理和变更管理这样的规程。这包括不同的流程角色和活动之间重要协作、重要信息的高级沟通以及支持这一点的集成工具。没有这些协同分工，质量将会由于缺少或误解需求、没有测试代码、没有发现缺陷和缺少关于现行软件质量水平的信息而降低。

沟通状态

        工作的价值等取决于它被认知的程度，而工作如何被认知取决于传递给涉众的信息。好的测试管理必须提供所有相关信息的完整和正确的报告。在软件开发项目里实时状态、目标的测量方法以及结果应该提供给所有相关的团队成员。

        报告应该不仅仅只是传统意义的静态文件。假定变化是持续的，为了准确地交流信息需要有多种形式的易更新的输出。所有这些会帮助不同的项目角色在随着项目的进展对变化如何做出反应方面做出正确的决策。

        来自不同的软件规程的信息不是完全独立的。这篇文章已经提到了测试管理和其他像需求、变更和配置管理和开发这样的规程之间的重要关系。因此来自测试管理的输出可以很容易地与其他项目数据结合起来是至关重要的。当前的技术使得将所有的项目方法结合成为统一视图成为可能，这样可以确定所有项目的健康状态。工具也使得清楚地展示和评估测试、开发和其他项目工件的关系成为可能。

关注目标和结果

        为项目确定质量目标并决定如何有效而准确的测量这些目标。测试管理是详细说明目标、用于测量这些目标的方法以及将如何收集这些数据的地方。测试中许多工作可能没有明显的完成标准。定义正在进行的流程和变更的特定输出和测量方法将更详细地说明测试工作的活动和任务。牢记测试的特定目标和测试方法不仅有助于跟踪状态和结果，还能避免最终将所需报告混在一起。

        在一个单一的、公共的知识库或数据库储存测试管理的结果以确保更加容易地对他们进行分析或使用。这也促进了工件（包括工作）的版本控制，避免出现过时或无效信息的问题。这一切将有助于项目成员了解流程并在测试工作的基础上做出决策。

通过自动化来节约时间

        测试管理的内容有很多，而且许多工作非常耗时。为了节约时间，可以使用工具让许多工作自动化，或者至少半自动化。虽然像字处理程序和电子数据表这样的简单的工具提供了很大的灵活性，但是专门用于测试的自动化工具更加有效，更加有助于节约时间。通过自动化收益极大的工作包括：

                       跟踪需求测试和其他测试激发因素的关系
                       组织和重用测试用例
                       记录和组织测试配置 
                       计划和协调各种工作版本和应用软件的测试执行
                       计算测试覆盖率
                       各种各样的报告工作 
                       在测试管理中对适当工作的使用工具以使其自动化将极大地提高其价值和收益。
 

总结

        提高软件质量的一个重要步骤是超越旧的和基于文档的方法，并促进测试管理实践。测试管理包含各种功能，包括计划、创作、执行和报告测试，以及如何使测试并与软件开发工作的其他部分结合起来。对于测试管理来说有许多令人生畏而且不可避免的挑战，如缺乏时间和资源、测试团队分布在相距较远的地方、将测试与需求和开发相结合的问题以及报告正确的信息。

        好消息是有大量的最佳实践可以有助于应对这些挑战。尽早地并重复地进行测试活动、把重点放在目标和结果上以及协调并整合开发的其他部分，将使得测试工作不会成为对软件的事后弥补工作。充分地重用测试工件、协调距离较远的测试资源、定义并执行一个灵活的测试过程以及自动化都有助于克服资源的局限。

        一个可以实现这些实践的工具是 ClearQuest 中的测试管理功能。它直接满足了许多特定的技术需要，例如：通过 ClearQuest MultiSite 与远方团队一起工作。它也为创建满足任何项目或组织需要的正确测试管理解决方案提供了一个灵活的框架。

先查看Linux服务器操作系统上是否安装了CVS
[root@localhost /]# rpm -qa|grep cvs
如果没有安装你可以在Redhat 第2张光盘上找到，另外你也可以在网上下载到最新的rpm包。很容易找，其实不存在什么linux版本
 
建立cvs用户组
[root@localhost home]# groupadd cvs

建立cvs组的cvsroot用户和所属的目录
[root@localhost home]# useradd -g cvs -G cvs –d /cvsroot cvsroot

为cvsroot用户添加密码
[root@localhost home]# passwd cvsroot

改变 /cvsroot/ 的目录属性：
[root@localhost home]# chmod –R 770 /cvsroot

改变用户登陆身份
[root@localhost home]# su cvsroot

以下开始正式建立项目
[root@localhost /]# cd /home/cvsroot/egov/
[root@localhost egov]# su cvsroot
[cvsroot@localhost ~]$ mkdir projectsxy
[cvsroot@localhost ~]$ ls -l

...
drwxrwx---  4 cvsroot cvs 4096  6月 19 14:00 OAchanp
drwxr-xr-x  2 cvsroot cvs 4096  6月 20 15:23 projectsxy
drwxrwx---  4 cvsroot cvs 4096  6月 19 14:12 qiyjcxx
...
[cvsroot@localhost ~]$ cvs -d /home/cvsroot/egov/projectsxy/ init
[cvsroot@localhost ~]$ chmod -R 770 projectsxy/
[cvsroot@localhost ~]$ ls -l

...
drwxrwx---  4 cvsroot cvs 4096  6月 19 14:00 OAchanp
drwxrwx---  3 cvsroot cvs 4096  6月 20 15:24 projectsxy
drwxrwx---  4 cvsroot cvs 4096  6月 19 14:12 qiyjcxx
...
[cvsroot@localhost ~]$ cd projectsxy/
[cvsroot@localhost projectsxy]$ ls -l

drwxrwx---  3 cvsroot cvs 4096  6月 20 15:24 CVSROOT
[cvsroot@localhost projectsxy]$ exit
[root@localhost egov]# vi /etc/xinetd.d/cvspserver
按i进入到编辑
service cvspserver
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/bin/cvs
server_args = -f --allow-root=/home/cvsroot/egov/test --allow-root=/home/cvsroot/egov/projectsxy pserver
log_on_failure += USERID
}

~
~
~
~
-- 插入 -- 
编辑完后Shift+：
：wq 保存退出   

[root@localhost egov]# cd projectsxy/
[root@localhost projectsxy]# ls -l
总用量 8
drwxrwx---  3 cvsroot cvs 4096  6月 20 15:24 CVSROOT
[root@localhost projectsxy]# cd CVSROOT/
[root@localhost CVSROOT]# ls -l
总用量 192
-rwxrwx---  1 cvsroot cvs  495  6月 20 15:24 checkoutlist
-rwxrwx---  1 cvsroot cvs  698  6月 20 15:24 checkoutlist,v
-rwxrwx---  1 cvsroot cvs  760  6月 20 15:24 commitinfo
-rwxrwx---  1 cvsroot cvs  963  6月 20 15:24 commitinfo,v
-rwxrwx---  1 cvsroot cvs  991  6月 20 15:24 config
-rwxrwx---  1 cvsroot cvs 1194  6月 20 15:24 config,v
-rwxrwx---  1 cvsroot cvs  602  6月 20 15:24 cvswrappers
-rwxrwx---  1 cvsroot cvs  805  6月 20 15:24 cvswrappers,v
-rwxrwx---  1 cvsroot cvs 1025  6月 20 15:24 editinfo
-rwxrwx---  1 cvsroot cvs 1228  6月 20 15:24 editinfo,v
drwxrwx---  2 cvsroot cvs 4096  6月 20 15:24 Emptydir
-rwxrwx---  1 cvsroot cvs    0  6月 20 15:24 history
-rwxrwx---  1 cvsroot cvs 1168  6月 20 15:24 loginfo
-rwxrwx---  1 cvsroot cvs 1371  6月 20 15:24 loginfo,v
-rwxrwx---  1 cvsroot cvs 1151  6月 20 15:24 modules
-rwxrwx---  1 cvsroot cvs 1354  6月 20 15:24 modules,v
-rwxrwx---  1 cvsroot cvs  564  6月 20 15:24 notify
-rwxrwx---  1 cvsroot cvs  767  6月 20 15:24 notify,v
-rwxrwx---  1 cvsroot cvs  649  6月 20 15:24 rcsinfo
-rwxrwx---  1 cvsroot cvs  852  6月 20 15:24 rcsinfo,v
-rwxrwx---  1 cvsroot cvs  879  6月 20 15:24 taginfo
-rwxrwx---  1 cvsroot cvs 1082  6月 20 15:24 taginfo,v
-rwxrwx---  1 cvsroot cvs    0  6月 20 15:24 val-tags
-rwxrwx---  1 cvsroot cvs 1026  6月 20 15:24 verifymsg
-rwxrwx---  1 cvsroot cvs 1229  6月 20 15:24 verifymsg,v
[root@localhost CVSROOT]# su cvsroot
[cvsroot@localhost CVSROOT]$

[cvsroot@localhost CVSROOT]$ vi passwd
按i进入到编辑
sunxiaoyong:ENSlmPaH.nb2Q:cvsroot
~
~
~
~
-- 插入 --                                                                                                        0,1          全部

上边密码得来是在另外打开一个窗口进行密码生成:
[root@localhost ~]# cd /
[root@localhost /]# /home/cvsroot/passwd.pl "sunxiaoyongprojectsxy"
ENSlmPaH.nb2Q [root@localhost /]#    

......
最后从客户机建立名称为projectsxy的项目并使用cvs客户端导入。

对于项目管理，缺陷跟踪是很重要的一个环节，它除了可以对需求的完成度进行控制，同时也可以对软件本身的质量进行控制，以保证软件开发迭代的顺利进行。原来的软件项目开发中的缺陷跟踪都是通过EXCEL表格的形式来完成的，这种表格虽然也可以进行项目管理和项目执行度的交互，但效率与实时性不高，同时也不好维护和统计，因此就出现了缺陷跟踪系统，通过软件技术来解决软件项目的管理问题。

目前缺陷跟踪系统还是比较多的，比较有名的像Mercury的TestDirector，Seapine的Test Track Pro，TechExcel的DevTrack，Atlassian的JIRA以及今天要重点介绍的Mantis。

l TestDirector

在工业级软件项目领域，由于Mercury是测试软件领域的老大（比较有名的如LoadRunner、WinRunner等），因此它的TD也成为了缺陷跟踪系统的标杆产品。其也是最早通过Web方式来进行管理的缺陷跟踪软件。不过由于其早期版本不能灵活的对项目管理流程进行配置，又由于其昂贵的价格，因此目前应用的企业也不是很多。

参考网址：http://www.mercury.com

l Test Track Pro

Seapine 公司主要也是做项目管理软件的，Test Track Pro同其同门配置管理产品Surround SCM可以完美结合并实现完整的代码级管理。其主要架构为Client/Server，同时提供了CGI的Web访问接口，不过其高昂的价格也会让很多公司望而却步。其License分为两种，Named和Floating，分别为US＄295和US＄795。

参考网址：http://www.seapine.com

l DevTrack

TechExcel 可以说是CRM系统以及HelpDesk系统的老大，它的产品在很多大公司（如Oracle、IBM等）里面都有应用，最新发布的DevTrack功能也确实强大，在其项目配置的部分可以提供用户对各级项目相关人员的UI进行配置，同时也提供了最大的灵活度给客户，可视化自定义跟踪流程可以实现任何复杂的配置处理。与Test Track Pro相比，其功能可谓更胜一筹，用他们自己的话讲：“DevTrack – The market leading defect and project tracking tool from TechExcel”。官方网站上没有详细的报价，只是对其SBE(Small Business Edition)有一个大概的报价是含维护费每人每年149美金。其价格也确实符合其产品的层次。

参考网址：http://www.techexcel.com

l JIRA

JIRA 是目前比较流行的基于Java架构的缺陷跟踪系统，由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务，因此在开源领域，其认知度比其他的产品要高得多，而且易用性也好一些。同时，开源则是其另一特色，在用户购买其软件的同时，也就将源代码也购置进来，方便做二次开发。正因为其开放性，价格上自然也相当不菲，对于中小型的软件企业做项目管理，则又要另寻出路。

参考网址：http://www.atlassian.com

l Mantis

Mantis 是一个基于PHP技术的轻量级的缺陷跟踪系统，其功能与前面提及的JIRA系统类似，都是以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上可能没有JIRA那么专业，界面也没有JIRA漂亮，但在实用性上足以满足中小型项目的管理及跟踪。更重要的是其开源，不需要负担任何费用。不过目前的版本还存在一些问题，期待在今后的版本中能够得以完善。

参考网址：http://www.mantisbt.org

Mantis安装准备
Mantis采用了目前比较流行的LAMP（Linux + Apache + MySQL + PHP）架构，不过也可以通过各个软件的Windows版本进行配置。本文中的运行环境就是基于Windows平台搭建的。

Mantis安装的软件环境：

OS：Windows 2003 Server

Application Server：Apache HTTP Server 2.0.54 or later

下载地址：http://httpd.apache.org/download.cgi

Database Server：MySQL 5.0.10a Beta or later

下载地址：http://dev.mysql.com/downloads/

Language：PHP 5.1.2

下载地址：http://down.phpv.net/soft/1300.htm

Mantis：Mantis 1.0.0

下载地址：http://www.mantisbt.org/download.php

Mantis安装步骤
l 软件安装

首先安装Apache HTTP Server以及MySQL，两个都是Windows的安装包，直接按照其安装向导进行安装就可以了。在Apache服务器安装时需要注意其端口不要与 Windows的IIS服务冲突，建议使用8080或者其他的端口来提供服务。对于MySQL可能会涉及到缺省字符集设置的问题，可以设置成gb2312 或者utf8，不过由于目前mantis本身的问题，目前对中文输入信息的支持不是很好，官网上说在1.1.0版本上解决这个问题。

安装好应用服务器和数据库服务器后，将php的安装包解压到一个目录下，最好是比较容易访问的，如d:\PHP5，以免环境设置时造成麻烦。再将下载好的mantis压缩包解压到相应的目录，如d:\mantis，这样，安装就告一段落，下面讲解各个软件的配置步骤。

l PHP的配置

先将PHP解压目录下的libmysql.dll文件复制到windows/system32目录下，然后将php.ini-recommended文件更名为php.ini并进行修改。

这个文件需要修改几个地方：

1．首先是memory_limit = 20M ; Maximum amount of memory a scrīpt may consume (8MB)，我在这里设置为20M，以保证文件上传时的缓冲。

2．然后设置extension_dir = "d:/PHP5/ext"，这个是需要加载的外部库的路径。

3．保证file_uploads = On，并设置upload_max_filesize = 20M，这个是控制最大上传文件的大小。设置post_max_size = 20M，保证最大传载上限。

4．接下来就是设置需要加载的外部库文件：

extension=php_dba.dll

extension=php_dbase.dll

extension=php_filepro.dll

extension=php_gd2.dll

extension=php_imap.dll

extension=php_mysql.dll

这些信息在原有配置文件中都是存在的，只要将其前面的分号注释去掉就可以了。

5．Mantis还需要用到PHP的邮件系统，因此这里还需要配置一下邮件服务器信息

[mail function]

; For Win32 only.

SMTP = 210.22.139.90

smtp_port = 25

; For Win32 only.

sendmail_from = sukiyou@yeah.net@yeah.net

6．由于用到了MySQL，因此还需要在该配置文件中设置MySQL的环境信息。

mysql.default_port = 3306

mysql.default_host = localhost

mysql.default_user = root

mysql.default_password = 1234

OK，到目前为止，php.ini文件就修改好了，将其copy到windows的目录下就可以了。

l Apache服务器的配置

Apache服务器的配置过程主要是修改其conf目录下的httpd.conf文件。

1．打开httpd.conf文件，在#LoadModule ssl_module modules/mod_ssl.so下面加入LoadModule php5_module "d:/php5/php5apache2.dll"，保证php5apache2.dll文件在php的解压目录中。

2．在DirectoryIndex index.html index.html.var一行后加入index.php，使index.php也作为其默认首页。

3．打开scrīptAlias /cgi-bin/ "D:/Apache/Httpd/Apache2/cgi-bin/"的注释，让apache支持CGI解析功能。

<Directory "D:/Apache/Httpd/Apache2/cgi-bin">

AllowOverride None

Options None

Order allow,deny

Allow from all

</Directory>

4．增加scrīptAlias /php/ "d:/PHP5/"，配置php5脚本执行环境

5．在AddCharset shift_jis .sjis后加入AddDefaultCharset GB2312，设置缺省字符集

6．在AddType application/x-gzip .gz .tgz下面增加一行

AddType application/x-httpd-php .php .php5 .php4 .php3

保证Apache可以识别php文件并进行解析

7．打开AddHandler cgi-scrīpt .cgi和AddHandler cgi-scrīpt .pl前的注释

8．打开AddType text/html .shtml和AddOutputFilter INCLUDES .shtml前的注释

9．增加Action application/x-httpd-php "/php/php-cgi.exe"

10．然后是设置Mantis环境

Alias /bugtrack "d:/mantis/"

<Location /bugtrack>

Options Indexes MultiViews Includes FollowSymLinks +ExecCGI

AllowOverride None

Order allow,deny

Allow from all

</Location>

其中/bugtrack是访问URI接口，"d:/mantis/"是其映射的Mantis的实际路径。

l MySQL配置

MySQL的设置比较简单，首先在MySQL中先建立一个用户，用户名和密码可以都取mantis，新建一个用户的好处是容易进行权限控制，然后再建立一个mantis的库，并把mantis的所有权限赋给该用户。

l Mantis的配置

然后就是Mantis的配置了：

1．先将解压目录下的config_inc.php.sample文件更名为config_inc.php并打开，按照下述信息进行修改和配置：

# set these values to match your setup

这里的配置信息要与之前MySQL中的信息相对应

＄g_hostname = "localhost"; 数据库主机IP

＄g_db_username = "mantis"; 数据库用户名

＄g_db_password = "mantis"; 数据库密码

＄g_database_name = "mantis"; 数据库名

＄g_db_type = "mysql"; 数据库类型，缺省为mysql

# Jed complement

＄g_path = "http://localhost:8080/bugtrack/"; 这里需要设置mantis发布的URL，其中bugtrack/要与之前在apache服务器中设置的环境相对应

＄g_icon_path = ＄g_path."images/";

＄g_absolute_path = "d:/mantis/"; mantis解压后的绝对路径，很多图片信息需要直接定位到绝对路径才能显示

＄g_use_iis = OFF; 由于使用的是apache服务器，因此将该项设置为OFF

＄g_show_version = ON;

#＄g_default_language = 'chinese_simplified'; 这是一条注释信息，由于其字符集支持的问题，在官网上查找到需要设置为UTF8才能正常使用，不过修改后问题仍然没有得到解决。

＄g_default_language = 'chinese_simplified_utf8'; 这一条就是设置缺省语言了，其主要是确认页面显示语言

＄g_fallback_language = 'chinese_simplified_utf8'; 这一条功能同上

# --- email variables -------------

这一部分都是设置系统邮件的，包括管理员以及网管的邮箱，便于通过邮件系统通知各个使用者各种信息

＄g_administrator_email = 'sukiyou@yeah.net';

＄g_webmaster_email = 'sukiyou@yeah.net';

# the "From: " field in emails

＄g_from_email = 'noreply@yeah.net';

# the return address for bounced mail

＄g_return_path_email = 'sukiyou@yeah.net';

# --- file upload settings --------

# This is the master setting to disable *all* file uploading functionality

#

# The default value is ON but you must make sure file uploading is enabled

# in PHP as well. You may need to add "file_uploads = TRUE" to your php.ini.

这部分是设置文件上传参数的

＄g_allow_file_upload = ON; 允许文件上传

＄g_file_upload_method = DISK; 上传方式是DISK

＄g_max_file_size = 20000000 最大上传文件限制为20M，这个值不能超过之前在PHP环境配置中的文件上传限制

2．启动Mysql服务以及Apache服务，开始进入Mantis的安装。打开浏览器，输入http://localhost: 8080/bugtrack/admin/install.php，进入安装页面，填写好各种数据库信息，提交该页面，则系统会在数据库中将需要的库表自动建立。安装完成后，可以进入http://localhost:8080/bugtrack/admin/index.php，来检查数据库建立是否正确。

3．之后就可以用http://localhost:8080/bugtrack/login_page.php来进行登录了，系统会有一个初始管理员帐号administrator，密码是root。进入系统后就可以建立各种用户以及构建缺陷跟踪的项目了。

后记

Mantis的安装过程相对其他产品确实有点复杂，大概花了半天的时间，查了N多资料才将其配置成功，而且还有一些细节问题，如中文方面的支持等，不过瑕不掩瑜，其功能还是可以满足很多项目的需要的。

1、测试负责人要进行严格的测试进度跟踪吗？

很多时候，由于人力资源的不足，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，一些问题（例如：有些成员的缺陷质量不够合格；开发人员修改不及时，系统某些功能发生严重问题导致部分功能无法测试。）得不到解决，耽误了进度。所以测试负责任必须全程监控项目，尽可能多的掌握信息。通常，测试负责人需要完成下面这些内容的管理工作：

测试用例执行情况；

每个测试员提交的缺陷情况；

测试中是否发生突发问题。

2、 测试也有版本控制吗？

这里的版本主要是指测试对象的版本控制，也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下，测试小组进行版本控制十分重要，要保证测试对象是可以控制的。建议开发和测试双方进行明确的约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交情况进行详细的记录，这样基本避免了版本失控导致的测试失误或无效。

3、如何处理测试人员的流动问题？

人员流动不仅仅是测试部门，这是IT行业的普遍现象。从管理者角度，主管需要多多和团队内成员进行沟通，建立一个融洽的团队环境，及时掌握情况，可以早些进行相应的调整。但是只有企业建立好的用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从根本上解决这一问题。

加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来的损失。同时，测试部门要建立培训机制，使新到员工接受直接或者间接的培训，快速适应工作。

4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差？

我们经常听开发人员说：“这不是缺陷！”，“这个缺陷没有，因为我的系统上运行正常！”。测试工程师本身就是做质量工作的，提交的成果本身就应该质量高些，为什么还会有这种现象？

提交的缺陷引起争议是一种正常的现象，例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试，交叉测试是提高测试质量的一个有效手段，当然交叉测试会增加一定的测试成本投入。在测试任务完成后，测试工程师之间互相验证彼此提交的缺陷，就会避免了缺陷描述不清、因运行环境而产生的缺陷等一系列问题，从而大大降低了回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进行交叉测试，来提高开发质量。

另外，测试人员一定要按照规范描述测试中发现的缺陷，一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容，缺陷管理参考第八章的内容。

5、“让那些新手来做测试，反正他们也不会什么”正确吗？

在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员。也有些单位尽管认识到了组建测试团队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率低下，测试人员对测试工作索然无味。

根据笔者的经验，测试团队应首先聘请一名资深的测试领域专家，他应具有极为丰富的同类项目软件测试经验，对软件开发过程中常见的缺陷或错误了然于胸;此外，他还具有较好的亲和力和人格魅力。其次，项目测试团队还具有很多具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本等。

另外，测试团队还应聘请一些兼职成员，如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手，这部分人可以安排去从事交付验证或黑盒测试之类的

6、测试同化现象是什么？

同化现象是指随着时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。

招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。

7、测试工程师如何避免定位效应？

社会心理学家曾作过一个试验：在召集会议时先让人们自由选择位子，之后到室外休息片刻再进入室内入座，如此五至六次，发现大多数人都选择他们第一次坐过的位子。这种现象称为定位效应，说明人们习惯上凡是自己认定的，人们大都不想轻易改变它。

定位效应在开发人员和测试人员身上都有体现。例如开发工程师针对某一自己写的功能，经常进行代码移植，这种复制的“功能”，由于上一次经过调试，在新的地方往往不会认真调试，这些代码往往会带来共享变量冲突等许多种类型的缺陷。

定位效应体现在测试人员身上就是测试过的功能不再进行认真测试：在回归测试时，之前由于进行过认真的测试，往往会认为某些功能是可靠，只要验证一些以前发现的缺陷是否修改完成就可以了。这种现象在反复多次回归时表现的更加突出，因为回归测试中很多功能都会进行多次反复测试。众所周知，开发人员在修改缺陷时往往会引入新的缺陷，测试人员的疏于防范就会把这些缺陷带到用户这里。

解决这种问题的方案一般有两个：

(1)完整的执行测试用例：这种方法投入较大，但是在开发产品时最好在最后一次回归测试时测试的执行一次全部的测试用例。

(2)交叉测试：测试人员交叉测试，就可以很大程度的避免定位效应。测试工程师在回归测试时互相交换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”人员某些功能没有缺陷。

通常上面的两个方法都是结合使用的，既要进行交叉测试，又要全面执行测试用例，测试覆盖面要尽可能的广泛。

8、测试人员忽然辞职怎么办？

目前IT行业人员流动较大已经成为一种不争的事实，员工的辞职大多数都会给组织带来一定的影响，而这种影响基本是不可能避免的。在测试领域，员工忽然辞职也会带来很大的负面影响，尤其测试队伍规模较小时。面对这种情况，我们所能做的，就是如何最大限度的降低这种影响。

根据作者的经验，主要有两种方法：第一种是在测试人员内部建立一个良好的学习环境，大家互相学习，这样某些特有技术不会被某一个人所掌握，而互相学习和提高自身，也是大多数成员愿意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时容易上手，通过学习快速适应环境。

此外，日常还要注意工作规范化，例如形成尽可能多的文档，都可以降低员工离职带来的损失。

9、测试人员工作发生问题测试经理应该如何做？

测试人员工作发生问题是测试经理经常要面对的问题，作为测试部门的领导，首先要做的是指出测试人员所犯的错误，使其尽快改正错误。

唯一不能做的就是盯着下属的错误不放。总盯着下属的失误，是一个领导者的最大失误。英国行为学家波特说：当遭受许多批评时，下级往往只记住开头的一些，其余就不听了，因为他们忙于思索论据来反驳开头的批评。身为测试经理要根据测试人员的心理来进行指导，最大限度的调动每个人员的积极性来参加工作。

10、不深入到具体测试工作时，测试经理如何考核员工？

这种现象在测试规模较大的组织中很常见。测试经理应该尽可能的安排每周与每个成员在不被打扰的环境下进行谈话，这样可以尽早发现和解决很多问题。

最为一个测试经理，主要工作之一就是定期的评定组织做了些什么并且是怎样做的。同时还要为员工做一个报告——关于充分了解测试人员正在做什么和怎样做的报告，以此来给测试人员做做工作成绩考核。这份报告要了解到每个人的动态。

测试经理和每个员工重点是谈谈目前的工作，例如大家在工作中的问题或意见；是否需要帮助等。许多管理者经常抱怨没有时间在一周会见每一个员工来谈他们的工作。但是根据作者的经验，如果不能安排时间和员工进行每周的谈话，员工会来打扰测试经理的工作，因为员工很多问题还要要来找测试经理商议。

同时对待员工要用他们能接受的方式，而不是我们自己可以接受的方式。“己之不予，勿施于人”，这条黄金法则可能会对许多生活中的纯粹的社交因素有效，但是并不是总对工作有用。有效率的管理者知道应该逐渐了解每一个员工需要怎样的对待方式。

总之，只有尽可能多的和员工接触，才能更精确的进行考核。

11、测试经理如何面对加班问题？

大多数情况下，作者是不主张加班的。当员工每周工作超过40个小时的时候，他们开始在工作的时候关心自己的事。他们花钱，会给很久没有联系的人打电话，因为员工们一直都在工作。员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己，这种情况下通常效率很低。

测试管理工作的重要任务之一就是要创造一个环境，让员工在工作时间内完成工作，同时还要鼓励他们每周不要超过40小时，甚至可以基于他们在40个小时能够完成的工作量给他们酬劳。通常情况下这样做能够提升创造力，从而会逐渐提高效率。

测试工作本身的一个突出特点就是不断重复枯燥、冗长的测试，如果在疲劳状态下，很有可能精力不集中，略过一些重要的测试环节。而且有的时候测试需要编写测试驱动程序，这种情况更需要较好的状态来工作。

12、测试管理者如何面对自己的错误？

每个人都会犯错。我们可能会因为忘记开会而使客户发怒，承认自己犯错是一件尴尬的事情，尤其是管理人员认为对自己负责的项目小组承认犯错可能会失去尊严。如果我们不是经常犯错，承认错误的时候其实能够赢得尊敬。例如我们忘记一次会议，然后为此向同事或者客户道歉，其他的人会理解我们的。

不管做了什么，不要否认或故意忽略自己的失误。故意忽略不会让错误消失，这只会让错误成长为怪物。

13、为什么计划定期的培训?

测试工作和开发工作一样，不但要面对日新月异的新技术，还要学习相关系统的领域知识。只有在不断的学习中，才能做好工作，跟上行业的发展。如果测试管理者没有基于不断的变化而培训员工，就会给组织带来一定的损失。日常培训可以是关于特定项目或者是技术，通常采用下面几种方法：

（1）测试部门内自由交流方式的培训。这种培训的交流比较随意，可以在周五的例会上进行交流，也可以大家一起坐在茶馆里进行交流。方法可以采用“头脑风暴法”，让每个组员讨论一个特定的领域，这种交流方法特别对同时要做很多不同项目的小组比较有益处。当每个人做不同的项目，这会有助于每个人了解你小组所有的工程。

（2）跨部门的互相学习。测试工作需要很多领域以及技术知识，这些知识单靠自学是远远不够的。和其它部门的同事进行交流是一个相当好的办法，大家在工作中可以在技术等各个方面互相得到提高。

（3）外部培训。外部培训尽管投入较高，但也是值得的。这些专家一般在自己的领域非常精通，可以快速提高整个测试团队的水平。也可以通过测试小组介绍一些朋友来进行培训，这种方式可以降低成本。

培训是构造学习型组织的基本条件，也是提高员工水平的重要方法。经常的定期培训，可以增强组织凝聚力，使员工更加愿意长期留在组织中发展。做为测试负责人，定期的进行培训是十分必要的。

14、时间上不允许进行全部测试，测试负责人应该如何做？

这个问题也许十分可笑，可是现实中我们的测试经理们却不得不面对这个问题。这里的全部测试不是指对软件进行遍历测试，而是指测试负责人制定的测试计划包含的全部测试内容。

通常，不管是开发产品还是做具体的项目，都会发生耽误进度的情况。一旦整体进度不能向后延迟，项目相关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完成的情况下，这种现象更为突出。

担负着质量重任的测试经理，如何来解决这个问题呢？比较好的做法是按照下面的步骤逐步来完成和改进工作：

（1）按照测试任务的轻重缓急，尽最大努力完成测试任务。在时间不足的情况下，我们应该对测试任务按照优先级来划分，重要紧急的任务先完成。这个时候的测试任务是一种辅助性工作，其目的就是尽最大努力来提高质量。因此，面对这种情况，测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。

（2）在实际工作中和开发人员共同配合，逐步改进工作。只有整个团队的软件开发能力提高了，才能从根源上解决问题。因此，测试负责人要带领团队和开发小组共同寻找适合自己的开发模式，从而使项目规划的更加合理，进而按照预定计划来开展测试工作。

总之，在任何情况下，测试负责人都不应该抱怨。只有积极的面对问题，才能更好的解决问题。

15、公司不重视测试，测试负责人如何开展测试工作？

目前国内的软件公司不重视测试仍然是一种普遍现象。尽管很多公司在意识上已经开始重视测试，但是在具体工作中，往往由于追赶进度、节省资源等方面原因而忽略测试工作。在这种情况下，测试负责人仍要对软件质量负主要责任。在这种环境下，测试负责人应该如何开展工作呢？

首先，要主动去配合开发人员完成工作。尤其是不能抱怨环境，在任何情况下抱怨是不能解决问题的，只能加重矛盾的激化。在此基础上，逐渐显出测试工作的重要性，然后再逐步健全测试体系。

其次，用实际行动来证明测试工作的重要性。只有测试工作的业绩逐步表现出来，人们才会真正的注意到测试的重要性。因此，测试负责人从点滴开始做起，才能逐步做好测试工作。

要想做好软件，把开发的软件产品形成商品，测试工作必须和开发一样重视。否则，质量不好的产品，很快会被市场淘汰的。现代的软件规模越来越大，测试工作也会越来越重要，因此测试负责人只要坚持做好工作，可发挥作用的空间会越来越大。

最后要说的是，如果真的是在一个没有希望的团队里，测试负责人可以考虑辞职。辞职也是一个不错的选择，到新的环境去发挥自己的能力，要比长时间的怀着“郁闷”的心情去工作好的多。

16、测试管理者需要是技术专家吗？

测试管理者在测试项目中的主要任务是制定测试策略，管理测试计划的落实情况，并且还要为测试项目的进行创造良好的执行环境。同时还要调动员工的创造性，对员工的工作作出评估。这些工作不一定要求测试管理者达到专家的水平。

但是在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队，测试管理者的日常工作通常以具体的测试执行工作为主，这个时候更需要测试管理者有较好的背景知识。

总体说来，技术方面的背景知识对测试管理者是十分有益的。例如：分配工作任务、做进度预算，以及一些具体的执行工作，都需要一定的背景知识。当然，做为一个测试管理者，没有必要精通所有的技术，那也是办不到的。测试管理者做到正确的帮助员工最好地完成工作，并且提供最好的完成工作的环境就可以了。

第一章 什么是高质量的用例

1.1 为什么要使用用例

用例提供了一种用于构建故事的半形式框架；

在每个用例和所有描述层次中，用例都描述了错误情况的系统需求；

虽然本质上是一种功能分解技术，但用例已经成为面向对象软件开发的一个流行元素；

用例提供了可以在其上处理其他项目信息的骨架：

项目经理根据用例进行估计和发布进度；

数据及业务规则制定人员可以把自己的需求和所需用例联系起来；

用户界面设计人员可以进行设计，并将其与相关用例联系起来；

测试人员可以根据用例中描述的成功和失败情况构建测试场景（测试用例）；

1.2 编写用例容易出现的问题

用户界面太多，用户界面应属于设计范畴，鼠标、按键等内容不应出现在用例中；
较低目标层次上的用例太多，无法展示系统将会给其最终用户提供什么功能；
使用用例表示非行为信息，性能需求、业务规则等不要在用例中描述；
太冗长，最好在3~9步；
目标实现不完整，尤其是错误处理；
句子片断，主、谓、宾尽量完整；

1.3 为什么使用用例模式语言

描述了用例的质量标志及其编写过程，提供了能够经受时间考验的用例改进建议；在评审用例初稿和改进其质量的过程中，这个工具能起到很大作用。

1.4 什么是模式

模式是质量标志和策略；

1.5 使用模式语言时错误观念

模式提供了一个关于其自身和模式内容的完整方法；只起补充作用
使用模式肯定会成功；
模式为老问题提供了新的解决方案；只是经常出现的问题的通用可靠方案
模式适用于所有情况；仅是处于某种上下文中的问题的解决方案

1.6 模式组织

1.7 用例的读者和编写者

有两组不同的认阅读和使用用例：（1）最终用户或业务专家；（2）程序员。
用例编写组必须包括：
至少一位具有编程背景的认，以获得描述所要求的准确性和精度；
至少一位熟知业务规则的认；
至少一位熟知在实际中如何使用系统的认；

第二章 团队

2.1 SmallWritingTeam

原因：

用例要求具有不同观点和专业知识的人编写；
将一大组人聚集在一起是困难的；
理论上，在用例上投入的人越多，就能越快的完成用例编写工作；
大的团队会变得低效；
大型编写团队可能会通过集体讨论的形式开发用例，添加许多不必要的特性；

所以：

一个由2人或3人组成的团队足够小，容易交流和达成一致；

可以使用几个SmallWritingTeam，但应当制定一位用例设计师，以保证所有用例与愿景一致。
最终目的是使过程保持在可管理状态，大的团队将在管理上投入更多的精力。

2.2 ParticipatingAudience

没有涉众提供的信息和反馈，就不能满足他们的需要；尽可能使客户和内部涉众积极参与用例开发过程。

2.3 BalancedTeam

由一些个性相似、意见相同的个人组成的团队开发用例，可能会得到一组缺乏创见、范围狭窄的用例，这种用例不能满足每个人的需要。

因此，为小组配备具有不同专长的人员，以维护开发过程中涉众的利益，确保团队中包括开发人员和最终用户。
最大好处是使编写人员在用例中使用常见的、可理解的术语。

第三章 过程

编写好的用例是极其个性化的，每个人都有他自己的风格，每个组织都有根据自己的文化和业务需要做事情的方式，因此，没有创建用例的通用过程。

3.1 BreadthBeforeDepth

原因：

需求收集是一个发现过程，用例编写是一个迭代过程；
人们很早就开始编写用例的细节；
人们浪费了精力或陷入了太多的细节，通常都会失去重点，无法描述所有可能的扩展条件；
从早期获得概述是有益的；
最初编写的细节越多，在了解系统后必须进行的改变也就越多；

所以：

通过首先开发用例的概述来保存精力，然后逐步增加细节，并行开发一组相关用例。

完成概述用例后，随着对系统了解的增多，不断提高用例精度，避免突然开发完所有用例或一次只开发一个用例的倾向。

3.2 SpiralDevelopment（螺旋式开发）

原因：

理解系统的行为可能会花掉大量时间，要求渐进式分析；
拖延是昂贵的。要尽快完成用例的编写；
对需求进行分析后，需求很可能会发生变化；
需求成本的错误是昂贵的；

所以：

以一种迭代的，宽度优先的方式开发用例，每次迭代都会提高用例集的准确性和精度。

基本过程：

从简单的东西开始，如一个参与者/用例列表；
简要描述用力主场景，即高层用例，以包含用例的主要范围；
扩展摘要的子集，并填充细节；
评审并调整；

3.3 MultipleForms

不同的项目需要不同程度的形式化，每个人对模板都有不同的偏好，要求每个人都使用相同的用例模板只会起到相反的作用。

原因：

每个人的个性、经验和经受的锻炼不同，每个开发组织都有其特有的人员、历史和文化；
不同的项目有不同的需要；
不同的编写团队需要不同程度的规范和严格度；
在组织中使用公共的编写形式有助于交流；
在同一个项目上使用不同的模板不是一个好主意；

因此：根据项目相关的风险性、项目特点，和所涉及到的人员选择用例的编写格式，并在该项目的开发过程中的组织内部使用。

3.4 TowTireReview（评审）

许多人都可能需要评审用例，这是一件昂贵耗时的事情。

原因：

对于验证和确认编写及内容来说，评审是必要的；
涉众在用例上有一种既得利益；
使每个人参与编写过程非常昂贵、麻烦并且缓慢；
如果仅由一个小的编写组进行评审，就不会考虑所有涉众的利益；
评审可能是昂贵的、乏味的、耗时的。

所以：

进行两种类型的评审：第一种是由较小的内部小组进行的评审，可能要重复进行很多次；第二种是由整个团队进行的评审，可能只进行一次。

3.5 QuittingTime

开发一个超出了涉众和开发人员需要的用例模型不仅浪费资源，而且会拖延项目进度。

原因：

忽视重要需求的巨大恐惧使构建人员和涉众延长了需求收集活动；
大多数人可以用一种合理的模糊性工作，即不言自明；
详细讲述谎言并不能使他们更为精确；

所以：

在用例完整并且符合参与者的需要后，停止开发用例；
用例模型完整性的检验：完整、可读、逻辑上正确、对开发人员足够详细。
是否识别了所有的参与者和目标并将其编成了文档？
客户及其代表是否承认用例集是完整的，而且每个用例都是可读的和正确的？
设计人员是否能够实现这些用例？

3.6 WriterLicense

小的格式差别并不重要，解决了所有系统问题后，及时还存在一些格式问题，也可以停止编写；