51Testing软件测试论坛

标题: 如何对测试过程进行可见的有效的管理？（09-08-17）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2009-8-17 11:23
标题: 如何对测试过程进行可见的有效的管理？（09-08-17）（获奖名单已公布）
如何对测试过程进行可见的有效管理？

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

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

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

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

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

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

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

作者: rolei 时间: 2009-8-18 11:09
标题: 测试过程有效的管理
计划、执行、监控、总结、跟进，循环往复。

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

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

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

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

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

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

作者: jiangmeiyu 时间: 2009-8-18 11:58
标题: 受益匪浅
看了各位高人的意见，真的收获不少。我是个非专业人士，而且刚刚参与测试工作。在上面表达了一下自己的看法，以及自己的管理方法。现在觉得有点献丑了，各位不要笑哈。

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

作者: zhong51test 时间: 2009-8-18 13:11
个人比较赞同过程控制。

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

作者: wyf221 时间: 2009-8-19 00:23
要想对测试过程进行可见的有效地管理，有一套好的管理方案是必然的，但要灵活用才是关键

作者: syq8050 时间: 2009-8-19 20:45
测试过程管理是个重点，特别是开发和测试人员交流过程中管理，可以大大提高效率

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

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

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

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

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

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

作者: woodcraft 时间: 2009-8-20 12:02
在传统的V模型中，应该不存在这个问题。V模型或者W模型都明确划分了阶段，因此测试过程的管理按阶段进行是可控的。

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

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

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

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

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

我们目前是这么做的：

计划：

一、进度计划：

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

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

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

二、技术计划：

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

执行：

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

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

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

作者: namisang 时间: 2009-8-21 15:53
看看大家的答案受教

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

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

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

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

作者: jzl2004 时间: 2009-8-21 17:00
标题: 测试过程有效管理方法-----目标管理，过程量化
测试过程有效管理方法-----目标管理，过程量化

目标=目的+标杆

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

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

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

作者: houzeal 时间: 2009-8-21 17:12
深入理解、思考 QC这这款工具的管理思想！
我想问题就已解决！！！

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

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

注意测试积累。

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

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

作者: 离离糖漂流记 时间: 2009-8-24 18:49
标题: 一定要有明确的计划
要对测试过程进行可见的，有效的管理，肯定要有一个明确的计划。
首先，制定计划，这是为了以后在以后的工作开展过程中，可以给测试的工作一个具体的可量化标准。
1. 在项目一开始的时候，召集所有测试团队成员和开发人员一起，理解项目的需求，和客户确认定义模糊的模块
2. 大致估计编写测试用例以及执行一轮测试所需的时间
3. 结合整个项目的开发计划，清楚定义测试用例完成时间及执行测试的介入时间
4. 在测试团队内部，把任务细分到每一个人或者某一个pair的身上，排出每一个人或者某一个pair的时间表
制定完计划，其它的就是执行了，软件项目本身存在很多不稳定性，所以在测试过程中，如果出现任何需求变更或者开发方面的推迟，需要及时调整测试计划，包括测试方法，测试侧重点以及Due date, 并且告知整个测试团队。

其次，量化，及时评定测试团队的工作。
1. 每日计划和每日报告，除了每天发给整个项目组的测试工作报告之外，鼓励团队成员在团队内部各自发送自己的每日计划和报告，一方面让队员明确自己需要完成什么工作，另一方面，让大家每天review自己的工作，可以提高大家对自我时间的管理能力，有利于后期的测试工作顺利进行
2. 尽量在每一个预先设定的Due date上开一个短会，讨论当前工作进行的状态，看是否是在计划的时间点之上，如果发现Delay,要及时找到原因，并且找到解决的办法。

一点看法，请大家指教。

作者: xiaoking 时间: 2009-8-24 19:24
谢谢各位,受益匪浅

