测试管理（二）

管理：管人+管事。

说到管理，其实就是团队，没有团队，就谈不上管理。个人理解，对个人而言，更多应该是计划，而非管理。做管理的时间并不长，或者说很短，可能很多地方理解的有问题。写这篇文章也是为了能更多的与大家交流，也是记录下在目前这个阶段我的理解。(本文均以在创业型公司工作为背景)，全篇分为管事篇跟管人篇。

管事篇

一、测试的工作流程。

关于这个点，其实网络上一搜一大堆，大体都差不多，需求分析，测试计划，设计测试用例，评审用例，执行测试，缺陷管理，定版，发布。但是，我认为作为一个测试leader，在一个创业型公司，并不是出一个这样的流程这么简单。我觉得更多应该考虑的是适合公司的。在我制定我们团队的测试流程时，与我们的项目经理，架构师甚至产品经理都有过很长时间的沟通，测试活动离不开产品，开发，所以在测试的工作流程中，应该包括如何去产品，开发更高效的去协作。下面讲讲我整理的测试工作流程。

1、需求分析

黑盒测试离不开需求分析，所有的测试都是基于需求，如果对于需求的理解不够透彻，测试的质量也就可想而知。所以在这个阶段，我会花很大量的时间去做。我团队的需求分析主要包括：两图一文档。

两图：业务流程图，思维导图。

一文档：需求分析文档。

业务流程图，是对于需求从流程（整体）去理解。思维导图，是对需求所包含的各项功能点去理解。需求分析文档，是对思维导图中的功能点去发散成为测试点。这样下来，一个需求所表达的内容，基本不会漏掉。而更高层次的隐性需求，就需要对业务有着很深的理解，这点可以在工作中慢慢去引导团队成员去做。流程上很难去控制。

2、测试计划

网络上的测试计划，都是一个文档，一大堆形式上的东西，可能对于大公司而言，有这个必要，我目前所见识的，基本都没有必要。

我认为测试计划主要给出以下几点：

小公司团队

（1）测试类型：黑盒测试，接口测试，UI自动化测试，接口自动化测试，性能测试等等

（2）测试时间：需求分析起止时间，设计测试用例的起止时间，执行测试的起止时间

（3）任务：将测试活动拆分成具体的任务

（4）测试执行人：创业型公司由于人员少的情况，很可能以项目（模块）划分测试负责人，也可以根据设计和执行来划分测试负责人

（5）风险控制

一个测试计划，有这5点，我个人认为就可行了。

中大公司团队

　　大公司测试团队往往是涉及多个项目，整个公司的硬件、时间、人力等资源的分配就更为复杂。在这种情况下，需要对各方面有更为精细的计划。

　　· 资源估算：整个项目需要多少资源？硬件资源，人力、时间资源等

　　· 进度控制：每个测试活动时间点控制

　　· 风险控制：对于在测试活动过程中出现问题的解决方案

　　· 资源配置：如何更有效率的使用资源

　　· 验收标准：文档、项目、测试过程的验收标准定义

　　· 测试策略：测试中使用的测试策略

3、测试用例

（1）关于设计测试用例，可能很多在创业型公司工作过的小伙伴会说，时间很紧，压根没时间来做这个事。

这一点，我用了两个月做了一个调研，前一个月不写测试用例，大家就按照自己的思路去测试；后一个月，严格写测试用例，执行测试集去测试。调研结果是：前一个月在测试开始时，测试速度稍微快点，在进入测试中后期，测试速度就很慢很慢，因为常见点已经测试完了，测试工程师自己都不知道哪些东西测试过了，哪些还没？哪些没有问题，哪些还有问题？不能很直观的去管控。后一个月在开始时，由于写测试用例的时间，速度会稍微慢点，但是在中后期，测试效率明显比前一个月要好很多，测试工程师对于项目的把握也更清楚。两者整个花的时间基本差不多。质量就更不用说了，肯定后者更有保证。

探索性测试，我觉得在业务能力以及测试经验都很充足的情况下，可以结合编写测试用例，去执行测试。一味的追求探索性测试，其实对于大多数测试工程师来讲，很难。

