2019年10月26日，由Testin主辦的第二屆NCTS中國云測試行業峰會在京召開，此次峰會以“AI+未來”為主題，匯聚來自國內外測試領域的知名專家學者、領先企業決策者、高層技術管理者、媒體從業者等，共同探討高端云測試技術，幫助測試從業者了解最前沿行業趨勢，及最新的行業實踐。

[[285501]]

會上，安暢物聯網CEO、川測試模型創始人李龍做《在軟件測試川模型下網絡安全產品的自動化測試架構設計與實踐分享》。李龍指出，“在進行軟件開發或軟件測試的項目之前，需要做整體流程的把控。尤其是把測試人員工作的切入、切出方式、與研發的無縫對接方法以及提高軟件質量保證的意義提高到一定程度上。而川測試模型，在借鑒前輩的模型實踐基礎上，創新性的使用了三條測試實施方法正好做到了這幾點。”

以下為李龍演講實錄：

很高興今天和大家做一個分享，我沒有想到剛才陳老師作為中國平安的技術專家，我一直以為他會分享技術內容，結果一聽是很多有關軟件測試生涯的哲學問題，確實受益匪淺。借著剛才陳老師說的話題和大家分享一下，我這個題目起的有點窄了，但是其實是很寬泛的話題，主要是以川測試模型為指導下，我們在測試開發過程當中做的一些自動化測試構架的設計以及實踐的分享。

首先講一下軟件測試模型的使用情況調查，這個調查我是在2014-2015年之間做的，只是取了兩百多個單位，但是這兩百多個確實是國家一些比較前沿的，可以理解成TOP100或者TOP200以內的企業做的一些測試模型實際的使用情況。但是結果其實不太理想，大家可以看一下，最終有87%的企業不清楚或不知道我們到底使用什么模型進行相關的軟件測試或者過程管理的。

原因可能有這些，測試根據開發的思路推進，沒有明確的時間版本或者相關概念，團隊里更改需求或者人員指派比較隨意。但是我們通過剛才調查出來的內容發現，之前我們聽說過一些模型，比如V模型、W模型、H模型或者瀑布模型等模型。第一個問題，測試與開發的關系、歸程到底是否是互融互通的，比如，V和W模型是從上往下嚴格的節點關系，這種節點關系很難反推，需求確定了、測試方案確定了、開發確定了，我們測試的時候，一旦后面反推這個項目的時候，基本上很難推翻上面的節點，這時會導致測試/開發工作量成倍的增加，質量也很難把控。還有比如，測試對質量的保證意義所處在的層級，咱們都很清楚，其實我們應該盡早的、盡快的將測試嵌入到整個軟件項目或者一個開發周期里去。但是，實際上很多企業都會發現，等到研發工程師或者研發部門把他們的設計架構都已經做完了，可能才會告訴我們，你們開始進行測試吧，去寫測試需求說明書、寫方案吧，這個時候我們已經在滯后了，雖然市面上說我們應該提前介入但是因為沒有合適的規程、規范，導致我們沒有辦法提前進入。當然所有的原因我總結的很簡單，我們現在所使用的一些測試的管理規程、模型，是從國外引進的。因為我是從二零一幾年開始創業，到現在為止創了n個公司，發現了一些問題，我們應該去改變一些東西，用我們自己的規則去想辦法適合我們現在軟件行業國情下的軟件測試的方法模式。這個時候我才真正開始研究一套真正適合在中國發展的軟件測試的模型，我起的名叫川模型。

