模板
教程
环境
性能
功能
管理
自动测试闲言杂语
很感激我的mentor，在刚进公司的前两周，没有马上让我接手自动化测试，使我有足够的时间熟悉系统的基本功能，就这么一个缓冲，了解了系统的基本功能，也研究了一个基本的自动化测试架构的组成，对测试系统、对自动化测试自己有了感觉。熟悉测试系统，这是软件自动化测试的第一步。
我的一些刚来的新同事或实习生，总是迫不及待地想学习自动化测试或者是想通过自动测试脚本学习业务，我总会告诉他们，熟悉业务是自动测试的基础，不要小看手工测试过大夸大自动化测试。如果一个系统你都没有亲自手工测试过，又怎会做好自动化测试呢？
用什么工具，我没有选择，因为项目组在我来之前就已经决定了。关于工具的选择，我看重的首先是它是否能够满足项目的需要，是否容易扩展，可以满足系统任何功能的测试自动化；其次是它是否易用，能否容易上手；当然最重要的是它的稳定性，是否不需要人工干预就能稳定地批量运行所有的自动化测试脚本。这三点，项目组所选择的工具都满足了，我自然乐于接受。选择合适的测试工具，是软件测试自动化的第二步。
开始做自动化测试，是从系统的基本功能开始，目标是每次出built都需要花半小时以上的手工smoke test cases测试自动化。在我接手前，已经有同事做了页面相关的功能测试，看了一些以前的脚本，只是简单的录制、回放，因为没有整理过，也就没有业务逻辑和注释，花了很大的精力才弄清一个脚本的步骤和功能。而且，这些脚本中，关键字的参数化做得不好，每次运行都需要手工修改，需要手工来干预的脚本，只能算是半自动化。最严重的问题是，同样的功能，同样的脚本，会被重复地拷贝，当这个功能或业务流程被改变的时候，所有相关的脚本都需要修改，那将会是很大的维护代价。思考了一天，我决定放弃原有的所有脚本，重新设计系统的架构。放弃原有的两百多个脚本，有些可惜，但如果按照原来的思路走下去，我将会付出更大的维护代价。有舍才会有得。
问题我看到了，知道要改，但至于怎样改，心里并没有把握，我知道自己需要时间去研究。我将用于smoke test的系统最基本的功能挑出来，作为设计的研究对象。Web测试自动化，无非就是录制、整理和回放，录制和回放都是简单的事情，关键是整理，好的脚本，应该容易扩展、维护和使用。这十几个脚本，我花了很多心思，不断地思考、不断地改进、不断地与我的同事讨论。慢慢地，自己的思路清稀了起来，做出了自己想要的架构。首先是容易扩展，能够满足现在的功能需求，也能满足以后需要测试的功能的需求。第二，容易维护，当业务流程、接口或页面变动的时候，只需要做一些简单的修改就可以实现。第三，可读性强，别人能够容易读懂和接手维护。第四，容易使用，项目组的其他人想要使用的时候能够简单地搭建和运行。第五，有统一的编码规范、存储规范和编写风格。最后，是最重要的一点，是脚本具有很高的可信性以及自动运行的稳定性。
我像绣花一样一点一点地将这个自动测试架构绣了出来，比别人多花了N倍的心思和时间，晚上从公司走出来，傻傻的望着夜空数星星，虽然累很仍然很快乐。
从系统的基本功能入手，设计自动测试架构，这是软件测试的关键一步。架构的好与坏很重要，它影响到系统的扩展、维护和使用，如果想要系统容易扩展和维护，一定要多花心思在设计上。很多同行问我使用什么测试工具，我会告诉他们，用什么测试工具其实并不那么重要，不同的人使用同样的测试工具，会做出效果完全不一样的东西，那是因为他们的架构不同，设计比工具重要得多。
架构出来之后，就是系统功能的自动化脚本编写，因为项目的原因，当时的自动测试团队已经解散，我面临的是只有一个人的自动测试团队，怎样将上千个测试案例自动化，成了我头疼的问题。至今仍然很感激我的老板和项目经理，调配给我足够的资源，真正的打开了项目的软件测试自动化之门。团队中的其它成员，都是没有自动化测试经验的同事，给他们足够的培训和技术支持很关键。他们所负责的功能，我都会写一个例子，他们可以参照例子按照我们自动测试架构编写规范写脚本，遇到技术问题或业务问题，我会协助解决，在整体的架构上，我会全局把握。那一段时间，特别忙，架构的扩展、业务的熟悉、问题的跟踪解决，有时候同时有好几个问题在等着我解决，但就是这么一段忙碌的日子，从对系统基本业务的理解到系统业务的全面理解，从原来的只有十几个测试案例的自动化测试脚本到上千个自动化测试脚本的实现。很感激我的这些同事，现在他们大部分都回到了他们原来的角色，我也将要开始担任新的角色，但那一段一起工作的日子，我会记在心里。也是因为大家一起的努力，老板原要求实现web页面自动测试或系统30%功能的自动化测试，我们最终实现的是几乎所有接口所有检查点的自动化测试，接近80%的测试覆盖率。
自动化脚本的编写，当然要注意全局的把握和review，不同的人会有不同的风格，稍不注意就会问题多多。