目前，我的团队是，测试工程师编写好测试用例，先组内评审，然后导入到QC，测试人员根据QC测试集去执行测试，而我也能很直观的把控测试进度，以及当然存在的问题。

（2）如果迭代较快，时间比较紧张，可以使用xmind将每个分支列出来，到了具体执行的时候再去看结果，这个时候要追求测试用例需求覆盖率。

4、测试用例评审

用例评审很重要，毕竟测试工程师也是人，也会有很多点是想不到的，所以用例评审就是一个查漏补缺的环节。用例评审不是找人茬，而是在这个过程中，补充测试思路，提升测试质量。

年前，这一项，我们没有做，因为当时我们的测试工程师写的用例还达不到评审的水平，所以只是组内评审。目前已经启动用例评审。效果还待观察中。

测试用例评审方法：

（1）、提前邮件提醒评审相关人员（开发负责人，产品负责人，测试负责人，项目经理等），附件上测试用例。

（2）、1-2天后，组织用例评审会议，由于事前有看过需求跟用例，所以会议时间不建议很长，只要是查漏补缺，每个人都会有一些测试思路，也会发现已有的测试用例的不足。

（3）、根据会议记录，将没有考虑到的点维护成测试用例。定版。

定版后的测试用例，就可以用来执行测试了。

5、缺陷管理

（1）缺陷，最重要的是，清晰明了的说明问题，重现步骤，以及如何解决。

（2）效率的提高在于细节，缺陷管理工具上写的不明了，也可以通过实时沟通来解决，但是沟通就需要时间，如果缺陷管理工具上，写的很清晰明了，这沟通的时间成本就节省了。

（3）一个缺陷就是一个用例，这个思想很重要，我经历的公司，对于缺陷都是放在管理工具中，缺陷解决后，关闭，就没有然后了。其实每一个缺陷都是一个优秀的用例，这些用例你可能已经写了，也可能没有，而没有的话，就需要维护到测试用例中去，下次执行时，你就多预防一个点，对之后的测试就可以提供思路

（4）量化bug统计

怎么样提出质量高的缺陷？怎么样对缺陷进行管理和分析？见下图

 

 

 

 

 

6、验收测试

通常，通过测试的功能就会准备上线。但是上线前，还需要产品或者运营，来验收需求。功能实现是否满足需求，有没有未考虑到的功能等等。产品或者运营做验收测试时，我会给一个EXCEL文档，作为他们记录问题的LIST，每天跟我反馈下进度跟结果。如果有缺陷，再安排时间去解决。如果有需求上的缺陷，会定会议评审，在这次发布修改，还是下次发布修改。最后，上线与否，需要他们的确定。

二、测试时间

1、争取测试时间

创业型公司，产品版本迭代快，周期紧，往往压缩的是测试时间。而测试质量在一定程度上，与测试时间成正比，所以这点很矛盾。

测试时间需要争取，因为项目时间很紧，资源更多的用于开发，上线时间确定后，基本上离上线时间只有2天时间才开发结束，才交付测试。而这么短的测试时间，要保证测试质量很大，并且可能还需要大量加班。而测试时间的争取，又需要测试质量作为依据。那么怎么来争取测试时间呢？我认为是这样的：

（1）、尽量在开始时，哪怕加班也要做好质量保证，之后在争取时间的时候，可以尽量拿质量作为理由来说；

（2）、平常要多跟项目经理，架构师等聊聊产品质量，输送质量意识，并多讲讲测试的重要性，不是每一个开发或者负责人，对于测试很重视的，尽管现在测试行业在快速发展。

（3）、就是在测试时间上，坚决不让步。上线后，产品出现问题，很多时候，会让测试背锅，当然也有开发的原因，但是大家的想法是：这个问题怎么没有测试到？这个时候，你再说测试时间不够，意义就不大了。

2、安排测试时间

测试时间的安排，需要根据测试人员本身能力定。能力强的，当然需要的时间短。大体上而言，我对于测试时间的安排如下：

