空间管理您的位置: 51Testing软件测试网 » 小马菜菜的个人空间 » 日志

自动化测试随想（二）

上一篇 / 下一篇 2012-09-14 22:10:55 / 天气: 晴朗 / 心情: 郁闷 / 精华(1) / 置顶(1) / 个人分类：自动化测试

很久之前写过一次自动化测试随想一，后来就一直没再写东西。最近这段时间公司机构调整给我整郁闷了，漫漫长夜无心睡眠，决定总结自己以前自动化测试的一些经验，就当时对自己工作的总结和回顾吧。内容比较散，段落比较乱，但是随想随想，就是想到哪里说到哪里嘛
    今天的随想，就聊聊自动化测试如何开始的问题。
    相信每一个正在看这篇文章的朋友，都很有可能已经或者准备做自动化测试，为了讨论方便，我们对自动化测试做个限制，本文中出现的所有的自动化测试，都指的是UI层面的功能自动化测试。OK，我们继续。估计有很多人都在踌躇满志的准备开始做自动化测试，可是却迷惑于不知道从哪里入手。想想当初我也碰到过这样的迷惑，那么当一个公司或者组织开始实施自动化测试时，要从哪里开始呢？我的回答是，就从你第一个有意义的脚本开始，强调一下，从第一个有意义的脚本开始
    作为一个测试设计优先论者，我的这个观点似乎有点矛盾，难道自动化测试不是应该从测试设计开始吗？其实二者不冲突，事实上很多测试团队或者公司决定去做自动化测试的时候，往往已经有了一定的测试积累，手工测试的经验非常丰富，但是大家都已经对发版疲于奔命了。这种情况下大家最希望的就是能减轻回归测试过程中重复的工作。希望脚本能被尽快开发出来，尽快投入使用，而且要有一定的健壮性，最好还无人值守，运行完毕后能给出测试报告，如果能跟自动构建衔接起来就更好了，我们还要做一个框架，我们要用自动化测试跑遍所有的功能，我们要……不过先等等，别忘了，您所在的公司以前一点自动化测试的经验都没有呢，一下子做这么多的功能难度太大，怎么办？先从一个最简单的有意义的脚本入手。再次强调，不管你的第一个自动化测试是多么简单或者是多么复杂，它必须是有意义的，就象JAVA的第一个Hello world那样，它能正确的执行，而且确实节省你的测试工作量。
    反正是随想，就想到哪里说到哪里，为了更好的进行情景讨论，我们来创造一个虚拟的测试团队，每一个人都是这个团队里的测试人员，包括我也是。假设我们这个团队每天都在不停的发版，大家每天都在不停的执行重复的测试工作，结果还是总有遗漏的BUG，客户给老板打电话，老板给项目经理打电话，项目经理给测试人员打电话：怎么老有BUG，周六过来加班~！擦，再这么下去真的会屎人的。所以我们必须做自动化测试。
    第一周，团队里热情高涨的下载了Watir，可是傻眼了，这破东西没有录制功能，而团队里又没人会写RUBY脚本，哇擦~！于是大家又换了QTP，哇，有录制功能~！那就速度开搞，于是十多个人一天的工夫录制了几百行代码，一运行，报错？我擦~！没做参数化……于是参数化，增强脚本，再运行，哇，能运行通过了哈，但是还没高兴多大会儿，似乎又有了个问题，这些脚本只是运行了，但是没有检查点……好吧，大家再七手八脚的加上检查点，再运行，好了，现在自动化测试能运行了，也能检查了。于是我们编译了个测试版本，高兴的把脚本挂上就下班了。期待着下周我们不用再测试那么多的重复用例了。
    第二周，进入办公室，大家兴冲冲的打开电脑看自动化测试的报告，哇擦~！差点没把电脑砸了，竟然有一半的脚本失败了，查原因原来是测试对象没有找到，还有些脚本失败是因为测试数据被污染了，小A使用guest用户登录，可是小B的脚本中却把这个用户删除了，导致小A的用例脚本都失败了，另一些用例则是由于开发改了界面。而测试通过的那些脚本，也没有覆盖多少核心功能，都是一些很简单的检查点，看看发版进度表，大家叹了口气，还是先执行手工用例吧。
    聊到这里我们暂停一下，先来看一下这个虚拟的自动化测试过程，毫无疑问这是一次失败的自动化测试。大家花费了一个星期的时间，开发出来一堆测试脚本可是却没能提升大家的工作效率，虽然这是一个虚拟的场景，但是相信大家在做自动化测试的时候，多少能有种似曾相识的感觉。为什么？为什么我们第一次的自动化测试会失败。
    原因一：缺少规划。在动手写第一个脚本的时候，我们要思考以下几个问题，我们希望自动化测试覆盖哪些测试点，我应该执行哪些检查才能证明这个测试点是正确的。这几个问题是自动化测试的核心问题，如果这两个问题没考虑清楚，写再多的测试脚本也是白搭，到最后只是在做无用功，不会有任何的效果。
    原因二：缺少协调。搞自动化测试不能靠人海战术，一窝蜂全上往往会使过程变的混乱并且难以控制，在编写脚本的过程中，如果各个测试人员只写自己的内容，那么最后整体运行时结果一定是非常惨。所以我们要弄清楚以下几个问题：1、根据测试点，我们要写哪些测试脚本；2、为了保证各个测试脚本的独立性，我们要如何设计脚本的操作；3、我们如何准备测试数据；4、我们需要在多长的时间内完成。这其实是对自动化测试过程的管理。其中脚本的独立性至关重要，它意味着一个脚本的运行不应该依赖于其他任何的脚本，也不会影响其他脚本的数据环境；
    原因三：缺少必要的技术积累。做自动化测试用录制？还是尽快放弃这个念头吧，除非你能很好的规划你的测试对象库，不然到后期，光是对象库的维护就足以让你放弃自动化测试。为了实现自动化测试，我们需要一批既有测试思想又有一定开发技能的人员去编写脚本。一个好的脚本开发人员3个小时的工作效率，远远超过10个使用录制功能开发脚本的测试人员（我承认这个观点有点偏激，但是我确实是这么认为的）。
    原因四：测试脚本不够健壮，缺乏必要的容错性。这个就不多说了，写过自动化测试的人对这一点应该都有感触。没有感触的人可以去写上一两百行的脚本每天执行，跑上一个月，很快你就能明白我说的意思了。
    原因五：公司对自动化测试的定位。在我们的虚拟场景中，大家是因为受不了重复工作才想到自动化测试，其实这已经晚了。自动化测试应该未雨绸缪，早做准备，但是这个也不多说了，按照国内软件公司的风格和做事习惯，这一点说了也白说……
    OK，总结完了，现在我们重新来做自动化测试：

