在構思這(zhè)個(gè)主題的(de)題目時(shí)，腦(nǎo)子(zǐ)‌β≈裡(lǐ)先是(shì)蹦出來(lái)三個(gè)詞，“哲學”、“本質”和(hé)“底層邏≈‌×輯”。

同時(shí)轉念一(yī)想，打算(suàn)通(tōng)過一(yī♥±)篇文(wén)章(zhāng)就(jiù)想探到(dào)如(  €≥rú)此深度豈非癡心妄想和(hé)不(bù)知(α‌zhī)天高(gāo)地(dì)厚。實際上(shàng)，諸多(duō)冠此類✘₽☆帽子(zǐ)的(de)文(wén)章(zhāng)多(duō)是(shì)名不(bù)副實₽‌&。算(suàn)了(le)，人(rén)近(jìn)不(b§δ↕ù)惑，腦(nǎo)力漸衰，把書(shū)讀(dú)薄也(yě)更甚于讀©®↓(dú)厚。

 

不(bù)過，讀(dú)薄的(de)前提至少(shǎo)是(shì)要(yào)有(yǒu)體(t γǐ)系和(hé)脈絡。所以選用(yòng)了(le)“脈絡”這(zhè)個(gè)詞，細想來(←≈∞¥lái)，确實比前面想到(dào)的(de)那(nà)三個(gè)詞更合我Ω₩≥真意。

 

在開(kāi)始這(zhè)條脈絡之前，還(hái)是(shì)先把概念澄清™σ♣®，以設定一(yī)個(gè)理(lǐ)解÷≤λ©基線。

0

什(shén)麽是(shì)軟件(jiàn ≠✔ )測試？

《軟件(jiàn)測試的(de)藝術(shù)》的(de)作(zuò)者梅耶的(de)定義是(σλ×shì)“軟件(jiàn)測試就(jiù)是(shì)為(wèi)了(le)發現(xiàn)缺陷而★‍&₹運行(xíng)程序的(de)過程”。

 

盡管不(bù)同的(de)角色在不(bù)同的(de)角度都(d<★ ōu)有(yǒu)不(bù)同的(de)定義，比如(rú)有(yǒu)從(cóng)需求入手÷σ₽的(de)、有(yǒu)從(cóng)質量著(zhe)眼的(de)，≤↓也(yě)有(yǒu)從(cóng)一(yī)緻性、風(fēng)險和(hé↔✘ α)成本等展開(kāi)的(de)……

