标签：
转载自“山丘的测试之道” ： 聊聊测试管理（管事篇）
管理：管人+管事。
说到管理，其实就是团队，没有团队，就谈不上管理。个人理解，对个人而言，更多应该是计划，而非管理。做管理的时间并不长，或者说很短，可能很多地方理解的有问题。写这篇文章也是为了能更多的与大家交流，也是记录下在目前这个阶段我的理解。(本文均以在创业型公司工作为背景)，全篇分为管事篇跟管人篇。
关于这个点，其实网络上一搜一大堆，大体都差不多，需求分析，测试计划，设计测试用例，评审用例，执行测试，缺陷管理，定版，发布。但是，我认为作为一个测试leader，在一个创业型公司，并不是出一个这样的流程这么简单。我觉得更多应该考虑的是适合公司的。在我制定我们团队的测试流程时，与我们的项目经理，架构师甚至产品经理都有过很长时间的沟通，测试活动离不开产品，开发，所以在测试的工作流程中，应该包括如何去产品，开发更高效的去协作。下面讲讲我整理的测试工作流程。
黑盒测试离不开需求分析，所有的测试都是基于需求，如果对于需求的理解不够透彻，测试的质量也就可想而知。所以在这个阶段，我会花很大量的时间去做。我团队的需求分析主要包括：两图一文档。
两图：业务流程图，思维导图。
一文档：需求分析文档。
业务流程图，是对于需求从流程（整体）去理解。思维导图，是对需求所包含的各项功能点去理解。需求分析文档，是对思维导图中的功能点去发散成为测试点。这样下来，一个需求所表达的内容，基本不会漏掉。而更高层次的隐性需求，就需要对业务有着很深的理解，这点可以在工作中慢慢去引导团队成员去做。流程上很难去控制。
网络上的测试计划，都是一个文档，一大堆形式上的东西，可能对于大公司而言，有这个必要，我目前所见识的，基本都没有必要。
我认为测试计划主要给出以下几点：
（1）、测试类型：黑盒测试，接口测试，UI自动化测试，接口自动化测试，性能测试等等
（2）、测试时间：需求分析起止时间，设计测试用例的起止时间，执行测试的起止时间
（3）、测试执行人：创业型公司由于人员少的情况，很可能以项目（模块）划分测试负责人，也可以根据设计和执行来划分测试负责人
一个测试计划，有这三点，我个人认为就可行了。
关于设计测试用例，可能很多在创业型公司工作过的小伙伴会说，时间很紧，压根没时间来做这个事。
这一点，我用了两个月做了一个调研，前一个月不写测试用例，大家就按照自己的思路去测试；后一个月，严格写测试用例，执行测试集去测试。调研结果是：前一个月在测试开始时，测试速度稍微快点，在进入测试中后期，测试速度就很慢很慢，因为常见点已经测试完了，测试工程师自己都不知道哪些东西测试过了，哪些还没？哪些没有问题，哪些还有问题？不能很直观的去管控。后一个月在开始时，由于写测试用例的时间，速度会稍微慢点，但是在中后期，测试效率明显比前一个月要好很多，测试工程师对于项目的把握也更清楚。两者整个花的时间基本差不多。质量就更不用说了，肯定后者更有保证。
探索性测试，我觉得在业务能力以及测试经验都很充足的情况下，可以结合编写测试用例，去执行测试。一味的追求探索性测试，其实对于大多数测试工程师来讲，很难。
目前，我的团队是，测试工程师编写好测试用例，先组内评审，然后导入到QC，测试人员根据QC测试集去执行测试，而我也能很直观的把控测试进度，以及当然存在的问题。
用例评审很重要，毕竟测试工程师也是人，也会有很多点是想不到的，所以用例评审就是一个查漏补缺的环节。用例评审不是找人茬，而是在这个过程中，补充测试思路，提升测试质量。
年前，这一项，我们没有做，因为当时我们的测试工程师写的用例还达不到评审的水平，所以只是组内评审。目前已经启动用例评审。效果还待观察中。
测试用例评审方法：
（1）、提前邮件提醒评审相关人员（开发负责人，产品负责人，测试负责人，项目经理等），附件上测试用例。
（2）、1-2天后，组织用例评审会议，由于事前有看过需求跟用例，所以会议时间不建议很长，只要是查漏补缺，每个人都会有一些测试思路，也会发现已有的测试用例的不足。
（3）、根据会议记录，将没有考虑到的点维护成测试用例。定版。
定版后的测试用例，就可以用来执行测试了。
缺陷，最重要的是，清晰明了的说明问题，重现步骤，以及如何解决。
效率的提高在于细节，缺陷管理工具上写的不明了，也可以通过实时沟通来解决，但是沟通就需要时间，如果缺陷管理工具上，写的很清晰明了，这沟通的时间成本就节省了。
一个缺陷就是一个用例，这个思想很重要，我经历的公司，对于缺陷都是放在管理工具中，缺陷解决后，关闭，就没有然后了。其实每一个缺陷都是一个优秀的用例，这些用例你可能已经写了，也可能没有，而没有的话，就需要维护到测试用例中去，下次执行时，你就多预防一个点。
通常，通过测试的功能就会准备上线。但是上线前，还需要产品或者运营，来验收需求。功能实现是否满足需求，有没有未考虑到的功能等等。产品或者运营做验收测试时，我会给一个EXCEL文档，作为他们记录问题的LIST，每天跟我反馈下进度跟结果。如果有缺陷，再安排时间去解决。如果有需求上的缺陷，会定会议评审，在这次发布修改，还是下次发布修改。最后，上线与否，需要他们的确定。
创业型公司，产品版本迭代快，周期紧，往往压缩的是测试时间。而测试质量在一定程度上，与测试时间成正比，所以这点很矛盾。
测试时间需要争取，因为项目时间很紧，资源更多的用于开发，上线时间确定后，基本上离上线时间只有2天时间才开发结束，才交付测试。而这么短的测试时间，要保证测试质量很大，并且可能还需要大量加班。而测试时间的争取，又需要测试质量作为依据。那么怎么来争取测试时间呢？我认为是这样的：
（1）、尽量在开始时，哪怕加班也要做好质量保证，之后在争取时间的时候，可以尽量拿质量作为理由来说；
（2）、平常要多跟项目经理，架构师等聊聊产品质量，输送质量意识，并多讲讲测试的重要性，不是每一个开发或者负责人，对于测试很重视的，尽管现在测试行业在快速发展。
（3）、就是在测试时间上，坚决不让步。上线后，产品出现问题，很多时候，会让测试背锅，当然也有开发的原因，但是大家的想法是：这个问题怎么没有测试到？这个时候，你再说测试时间不够，意义就不大了。
测试时间的安排，需要根据测试人员本身能力定。能力强的，当然需要的时间短。大体上而言，我对于测试时间的安排如下：
（1）、模块内（模块间交互少）的功能，需求分析时间和设计测试用例的时间为1天，执行测试的时间为2天（主要是缺陷修复时间），最后验收时间为半天。
（2）、模块间交互多的功能，需求分析和设计测试用例各1-2天，执行测试时间4-5天，最后验收时间为1天。
（3）、系统级的功能需求，需求分析3天及以上，设计测试用例时间2-3天，执行测试时间一周以上，最后验收时间为2-3天
主要策略是，需求分析的时间得保证，这个时间不能挤，毕竟这是测试最重要的部分。设计测试用例的时间可以稍微挤挤，这块最主要的时间是需要写文档。测试时间多考虑缺陷修复时间，测试一轮下来可能很快，但是缺陷修复的时间就可能很久。最后需要验收时间，产品或者运维对于该功能的验收，看是否满足产品需求。
测试计划确定后，接下来就是测试进度的把控了。进度的把握不是实时的要求测试工程师反馈，也不是自己想了解的时候就去问一下。需要有这么一个规则，既可以直观的查询到目前的测试进度，又可以接受测试工程师的反馈。而我们团队的规则如下：
1、使用项目管理工具：Teambiton，任务板上有每一个测试工程师在这次发布前的任务，每一个任务都有详细的测试时间，能明了直观的看到任务的执行情况。
2、执行QC测试集：QC测试集，是基于测试用例的执行，每一个用例的每一个步骤都有执行状态，这样在测试过程中，就能实时的查看到当前测试的进度。这个最为准确。有没有偷懒，或者是否是应付式的工作都能看出来。
3、每天下班前，都会将今天的测试情况反馈给我。这一点准备改良，定为每天早上5-10分钟站会。每一个人都需要讲讲昨天干了什么，今天准备干什么。时间长了，站会可以提高整个团队的效率。
4、每天早上跟每天下班前，都需要检查一次缺陷管理工具，查看今天已解决尚未验证的缺陷是否已经处理完了。
如果出现测试进度很慢，跟预期严重不符，会先跟相关测试工程师讨论，是预期时间不够，还是测试工程师本身的问题，还是开发工程师的问题。这个时候就是需要测试leader来解决了。找到相应的问题并解决它。
如果出现测试进度过快，也需要去确认，防止为了赶进度而忽略质量的情况。
行业内有一句话：测试不能保证软件质量。我认为，虽然我们不能保证软件质量，但是我们可以保证测试质量，尽量提高软件质量。
测试的质量，是测试活动最重要的一环，所有之前的一切都是基于提高测试质量为目标的。那么如何提高测试质量呢？
（1）、充足的测试时间。并不是时间越长越好。
（2）、全面的测试需求分析。
（3）、充分的测试用例设计。
（4）、测试人员的能力（管人篇详细聊）
（5）、做好验收测试。
（6）、风险控制
等等。
我一直都认为，不管测试多么精确，到线上后，都会存在问题。只是说测试可以尽量去减少这样的情况发生。
如果产品上线后，出现问题，怎么处理？
第一时间，在测试环境中，重现。能重现，则找相应的开发工程师解决，再评估上线时间。如果不能重现，就直接找项目经理，评估解决办法。
而一般而言，出现问题后，责任我会担着（这是一种得人心的方法），事后会跟相关的测试工程师去探讨出现这个问题的原因，是由于他自己引起的，就总结为什么，争取别在同一个地方跌倒两次，对于他而言，是一种成长和进步。
结语
以上仅仅是个人的理解。希望大家能多探讨。
标签：
原文地址：http://www.cnblogs.com/miniren/p/5336219.html
