关于自动化测试的一些思考（一）

  时至今日，进项目组已经半年了，对自动化测试也有了更深刻的认识和理解。

为什么要进行自动化测试？要回答这个问题，先了解一下测试背景。我们项目所使用的软件开发模型是agile，agile开发的scrum模型，整个大项目分成一个个小team，每个team都有一个scrum master。Scrum master 根据每个人的情况安排任务，制定sprint plan。我们的测试有两条线，一条是main line ，一条是branch line，平均每个sprint是一个月（22个工作日），差不多每周要出2个build，每个sprint大概4-7个build。版本迭代非常快，周期短；对于QA,每个人要负责至少一个component，每个component有200-400个case，每个case如果手工测需要2分钟左右，再加上整理test summary,将测试结果上传到ALM，时间往往不够用。因此单纯的依靠手工测试，workload 非常大，占用时间非常多，显而易见；另外的一个问题是regression，有很多情况下新发布的版本并未修改你所测component的code。当然，除了workload的另外一个因素就是没玩没了的meeting，stand up meeting,各种on line meeting，无形中会影响一个人的工作进度。这时候矛盾就凸显出来，在人员有限，工作量很大的情况下，测试风险极大的情况下，急需一种解决方案—就是自动化测试。

自动化测试有什么好处：

a) 节省人力，只要代码维护的好，不需要那么多人就可完成测试

b) 节省时间，测试脚本可以晚上或者是周末跑测试脚本

c) 优化资源分配，在运行测试脚本的同时，QA可以做其他事，比如设计新测试用例

d) 方便regression，极大提高效率

e) 增加软件的可信度，测试是机器执行的，排除了手工测试时因人为情绪而发生的随意性或疏忽性，测试结果更可信

f) 能完成手工不易控制的工作，比如采集系统cpu占有率信息，手工计算很复杂，还要进行数据比对，使用脚本更简单，更方便。

自动化测试的缺点：

a) 脚本维护成本高，尤其是版本变动比较大，对项目来说，是潜在的风险

b) 不易发现新bug

使用什么自动化测试工具，对于client端的同学来说，一般是QTP，而对于server端的，我们使用的是perl和shell写的自动化测试框架。