一、概要
这篇文章描述了一种适合中小型软件项目的敏捷自动化测试方法。考虑下创立一个小的测试工具团队，他们会将敏捷开发规范应用到测试自动化问题中。这样做意味着，他们会每天跟测试人员比对，见证测试策略的展开，然后发现方法去应用丰富的技术（很多是便宜或者开源的技术）到特定测试人员需要的特定事上。他们会在可衡量的，易维护的用不到一周甚至更少工夫就可以完成的迷你项目上实施这个做法。这些工匠们也将会跟开发一起共事来确保产品有合理的可测试特性。他们将把技术应用到一系列测试需求上，不仅仅是测试自动化。
二、测试自动化的原则
在考虑如何采用系统化和有效率的测试自动化方法时，这或许能帮助将以下的原则牢记在头脑里。他们在过去15年里被从很多测试自动化工程师和经理们的经验中剔除。其中有一些我曾经在我的一篇文章--测试自动化蜗牛油中详细讲过，在我的书《从软件测试中学到的东西》里也谈过。
1) 测试自动化不能复制手工测试人员。
手工测试人员，即使是那些没有特殊技术和培训的人，也能够去做和发现自动化测试能做或发现的想得到的事情。即使有其局限性，也要承认自动化有很大的价值。但是，通常认为自动化作为手工测试的延伸更有效率，而不是取代手工测试。有效率的自动化努力因此从有效率的思考测试开始。缺席的好的测试策略，自动化自然成为很多极少发现缺陷的重复性活动。
2）测试自动化不只是测试执行。
大多数人听到测试自动化立即会有一种想法"测试在我们睡觉的时候进行"换句话说，他们想让计算机来跑测试用例。这的确是一种有用的测试自动化。但是，还是更多的东西。举例来说，下面的清单中的每个都可以在某种程度上自动化，即使其他项目保持手工流程。测试产生（数据和脚本产生器）。工具可能会创建特定的数据例如随机的邮件信息，或者构成数据库，或者产生我们想要去覆盖测试的参数组合。
· 系统配置。工具可能保留或者复制系统参数，将系统设置为一个特定状态，或者创建或者还原"复原的"硬盘驱动。
· 模拟器。工具可能模拟次级系统或还不能用来测试的环境条件，或者手头上去提供真实的环境比较贵的情形。
· 测试执行（道具和测试脚本）。工具可能自行运行软件，或者是通过GUI模拟用户工作，或者通过绕过GUI使用替换的可测试的接口。
· 侦探器。工具可能能使对人类来说不可见的东西变成为可见。他们可能统计性地分析一个产品，从语法上分析一个日志文件或者监控系统参数。
· 神谕。一个神谕或者看到的东西是任何一种我们发现失败或成功的机制。工具可能自动探测到某种产品中的故障情形。
· 活动录制和覆盖分析。工具可能监视测试活动当他发生且回顾性报道什么在测，什么没有在测。他们可能记录下动作为以后其他测试做回放。
· 测试管理。工具可能跟测试结果打交道，组织测试思想，或者呈现度量方式。
3）测试自动化易于即时作废。
软件项目围绕生产代码做解析。测试代码并不是生产代码。因此一个典型的软件项目的优先级允许生产代码来改变及时当这种行为会破坏测试代码。这是正常的现象，而通常来说是合理且经济实惠的做法。
设想产品会变化，你基本上有两个选项：投资测试代码让他更坚固地面对这种变化，或者让测试代码不那么昂贵和不易修复如果你不在意产品变化会破坏测试代码的话。
... ...
查看全文内容，请点击下载：http://www.51testing.com/html/18/n-3708418.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