作者: polestark 时间: 2009-8-25 10:07
随便说几句吧。其实这个问题可以参考前面有一期的提问，好像是测试人员的考核，里面提到了很多量化指标。有一部分可以拿过来用的。

看了上面很多人说的，基本都是需要量化。针对这个题目，的确是触及到了中心点。拆解下这个题目，何为“可见”，何为“过程”。过程好理解，当然是公司定义好的测试过程。可见，说的简单一点就是别人问你一句：测试目前进行的怎么样？你能够很清楚的回答出来。当然你可以说：还不错啊，马马虎虎啦，按照计划来进行的等等。但这种回答是可见的嘛？当然是不可见。既然要可见，当然要对过程进行拆分。在定义测试过程，你需要知道量化是做什么用的，为了什么目的。的确，指标有很多个，但并非所有的指标是需要的，要知道度量是需要成本的。既然有了目标，那回过头来看看如何去满足或者达到你的目标。
把测试过程分开，既然是要可见，说的当然是细节可见，而不是只在里程碑可见。所以需要在测试过程中定义 “阶段和细化的目标”。比如在测试设计进行过程阶段，你要定义好在下一个里程碑的目标（不一定是实际意义的里程碑，可能是一周的要求等等），然后对比目前的情况，你可以很清晰的说出来是否能按时达到目标，如果不能达到目标，现在的趋势是怎么样的。比如测试设计的时间偏差，测试用例的完成率，测试用例的缺陷率等等。（注意，可见是有个标准依据的）。

至于如何去实施，上面已经提到了很多了。比如制订好的计划（多做里程碑式的控制），做好评审，定期的会议，检查等等。不一一提了。

作者: kuailederen 时间: 2009-8-25 13:37
我觉得弄一些书面的标准没有意义，我来简单的回答一下吧。
一个好的测试过程包括以下特点：流程化，标准化，可度量，有效性和可见性。
为什么要做到可见呢，目前最主要的原因，是让关心项目的人看到项目的进度，项目与计划的符合度及项目的总体控制。
说白了，可见性是为专人（领导）专部门（需要监控项目的部门）服务的。他不是为测试自己服务的。

如果做到项目的看见性;
1.有一套行之有效的流程。在不发生意外的情况下，能够按照计划执行此流程，不用参与测试，就能知道项目的进度。
2.有效的测试度量。每一个都清楚测试内容和不标准，按部就班的执行。
3.清楚的测试数据。每一个步骤，都有相应的准确数据输出，并能够得到评估。
4.一套监控项目的措施。如果项目发生了偏离，能及时的发现和纠正。
5.有定义的测试过程。保证测试中的每一个步骤，都是计划中有定义的。
6.建立应对风险的措施。保证项目中可能出现的风险，不会盲目的应对，而是由针对性的。

作者: wuruling 时间: 2009-8-27 16:37
我觉得这个问题，应该从两方面来说，1：可见管理 2、有效管理，问题的本质是“管理”

1、了解测试员工在做什么
   在测试的各个阶段我们需要了解，测试员工在做什么，进展如何
   可以通过以下几种方式
   A、工作日志，每天让测试员工养成写工作日志的习惯，内容不要求太长，但要概括前天做了什么，如果项目中有困难、需要提供的帮助也可以提出来。
B、周报
C、周例会
D、敏捷测试中提到的站立例会
只要能了解到测试员工在做什么就OK，方式不限，你请他们吃饭也成，哈哈。
2、有效的管理
了解到测试员工工作情况，以及其工作中遇到的困难，就需要采取相应的方式，解决测试员工权力外的事情。
测试员工经常遇到的问题：
  A、测试计划合理性
      需要从整体上对测试员提交的测试计划进行审核，通过项目例会，确定合理的项目计划
  B、版本提交不及时和版本质量不高
      需要和项目经理进行勾通，若提交版本不及时，分配给测试员工的时间不能少，可能会导致项目延期。
  C、BUG处理情况
      在BUG产生争议时，需要和项目经理、产品经理进行沟通

