转自：https://mp.weixin.qq.com/s/Y_DhYHYecl84WAcSdl0mCw
自动化的能力并非在于自动执行用户任务（并非怀疑所有的价值，我承认有一类自动化测试是有价值的：编写简单的测试，定时运行跨多平台和操作性的测试，以确保兼容性等）。测试自动化的真正威力，是编写代码来测试代码，使得计算机执行的测试工作是用其他方法无法替代的。
好的测试设计必须考虑到软件行为功能（它是否做了所期望的事情，又是否做了不被期望的事），以及非功能的属性，比如可靠性、性能和安全性等。一个好的测试设计方法是将这些东西视为整体（系统性思维）。我经常通过头脑风暴产生脑图来开始这个过程的，以确定测试方法。下面是一个脑图的例子：
在创建这张脑图的时候，并没有考虑任何要不要执行自动化的问题，只是写了许多关于要测试的笔记、想法和问题。最终，我会使用脑图来帮助我组织测试思路，并通过脑图与其他人交流。
现在，就可以着手考虑自动化了！脑图里有许多关于需要发送的字符串的不同想法，每个测试的设置都手动执行是极其无聊而烦人的（此时正好就需要一个好的启发思维来决定哪些部分进行自动化测试），于是就从这里开始：
For Each string in TestString.txt
{
SendSackMessage(string);
VerifyMessageAppears(string);
VerifyRemoteMessageAppears(string);
}
看，这是一个数据驱动的测试。当然，我写了上面那段代码，很短。假设现在有一些新的测试思路，我可以把它们存入TestStrings.txt。
人类对重复测试感到厌烦，而计算机正擅长于此。发出1万条消息，测试每个消息发出的延迟情况；如果任一个消息的发送超出两个标准偏差，那么就返回一个具诊断信息的错误，保存或把数据绘入图表；尽可能快速地发送一串的单个字符，验证是否能按正确的顺序到达。此类自动化测试的优点在于利用了计算机的优势，这通常比端到端的UI测试更有价值。这种类型的自动化测试就是有价值的。
类似的，对于用户的行为，许多人试图没有创建片状测试（flaky tests）的情况下去实现自动化，这是非常难的，这部分测试更适合人类自己去验证。
好消息是在这种思维方式中考虑测试设计和自动化测试，会消除那些自动化测试将会取代测试人员的所有价值和可信度的担心，或者如何“转换”人工测试到自动化的疑虑。好的测试设计并不是那样的。
以后测试设计时记住两个定律：
- 应该自动化的部分就100%的自动化
- 需要人工验证的部分就100%的采用人工