应用测试工具帮助大家进行更有效率的测试，用更少的时间做更多的测试。另外，这些工具帮忙减少重复操作—代替人工干预—并且完成人工无法完成的测试，比如使用对于测试和软件开发企业而言通用的方式来补充或者编目，搜索并且组合信息。应用测试帮助企业抢在客户之前定位出产品所存在的问题。即使是一个小程序，所需测试的组合数量也会大得惊人。比如，一对嵌套循环，就能生成成千上万的不同的测试用例。

应用测试工具本身并不完成实际的测试工作。测试人员手工来完成测试，需要注意细节，同时能够基于收到的信息来区分出细微的不同之处和有意思的地方。可以编程来让测试工具运行一系列操作并且检查期待结果。这些工具可以帮助有经验的测试人员扩大测试范围。本文探讨测试工具的四大类型：自动化、基础架构和支持、bug跟踪，以及覆盖率。

质量保证和软件测试的区别

在讨论应用测试工具的主流类别之前，了解质量保证（QA）和测试的区别很重要，能够帮助更好得理解这些工具应该做什么以及不应该做什么。质量保证是为了保证构建过程是正确的。测试确保构建出正确的东西。质量保证意味着确保正确遵循了质量流程的每一个步骤，并且顺序也是正确的，从而避免问题的产生，每次都能得到相同的产品。测试主要是指在制造流程走完之后来检查产品的所有部分是否正确。这两者之间有明显区别，用来完成这两部分功能的工具也差异很大。

QA确保没有需求就不会创造任何代码；并且在最终测试开始之前确保所有代码都已经被审核——并且被批准；同时确保计划运行的测试都会运行或者已经运行过了。各个公司定义其工作流程模型，拥有QA职责的人要么检查所有步骤，要么可能在完成之后审核每个步骤，来确保团队完成了每一步并且检查了正确的东西。

如果软件QA工具确保产品被正确得构建，应用测试工具则帮助确保团队构建了正确的产品。因为每个软件变更请求都各不相同，软件QA注定要失败——工具可以帮助确保需求文档存在，但是不能确保该需求被完美实现了。

应用程序测试工具能够在软件构建的过程中，帮助软件团队确定软件的实际状态。我们一起看看测试工具的四大主流类型。

自动化

应用测试工具最广为人知的就是自动化工具，它们尝试来取代人力 ——让电脑完成点击并检查。测试自动化最常见的类型就是用户界面驱动的，用户记录一系列操作及其预期结果。用户界面自动化的两大常见类型是记录/回放这里一个工具记录下交互操作并且随后将这些操作自动化，期望得到相同的结果—并且是关键词驱动的—这里用户界面的元素，比如文本框和submit按钮，都被用名称来指代。关键词驱动的测试通常在某个编程语言里创建，但是不一定非得如此；可以在电子表格里记录元素标识符，命令，输入和预期结果。

自动化工具执行一系列计划好的场景，期望得到的预期结果，并且要么检查特定的屏幕区域—在记录/回放里—要么仅仅检查工具被告知的检查步骤—在关键字驱动领域。计算机永远不可能说“这看起来有点奇怪”，永远不会探索或者被某个测试激发出新的想法。计算机也无法注意到某个“错误”实际上是需求的改变。相反，测试自动化工具会记录每一次失败，测试人员需要去查看失败，分析出这不是个bug，并且“修复”测试本身。这会带来维护的重担。测试自动化只能自动化测试的执行和评估。

这一类测试的另一个术语是，Michael Bolton和James Bach称之为，检查——可以通过算法计算出是pass还是fail的决策规则。计算机可以做这样的工作，并且可以做得很好。在代码级别运行检查的自动化—单元测试—或者在用户界面级别，都能深远改进质量，并且在有人使用软件之前就迅速地发现明显的错误。

基础架构和支持

测试自动化假定应用的最新版本已经安装在计算机或者Web服务器之上。它仍然需要编译和安装，自动化测试需要启动，并且需要通知某些人去检查结果。所有这些任务都属于支持——这些也能够自动化。持续集成工具就是支持类工具，可以检测到新代码的check-in，从而开始构建build，创建一个新的虚拟Web服务器—或者更新某个staging服务器—将新代码交付到目标机器上，运行自动化来测试程序，检查结果并且用邮件将失败信息发送给相关团队。

支持包括测试人员使用的能帮助他们更快速或者做更多测试的工具。产生随机姓名作为输入，或者广义的测试数据的软件，以及创建屏幕截图和视频的软件都属于这一类别。这一类型的软件用来记录测试人员需要做的使用各种字段的所有交互，模拟移动设备和所需的开发环境，以及弹出窗口来记录备份。

Bug跟踪

对于很简单的软件而言，可以使用便利贴或者电子表格来跟踪bug报告。但是当软件更为复杂时，这就会变得很难用，公司就需要使用为解决此类问题而设计的专业软件。通常来说，专业的bug跟踪工具会报告bug的严重程度，优先级，发现问题的时间，确切的重现步骤，修复问题的人，问题在哪个build上被修复，以及提供搜索和标签的机制来帮助使用者找到某个defect。这些工具不仅仅能够帮助编程人员和项目经理；客户服务和已有用户也可以使用这些工具来查找某个问题是不是已知问题，是否已经计划修复，升级某个已知问题，并且汇报非已知问题。Bug跟踪工具也能够有助于工作流，因为可以将bug分配给编程人员，然后给测试人员重新检查，然后标记为待部署，并且在部署之后，标记为已部署。

覆盖率

当我们讨论软件测试领域的覆盖率时，我们实际在探讨两个领域的问题。

第一个领域是代码覆盖率，关注于被测试覆盖的软件的代码百分比。代码覆盖率最常见的类型是statement覆盖率，它是在测试流程运行过的statement的百分比——手动测试，自动测试或者两者。

第二个领域是应用程序覆盖率，从另外的维度查看测试流程——通常是，被“覆盖”的需求百分比。常见的应用程序覆盖率工具之一是一个可跟踪的矩阵——一个列表，列出哪些测试覆盖了哪些需求。通常来说，测试用例管理软件记录了所有计划的测试，并且允许测试人员为某个给定版本将某个测试用例标记成“已执行”，这使得管理层可以了解多少百分比的测试已经“被覆盖”了。这是一种“质量保证”，检查测试流程，和管理控制一起来确保应用程序的每个部分都被覆盖了。

最后，这四种类型的工具的每一种都能够帮助软件团队管理问题和代码变更。当组合使用这些工具时，团队就拥有了健壮的工具集能够帮助其定位bug，调试代码并且将团队从琐事中解脱出来，更多得去思考需要测试的领域。