提升测试工具开发的思考-Toy模板网

这篇具有很好参考价值的文章主要介绍了提升测试工具开发的思考。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

本文针对测试部效率提升测试工具开发、管理、维护暴露出来的问题的一些思考以及一些个人改进观点。

写在前面

本文提到的效率提升测试工具不是指的部门中固有的自动化测试工具，这里提到的测试工具统一指测试人员在工作之余自主开发用于期望替代重复、繁琐、耗时的手工操作的测试工具，开发的目的是希望提升测试工作效率。不是针对专业工具开发部门团队的测试工具。

测试工具管理暴露的问题

总体来说，测试内部发布的用于效率提升的测试工具整体质量不高，工具功能、性能、易用性、可维护性质量都不高。大部分测试工具通常都是谁开发的谁用的比较顺手，工具推广度不高。并没有真正让部门其他测试人员效率得到提升。针对这些问题简单调研了一下身边的同事原因，主要以下几个问题。

1、工具不知道从哪里可以获取。这是测试部工具管理的问题。没有统一的发布路径、测试人员不知道当前测试部都有哪些测试工具可以用，不知道从哪里可以获取到。

2、工具不会用。测试人员拿到工具不知道怎么使用。对一些相对复杂功能的测试工具没有使用指导书、没有联机帮助。甚至有一些工具开发的菜单、标签、工具名称起的都很含糊。不知道这个工具是要干嘛的。这些通常都是测试人员在开发工具时不考虑工具的易用性问题导致其他测试人员很难上手使用。举个例子，测试工具开发人员用 Python开发了一个windows平台工具但是并没有编译成可执行的.exe程序发布，其他人很难用，首先可能要下载python程序、其他要下载程序依赖的各种类库。用个工具这么麻烦很多人就不想用了。。

3、工具不好用、经常出现问题。测试工具开发在实现工具时可能只针对某一个具体的场景、某一个具体的业务版本进行开发导致工具并不具备推广性。另外，一些工具交互太多甚至使用时有一些依赖外部条件需要设置程序才能正常执行等等都是导致不好用、没人用的原因。

4、工具很难维护（可维护性问题）。工具开发人员技能不一、能力高低有区别、对编码规范的遵循程度也不一样。实现工具开发的语言多样化，主流的开发语言Python、Java等还好，如果是AutoIt、vbs等这些比较少用的语言开发的工具后期维护就很麻烦甚至就没人维护了。另外，测试人员毕竟没有对编码规范有很好的理解，代码怎么写的都有、几千行代码注释几乎为0，也没有开发文档说明，维护起来特别困难。

5、工具需求开发随意、发布路径不统一、工具发布格式不规范。这也是管理的问题。工具没有统一的管理就会衍生出很多额外的问题。比如前文提到的不知道从哪里获取工具、工具没有指导书，我没有编码能力但是我识别出了工作中的短板需要开发工具可以把需求提交给谁。。等等。。这里，不是一定要强制某些工具不能开发，某些工具可以开发。从测试部整体角度来说，将工作量聚焦测试部topN效率短板提升的工具开发肯定是必要的。。

工具开发改进几点意见

上面暴露的问题在我呆过的很多产品都遇到过，并不是个例。针对这些问题的解决方法，谈一下个人观点。

1、工具统一管理。测试部内部发布工具开发规范、统一工具发布路径、工具发布格式（工具名称+版本号、工具主要功能、工具作者、工具维护历史、工具开发IDE等）。建议使用主流编程语言开发（Python、Java等），内部强调编程规范等。

2、工具开发提高易用性。一是减少交互而是方便交互。减少交互主要是指没有必要的输入或者可以固化的输入就集成到软件中，需要依赖的步骤也可以直接在工具中实现。方便交互主要是指在windows系统使用时尽量提供界面化形式的交互窗口。windows上使用的程序培养的习惯是这样。对于linux下，命令行交互没有问题，但是每一步的输入提示描述尽量简单清晰。尽量可以达到傻瓜式的使用。实现的时候就从这个角度考虑。你不期望你给别人工具还要教他怎么用吧。。

3、提高工具可用性。这是功能的问题。通常这些效率提升工具都是个人在工作之余花时间实现的，要求面面俱到也是很困难，但是尽量还是要保证主场景在绝大多数情况下运行正常，可以正常输出预期结果。不能换一个测试版本工具就出问题就好了，别人可能就不想用了。对于工具的完善可以在下一次迭代优化。这是每一个工具开发人员都是应该思考的问题。。你也不期望自己发布的工具别人一用就出问题。。对自己的形象也不好。。是吧

4、提高工具可维护性。要求不高，就是多加一些注释，代码自己觉得可读性还可以。函数/类尽量划分的合理。至少保证自己过半年一年再回来看自己的代码还能快速读懂修改就差不多了。。

5、工具定期宣传。定期挑选一些好用的、具有一定普遍性的工具进行推广。酒香也怕巷子深，每个工具开发作者也希望自己的劳动成果可以真正的让其他人受益，让自己的付出得到别人的认可。

6、编码技能交流。测试人员整体编码技能还是相对较弱，工具的开发主要还是集中在一小部分人身上。可以将这部分人员统一集中起来多交流、探讨。也可以在测试内部推一些编码基础培训课程或者是一些基础文章，可以帮助有兴趣提升编码能力的测试人员。