别的也没什么了吧，测试还是蛮轻松的哈·~~

作者: hcn302 时间: 2009-8-27 17:31
1. 目标
有一个项目完美完成的最终目标，有了目标才会有责任心和为之努力的行动。
2. 写一个全面的切实可行的测试计划。
测试计划的中的测试范围，测试流程，时间安排，资源，风险和评估要全面，明确。
3．过程跟踪和控制
测试过程中，做好测试运行状态的追踪，做好阶段性的bug分析工作，以指导测试者找到测试点，发现更多的潜在问题，对于一个好的测试点，要及时普及到所有测试人员的意识里。
4．测试工作过程中的沟通和交流
积极和开发组长，项目经理进行沟通，对有分歧的地方及时和各方达成一致，并把结果反馈给项目测试成员，减少测试过程中不必要的沟通障碍和冲突，是工作更顺畅的进行。
5．及时解决测试成员在测试过程中遇到的问题，起到很好的桥梁作用，很好的解决项目过程中遇到的突发问题，。
6．分析，总结
在各个测试阶段，分析不同的特点，进行总结，积累。

作者: rainbow_qu 时间: 2009-8-27 17:34
标题: 向前辈们学习
赞成用TD工具

作者: zhou_yiyi 时间: 2009-8-27 18:02
标题: 顶
写的太好了，顶，真希望有一天自己也能写出如此好的文章。

作者: woodcraft 时间: 2009-8-27 18:40
有个问题：

产品人员最关注的是“软件什么时候能够发布？”

而测试人员一般只能回答：“这个版本什么时候测试结束”

至于能不能发布，只有测试结束才知道。

这种过程管理算可见而有效么？

测试过程管理不仅仅需要对测试做管理，也需要对软件周期负责.....

从这一点上来说，测试的过程管理太难了.........

作者: love_yebin 时间: 2009-8-28 09:56
巫婆这个问题还不错仁者见仁智者见智~~~~~~~~~~~~

不过我对各位的观点有一点质疑。你们写的和你们做的能一致吗？？？？？？？？？？？？

尤其是基于敏捷开发的

所以最佳答案应该还么诞生咯，
理论理论理论理论理论理论理论理论理论理论理论理论理论理论理论理论理论理论理论理论理论理论，这些是各位的实际，

暴风雨来临前，能不能讲点实际的？

比如我的观点 P--D---C----A 模型嘿嘿按计划做事，按规则检查，按方案执行，如果这个过程能持续，那这个问题就可以回答

[ 本帖最后由 love_yebin 于 2009-8-28 09:58 编辑 ]

作者: woodcraft 时间: 2009-8-28 11:53
P--D---C----A 模型中，你能回答“产品在何时达到质量标准并发布”这个问题么？

产品是开发人员实现并提供的，你如何保证这个过程？

割裂测试过程管理与开发过程管理，是很容易让测试人员抓狂的.......

这也是我的实践经验，在1个不负责或者能力不足的开发者面前，测试的过程做的再好，也无法确认软件测试的停止点，太累了.....

测试过程的管理必须回归软件质量的提升本质，以软件的质量提升作为测试过程的里程碑计划，这个里程碑，是测试者与开发者一同负责的，只有这样，才能有效控制测试过程.......

嘿嘿，也算对我的观点做个补充吧，欢迎大家指正。

作者: love_yebin 时间: 2009-8-28 18:59
标题: 回复 31# 的帖子
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
这里的check不仅仅是你说的过程检验，再说了理论上的产品质量标准或者项目通过准则不是在 P 里面写过了吗?
楼上的观点类似穷举，
:
在1个不负责或者能力不足的开发者面前，测试的过程做的再好，也无法确认软件测试的停止点，太累了.....:

对这个偶深表同情，但是我想从开发或者项目实施角度来说，这些角色是不可能担当重要模块的coding工作的

我不是在推崇ISO，因为这个东西如果配置管理到位的话，的确对项目过程可以起到督促和指导作用

