在構思這個主題的題目時，腦子里先是蹦出來三個詞，“哲學”、“本質”和“底層邏輯”。

同時轉念一想，打算通過一篇文章就想探到如此深度豈非癡心妄想和不知天高地厚。實際上，諸多冠此類帽子的文章多是名不副實。算了，人近不惑，腦力漸衰，把書讀薄也更甚于讀厚。

 

不過，讀薄的前提至少是要有體系和脈絡。所以選用了“脈絡”這個詞，細想來，確實比前面想到的那三個詞更合我真意。

 

在開始這條脈絡之前，還是先把概念澄清，以設定一個理解基線。

0

什么是軟件測試？

《軟件測試的藝術》的作者梅耶的定義是“軟件測試就是為了發現缺陷而運行程序的過程”。

 

盡管不同的角色在不同的角度都有不同的定義，比如有從需求入手的、有從質量著眼的，也有從一致性、風險和成本等展開的……

各有各的道理，但我從實務的角度看，選用了梅耶的定義，畢竟運行程序發現缺陷是我們日?？梢姷臏y試的最顯著特點。

 

好，正式開始。

 

為了更貼近實際項目運行，我大體按照業務的運行時間線，把這條脈絡的一頭一尾分別定義為“測試策略”和“測試匯總”。

1

測試策略 

在企業里，我們所做的所有工作，從來不是獨立的，也從來不是單一的技術問題或者管理問題，而是需要一個統籌的考慮。

 

測試也一樣，開始之前我們要有“策略”，這是一個High-level的概念，多少有一點模棱兩可，很難說清楚其準確內涵，不同干系人也有不同的期望，本文給三個參考的維度，分別是測試規則或指南、測試目標和測試原則。

 

盡管實際工作中，我們基本無法清晰地拆分出隸屬于不同維度的工作，而是相互混雜和滲透，但為了便于溝通和理解，暫且還是按此拆分。

1.1 測試規則或指南

 

測試規則或指南，我們把它定義為統領性、強制性或推薦性的一些規則、要求或建議，它們一般由公司層面整體定義，并要求執行。

 

比如，什么節點前應該做測試分析，應該用哪個報告模板，什么測試條目是必測項，測試用例的選擇要考慮哪些，測試的準入準出規則是什么，是否必須先完成冒煙測試，什么情況下必須做壓力測試，測試覆蓋率怎么考慮，測試通過率怎么定義，如何區分不同層次測試的責任人，缺陷的處理方式，測試與需求的追溯性要求，單元測試必須在其他測試前完成，回歸測試時測試用例如何選擇，自動化測試比例及開始時機怎么定義，必須執行全量測試的標準等等。

會有很多的角度去定義，無法詳述。

 

總之，是一些基于公司策略和歷史經驗等制定的綱領性的文件。

 

當然，多數不那么規范的公司不會定義很細，要求也不會很嚴格，姑且有這么個概念。

1.2 測試目標

 

測試目標呢，比較寬泛的理解有查找問題、確認滿足需求、避免問題泄漏、保證客戶滿意、提升質量、降低成本、推進持續改善等等。

這些內容雖然并不難理解，但還是太泛泛而談了。

 

在具體的某個客戶、某個平臺、某個項目、某次迭代、某次交付的組合里，會有多方面因素要考慮，這是個復雜的且需要背景信息的事，無法簡單說明。

 

舉幾個可能需要思考的問題，感性感覺下。

這個客戶對測試報告的提交需求是什么？這次上了哪些主要功能點？該平臺或該項目是否有歷史LLs？已經識別到什么潛在風險需要測試探測嗎？內部有什么質量目標？本次交付變更點是什么？自動化測試臺架是否可用？這次是工程車間裝車，還是臺架或者產線？什么功能是本次交付最關注的？是否上路，上什么路……

 

綜合各種信息，項目經理或測試經理可以來統籌判斷及調整本次測試的目標，據此再來進行后續的計劃、執行等工作。

1.3 測試原則

 

考試有答題技巧，工作有方法論，打仗有兵法。測試原則差不多等同于這類。在整個和測試相關的工作中，是否有一些參考性的原則呢？

 

