精彩答案：
会员 1316016 ：
大家好多都是在说自动化和手动测试分工的问题，总是在谁测哪部分，谁更适合测试哪部分种纠缠，这只是二者结合的一部分，一个小部分，当这个问题解决了之后，还会有更多的问题困扰我们。以下，我们将一一道来。
我们现将自动测试粗略的分为如下几个阶段，并讨论在各阶段，经常出现的矛盾及误会，该如何配合：
1、整体的测试策略
最重要的问题就是哪些Case要做自动化？也就是大家常说的分工问题。可以从以下几个方面考量：
a）根据自己Team的实际情况，来选择自动化的程度，如：自动化人充足，或者技术高，就可以多选一些Case；如果自动化刚起步，就可以选择一些简单的，重复的Case实现。
b）老板或客户的要求。现实中，自动化的比例也多数会被领导要求，搞一些形象工程，强制某些模块或者什么的自动化比例多少，我们必须硬着头皮做的。
c）传统的Case分割。比如，重复的，稳定的，等等Case适合做的，我们就拿来做。之所以把这项放在最后，想说明的就是虽然这个是评判Case是否自动化的最根本标准，但是面对a）和b）状况的时候，我们只能在一定范围内应用c）的策略。
总之，根据各公司的策略可以分出要哪些自动化。这时看似和自动手动测试无关，是highlevel的事情，但是，如果各方的test leader有远见的话，在后续的执行力上是有很大差异的。
2、测试脚本生成
当测试策略订定，下面面对的就是自动化脚本生成了。
大多数的状况下，写自动化Case的范本，是基于手动测试的测试用例，很少有直接对需求人员的，这对自动化开发人员了解需求和手动测试用例都是很大的考验。结果，问题出来了：
a）编写自动化脚本的人，往往会对业务逻辑不太熟悉，这个时候就需要和手动测试人员沟通，而在沟通的时候，势必会影响手动测试的正常进行，部分手动人员则不配合或消极配合。
b）在沟通的过程中，手动测试的人员往往无法设想到自动化的情境，认为某个功能实现自动化很容易或者很不容易，自动化人员则又认为手动人员什么也不懂，无法沟通。
以上的问题都是我们切身经历过的，针对这样的状况，我的建议是：在平常的时候，手动测试的人员要了解一下本公司主流的自动测试工具及流程，对自己能力也是一种提升。自动测试人员也要多去了解业务逻辑和一些手动测试的技能，而不是单纯的坐为一个开发者。总之，这个阶段一旦出现问题，就不是一时半会可以解决的，而且相当影响双方的士气。
