在软件测试行业近20年的我，再来和大家谈谈今日的软件测试（软件测试行情怎么样）

2022年的钟声已经响过，1972年出生的我已经在这个世界上度过了整整半个世纪，时间如流水，都去哪了？好像昨天还刚刚从大学的校门走出，可是当时刚从大学殿堂呱呱落地的婴儿，现在都变成了IT界的主力军。我的称谓也由以前的同学、男孩，小顾变成了现在的大佬、大咖，甚至是老前辈，好多人认为我很成功，好厉害…，但是我自己知道我仅仅比现在的IT从业人员大几岁，多吃了几口盐，多过了几座桥罢了。

好吧，废话少说，我再和大家结合现在的情况谈谈软件测试，现在的软件测试和当年的软件测试不可同日而语，我当年进入测试部门正因为我的首任CTO是海归派，他与他的夫人当时都在美国硅谷学习和工作，他从事软件研发，而他的夫人从事软件测试，正因为他夫人的“教导”，使得他感觉到软件测试的重要性，所以在我们公司中开辟了独立的软件测试部，并且多次邀请他的夫人来公司作关于软件测试方面的普及，我也因为当时在软件测试方面表现出的特有气质，当选了软件测试部的部门经理，从而走上了软件测试之路，这一走就是整整20年之久，甚至会更长。

好，主题上场，我来谈谈我对现在软件测试的一些看法。

1.软件测试左右移

1）软件测试左移

a) 黑盒测试

关于软件测试的做用其实我在2001年刚刚从事软件测试的时候就提到过。当时我们开发了一个中国电信牵头的，名为“网上商品交易会”的项目（可惜这个最后放弃了，否则可能成为中国第一个B2B的平台），在这个系统中，包含了展会、展商、展位、展品几个实体，一个展会由多个展商参加；一个展商有多个展位（比如格力，包括家庭电器展位和办公电器展位）、一个展位下包括多个展品。我们测试人员在一开始就设计了这么一个测试用例：删除展位，试图查看展位下的展品；删除展商，试图查看展商下的展位和展品；删除展会，试图查看展会下的展商、展位和展品。大家如果学习过关系数据库，就会知道这属于关系型数据库的主外键关系。但是这个产品的产品架构师不太鼓励在数据库中加上外键锁，希望程序员在程序中进行控制。可是程序员在开发代码的时候，由于产品架构师没有过于强调，就把这个验证给忽略了，最后在项目末尾，出现了展品找不到展位、展位找不到展商、展商找不到展会这样的尴尬情形，只好打回，延期发布。如果在测试工程师书写完毕测试用例，由开发与测试一起坐下来进行一次测试用例评审，或者把这部分测试用例让开发测试工程师作为自测用例来执行，是不是就可以提前发现这个问题呢？记得济南的李龙同学提出了川模型软件测试模型，我在这里结合这个模型提出了洋葱软件测试模型，如下图：

最里面为冒烟测试用例，外面为开发自测用例（研发开发完产品代码，需要自己运行一次冒烟测试用例和自身相关的自测用例），外面是验收测试用例。最外面为所有测试用例，当然这些测试用例可以是手工的，也可以是自动化的。

b) 白盒测试

白盒测试包括静态白盒测试和动态白盒测试，在测试座用中，白盒测试起着至关重要的作用，我个人认为嵌入式软件是最难测的软件，而这种软件最重要的是做好白盒测试。对于静态白盒测试（包括Code Review和代码扫描），在这方面测试人员真的不具备优势，让专业的人作专业的事，所以这个我认为还是让开发人员自己来完成；动态白盒测试往往通过书写单元测试代码来实现，由于测试人员具有独特的逆向、系统、变向等思维能力，我认为应该让测试人员参与单元测试的设计。我当时在从事机顶盒软件测试产品，我们的CTO真是这样要求我们的，测试一个函数，对于函数中变量的空值，0值，非法值、边界值…，开发人员开始都是不考虑的。由于有测试人员与开发人员的共同参与，我们当时机顶盒的质量是非常高的（这算不算结对测试），可惜的是后来清华与上海交大争夺机顶盒的标准权（一个信号强，但是覆盖率低；另一个信号弱，但是覆盖率高），搞得两败俱伤，最后被IP TV取代，真是鹬蚌相争，渔翁得利啊（所以质量好，不代表销售就好，这需要公司各方面的努力）。

2）软件测试右移

在我刚毕业的年代，软件测试右移是想都不敢想的，现在随着分布式、大数据和人工智能的发展，使得软件测试右移成为了可能。软件测试右移说白了就是在生产环境中进行软件测试。下面来介绍一下测试有以下的几种技术（特别强调一点，在在线测试中，监控和告警是非常重要的）：

a) 灰度发布（又叫金丝雀发布）

在英国，由于金丝雀对瓦斯极为敏感，矿井工人携带金丝雀，以便及时发发现危险。在分布式系统中，我们可以通过将不太确定的新版本软件反挂在分布式系统的一个节点上，让少部分用户来使用，通过监控和告警来及时发现问题。当所有问题都解决了再逐步扩展新版本的发布。

