在構(gòu)思這個主題的題目時，腦子里先是蹦出來三個詞，“哲學(xué)”、“本質(zhì)”和“底層邏輯”。
同時轉(zhuǎn)念一想，打算通過一篇文章就想探到如此深度豈非癡心妄想和不知天高地厚。實際上，諸多冠此類帽子的文章多是名不副實。算了，人近不惑，腦力漸衰，把書讀薄也更甚于讀厚。
不過，讀薄的前提至少是要有體系和脈絡(luò)。所以選用了“脈絡(luò)”這個詞，細(xì)想來，確實比前面想到的那三個詞更合我真意。
在開始這條脈絡(luò)之前，還是先把概念澄清，以設(shè)定一個理解基線。
0
什么是軟件測試？
《軟件測試的藝術(shù)》的作者梅耶的定義是“軟件測試就是為了發(fā)現(xiàn)缺陷而運行程序的過程”。
盡管不同的角色在不同的角度都有不同的定義，比如有從需求入手的、有從質(zhì)量著眼的，也有從一致性、風(fēng)險和成本等展開的……
各有各的道理，但我從實務(wù)的角度看，選用了梅耶的定義，畢竟運行程序發(fā)現(xiàn)缺陷是我們?nèi)粘？梢姷臏y試的最顯著特點。
好，正式開始。
為了更貼近實際項目運行，我大體按照業(yè)務(wù)的運行時間線，把這條脈絡(luò)的一頭一尾分別定義為“測試策略”和“測試匯總”。
1
測試策略
在企業(yè)里，我們所做的所有工作，從來不是獨立的，也從來不是單一的技術(shù)問題或者管理問題，而是需要一個統(tǒng)籌的考慮。
測試也一樣，開始之前我們要有“策略”，這是一個High-level的概念，多少有一點模棱兩可，很難說清楚其準(zhǔn)確內(nèi)涵，不同干系人也有不同的期望，本文給三個參考的維度，分別是測試規(guī)則或指南、測試目標(biāo)和測試原則。
盡管實際工作中，我們基本無法清晰地拆分出隸屬于不同維度的工作，而是相互混雜和滲透，但為了便于溝通和理解，暫且還是按此拆分。
1.1 測試規(guī)則或指南
測試規(guī)則或指南，我們把它定義為統(tǒng)領(lǐng)性、強制性或推薦性的一些規(guī)則、要求或建議，它們一般由公司層面整體定義，并要求執(zhí)行。
比如，什么節(jié)點前應(yīng)該做測試分析，應(yīng)該用哪個報告模板，什么測試條目是必測項，測試用例的選擇要考慮哪些，測試的準(zhǔn)入準(zhǔn)出規(guī)則是什么，是否必須先完成冒煙測試，什么情況下必須做壓力測試，測試覆蓋率怎么考慮，測試通過率怎么定義，如何區(qū)分不同層次測試的責(zé)任人，缺陷的處理方式，測試與需求的追溯性要求，單元測試必須在其他測試前完成，回歸測試時測試用例如何選擇，自動化測試比例及開始時機怎么定義，必須執(zhí)行全量測試的標(biāo)準(zhǔn)等等。
會有很多的角度去定義，無法詳述。
總之，是一些基于公司策略和歷史經(jīng)驗等制定的綱領(lǐng)性的文件。
當(dāng)然，多數(shù)不那么規(guī)范的公司不會定義很細(xì)，要求也不會很嚴(yán)格，姑且有這么個概念。
1.2 測試目標(biāo)
測試目標(biāo)呢，比較寬泛的理解有查找問題、確認(rèn)滿足需求、避免問題泄漏、保證客戶滿意、提升質(zhì)量、降低成本、推進(jìn)持續(xù)改善等等。
這些內(nèi)容雖然并不難理解，但還是太泛泛而談了。
在具體的某個客戶、某個平臺、某個項目、某次迭代、某次交付的組合里，會有多方面因素要考慮，這是個復(fù)雜的且需要背景信息的事，無法簡單說明。
舉幾個可能需要思考的問題，感性感覺下。
這個客戶對測試報告的提交需求是什么？這次上了哪些主要功能點？該平臺或該項目是否有歷史LLs？已經(jīng)識別到什么潛在風(fēng)險需要測試探測嗎？內(nèi)部有什么質(zhì)量目標(biāo)？本次交付變更點是什么？自動化測試臺架是否可用？這次是工程車間裝車，還是臺架或者產(chǎn)線？什么功能是本次交付最關(guān)注的？是否上路，上什么路……
綜合各種信息，項目經(jīng)理或測試經(jīng)理可以來統(tǒng)籌判斷及調(diào)整本次測試的目標(biāo)，據(jù)此再來進(jìn)行后續(xù)的計劃、執(zhí)行等工作。
1.3 測試原則
考試有答題技巧，工作有方法論，打仗有兵法。測試原則差不多等同于這類。在整個和測試相關(guān)的工作中，是否有一些參考性的原則呢？
1、要盡可能早地測試。這是質(zhì)量成本的原則，發(fā)現(xiàn)問題越晚，成本和影響越高越大。
2、不可能進(jìn)行窮舉式測試。進(jìn)行完全的測試是不可能的，完全沒有任何缺陷的軟件也是不存在的，要根據(jù)風(fēng)險評估進(jìn)行測試用例設(shè)計，進(jìn)行最佳的測試量定義。
3、關(guān)注缺陷群集效應(yīng)。二八法則我們都聽說過，在此也是適用的，少量的模塊經(jīng)常包含大部分缺陷。統(tǒng)計數(shù)據(jù)也表明，一段程序已發(fā)現(xiàn)的缺陷越多，則該段程序發(fā)生更多缺陷的可能性也很大.
4、殺蟲劑悖論。如果同一個測試人員重復(fù)執(zhí)行相同的測試，該方法將無法發(fā)現(xiàn)新的測試缺陷。這既有測試用例更新不及時的原因，也有測試人員的思維定勢和思維懈怠的原因。所以測試用例要經(jīng)常更新，測試人員也可以適時輪換。
5、測試只能證明存在缺陷，而無法證明不存在缺陷。因為測試實際上是一個樣本實驗，不可能涵蓋所有情況。
6、沒有缺陷不代表軟件一定能夠使用。比如測試用例本身未覆蓋需求，這其實說明了測試本身的局限性，也說明了我們要進(jìn)行全方位軟件開發(fā)及測試管理的必要性。
7、測試最好由非軟件開發(fā)人員擔(dān)任。這是從心理學(xué)角度來看的，畢竟讓一個人否定自己的工作是令人沮喪的，而且如果開發(fā)人員對某個功能有錯誤認(rèn)識，再去測試可能依舊無法識別。
8、測試順序。為了盡可能早地合理退出，要首先執(zhí)行具有較高失敗概率的測試。比如，最好依次進(jìn)行冒煙測試（核心功能預(yù)測試）、缺陷重新測試、測試新功能、測試修改或優(yōu)化的特性、測試未改變的特性(回歸測試)。
實際工作中，策略更多是在項目經(jīng)理或測試經(jīng)理腦子里的整體謀篇布局，以上三個維度是落于紙面上的一個參考。
2
測試管理
有個通盤的策略性考量后，就可以進(jìn)入管理層面的工作上了。
接下來看測試管理。
當(dāng)組織結(jié)構(gòu)龐大和軟硬件功能復(fù)雜時，測試也同樣會變得很復(fù)雜和容易混亂。
這時，就非常需要由專門的人按照特有的流程進(jìn)行組織和管理。管理的范疇很大，為了避免描述混雜在一起，我們這里只談小管理，不涉及具體工程層面的內(nèi)容。
我們可以將測試管理的目標(biāo)定義為，根據(jù)確定的測試范圍，交付與測試相關(guān)的工作包（例如，測試規(guī)范、測試執(zhí)行、評審和報告等），同時還要滿足項目進(jìn)度計劃中定義的里程碑節(jié)點。
簡單來說，就是先要明確誰在什么時間做完什么，然后，在出現(xiàn)異常時，進(jìn)行調(diào)整。
當(dāng)然，這個交付目標(biāo)的達(dá)成需要很多支持。
首先，要明確做什么，根據(jù)我們的策略定義測試范圍，比較粗略的分類，可能會有單元測試、集成測試、系統(tǒng)測試，以及輔助性的文檔、報告、評審之類的工作。這些內(nèi)容之間可能會有依賴關(guān)系和前后次序等。同時，也要識別出責(zé)任人，根據(jù)我的項目經(jīng)驗，沒有明確到具體的人的任務(wù)99%會延期。
接下來，要確認(rèn)資源（Resource），這里包括人員和設(shè)備及樣品，再細(xì)分還要看人員是否充足與人員能力是否足夠、設(shè)備及樣品是否充足和可用。比如，可能考慮到軟件測試工程師、系統(tǒng)測試工程師、具備特殊測試能力的專家，以及臺架、ECU、線束、CAN工具、診斷儀、示波器等等。當(dāng)這些有問題時，就需要管理人員進(jìn)行調(diào)配。
對于執(zhí)行人而言，會提出工作包的完成時間（Duration），這個也是經(jīng)常在測試人員和管理人員之間針鋒相對的地方，測試人員希望As long as possible，管理人員希望As soon as possible。就看實際工作中，如何論戰(zhàn)和平衡了。
如果成本管控比較好的公司，還會考慮成本（Cost），一般包含人員工時和材料成本。特別是涉及到第三方公司或其他獨立結(jié)算團隊時。
對于項目經(jīng)理而言，最關(guān)心的是完成的截止時間及監(jiān)控，也就是催催催。根據(jù)整個項目的進(jìn)度和前面的一些梳理，就可以得到詳細(xì)的計劃。至于所需的詳細(xì)程度，取決于產(chǎn)品的復(fù)雜性和所涉及的測試人員的數(shù)量等。
然而，出問題和延期幾乎是必然的，基本沒有哪一個項目能夠完全避免，解決這些問題也是管理人員最主要的任務(wù)了。或拿出自己的Buffer，或減少測試，或調(diào)整優(yōu)先級，或談判，或帶風(fēng)險并行，或升級管理層支持。
整個管理過程會有不同的工具支持、流程部署、模式風(fēng)格，暫不詳述，各有各的做法。
這里給一個我所見到的眾多做法中做得比較嚴(yán)謹(jǐn)?shù)陌咐?/span>
簡單思路是，在測試之初，定義一張完整的測試全量計劃表，這里面包含系統(tǒng)、軟件、硬件、結(jié)構(gòu)等所有的測試條目，以及每個條目測試與否、不測試的分析理由、通過與否、對應(yīng)缺陷和報告鏈接等。由項目經(jīng)理或測試經(jīng)理作為總負(fù)責(zé)人，組織相關(guān)人員進(jìn)行測試范圍識別、測試計劃排定、測試進(jìn)度跟蹤、測試報告提交完善等。每次迭代都對應(yīng)這樣一份統(tǒng)一的測試匯總表，通過這種方式可以系統(tǒng)地將測試管理起來。
3
測試過程
上面的闡述都屬于規(guī)劃管理性質(zhì)，下面開始進(jìn)入具體操作層面。
測試的分類方法有很多種，比如。
按照測試時序，可以把整體的測試過程分為需求分析、測試計劃、測試設(shè)計、測試環(huán)境搭建、測試執(zhí)行、測試報告這幾大部分。
按照測試類型，可以分為功能測試、性能測試、負(fù)載測試、壓力測試、冒煙測試、安全性測試、兼容性測試等。
按照是否執(zhí)行程序，可以分為靜態(tài)測試和動態(tài)測試。
按照對軟件內(nèi)部信息的了解程度，可以分為黑盒測試、白盒測試、灰盒測試。
按照測試層次呢，又可以分為單元測試、軟件集成測試、軟件需求測試、系統(tǒng)集成測試、系統(tǒng)測試、驗收測試這幾大部分。
從另外一個工程應(yīng)用的思路，我們將測試層次還能做一個整合，單元測試、集成測試都屬于“設(shè)計”層（Technical），軟件需求測試和系統(tǒng)測試屬于“功能”層（Functional），而驗收測試屬于“方案”或“問題解決”層（Solution）。
五花八門，不一而足。
粗略來看，從測試層次的角度，基本也能夠覆蓋到其他分類的內(nèi)容。為了理解起來比較清晰，而且業(yè)內(nèi)講得非常多的V模型或ASPICE也是按照層次來劃分的，所以我們著重從測試層次逐一鋪展開。
3.1 單元測試
單元測試是軟件驗證的最低級別，是對軟件的最小可測單元進(jìn)行驗證的工作。
但如何定義單元一直是爭論的焦點，通常我們會說是一個函數(shù)，可有的函數(shù)代碼段很短，這樣去做又會顯得很浪費，經(jīng)常也會將單元異化為具有獨立功能的組件。
總之，單元是一個人為定義的最小測試點，去針對軟件的詳細(xì)設(shè)計（即代碼）來進(jìn)行的，一般是開發(fā)自己去完成的。
測試方法會有靜態(tài)代碼分析，如熟知的基于MISRA C規(guī)范的靜態(tài)代碼掃描，或者關(guān)注代碼覆蓋率的測試，如語句覆蓋率、分支覆蓋率、MC/DC覆蓋度等。
在這個階段之后，軟件組件可以被集成了。
3.2 軟件及系統(tǒng)集成測試
軟件集成測試的目的是為集成的軟件組件與軟件架構(gòu)的一致性提供證據(jù)，包括組件之間的接口。
測試的內(nèi)容可能包括通過接口的數(shù)據(jù)是否丟失、組件組合后能否達(dá)到預(yù)期父功能以及一個組件是否會對其他組件造成影響等。
此外，非功能的測試會涉及到CPU負(fù)載率、內(nèi)存占有率等資源消耗的內(nèi)容。
在測試思路的選擇上，一般有兩類：增量式和非增量式，主要差別在于是一次性集成完畢后一次性測試，還是邊集成邊測試。前者容易造成大量缺陷報出而難以定位原因的問題，而且修改過程也會不斷引入新問題，造成混亂。
系統(tǒng)集成測試呢，是沿著HW/SW的接口進(jìn)行的，通過物理引腳（物理層）和邏輯協(xié)議（邏輯層）連接的HW/SW接口構(gòu)成系統(tǒng)內(nèi)部接口。
因此，系統(tǒng)集成的先決條件是已經(jīng)集成的軟件和硬件。從技術(shù)上講，系統(tǒng)集成只需根據(jù)BOM在硬件上刷新軟件即可。這和軟件集成過程中功能集成是逐步進(jìn)行的有些不同。
盡管理論上，軟件集成測試是側(cè)重于軟件模塊之間的接口的，系統(tǒng)集成測試是著眼于軟硬件之間的接口的，但是系統(tǒng)不會單獨懸浮于軟件和硬件之上，硬件需要軟件驅(qū)動，軟件也需要運行在硬件上，所以系統(tǒng)集成測試的用例往往來源于軟件或硬件各自的測試，有時也會來源于系統(tǒng)測試。
此外，還可以提的一點是，系統(tǒng)可以分幾個層級的，比如，ECU能作為一級系統(tǒng)，ECU加傳感部件能作為二級系統(tǒng)，ECU加傳感部件再加執(zhí)行部件能作為三級系統(tǒng)，三級系統(tǒng)集成于整車環(huán)境里還能被定義為四級系統(tǒng)。
宏觀來講，系統(tǒng)集成測試需要考慮到這所有的系統(tǒng)及對應(yīng)接口，只不過越往上走，就越不是單一的軟件范疇了。
3.3 軟件及系統(tǒng)需求測試
軟件需求測試，顧名思義，就是為在芯片上運行的集成軟件符合軟件需求提供證據(jù)，證明軟件功能滿足需求。
系統(tǒng)需求測試呢，習(xí)慣被簡稱為系統(tǒng)測試，也是類似，是確保測試集成系統(tǒng)，以提供符合系統(tǒng)需求的證據(jù)，并確保系統(tǒng)已準(zhǔn)備好交付。
與軟件需求測試的差別，主要是系統(tǒng)需求測試要在集成軟件、標(biāo)定、硬件、外設(shè)設(shè)備、數(shù)據(jù)乃至人員的系統(tǒng)下進(jìn)行的，這也是最常見的最終交付前的測試。
測試內(nèi)容上，主要是針對需求、風(fēng)險、特定用例或其他高層級系統(tǒng)行為的描述進(jìn)行的功能測試與非功能測試（如性能、負(fù)載、壓力、可靠性、魯棒性、恢復(fù)性、安全性、兼容性等各類測試）。
這個層次的測試也都是黑盒測試，不需要了解內(nèi)部實現(xiàn)細(xì)節(jié)，只需關(guān)注輸入與輸出。
3.4 驗收測試
驗收測試，實際上已經(jīng)脫離了嚴(yán)格意義的工程開發(fā)的范疇，在ASPICE里也沒有明確定義。
但是，現(xiàn)在行業(yè)內(nèi)越來越多地思考用戶導(dǎo)向和用戶思維，所以把驗收測試單獨拿了進(jìn)來。
我傾向于把驗收測試定義為非專業(yè)的客戶評判，比如汽車行業(yè)領(lǐng)導(dǎo)或特定人員的試駕，就屬于比較典型的驗收測試，它是更高層級的、更貼近實際使用的一種確認(rèn)，他們可能不懂軟件，不懂汽車，只是從自己的需要上來給出判斷。
還有個例子，你買新房交房時或者毛坯房裝修后，業(yè)主要去驗房，就是典型的驗收測試，他們顯然不那么懂裝修、懂材料、懂建筑資質(zhì)、懂行業(yè)標(biāo)準(zhǔn)，但他們會從使用上、美觀上、感覺上去評判。
以往的汽車行業(yè)基本不太會關(guān)注終端消費者的切身體驗，大家沒那么多可選的，造什么買什么。現(xiàn)在及往后的時間，終端消費者會介入得越來越多，以新勢力為領(lǐng)頭的各大車企也會不遺余力地關(guān)注到他們的“驗收”。
4
測試報告
測試報告及相應(yīng)文檔定義的主要的焦點在于測試基礎(chǔ)（需求或設(shè)計）和所有測試級別上相應(yīng)的測試用例及結(jié)果之間的可跟蹤性。
理論上或者說做得比較好的，這些測試相關(guān)文檔都要通過配置管理管理起來。
測試執(zhí)行后，得到的結(jié)果和評估結(jié)果被輸入到不同格式的報告中。其中的評估必須要進(jìn)行，以避免不適當(dāng)?shù)臏y試用例或測試環(huán)境引起的“假陽性”，就像最近持續(xù)做的核酸檢測，要審核的。
測試失敗的用例要建立相應(yīng)的缺陷記錄，以確保可追溯性。如果一個缺陷在專家評審后可以被接受，那么它也應(yīng)該在測試文檔中被清楚地注釋。
5
測試匯總
這一部分就到了我們這條“脈絡(luò)”的結(jié)尾，實際項目中很多都沒有這部分，各類報告都是散落各處的、千奇百怪模板的、由各人負(fù)責(zé)的報告。
為了”客戶”滿意，我想這個工作包最好是有。
一份整體測試狀態(tài)的匯總可以比較清晰地讓內(nèi)外部都知道當(dāng)前的或歷史的軟件質(zhì)量狀態(tài)。
當(dāng)然，做起來會有些障礙，特別是系統(tǒng)復(fù)雜、分工細(xì)的領(lǐng)域，及時且準(zhǔn)確維護一張不斷更新的大表是需要一番心力的，后續(xù)我們可以探討下是否有改善思路。
文章有點長，但還是只能在“皮毛”和“脈絡(luò)”上聊一下，畢竟測試是一門很大的學(xué)問。
最后呢，嘗試總結(jié)一下這條“脈絡(luò)”。
汽車軟件測試是一項以尋找問題為主要目標(biāo)，基于各種組織策略、測試原則和業(yè)務(wù)限制，而進(jìn)行多層次驗證并提供證據(jù)的管理和工程實踐工作。
轉(zhuǎn)自水輕言