大家看這個圖可以理解一些，這套模型今天算是第二次和大家進行分享，最早一次是在上海，上海十周年慶典上做了一次分享。之所以叫川模型，是因為在整個軟件測試過程當中我們是分了三條業務執行線的，最左邊一條業務執行線屬于驗收測試的實施模型；中間這條執行線是需求級的，而最后一條執行線是屬于業務測試實施的流程。這樣在我們整個軟件測試過程當中，其實是把一個測試團隊分成三類不同的人群，而不是把部門分成了比如自動化組、性能組、功能組、安全性組。不是這樣劃分的，我們劃分的模式是把測試團隊劃分成三條業務執行線，他們執行的內容是有區別的。那么，我們整個一套系統進行敏捷測試的時候怎么辦？要快速的迭代出來，快速出測試報告、測試結果，這時我們最多使用的是業務測試的實施流程，相當于我們使用基于場景的、風險的、探索的測試方法論來快速的測試20%的模塊，而這20%大家也可以理解是八二法則的劃分，它可能隱藏著80%的缺陷，這時候我們就能夠很快的迭代出這些內容，這些迭代的內容會應用到敏捷的方法，我講的是一套流程管理體系。

我們相關行業在實際做產品的過程中，不可能每一次都說“我選擇用戶使用最多的一些功能”。它可能只占20%的功能，實際上是業務場景80%以上需求的時候，不能完全使用業務場景的方式來測試，我們用什么場景？同時進行著需求級測試，需求級測試是大部分企業或者合作單位用的最多的，是從需求的，比如案例設計、和概要設計的對稱、對接，中間完成一些測試的構建，比如，包含單元集成、功能、自動化、性能穩定性測試，還有相關的安全測試等，這個就比較多了。還有一條線是我們遇到大部分的情況，我們是要把產品交給用戶的，而用戶實際上他所需要的東西，就是我們一開始和用戶、甲方談出來的，他的驗收測試的內容。一開始是要把驗收測試評定出來的，而這時候在有個驗收標尺的時候，把驗收測試里面的功能性能項解決掉，就達到了驗收執行流程。而整個三個方面是在模型提出來到現在試用過程當中有幾個大的企業，在使用過程當中確實是把測試的質量、覆蓋率已經提高到一定檔次了，因為它是一種方法論，它是和V模型、W模型相等平的，這套模型在2015年中科院某所和發改委等這幾個單位做過發表，還有在國際上做了一些學術的論文，大家可以了解一下。

這套模型解決的問題：1、提高了測試人員的使命感和榮譽感，在這個過程中讓他們認同我們作為測試工程師、測試負責人，我們從項目一開始就應該切入了，我們的榮譽感、使命感這個時候是最強的。2、減少過程的冗余，盡早的不斷地進行軟件測試和以測試者引導開發等等。這是這些模型解決的問題。

剛才把模型介紹了一下，沒有實際的方法是紙上談兵，所以今天我把實際的方法給大家摘出來一些，主要介紹這幾個部分：1、對于提前準備測試環境、數據的工作的方式方法。2、在自動化測試平臺搭建的方式方法上。3、專項測試的設計方法；4、基于業務、風險、探索的測試設計方法和框架的整合。5、測試數據資料的完備性與可追溯性設計與體系的掛鉤。

這里講了基于場景自動化的設計，著重說一下思維導圖的。口頭聊一下思維導圖的設計，因為上一次分享聊完之后，很多朋友特別關注基于思維導圖如何進行用例或者測試方案的設計和分析。

首先給大家解釋一下我們會把思維導圖分成兩大部分，一個是用例分析的模塊，另一塊是我們需求分析的模塊。而需求分析它是分為三步的，第一步是我們的明確需求分析；第二是繼承需求；第三是一些隱含的需求，明確需求大家都理解，我們在設計測試方案或者相關項目方案的時候，明確需求是很容易獲取到的，它包含一些和甲方的項目開發合同，也包含一些產品的使用說明書、需求說明書，這是我們可以看到的明確需求相關的內容。繼承需求是什么，我們在設計用例、方案的時候，這套產品不是平白無故過來的，一定會有一個對標的產品或者對標的項目，我們就要學會把它的對標的項目拿過來，比如，同版本的或者是不同版本的，然后相同行業軟件的，但是不是我們公司自己軟件的時候，我們把他們的需求給提取過來，然后去做一些測試需求的提取；第三個隱含的，行業內部或者我們的經驗值，像軍工行業、安全行業測試的時候有一些國際標準的，國標體系、國家強制標準、行標，而這里面的內容其實是很多的，但是我們作為測試人員去設計的時候，往往會忽略掉這塊，因為我們的甲方/客戶可能不懂，或者我們的產品經理也不明白，比如，我們的安全系統或者所有的系統、特種裝備設備，它的性能要求到底是怎么樣，高低溫要求到底是什么狀態，甚至我們進行一些動態的探索、探測滲透的時候達到什么情況才能滿足這個要求，有些東西是國標、行業標準甚至國際標準，是完全已經規定好了，但是我們設計的時候沒有想到的話，就一定會漏測或者測的準確度是不高的，這是我說的思維導圖需求分析的左半部分。

