灵魂直击，软件测试岗是否会消失？

lsekfe

　　软件测试岗未来是否会消失？这是一个问题，因为它决定了软件测试人员这个群体未来会走向哪里？作为测试群体的一分子，笔者认真梳理了这个问题并得出个人观点，供各位测试同仁参考。
　　一、软件测试的由来
　　1936年，英国数学家阿兰·麦席森·图灵提出一种抽象计算模型：图灵机。科学家将带点的卡片纸传递给图灵机，图灵机通过计算给出计算结果。这一时期的软件多以计算为主，规模小复杂度低，尚未出现专职测试员。
　　1957年，美国科学家约翰·巴科斯开发出第一套高级编程语言Fortran，Frotran被广泛应用在科学计算领域，这时的Frotran程序有主程序和子程序的概念。同时由于摆脱了卡片纸的约束，程序的代码规模呈现出几何级的增长。如何证明程序是正确的、完备的，就成了一个无法回避的问题，测试活动由此而诞生。软件测试不同于调试，软件测试旨在发现软件的缺陷，其目的是要鉴定软件的正确性、完备性。
　　这么看来，软件测试活动存在的原因是因为程序代码规模的增加和复杂度的提高。看似合理实际不然！笔者大学期间曾参与开发了一套学院选课系统，该系统前台有二十多个功能，后台有十几张数据库表。这套选课系统与早期的Frotran程序相比，代码规模和程序复杂度都高出很多。但是，我们却并没有软件测试活动这个环节。原因很简单，因为这个程序没有真实客户，学生算真实客户吗？答案是不算，如果学生A使用选课系统出现异常，我们会告诉A你的操作有问题，你应按操作说明再试一遍或者重启下电脑。假如我们有时间、有精力，我们会排查并修正这个异常。
　　因为没有真实客户或者我们不关心使用者是否会喜欢我们的系统，是否会不用我们的系统（实际他们也不得不用），所以我们也不担心这个系统是否会在某一时刻出现异常，是否会流失这些使用者。
　　然而，这些在商业社会却行不通。商业社会中，如果一个软件没有客户，那么这个软件就失去了存在的必要性。一个未经过严格软件测试的程序冒然投入商业社会，那么软件上线之日就注定会丧失客户。没有客户就意味着没有收益，没有收益软件开发活动就无以为继。所以软件开发离不开软件测试活动。
　　概括而言，软件测试活动本质上就是服务客户。给客户提供一个操作便捷、功能强大、运行平稳的软件，营造一个良好的用户体验是软件测试活动追求的重要目标。
　　二、软件测试的发展
　　早期的软件测试活动以手工测试开展，随着软件行业的迅猛发展，软件规模和复杂度日益剧增。如何更好、更快的将软件投入市场，抢占商业高地，吸引更多客户成为软件开发项目团队不得不考虑的问题。
　　应对这一问题，纯手工测试方法就需要投入更多的人力、物力。受限于人力的投入极限，软件测试活动压缩有限。受限于测试人员技能层次不齐，软件质量无法有效保障。
　　为了更好的解决这一问题，人们开始尝试借助于一些小工具辅助测试工作。这就是自动化测试的萌芽。随着此类辅助工具功能的不断增多和相关理论的不断完善，接口自动化测试应用而生。
　　接口自动化测试的工作原理是通过接口测试工具模拟客户机向应用服务器发送服务请求报文，应用服务器解析请求报文。然后加工数据，将加工结果放在应答报文中发送给客户机。
　　这种测试方式主要用于测试系统间和系统内部各个模块之间的交互关系和处理逻辑是否正常。其重点关注数据交换和逻辑处理，缺乏对UI层的测试。而UI界面恰是用户直观面对的，是用户体验产品的直接入口。忽视了UI测试就会造成测试链条的断裂和无法保障的用户体验，这极易造成用户的流失。
　　为了解决这一问题，界面自动化测试应运而生。界面自动化测试是从用户角度出发，通过识别界面元素对象，然后调用元素对象其相应操作，模拟用户输入、点击等操作。
　　接口自动化测试和界面自动化测试共同组成了自动化测试，自动化测试是对手工测试的补充和升级。自动化测试的出现使得测试活动和软件开发活动达到真正意义上的并行进行。通过一些自动化测试技术和框架，项目团队可以轻松搭建出适合自己系统的自动化测试平台。借助这些测试平台，编码完成的程序可以达到即测即得。这极大压缩了测试活动工时，提高了测试响应速度。
　　为了进一步向客户提供更好的产品体验，测试活动也由单纯的功能测试扩展出性能测试、安全测试和用户体验测试等。
　　三、测试岗位的未来
　　持续不断升级的软件测试活动促使软件测试方式从纯手工测试演化到现在的手工测试+自动化测试，以及未来可期的智能化测试。
　　不同的测试方式催生了不同的测试岗位。按照测试方式划分，测试岗位分为使用手工测试的测试工程师（TE）和使用自动化测试的测试开发工程师（SET）。从测试内容上看，测试工程师侧重承担功能测试（手工执行）、用户体验测试。测试开发工程师侧重承担功能测试（自动化执行）、性能测试、安全测试。
　　TE or SET 那一个会是软件活动下一阶段持续推进的关键？或者说哪一角色在软件活动未来的持续升级中不可或缺？
　　《Google的软件测试之道》对测试工程师的定义是评估软件应用对用户的影响以及软件产品整体目标上的风险，是一种面向用户的测试角色。从笔者的项目经历来看，测试工程师是在程序开发完成后执行测试。主要两大职责是：1）检测程序质量，验证项目活动是否可以进入验收环节；2）从用户角度体验产品（用户体验测试）。
　　从时机上来看，测试工程师在产品开发完成后进行测试。测试活动作为一个独立的阶段存在，这就天然造成了项目开发周期的延长。在软件产品竞争日趋激烈的商业环境中，意味着产品会流失更多潜在客户。近年流行的敏捷开发主要目的就是通过进一步压缩项目周期，提高产品迭代频率，适应日新月异的客户需求，进而获得更多客户青睐。从这种大趋势上看，测试工程师已丧失时机优势。
　　从职责上看，测试工程师职责一是：检测程序质量。随着CMM、DevOps这类软件过程管理标准的不断完善和自动化测试在软件开发过程中的深度嵌入融合，项目团队开发出的产品质量日却稳定。使用测试工程师检测产品质量，判断是否可进入验收阶段已变得不再必要；测试工程师的职责二是：用户体验测试。用户体验测试的内容和业务（产品）人员完成的业务（产品）验收测试内容存在高度的重合。
　　归纳而言，从时机和职责角度看，测试工程师这一角色存在的必要性在逐步降低。未来商业公司从节约成本等现实角度从发，完全可以将测试工程师的角色任务分解给业务(产品)人员和测试开发工程师。
　　《Google的软件测试之道》对测试开发工程师的职责描述是通过开发适合自身系统的质量测试平台，验证程序功能的正确性。从笔者的项目经历来看，测试开发工程师在软件开发工程师进行详细设计时就开始开发自动化测试案例和工具，测试活动深度嵌入开发过程，与开发人员并行开展工作。当前的测试开发工程师在完成系统功能测试之余，通常还需承担项目的性能、安全测试等。
　　从时机上看，测试开发工程师的存在，使得测试执行可以不用作为一个单独的活动阶段存在。这大大缩短了项目的开发周期，适应日趋激烈的商业环境，适合主流的产品迭代要求。
　　从职责上看，业务（产品）人员通常不具备功能测试（自动化方式）、性能测试、安全测试技能，无法替代测试工程师的职责。经过系列测试培训指导的软件开发工程师（SWE）具备替代测试开发工程师的能力。但是两者迥然不同的思维方式（SWE重创造，SET重破坏）和SET繁重的工作任务，使得现实中一名工程师无法同时肩负SWE、SET两类角色的任务。
　　更重要的是当前的自动化测试尚处于发展的初期阶段，自动执行自动核对尚未成熟，距离智能化测试相距甚远。自动化测试还有很长的路需要走，作为推动自动化测试前进的中坚力量，测试开发工程师在测试活动中的比重会逐步提高。此类岗位角色在未来很长一段时间内都具备不可替代的重要价值。
　　四、总结
　　以上是笔者根据个人项目经历和认识得出来的观点，笔者的个人建议是身处测试工程师岗位的同事在完成手工测试之余通过积累自身的业务知识转型成一名业务（产品）人，或者扩展编码、自动化测试相关技能化身成一名测试开发工程师。对于身处测试开发工程师岗位的同事建议不断提高自身技术、扩展测试技能，适应未来不断发展进步的软件测试活动。
　　以上是笔者根据个人项目经历和认识得出来的观点，目的是警示和指引广大测试同行尽早做好自身职业规划。诚挚的建议身处测试工程师岗位的同事在完成手工测试之余通过积累自身的业务知识转型成一名业务（产品）人，或者扩展编码、自动化测试相关技能化身成一名测试开发工程师。对于身处测试开发工程师岗位的同事建议不断提高自身技术、扩展测试技能，适应未来不断发展进步的软件测试活动。
　　无论如何不断学习和进步才是我们应对未来风云变幻的关键，现在扩展的每一种业务、技术能力，都是为未来准备的一条可选之路。

Miss_love

慌。。。