在谷歌搜索引擎中输入"如何选择一种测试工具？" ，你会发现答案从开源软件到各种基于不同假设的最佳繁衍物，五花八门。一类结果是假定在理想状态下你需要一个不需要编码的、基于GUI界面的测试工具，而另一类结果宣称是可以编码的自动化测试，第三类则是更加感兴趣于测试工具中的例子和文档是否可被执行。

Liquidity Services公司的质量和测试主管Connor Roberts曾说过，有时公司引入或更换测试工具，仅仅是因为新上任的经理在上一家公司有此工具的使用经验，或者为了节省开支，使得预算单上的数据看起来更漂亮。Connor Roberts说：最终每天都使用工具的团队发现自己和以前一样沮丧，只是特点轻微不同而已。追究其失败的原因是没有询问这个工具是否真正的解决了团队需要解决的问题。

通常来讲，工具的选择都是低于最优标准的，那么我们如何正确选择工具呢？以下是选择功能测试工具的7个关键因素。

1、缺陷种类

你发现了什么严重缺陷？这些缺陷在哪里被发现的? 这个问题太容易回答了。大部分拥有缺陷追踪工具的团队可以在一顿饭的时间内找到答案。这种测试方法可能会找出在业务逻辑、数据层或图形用户接口（GUI）的大部分缺陷。

若很多重要的缺陷出现在GUI界面中，那么通过单元测试来对业务逻辑进行测试自动化的方法将不会有更多的价值，这肯定不是我们首先开始的地方。

尽管这是第一个问题，但也有可能是最后一个问题。一旦选定了工具，再重新回到这个问题。回顾最近在测试和生产中发现的相关缺陷，然后扪心自问，这个工具是否能够真实的捕获到这些种类的缺陷。如果答案是"可能不"或者更糟糕，那么请重新进入工具选择的流程。

2.适合团队

接下来的问题可能是:谁将要做自动化测试？若是开发或者测试开发人员，那么这个工具可能会是一个代码库或者代码包。同样的，若面对一群非技术专业的测试人员，那么带有可录制和回放界面的工具将会令人非常舒服。

有些工具提供了两全其美的方法：可以录制你的操作然后创建代码，或者创建一个前端画面，允许开发人员窥探画面背后的代码。

这里的主要问题是：渴望学习此工具的人需要有意愿、有能力并且有时间去做这件事情。如果测试过程滞后，分配测试人员去学习一个新的工具将会增加工作量，延缓将来的软件交付过程。

如果集成测试过程需要几天或者几周的时间，那么自动化测试特别是前端的自动化测试在达到盈亏平衡点之前将会延缓测试进度并制造冗余工作量。即使在达到盈亏平衡点之后，工具不会延缓测试进度，之前积压的未完成的事情也是需要被清理的。

当然如果是一个新项目，或者公司想要雇一个新人来做测试工具的工作，这个反对的理由就不适用了。所以我们要分析：如何将工具添加到团队中，添加工具会打乱什么秩序，谁来做这个工作，这些人是否有能力并且有时间来做这个工作。

3.程序语言和开发环境

若工具可以使用编程语言，有两种方法：使用一种非常强大的易于学习的高级语言，例如Ruby，或者使用开发程序所使用的语言。

Curtis Pettit是Huge Inc.（一个数字媒体机构）公司的高级测试工程师，他最近推荐使用第二种方法。

就开发语言来讲，我喜欢和开发保持一致。这使得我在提交代码之前更容易获得代码评审，也容易在他们的机器上运行测试。---Curtis Pettit说

若测试语言与产品开发语言相同，在持续集成运行周期内运行测试，可能会发生错误需要开发人员来修复。甚至更好的，这个工具可以作为开发使用的集成开发环境的一个插件来运行，来最小化开发为来回切换工作所必需付出的工作量。

若工具运行在集成开发环境之外并且使用不同的程序开发语言，开发人员不可能学习新工具或当工具报错时他们也不能提供工具的支持工作。

4.搭建测试数据管理进程

最近我一个客户购买了一个拥有30天试用权的大众流行的自动化测试工具。他们公司有三种测试环境，大家使用共享的测试用户帐号，一旦账号的顺序被创建，就没有一种简单的方式来删除它。这个顺序是可以被取消的，但取消后的顺序会作为第一个最早出现的数序继续出现在 "今日顺序"的主屏幕上。一旦系统创建10个顺序，新的顺序将不会出现在前端页面上。

冒烟测试过程中创建了3个顺序，这意味着每天运行3次。

在试用期满前几天我们取得了很大的进步，花费了几千美元来购买工具和相关的培训资料。可问题来了，我们无法从命令行中清除数据或者在重新创建新的账户-这些需要通过管理员帐户来驱动。