右半部分是用例分析的模塊方案設計。它主要包含六大模塊，第一是功能性測試，第二是性能測試，第三是兼容性測試，第四是穩定性測試，第五是安全性測試，還有一個是安裝性測試。這六個測試的用例或者方案設計的大體模型把我們整個測試的場景已經完全給涵蓋進去了，這是用例分析。后面還有一些分級的問題，我們設計相關的思維導圖的時候分三個等級，因為大家沒法形象的看這個事情，大體聊一下。第一級就是分為安裝性、功能、性能、穩定性、兼容性、安全性這樣幾塊；第二級是我們對它進行的不同的功能細節的劃分，比如像安全性測試一樣，我們劃分成平臺安全性、數據安全性、業務安全性，這么三個大塊，不同得大塊代表的含義大家也都大體理解一些，我們測試的時候不可能只測試我們的數據安全，大部分人都說，安全性測試用AppScanner就可以了，這個也是很難的，它有些測試不全，因為我們還有平臺安全，包含對于內存或者操作系統，尤其國家現在對于國產化的要求，我們會用中標麒麟或者達夢數據庫，金蝶或者WPS。

直接給大家做案例分享。我們做整個架構設計的時候先經過了兩個步驟，第一個步驟是測試體系與測試平臺的整合；先做的一件事情是把模板進行整合，無規矩不成方圓，大家也都理解，我們是把整個測試用例的模板、測試的計劃模板、報告模板全都進行平臺化的整合，它可以讓我們手動編寫，但是編寫的所有內容都能無縫與自動化測試的平臺進行翻譯和提取，這是第一步要做的；第二步是做方法的整合，把一些測試的設計方法，測試的執行方法和一些分析方法進行了合規化的統計、標注；第三是規范，測試流程、測試評審的規范，缺陷管理的規范，這是第一步做的測試體系與測試平臺整合的內容。

第二部分是用例的標準化，大家都理解了，第一是可重用的用例，為什么要說這一點？是因為我們真正要設計的時候會發現，很多測試工程師寫的用例，讓第二個人看的時候用不了，或者說他看不懂，甚至他要再經過二次加工，這個時候其實它的利用率、效益比也是很低的。作為公司是不允許這樣做的，甚至他應該是想辦法解決的。這時候我們這個平臺做了一件事情，是把很多通用的測試用例進行了一些標準化的設計。比如說測界面的、測UI的、測兼容性的、測試安全性的，這些所有的用例，整個提出了一套自動化的用例標準庫，任何一個新入職的員工或者一個工程師他進了這個標準庫的時候就完全可以解決所有的問題，就可以重用了，重用之后的下一步就是復用，不同測試工程師共享測試用例庫，這是復用的概念。

該完善的完善，下一步是整個流程的把控，這是整個項目，這個流程從一開始的調研階段直到最后驗收結束和提供的測試報告，把它規定的都很清晰。這里面也是分了三條線，大家可以看出來，最上面的線就是驗收方案設計標準，中間有一個需求級和業務級測試的流程的把控。中間有一個測試環境的搭建，這個測試環境是和業務級測試以及需求級測試是相同的，他們會用同一套環境來進行實際的設計與測試。執行的時候，我們用到最多的就是這幾個模式，使用這套模型測試的時候用的最多的是基于任務、探索的、基于風險和業務場景的測試方法論。大家可以看一下。

