2022年的鐘聲已經(jīng)響過，1972年出生的我已經(jīng)在這個世界上度過了整整半個世紀，時間如流水，都去哪了？好像昨天還剛剛從大學(xué)的校門走出，可是當時剛從大學(xué)殿堂呱呱落地的嬰兒，現(xiàn)在都變成了IT界的主力軍。我的稱謂也由以前的同學(xué)、男孩，小顧變成了現(xiàn)在的大佬、大咖，甚至是老前輩，好多人認為我很成功，好厲害…，但是我自己知道我僅僅比現(xiàn)在的IT從業(yè)人員大幾歲，多吃了幾口鹽，多過了幾座橋罷了。

好吧，廢話少說，我再和大家結(jié)合現(xiàn)在的情況談?wù)?span id="keyeciooq" class="candidate-entity-word" data-gid="374714">軟件測試，現(xiàn)在的軟件測試和當年的軟件測試不可同日而語，我當年進入測試部門正因為我的首任CTO是海歸派，他與他的夫人當時都在美國硅谷學(xué)習(xí)和工作，他從事軟件研發(fā)，而他的夫人從事軟件測試，正因為他夫人的“教導(dǎo)”，使得他感覺到軟件測試的重要性，所以在我們公司中開辟了獨立的軟件測試部，并且多次邀請他的夫人來公司作關(guān)于軟件測試方面的普及，我也因為當時在軟件測試方面表現(xiàn)出的特有氣質(zhì)，當選了軟件測試部的部門經(jīng)理，從而走上了軟件測試之路，這一走就是整整20年之久，甚至?xí)L。

好，主題上場，我來談?wù)勎覍ΜF(xiàn)在軟件測試的一些看法。

1.軟件測試左右移

1）軟件測試左移

a) 黑盒測試

關(guān)于軟件測試的做用其實我在2001年剛剛從事軟件測試的時候就提到過。當時我們開發(fā)了一個中國電信牽頭的，名為“網(wǎng)上商品交易會”的項目（可惜這個最后放棄了，否則可能成為中國第一個B2B的平臺），在這個系統(tǒng)中，包含了展會、展商、展位、展品幾個實體，一個展會由多個展商參加；一個展商有多個展位（比如格力，包括家庭電器展位和辦公電器展位）、一個展位下包括多個展品。我們測試人員在一開始就設(shè)計了這么一個測試用例：刪除展位，試圖查看展位下的展品；刪除展商，試圖查看展商下的展位和展品；刪除展會，試圖查看展會下的展商、展位和展品。大家如果學(xué)習(xí)過關(guān)系數(shù)據(jù)庫，就會知道這屬于關(guān)系型數(shù)據(jù)庫的主外鍵關(guān)系。但是這個產(chǎn)品的產(chǎn)品架構(gòu)師不太鼓勵在數(shù)據(jù)庫中加上外鍵鎖，希望程序員在程序中進行控制?？墒浅绦騿T在開發(fā)代碼的時候，由于產(chǎn)品架構(gòu)師沒有過于強調(diào)，就把這個驗證給忽略了，最后在項目末尾，出現(xiàn)了展品找不到展位、展位找不到展商、展商找不到展會這樣的尷尬情形，只好打回，延期發(fā)布。如果在測試工程師書寫完畢測試用例，由開發(fā)與測試一起坐下來進行一次測試用例評審，或者把這部分測試用例讓開發(fā)測試工程師作為自測用例來執(zhí)行，是不是就可以提前發(fā)現(xiàn)這個問題呢？記得濟南的李龍同學(xué)提出了川模型軟件測試模型，我在這里結(jié)合這個模型提出了洋蔥軟件測試模型，如下圖：

最里面為冒煙測試用例，外面為開發(fā)自測用例（研發(fā)開發(fā)完產(chǎn)品代碼，需要自己運行一次冒煙測試用例和自身相關(guān)的自測用例），外面是驗收測試用例。最外面為所有測試用例，當然這些測試用例可以是手工的，也可以是自動化的。

b) 白盒測試