小弟的小小补充下，测试的各个阶段及测试提交文档如果也有配置管理员监督的话，是不是更好点？

作者: jrq1224 时间: 2009-8-29 16:46
1..完善相关的计划，规程，策略，约定等规范性文档。
2..使用质量管理工具，使整个测试过程处在一个可控的范围内。
3.召集项目或产品的相关人员对目前工作情况进行阶段性的评审以及明确下个阶段中工作的重点。
4.召开一些项目学习会议,加强对软件的整体理解（大的系统中避免一个测试人员只了解自己测试的功能模块）。
5..加强项目组成员的沟通，提高相关人员的技能水平。
6.经常进行一些例如“测试之星”的评选活动，从物质和精神上给予肯定，激发员工对工作的热情
7.总结测试过程中的不知，持续改进。
【over】
工作后自己的小总结，欢迎批评指正。

作者: ljl_dxl 时间: 2009-8-29 18:17
标题: 回复：如何对测试过程进行可见的有效的管理？
测试过程包括了测试分析、测试计划、测试设计、测试执行、测试总结和测试培训，根据个人以往的一些测试经验，我认为，要做到可见和有效，要重点关注以下几方面的问题：
测试分析：在我们参加项目开工会时，作为测试人员要着重关注测试的可行性，需要什么工具、需要什么样的软硬件环境、需要什么人员配合、需要多少人力，测试人员需要具备怎样的技能才可以参与测试，这些条件现在都具备了没？对于目前还不具备的条件，是否有规避方法，若没有，该如何处理？对于这些潜在的风险都需要在项目组（包括开发和测试）上公开并共同讨论解决措施，由测试负责人跟踪问题解决过程并实时公布进度。
测试计划：分析完后，当然少不了做测试计划，在什么时间完成用例设计、什么时间转测试、多少人力参与、计划多少轮回归测试、质量目标和版本发布日期等等，这些测试负责人都要在测试计划中明确下来并在项目组公布。
测试设计：一般来说，SRS出来后，测试人员就可以开始设计系统测试用例，用例写作、用例评审、用例修改，每一个环节都需要严格执行，不能因为赶时间而忽视评审和沟通环节，有的测试人员写用例非常快，操作步骤写的很简单，同时对同事提出的评审意见不沟通、不修、改者修改不完整，导致用例质量下降，这些都是我们需要避免的。所以，在用例设计阶段，及时通报用例设计的进度、评审发现的问题、修改的用例数，这些作为设计人员需要仔细的记录并提交给测试负责人，测试负责人统一汇总并公布，并且奖励用例设计做得规范、全面的个人。另外，在测试设计过程中，大家容易犯一个错误，就是在对问题单进行回归测试的时候，不写测试用例，凭着对这一模块已有的认识，进行测试，简单填写测试结果，回归测试效率看似很高，但是往往容易漏测。再者，不少测试人员也容易犯一个错误，就是在回归测试前，没有对已有的测试用例进行全面细致的修改，特别是自动化接口测试用例，用例数多，而且开发也在不断的修改接口，这样往往会导致回归测试时，用例过老，跟不上最新需求或者变更。所以在从一轮测试结束到下一论回归测试前，测试人员需要实时的跟开发保持良好的沟通联系，了解开发最新的需求和变更，及时修改用例，做到“知己知彼，百战百胜”。还有一点，别忘了对测试用例进行基线化，测试用例是我们宝贵的财富，每隔几个测试周期后，我们就可以考虑对测试用例进行基线化，归档，不过，在使用基线化测试用例时，不能盲目的拷贝粘贴，因为具体项目产品需求略有不同，不能生搬硬套，要注意修改。
测试执行：在执行阶段，我们也需要注意做好几方面的工作。第一，环境搭建。通常来说，一个测试团队有新员工和老员工，老员工通常可以不看安装指导就可以将环境搭建起来，新员工通常要按照安装指导按部就班来做，不过，开发人员往往在完成软件修改后，就忽视安装指导的修改，结果，新员工搭建环境频频受阻，只能找老员工帮忙，这样以来，老员工走的不快，新员工跌跌碰碰，导致整体效率下降。所以，在转测试时，作为测试端，需要求开发提供详细正确的安装指导，另外，对有错误的安装指导，也需要提交问题单进行修改。第二，预测试验证，大家都知道转测试后要进行预测试检查，怎样才算通过预测试了，这个必须在开发和测试之间达成一致意见并严格执行，另外，预测试用例要需要得到开发的认同。所以，在预测前，开发和测试之间必须沟通好预测试通过的条件和预测试用例，以避免发生争议，同时结果定下后需要在项目内公布，让每个人都了解。第三，测试执行过程数据的统计和公布，风险预测。在测试过程中，测试负责人需要每天搜集当天测试执行用例数、发现问题数、问题级别和缺陷率，当然如果有开发修改进度的信息就更好了。这样，测试团队的每一成员都可以看到自己的测试成果和整个项目的进度，并跟周边的测试人员进行比较，调整测试步调。当然，测试日报中少不了风险预测，无风险则不成项目，在测试过程中，要实时分析当前项目的瓶颈和风险所在，及时寻找解决措施并在项目组内公布，可以加强大家的紧迫感和风险意识。
测试总结：每轮测试结束后，我们都会写测试总结报告，对于测试负责人来说，除了对该版本发现的总问题数、缺陷率、问题分布情况进行总结以外，同时也要对测试用例质量进行总结，也就是总结一下用例发现问题数，看看每100个用例可以发现多少个问题？另外，发现的问题中，有多少是通过用例发现的，有多少是用例覆盖不到的，分析其中的原因。这个总结的过程需要全员参与，最好人员交叉对用例进行检查，通过这种设计－》执行－》分析－》优化的过程来改善用例的质量。另外，测试过程中的遗留问题进行汇总并商讨解决措施，涉及到开发的部分需要跟开发共同讨论解决方法，并在项目组内公布。最后，可以开个技术总结会，让每个人先做个小测试总结，然后分享测试过程中的新发现，例如测试方法的小改进，测试疑难问题的解决过程等等。
测试培训：在做测试设计前，别忘了给大家做培训，因为一个测试团队有新老员工，产品也在不断变化，在设计前，有针对性的进行测试前培训非常必要，培训不一定要很细，重点是让大家对产品的总体框架和各模块之间的联系有所了解，这样，在设计用例时就可以避免关注点遗漏，忽略了对模块间用例的设计，同时让测试人员做到心中有数，把握该模块的测试进度。
总的来说，在整个测试过程中，测试数据的统计分析、问题的跟进解决、及时公布项目进度和质量数据，透明公开，全员参与，是实现可见和有效的重要手段。