首先，我们明确了测试目标是逐步实现核心功能的自动化.
其次根据这个目标我们明确了这周自动化测试要实现的测试点是表格数据的保存和运算，
然后根据这个测试点我们设计了N条测试用例以检查正向和反向的情况；
接着我们规划了我们的测试脚本，我们重新设计了操作步骤以防止脚本之间互相影响；我们准备了测试数据以支持脚本的验证，我们甚至参考IBM的ITCL框架，决定将脚本划分成对象层、操作层、用例层，
我们明确了团队的工作模式：我们挑选了几个编程基础比较好的人去负责专职实现自动化测试，
我们也和项目经理沟通好了，他也同意抽出一两个专职的测试人员来实现自动化测试，并且要求开发人员不得随意更改界面，以保证自动化测试在发版阶段的稳定性。
最后在工具的选择方面，为了提高脚本的开发效率，我们决定使用RFT，并且约定不再使用录制功能以提高脚本的可维护性（其实录制用好了脚本一样很好维护）。
我们确定了脚本的运行模式，决定每天晚上下班前开始执行自动化测试，第二天来看结果。至于自动构建，决定放到下一个阶段再考虑（量力而行，第一次不要贪多贪全）

   现在所有的事情看起来都井井有条了，但是貌似还是有很多的问题没考虑清楚，或者我们由于缺乏经验不知道应该怎么做。那么这个时候我们应该开始做自动化测试了？我的回答是完全可以~！因为我们已经在自己的能力范围内考虑了所有的问题，做了尽可能充足的准备，现在就要迈出最关键的一步：按照我们对自动化测试规划，完成我们第一个有意义的测试脚本，并且能让它执行起来。想知道水有多深，唯一的办法就是踩下去
   于是接下来的一段时间，每天就是上班、写脚本、调试、下班、执行脚本……上班、写脚本、调试、下班、执行脚本……
    两个星期以后，第一阶段的测试用例完成了，我们实现了核心功能中表格数据的保存和运算的自动化测试，终于再发版本的时候，不用再苦逼的盯着屏幕像僵尸一样录数据了。节省的时间我们可以去规划下一阶段要实现的功能点，补充测试用例，然后再提交给写脚本的那几个人，一起看起来都步入正轨，并且开始变得美好了。这可以说是自动化测试一个比较成功的开始。
     正所谓万事开头难，第一次做自动化测试也是这样，切忌一上来就拿着测试工具昏天黑地的录脚本，我们应该也必须先做规划，想清楚要做什么了，考虑一下怎么做，然后剩下的事情就是去做，just do it.