1． 自动化测试在项目中的扮演角色
首先，需要明确自动化测试人员是项目的测试资源，是项目的一份子，因此与功能测试人员一样肩负着测试重任，保证项目质量。
2． 对自动化测试人员的要求
在充分熟悉需求，理解需求的基础上能挑选出项目中适合做自动化测试的模块，并对自己所写的测试脚本负责，保证测试用例覆盖。
3． 自动化测试人员介入项目的几个关键时间点以及各时间点的产出
PRD评审阶段
建议自动化测试人员在PRD评审阶段开始介入项目，该阶段的介入并不是要求自动化测试人员全程投入，而是花小部分时间去理解项目，对项目的背景，项目的流程有个大致了解，有助于后续对UC的更全面了解。
PRD评审完之后
在该阶段通过对PRD文档的大致了解，能够得出一个大概的自动化测试范围，从整体上大致了解本次项目自动化测试可以在哪些模块上投入，在哪些模块上会有效果，当然这个范围有点类似预估，并不一定意味着后续一定要按这个范围确定。同时，在该阶段，测试负责人也可提出自动化测试数据资源申请。
UC评审阶段
自动化测试人员与开发沟通，如：页面的控件设计，程序接口开放等问题，有助与后续脚本实现。
另外在该阶段自动化测试人员了解UC，并与功能测试人员对uc进行交流，能够挖掘出深层次的需求，保证对uc的全面覆盖，当然这里不强求熟悉具体的每一个校验点，只是需要做到了解流程步骤，熟悉功能点。
测试设计阶段
在该阶段，自动化测试人员需要有2个产出，评估自动化测试点，产出自动化测试具体范围和时间点，这里我们可以针对功能测试人员的测试设计罗列的具体的校验点来进行自动化测试预估，产出自动化测试范围和计划。另一个产出是自动化测试人员需要在该阶段构思出数据准备策略，为后续的脚本逻辑设计做数据准备。
测试用例阶段
在该阶段自动化测试人员可以先进行具体的数据准备，如果可能的话设置可以出部分设计脚本。在该阶段还需要有一个非常重要的环节即：对自动化测试用例评审，该评审非正式评审，但需要相关测试人员参与，自动化测试人员讲解脚本的设计逻辑以及测试覆盖点，让相应的测试人员评审脚本设计是否合理，测试点是否覆盖。
自动化测试运行阶段
自动化测试脚本的提交可以根据具体项目具体模块而定，如果可能的话尽量将脚本在p1阶段就执行，这样有助与提高后续的测试效率。
在脚本实现阶段
当自动化测试脚本基本稳定的时候需要将测试脚本移植测试平台（twork）上运行这样一方面可以通过指定测试计划帮组脚本执行，将自动化测试人员从脚本执行中脱离出来，另一方面有助与其他测试人员查看脚本运行情况，尤其是测试负责人
4. 自动化测试中的几个问题
从自动化测试的工作阶段来看主要有：自动化测试人员理解需求、脚本的测试数据的准备、脚本编写、脚本执行这四大块。其中测试需求理解、数据准备、脚本编写是花费时间比较其中的三块。
就目前的淘规则项目，以及信用卡项目为例，自动化测试人员在前期理解需求上面由于对该项目的业务不了解，需要花很大精力去熟悉，同时在理解需求的时候与手工测试人员之间的沟通成本也会很高，间接造成了手工测试人员的时间负担。此外需求的理解程度也在一定程度上影响了数据准备策略和数据准备的时间花费。但是这部分的时间花费随着所参与的项目经验增加，对业务的不断熟悉，也会在一定程度上在后续的项目中减少这部分的时间投入。
数据准备是自动化测试中的关键点，数据准备策略的好坏直接影响了后期自动化测试用例的脚本设计、脚本效率、以及用例覆盖程度，好的数据准备策略能让测试数据受到外部干扰小，使得脚本在各个阶段P1,P2,P3，冒烟甚至后期回归日常中用，因此需要自动化测试人员与手工人员一起协商有时候设置会需要开发一起参与协商数据准备策略。在有了数据准备策略之后，就是数据准备过程，该过程依赖与项目中测数数据的复杂度，例如需要事先准备好什么样的账号类型，账号需要哪些条件，这些条件可以怎样做到，操作后的数据恢复方法以及需要有哪些数据分支情况等等。因此，整个数据准备过程在自动化测试中占用时间花费很大。
脚本编写是自动化脚本的实际产出部分也是自动化测试的核心，也是时间投入最大的一块。但是该部分的时间投入可以通过一些措施来尽最大可能的缩减，最直接的方法就是在理解需求的时候就与开发约定一些界面控件设计方式和一些内部逻辑的设计。这是一个有用的方法但不是万能的方法，因为你的方便是建立在人家（开发）的付出上的，所以人家完全有理由不搭理你，所以这个时候就要看你的“人格魅力”了呵呵。另外，随着我们脚本写的越来越多，一些封装的方法越来越完善，写脚本的熟练度的提高，随着经验积累，相应的时间消耗也会减少，毕竟我们目前面对的测试对象，测试人员是相对稳定的。
对与脚本执行这块的时间花费随着测试平台的不断完善和稳定，这部分的投入会很小，测试人员基本上可以脱离出来。
从上面四点可以看到，随着我们经验的不断积累，做自动化测试应该会越来越顺！
5. 关于对自动化效果的评价标准的看法
就目前而言，自动化测试还在建立根据地阶段，离实现全国解放还有一定距离，因此在自动化发展的各个阶段应该有各自阶段的实现目标和评价标准。就目前而言，由于我们的自动化测试平台还在不断完善中，手工测试人员与自动化测试人员还在磨合期。就现状而言，希望在各个测试阶段节省测试时间似乎比较困难：功能测试人员对自动化测试并不完全信任，因此不可能让自动化测试完全替代手工测试，换言之，功能测试人员也会抽取部分自动化测试用例进行手工执行。但是不可否认自动化测试的加入大大提高了测试的效率和测试质量。由于自动化测试人员承担了一部分的测试用例，所以手工测试人员会将工作重心放在自动化测试没有覆盖的点进行重点测试，使得在每一轮测试中的每一个测试用例点执行次数增加，从而保证了测试质量；另一方面，自动化测试能够增加测试覆盖点，覆盖更多的测试分支。
因此，对自动化测试效果的评估不能用一个不变的指标进行评价，而是根据自动化测试的不同发展阶段用不同的评价标准。就目前而言，uc，tc的覆盖率，以及测试用例的执行轮次，发现的bug比率可能是比较实际的衡量标准，随着自动化测试的不断发展，以及依赖的测试平台的不断完善，再将一些时间量度加入衡量标准中，感觉会比较容易接受。当然，这些都是个人看法，仁者见仁，欢迎大家探讨。
相关阅读：
QTP自动化测试流程