白盒測試包括靜態(tài)白盒測試和動態(tài)白盒測試，在測試座用中，白盒測試起著至關(guān)重要的作用，我個人認為嵌入式軟件是最難測的軟件，而這種軟件最重要的是做好白盒測試。對于靜態(tài)白盒測試（包括Code Review和代碼掃描），在這方面測試人員真的不具備優(yōu)勢，讓專業(yè)的人作專業(yè)的事，所以這個我認為還是讓開發(fā)人員自己來完成；動態(tài)白盒測試往往通過書寫單元測試代碼來實現(xiàn)，由于測試人員具有獨特的逆向、系統(tǒng)、變向等思維能力，我認為應(yīng)該讓測試人員參與單元測試的設(shè)計。我當時在從事機頂盒軟件測試產(chǎn)品，我們的CTO真是這樣要求我們的，測試一個函數(shù)，對于函數(shù)中變量的空值，0值，非法值、邊界值…，開發(fā)人員開始都是不考慮的。由于有測試人員與開發(fā)人員的共同參與，我們當時機頂盒的質(zhì)量是非常高的（這算不算結(jié)對測試），可惜的是后來清華與上海交大爭奪機頂盒的標準權(quán)（一個信號強，但是覆蓋率低；另一個信號弱，但是覆蓋率高），搞得兩敗俱傷，最后被IP TV取代，真是鷸蚌相爭，漁翁得利啊（所以質(zhì)量好，不代表銷售就好，這需要公司各方面的努力）。

2）軟件測試右移

在我剛畢業(yè)的年代，軟件測試右移是想都不敢想的，現(xiàn)在隨著分布式、大數(shù)據(jù)和人工智能的發(fā)展，使得軟件測試右移成為了可能。軟件測試右移說白了就是在生產(chǎn)環(huán)境中進行軟件測試。下面來介紹一下測試有以下的幾種技術(shù)（特別強調(diào)一點，在在線測試中，監(jiān)控和告警是非常重要的）：

a) 灰度發(fā)布（又叫金絲雀發(fā)布）

在英國，由于金絲雀對瓦斯極為敏感，礦井工人攜帶金絲雀，以便及時發(fā)發(fā)現(xiàn)危險。在分布式系統(tǒng)中，我們可以通過將不太確定的新版本軟件反掛在分布式系統(tǒng)的一個節(jié)點上，讓少部分用戶來使用，通過監(jiān)控和告警來及時發(fā)現(xiàn)問題。當所有問題都解決了再逐步擴展新版本的發(fā)布。

在這張圖中，綠色的為新版本，10%的用戶使用這個版本，當所有問題都解決了，可以把新版本擴大到30%、50%、80%停頓一段時間，從而驗證性能質(zhì)量。

b) 全鏈路壓測

在全鏈路壓測中，分離測試數(shù)據(jù)和測試鏈路，測試數(shù)據(jù)放到影子庫和影子表中，對試鏈路進行染色；測試完畢必須復(fù)原，刪除測試數(shù)據(jù)和測試鏈路；當全鏈路測試過程中發(fā)現(xiàn)了問題，需要有良好的災(zāi)備機制，在災(zāi)備機制下，精確記錄故障原因，并且盡快把環(huán)境恢復(fù)正常。

c) 流量回放技術(shù)

收集線上的流量數(shù)據(jù)，在線下回放。

d）混沌工程

混沌工程（Chaos Engineering）是在分布式系統(tǒng)上進行實驗的學(xué)科，通過主動制造故障，測試分布式系統(tǒng)在各種異常情況下的行為，對系統(tǒng)穩(wěn)定性進行校驗和評估，識別并修復(fù)故障問題，進而建立對系統(tǒng)抵御生產(chǎn)環(huán)境中失控條件的能力和信心。

這里強調(diào)一下，混沌工程與故障注入法的區(qū)別：

故障注入法：是指當故障注入后，應(yīng)該發(fā)現(xiàn)什么事故，是固定的。

混沌工程：是指當故障注入后，什么事故會發(fā)生，是未知的。

在《性能之巔》一書提及到已知的已知；已知的未知；未知的未知。對于缺陷而言：已知的已知，即已經(jīng)被發(fā)現(xiàn)的缺陷；已知的未知，即已經(jīng)知道操作后可能會出現(xiàn)的缺陷；未知的未知，即不知道什么操作后是否存在缺陷。所以故障注入法是發(fā)現(xiàn)已知的未知缺陷；混沌工程是發(fā)現(xiàn)未知的未知缺陷。但是混沌工程不是隨意進行的（據(jù)說當年切爾日核電站爆炸，就是在一次類似于“混沌工程”演練后發(fā)生的）。

混沌工程實施規(guī)范

1. 建立一個圍繞穩(wěn)定狀態(tài)行為的假說（Build a Hypothesis around Steady State Behavior）
2. 多樣化真實世界的事件 （Vary Real-world Events）
3. 在生產(chǎn)環(huán)境中運行實驗 （Run Experiments in Production）
4. 持續(xù)自動化運行實驗 （Automate Experiments to RunContinuously）
5. 最小化爆炸半徑 （Minimize Blast Radius）

以前我在大學(xué)里面學(xué)習(xí)軟件工程，主要批判大棒模型，鼓吹瀑布模型，而現(xiàn)在瀑布模型遇到淘汰，在敏捷思想提出后，各種Ops思想運運而生，下面簡單來給大家介紹一下。