各有(yǒu)各的(de)道(dào)理(lǐ)，但(dà≤™n)我從(cóng)實務的(de)角度看(kàn)，∑ 選用(yòng)了(le)梅耶的(de)定義，畢竟運行(xíng)程序發現(xiàn)缺陷是(shì)我們日(rì)常可(kě)見(∑'¥jiàn)的(de)測試的(de)最顯著特點。

 

好(hǎo)，正式開(kāi)始。

 

為(wèi)了(le)更貼近(jìn)實際項目運行(xíng)，我大♦£(dà)體(tǐ)按照(zhào)業(yè)務的(de)運行(xíng)時(shí)間(jiān‍"‍£)線，把這(zhè)條脈絡的(de)一(yī)頭一(yī)尾分(fēn)别定λ★®義為(wèi)“測試策略”和(hé)“測試彙總”。

1

測試策略 

在企業(yè)裡(lǐ)，我們所做(zuò)的(de)所有(yǒu)工(gōng)作(zuò>α)，從(cóng)來(lái)不(bù)是(sh±‌♠≠ì)獨立的(de)，也(yě)從(cóng)來(lái)不(bù)是(shì)單一✘ ☆$(yī)的(de)技(jì)術(shù)問(wèn)題或者管理(lǐ)問(wèn±☆©)題，而是(shì)需要(yào)一(yī)個(gè)統± σε籌的(de)考慮。

 

測試也(yě)一(yī)樣，開(kāi)始之前我¶♦∏∏們要(yào)有(yǒu)“策略”，這(zhè)是(shì)一(yī)個(gè)High-level的(de)♥φδ¥概念，多(duō)少(shǎo)有(yǒu)一(yī)點模棱兩可(kě)，很(hěn)難說(←↑∞shuō)清楚其準确內(nèi)涵，不(bù)同幹系人(rén)也(yě)有(yǒu)不(bù)同的(de)期望，本文(wén)給三個(gè)參考的(de)維度，分(fēn)别是(shì)測試規則或指南(nán'↓←)、測試目标和(hé)測試原則。

 

盡管實際工(gōng)作(zuò)中，我們基本無法清晰地(dì)拆分♠​(fēn)出隸屬于不(bù)同維度的(de∞∞✘‌)工(gōng)作(zuò)，而是(shì)相(xiàng)互混雜(zá)和(£&hé)滲透，但(dàn)為(wèi)了(le)便于溝通(tōng)和(hé)理(lǐ'€☆)解，暫且還(hái)是(shì)按此拆分(fēn)。

1.1 測試規則或指南(nán)

 

測試規則或指南(nán)，我們把它定義為(wèi)統領性、強制(zhì)性或×‌推薦性的(de)一(yī)些(xiē)規則、要(yào)求或建議(yì)，它們一(yī)般由公司層☆♠♥≥面整體(tǐ)定義，并要(yào)求執行(xíng)。

 

比如(rú)，什(shén)麽節點前應該做(zuò)測試分(fēn)析∏α，應該用(yòng)哪個(gè)報(bào)告模闆，什(shén)麽測試條'α€目是(shì)必測項，測試用(yòng)例的(de)選擇要(yào)考慮哪些(xiē)，測試的±φ ★(de)準入準出規則是(shì)什(shén)麽，是(shì)否必須先完成冒煙(yān)測試，什(↔₹shén)麽情況下(xià)必須做(zuò)壓力測試，測試覆蓋率怎麽考慮，測試通(tōn™β>←g)過率怎麽定義，如(rú)何區(qū)分(fēn)不(bù)同層次γ♣£測試的(de)責任人(rén)，缺陷的(de)處理(lǐ)方式，測試與需求的(d<φ e)追溯性要(yào)求，單元測試必須在其他(tā)測試前完成，↑£↓回歸測試時(shí)測試用(yòng)例如(rú)何選擇，自(zì)動化(huà)測試比例及開(kāi$​<×)始時(shí)機(jī)怎麽定義，必須執行(xíng)全量測試的(de)标準等等。♠→‌§

會(huì)有(yǒu)很(hěn)多(duō)的(de)角度去(qù₹$)定義，無法詳述。

 

總之，是(shì)一(yī)些(xiē)基于¥γ♣ 公司策略和(hé)曆史經驗等制(zhì)定的(de)綱領性的(de)♦♥≠文(wén)件(jiàn)。

 

當然，多(duō)數(shù)不(bù)那(nà)麽規範的©♠​₩(de)公司不(bù)會(huì)定義很(hěn)細，要(yào)求也(yě)不(bù>φφ)會(huì)很(hěn)嚴格，姑且有(£€≈≥yǒu)這(zhè)麽個(gè)概念。

1.2 測試目标

 

測試目标呢(ne)，比較寬泛的(de)理(lǐ)解有(yǒu)查£•★'找問(wèn)題、确認滿足需求、避免問(wèn)題洩漏、保證客戶滿意、提升質量、降低(×ε₽dī)成本、推進持續改善等等。

這(zhè)些(xiē)內(nèi)容雖然并不(bù)難理(lǐ)解，但(dàn)還(hái)是₽₽£™(shì)太泛泛而談了(le)。

 

在具體(tǐ)的(de)某個(gè)客戶、某個(gè)平台、某個(gè☆≈)項目、某次叠代、某次交付的(de)組合裡(lǐ)，會(huì)有(yǒu)多(d✔§uō)方面因素要(yào)考慮，這(zhè)是(shì)個(gè)複雜(zá)的(de)且需要™₹≥(yào)背景信息的(de)事(shì)，無法簡Ωβ單說(shuō)明(míng)。

 

舉幾個(gè)可(kě)能(néng)需要(yào)思考的♣∏"₽(de)問(wèn)題，感性感覺下(xià)。

這(zhè)個(gè)客戶對(duì)測試報(bào)告的(de)提交需求是(shì)什☆'¶(shén)麽？這(zhè)次上(shàng)了(le)哪些(xiē)主要(yào &)功能(néng)點？該平台或該項目是(shì)否有✔÷↕ (yǒu)曆史LLs？已經識别到(dào)什(shén)麽潛在風(fēng)險需要(yào)測試探測嗎(ma)？內(n>☆λèi)部有(yǒu)什(shén)麽質量目标？本次交付變更點是(shì)什(shén)麽？自(z↕→εì)動化(huà)測試台架是(shì)否可(kě)用(yòng)？這(zhè∑÷Ω©)次是(shì)工(gōng)程車(chē)間(≠ σjiān)裝車(chē)，還(hái)是(shì)台架或者 $§産線？什(shén)麽功能(néng)是(shì)本次交付最關注的(de)？是(shì)Ω‍↔©否上(shàng)路(lù)，上(shàng)什(shén)←₽麽路(lù)……

 

綜合各種信息，項目經理(lǐ)或測試經理£₩∞(lǐ)可(kě)以來(lái)統籌判斷及調整本次測試的(de)目标，據此再來(lái)進行(x÷×εíng)後續的(de)計(jì)劃、執行(xí€‌γ±ng)等工(gōng)作(zuò)。

1.3 測試原則

 

考試有(yǒu)答(dá)題技(jì)巧，工(gōng)作(zuò)有(yǒu)方法論，打↓™↕仗有(yǒu)兵(bīng)法。測試原則差不(bù)多(duō)等同于這(zhè)類。₩$✔在整個(gè)和(hé)測試相(xiàng)關的(de)工(gōn≠₹<Ωg)作(zuò)中，是(shì)否有(yǒu)一(yī)些(xi₽←Ω↕ē)參考性的(de)原則呢(ne)？

 

1、要(yào)盡可(kě)能(néng)早₹£★£地(dì)測試。這(zhè)是(shì)質量成本的(de)原則，>£€發現(xiàn)問(wèn)題越晚，成本和(hé)影(yǐng)響越高(gāo) Ω'越大(dà)。

 

2、不(bù)可(kě)能(néng)進行(xíng)窮舉式測試。進行(xíng)完全的(de)測試是(shì)不(bù)可(kě)能(néng)Ω★的(de)，完全沒有(yǒu)任何缺陷的(de)軟件(jiàn)也(yě)是(sh÷☆φì)不(bù)存在的(de)，要(yào)根據風(fē♣'☆δng)險評估進行(xíng)測試用(yòng)例設計(jì)，進§≈♠♣行(xíng)最佳的(de)測試量定義。

 

3、關注缺陷群集效應。二八法則我們都(dōu)聽(tīng)說¶✔∞∑(shuō)過，在此也(yě)是(shì)适用(yòng)的(de)，少∞§'&(shǎo)量的(de)模塊經常包含大(dà↓€★)部分(fēn)缺陷。統計(jì)數(shù)據也(yě)表明(míng)，一(yī)段程序已發現‍‍(xiàn)的(de)缺陷越多(duō)，則該段程序發生(shēεπng)更多(duō)缺陷的(de)可(kě)能(néng)性也(yě)很(hěn)大(d☆∑à).

 

4、殺蟲劑悖論。如(rú)果同一(yī)個(gè)測試人(rén)員(yuán)重複執行(xíng)相(xi✘&₽àng)同的(de)測試，該方法将無法發現(xiàn)新的(de)測試缺陷‍α♥。這(zhè)既有(yǒu)測試用(yòng)例更新不(bù)及φδ$​時(shí)的(de)原因，也(yě)有(yǒu)測試人(rén)員<♦(yuán)的(de)思維定勢和(hé)思維懈怠的(de)原因。所以測試用(yòng)例要(yào§←×₩)經常更新，測試人(rén)員(yuán)±← ¥也(yě)可(kě)以适時(shí)輪換。

 

5、測試隻能(néng)證明(míng)存在缺∑↓☆陷，而無法證明(míng)不(bù)存在缺陷。因為(wèi)測試實際上(shàng)是(shì)一(yī)個(gè)樣本∑$實驗，不(bù)可(kě)能(néng)☆>涵蓋所有(yǒu)情況。

 

6、沒有(yǒu)缺陷不(bù)代表軟件(jiàn)一(yī)定能•♣₩(néng)夠使用(yòng)。比如(rú)測試用(yòng)例本身(shēn)未覆蓋需∞&求，這(zhè)其實說(shuō)明(míng)了(le)測試本身(sΩ®δhēn)的(de)局限性，也(yě)說(s§↑↓↕huō)明(míng)了(le)我們要(yào)進行(xíng)全方位軟件(jiàn)開(β₹kāi)發及測試管理(lǐ)的(de)必要(yào)性。

 

7、測試最好(hǎo)由非軟件(jiàn)開(kāi)發人(rén)員(yuán)擔任。這(zhè)是(shì)從(cóng)心理(lǐ)學角度來(lái)看(kà≠&n)的(de)，畢竟讓一(yī)個(gè)人(rén)否•σ•定自(zì)己的(de)工(gōng)作(zuò)是(§₩shì)令人(rén)沮喪的(de)，而且如(rú)果開☆λ(kāi)發人(rén)員(yuán)對(duì)某個(gè)功能(néng)有(yǒu)錯(cu÷∑ò)誤認識，再去(qù)測試可(kě)能(néng)依舊(jiù)無法識别。

 

8、測試順序。為(wèi)了(le)盡可(kě)能(néng)早地(dì)合理•∏¶×(lǐ)退出，要(yào)首先執行(xíng)具有(yǒu)較高(gāo)↑±↕失敗概率的(de)測試。比如(rú)，最好(hǎo)依次進行(x≤£‌íng)冒煙(yān)測試（核心功能(néng)預測試）、缺陷重新測試、測試新功能(néng)✔≈φ≈、測試修改或優化(huà)的(de)特性、測試未改變的δ$☆(de)特性(回歸測試)。

 

實際工(gōng)作(zuò)中，策略更多(duō)是(shì)在項目經理(lǐ)或測試經理↓∑(lǐ)腦(nǎo)子(zǐ)裡(lǐ)的(de)整體(tǐ)謀篇布局，以上(s×₹∏hàng)三個(gè)維度是(shì)落于紙(zhǐ)面上(shàng)的(d↔✔≈♥e)一(yī)個(gè)參考。

2

測試管理(lǐ)

有(yǒu)個(gè)通(tōng)盤的(de)策略性考✔≥→量後，就(jiù)可(kě)以進入管理(lǐ♣★)層面的(de)工(gōng)作(zuò)上(shàng)了(le)。

 

接下(xià)來(lái)看(kàn)測試管理(lǐ)。

 

當組織結構龐大(dà)和(hé)軟硬件(jiàn)功能(néng)複雜(↑εzá)時(shí)，測試也(yě)同樣會(huìφφ)變得(de)很(hěn)複雜(zá)和(hé)容易混亂。

這(zhè)時(shí)，就(jiù)非常需要(yào)由專門(mén)的(de)人(rén)¥‍§φ按照(zhào)特有(yǒu)的(de)流程進行(xíng)組織和(hé)管理(lǐ)。管理(l‍λǐ)的(de)範疇很(hěn)大(dà)，為↓π★€(wèi)了(le)避免描述混雜(zá)在一(yī)起，我們這(zhè)裡(l≈γ↕ǐ)隻談小(xiǎo)管理(lǐ)，不(bù)涉及具體(tǐ)工(gōng)程層面的(de)δπ 內(nèi)容。

 

我們可(kě)以将測試管理(lǐ)的(de)目标定義為(wèi)，根據确定的(de)測試範圍，交付與測試相(xiàng)關的(de)工(gōng)作(zuò£α♣)包（例如(rú)，測試規範、測試執行(xíng)♠ ♦、評審和(hé)報(bào)告等），同時(shí)還(hái)要(yào)滿足項目進度計(jì♦δ)劃中定義的(de)裡(lǐ)程碑節點。

 

簡單來(lái)說(shuō)，就(jiù)是(shì)先要±≈÷€(yào)明(míng)确誰在什(shén)麽>€時(shí)間(jiān)做(zuò)完什(shén)麽，然後，在出現(x♠€βiàn)異常時(shí)，進行(xíng)調整。

 

當然，這(zhè)個(gè)交付目标的(de)達成需₩‍要(yào)很(hěn)多(duō)支持。

 

首先，要(yào)明(míng)确做(zuò)什→‍(shén)麽，根據我們的(de)策略定義測試範圍，比較粗略的(de)分(fēn)類，可(kě)能(néng)會(huì)有(yǒu)單元∏♦✘測試、集成測試、系統測試，以及輔助性的(de)文(wén)≈‌檔、報(bào)告、評審之類的(de)工(gōng)作(z≈±uò)。這(zhè)些(xiē)內(nèi)容↑∏Ω之間(jiān)可(kě)能(néng)​↑σλ會(huì)有(yǒu)依賴關系和(hé)前後次序等。同時(shí)，←​λ也(yě)要(yào)識别出責任人(rén)，根據我的(Ω"de)項目經驗，沒有(yǒu)明(míng)确到(dào)具體÷γ←(tǐ)的(de)人(rén)的(de)任務99%會(huì)延期。

 

接下(xià)來(lái)，要(yào)确認資源（♥§Resource），這(zhè)裡(lǐ)包括♥¶×$人(rén)員(yuán)和(hé)設備及樣品，再細分(fēn)還(há←₹≠i)要(yào)看(kàn)人(rén)員(yuπ÷₹αán)是(shì)否充足與人(rén)員(yuán)能(néng)力是(shì)否足夠、設備&§ ×及樣品是(shì)否充足和(hé)可(kě ✘♦​)用(yòng)。比如(rú)，可(kě)能(néng)考慮到(dào)軟件(jiàn)測試工(gō↓↕ng)程師(shī)、系統測試工(gōng)程師(shī)、具備特殊測試能(né≥×π÷ng)力的(de)專家(jiā)，以及台架、ECU、線束、CAN工(gōng)具、 ↕✘$診斷儀、示波器(qì)等等。當這(zhè)些(xiē)有(yǒu)問(wèn)題時™ ☆‌(shí)，就(jiù)需要(yào)管理(lǐ)人(rén)員(y&✔‍☆uán)進行(xíng)調配。

 

對(duì)于執行(xíng)人(rén)而言，會(huì)提出  ↔工(gōng)作(zuò)包的(de)完成時(shí)間(jiā'™↔n)（Duration），這(zhè)個(gè)也(yě)是(shì)經常在測試​‌人(rén)員(yuán)和(hé)管理(lǐ)人(rén)員(δ¶₹≠yuán)之間(jiān)針鋒相(xiàng)對(duì)的(de)地(dì)方，測試人(rén>±₩∞)員(yuán)希望As long as possible，管理(lǐ)人(réπ≤→♥n)員(yuán)希望As soon as possible。就(jiù¶≤)看(kàn)實際工(gōng)作(zu÷σò)中，如(rú)何論戰和(hé)平衡了(le)。

 

如(rú)果成本管控比較好(hǎo)的(de)公司，還(hái)會↓  (huì)考慮成本（Cost），一(yī)般包含人(rén)員(yuán)工(gōng)≥δ©δ時(shí)和(hé)材料成本。特别是(shì)涉及到(dào)第三方公司或其他(tā)獨立結算(suàn)團隊π‍時(shí)。

 

對(duì)于項目經理(lǐ)而言，最關心的(de)是(shì)¶ 完成的(de)截止時(shí)間(jiān)及監控，也( §✘yě)就(jiù)是(shì)催催催。根據整個(gè)項目的(de)進度和(hé)前面的(de)一(yī)些(xiē)梳∞✔™±理(lǐ)，就(jiù)可(kě)以得(de)到(dào)詳細的(de)計(jì•‌&')劃。至于所需的(de)詳細程度，取決于産品的(de)複雜(zá)性和(hé)所涉及的(de)測✔✔π∞試人(rén)員(yuán)的(de)數(shù)量等。

 

然而，出問(wèn)題和(hé)延期幾乎是(shì∑& ≈)必然的(de)，基本沒有(yǒu)哪一(yī)個(gè£β)項目能(néng)夠完全避免，解決這(α✔λzhè)些(xiē)問(wèn)題也(yě✘£ )是(shì)管理(lǐ)人(rén)員(yuán)最主要(yào)©∏的(de)任務了(le)。或拿(ná)出自(zì)己的(de)Buffer，或減少(s₹•hǎo)測試，或調整優先級，或談判，或帶風(fēng)險并行β↔↔(xíng)，或升級管理(lǐ)層支持。

 

整個(gè)管理(lǐ)過程會(huì)∞↓有(yǒu)不(bù)同的(de)工(gōng)具支持、流程部署、模式風(f≤₽ēng)格，暫不(bù)詳述，各有(yǒu)各的(de)做(zuò÷₹)法。

 

這(zhè)裡(lǐ)給一(yī)個(gè)我所見(jiàn)到(dào)的(de)衆多★  (duō)做(zuò)法中做(zuò)得(de)比較嚴謹的(de)案例。

 

簡單思路(lù)是(shì)，在測試之初，定義一(yī)張完整的(de)測試全 ✔™©量計(jì)劃表，這(zhè)裡(lǐ)面包含系統、軟件(jiàn)、硬件(jiàn)、♦¥✔•結構等所有(yǒu)的(de)測試條目，以及♠♦ γ每個(gè)條目測試與否、不(bù)測試的(→↑$€de)分(fēn)析理(lǐ)由、通(tōng)過與否、對(duì)應缺陷和(hé)報(bào)♦≥告鏈接等。由項目經理(lǐ)或測試經理(lǐ≠×↑→)作(zuò)為(wèi)總負責人(rén)，組織相(xiàn€εg)關人(rén)員(yuán)進行(xíng)測試範圍識别、測試計α÷(jì)劃排定、測試進度跟蹤、測試報(bào)告提交完善等。每次叠∏ ♥₽代都(dōu)對(duì)應這(zhè)樣一(yī)份統一(yī)的(de)測試彙總表，通(↔÷™tōng)過這(zhè)種方式可(kě)以系統地(dì)将測試管理(lǐ)起來(lái)。

3

測試過程

上(shàng)面的(de)闡述都(dōu)屬于規劃管理(lǐ)性質，下(xià☆σ®​)面開(kāi)始進入具體(tǐ)操作(zuò)層面。

 

測試的(de)分(fēn)類方法有(yǒu)很(hěn)多(duō)種，比如(rú)。

 

按照(zhào)測試時(shí)序，可(kě)以把整體(tǐ)的(de)測試過程分(fēn)為(wèλ↓×i)需求分(fēn)析、測試計(jì)劃、測試設計(​§jì)、測試環境搭建、測試執行(xíng)、測試報γδ€(bào)告這(zhè)幾大(dà)部分(fēn)。

 

按照(zhào)測試類型，可(kě)以分(fēn)為(wèi)功能(né$γng)測試、性能(néng)測試、負載測試、÷×Ω壓力測試、冒煙(yān)測試、安全性測試、兼容性測試等。

 

按照(zhào)是(shì)否執行(xíng)程序，可(kě)以分(fēn)為(wèi)靜(jìng)态測試和(hé)動态測"¶試。

 

按照(zhào)對(duì)軟件(jià↕ n)內(nèi)部信息的(de)了(le)解程度，可(kě)以分(fēn)為(wèi)黑(h₩π‌ēi)盒測試、白(bái)盒測試、灰盒測試。

 

按照(zhào)測試層次呢(ne)，又(yòu)可(kě)以分(fēn)為(wèi)單元測試、™"Ω軟件(jiàn)集成測試、軟件(jiàn)需求₩>€ 測試、系統集成測試、系統測試、驗收測試這(zhè)幾大(dà)部分(fēn'σ∞)。

 

從(cóng)另外(wài)一(yī)個(gè)工(gōng)程應用(yòng)的(de)思路(lù)，我們将測試層次還(hái)能(néng)做(zuò)一(yī)個∏>★(gè)整合，單元測試、集成測試都(dōu)屬于“設計(jì)”層（Technical），軟件(jiàn)需求測試和(hé)系統測試∑¶‌屬于“功能(néng)”層（Functional），而驗收測試屬于“方案”或“問(wèn)題解決”層（Solution）。

 

五花(huā)八門(mén)，不(bù)一(yī)Ω®而足。

粗略來(lái)看(kàn)，從(cóng)測試層次的(de)角度，基本也(yě)能↑↔<(néng)夠覆蓋到(dào)其他(tā)分(fēn)類的(de)內(nèi)容。為(w✘♥∑'èi)了(le)理(lǐ)解起來(lái)比較清晰，而且業(yè)內(nèi)<'§"講得(de)非常多(duō)的(de)V模型或ASPICE也(yě)是(shì)按照(zhàoγ≠¶☆)層次來(lái)劃分(fēn)的(de)，所以我們著(zhe)重從(cóng)測試層次逐一(↑♦'yī)鋪展開(kāi)。

3.1 單元測試

 

單元測試是(shì)軟件(jiàn)驗證的(de)最低→σ∏‍(dī)級别，是(shì)對(duì)軟件(j‍σiàn)的(de)最小(xiǎo)可(kě)測單元進行(xíng)驗證的(de)β→工(gōng)作(zuò)。

但(dàn)如(rú)何定義單元一(yī)直是(shì)争論的(de₹'™™)焦點，通(tōng)常我們會(huì)說(sh≠∏∞uō)是(shì)一(yī)個(gè)函數(shù)，可(kě)有(yǒu)的(d₹σe)函數(shù)代碼段很(hěn)短(duǎn)，這(zhè)樣去(qù)做(zuφ<ò)又(yòu)會(huì)顯得(de)很(hěn)浪費(fèi)，經常也(yě)會(h¥ ≈Ωuì)将單元異化(huà)為(wèi)具有(yǒu)獨立功能(néng)的(de)組件(jiàn×★π♣)。

 

總之，單元是(shì)一(yī)個(gè)人(rén)為(wèi)定義的(de)最小( αxiǎo)測試點，去(qù)針對(duì)軟件(jiàn)的(de)詳細設計₽©€™(jì)（即代碼）來(lái)進行(xíng)的(de∑λ)，一(yī)般是(shì)開(kāi)發自(zì)己去(qù)完成的(de)。

 

測試方法會(huì)有(yǒu)靜(jìn£↕λg)态代碼分(fēn)析，如(rú)熟知(zhī)的(de)基于MISRA →✘C規範的(de)靜(jìng)态代碼掃描，或者關注代₩α碼覆蓋率的(de)測試，如(rú)語句覆蓋率、分(fēn)支覆蓋率→¥₽≥、MC/DC覆蓋度等。

 

在這(zhè)個(gè)階段之後，軟件(jiφ→βàn)組件(jiàn)可(kě)以被集成了(le)。

 

3.2 軟件(jiàn)及系統集成測試

 

軟件(jiàn)集成測試的(de)目的(de)是(shì☆♦)為(wèi)集成的(de)軟件(jiàn)組件(jiàn)與軟件(jiàn)架構的(de←≤≤)一(yī)緻性提供證據，包括組件(jiàn)之間∏σ(jiān)的(de)接口。

 

測試的(de)內(nèi)容可(kě)能✔×←(néng)包括通(tōng)過接口的(de)數(shù)據是(shì)否丢失、 ∏組件(jiàn)組合後能(néng)否達到(dào)預期父功能(néng)以及一(yī)✔≤'"個(gè)組件(jiàn)是(shì)否會(huì)對(duì)其他(tā)組件(jiàn)造成影↓₽☆&(yǐng)響等。

 

此外(wài)，非功能(néng)的(de)測試會(huì)涉及到(dào)<φCPU負載率、內(nèi)存占有(yǒu)率等資源消耗的(de)內(nèi)容。

 

在測試思路(lù)的(de)選擇上(shàng) •，一(yī)般有(yǒu)兩類：增量式和€γδ(hé)非增量式，主要(yào)差别在于是(shì)一(yī)次性集成完畢後一(yī)次性測試，還(h☆¥ái)是(shì)邊集成邊測試。前者容易造成大(÷©±×dà)量缺陷報(bào)出而難以定位原因的(de)☆₩問(wèn)題，而且修改過程也(yě)會(huì)不(bù)斷引入新≥↕​™問(wèn)題，造成混亂。

 

系統集成測試呢(ne)，是(shì)沿著(zhe)HW₽λγα/SW的(de)接口進行(xíng)的(de)，通(tōng)過物(γ §wù)理(lǐ)引腳（物(wù)理(lǐ)層）和(hé)邏ε'™輯協議(yì)（邏輯層）連接的(de)HW/SW接口構成系統內(nèi)Ω☆₩×部接口。

因此，系統集成的(de)先決條件(jiàΩ↕n)是(shì)已經集成的(de)軟件(jiàn)↑≠和(hé)硬件(jiàn)。從(cóng)技(jì)術(shù)上(shàn♠✘>☆g)講，系統集成隻需根據BOM在硬件(jiàn)上(shànε←g)刷新軟件(jiàn)即可(kě)。這(zhè)和(hé)軟件(jiàn)集成過程中功能(nén♠&→εg)集成是(shì)逐步進行(xíng)的(de)有(yǒu)些(xiē)不(bù₩™≥‍)同。

 

盡管理(lǐ)論上(shàng)，軟件(jiàn)集成測試是(shì)側重于軟件(jià₩↔✔&n)模塊之間(jiān)的(de)接口的(de)，系統集®ε≤成測試是(shì)著(zhe)眼于軟硬件(jiàn)之間(jiān)的(✔>  de)接口的(de)，但(dàn)是(shì)系統不(bù)會(huì)單€±獨懸浮于軟件(jiàn)和(hé)硬件(jiàn)之上(shàng)，硬件(jià&≈n)需要(yào)軟件(jiàn)驅動，軟件×↕≈♠(jiàn)也(yě)需要(yào)運行(xíng)在硬件(≠©jiàn)上(shàng)，所以系統集成測試的(de)用↕​ε(yòng)例往往來(lái)源于軟件(jiàn)或硬件→¶≈(jiàn)各自(zì)的(de)測試，有(φαyǒu)時(shí)也(yě)會(huì)來(lá♣ €<i)源于系統測試。

 

此外(wài)，還(hái)可(kě)以提的(de)一(yī)π<點是(shì)，系統可(kě)以分(fēn)幾個(gè)層級的(de)，比如(rú)，EC←φ¶÷U能(néng)作(zuò)為(wèi)一(yī)級δ↕≈$系統，ECU加傳感部件(jiàn)能(néng)作(zuòΩ™)為(wèi)二級系統，ECU加傳感部件(₽&§jiàn)再加執行(xíng)部件(jiàn)能(néng)作(zuò)為(wèi)∑♥¶三級系統，三級系統集成于整車(chē)環境裡(lǐ)還(hái)能(néng)被定義<δ™為(wèi)四級系統。

宏觀來(lái)講，系統集成測試需要(yào)考慮到(dào)這(z×✔&€hè)所有(yǒu)的(de)系統及對(duì)應接口，隻不Ω"♣(bù)過越往上(shàng)走，就(jiù)越不(bù)是(shì)↓✔‌單一(yī)的(de)軟件(jiàn)範疇了(le≠✘ελ)。

 

3.3 軟件(jiàn)及系統需求測試

 

軟件(jiàn)需求測試，顧名思義，就(jiù)是(shì)為(wèi)在芯片上(shànαγδ♦g)運行(xíng)的(de)集成軟件(jiàn)符合軟件(jiàn)需φ∏求提供證據，證明(míng)軟件(jiàn)功能(néng)滿足需求。

 

系統需求測試呢(ne)，習(xí)慣被簡稱為(•π§'wèi)系統測試，也(yě)是(shì)類似，是(shì)确保測試集成系統，以提供符合™€‌×系統需求的(de)證據，并确保系統已準備好(hǎo)交付‍ 。

 

與軟件(jiàn)需求測試的(de)差别，主要(yào)是(shì)系統需求測試要(yào↓♣×)在集成軟件(jiàn)、标定、硬件(jiàn)、外(wài™‌♥♠)設設備、數(shù)據乃至人(rén)員(yuán)的(de)‌β σ系統下(xià)進行(xíng)的(de)，這(zhè)也(yě)是(shì)最常見♣↓π$(jiàn)的(de)最終交付前的(de)測試。

 

測試內(nèi)容上(shàng)，主要(yào)是(shì)針對(du ×↔αì)需求、風(fēng)險、特定用(yòng)例或其他(t•βā)高(gāo)層級系統行(xíng)為(wèi)的¶​(de)描述進行(xíng)的(de)功能(néng)測試與非功能(néng)測試（如(rú)性能(néng)、負載、壓力、可(kě)靠性、魯棒性、恢複性、安全性、兼容性等各λσ類測試）。

 

這(zhè)個(gè)層次的(de)測試也(yě)都(dōu)是(shβ®​≤ì)黑(hēi)盒測試，不(bù)需要(yào)了(le)解內(nèi)<>>₽部實現(xiàn)細節，隻需關注輸入與輸出↑↓↔→。

 

3.4 驗收測試

 

驗收測試，實際上(shàng)已經脫離(lí)了(le)嚴格意義的(deΩ↔≈)工(gōng)程開(kāi)發的(de)範疇，在ASPICE裡(lǐ)也(yě)沒有(yǒ→<u)明(míng)确定義。

 

但(dàn)是(shì)，現(xiàn)在行(xínα≥g)業(yè)內(nèi)越來(lái)越多(duō)地(d λ≠ì)思考用(yòng)戶導向和(hé)用(yòn•☆™¥g)戶思維，所以把驗收測試單獨拿(ná)了(le)進¥¶來(lái)。

 

我傾向于把驗收測試定義為(wèi)非專業(yè)的(de)客戶評判，比如(rú)汽車(chē)行(xíng)業(yè)領導或特定人(rén)員(yuán)的(de  ←)試駕，就(jiù)屬于比較典型的(deβ₩<∞)驗收測試，它是(shì)更高(gāo)層級的(de☆☆™€)、更貼近(jìn)實際使用(yòng)的(de)一φ↕(yī)種确認，他(tā)們可(kě)能(néng)不(bù)懂(d€♠≥¶ǒng)軟件(jiàn)，不(bù)懂(dǒng)汽車(chē)，隻是(shì‍Ω♠ε)從(cóng)自(zì)己的(de)需要(yào)上(shàng)來(lái)‍‌給出判斷。

 

還(hái)有(yǒu)個(gè)例子(zǐ)，你εγ(nǐ)買新房(fáng)交房(fáng)時(shí)或者毛坯房(fáng)裝α‌±修後，業(yè)主要(yào)去(qù)驗房(fáng)&♣，就(jiù)是(shì)典型的(de)驗收測試，他(tā)們顯然不Ω₽∞(bù)那(nà)麽懂(dǒng)裝修、懂(dǒng)材料、懂(dǒng)建築資質、懂(dǒn"Ωg)行(xíng)業(yè)标準，但(d™•→±àn)他(tā)們會(huì)從(cóng)使用↓φ ₹(yòng)上(shàng)、美(měi)觀上(shàng)、感覺上(shàng)去(qù)☆δ α評判。

 

以往的(de)汽車(chē)行(xíng)業(yè)基本不(bù)太會(huì)關γ​★注終端消費(fèi)者的(de)切身(shēn)體(tǐ)驗，大(σ↕dà)家(jiā)沒那(nà)麽多(duō)可(kě)選的(de)，造什(shénλε$)麽買什(shén)麽。現(xiàn)在及往後←≠♦​的(de)時(shí)間(jiān)，終端消費→​ε(fèi)者會(huì)介入得(de)越來(lái)越多(duō)，以新勢Ω♠↔力為(wèi)領頭的(de)各大(dà)車(chē)企也("πyě)會(huì)不(bù)遺餘力地(dì)關注§✔​到(dào)他(tā)們的(de)“驗收”。

4

測試報(bào)告

 

測試報(bào)告及相(xiàng)應文(wén)檔定義的(de)主要(yào)的(de)焦點×→∑在于測試基礎（需求或設計(jì)）和(hé)所有(yǒu)測試級别上(shà§δng)相(xiàng)應的(de)測試用(yòng)例及結果之間(jiān)的(d™®ε÷e)可(kě)跟蹤性。

理(lǐ)論上(shàng)或者說(shuō)做(zuò)得€✘&±(de)比較好(hǎo)的(de)，這(zhè)些♥•≈γ(xiē)測試相(xiàng)關文(wén)檔都(dōu)要(yào)通(tōng)Ω<過配置管理(lǐ)管理(lǐ)起來(lái)。

 

測試執行(xíng)後，得(de)到(dào)的(de)結果和(hé)評估結果被輸$♣& 入到(dào)不(bù)同格式的(de)報(bào)告中。其中的(de)評估必須要(yào)∞≠©進行(xíng)，以避免不(bù)适當的(de)測試用(yòng)例或測試環境引Ω↕起的(de)“假陽性”，就(jiù)像最近(jìn)持續做(z‍☆÷™uò)的(de)核酸檢測，要(yào)審核的(de)。

 

測試失敗的(de)用(yòng)例要(yào)建立相(xiàng)應的(de)缺陷₩®‌記錄，以确保可(kě)追溯性。如(rú)果一(yī)個(gè)缺Ω♣¥陷在專家(jiā)評審後可(kě)以被接受，那(nà)麽它也(yě)應該在測試↑¶文(wén)檔中被清楚地(dì)注釋。

5

測試彙總

 

這(zhè)一(yī)部分(fēn)就(jiù)到(dào)了(leα↓‌¶)我們這(zhè)條“脈絡”的(de)結尾，實際項目中很(hěn)多(duō)¥‍都(dōu)沒有(yǒu)這(zhè)部分(fēn)，各類報(bào)告都$¥(dōu)是(shì)散落各處的(de)、千奇百怪模←$→闆的(de)、由各人(rén)負責的(de)報(®♦→bào)告。

 

為(wèi)了(le)”客戶”滿意，我想這(zhè)個(gè)> ∞₩工(gōng)作(zuò)包最好(hǎo)是(shì)有(yǒu)。

一(yī)份整體(tǐ)測試狀态的(de)彙總可(kě)以比較清晰地→≥'(dì)讓內(nèi)外(wài)部都(dōu)知(zhī)÷ 道(dào)當前的(de)或曆史的(de)‍Ω軟件(jiàn)質量狀态。

 

當然，做(zuò)起來(lái)會(huì)有(yǒu)些(xiē)障礙，特别是(shì)∑"系統複雜(zá)、分(fēn)工(gōng)細的(de₩₹✘©)領域，及時(shí)且準确維護一(yī)張不(bù)斷更新的(de)λΩ&™大(dà)表是(shì)需要(yào)一(yī)番心力的(de)，後續我們可(kě​σ)以探討(tǎo)下(xià)是(shì)否有(yǒu)改善思路(lù)。

 

文(wén)章(zhāng)有(yǒu)♥₹↔點長(cháng)，但(dàn)還(hái)是(shì)隻能α€(néng)在“皮毛”和(hé)“脈絡”上(shàng)'♠聊一(yī)下(xià)，畢竟測試是(shì)一(yī)門(mén)很(hěn)大(dà)的(de≈§★)學問(wèn)。

最後呢(ne)，嘗試總結一(yī)下(xià)這(zh×∞₹×è)條“脈絡”。

汽車(chē)軟件(jiàn)測試是(shì)一(yī∑®← )項以尋找問(wèn)題為(wèi)主要(yào)目标，基于各種組織策略、><測試原則和(hé)業(yè)務限制(zhì)‍>€•，而進行(xíng)多(duō)層次驗證并提供證據的(de)管理(lǐ)和(hé)工↕β(gōng)程實踐工(gōng)作(zuò)。

轉自(zì)水(shuǐ)輕言