给中小型研发团队的测试人员的建议

给中小型研发团队的测试人员的建议

 apiaoqzh 关注

2017.08.06 17:33* 字数 3312 阅读 965评论 0喜欢 3赞赏 1

前言

当下可谓是前无古人的一场互联网大潮，具体意义我也就不在此阐述了。就在这个时代，开发这个行业几乎是蓬勃发展，打开各种招聘平台，满屏都是关于PHP，JAVA，前端等岗位的招聘信息。同样的，各种各样的平台的发展，也促进了各式各样的开发人员、团队的发展，技术也在不断地更新迭代，也不断地有新人加入这个圈子。

本人经历过多个开发团队，担任过前端开发、测试、测试开发等岗位，不难发现，其实在这种欣欣向荣的大环境下，非常悲观的是有非常多的开发团队及项目对测试这个工序投入得并不足，同样的也导致了软件质量相对低下、返工率高等问题。而这种情况却多出现于中小型企业及研发团队中。

由此，我们在本文中对此进行一次分析。

一.现状

在大多数的中小型研发团队中，项目进行过程中可能会遇见这么一些问题：工期短，需求变动大，开发人员间对接问题多。

工期短，可以说这个问题是硬伤，其最大程度上导致了开发的囫囵吞枣以及测试的投入不足等问题。

需求变动大，经常在工期不变的情况下，需求变更幅度越大，实际有效工期越短，从而引发了死循环。

开发人员对接问题多，这里需要考虑到不同开发人员具有不同的风格这种因素，可能会出现前端开发完毕后，对接后端的数据源发现后端数据源并不是设想中的情况，需要耗费大量的交流成本和返工的时间成本来解决每一个对接问题。也是导致了实际有效工期被压缩。

实际有效的工期被不断地压缩压缩再压缩，按照大部分的研发团队的惯性思维：测试是开发完毕后才进行的工作。那么一个项目中测试所能投入的时间可能会变得非常少，可能只能占整个项目周期的10%不到的时间。

这里可以给出一个亲身经历：

某年五月，本人担任测试岗位，与公司另外两位测试同事一起经手公司项目的测试。在测试工作展开之前发现了以下问题：

1.测试时间非常得短，整个项目的开发工期只有两周，一直到测试催促开发方给出测试地址多次后才获取到能够进行测试的版本。而此时离上线不过剩余12个小时。

2.产品方并未将产品需求给到测试，测试方不知系统到底解决什么问题，实现什么功能。

3.因为没有事先准备，测试工作在无用例，无计划，无技术支持的条件下进行。

最终测试共进行了12个小时，无论是产品、测试、开发都是通宵工作，可是直到产品上线后，依旧遗留了部分的问题待解决。而大家已经无多余的精力去解决这些遗留问题了。

测试开展过程中也是发现了诸多的问题，如：

前端开发人员和后端的接口在开发前未定好规则，因此对接的时候出现了字段对接错误或者字段缺乏等问题。

测试人员的技术底子不够，发现问题只能简单的阐述问题的描述以及重现方法，而不清楚问题到底是出现在前端开发者或者后端开发者身上。甩错锅而导致缺陷年龄无端拉长。

在项目成型后进行测试，发现问题后解决问题的代价会根据问题根源出现的阶段而加大。例如：项目成型后，发现需求中有个功能漏了，导致需要在已成型的功能中加入一个漏了的功能。设计过程中，设计图中缺漏或者写错了一个模块，从而导致后面所有代码几乎都要翻看并修正。

项目的功能越多，接口越多，测试的成本就越大，后期测试几乎需要在找错，跟踪，回归等工作中来回奔波，过去测过的接口可能需要重新覆盖一次。分散了大量的精力。

从上面的例子里可以看出其实我们研发团队存在的问题：开发缺乏规范、测试投入阶段不够全面、测试人员素质不足、测试缺乏强有力的技术及工具支撑。

二.建议

发现问题当然就要解决问题了。

1.确立规范

开发展开之前，确立一个多方都遵守的规范是重中之重，如何确保一个团队做一系列的功能，对接上的问题又能够降到可接受程度呢。最好的办法莫过于整个项目一个人做。当然这个办法不可取。此外最好的办法就是用规范让所有人的产出都如同一个人产出一样标准。规范是最好的选择。

这里建议规范的制定过程中，测试人员必须参与，甚至开发过程中验收规范必须先由测试人员进行查验。