2. XxxOps

1) DevOps

2009年 Velicity大會，全球大型圖片分享網(wǎng)站Filckr的運維部經(jīng)理John Allspaw和Paul Hammond分享，每日10次部署：Dev和Ops在Filckr的協(xié)作。DevOps之父：Patrick Debois在比利時首次發(fā)起DevOpsDay活動。

許多人不太理解DevOps之間的關(guān)系，看了上面這張圖，大家就能一目了然了。

DevOps六大武器

1. 標準化作業(yè)：pipline
2. 快速失敗（Fast Fail）
3. 快速反應(yīng)
4. 高質(zhì)量與高效率
5. 降低成本
6. 團隊協(xié)作（研發(fā)、運維、測試）

DevOps七個階段

1. 持續(xù)開發(fā)：計劃、編碼。工具：代碼倉庫、版本控制、包管理、甘特圖、燃盡圖。管理：分支管理、單元測試。
2. 持續(xù)集成：頻繁提交代碼->頻繁編譯代碼->頻繁構(gòu)建項目->頻繁單元測試->頻繁集成（快速失?。?/li>
3. 持續(xù)測試
4. 持續(xù)監(jiān)控：各項工作的監(jiān)控
5. 持續(xù)反饋
6. 持續(xù)部署
7. 持續(xù)運營：事件和變更 配置管理、容量管理、高可用管理、用戶體驗管理。

2)DevSecOps

將軟件安全貫穿于軟件開發(fā)始終。

2012 著名IT研究機構(gòu)Gartner公司DevOps報告：DevSecOps：Creating the Agile Triangle提出DevSecOps概念。

2016年Gartner公司：DevSecOps：How to Seamlessly Interate SecurityInto DevOps.（如何將安全性無縫集成到開發(fā)平臺中）更加闡述DevSecOps概念

安全相關(guān)的成熟度模型

• 軟件安全構(gòu)建成熟度模型(Building Security InMaturity Mode，BSIMMl)
• 軟件保證成熟度模型(Software AssuranceMaturity Model,SAMM)
• 安全開發(fā)生命周期模型(Security DevelopmentLifecycle,SDL)
• 運維安全保障模型（Operational SecurityAssurance,OSA）

軟件安全工具

• 動態(tài)應(yīng)用安全測試（Dynamic ApplicationSecurity Testing，DAST）：
  開源的Zed AttackProxy (ZAP)、AcunetixWVS,Burpsuite,OWASP ZAP,長亭科技X-Ray,w3af。
• 靜態(tài)應(yīng)用安全測試（Static Application SecurityTesting ,SAST）：
  Klocwork、Helix QAC、HCL AppScan、國內(nèi)的騰訊xcheck、Wukong（悟空）、Coverity,Checkmark FindBugs,CodeQL,ShiftLeft inspect
• 交互式應(yīng)用安全測試（Interactive ApplicationSecurity Testing，IAST）：
  CodeDx、Checkmarx CxIAST、Contrast Secutity，默安LAST，玄鏡。IAST相當于是DAST和SAST結(jié)合的一種互相關(guān)聯(lián)運行時安全檢測技術(shù)
• 軟件成分分析（Software Composition Analysis，SCA）：
  Synopsys Black Duck、RedRocket-SCA、X-ray，SonatypeIQServer，Dependencies Check

3)DevPerfOps

將軟件性能質(zhì)量貫穿于軟件開發(fā)始終。

4) AIOps（Aritificial Intelligence for ITOperation）

用AI來輔助運維，整合大數(shù)據(jù)和機器學(xué)習(xí)，通過松耦合、可擴展方式去提取和分析在數(shù)據(jù)量（Volume）、種類（Variety）、和速度（velocity）這三個方面不斷增長的IT數(shù)據(jù)，為所有主流的IT運維管理(IT Operations Management, ITOM)產(chǎn)品提供支撐。

AIOps關(guān)鍵技術(shù)

• 數(shù)據(jù)采集
• 數(shù)據(jù)處理
• 數(shù)據(jù)存儲
• 數(shù)據(jù)分析
• AIOps算法

AIOps應(yīng)用場景

保障運營

• 異常檢查
• 故障診斷
• 故障預(yù)防
• 故障自愈

成本優(yōu)化

• 資源優(yōu)化
• 容量規(guī)劃
• 性能優(yōu)化

效率提升

• 智能預(yù)測
• 智能變更
• 智能問答
• 智能決策

5) DataOps

用大數(shù)據(jù)支持運維。主要是用把線上日志作為大數(shù)據(jù)來進行分析處理，在這里我特別要提一下Splunk軟件，這個工具非常強大，唯一的缺陷就是價格也非常的昂貴。