在这张图中，绿色的为新版本，10%的用户使用这个版本，当所有问题都解决了，可以把新版本扩大到30%、50%、80%停顿一段时间，从而验证性能质量。

b) 全链路压测

在全链路压测中，分离测试数据和测试链路，测试数据放到影子库和影子表中，对试链路进行染色；测试完毕必须复原，删除测试数据和测试链路；当全链路测试过程中发现了问题，需要有良好的灾备机制，在灾备机制下，精确记录故障原因，并且尽快把环境恢复正常。

c) 流量回放技术

收集线上的流量数据，在线下回放。

d）混沌工程

混沌工程（Chaos Engineering）是在分布式系统上进行实验的学科，通过主动制造故障，测试分布式系统在各种异常情况下的行为，对系统稳定性进行校验和评估，识别并修复故障问题，进而建立对系统抵御生产环境中失控条件的能力和信心。

这里强调一下，混沌工程与故障注入法的区别：

故障注入法：是指当故障注入后，应该发现什么事故，是固定的。

混沌工程：是指当故障注入后，什么事故会发生，是未知的。

在《性能之巅》一书提及到已知的已知；已知的未知；未知的未知。对于缺陷而言：已知的已知，即已经被发现的缺陷；已知的未知，即已经知道操作后可能会出现的缺陷；未知的未知，即不知道什么操作后是否存在缺陷。所以故障注入法是发现已知的未知缺陷；混沌工程是发现未知的未知缺陷。但是混沌工程不是随意进行的（据说当年切尔日核电站爆炸，就是在一次类似于“混沌工程”演练后发生的）。

混沌工程实施规范

1. 建立一个围绕稳定状态行为的假说（Build a Hypothesis around Steady State Behavior）
2. 多样化真实世界的事件 （Vary Real-world Events）
3. 在生产环境中运行实验 （Run Experiments in Production）
4. 持续自动化运行实验 （Automate Experiments to RunContinuously）
5. 最小化爆炸半径 （Minimize Blast Radius）

以前我在大学里面学习软件工程，主要批判大棒模型，鼓吹瀑布模型，而现在瀑布模型遇到淘汰，在敏捷思想提出后，各种Ops思想运运而生，下面简单来给大家介绍一下。

2. XxxOps

1) DevOps

2009年 Velicity大会，全球大型图片分享网站Filckr的运维部经理John Allspaw和Paul Hammond分享，每日10次部署：Dev和Ops在Filckr的协作。DevOps之父：Patrick Debois在比利时首次发起DevOpsDay活动。

许多人不太理解DevOps之间的关系，看了上面这张图，大家就能一目了然了。

DevOps六大武器

1. 标准化作业：pipline
2. 快速失败（Fast Fail）
3. 快速反应
4. 高质量与高效率
5. 降低成本
6. 团队协作（研发、运维、测试）

DevOps七个阶段

1. 持续开发：计划、编码。工具：代码仓库、版本控制、包管理、甘特图、燃尽图。管理：分支管理、单元测试。
2. 持续集成：频繁提交代码->频繁编译代码->频繁构建项目->频繁单元测试->频繁集成（快速失败）
3. 持续测试
4. 持续监控：各项工作的监控
5. 持续反馈
6. 持续部署
7. 持续运营：事件和变更 配置管理、容量管理、高可用管理、用户体验管理。

2)DevSecOps

将软件安全贯穿于软件开发始终。

2012 著名IT研究机构Gartner公司DevOps报告：DevSecOps：Creating the Agile Triangle提出DevSecOps概念。

2016年Gartner公司：DevSecOps：How to Seamlessly Interate SecurityInto DevOps.（如何将安全性无缝集成到开发平台中）更加阐述DevSecOps概念

安全相关的成熟度模型

• 软件安全构建成熟度模型(Building Security InMaturity Mode，BSIMMl)
• 软件保证成熟度模型(Software AssuranceMaturity Model,SAMM)
• 安全开发生命周期模型(Security DevelopmentLifecycle,SDL)
• 运维安全保障模型（Operational SecurityAssurance,OSA）

软件安全工具

• 动态应用安全测试（Dynamic ApplicationSecurity Testing，DAST）：
  开源的Zed AttackProxy (ZAP)、AcunetixWVS,Burpsuite,OWASP ZAP,长亭科技X-Ray,w3af。
• 静态应用安全测试（Static Application SecurityTesting ,SAST）：
  Klocwork、Helix QAC、HCL AppScan、国内的腾讯xcheck、Wukong（悟空）、Coverity,Checkmark FindBugs,CodeQL,ShiftLeft inspect
• 交互式应用安全测试（Interactive ApplicationSecurity Testing，IAST）：
  CodeDx、Checkmarx CxIAST、Contrast Secutity，默安LAST，玄镜。IAST相当于是DAST和SAST结合的一种互相关联运行时安全检测技术
