译者前言：
本文作者Alan Page（后面有作者简介）提出了一种将让自动化测试能更好的体现其价值的测试思维方法。而其中有意思的是文中的输入框的例子，分析过程属于“系统性思维”范畴，站在整体的角度来考虑单个控件的测试用例设计，从而发现一个测试用例设计的新角度。
我们会把自动化测试的一些坏味道归咎于缺乏培训、糟糕的测试工作或无能的管理等。无论是哪种情况，我不赞同的是许多测试人员的关于自动化测试的思路。我认为，目前测试界流行的一些自动化测试思路是错误的，在这篇文章中我将告诉你为什么。
自动化任务
测试工作中，普遍的观点是我们写一个自动化测试来模拟用户的输入，编写测试脚本把用户工作流程走一遍，然后验证和捕捉缺陷。
虽然没有这方面的具体统计数据，但是即使是带有偏见和控制的对网页文章的浏览中也可以窥见，我的观点并非无稽之谈。当用户执行“操作虽然没有这方面的具体统计数据，但是即使是带有偏见和控制的对网页文章的浏览中也可以窥见，我的观点并非无稽之谈。用户执行“操作”，软件则“输出”结果。测试人员则会想要：“确信软件运行的方式，能和用户使用它的方式一样”，但是其实我们并不知道用户会如何使用它。实质上，我们在做的是希望用户如何去使用它，然而我们所希望的在现实世界里都消失了。
在实现自动化用户场景上，常常引起讨论的是编写的自动化测试可否将替代对人类测试人员的需求。而自动化测试可以代替人类测试人员的想法是愚蠢的，基于以下的原因：
1、自动化测试是缺乏创造性和错误的。
2、为测试人员分配的任务是缺乏创造性和错误的。
我不仅发现验证和探索用户场景对于自动化测试是很糟糕的用法，而且发现要作为人类测试人员的最佳使用，这可能更糟糕。
我（太）经常看到测试人员谈论“人工”和“自动化”测试时，会把它们作为两个泾渭分明的活动，通常会由两个不同的独立小组来实现。然而，没有考虑到人工和计算机辅助设计的同步进行的问题，就不可能有良好的测试设计。
一种替代
自动化的能力并非在于自动执行用户任务（并非怀疑所有的价值，我承认有一类自动化测试是有价值的：编写简单的测试，定时运行跨多平台和操作性的测试，以确保兼容性等）。测试自动化的真正威力，是编写代码来测试代码，使得计算机执行的测试工作是用其他方法无法替代的。
举个例子，例如每天要重复执行上百次Slack里的一个输入框：
怎么来测试它？（很不幸的是）一个通用的方法是先设计测试用例，然后或是自动化执行那些测试用例，或把是那些测试用例给自动化测试团队实现自动化。测试用例可能如下：
●提交一个可以确认提交成功的字符串，按回车。
●验证发送的消息是否出现在其他计算机/账户上。
●输入一个非常长的字符串……
●输入外来字符……
●从剪贴板粘贴字符……
c等等（你懂得）
好的测试设计必须考虑到软件行为功能（它是否做了所期望的事情，又是否做了不被期望的事），以及非功能的属性，比如可靠性、性能和安全性等。一个好的测试设计方法是将这些东西视为整体（系统性思维）。我经常通过头脑风暴产生脑图来开始这个过程的，以确定测试方法。下面是一个脑图的例子：
在创建这张脑图的时候，并没有考虑任何要不要执行自动化的问题，只是写了许多关于要测试的笔记、想法和问题。最终，我会使用脑图来帮助我组织测试思路，并通过脑图与其他人交流。
现在，就可以着手考虑自动化了！脑图里有许多关于需要发送的字符串的不同想法，每个测试的设置都手动执行是极其无聊而烦人的（此时正好就需要一个好的启发思维来决定哪些部分进行自动化测试），于是就从这里开始：
For Each string in TestString.txt { SendSackMessage(string); VerifyMessageAppears(string); VerifyRemoteMessageAppears(string); } 看，这是一个数据驱动的测试。当然，我写了上面那段代码，很短。假设现在有一些新的测试思路，我可以把它们存入TestStrings.txt(或从The Big List of Naughty Strings注1的列表里“偷"一些清单)，我可以去参加比赛了。 |
人类对重复测试感到厌烦，而计算机正擅长于此。发出1万条消息，测试每个消息发出的延迟情况；如果任一个消息的发送超出两个标准偏差，那么就返回一个具诊断信息的错误，保存或把数据绘入图表；尽可能快速地发送一串的单个字符，验证是否能按正确的顺序到达。此类自动化测试的优点在于利用了计算机的优势，这通常比端到端的UI测试更有价值。这种类型的自动化测试就是有价值的。
类似的，对于用户的行为，许多人试图没有创建片状测试（flaky tests）的情况下去实现自动化，这是非常难的，这部分测试更适合人类自己去验证。
好消息是在这种思维方式中考虑测试设计和自动化测试，会消除那些自动化测试将会取代测试人员的所有价值和可信度的担心，或者如何“转换”人工测试到自动化的疑虑。好的测试设计并不是那样的。
以后测试设计时记住两个定律：
●应该自动化的部分就100%的自动化
●需要人工验证的部分就100%的采用人工
测试的目标不是自动化，我们的目标甚至不是测试。目标应该是帮助我们的团队尽可能高效的提供高质量的软件！为达到这个目标而创建测试自动化，才是优质的！
