目录
自动化测试人员需要知道的50件事(目录篇)
上一章
自动化测试人员需要知道的50件事（第二章 测试）
关于这部分的说明：非原文翻译，是我根据作者原文，加上自己的理解，写下的内容。算是半笔记半心得体会性质的原创内容。为了加以区分，尽量把纯粹是自己观点的大段文字做了加粗处理。
第三章 环境 Environment
在软件测试自动化中，有两个重要环境：一个环境是创建和debug测试用的，另一个用来执行测试的。
1. 选择一套适当的工具满足你的需要
有这么两类人：一类想用一个工具来解决所有问题，而另一类人，则是有一个新任务，就选一个新工具。
实际上，应该选择介于两者之间的方案：选一个可以满足大多数需要的工具，并为其他情况增加一到两个工具。不要在你的项目中使用一整个“动物园”的语言，工具和类库，但是也不要指望用一个工具来解决所有问题。
2. 不要使用脚本自动创建bug
如果你的自动化工具和bug跟踪器集成，你可能会有这么一个秒主意：当运行脚本出现错误时，自动化的创建bug。但是大多数时候这是无意义的，因为很多脚本运行时产生的错误并不是真正的bug。
另一个不建议这样做的原因是：自动化创建bug时，很难描述复现这个问题的正确步骤。
不过你可以在错误发生时自动化的创建任务，并且指给这个测试的作者，让他来进行分析和处理。
但是，在这种情况下，也存在隐藏的陷阱。 如果我们的测试环境有问题并且没有通过测试，那么对于他们每个人都会创建一个单独的错误。 因此，在早上，每个测试人员都会在一夜之间创建大量新任务。 如果这种情况经常发生，过了一段时间，人们会开始忽略这种通知。
关于这部分，在我之前的项目经验中，是会把所有不通过的测试整理出来，发一份报告邮件给到所有相关测试人员，让他们去分析。所以如果测试环境有问题的话，从这份报告中就很容易看出来（因为绝大多数甚至全部的测试都是不通过的）。
3. 在质量的偏见中不要追逐“绿色构建”
避免注释有问题部分的代码，同时避免暂时更改预期结果，以便测试运行完成而不会失败。
这部分是指，不要一直盯着测试状态，使之保持绿色（红色是失败，绿色是通过嘛）。过于追求这种绿色，可能会导致测试人员通过注释或者修改测试内容的方式，来完成这件事。
当然，如果构建长时间保持红色，这可能也是个问题，因为人们习惯了这样，并感觉正常。
作者提出的这个问题非常棒。因为在实际项目中，有些不懂得技术细节的管理人员，很有可能就只盯着“绿色构建”，并且要求一直保持这样的状态。如果这位管理人员不是那么好沟通的话，测试人员可能真的会通过各种修改来应付差事。而这样的话，真的不是很利于工作呢。
4. 学习你工作中使用的工具
这部分我就不去直接翻译作者原话了，意思是说很多工具，虽然你已经用了很多年了，可能你并不知道某些常用的功能，还有更高效率的方式；以及有些功能，你可能根本没用过。感兴趣的去看原文吧，绝对戳中大多数人的痛点！
下面开启本人的碎碎念时间：
深有体会！人们都是懒的嘛，而且现在软件工具什么的都越来越多，越复杂，再也不是很多年前，当我刚接触互联网时那样信息贫乏。那时候可获取的软件也好工具也罢都特别特别有限（而且很贵！），所以对于手上每个软件、工具，都恨不得每个按钮每个功能都玩一遍。
但是学习一下工具，真的是磨刀不误砍柴工。我也需要自省一下，最近这些年来，很多用到的工具软件的确是没有深入的去学习过。
5. 使用版本控制系统
如果你以前没用过版本控制系统，是时候开始了。如果你觉得这么小的自动化测试没必要使用版本控制系统存储，那么你错了。
你不能只是把测试件保存在自己的硬盘上，如果你的硬盘坏掉了，这些辛辛苦苦花时间写出来的测试件就跟着没了。
一般来说开发会用某种版本控制系统，所以最开始可以直接用他们的那套。
关于这点，应该很多人都是用git的。从我参加的第一个自动化项目起，我们就使用了git来管理相关测试脚本、数据等。所以这方面算是没有走过弯路。但是在和同行小伙伴的交谈中发现，的确不少公司就是采取了保存在自己电脑上这样一种方式。所以这点值得注意！
6. 避免自定义表单
在一些自动化工具中，有自定义表单这样的功能。尤其经常在商业工具中发现它们。
自定义窗体是在测试运行期间出现在某个特定点上的普通窗口，用于输入用户的任何信息。在某些项目中，这些表单用于输入将要使用的测试参数（例如服务器地址，用户名等）。
在大多数情况下，不建议使用此类表单，以及任何用户与自动脚本的交互。
至于测试启动参数，它们可以存储在配置文件中（例如，ini，xml等）。在文件中更改这些参数与将其输入到自定义表单中一样简单。如果在不同的计算机上使用不同的参数（例如，当前计算机上的用户名），则可以使用多个参数文件，每个参数文件对应于当前计算机的名称。
项目中没碰到过这种情况，不过核心思路就是避免测试过程中需要人工干预的情况。
7. 尽可能的简化一切
您需要处理很多事情：测试，代码，测试环境，虚拟机，SQL查询，测试数据，报告等等。让每件事情都尽可能简单，这很重要。
如果你有一个困难的测试，你必须经历很长一段时间才能确定它 # 把它分解成几个简单的测试。如果你有复杂的代码，并且你必须长时间调试它，简化这个代码（例如，把它分成几个独立的基本函数）。等等。
任何看似困难或需要大量额外行动的事情都需要简化。如果你解决了一个问题并找到解决方案 # 不要急于实施它，试着找到一个更简单的解决方案。通常解决问题的第一种方法并不是最简单的。再思考半小时，你可以为自己节省半天的工作。
寻找更简单的解决方案的最佳方法之一是咨询与您合作的人。外部观点可以推动朝不同方向思考。
最好的解决方案并不总是改进现有的方法。 如果您将问题转移到不同的平面上，可以找到最佳解决方案。
这一段，是解决问题的方法论。问问自己，是不是在工作中找到一个解决方案就用了，而没有考虑是否可以简化？或者在工作间歇期去复盘已有的工作，思考可以优化它们，提升效率的更好方案呢？
如果能够经常使用这种方法，对自己对公司，都必然是很棒的事情。
###重点推荐这部分的观点。所以你也看到我也花很大篇幅翻译了作者原话的大部分，希望你可以有所思，有所得。
8. 自动化任何日常工作
我经常遇到一些进行自动化工作的怪人，他们在以最不方便的方式执行其他日常任务。例如，要启动程序，他们打开资源管理器，在其中找到必要的文件夹，然后运行该程序。他们每天多次执行此操作，而不是在任务栏上创建快捷方式或按某个键盘组合开始。
在另一种情况下，要从命令行启动一个包含许多参数的程序，该人员将打开控制台，转到所需的文件夹，然后手动编写程序名称及其所有参数，但如果您的程序可以以相同的速度快10倍编写一个批处理文件。
有很多这样的例子：人们手动输入大量数据集，而不是写一个简单的脚本并执行它;使用鼠标的地方使用键盘组合的速度要快10倍;使用简单的程序，如记事本而不是更高级的编辑器等。
您的自动化工具不是您可以将日常任务自动化的唯一手段。使用一切可用！一旦您定期执行例行任务，请考虑如何加速或自动化。使用这种方法不仅可以提高您的工作速度，还可以提高您对所用操作系统的了解。
这部分非常棒！我也经常会写一些脚本去自动化某些工作。举个例子，我在工作中要经常打开某几个测试网站，但不是简单的打开就完了，我需要输入特定的内容并登录（并且出于安全考虑，某些输入项不支持浏览器保存），登录后进入特定的某个或某几个页面。
于是我就用web自动化工具写了一个脚本程序，去完成这些事情。然后还写了对应的界面，这样我只要启动这个程序，点击一个按钮就可以完成上述工作，并且不会出错。手工的时候，总会碰到输入错的网址，或者半天都想不起来要打开的网站在收藏夹中叫什么名字的事情。
但是我做的还远远不够好。接下来我要经常发现日常工作中可以自动化的事情，并且自动化它们！
下一章
自动化测试人员需要知道的50件事（第四章 运行，记录日志，验证）（待更新）