說一下平臺，大家看過這個平臺有一個最大的印象是“這不是一個簡單的自動化測試的軟件”，它是真正的一套架構設計的東西”為什么？大家看最底層，我們真正細粒化的是發現我們連虛擬機群、硬件群、測試標準區庫、測試案例庫、產品案例區、交互區全都在這個平臺里面，而這里面我們真正能用到的自動化的平臺，其實是中間測試區的測試控制臺、工具池以及執行規程做的內容。這個時候我們是真正的打通了所有的人、所有的范圍。這樣平臺算搭起來的，整個平臺監控端，這個平臺監控端是給CTO、CEO等各種O看的，他們能看到我們真正的項目管理、測試管理還有一些產品研發測試的實際工作的情況。

我們在整個部署過程當中出現過一些小插曲，很多用戶不理解“你這個自動化測試為什么非要把我的環境也給我改造、甚至于把我的硬件群、虛擬機群都相應的變更？”我說，不要把自動化測試想象成狹義的測試軟件，其實它是很寬泛的。比如我們測試一個軟件安裝卸載到底正不正確，有人說我就得用自動化測試工具，那么如果我們用一個文件目錄監控軟件，它能干嗎？在你安裝軟件系統的時候把這個軟件打開，里面所有文件目錄的變化，文件的MD5值、注冊表的更改以及鏈接庫的更改都能監控到的話，這也符合自動化測試。因為下一次再進行安裝卸載時，發現它更改的地方只是開發所涉及到的三個文件，這三個文件所代表的含義、功能對大家來說是明確的，你們測試的時候是不是有針對性的知道重點要測哪些內容了？這個事情，像測試區工具池一樣，不一定是測試軟件，一個很簡單的文件監控軟件也是測試工具，同樣的，一些注冊表更改的軟件也算是，哪怕自己寫個腳本，寫批處理文件，寫個文件監控也可以。這時不要把測試自動化想的太窄了，很多客戶找我或者一些朋友，他說你教我們做一下自動化測試吧。這些是我們能替代的東西，一旦把環境、測試區、資源區合在一起的時候就真正實現了自動化測試，這么一個框架。

如圖，這是幾年前搭建起來的，這就是一套環境，這么多交換機、路由器之類的設備，我們測試是離不開交換機、路由器的，但是你想領導會讓你買那么多嗎？不能買，我們自己去構造、去改、去寫，因為大家作為技術都知道，我們是有軟路由的，隨便找到一個功能機安裝軟路由軟件，代表路由器，一千塊錢買個八口的軟路由的工控機，安裝軟路由軟件至少可以替代四臺路由器，這時候我們是把測試的數據準備出來，用到很多的工具庫、工具池，把任何來的一套系統，測試的東西都可以在里面的任何一個節點無縫的運行，把測試效率提高了很多，這是整個環境的狀態。

自動化部署的平臺圖，有個上位機、下位機、交換機還有云服務端的服務器進行相關的測試，這里面測試舉的例子是給他們做嵌入式行業或者安全行業的東西，對于互聯網金融也一樣，我們只需要把下位機連接到被測系統上，通過上位機的定位，調取云端服務器的資源。那些資源是什么，可能剛才跟大家說了，就是我們的工具池、測試庫、測試區、硬件環境區相關的東西，就可以完全進行相關的調取、監控。

這里有幾個簡單的頁面，大家可以看一下，已經集成了很多性能測試、安全性測試、自動化、環境搭建等的內容。還有寫的小軟件，我們可以自己定制，現在代碼開發成本這么低，可以用Python、用易語言的模式，寫出我們想要的東西，其實是很簡單的，還有自我保護、自動化測試工具的情況，我們看軟件自己的保護能力、文件變化的情況、注冊表、目錄、他們監控的狀態。

今天，就給大家分享這些內容。