1、要盡可能早地測試。這是質量成本的原則，發現問題越晚，成本和影響越高越大。

 

2、不可能進行窮舉式測試。進行完全的測試是不可能的，完全沒有任何缺陷的軟件也是不存在的，要根據風險評估進行測試用例設計，進行最佳的測試量定義。

 

3、關注缺陷群集效應。二八法則我們都聽說過，在此也是適用的，少量的模塊經常包含大部分缺陷。統計數據也表明，一段程序已發現的缺陷越多，則該段程序發生更多缺陷的可能性也很大.

 

4、殺蟲劑悖論。如果同一個測試人員重復執行相同的測試，該方法將無法發現新的測試缺陷。這既有測試用例更新不及時的原因，也有測試人員的思維定勢和思維懈怠的原因。所以測試用例要經常更新，測試人員也可以適時輪換。

 

5、測試只能證明存在缺陷，而無法證明不存在缺陷。因為測試實際上是一個樣本實驗，不可能涵蓋所有情況。

 

6、沒有缺陷不代表軟件一定能夠使用。比如測試用例本身未覆蓋需求，這其實說明了測試本身的局限性，也說明了我們要進行全方位軟件開發及測試管理的必要性。

 

7、測試最好由非軟件開發人員擔任。這是從心理學角度來看的，畢竟讓一個人否定自己的工作是令人沮喪的，而且如果開發人員對某個功能有錯誤認識，再去測試可能依舊無法識別。

 

8、測試順序。為了盡可能早地合理退出，要首先執行具有較高失敗概率的測試。比如，最好依次進行冒煙測試（核心功能預測試）、缺陷重新測試、測試新功能、測試修改或優化的特性、測試未改變的特性(回歸測試)。

 

實際工作中，策略更多是在項目經理或測試經理腦子里的整體謀篇布局，以上三個維度是落于紙面上的一個參考。

2

測試管理

有個通盤的策略性考量后，就可以進入管理層面的工作上了。

 

接下來看測試管理。

 

當組織結構龐大和軟硬件功能復雜時，測試也同樣會變得很復雜和容易混亂。

這時，就非常需要由專門的人按照特有的流程進行組織和管理。管理的范疇很大，為了避免描述混雜在一起，我們這里只談小管理，不涉及具體工程層面的內容。

 

我們可以將測試管理的目標定義為，根據確定的測試范圍，交付與測試相關的工作包（例如，測試規范、測試執行、評審和報告等），同時還要滿足項目進度計劃中定義的里程碑節點。

 

簡單來說，就是先要明確誰在什么時間做完什么，然后，在出現異常時，進行調整。

 

當然，這個交付目標的達成需要很多支持。

 

首先，要明確做什么，根據我們的策略定義測試范圍，比較粗略的分類，可能會有單元測試、集成測試、系統測試，以及輔助性的文檔、報告、評審之類的工作。這些內容之間可能會有依賴關系和前后次序等。同時，也要識別出責任人，根據我的項目經驗，沒有明確到具體的人的任務99%會延期。

 

接下來，要確認資源（Resource），這里包括人員和設備及樣品，再細分還要看人員是否充足與人員能力是否足夠、設備及樣品是否充足和可用。比如，可能考慮到軟件測試工程師、系統測試工程師、具備特殊測試能力的專家，以及臺架、ECU、線束、CAN工具、診斷儀、示波器等等。當這些有問題時，就需要管理人員進行調配。

 

對于執行人而言，會提出工作包的完成時間（Duration），這個也是經常在測試人員和管理人員之間針鋒相對的地方，測試人員希望As long as possible，管理人員希望As soon as possible。就看實際工作中，如何論戰和平衡了。

 

如果成本管控比較好的公司，還會考慮成本（Cost），一般包含人員工時和材料成本。特別是涉及到第三方公司或其他獨立結算團隊時。

 

對于項目經理而言，最關心的是完成的截止時間及監控，也就是催催催。根據整個項目的進度和前面的一些梳理，就可以得到詳細的計劃。至于所需的詳細程度，取決于產品的復雜性和所涉及的測試人員的數量等。

 

然而，出問題和延期幾乎是必然的，基本沒有哪一個項目能夠完全避免，解決這些問題也是管理人員最主要的任務了?；蚰贸鲎约旱腂uffer，或減少測試，或調整優先級，或談判，或帶風險并行，或升級管理層支持。

 

