由于内容过长，分章节来发表文章。
目录
自动化测试人员需要知道的50件事(目录篇)
上一章
自动化测试人员需要知道的50件事（第一章 脚本）
关于这部分的说明：非原文翻译，是我根据作者原文，加上自己的理解，写下的内容。算是半笔记半心得体会性质的原创内容。为了加以区分，尽量把纯粹是自己观点的大段文字做了加粗处理。
第二章 测试
1. 不要在脚本中重复实现被测程序的功能
话说实际项目中，还真碰到过这种情况呢。其实抛开技术层面，用脚趾头想想嘛，同样的功能逻辑，开发写了一遍，测试脚本又写一遍，这是在挑衅开发的代码能力么……不太利于内部团结呢。
那为啥不能这样做呢？
作者说了：
- 首先实现逻辑可能比较复杂，被测程序都实现过一遍了，那你现在又要做重复劳动。
- 而且公式和逻辑后续可能会有变化，那么就会导致被测程序实际上没有bug的情况下，测试脚本也会报错。这不是浪费时间嘛
- 如果是处理浮点数的话，不同的编程语言会导致结果的不同，那么测试脚本还必须采用和被测程序一样的语言编写，用来避免这种情况出现。
前两点都是我曾经想到过的，第三点还真没注意过呢。
那这种情况下，正确的做法是手工计算得出正确的结果，并且作为期望值保存在脚本中。如果感觉一个数据不够用，那就用一组数据呀。
2. 每个测试应当是独立的
初学者经常犯的一个错误就是，一个测试使用的数据，来源于另外一个测试。一个形象的例子就是对于增删改查功能，一个测试创建一条记录，另一条测试编辑它，第三条测试删除这条记录。
这么做的唯一好处就是节省时间，缺点则有一箩筐：
- 如果第一个测试不通过，后面几个也会挂掉
- 在报告中你会看到所有测试都不通过，但是实际上第2、3条测试对应的功能是好的。
- 当自动化执行测试时，这些测试并不能保证按特定顺序执行。
所以呢，你可以考虑先用SQL生成所有所需数据；或者先执行生成数据的测试，如果它没有通过，那么也就没有必要执行剩下的测试了。
如果你仍然觉得在你的情况下，使用这些互相之间不独立的测试，是最优的方案，那么请确保检查所依赖测试的执行结果，在它没有被正确运行的情况下，不要执行后续测试。
当然还有一种可行的解决方案就是把这些不独立的测试组合成一个独立的测试。
嗯，在我早期做过的实际项目中，的确碰到过这种情况，当时还真的觉得这种方法很棒呢。后来回过头来再思考的时候，虽然也会觉得这种方式并不是很好，但是没有作者思考的这么深入。不过我们在项目中做到了检查每一个测试的执行结果，所以还好啦。
3. 哪些不应该被自动化？
- 不要去自动化很难维护的部分。
- 不要去自动化第三方的应用
- 自动化接口Interface（正确性和易用性）原则上是可行的，但是太耗时间而且通常不会被完成
- 需要与周边设备交互的操作，它可能比较复或者需要很多手工操作
- 图形图像和视频的正确性更适合用手工检测
- 混淆程序和单个组件（Obfuscated applications and individual components）不能被自动化，因为每一次编译时属性名称可能会被改变
关于接口Interface的那块，虽然翻译过来是叫接口。但是我认为作者所说的接口（Interface），应该和API不能混为一谈。
毕竟在实际项目中，对于API接口（如http接口）的自动化测试还是比较有效和常见的。个人浅见，欢迎指正。
关于混淆程序和单个组件（Obfuscated applications and individual components）的部分，这部分理解的不是很深刻。我想应该是和自动化的方式有关，比如自动化的时候用了具体的属性名称，但是每次编译的时候根据情况都有变化，就不好被自动化了。在项目中会碰到过同一个部件，在页面每次加载时属性名称不同的情况，不知道和作者说的是不是一回事呢？
当然，有些时候把手工和自动化相结合，是很有用的。
所以不要把前面所列的几条当做真理，只要在脑子里留个印象，并且在实际问题中找到最优方案。有些时候正确的方案就是要打破规则。
4. 向开发寻求帮助
当你遇到复杂的问题，不妨向开发求助。因为他们在你所不熟悉的领域内可能有专长。
有时候当你知道问题的解决方案时也不妨和开发聊聊，因为可能有更好的方式去实现它。
当然，要记住开发人员的视角和测试人员不同，他们从内部去看一个程序，而你从外部去看。所以开发给出的建议也不一定全是好建议。
5. 云测试
- 要测试桌面应用程序，必须打开会话（登录用户，或者远程桌面会话），否则不会呈现相应的GUI，自动化工具也不会识别出窗口和控件。如果在操作过程中连接中断，自动化工具将无法识别应用元素，将导致无法预料的错误。
- 任何与物理设备相关的自动化在云中也很不方便。
- 提供访问移动设备的云服务比平常的云虚拟机更昂贵。
- Web应用程序的自动化是很适合在云中运行的。如果在测试结束时需要验证机器上的某些内容，只要不把虚拟机返回到初始状态就可以。
一般来说，使用云中的虚拟机并不像使用本地计算机和虚拟机那样方便快捷。
项目中还没有遇到过使用云服务来测试的情况，因此这块我只能看看作者的经验啦。
6. 边界值用例的自动化
假设在某个测试点，需要输入1到10的数字。那么在自动化测试中，需要至少检查3个数字：1，10，范围为2~9的数字。
当然还需要检查不允许输入的数字，我们此处只讨论正确的输入值。
所以：这部分作者的意思是，设计自动化用例时要考虑输入边界值，以及非边界的正常值。
7. 错误和警告的区别
有两种类型的错误：关键和非关键（Critial and non-critical)。从自动化角度来看，如果发生错误后我们可以继续运行测试，那么这些非严重错误是警告。
但是以JUnit格式生成报表的许多工具，测试不能有中间状态：通过或失败。
当单元测试引擎用于GUI测试时，出现任何错误时测试将停止。
因此在使用JUnit报告的工具中，可以使用以下方法：执行非关键验证(non-critical verification)，如果出现错误，只需向错误列表（初始为空）添加错误行。在测试结束时检查这个列表。
关于这点啊，如果一个测试失败会导致后续测试无法运行，的确需要考虑如何处理。但是在之前的地方提到自动化测试用例必须相互独立，并且我目前的项目中也没有碰到过这种事情。可能是因为我没有用过JUnit，不是太熟悉相关处理吧。如果以后用到了，可以考虑下作者的思路。
8.使用适当的方法
在自动化测试中使用了许多特定的方法：ODT，DDT，KDT，BDD，页面对象，基于模型的测试等。但仅仅知道它们是不够的;你需要适当地使用它们。
这部分呢，就需要自动化相关人员的知识水平，以及考虑到团队和项目的具体情况，再考虑到自动化效率和维护成本，来选择适合的方法了。我之前简单翻译了一篇文章“错误的自动化测试目标 VS 建议目标”，也发在简书上了，可以参考之。
9. 个别错误的验证
在大多数情况下，编写测试是为了验证一些功能，而不是验证特殊情况，例如特定数据的错误。但是，有时候会发生一段时间后再次出现该错误：其外部的原因可以完全不同，但结果看起来是一样的。这种情况下，编写单独的测试来验证这个特定错误是有意义的。
这些bug的特点是不适合手动测试脚本，因此只能偶然发现。通常，在积极开发项目中会出现这样的错误，其中有几个程序员可以修改相同的功能，从而影响彼此的变化。
所以当写此类测试时，在报告中要指出现有bug的编号，以便查看其发现和修复的历史记录。当编写自动化测试并发现错误时，可以采用相同的方式。你注册了一个错误，并在新测试的验证注释中，指定其编号。
这块有点绕，看了几遍总算有点明白了。我的理解是这样的：本来针对一个功能，你写了一个测试用例来测试，并且也测试通过了。但是一段时间后又不通过了。查原因的时候发现，是另外的修改导致了结果的不通过。此时就需要针对这个特定的原因，另外写一个测试来验证它，并且附上对应的bug编号。
10. 在写真实测试之前做一个试点项目
有几种情况适合使用试点项目：
- 第一次使用新的自动化工具
- 自动化新类型的项目
- 在以前不存在的项目中实施自动化时，快速向管理层或客户展示特定结果
这部分说的非常棒！在我的项目经验中，也做过相关的试点项目（我们当时称之为demo），但是也存在没有做demo就立刻开始的情况。回过头来总结一下，或许有些项目还是可以考虑使用不同工具和方法做一下demo，再正式开始的。