手动測试和自己主动化測试永远是一个非常热门的话题。自己主动化也一直被人们捧上神坛。自己主动化測试和手动測试从技术上来说本质事实上都是測试用例设计。仅仅只是终于形式一个是人工运行，一个是代码运行罢了。这两者就如白盒測试和黑盒測试一样在项目中都是不可或缺的。
我们来看两个场景。
案例一：某企业招聘软件測试project师，并组建了各自分工明白的自己主动化和手动測试部门，在项目中两个測试团队分工明白并互相分享经验。终于项目产品的质量得到了良好的保证。
案例二：小陈同学想应聘软件測试project师的岗位。投了非常多简历之后也得到了若干面试的机会，但在面试过程中却频频由于自己之前都是手动測试而导致失败甚至被别人看不起。经过了一段时间之后，小陈同学也心灰意冷，也開始认为手动測试就是没有价值的活动。
上面列举的场景在行业中很常见。那么我们应该怎样正确的在项目的測试活动中实施手动測试或自己主动化測试呢？主要有下面几个因素决定：
1. 回归和探索
我们在项目的測试过程中，回归測试是不可缺少的一个环节，它可以使得我们的产品尽量不会出现反复的缺陷。比方測试输入法产品，不管功能和设计怎样变化。其主要的字符输入功能总是不会改变的。
在长期的项目迭代过程中，測试人员多少都会由于每次验证相同的问题而掉以轻心，同一时候也浪费了project师的时间在反复的工作上。
往往这类每一个迭代版本号都须要验证的重要核心的功能就被贴上了自己主动化測试的标签。自己主动化測试既可以节省回归的成本也可以增加持续集成的平台。而每次版本号新增的功能的单独模块和集成測试很多其它的须要手动的探索性測试。手动測试很多其它的须要基于測试人员对于产品的了解和经验而进行的，一个经验丰富的手动測试project师可以在短时间内发现非常多的功能上的缺陷。这绝对是自己主动化測试无法达到的高度。
2. 压力測试
測试活动的目的决定了选择手动測试还是自己主动化測试。
就比方压力測试。本身測试的目的在于查看软件功能在被长时间使用之后是否会有内存泄漏、溢出等问题。这类測试活动假设手动来做的话。或许一个測试project师一天八小时得所有放在这个上面。还未必可以达到測试得效果。
所以这类測试就贴上了自己主动化測试得标签。仅仅要有针对性得编写脚本去不停得使用产品。在自己主动化測试得过程中可监控功能的异常情况从而获取有效的信息。在这类測试活动中，手动測试是无法正常支持的。
3.场景模拟測试
在測试活动中有非常多环境是我们通过手动測试无法覆盖到的。
包含方法的各种类型的參数、各种边界的模拟等，这类測试活动就更适合用自己主动化来做。
在測试过程中，使用技术手段将各种測试环境、配置等进行模拟之后从而弥补手动測试在有限的測试环境中遗漏的測试点。