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