在此实例中，"正确的"工具可能涉及到一些功能：创建用户，清除顺序，导出用户以及作为"已知的好的测试数据"来关联顺序，然后重新导入顺序。这个将允许测试人员每次都是从一个已知的好的测试数据搭建开始。

这些会立即加速整个测试进程，包括原来的那些人正在做的工作。

另一个提升是能跟据分支或提交按需创建测试服务。至少追求持续集成的团队，想端到端地验证其是持续集成的一部分时一般需要创建这个测试服务。

若在测试过程中最大的瓶颈是搭建，或者重复的验证工作离开自动化是不可能搭建的，那么正确的功能测试工具可能就是自动化的测试搭建工具。

5.版本控制和持续集成

大多数想要避免自动化延迟的团队最终会把工具放入持续集成的进程中。也就是说，持续集成系统检出代码、执行构建、运行单元测试，并创建一个实际的服务器（如果需要的话）和一个可能会将软件放到移动设备上的客户端。然后持续集成系统开始使用功能工具进行端到端的测试。

持续集成下的测试产生一个新的需求：测试需要对代码进行版本化。当创建新的代码分支时，我们会创建一个新的测试分支。这样，具有多个"正确"定义的多个持续集成管道可以同时运行。

这意味着该工具需要从命令行运行并生成持续集成系统可以解释的输出。或者至少需要捕获输出并将其转换成持续集成系统可以读取的内容。许多持续集成系统可以向股东展示漂亮的仪表盘和饼图结果。要想使用它们，数据首先要脱离工具然后在进入持续集成系统。

工具一旦运行在持续集成环境下，它的内部动力就会给违规的程序员发送错误报告。这在跟踪是谁提交故障代码时会发生，然后程序员调试代码，给测试结果标绿或者修复代码。如果程序员熟悉测试语言并且测试语言是被团队支持的或者测试结果是以纯文本形式存储的话，那这个就很容易做到。即使测试结果存储在版本控制中，它也很难区分二进制格式的文件之间的差异。

6. 报告

若测试工具没有对使用者输出有意义的东西，那么它就是一项糟糕的投资。除非团队想要把测试结果推到另一个系统以获取更好的测试报告，否则仪表盘和图表的功能可能就没用。

随着时间的推移跟踪测试也可能是一个非常强大的功能。不同层次的股东关心不同的结果。高水平的主管可能并不想知道成功失败比率的走向；中层管理人员希望了解工作流程；技术人员希望深入了解特定测试中出错的细节，如果可能的话，观看执行的视频。

7.支持的平台和测量

这似乎很明显，如果测试工具不能运行在所有团队所支持的平台和级别上（如Web、移动Web、ios原生、Android原生、API、单元等），那么团队将要承受各种风险，这将会导致团队付出更多的支持。

大多数平台都有类似的用例：登录、搜索、显示产品页面、标签、结帐等等。对端到端测试工具，它的一种常见的用法是创建一个"页面对象"，其中包含描述为函数的公共特性。自动检查模块调用这些函数。页面对象是在运行时被创建的，因此可以复用购买路径来对每个设备进行检查；换句话说，您可以针对不同的页面对象运行相同的测试。

某些特性没有重叠，它们只存在于全尺寸Web版本的产品中。

标签是跟踪哪个测试运行在哪个浏览器中的一种方式。还会通过注册页面对象来了解所需的页面对象类型是否存在在本次测试中。

有了标签之后，就可以指导工具"运行所有在edge浏览器上的全尺寸测试"，或只做前端测试，或只进行后端测试，或只测试某个API，或只进行概要测试等等。

如果该工具具有不同级别的平台支持，团队也支持多个平台，那么该工具将需要跟踪和运行所支持的子集。通过功能来对测试进行标签标记，并且快速的重新运行某个功能的所有测试，这个功能也许是放在桌面上准备马上提交代码的，在加速交付过程中这是降低风险的有效方法。

还有该软件可能是国内的，其只支持一个平台，也可能以某种方式耦合在一起，这就使得标签的作用不是很有价值了。

综述

测试工具主要集中在框架、自动化工具和跟踪方法三个方面。有时框架和工具融合在一起，事实上它仅有这一种选择，其他时候该框架允许用户插入多个工具。

无论是对所有的测试选择一种工具（JUnit）还是选择工具组合来满足不同风险水平（单元、集成、端到端）、不同平台和不同技能水平的测试，答案一样简单。

所以观察团队目前试图解决的真正问题，然后针对那些风险、团队拥有的工作技能并结合工作流程和技术栈来尝试选择一种工具。如果可以的话，尽量多尝试一些工具避免锁定。

几个月后，该工具将融入你的工作过程，所以你最好确保工具是你喜欢的，就像摇滚歌手Stephen Stills唱的一样，喜欢与你在一起的。

版权声明：本文出自《51测试天地》原创测试文章系列（四十八）投稿。51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。