如何对测试过程进行可见的有效的管理？（09-08-17）（获奖名单已公布）

默默巫

如何对测试过程进行可见的有效管理？

本话题由会员BigStones提供,如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	清风随雨	当当购物卡50元	7#
二等奖	狩猎者	300论坛积分	20#
三等奖	ljl_dxl	100论坛积分	34#

xihong2004

1、可以在TD的管理流程上，作一些修改，就是一个不错的管理方法
2、进行有效的版本控制
3、不能因为开发的延期而压缩测试的工期

[ 本帖最后由 xihong2004 于 2009-8-17 15:11 编辑 ]

jiangmeiyu

应该在测试结果上，采取轮流验证的方法，让测试人员能够通过不同的角度不同的方法进行测试。不仅对测试结果进行了进一步确认，还可以起到相互学习的作用

南小木

基于V模型和W H模型的测试过程的控制。
基于管理工具对于测试执行进度的掌控
基于测试策略风险的规避
基于测试过程中需求的频繁变更如何更好的掌控进度是上线日期。
基于需求分析中优先级的划分，测试过程不脱离需求。

[ 本帖最后由 南小木 于 2009-8-18 09:46 编辑 ]

rolei

计划、执行、监控、总结、跟进，循环往复。

1、计划：明确任务、资源和风险 --- 明确。
真实有效的测试计划可以对整个测试过程进行有效的评估，对于测试需要做的、不需要做的，哪些能做、哪些不能做，以及存在的风险会有一个明确、细致的描述。
有了目标，才有可能制定出有效的措施管理整个测试过程。

2、执行：计划过程的实际操作 --- 坚持。
有了目标，有了计划，就要切实的执行，没有强有利的执行，一切都是空谈。
也许会有种种原因阻碍计划的执行，但为了保证测试过程的有效性，坚持应当是必不可少的。
分清主次可以帮助我们在执行过程中对计划任务做动态的取舍。

3、监控：测试过程的何障 --- 发现
监控可以由测试组内部或是QA来执行。
个人更侧重测试内部监控，毕竟是管理测试的过程，只有身在其中的测试人员才真正了解整个过程的执行情况，跟据这些情况才能制定出有效的控制措施。
也许是未雨绸缪，也许是亡羊补牢。不论怎样，先发现问题，然后才可能解决问题。
测试例会、内部评审可以提高监控的效率，使大家明确当前的问题和将要重点观注的工作。
让过程中的团队成员（测试、开发、管理）参与过程管理，一方面可以调动积极性，另一方面可以有效的执行。：）

4、总结：分析问题、解决问题 -- 积累
发现问题、解决问题，需要不断的总结存在的问题，跟据问题设计和调整有针对性的测试方案。
不断的总结可以帮助我们发现真正的问题，同时在不断的积累过程中形成一套有针对性的、切实有效的管理方案，为今后的测试执行积累和提供有价值的技术支撑。

5、跟进：执行和监控后对问题的处理的细化 --- Tracking
计划在执行，计划也在整个测试过程的有效管理和监控中，那么出现的问题怎么办？
“当日事，当日闭”有点太慢了，过程中出现的问题应当是“当时事，当时闭”，针对问题，快速响应，及时调整，有效管理 ：）
过程出现的问题对整个过程的影响不容小视，不断的跟进（不断的监控和执行），可以有效控制问题的解决，保证整个过程持续、有效、健康的前进。

[ 本帖最后由 rolei 于 2009-8-18 11:20 编辑 ]

jiangmeiyu

看了各位高人的意见，真的收获不少。我是个非专业人士，而且刚刚参与测试工作。在上面表达了一下自己的看法，以及自己的管理方法。现在觉得有点献丑了，各位不要笑哈。

清风随雨

只有在各项管理制度相对规范的情况下，才能够实现对测试过程进行可见的有效的管理，主要包括以下几个方面：
1、测试计划
   测试计划是测试工作开展的基础，测试策略、测试重点、人力资源、时间资源、阶段划分等等都需要在计划中明确，可以说，没有测试计划，整个测试工作将面临无序的状态，所开展的工作将是盲目的；
2、分阶段管理
   测试工作是一个循序渐进的过程，因此，需要把整个测试工作拆分为若干阶段进行管理，每个阶段有阶段性的任务，有明确的目的性。大致可分为测试准备阶段、测试设计阶段、测试执行阶段、评审阶段、回归测试阶段、测试总结阶段。