（1）、模块内（模块间交互少）的功能，需求分析时间和设计测试用例的时间为1天，执行测试的时间为2天（主要是缺陷修复时间），最后验收时间为半天。

（2）、模块间交互多的功能，需求分析和设计测试用例各1-2天，执行测试时间4-5天，最后验收时间为1天。

（3）、系统级的功能需求，需求分析3天及以上，设计测试用例时间2-3天，执行测试时间一周以上，最后验收时间为2-3天

主要策略是，需求分析的时间得保证，这个时间不能挤，毕竟这是测试最重要的部分。设计测试用例的时间可以稍微挤挤，这块最主要的时间是需要写文档。测试时间多考虑缺陷修复时间，测试一轮下来可能很快，但是缺陷修复的时间就可能很久。最后需要验收时间，产品或者运维对于该功能的验收，看是否满足产品需求。

三、测试进度与质量

1、测试进度

测试计划确定后，接下来就是测试进度的把控了。进度的把握不是实时的要求测试工程师反馈，也不是自己想了解的时候就去问一下。需要有这么一个规则，既可以直观的查询到目前的测试进度，又可以接受测试工程师的反馈。而我们团队的规则如下：

1、使用项目管理工具：Teambiton，任务板上有每一个测试工程师在这次发布前的任务，每一个任务都有详细的测试时间，能明了直观的看到任务的执行情况。

2、执行QC测试集：QC测试集，是基于测试用例的执行，每一个用例的每一个步骤都有执行状态，这样在测试过程中，就能实时的查看到当前测试的进度。这个最为准确。有没有偷懒，或者是否是应付式的工作都能看出来。

3、每天下班前，都会将今天的测试情况反馈给我。这一点准备改良，定为每天早上5-10分钟站会。每一个人都需要讲讲昨天干了什么，今天准备干什么。时间长了，站会可以提高整个团队的效率。

4、每天早上跟每天下班前，都需要检查一次缺陷管理工具，查看今天已解决尚未验证的缺陷是否已经处理完了。

如果出现测试进度很慢，跟预期严重不符，会先跟相关测试工程师讨论，是预期时间不够，还是测试工程师本身的问题，还是开发工程师的问题。这个时候就是需要测试leader来解决了。找到相应的问题并解决它。

如果出现测试进度过快，也需要去确认，防止为了赶进度而忽略质量的情况。

2、测试质量

行业内有一句话：测试不能保证软件质量。我认为，虽然我们不能保证软件质量，但是我们可以保证测试质量，尽量提高软件质量。

测试的质量，是测试活动最重要的一环，所有之前的一切都是基于提高测试质量为目标的。那么如何提高测试质量呢？

（1）、充足的测试时间。并不是时间越长越好。

（2）、全面的测试需求分析。

（3）、充分的测试用例设计。

（4）、测试人员的能力（管人篇详细聊）

（5）、做好验收测试。

（6）、风险控制

（7）、测试人员都应该持续反馈，改进、总结每个版本中遇到的问题，不管是缺陷还是流程问题，从一次次的问题中总结一些经验，提高整个软件生命周期的质量

等等。

四、线上跟踪

我一直都认为，不管测试多么精确，到线上后，都会存在问题。只是说测试可以尽量去减少这样的情况发生。

如果产品上线后，出现问题，怎么处理？

1、第一时间，在测试环境中，重现。能重现，则找相应的开发工程师解决，再评估上线时间。（问题不严重）

2、不能重现，就直接找项目经理，评估解决办法。

3、如果线上出现的问题很严重，就必须要系统回滚，保证线上用户的正常使用（系统回滚方案须跟开发/项目经理确认）

4、线上功能检查：程序原有功能的回归测试、新上线的功能全面测试

5、而一般而言，出现问题后，责任我会担着（这是一种得人心的方法），事后会跟相关的测试工程师去探讨出现这个问题的原因，是由于他自己引起的，就总结为什么，争取别在同一个地方跌倒两次，对于他而言，是一种成长和进步。

6、使收集用户反馈的问题，并尽快组织人员评估和修复