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

离离糖漂流记

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

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

一点看法，请大家指教。

xiaoking

谢谢各位,受益匪浅

polestark

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

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

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

kuailederen

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

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

wuruling

我觉得这个问题 ，应该从两方面来说，1：可见管理 2、有效管理， 问题的本质是“管理”

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


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

hcn302

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

rainbow_qu

赞成用TD工具

zhou_yiyi

写的太好了，顶，真希望有一天自己也能写出如此好的文章。

woodcraft

有个问题：

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

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

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

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

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

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

love_yebin

巫婆 这个问题 还不错 仁者见仁智者见智~~~~~~~~~~~~


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

尤其是基于 敏捷开发的

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

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

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

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

woodcraft

P--D---C----A 模型中，你能回答“产品在何时达到质量标准并发布”这个问题么？

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

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

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

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

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

love_yebin

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

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

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

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

jrq1224

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

ljl_dxl

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

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

vaguely

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

reshma

测试各阶段都要形成相应的文档并进行审核
日报周报汇报当前完成的任务进度及完成情况

zajy

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

yzylion

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

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

abedd

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

fmsbai5

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