正像瀑布模型取代大棒模型、敏捷、DevOps取代瀑布一樣，隨著技術(shù)和管理進步，以后肯定有一門新的技術(shù)取代敏捷、DevOps，我估計可能是人工智能技術(shù)。但是人人就是主體，如何利用軟件工程化為以人為主導(dǎo)軟件項目，人的要素始終是最重要的。

3. 自動化軟件測試

關(guān)于自動化軟件測試，在DevOps下是非常重要的，在以前幾年業(yè)界討論也是非常熱烈的，我也寫過許多類似的文章，業(yè)界甚至出現(xiàn)的軟件測試就是軟件自動化軟件測試的怪圈，還好這幾年這個怪圈回歸了理性。總之，自動化軟件測試不是萬能的，但是沒有自動化軟件測試是萬萬不能的。由于以前這方面講述了很多，在這里不再進行詳細展開。

4. 基于技術(shù)的軟件測試

1）性能測試

關(guān)于性能測試，可以說上三天三夜，在這里我特別需要指出得到是，在線下，特別是第一次性能測試，必須需要給一個相對獨立網(wǎng)段的測試環(huán)境，如果測試環(huán)境與研發(fā)環(huán)境在同一網(wǎng)段（前幾天剛剛給一家企業(yè)作測試咨詢，他們竟然在WiFi環(huán)境下進行性能測試），在這種環(huán)境下進行測試，由于網(wǎng)絡(luò)的抖動性是非常不確定的，一方面影響大家的工作，另一方面測試出來的數(shù)據(jù)也是不完善的。

2）安全性測試

大家都認為安全性測試是非常困難的，就測試而言，安全測試是非常容易的，參看下表：

對于與業(yè)務(wù)相關(guān)的安全測試，需要根據(jù)對應(yīng)的業(yè)務(wù)，做好測試。

5. 軟件測試分析與設(shè)計

特別提出軟件測試分析與設(shè)計是作為一個軟件測試工程師的看家本領(lǐng)，在這里我介紹兩本書，一本是邰曉梅女士書寫的《海盜派測試分析 MFQ&PPDCS》，另一本是劉琛梅女士書寫的《測試架構(gòu)師修煉之道》

6. 精準測試

精準測試是我特別崇拜的一門技術(shù)

利用精準測試，我們可以做到：

1. 發(fā)現(xiàn)軟件缺陷可以精準定位到所在缺陷的近N條代碼，便于調(diào)試；
2. 為回歸測試做到精準定位。版本N 1與版本N哪些代碼受到了影響，哪些不受到影響;哪些測試用例需要回歸，哪些不需要；
3. 對測試人員的工具進行有效的度量，這些用例覆蓋了哪些代碼？哪些代碼還沒有用例覆蓋

7. Model-Based Testing

基于模型的測試（Model-Based Testing：MBT）我個人不太看好，不詳談。

8. 關(guān)于ABC測試

ABC測試，就是人工智能(AI)，大數(shù)據(jù)(Big Data)，云原生(Cloud)測試。

人工智能(AI)測試：主要包括算法測試和應(yīng)用測試。

大數(shù)據(jù)(Big Data)：主要包括數(shù)據(jù)驗證和應(yīng)用測試。

云原生(Cloud)測試主要人就是應(yīng)用測試。

我個人認為ABC測試仍舊處于起步階段，測試的重點主要在應(yīng)用的本身，數(shù)據(jù)驗證，算法測試需要許多其他領(lǐng)域的技能，比如統(tǒng)計學(xué)、概率論等。

9. 對目前比較關(guān)注的測試問題

最后對目前比較關(guān)注的測試問題闡述我的人的觀點

1. 如何在短時間內(nèi)執(zhí)行測試

a) 基于深度優(yōu)先的策略執(zhí)行優(yōu)先級高的測試用例；

b) 開展探索式測試，根據(jù)缺陷的80/20原則，對80%產(chǎn)生缺陷的模塊進行強力測試

2. 哪些用例需要寫測試用例，哪些不需要

a) 用戶用例中提及的基本測試（正向、反向）的功能需要書寫測試用例。

b) 上面提及的洋蔥軟件測試模型內(nèi)三層冒煙測試、開發(fā)自測、驗收測試需要書寫測試用例。

c) 其他根據(jù)情況書寫或不書寫測試用例

3. 哪些需要書寫自動化測試用例

a) 保證這個用例執(zhí)行次數(shù)超過5次，必須書寫測試用例。

b) 同一缺陷被修復(fù)在其他版本中又發(fā)現(xiàn)（非合并出現(xiàn)的問題），必須書寫測試用例。

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