随着被测系统越来越复杂，规模越来越庞大，测试的工作量也越来越大，这也必然会暴露出人和测试生命周期内时间的冲突。为了更加快速、有效、可靠地对软件进行测试，提高被测系统的质量，测试工具和工具思维也就必然会被引入到测试工作中，自动化测试也自然而然地引入到了测试工作中。
随着IT从业领域的不断深入和复杂化，职位细分也越来越复杂。从一开始的开发、测试、运维、DBA等一系列工作于一身的软件"英雄"，到现在已经细分到开发工程师、测试工程师、运维工程师、测试开发工程师、开发运维工程师和测试运维工程师等职位，如图1-6所示。
图1-6 职位细分趋势图
软件工程师英文是Development（Software Engineer），是从事软件开发相关工作的人员的统称。它是一个广义的概念，包括软件设计人员、软件架构人员、软件工程管理人员、程序员等一系列岗位，工作内容都与软件开发生产相关。软件工程师的技术要求是比较全面的，除了基础的编程语言（C语言/C++/Java等）、数据库技术（SQL/Oracle/Db2等）等，还有诸如JavaScript、AJAX、Hibernate、Spring等前沿技术。
运维工程师(Operations)负责维护并确保整个服务的高可用性，同时通过不断优化系统架构、提升部署效率、优化资源利用率提高整体的ROI。运维工程师面对的最大挑战之一是大规模集群的管理问题，既要管理好几十万台服务器上的服务，又要保证服务的高可用性。
质量保障工程师QA）指理解产品的功能要求，并对其进行测试，检查软件有没有缺陷（Bug），测试软件是否具备稳定性（Robustness，又称鲁棒性）、安全性和易操作性等性能，写出相应的测试规范和测试用例的专门工作人员。简而言之，软件测试工程师在一家软件企业中担当的是"质量管理"角色，及时发现软件问题并及时督促更正，确保产品的正常运作。
随着细分领域的不断发展，出现了承担开发和测试交叉工作内容的角色--测试开发工程师；承担开发和运维交叉工作内容的角色--开发运维工程师；承担测试和运维交叉工作内容的角色--测试运维工程师。由于3个角色交叉的工作在现在的大型项目中不太容易出现，因此，如果有这部分工作，那么只能需要一个"超人"一样的角色完成。
分层自动化测试这个概念最近曝光度比较高。传统的自动化测试更关注产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试，如图1-7所示。
图1-7 分层示意图
相信测试人员对图1-7所示的"金字塔"结构并不陌生，这也就是对产品开发不同阶段所对应的测试。我们需要规范地进行单元测试，同样需要相应的单元测试框架，如Java的JUnit、TestNG，C#的NUnit，Python的unittest、pytest等，几乎所有的主流语言，都会有其对应的单元测试框架。
集成、接口测试对于测试新手来说不太容易理解。单元测试关注代码的实现逻辑，如一个if分支或一个for循环的实现，而集成、接口测试关注的是一个函数、类（方法）所提供的接口是否可靠。例如，定义一个add()函数，用于计算两个参数的结果并返回，那么需要调用add()方法并传参，而后比较返回值是否为两个参数相加之和。当然，接口测试也可以是以URL的形式进行传递。例如，通过get方式向服务器发送请求，那么发送的内容作为URL的一部分传递到服务器端。但是，如果Web Service技术对外提供一个公共接口，那么需要通过SoapUI等工具对其进行测试。
关于UI层的自动化测试，有些读者可能非常熟悉，因为大部分测试人员的大部分工作都是对UI层的功能进行测试。例如，如果不断重复对表单提交、结果查询等功能进行的测试，那么可以通过相应的自动化测试工具来模拟这些操作，从而避免重复的操作。UI层的自动化测试工具非常多，目前比较主流的是QTP、Watir和Selenium等。
图1-7为什么要设计成一个金字塔结构，而不是长方形或倒三角形呢？这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从来没有进行单元测试与接口测试，只进行了UI层的自动化测试，那么这是不科学的，很难从本质上保证产品的质量。如果用户企图实现全面的UI层的自动化测试，那么不仅浪费了大量的人力和物力，而且最终获得的收益可能会远远低于所支付的成本，因为越往上层，其维护成本越高，尤其是UI层的元素会时常发生改变。因此，应该把更多的自动化测试放在单元测试与接口测试阶段进行。
既然UI层的自动化测试这样"劳民伤财"，那么只进行单元测试与接口测试？不可以！因为无论什么样的产品，最终呈现给用户的是UI层，所以测试人员应该将更多的精力放在UI层。也正是因为测试人员需要在UI层投入大量的精力，所以才有必要通过自动化的方式帮助测试人员"部分解放"重复的劳动。
在自动化测试中，测试人员最怕的是变化，因为变化的直接结果就是导致测试用例的运行失败，这时就需要对自动化脚本进行维护。如何控制失败，以及降低维护成本，对自动化测试的成败至关重要。换个角度讲，一个永远都运行成功的自动化测试用例是没有价值的。
到了这里，读者对自动化测试应该有了一定的了解。但是，可能有些读者依然不知道如何下手和提高技术能力。因此，现在开始介绍如何提高技术能力。从软件测试入门，学习各种技术，然后到达一个比较好的职位，功能测试是这样一个过程，自动化测试也同样是这样。图1-8给出了一个学习成长路线，也许不完全适合你，但是希望对你有所帮助。
图1-8 成长路线
测试开发主要的工作内容就是完成和维护自动化测试相关工作。自动化测试就是通过使用或者开发测试工具、测试框架、测试系统和测试平台，按照测试工程业务测试的流程、计划以及预期对被测系统进行测试的过程。自动化测试也是软件测试的一个重要组成部分，自动化测试和业务测试既不能相互完全替代，也不能完全相互分离。正确合理地利用自动化测试手段，结合业务测试流程和执行，能够提高测试效率和测试覆盖率，从而保证软件的质量，缩短开发到发布的周期，提高交付频率，节省工期、人力成本。
自动化测试涉及测试流程、测试体系、测试规范、测试方案、自动化的执行测试、自动化的测试环境治理等多方面，既有技术的问题，又不仅仅只有技术问题。自动化需要长期投入，存在专门团队建立、维护，以及发展自动化的流程、体系等内容。自动化测试的优点如下。
1)模拟人工测试流程，减少重复机械测试工作，让机器执行固有流程，提高执行可靠性。
2)提高测试的精准度，提高测试执行范围，针对海量参数的测试，机器执行效率会更高。
3)更好地利用测试资源，将复杂、烦琐的测试流程交由机器执行，可以让测试人员有更多的精力去关注质量保证方面的问题。
4)自动化测试具有可重复性和测试一致性。
5)提高测试用例的复用性。
但是自动化测试不是测试效率提升的关键，自动化测试也存在其不可避免的劣势和局限性，因此，在如下一些方面并不适用。
1)永远不会再重复的测试流程。由于维护一套自动化测试脚本或者流程需要投入很大精力和成本，因此仅仅测试一次永远不会再次出现的被测流程并不适合自动化测试。
2)项目工期非常短的需求。由于准备一个新流程的测试脚本的时间会远远大于业务测试执行时间，因此，在工期并不充分的情况下，业务测试手段保障测试质量会更直接、更迅速。
3)UI的易用性等测试并不适合自动化测试，因为UI设计的美化、交互是否符合人的固有习惯目前是机器无法评价的，还是需要业务测试人员直接参与。
4)实际软硬件结合场景并不适合。例如，需要无人机配送的测试，并不适合纯自动化完成全部流程。
5)任何技术有局限性，上述并没有完全覆盖所有自动化不适合解决问题的方面。
测试开发工程师是一个交叉工作的角色。与开发工程师相比，测试开发工程师除了要具备写代码的能力，还需要掌握操作系统、数据库、网络、软件测试等相关领域的知识；与业务测试工程师相比，测试开发工程师拥有编写测试脚本、设计测试框架、搭建测试平台、维护测试环境等技能，但是可能没有业务测试工程师那种专业的业务知识背景。测试开发工作，本质就是为了保证测试能够正确且顺利进行而做的工作。测试开发要服务于业务测试，测试开发不是脱离业务而单独存在的。在软件系统生命周期过程中，业务测试工程师和测试开发工程师是并存的，并不会一个替代另一个。生活服务技术平台质量管理组的转型也是由于工作需要，才逐渐地走上了转型这条路。那么，你为转型做好准备了吗？
相关推荐：
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
