自动化测试人员的定位

今天想谈谈工作中最重要的一个公司，在那里我度过了四年，经历了人生的两件大事，结识了很多小伙伴，但最重要的是对我工作生涯有很大的影响，在那里我转型成为了自动化测试工程师。

刚刚转行做自动化测试的时候，我其实对测试都只停留在理论阶段，对自动化测试更是没有了解过。于是边学边做，真的很感谢公司给了我这么一个机会。刚开始我认为的自动化测试很肤浅，只是利用程序模拟人工操作点击软件产品，对产品做冒烟测试和功能测试。在这个过程中主要是学习了自动化测试工具和了解了一下自动化测试框架。

后来也证明这个基础还是不错的，因为无论是我接触的第一个测试工具还是现在正在使用的测试工具，针对WEB测试还是针对Winform程序进行测试，对于我们自动化测试人员来说，原理是一样的，都通过一个渠道实现与页面元素进行交互，渠道是什么其实并不是我们需要关心的事，当然对于资深自动化测试人员了解一些更好的。举两个例子，现在大多数自动化测试是针对WEB页面的，Selenium webdrive获取页面源码后，通过多种定位器定位元素与元素进行交互。对于Winform程序自动化测试就比较复杂了，以delphi开发的程序来说，先获取到窗体句柄，再转换成delphi的类，一层层遍历找到组件，实现与组件的交互。而对于.net开发的程序这个渠道又不一样。

另外一个重点，自动化测试框架也是颇具有通用性的，首先给了我一个非常明确的概念——关键字。现在自动化测试基本离不开这个词，其实我认为关键字就是软件开发中的方法，实现一个或者一系列功能，但是它在自动化测试里就是叫作‘关键字’。总之，如果连关键字是什么都不知道，千万不要说你做过自动化测试。而据我后来接触的框架，基本上就是分成三部分：启动部分：解析Test suit——test case——test step——command，处理好分发执行；运行部分：调用关键字源码；结果部分：日志处理及生成报告。如果关键字封装得好，基本可以实现脚本与业务的分离，开发能力强的人专注于写好脚本，业务能力强的人专注于设计更合理的测试用例。但是其实这只是个设想，中间没有人协调的话，开发人员不知道业务人员需要什么样的关键字，业务人员也不知道关键字的用法，这个理念的实施感觉又会是一次理想和现实的冲撞。

所以个人认为，好的自动化测试人员其实是具备很基础的开发能力+优秀的测试能力，自己设计用例再用代码翻译过来。设计出好的测试用例，在不同的场景用不同的测试用例，才能达到最好的测试效果。说到测试场景我觉得很多人都忽略了这个事情。在工作中我发现很多开发人员一边指责测试人员做得少，一边完全不相信测试人员的能力所以不听测试人员的方案，其实这是用人大忌嘛，用人不疑，疑人不用才对呀。当然我自己做开发的时候也犯过这个错，但是我成长了嘛^.^。曾经参加过公司的测试用例评审，全程不是听开发人员和需求人员对测试用例的业务逻辑的补充，全程是在听开发经理教测试人员应该怎么写测试用例，其实总结他的话就是边界值法，划分等价类法要用起来，输入输出要明确得我一看就懂。但是在场测试人员包括测试经理没有人打断开发经理的夸夸其谈，最搞笑的是当他提出要从他们的代码出发写测试用例，都没有测试人员出来反驳。当时我都要绝望了，测试人员就是这样的没地位的存在了嘛.....还有一次跟一位开发经理聊天，他居然认为直接在服务器上做自动化测试很正常。我很想说这正常个什么呀，你见过这样的场景嘛....自动化测试虽然并不是以发现BUG为目标的测试，但是也不是说为了存在而存在的面子工程（现在很多互联网公司，只是需要有这个自动化测试的流程，用例质量怎样，覆盖率如何都不管），我想说任何测试，测试用例和测试场景都是核心！

扯完了刚开始的浅溥认识，说说深入点的自动化测试实施。后来工作中体会到自动化测试更好的发展是测试自动化以及daily build + daily test。在这个测试自动化过程中就涉及到更多的内容，以往观注的自动化测试脚本变成了一小块核心内容而已。先说说daily bulid+daily test，其实是需要一个可持续集成测试的环境，目前持续集成测试的工具也是有不少了，我本人涉及得不多，只知道jenkins。但在是工作中曾经自己用shell以及dos脚本加上C#编写的小工具实现了一套持续集成测试环境。所以综合自己的经验，我认为持续集成测试环境其实也是相似的。无非就是1、能够实现简易的自动化触发测试自动化流程。2、能够实现自动化update待测服务并正确启动。3、自动启动自动化测试脚本（包括单元测试和功能测试）。4、展示测试报告。有了这些基础，再优化一下周边其它功能，利用启动策略，邮件功能等，那么持续集成测试环境就成功了。至于测试自动化就会更多一点，还需要考虑到测试的服务端和客户端。随着docker等虚拟机设备的出现，自动的生成待测环境以及测试客户端也不是难题了。如果以上过程全部由自动化测试人员完成，那么对自动化测试人员的要求势必就会比较高一些，自动化测试人员以这个方向发展也就比较明确，或许会成为自动化测试架构师（有这个岗么？）可惜的是在工作中以上许多过程会被开发人接手完成，自动化测试人员还是停留在了观注自动化测试脚本上。本来这个现象也是我们接受的，但是存在一个问题，测试场景又被忽略了，开发人员只观注自动化流程能否走通，测试场景怎么安排他们也不管，最好是启动的时候把所有的自动化测试脚本全运行了。测试人员还不能提，提出了会被说，你那些小问题以后再考虑.....

当然现在还有一样比较大的软件公司，对员工分工更细致，会有测试开发岗，专注的可能是开发一些小的测试工具以满足测试人员的需求（对代码能力要求就会比较高了），达到提高测试效率的目的。这些工具可能包括开发自动化测试框架（现有的自动化测试框架RF，RAFFS等均可进行二次开发），用例管理软件，测试报告管理软件。实话是我没有从事过这个岗位，但本人觉得这个岗位对测试人员来说不是个好岗位，因为完全可以直接由开发人员担任。就算自动化测试人员担任了这个岗位，可能下一步他就会直接转开发岗去了。不过这个岗位可能有一个优势，相比刚刚提到的开发人员，更贴近测试人员，这样做开发工作的时候会愿意考虑到测试场景。

综上所述，个人认为自动化测试人员对自己的定位应该还是测试人员，开发能力应该是附加值（完全偏向开发后，离开发也不远了），更应该专注于写好的测试用例和设计合理的测试场景，将这些用例用到合适的地方，就是自动化测试人员的价值。

回顾自动化测试的四年时光，很感谢公司给我这样的机会，如果我还在坚持做开发，可能我不会有这么清晰的认识（因为本人比较笨，开发方向太多，内容太多，我把握不来，当然现在我也不能说自己方向把握对了，至少有了见解才可以一步一步摸索改正），也不可能几年内定位到高级工程师。

待续~~