[ 本帖最后由 ljl_dxl 于 2009-8-29 18:27 编辑 ]

作者: vaguely 时间: 2009-9-1 15:53
我觉得这涉及到质量管理，比如取得ISO或者CMMI的认证.
为了达到ISO或者CMMI的标准，整个软件测试的过程都要进行规范化和文档化。
达到了他们的标准，应该说测试管理就基本上是可见的有效的了。

作者: reshma 时间: 2009-9-2 12:32
测试各阶段都要形成相应的文档并进行审核
日报周报汇报当前完成的任务进度及完成情况

作者: zajy 时间: 2009-9-4 15:35
标题: 很受启发
看了各位高人的意见，真的收获不少。我是个非专业人士，而且刚刚参与测试工作。在上面表达了一下自己的看法，以及自己的管理方法。现在觉得有点献丑了，各位不要笑哈。

作者: yzylion 时间: 2009-9-6 08:22
标题: 对测试过程进行可见的有效的管理
对于这个问题，我个人的意见如下：
首先，我们是需要对测试过程来进行可见和有效的管理，我们的对象是测试过程，那么我们首先就应该要弄清楚，一个测试过程是包括的哪些活动，这个类似于需求分析的过程一样，把一个大的系统分为子系统、模块、接口的过程一样，相信大家都知道，该过程是由编写测试计划，测试设计和开发，测试执行以及测试总结几个活动构成的，那么接下来就该是我们对这些活动具体的管理方法的体现了，这样的思想源自于CMMI的PP这个PA，做任何事情都要有一个计划。所以
  第一：测试计划阶段。可见的管理：形成文档（纸质或者电子）化的测试计划。
                  有效的管理：形成该测试计划后组织评审，评审通过之后纳入配置库作基线管理，测试过程进入受控阶段。
