软件测试管理（管事）

聊聊测试管理（管事篇）

 

管理：管人+管事。

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

管事篇

1、测试的工做流程。

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

 

一、需求分析

 

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

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

一文档：需求分析文档。

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

 

二、测试计划

 

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

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

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

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

（3）、测试执行人：创业型公司因为人员少的状况，极可能以项目（模块）划分测试负责人，也能够根据设计和执行来划分测试负责人

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

 

三、测试用例

 

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

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

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

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

 

四、测试用例评审

 

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

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

测试用例评审方法：

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

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

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

定版后的测试用例，就能够用来执行测试了。

 

五、缺陷管理

 

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

效率的提升在于细节，缺陷管理工具上写的不明了，也能够经过实时沟通来解决，可是沟通就须要时间，若是缺陷管理工具上，写的很清晰明了，这沟通的时间成本就节省了。

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

 

六、验收测试

 

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

 

2、测试时间

 

一、争取测试时间

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

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

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

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

（3）、就是在测试时间上，坚定不让步。上线后，产品出现问题，不少时候，会让测试背锅，固然也有开发的缘由，可是你们的想法是：这个问题怎么没有测试到？这个时候，你再说测试时间不够，意义就不大了。

 

二、安排测试时间

测试时间的安排，须要根据测试人员自己能力定。能力强的，固然须要的时间短。大致上而言，我对于测试时间的安排以下：

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

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

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

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

 

3、测试进度与质量

 

一、测试进度

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

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

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

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

四、天天早上跟天天下班前，都须要检查一次缺陷管理工具，查看今天已解决还没有验证的缺陷是否已经处理完了。

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

若是出现测试进度过快，也须要去确认，防止为了赶进度而忽略质量的状况。

 

二、测试质量

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

测试的质量，是测试活动最重要的一环，全部以前的一切都是基于提升测试质量为目标的。那么如何提升测试质量呢？

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

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

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

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

（5）、作好验收测试。

（6）、风险控制

等等。

 

4、线上跟踪

 

我一直都认为，无论测试多么精确，到线上后，都会存在问题。只是说测试能够尽可能去减小这样的状况发生。

若是产品上线后，出现问题，怎么处理？

第一时间，在测试环境中，重现。能重现，则找相应的开发工程师解决，再评估上线时间。若是不能重现，就直接找项目经理，评估解决办法。

而通常而言，出现问题后，责任我会担着（这是一种得人心的方法），过后会跟相关的测试工程师去探讨出现这个问题的缘由，是因为他本身引发的，就总结为何，争取别在同一个地方跌倒两次，对于他而言，是一种成长和进步。

 

结语

以上仅仅是我的的理解。但愿你们能多探讨。