整個管理過程會有不同的工具支持、流程部署、模式風格，暫不詳述，各有各的做法。

 

這里給一個我所見到的眾多做法中做得比較嚴謹的案例。

 

簡單思路是，在測試之初，定義一張完整的測試全量計劃表，這里面包含系統、軟件、硬件、結構等所有的測試條目，以及每個條目測試與否、不測試的分析理由、通過與否、對應缺陷和報告鏈接等。由項目經理或測試經理作為總負責人，組織相關人員進行測試范圍識別、測試計劃排定、測試進度跟蹤、測試報告提交完善等。每次迭代都對應這樣一份統一的測試匯總表，通過這種方式可以系統地將測試管理起來。

3

測試過程

上面的闡述都屬于規劃管理性質，下面開始進入具體操作層面。

 

測試的分類方法有很多種，比如。

 

按照測試時序，可以把整體的測試過程分為需求分析、測試計劃、測試設計、測試環境搭建、測試執行、測試報告這幾大部分。

 

按照測試類型，可以分為功能測試、性能測試、負載測試、壓力測試、冒煙測試、安全性測試、兼容性測試等。

 

按照是否執行程序，可以分為靜態測試和動態測試。

 

按照對軟件內部信息的了解程度，可以分為黑盒測試、白盒測試、灰盒測試。

 

按照測試層次呢，又可以分為單元測試、軟件集成測試、軟件需求測試、系統集成測試、系統測試、驗收測試這幾大部分。

 

從另外一個工程應用的思路，我們將測試層次還能做一個整合，單元測試、集成測試都屬于“設計”層（Technical），軟件需求測試和系統測試屬于“功能”層（Functional），而驗收測試屬于“方案”或“問題解決”層（Solution）。

 

五花八門，不一而足。

粗略來看，從測試層次的角度，基本也能夠覆蓋到其他分類的內容。為了理解起來比較清晰，而且業內講得非常多的V模型或ASPICE也是按照層次來劃分的，所以我們著重從測試層次逐一鋪展開。

3.1 單元測試

 

單元測試是軟件驗證的最低級別，是對軟件的最小可測單元進行驗證的工作。

但如何定義單元一直是爭論的焦點，通常我們會說是一個函數，可有的函數代碼段很短，這樣去做又會顯得很浪費，經常也會將單元異化為具有獨立功能的組件。

 

總之，單元是一個人為定義的最小測試點，去針對軟件的詳細設計（即代碼）來進行的，一般是開發自己去完成的。

 

測試方法會有靜態代碼分析，如熟知的基于MISRA C規范的靜態代碼掃描，或者關注代碼覆蓋率的測試，如語句覆蓋率、分支覆蓋率、MC/DC覆蓋度等。

 

在這個階段之后，軟件組件可以被集成了。

 

3.2 軟件及系統集成測試

 

軟件集成測試的目的是為集成的軟件組件與軟件架構的一致性提供證據，包括組件之間的接口。

 

測試的內容可能包括通過接口的數據是否丟失、組件組合后能否達到預期父功能以及一個組件是否會對其他組件造成影響等。

 

此外，非功能的測試會涉及到CPU負載率、內存占有率等資源消耗的內容。

 

在測試思路的選擇上，一般有兩類：增量式和非增量式，主要差別在于是一次性集成完畢后一次性測試，還是邊集成邊測試。前者容易造成大量缺陷報出而難以定位原因的問題，而且修改過程也會不斷引入新問題，造成混亂。

 

系統集成測試呢，是沿著HW/SW的接口進行的，通過物理引腳（物理層）和邏輯協議（邏輯層）連接的HW/SW接口構成系統內部接口。

因此，系統集成的先決條件是已經集成的軟件和硬件。從技術上講，系統集成只需根據BOM在硬件上刷新軟件即可。這和軟件集成過程中功能集成是逐步進行的有些不同。

 

盡管理論上，軟件集成測試是側重于軟件模塊之間的接口的，系統集成測試是著眼于軟硬件之間的接口的，但是系統不會單獨懸浮于軟件和硬件之上，硬件需要軟件驅動，軟件也需要運行在硬件上，所以系統集成測試的用例往往來源于軟件或硬件各自的測試，有時也會來源于系統測試。

 