3、测试准备阶段
   测试工作的质量高低取决于测试用例，而测试用例的优良除与测试人员的经验和技能有关外，还取决于测试准备工作是否充分。测试准备工作可分为以下几个方面：
   测试功能点划分、业务流程图制作、数据流程图制作、测试变更管理、测试培训等等。因为软件的多变性，所以，以上工作的开展必须得到需求管理制度、需求变更管理制度、配置管理制度的有效支持才能够真正开展。
4、测试设计阶段
   测试设计阶段特指测试用例编制阶段。该阶段根据上一阶段的成果:测试功能点、业务流程图、数据流程图（满足功能覆盖）结合各种测试方法（满足测试深度覆盖）编制测试用例，同时，根据测试变更管理，随时针对需求变更分析变更功能点以及影响范围，从而调整测试范围和测试用例。
5、测试执行阶段
   测试执行阶段主要包括以下工作内容：测试用例执行、测试脚本录制及修改、测试执行记录填报、Bug提交。其中，测试执行记录是属于测试部门内部工作监控，便于管理人员随时了解测试工作执行情况以及成员的工作状态。Bug提交需要有Bug管理制度的支持。
6、评审阶段
   评审阶段并不是特定在测试执行阶段之后，而是贯穿整个测试工作过程。主要是针对各个阶段的成果进行评审，评审对象包括：测试计划、测试功能点、测试策略、业务流程图、数据流程图、各项变更、测试用例、Bug等等。
7、回归测试阶段
   回归测试阶段根据Bug评审结果执行回归测试，同时需要统计Bug分布、Bug修改率，以供项目管理需要。
8、测试总结阶段
   测试总结阶段指各类测试文档整理以及测试报告编写。
   个人认为，测试计划是基线，是测试工作开展的标尺；测试准备工作是基础，是测试工作优良的根本；测试设计是方法；各种评审是监督；这样贯穿起来，各个阶段的成果环环相扣，后一阶段的开展是对前一阶段成果的检查和补充完善。这样管理不但使各个阶段的工作目的、工作内容明确，同时，对整个测试工作的进度能够更好的掌控，其测试结果也会令人满意的。
   以上个人对以往测试工作的总结，不足之处还望同行们指出，大家一起交流。

zhong51test

个人比较赞同过程控制。

JerryYe

理论是一方面，关键是要结合公司的实地情况，好的理论并不一定适合每个公司。
严格的版本控制是一方面但有时敏捷快速测试也是适合一定的环境。
交叉测试 避免测试遗漏，确保测试的充分性。

wyf221

要想对测试过程进行可见的有效地管理，有一套好的管理方案是必然的，但要灵活用才是关键

syq8050

测试过程管理是个重点，特别是开发和测试人员交流过程中管理，可以大大提高效率

zdlzx

个人认为“最可见的有效的管理"就是充分信息沟通基础上的自治"，而测试管理人员可以从日常工作和长期培养积累两个方面来着手：

日常工作
1.制定切合实际的测试计划，并分享和所有相关的stakeholder
一个可见的测试计划让大家都知道接下来的方向、里程碑、范围、目标等。走一步看一步或者不分享信息给其他角色，纵然你测试组的工作再有把握，也不能在一个团队中得到广泛的认可。

2.及时跟踪、发布、分析测试结果
测试执行过程通常要持续若干周甚至月。如何让所有关心测试进展的人都能够和测试者一样了解当前的状态、问题、风险，可以通过daily report, release report等各种形式及时跟踪、发布、分析测试结果。因为bug的数量绝对不能说明整个测试的全面状态，甚至会误导，所以及时透明的信息分享和正确的引导会让测试更有效。

3.对突法事件及时响应
不是所有测试过程中发生的大事都是事先可以预见的。碰到紧急情况，需要测试组长或者比较有经验的测试人员及时响应，扫清障碍，让测试顺利进行。

4.与开发团队和需求分析及实施团队保持有效的沟通，提供对方需要的信息，在测试方面提供专业性的意见和风险控制。
必要的话，分享至少两类信息给测试团队以外的人员。一是定性的，比如，不管当前的统计数据如何，你给出专业的对于质量水平和风险的判断。二是定量的，给出具体的数据支持你的定性的论点。