第二：测试设计和开发。在这一阶段我们是要完成测试用例的设计与相关脚本的编写，测试用例数据的准备等工作，在这一阶段来说，有效性管理方法为：该阶段的所有输出物都要在形成后组织同行技术评审，评审通过后，进入测试执行阶段。另外，在有效性上面，还应该将被测项目的测试需求录入TD的测试需求目录下，在TD中建立需求与用例的关联关系，从而便于统计出用例对测试需求的覆盖程度。可见性管理：在测试计划执行完之后，由测试组长监督计划执行的有效性，测试员每天下班前形成日报并发送给测试组长，测试组长需要在用例编写完成的时间点上做进度的控制，如果在这一时间点，用例编写仍未完成，则需要做出一定的处理，例如：向测试经理汇报未按时编写完用例的原因，偏差率是多少，是否需要调整测试计划等。
第三：测试执行。这一阶段就是对之前的评审通过的用例进行执行。这一活动，我建议在TD中执行，将用例录入TD的用例与执行该项目目录下，然后在测试执行的目录下执行测试用例，这个也就是该阶段的有效性管理方法，通过这样的方式，测试用例发现的BUG情况则可以一目了然。至于可见性管理办法：该阶段仍然需要测试组长监督测试执行的进度，在出现偏差时需要分析汇总，测试组员每天形成测试日志，汇总自己的进度情况。同时对于每一次测试活动都需要形成一个测试分析报告，递交给测试经理和测试组长，便于对测试过程中当前产品质量有一个总体的了解。
第四：测试总结。该阶段呢就主要是在测试结束之后，对测试的过程，缺陷的分析等活动的总结。这一阶段我个人认为：在测试计划时间制定范围内组织好总结会议的召开，形成会议纪要，形成有效的测试总结报告，纳入配置管理也就是有效性和可见性的管理表现啦。

  以上为一家之言，不求苟同。欢迎拍砖

作者: abedd 时间: 2009-9-7 17:54
标题: 对测试过程进行可见的有效的管理
看到各位大侠对测试过程进行可见的有效的管理见仁见智，受益匪浅。
这里要注意的是“过程”和“可见”“有效”“管理”几个词，前面一些大侠谈到了很多，比如用到工具TD，QC之类对过程进行监管，而要用工具的话像VSS或SVN等版本控制的其实也是比较重要的。通过这些工具可以提高一定的效率，这是显而易见的。但是对于一些小一点的公司，若是对工具不很熟悉了，把文档做规范，按照时间分门别类的存放，更新之后填写更改log，也不失为一种比较可见而有效的管理办法，通过文档变更就可以看到整个项目的过程。

作者: fmsbai5 时间: 2009-9-11 23:45
大家说的都很好，但大部分讲的都是“渔”，那么现在我就想要“鱼”，一些具体的数值图表度量方法，数值化的测试质量控制，我觉得这可以另开个专题。

作者: zouzoulo 时间: 2009-9-15 17:08
标题: 提出一个新的思想，没有经过思考的
大家都提倡根据过程来管理，也就是面向过程。
根据现在主流的开发思想，在控制测试上面是否也能面向对象。
如果哪位智者有兴趣可以多思考一下。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)