此外，還可以提的一點是，系統可以分幾個層級的，比如，ECU能作為一級系統，ECU加傳感部件能作為二級系統，ECU加傳感部件再加執行部件能作為三級系統，三級系統集成于整車環境里還能被定義為四級系統。

宏觀來講，系統集成測試需要考慮到這所有的系統及對應接口，只不過越往上走，就越不是單一的軟件范疇了。

 

3.3 軟件及系統需求測試

 

軟件需求測試，顧名思義，就是為在芯片上運行的集成軟件符合軟件需求提供證據，證明軟件功能滿足需求。

 

系統需求測試呢，習慣被簡稱為系統測試，也是類似，是確保測試集成系統，以提供符合系統需求的證據，并確保系統已準備好交付。

 

與軟件需求測試的差別，主要是系統需求測試要在集成軟件、標定、硬件、外設設備、數據乃至人員的系統下進行的，這也是最常見的最終交付前的測試。

 

測試內容上，主要是針對需求、風險、特定用例或其他高層級系統行為的描述進行的功能測試與非功能測試（如性能、負載、壓力、可靠性、魯棒性、恢復性、安全性、兼容性等各類測試）。

 

這個層次的測試也都是黑盒測試，不需要了解內部實現細節，只需關注輸入與輸出。

 

3.4 驗收測試

 

驗收測試，實際上已經脫離了嚴格意義的工程開發的范疇，在ASPICE里也沒有明確定義。

 

但是，現在行業內越來越多地思考用戶導向和用戶思維，所以把驗收測試單獨拿了進來。

 

我傾向于把驗收測試定義為非專業的客戶評判，比如汽車行業領導或特定人員的試駕，就屬于比較典型的驗收測試，它是更高層級的、更貼近實際使用的一種確認，他們可能不懂軟件，不懂汽車，只是從自己的需要上來給出判斷。

 

還有個例子，你買新房交房時或者毛坯房裝修后，業主要去驗房，就是典型的驗收測試，他們顯然不那么懂裝修、懂材料、懂建筑資質、懂行業標準，但他們會從使用上、美觀上、感覺上去評判。

 

以往的汽車行業基本不太會關注終端消費者的切身體驗，大家沒那么多可選的，造什么買什么?，F在及往后的時間，終端消費者會介入得越來越多，以新勢力為領頭的各大車企也會不遺余力地關注到他們的“驗收”。

4

測試報告

 

測試報告及相應文檔定義的主要的焦點在于測試基礎（需求或設計）和所有測試級別上相應的測試用例及結果之間的可跟蹤性。

理論上或者說做得比較好的，這些測試相關文檔都要通過配置管理管理起來。

 

測試執行后，得到的結果和評估結果被輸入到不同格式的報告中。其中的評估必須要進行，以避免不適當的測試用例或測試環境引起的“假陽性”，就像最近持續做的核酸檢測，要審核的。

 

測試失敗的用例要建立相應的缺陷記錄，以確?？勺匪菪?。如果一個缺陷在專家評審后可以被接受，那么它也應該在測試文檔中被清楚地注釋。

5

測試匯總

 

這一部分就到了我們這條“脈絡”的結尾，實際項目中很多都沒有這部分，各類報告都是散落各處的、千奇百怪模板的、由各人負責的報告。

 

為了”客戶”滿意，我想這個工作包最好是有。

一份整體測試狀態的匯總可以比較清晰地讓內外部都知道當前的或歷史的軟件質量狀態。

 

當然，做起來會有些障礙，特別是系統復雜、分工細的領域，及時且準確維護一張不斷更新的大表是需要一番心力的，后續我們可以探討下是否有改善思路。

 

文章有點長，但還是只能在“皮毛”和“脈絡”上聊一下，畢竟測試是一門很大的學問。

最后呢，嘗試總結一下這條“脈絡”。

汽車軟件測試是一項以尋找問題為主要目標，基于各種組織策略、測試原則和業務限制，而進行多層次驗證并提供證據的管理和工程實踐工作。

轉自水輕言