长期培养和积累
1.提高测试人员的认知，为自治和提高做长期的积累和准备
流程的管理是基础，也是死的。真正有效的管理还要与人的素质和能力进行结合。比如，一个不知道为何要统计这些数据的测试人员在写测试报告的时候就不可能将最有价值的信息挖掘出来。所以，要让每个测试团队的人员都理解为什么要这么做，而不仅仅是照着做。最理想的情况是不需要所谓的测试组长，每个测试组员都能对当前项目的整个质量状况作出全面的正确的评判和知道如何去控制相关的风险。

woodcraft

在传统的V模型中，应该不存在这个问题。V模型或者W模型都明确划分了阶段，因此测试过程的管理按阶段进行是可控的。

但是目前的环境，决定了很多团队的测试无法按照V或者W模型进行，这时候如何可见的管理测试过程就是个问题了。

我们团队的经验是进行目标导向管理。

我认为，测试团队应该有两个角色：

其一是“研发部门的测试团队”，作为这个角色，测试的目标是尽快使软件达到质量与进度的发布要求。

其二是“第三方评测团队”，作为这个角色，测试的目标是评价目前软件的静态成熟度。

我们目前是这么做的：

计划：

一、进度计划：

在项目开始前，由测试负责人制订分阶段进度计划，包括此项目的可能风险模块，以及每个模块的质量达标日期。最终制订软件发布的日期。

对于软件的部分改动，首先识别软件中有可能存在较多BUG的模块（大多为改动部分），测试团队与开发团队一同评估质量可以达标的进度计划。

对于重新立项的项目，也根据各模块的风险大小排序，然后制定每个模块的进度计划。

二、技术计划：

针对进度计划，在技术上确认每个阶段的测试策略、方法与环境。我们将V模型中的单元测试、集成测试、系统测试不再视为阶段，而是手段，在进度计划的要求下灵活使用各种手段发现更多的BUG，完成“研发部门的测试团队”这个角色。

执行：

在开发团队提交测试软件后进行质量推进阶段测试，测试的目的是尽可能多的发现BUG，通过发现BUG来推进软件质量，完成进度计划。这时候，我们是“研发部门的测试团队”。

在每个模块的质量达标点上，我们可能会进行验收测试，承担“第三方评测团队”这种角色，确认模块的质量是否与计划一致，以对测试过程进行评估与管理。

这种模式围绕软件为中心，将漫长的测试过程分阶段制订目标，能够在过程中实时对目前的软件质量与进度进行评估。我们团队目前正在实行，也欢迎大家指正。

namisang

看看大家的答案 受教

xunmi

要进行可见的有效的管理，首先得领导做好工作计划，测试做好任务跟踪，QA做好监控，再结合部门考核来充分实现。

我们公司首先每月和每周由部门经理给出大概的工作计划，然后由各开发组长根据工作计划，提取细化成每个人员的工作任务，测试主管会根据开发组长的工作计划，编写测试人员的测试计划，还有QA的阶段输出检查计划，然后各测试人员根据测试计划，填写测试要点，测试用例，最后QA根据计划中的时间点来检查开发人员工作完成进度，测试人员的测试用例数，提交BUG数，阶段输出文档是否齐全来进行工作质量评定，最后领导根据质量评定进行人员工作考核打分。

测试工作与开发工作是相辅相成的，需要以一个统一流程来进行管理。

[ 本帖最后由 xunmi 于 2009-8-21 16:06 编辑 ]

jzl2004

测试过程有效管理方法-----目标管理，过程量化

目标=目的+标杆
  
  标杆： 测试过程量化，形成规范，明确过程量化，形成阶段的里程碑，交付件，进度控制，即企业级别的《软件测试过程说明》文档，整个测试过程在该文档进行详细量化定义，包括方法、类型、定义、策略

  目的：明确本次测试目的，结合公司的《软件测试过程说明》文档，在该项目种进行修改和调整（修改内容需记录），然后根据项目情况，对该文档进行量化环节，每个环节对应文档进行二次量化，量化的标准为输入和输出工作成果

  管理: 管理的过程，就是监督《软件测试过程说明》量化的过程，对执行过程中的每个环节进行输入输出的质量、进度、影响进行管理控制

houzeal

深入理解、思考 QC这这款工具的管理思想！
我想问题就已解决！！！

hongwu360249

