自动化测试一直以来都是业界讨论的热门话题，目前也有不少成熟的自动化测试工具，如LoadRunnert，QTP等。每谈起自动化测试，笔者与很多热衷于自动化测试的朋友一样，很兴奋，因为它确实能给我们带来很多好处，以及快乐的美好时光。例如无人值守的夜间测试，第二天一上班准能收到汇报测试结果的邮件；在办公室里你大可以优哉游哉地喝着咖啡，而它在听从你的指令拼命地跑，当你喝完一杯咖啡回到座位上后，测试结果已呈现在你眼前，可以尽享高效工作带来的愉悦。
自动化测试在以下几方面有突出的优势。
回归测试：在版本稳定的前提下，当每一次软件版本变更后，由于担忧更改影响原来功能，需要再执行原来成千上万条或更多用例，工作量可想而知。而如果此时能把这些用例自动执行，无疑可节省测试人员大量的执行时间。一旦测试脚本及测试环境搭建好，每次做很小的改动或不改动即可自动运行程序完成回归测试。
每日构建：在每日构建中加入自动化测试是一个很不错的做法。开发人员提交到版本库上的代码必须保证能顺利通过，而且要通过基本功能的自动化测试，以保证提交到测试的版本合格。
压力测试：可以代替手工执行困难或不可能做的测试。例如做一个反复点击某按键的压力测试，人工执行100次、200次可以接受，但要连续点击1000、2000次可能就坚持不住了，如果是10000次或更多次则基本不可能完成。而这正是自动化测试的强项，再多它也不嫌累，速度上也一成不变。
一致性测试：执行相同的用例，不同的测试执行人员，常会有不同的结果，并不是用例有问题，预期结果也是正确的。主要原因是因为不同的人，对用例的理解不同，有些人执行过程中会发现其他的发散路径，做试探测试，而有些人可能没有。思维是不一样的，故同一条用例，有些人能发现Bug，有些人则不能。而自动化测试则非常乖巧，对同一条用例，每次执行的结果绝对是一致的、可重复的，是主人最忠实的奴仆。
测试执行能自动化固然好，但不要盲目自动化，自动化测试并非万能。然而业界的很多测试朋友对自动化测试的认识存在一定的误区，认为自动化测试技术含量高，只有从事自动化测试才有发展前途。这些年，笔者在参与社会招聘时，收到的简历中几乎没有不提及自己熟悉某某自动化测试工具的。然而对所掌握的工具如何应用在工作中，给项目带来了哪些实际的贡献等，却没几人能说得清楚，大部分是在学习、尝试中。在面试过程中还发现有不少人认为如果不提自动化测试，不掌握某项流行的工具，就好像差人一截，失去竞争优势。然而，自动化测试工具毕竟是由人设计出来的，工具本身并没有人所具有的逻辑思维能力，不具有人的智慧与创新能力。
在一个测试项目中，哪些可以进行自动化测试，哪些可暂不考虑，哪些根本不值得考虑等，需在项目规划初期，纳入测试策略的部署中。以下这些情况不适合进行自动化测试。
软件不稳定。如项目在研发的前期，版本频繁变更。如果此时就上自动化，那么随软件代码的修改，测试程序的修改也是相当巨大的。当然，这并不意味着在项目前期自动化测试不用介入，相反可以做好测试方案、测试数据及用例的准备等。
用户很少用的功能。例如，某功能仅是为了产品的销售亮点而捆绑的一些锦上添花的功能，用户很少用或基本不用，这种情况不值得自动化。
用户体验测试。如易用性测试、UI界面检查、与人的主观感觉直接相关的测试不适合自动化。
涉及物理交互的测试。例如，通信过程中、网线没插好、设备工作过程中开/关电源等。
以上观之，自动化测试所完成的功能是有限的，并非所有的手工测试都应该自动化。只有需要反反复复执行的用例，才需要将它测试自动化。
小贴士：
美国一位测试专家James Bach称：根据经验自动测试只能发现15%的缺陷，而手工测试可以发现85%的缺陷。
相关链接：