规范在这里可以泛指：接口数据结构、数据库表设计等文档，可能根据项目要求或者团队的成熟度会变得更多，更复杂。

确立规范有如下好处：各个需要协同的开发人员之间的交流成本降低了，确保规范相关文档各位都熟读且理解后，各方即可根据规范分头开发，最终进行整合，能够有效降低对接时的问题出现几率，从而降低风险。

同时规范对测试人员也有非常重要的好处：测试人员可以在开发阶段依据规范来对各个开发的产出进行校验，确保问题不会出现在对接时期，降低了对接时的问题出现几率。

2.测试驱动开发

确立了规范后，上文说过，规范可以作为测试人员测试校验参照物，通过对规范的校验，验收各个开发的产出，同时在这个基础上，深入到一些业务功能的测试。如，设计中后端需要实现一个可供查询数据的列表，规范中确定了该数据列表的数据结构及字段，测试在开发完毕后对该接口进行查验，再根据这个接口的数据交互进行业务上的测试，当这个功能通过了测试的审查，这个功能就可以通过。这可以说是测试驱动开发的其中一个体现。

测试驱动开发中，测试作为一个标杆的存在，开发人员编写能够让测试人员测试通过的代码，并交由测试进行测试，由测试来推动开发的过程。

3.提高测试人员的素质

在大多数具有一定规模的开发团队中，会发现测试人员其实大多不熟悉开发的流程及开发的技术。比如常见的测试团队，大多都是通过大量的人力手工对项目进行操作，根据事先录好的用例一个个进行覆盖，并将与用例预期结果不符的实际情况记录下来。这种工作方式优势在于测试的覆盖面广，更接近于真实的用户，人数优势能够在一定程度上降低测试的时间成本。

而这种测试流程，特点就在于人多、测试人员的技术门槛低，甚至于有些企业在这个方面几乎是无门槛。从而也会导致以下问题：测试人员不了解开发的过程和技术底蕴，导致出现问题的时候不知道是什么问题，谁的锅，因而甩错了锅，白白浪费时间。同样的，开发人员会获取到无数的问题，这些问题大多存在于表象，需要开发人员花费时间去重现该问题，也是耗费了一定的时间成本。

测试不懂技术，会导致测试并不能在根本上推动开发的过程。

例如：测试人员发现页面上，列表中缺少了手机号码的数据。这种问题一般测试是非常容易直接把缺陷指派给前端的，因为大多数问题都会直接在前端中体现出来。而如果说深入排查，发现其实是后端接口中并未给出这个字段，那么这个问题理应是要指派给后端开发工程师。这里价值忽然就体现出来了。而能够实现这个过程的测试，是需要经过一系列技术和经验的积累的。同时也是降低了排错的成本，更深入的测试能够更深入地找出根源问题。

提高了测试人员的素质，测试人员对技术的了解程度越深，越可以进行一些更为接近开发的测试工作，测试能够覆盖的阶段越前，发现问题也就越及时。如果100个问题分散在整个开发阶段中间发现，甚至一发现就能够立马解决而不会影响其他部分，是一定会比开发完毕后发现100个问题，再翻开代码一个个修正的代价要低非常多的。

4.采用有效的工具

上文中所说，测试如果能够更加深入到技术中，能够带来更高的价值。那么如何深入呢？

当然是需要借助工具。

测试人员在测试过程中，按原则是不允许直接动代码的。如何去测试开发人员的代码，就必须要借助到各种各样的工具。

例如：接口测试一般情况下是采用postman这种非常适合用于接口调试或者测试的工具。它能够模拟一个前端的客户端对接口进行请求，并输出请求的响应数据。测试可以通过这个方法来对后端接口进行一对一的测试。当然这类工具还有非常多。

前端测试，非常常见的办法就是采用浏览器的控制台，俗称f12.根据这个控制台，测试人员可以在dom节点，网络请求等不同维度对项目进行测试和监控。

当然不同的平台一定会有它非常好用的测试工具的。

这里如果有能力、有投入的预算的话，可以考虑采用自动化的工具或者平台。自动化的意义在于能够降低人工成本，其具体体现在，录入了一定数量的测试用例后，可以让它自动执行，并在远低于人手工执行测试的时间内，给出测试报告。

这里建议，如果一个项目刚开始，可以在开发前根据规范定制自动化脚本，开发人员可根据自动化的报告进行开发，测试人员可对一些自动化不能覆盖到的用例进行测试。这样测试人员的人工成本能降到非常低。人手工测试可主要投入到后期的黑盒测试中。