简单的说几句：
1、让各测试人员明确需要测试的项目的相关模块，是全新的版本还是在以前基础上修改的版本，熟悉模块的组成及功能特性，这个可以通过阅读相关需求文档或者直接跟开发交流。如果是测试在之前版本基础上修改的版本，需要明确哪些地方做了改动，哪些是新增的功能。
2、思考当测试工作正式启动后如何在有限的时间内展开有效的测试，重点测试哪些项目，提前设计测试用例。
3、阅读之前版本的相关缺陷报告及bug修改报告，了解软件哪些地方容易出问题，根据软件缺陷的集群现象，针对性的补充一些测试用例。
4、测试用例评审 可以组织有经验的测试人员对编写的测试用例进行评审，看那些地方还需要补充或修改
5、版本转测试时可以开展转测试沟通会，进一步明确测试目标及重点测试项目
6、开始测试 根据前几个步骤对模块的熟悉情况及设计的测试用例展开测试工作
7、发现严重的bug后保留现场第一时间通知开发人员确认  有些bug可能是由于环境搭建引入的，有些可能是比较难以重现的。保留现场让开发人员确认可以判断是不是bug，如果是bug，根据现场情况也能给开发人员提供更多的定位信息
8、提交bug  发现bug后尽早提交，不要累计到后面一起提交，给开发人员足够的定位修改bug时间，同时尽量详细的描述发现bug的步骤
整个过程中沟通很重要

free_xiaoyu

1、制订切实可行的测试计划，明确测试对象和目标。
2、做好充足的测试前期准备。
3、执行测试时及时跟踪、发布、分析测试结果，并与开发团队进行有效的交流沟通。
4、定期检查项目进度，汇总测试中出现的问题，并给出相应解决办法。
5、项目测试完成后，针对该项目作出完整的测试总结。

注意测试积累。

狩猎者

我认为要实现测试过程的可见的有效的管理，必须要做到两项。
一、        使用测试管理工具
最直观、最简洁，最方便管理的方法。管理工具可选用的就很多了，我就不多说了。
二、        制定测试管理的规则
规则即将工作进行量化处理和如何进行工作评定。良好的量化使测试过程具备了可见性，合理的评定规则使测试过程可以进行有效的管理。
下面我所阐述的是针对一个测试部门的测试过程进行可见的有效的管理，而不是针对一个项目的测试过程进行可见的有效的管理。如果只针对一个项目的话，项目分析量化可以忽略。
1、        项目分析量化
根据项目的合同（或需求分析），计算项目的成本，根据测试工作在项目中所占比重，转化成测试工作的量化指标。
例如：一个100万的项目，测试占项目总体的比重数是多少，如占15%。我们将100万转换成1000个积分，那测试占150分。这150分就是测试工作在项目中所占的积分。
也许看到这很多人会说，我们讨论的测试过程可见性，和测试工作在项目中所占比例没有什么关系，其实这也是一个重要指标。
如果每个项目的测试积分相同分数，那么参与测试比重大、测试过程复杂项目的人员，和参与测试比重小、测试过程简单项目人员的工作量和技术难度对比将无法体现，这也就只能做到模糊的可见，并无法做到有效的管理。可能会出现测试人员抢着做简单任务的情况，因为简单任务积分和复杂任务相同，谁也知道简单的容易拿到积分。
2、        测试过程量化
测试过程的量化，要以测试计划为依据进行分析。测试计划可以由测试经理制定，测试组长制定，制定完成后要经过项目经理和相关评审人员组成的评审小组进行审核。
（1）进行测试用例的量化。
测试用例的优劣对测试工作的进行有着直接的影响。根据测试计划，对测试用例进行量化，根据编写测试用例的工作量，给定测试用例工作的基本分。
根据测试人员编写的测试用例进行评审，给定最终测试用例得分。
测试用例评审规则主要依据测试用例的覆盖率、测试用例的完成情况、测试用例的有效性进行评定。
（2）执行过程的量化
执行过程根据测试计划中所占工作量比例给定基本分。
根据测试人员执行测试用例的效率、执行情况（是否按照用例进行）、执行的正确性进行评定、测试报告提交是否及时等进行评定。
评定主要有测试部经理负责进行。
（3）执行结果的量化
执行结果量化根据测试人员提交Bug的质量和回归测试进行的情况进行评定。
Bug质量主要是指发现的Bug的重要性和测试人员对Bug的描述是否规范以及Bug的可重复性。
对回归测试是否进行，进行的具体情况，是针对Bug进行了测试，还是对相关功能进行了测试。

以上是本人根据自己工作经历发表的一点看法，不足之处欢迎大家指正。