• 软件成分分析（Software Composition Analysis，SCA）：
  Synopsys Black Duck、RedRocket-SCA、X-ray，SonatypeIQServer，Dependencies Check

3)DevPerfOps

将软件性能质量贯穿于软件开发始终。

4) AIOps（Aritificial Intelligence for ITOperation）

用AI来辅助运维，整合大数据和机器学习，通过松耦合、可扩展方式去提取和分析在数据量（Volume）、种类（Variety）、和速度（velocity）这三个方面不断增长的IT数据，为所有主流的IT运维管理(IT Operations Management, ITOM)产品提供支撑。

AIOps关键技术

• 数据采集
• 数据处理
• 数据存储
• 数据分析
• AIOps算法

AIOps应用场景

保障运营

• 异常检查
• 故障诊断
• 故障预防
• 故障自愈

成本优化

• 资源优化
• 容量规划
• 性能优化

效率提升

• 智能预测
• 智能变更
• 智能问答
• 智能决策

5) DataOps

用大数据支持运维。主要是用把线上日志作为大数据来进行分析处理，在这里我特别要提一下Splunk软件，这个工具非常强大，唯一的缺陷就是价格也非常的昂贵。

正像瀑布模型取代大棒模型、敏捷、DevOps取代瀑布一样，随着技术和管理进步，以后肯定有一门新的技术取代敏捷、DevOps，我估计可能是人工智能技术。但是人人就是主体，如何利用软件工程化为以人为主导软件项目，人的要素始终是最重要的。

3. 自动化软件测试

关于自动化软件测试，在DevOps下是非常重要的，在以前几年业界讨论也是非常热烈的，我也写过许多类似的文章，业界甚至出现的软件测试就是软件自动化软件测试的怪圈，还好这几年这个怪圈回归了理性。总之，自动化软件测试不是万能的，但是没有自动化软件测试是万万不能的。由于以前这方面讲述了很多，在这里不再进行详细展开。

4. 基于技术的软件测试

1）性能测试

关于性能测试，可以说上三天三夜，在这里我特别需要指出得到是，在线下，特别是第一次性能测试，必须需要给一个相对独立网段的测试环境，如果测试环境与研发环境在同一网段（前几天刚刚给一家企业作测试咨询，他们竟然在WiFi环境下进行性能测试），在这种环境下进行测试，由于网络的抖动性是非常不确定的，一方面影响大家的工作，另一方面测试出来的数据也是不完善的。

2）安全性测试

大家都认为安全性测试是非常困难的，就测试而言，安全测试是非常容易的，参看下表：

对于与业务相关的安全测试，需要根据对应的业务，做好测试。

5. 软件测试分析与设计

特别提出软件测试分析与设计是作为一个软件测试工程师的看家本领，在这里我介绍两本书，一本是邰晓梅女士书写的《海盗派测试分析 MFQ&PPDCS》，另一本是刘琛梅女士书写的《测试架构师修炼之道》

6. 精准测试

精准测试是我特别崇拜的一门技术

利用精准测试，我们可以做到：

1. 发现软件缺陷可以精准定位到所在缺陷的近N条代码，便于调试；
2. 为回归测试做到精准定位。版本N 1与版本N哪些代码受到了影响，哪些不受到影响;哪些测试用例需要回归，哪些不需要；
3. 对测试人员的工具进行有效的度量，这些用例覆盖了哪些代码？哪些代码还没有用例覆盖

7. Model-Based Testing

基于模型的测试（Model-Based Testing：MBT）我个人不太看好，不详谈。

8. 关于ABC测试

ABC测试，就是人工智能(AI)，大数据(Big Data)，云原生(Cloud)测试。

人工智能(AI)测试：主要包括算法测试和应用测试。

大数据(Big Data)：主要包括数据验证和应用测试。

云原生(Cloud)测试主要人就是应用测试。

我个人认为ABC测试仍旧处于起步阶段，测试的重点主要在应用的本身，数据验证，算法测试需要许多其他领域的技能，比如统计学、概率论等。

9. 对目前比较关注的测试问题

最后对目前比较关注的测试问题阐述我的人的观点

1. 如何在短时间内执行测试

a) 基于深度优先的策略执行优先级高的测试用例；

b) 开展探索式测试，根据缺陷的80/20原则，对80%产生缺陷的模块进行强力测试

2. 哪些用例需要写测试用例，哪些不需要

a) 用户用例中提及的基本测试（正向、反向）的功能需要书写测试用例。

b) 上面提及的洋葱软件测试模型内三层冒烟测试、开发自测、验收测试需要书写测试用例。

c) 其他根据情况书写或不书写测试用例

3. 哪些需要书写自动化测试用例

a) 保证这个用例执行次数超过5次，必须书写测试用例。

b) 同一缺陷被修复在其他版本中又发现（非合并出现的问题），必须书写测试用例。

最后祝大家工作顺利，生活愉快。