随着软件和互联网行业的发展，软件测试正受到方方面面的机遇和挑战。从技能层面上讲：领域知识、测试工具、测试思维、自动化测试框架、编码技能…..等等方方面面都有待提升，又都无法一蹴而就；从职业发展跑道的角度上来讲：管理通道、技术通道、甚至扩岗位转型都是可以考虑的，但也无一坦途。测试人员大脑被各种的思潮不停拍打着…..测试会不会死掉？我们到底应该怎么走？从当前从网上的各种分享渠道来看，理性的观点应该是：测试岗位可能会死掉，但是测试的职能不会死掉。大牛们建议给测试人员的发展提升方向主要是：测试工具与技术、测试思维、测试策略。在我看来这三个都是测试人员的关键提升方向，三者并不是谁替代谁的关系，而是应该选择合适的学习路径全面提升。但无论选择何种学习路径终极的修炼一定是思维。
一.软件开发和测试中的一些现象：
我们先来看看测试和开发工作中的一些现象：
做测试设计的时候，很多人会沉迷于输出大量的测试用例。比如，在测试网络设备端口工作模式的时候，本端端口、对端端口所支持的工作模式、介质类型两两组合，输出茫茫多的用例，乐此不疲的Copy、Paste，测试执行和工作汇报的时候似乎也很满足与自己的工作量。而后呢？当新的测试测试任务增了不同的硬件单板，增加了更多的接口类型和工作模式之后呢…..？类似这样的例子还很多，我们都很辛苦,加班很多，但这样自己的成长在哪里？那这里究竟缺少一个什么能力呢？
还有些测试人员（包括曾经的我），认为测试用例的编写应该事无巨细，尽可能的详细，在用例步骤中应该尽可能的清晰的描述清楚每一个细节，让任何新手一看就能够明白该怎么测试。在以往非敏捷研发模型的大背景下，一个版本交付周期20几天甚至1个月的情况下，其实时是OK的，即使你拿出3-5天做测试设计测试时间还是足够的。但学习了邰晓梅MFQ 的TestCondition后，我发现一个用例其实并不需要展现每一个细节，只需要将其重要的覆盖场景、覆盖数据或其他条件参数清楚就可以了。在敏捷大背景下应尽可能减少测试设计过程中文本化编写的时间，把时间归还给测试人员，让他们有更充足测试执行和思考的时间，价值更大。那么从事无巨细的的脚本化用例到TestCondition的转变过程需要的是一种什么能力呢？
在开发过程中，让我看到了更多软件设计与实现方面现象：大量的配置约束脚本，在增一个单板类型的时候所有脚本都要进行维护，缺少的是什么？还是新增单板，只是变更了底层BSP，但依然波及着上层协议栈，这里面缺少的是什么？一个原本清晰的代码逻辑，在做了若干年的需求之后，代码架构已经丧失了层次感、变得理不清脉络故障难以定位了，缺少的是什么？
对，缺少的是抽象！
测试人员的测试设计需要抽象出什么是测试逻辑？什么是测试数据？什么是测试条件？使得测试用例具备可复用性。作为软件开发人员抽象能力更是必不可少。”设计模式”里面就提到了要基于“抽象编程”，这样才能减少耦合，使得程序的可维护性和可扩展性更好。
可见，当测试人员还在纠结自己到底应该继续走测试的道路还是应该转型做开发是不是更有出路的时候其实你更应该修炼的是抽象能力。抽象能力是你在不同行业和岗位可无缝平移的重要技能之一。
下面我从：架构、设计和执行三个维度来横向对比一下开发人员和测试人员都应该具备的抽象能力：
二.架构层面的抽象：
无论是软件开发活动还是软件测试活动，在架构从层面上都应该是有抽象的。我们最常见的一种抽象就是进行分层。第一次听到分层的概念是在学习TCP/IP的5层和OSI的7层网络模型如下图所示：
图2.1 网络分层模型
这两个都是经典的网络模型，从提出到现在40年以上了我们依然可以看到当前从大到一个复杂的网络，小到一个网络设备的设计实现，都在从抽象层面上遵循着这样的分层的规律。它的核心思想是：
从下层到上层，每一层为上层提供提供服务，上层依赖下层所提供的接口，各司其职专注其应该做的事情。
其实这样的分层理念在任何行业都是适用的，具有普适意义：
2.1 软件开发领域的分层：
DDD（领域驱动设计）是当前炙手可热的的软件开发范式。在DDD里面就提到了4层分层模型，如下图所示：
图2.2 领域驱动设计分层模型
DDD四层模型将整个软件分为了:用户界面层(User Interface Layer)、应用层(Application)、领域层（Domain Layer）、基础设施层(Infrastructure Layer)。
其中：基础设施层提供通用的技术能力。如：网络通讯接口、数据库接口等；领域层是站在用户和应用的角度抽象出来的软件的核心概念，它是众多领域对象、聚合的集合，领域层的设计力争做到软件真实应用的领域模型和设计模型的一致；应用层要定义软件要完成的事务，事务的实现依赖领域层的支持；用户接口层也就是提供软件给用户的界面呈现。
DDD四层模型的核心是领域层，但我们看到了它和TCP/IP层次模型同样理念。DDD对整个软件每个层次职责定义和聚焦点是定义十分清晰和明确的，保证每个层次做好它该做的事情，并为上层提供着支持。
2.2 测试领域的分层和分级：
复杂的软件设计，会将软件从函数/类单元、模块、组件、子系统、系统这样从微观的层级进行划分。我们测试随之也会有单元测试、集成测试、系统测试、甚至是系统集成测试，这就是我们的测试分层。而按照邰晓梅的MFQ理论每一个分层我们又可以进行分级：单功能（M）、功能交互(F)、整体上的质量属性(Q)。单功能验证更偏向LLT(Low Level Testing),而Q更偏向于HLT(HIGH Level Testing),如下图所示：
图2.2测试分层分级
不同测试分层体现的是不同的测试视角的融合；在大公司里不同层次的测试工作可能还是由不同团队来完成，它体现的是不同团队的协作；分工之后各个团队也可以更聚焦自己做的测试工作。
总结：
无论测试人员还是开发人员，在面对复杂问题时一定要具备层次化思考的习惯，要学会切蛋糕，并将蛋糕进行有效的分配和协作。
三.设计层面的抽象：
设计层面的抽象，我们通常见到的是将自己具体工作对象进行模型化的梳理。模型的使用可以参考，但不存在最佳实践。
3.1软件开发领域的模型(模式)：
软件开发领域中提到模型，我第一反应想到的是“设计模式”中提到的23种常用设计模式。它们都是为解决具体设计问题提供的一种参考，比如：
工厂模式：
图3.1 工厂方法类图（摘自《大话设计模式》）
给所有”产品”抽象出一个公共的接口，工厂类根据需要实例化不同的”产品”。它抽象出产品创建接口。业务代码可以依赖工厂接口进行编码。解决了 当“产品”种类扩展时对于其他业务代码的修改和波及问题。
中介者模式（Mediator）：
图3.2 中介者模式（摘自《大话设计模式》）
用一个中介对象来封装一系列的对象交互，中介者使得各对象不需要显示的相互引用，从而使其松耦合，而且可以独立地改变他们之间的交互。它解决的是对象间的复杂引用和交互问题。
我们可以看到“设计模式”，它是软件开发中对具体事务进行分析后进行抽象的一种选择。软件设计有了合适的模型可以使软件更合理的构建，软件才能做到：可维护、可复用、可扩展。清晰的模型也更加便于不同开发人员之间的交流。
3.2软件测试领域的模型：
在MFQ理论中，我们有着一套对被测对象的建模的方法：P:Parameter ;P:Proccess D:Data C: Combination S:State。
比如：在通讯协议行业的软件测试中，对于有状态的协议测试采用S:State的模型进行建模比较合适。例如下面的 ARP协议的基于状态的建模：
图3.3 ARP协议基于S-STATE建模
表3.1 ARP协议基于S-STATE建模
在对被测对象进行建模的时候着重分析和考虑它所体现出来的外在特征选取合适的建模方式，这个建模的过程即是对被测对象抽象理解的过程。但并不代码它只能用一种建模方式，任何一种建模方式也很难涵盖它的方方面。同样好的测试模型也便于团队内部的交流和评估。
总结：
无论是开发还是测试，对被测对象都需要对所工作的对象进行分析和学习，而分析和学习的产物之一就是模型。前人为我们留下了许多经典的模型、模式我们可以根据工作对象的特征进行选取，但并不代表这种选择是唯一的，只要能更好的解决问题我们也完全可以提出自己的模式或模型，而真正的高手更是能达到“无招胜有招”的境界。
**
四.执行层面的抽象：
**
执行，在汉语词典中的解释是：贯彻施行;实际履行。
从字面上就仿佛告诉我们，执行工作存在着一张有形或无形的Paper，让你完全遵从它一步一步去履行，它像由机器去执行一段固定的脚本那么的机械。然而无论是测试还是开发领域，目前都有着这么一些实践不那么遵循Paper却做的似乎也非常成功。
执行层面的抽象，我想讲的是跳出脚本化去追寻事物的本质。
4.1开发编码过程中的抽象：
传统的研发流程开发人员可能习惯于等待，等待完善的架构和方案，然后再按照Paper进行编码。然而，好的架构不是设计出来的。需求是不断变化甚至一开始都是无法明确的，开发人员又如何能期待拿到一张靠谱的Paper包治百病，永远Match住不断变化的需求呢？
所以最新的研发思维是TDD，认为好的架构是“重构”出来的。基于满足实例化的需求、用户故事的测试用例永远写出刚刚够用的代码。最求完美的架构和方案并不是实物的本质，快速响应变化，抓住用户的应用场景为用户提供价值是我们做编码的本质。在重构中我们不断的满足变化的需求，也不断的提炼出我们的架构。
当然在最求为用户提供价值的同时，也同样要考虑团队内部的成本和价值。有的人会说，不是尽快的给用户提供价值就行了吗？还要什么重构？还要什么抽象？有新需求代码Copy,Paste一把；加个功能宏塞代码；运行状态梳理不清楚了加个标志位（全局变量）；那么长此以往………..我想说的是那么多程序员加班不是为了理想而只是为填坑。长期处于填坑状态的程序员，必定会处于一种“稀缺”状态，会导致认知带宽急剧下降（稀缺，认知带宽的概念，请参考《稀缺》这本书），埋下更多的坑。这样填坑式的加班对于客户和项目都没有任何的价值。
4.2测试执行过程中的抽象：
从测试的本质上来说：测试是为了发现缺陷而不是为了证明软件没有缺陷。《软件测试的艺术》也在测试心理学的章节中提到了“测试是为了发现错误而执行程序的过程”。
简单说就是发现聚焦风险的缺陷才是硬道理。
测试用例精美与否，文档漂亮与否都不是关键问题。我们说到了需求是变化的用户场景也是变化的如果能够要求一份一成不变的Paper就能满足所有测试的需求？基于上面提到的两个方面ET探索性测试被越来越多的提起。ET更注重测试人员的测试思路；信息的及时反馈；策略的及时调整；而不是让文本化的工作占据大量的精力，更不是用例机械化的执行限制了自己的思路。
当测试人员在每个测试周期一遍一遍的重复执行测试用例而逐渐开始发现没有任何斩获的时候，是否还是还应该还是为了测试执行率，覆盖率进行机械的执行呢？答案是否定的，执行用例并不是测试的本质。本质是发现更多的缺陷。比如，在项目生命周期的中期，按照《软件测试经验与教训》那本书中提到的缺陷率“倒浴盆曲线”那样,你应该尝试的是新的测试策略来保持持续的缺陷发现率，采用新的工具、手段，收集新的测试Idea进行探索。
总结：
正如《简单思考》一书中的观点：“排除表面价值”，实现真正的简单思考就是要“抓住本质，精简一切”。作为开发人员，本质就是持续交付内/外部价值，降低成本。而测试人员的价值就是尽可能早、多的发现产品缺陷。这样你才能从繁杂的事务中正确的应用你有限的精力。这样的简单思考的抽象思维，无论是测试人员还是开发人员都是需要的。
最后，我想说的是与其焦虑测试人员的未来，不如先力争从测试技术、测试策略、测试思维这三个维度努力让自己成为业界的专家再说，修炼到高阶之后重点在思维；任何一个行业无论处在什么阶段，你要能站在金字塔的顶尖总不会混得太差。多学习一些除了测试之外的“软技能”。不仅仅是大家熟悉的沟通力、表达力….。在互联网P to P时代的个人分享能力；个人营销能力；如何技术换资源？资源建平台？….这些都是要成功的重要技能。