內容提要：此文為該連載系列的“第二”篇章，在之前的“篇章（一）”中已經闡述了汽車軟件工程的特點，以及使用混合方法設計的分階段EBSE測試過程，并提出問題。接下來，我們將具體分析EBSE步驟一：關于優勢和挑戰的案例分析。

EBSE專題連載共分為“五個”篇章。此文為該連載系列的“第二”篇章，在之前的“篇章（一）”中已經闡述了汽車軟件工程的特點，以及使用混合方法設計的分階段EBSE測試過程，并提出問題。接下來，我們將具體分析EBSE步驟一：關于優勢和挑戰的案例分析。

4.EBSE步驟一：關于優勢和挑戰的案例分析

我們進行了一項行業案例研究，以調查汽車軟件測試過程中的優勢和挑戰，并確定改進空間，回答本專題連載（一）的RQ1和RQ2。

4.1.案例分析設計類型

案例是瑞典一家大型汽車組織的開發基地之一。案例組織已通過ISO認證。然而，該組織一直在努力實現其客戶期望的SPICE級別。特別是，不同部門在考核中取得了不同的成績。從這項研究中也可以明顯看出一點，我們發現沒有統一的測試流程，而且并非所有項目都有合適的測試計劃。他們專注于車聯網、物流、電子、機械、仿真建模和系統工程等領域的軟硬產品。

我們報告了一個具有多個分析單元的案例，其中我們重點研究了在一個公司進行多個項目測試的現象。這種類型的案例研究有助于比較案例組織中用于不同項目的測試方法論、工具和方法。

這里的分析單元是所研究公司的不同項目。選擇的方式是讓他們在使用的方法、團隊規模和用于測試的技術等因素上具有最大的差異。關注變化的項目的動機是能夠引發廣泛的挑戰和優勢。此外，這有助于提高普遍性，因為挑戰不會偏向于特定類型的項目。

4.2.分析對象

此次所研究的所有項目都是定制的，因為案例組織是特定客戶的供應商。這里的所有項目都是外部發起的，該組織不銷售任何專有產品/服務。組織內的項目大多是維護項目或現有產品的改進。在這個組織中，一個角色在多個項目中承擔多項職責是很常見的。表1給出了所研究項目的概述。

系統：大多數系統是嵌入式應用程序（P1、P2、P3、P4、P7和P8），即它們涉及軟件和硬件部分，例如控制單元、液壓件等。在P2、P5和P6中開發的Windows應用程序不控制硬件。

團隊規模：我們區分小型項目（團隊少于4人）和大型項目（團隊有4人或更多人）。大多數團隊規模較大，如表1所示。小型團隊不一定擁有結構化的開發和測試流程、角色和職責、測試方法或工具。三個項目（P3、P6和P8）未報告任何測試計劃。模塊數量較多的項目由大型團隊開發，與小型團隊處理的項目相比，這些項目已經過時。也就是說，隨著時間的推移，這些系統已經有了相當大的發展。

開發方法：組織內采用不同的軟件開發方法。然而，基于模型的開發是最突出的（P4、P5、P7和P8），并與瀑布模型概念一起使用。瀑布是指涉及需求、設計、組件開發、集成和測試的順序過程。在一個項目（P2）中采用了使用Scrum的敏捷開發。參與維護的小團隊采用了臨時方法 (P6)。最近有兩個項目引入了一些敏捷實踐來合并迭代開發（P1和P5）。

工具：測試項目中使用各種工具，例如測試用例和數據生成器、測試執行工具、缺陷檢測和管理工具、調試工具、需求跟蹤和配置管理工具以及用于建模和分析電子控制單元（ECU）的工具。除了這些工具之外，當任何其他工具無法滿足項目的特定目的時，在某些項目中會使用定制工具。這些工具通常用于測試執行，使測試環境接近目標環境。小型團隊（例如P3）不依賴測試工具，而是使用電子表格。負責多個模塊的大型團隊使用多種工具來組織和管理測試工件。

測試級別：如表1所示，幾乎所有項目（八分之七）都進行了單元測試，并且在五個項目中使用了集成測試。項目中的單元/基本測試類似于冒煙測試。但是，此上下文中的單元測試沒有明確定義的范圍。研究的項目中有一半使用了測試自動化。然而，不斷增加的測試用例并不總是更新到自動化架構中。從訪談數據可以看出，很多團隊并沒有進行系統集成測試。然而，大多數團隊都認為集成測試可以取代系統測試。如表1所示，其他形式的測試，如回歸和探索性測試，不太常見，但最近在公司內越來越重要。

4.3.數據采集

數據是通過訪談和過程文檔收集的。然而，由于缺乏可用性和數據質量（例如定量數據）不足，未收集其他來源的數據。使用多個數據源（三角測量）背后的動機是限制僅一種解釋的影響，并由此使結論更有力。

4.3.1.受訪者選擇

受訪者的選擇過程使用以下步驟完成：

? 創建了參與測試過程的人員的完整列表，無論他們的角色如何。

? 我們想為每個項目選擇至少2個人，從可用性的角度來看，這是不可能的。特別是，對于小型項目，只選擇了1個人。對于更大的項目，選擇了更多的人。此外，應涵蓋與測試過程相關的不同角色（包括開發人員、經理和指定的測試人員）。然而，參與訪談的最終員工名單是根據進行訪談的時間段的可用性而定的。

? 我們通過電子郵件向受訪者解釋了為什么他們被考慮參加這項研究。郵件還包含研究目的和采訪邀請。

表1：項目概覽（分析單位）

所選角色代表直接參與測試相關活動，或受整個測試過程結果影響的職位（見表 2）。

表2：角色描述

來自三個部門Alpha、Beta和Gamma（出于保密原因，部門名稱已重命名）的項目和直線組織的角色都包含在我們的研究中。還可以看出，有些角色與項目工作相關，有些與部門內的直線職責相關，即他們支持部門內的不同項目。與部門、項目和角色相關的訪談數量如表3所示。

表3：受訪者

在Alpha和Beta部門，有足夠數量的員工可用，但在Gamma，由于該部門人員不足，只有1個人接受了采訪。之所以選擇此人，是因為她被認為是在測試汽車系統方面擁有豐富經驗的專家。

4.3.2.面試設計

訪談包括四個主題；訪談的持續時間定為每次約一小時。所有訪談都以音頻格式錄制，并做了筆記。在所有采訪中都使用了半結構化采訪策略。采訪的主題是：

1. 熱身和經歷：關于受訪者背景、經歷和當前活動的問題。

2. 軟件測試過程概述：與測試對象、測試活動以及為進行測試所需和產生的信息相關的問題。

3. 測試過程中的挑戰和優勢：這個主題抓住了優勢/好的實踐以及挑戰/表現不佳的實踐。受訪者應該說明他們使用了什么樣的實踐，它的價值貢獻是什么，以及它在測試過程中的位置。

4. 測試過程的改進空間：這個主題包括收集有關為什么必須消除挑戰，以及如何改進測試過程的問題。

4.3.3.工藝文件

研究了軟件開發過程文檔、軟件測試描述文檔、軟件測試計劃文檔和測試報告等過程文檔，以深入了解測試活動。此外，研究了與整個開發過程的組織和過程描述相關的文件，以熟悉公司使用的術語。這反過來有助于理解和分析訪談數據。

4.4.數據分析

為了了解汽車測試過程中的挑戰和優勢，我們使用編碼的方法對不同的分析單元進行了深入分析。對5份訪談記錄進行了手動編碼，以創建一組初始代碼。這些代碼分為不同的主要類別，根據我們的研究問題（Level 1）、文獻（Level 2）和開放編碼（Level 3和Level 4）預定義，請參見表4。由此開發了編碼指南。我們對采訪中的轉錄文本采用了開放式編碼，這些采訪不斷演變。例如，如果我們發現一個新的語句不適合已經確定的代碼，我們就會創建一個新的代碼，例如交互和通信。當我們發現另一個屬于現有代碼的語句時，我們將該語句鏈接到該代碼。在對文本進行編碼后，我們查看了每個集群，識別出非常相似的陳述，然后重新制定它們以代表一個單一的挑戰/優勢。完成后，我們審查了集群并為每個集群提供了高級描述。為了驗證編碼指南，案例組織的一名員工對訪談記錄進行了手動編碼，并將編碼結果與研究人員的解釋進行了比較，并進行了必要的修改。編碼指南在整個數據提取階段不斷完善。

4.5.結果

結果包括對測試過程的描述，以及與該過程相關的優勢和挑戰。

4.5.1.測試過程

大多數受訪者（9名受訪者）表示，缺乏可應用于任何項目生命周期的明確測試流程。在所研究的8個項目中，只有3個項目具有明確定義的測試過程。據觀察，每個項目都遵循與圖2所示非常相似的過程，盡管并非所有項目都遵循此過程中概述的所有活動。

一個組織的測試策略描述了需要進行哪種類型的測試，以及如何將它們用于風險最小的開發項目。公司使用的測試策略主要集中在黑盒測試上，只有一小部分測試作為白盒測試執行。組織內有一本測試人員手冊，其中描述了測試過程、方法和工具。但是，這項研究表明大多數團隊都沒有實施/使用它。進行的主要活動是：測試計劃、測試分析和設計、測試搭建、測試執行和報告。其中，測試計劃由5個項目（P1、P2、P4為代表的三個大團隊和P5、P7為代表的兩個小團隊）提前完成。大多數小團隊沒有任何軟件測試計劃，盡管他們有非常靈活的測試策略/方法來進行測試。

下面將更詳細地描述這些步驟：

測試計劃：此活動旨在解決要測試的內容和原因。此活動的進入標準是為發布準備好優先需求，作為測試計劃的輸入。該階段交付的是軟件測試計劃，包含對所需資源的估計和調度、要創建的測試工件，以及所需的技術、工具和測試環境。該階段測試涉及的角色有客戶、項目經理和測試負責人。如果項目沒有可用的測試負責人，則開發人員自己參與測試計劃活動。測試計劃的出口標準是客戶和項目管理對測試計劃的批準。

表4：通過編碼進行分析

測試分析和設計：此測試活動旨在確定如何執行測試（通過定義測試數據、測試用例和被測過程或系統的進度），這記錄在軟件測試描述中。軟件測試描述還定義了在測試執行期間將執行哪些測試（即測試技術）。此階段的其他交付是需求可跟蹤性矩陣、測試用例和用于實現測試用例的測試腳本設計。測試用例是使用所有項目中使用的測試用例管理工具編寫和管理的。進入這個階段的標準是軟件測試計劃得到客戶和項目管理人員的認可。上一階段安排的測試計劃會更新為每個測試活動的所有詳細時間表。此階段涉及的角色是測試負責人或測試協調員，他們負責設計、選擇、確定優先級和審查測試用例。由于測試人員在項目之間分擔責任并且并不總是可以執行測試任務，因此在大多數項目中，開發人員負責為自己的代碼編寫測試用例。項目經理負責測試活動的監督。

測試搭建：在汽車軟件測試中，測試搭建是測試過程中最重要的部分，因為它涉及構建描述目標環境的測試環境。這個級別的結果是擁有硬件和可以將其可視化為實時環境，包括測試腳本和所有其他測試數據。由于案例組織與大多數項目的控制引擎和電子控制單元(ECU)一起工作，建模工具如Simulink和MATLAB被用來可視化目標環境。大部分測試人員或開發人員參與此活動。項目經理負責提供資源，如硬件設備。測試組長監督活動。

測試執行和報告：測試過程的最后階段是執行測試并將結果報告給客戶。為了執行測試，測試負責人或項目經理將選擇合適的人來運行測試腳本。測試完成后，結果將記錄在缺陷管理系統中。此階段的結果是一份軟件測試報告，其中描述了所執行的整個測試及其測試結論。稍后還會對結果進行分析和評估，以發現與之前版本的測試報告相比是否存在任何差異。如果出現嚴重錯誤，將糾正這些錯誤并重復測試。項目經理負責決定測試執行的停止標準。

4.5.2.優勢和經驗

發現測試過程的優勢取決于團隊規模。大多數在小型團隊中被視為優勢的實踐，在大型團隊中并不被視為優勢，反之亦然。也就是說，從訪談中可以明顯看出，優勢隨團隊規模而變化。

在小型敏捷團隊中工作：測試活動很靈活，無需生成大量測試報告。大型團隊僅針對小型版本執行此操作。大型團隊有一個非常結構化和計劃驅動的測試方法。小型團隊專注于持續集成和迭代開發（例如，P2使用具有持續集成和沖刺計劃的Scrum）。敏捷測試實踐使他們更容易為與需求規范兼容的每個迭代計劃測試。這反過來又可以使測試與其他活動（如需求、設計等）正確對齊。與小團隊相比，大團隊在大多數時候更注重重用測試用例，這使得他們更有效率。

圖2：測試過程

溝通：在具有敏捷實踐的項目中可以發現溝通的優勢，例如站立會議、定期的利益相關者協作以及在開放式辦公空間中一起工作。每個活動都涉及一個測試人員，這表明整個開發生命周期中的并行測試工作。除此之外，敏捷方法增強了團隊精神，導致團隊成員之間的高效互動，并形成了跨職能團隊。其他項目使用每周會議和其他電子服務，例如項目內的電子郵件和消息傳遞。

共享角色和責任：小型團隊認為讓一個人來執行測試人員和開發人員的角色是一種優勢，因為這不會延遲等待某人測試軟件的過程，一位開發人員表示：“當我們工作時，由于測試人員與開發人員是同一個人，所以不會延遲報告。因此，如果開發人員/測試人員發現錯誤，他知道錯誤是從哪里引入的，而不是責怪別人，開發人員在編寫代碼時會更加小心”。但是，大型團隊并不認為這是優勢；這些團隊中的大多數都沒有任何專門的測試人員（除了一個擁有專門測試團隊的大型團隊）。

測試技術、工具和環境：在這里，我們對項目的規模進行了不同的觀察。在小團隊中，使用較少的測試工具和方法來避免更多的文檔。與大型團隊相比，這些團隊的項目模塊通常較少。在這種情況下，系統為測試人員/開發人員所熟知（開發和測試由小團隊中的一個人完成），這使得使用最少數量的工具和方法進行測試變得容易。小團隊（例如項目P3、P6）一般先進行冒煙或單元測試，測試系統的基本功能，然后再進行集成測試。一名員工通過以下方式傳達單元/基本測試的用途：“我認為單元測試是一種優勢。有了這個進入細節并確保每個子系統都按預期工作”。這里使用的測試工具是由團隊開發的，以適應項目需求。但是，這些為其特定團隊開發的定制工具不會在團隊之間共享。小型團隊的主要關注點是擁有一個與目標環境具有相同硬件和接口的測試環境。這使得項目中的測試維護變得高效。

推薦的代碼測試工具

與小團隊相反，大團隊使用多種方法和工具進行測試以執行多項活動。在大型團隊中發現的最明顯的優勢之一是基于經驗的測試（例如P1、P2、P4和P8等項目）。由于相同的團隊成員多年來一直致力于同一個項目，他們發現在產品開發和測試中使用他們基于經驗的知識很容易。一個大型團隊中負責質量協調的員工說：“用于測試的指標對我們團隊沒有太大幫助，因為測試更多地是基于我們的經驗，我們用這些經驗來決定需要運行什么類型的測試用例。”另一個可感知的優勢是在項目P1和P2中應用的探索性測試/基于會話的測試管理。一位員工指出“執行基于會話的測試（即探索性測試）的章程，我們發現了更詳細級別的關鍵錯誤”。硬件在環(HIL)也被認為是大型團隊之一的優勢，因為它可以在集成測試期間檢測到大部分缺陷。用于集成和系統級測試的HIL被認為是一種優勢，因為它可以檢測最關鍵的缺陷，例如大型和復雜系統的時序問題和其他實時問題。非正式代碼審查被認為是大型團隊的優勢，盡管它們也被用于小型團隊。非正式的代碼審查避免測試產生偏見，因為它是由負責編碼的人以外的人執行的。

談到工具，測試用例管理工具被認為是大型團隊（例如P4）的優勢，正如一位員工指出的那樣，“我認為測試用例管理是存儲測試用例、選擇應該執行的測試以及測試人員提供反饋的好方法”。其他被認為有用的工具是缺陷管理工具（例如，項目）。大型團隊中的測試環境非常適合測試，因為它描述了實時環境。

4.5.3.挑戰

挑戰分為幾個領域。對于每個挑戰領域，我們還說明了在挑戰領域內提出挑戰的項目數量，以及挑戰領域所關注的過程領域（見表5），并報告了每個領域的一系列相關問題。

表5：挑戰領域概覽

C01：測試的組織及其過程相關問題：組織問題涉及與組織及其測試過程相關的執行不力的實踐，如變更管理、缺乏結構化的測試過程等。組織問題還包括利益相關者對測試的態度（如果測試被給予低優先級）。

C01_1：沒有統一的測試流程：項目在測試方法和工具的使用上各不相同，由于硬件和軟件的功能分散和復雜性不斷發展，找到一個適合所有項目的統一流程被認為是一項挑戰。盡管有測試人員手冊可以幫助實現更統一的流程，但由于團隊沒有意識到這一點，或者人們覺得這不適合他們的項目特征，所以沒有使用它。非結構化和組織性較差的流程適用于小型項目，但不適用于大型項目，因為這會影響質量。正如受訪者所指出的那樣，“感覺缺乏結構化的測試流程，而且總是沒有組織。它對小項目很有效，但對大項目不適用”。

C01_2：測試倉促完成，計劃不周：交付日期沒有延長，因為需要更多的時間，這導致測試受到影響，倉促完成。此外，客戶沒有及時交付用于測試的硬件和確保良好的質量，因此測試無法提前完成；結果是普遍不遵守測試的最后期限。

C01_3：利益相關者對測試的態度：過去的改進工作側重于實施，而不是測試。因此，新的測試方法沒有得到管理層的太多支持，這有時會使團隊開發自己的方法和工具，這需要付出很大的努力。

C01_4：異步測試活動：測試與供應商相關的其他活動不同步；測試工件必須重新結構化，以便與供應商提供的工件同步。這會導致測試方面的返工。

C02：測試的時間和成本限制：時間和成本約束方面的挑戰可能是由于在需求、測試活動或測試過程上花費的時間不足。

C02_1：缺乏規定驗證要求的時間和預算：驗證要求是在測試期間進行驗證的要求（例如，規定必須測試系統的環境條件）。由于沒有編寫驗證要求而節省的時間和金錢導致了流程其他部分的大量返工和時間，特別是測試。

正如一位受訪者所指出的：“將客戶規范重新寫入我們自己的要求中？這在今天是不可能的，因為客戶不會為此付費，而且我們沒有內部預算?！笨偟膩碚f，缺乏驗證要求導致缺乏目標和明確的測試范圍。

C02_2：測試設備按時可用：測試設備不能按時可用且質量不好，導致無法進行單元測試。

C03：與需求相關的問題：測試需求不足、難以理解的高層次需求以及需求波動性是阻礙進行適當測試以實現高質量的挑戰。這些問題通常發生在客戶由于缺乏時間或知識而沒有正確指定需求時，這意味著需求管理不善。

C03_1：缺乏明確的需求：在理解和記錄明確的需求方面投入的精力太少，導致在后期階段（如測試）重新解釋需求的精力太多。正如其中一名員工所指出的：“我認為，我們最好開始在需求管理方面付出更大的努力，避免客戶抱怨誤解/曲解他們指定的需求，以便最終減少問題，并節省重復更改和測試所有內容的時間”。

C03_2：最終確定測試設計和啟動/停止測試的標準尚不明確：根據訪談，一旦需求穩定，將完成測試過程的定義。受訪者將需求波動性與測試的啟動和停止標準聯系起來。需求的波動性要求重新定義整個測試計劃。這在實際測試開始時起到了障礙的作用。在組織使用測試腳本執行測試的情況下，隨著需求的涌入，他們很難定義何時停止腳本編寫和啟動/停止測試。何時停止測試的標準主要與預算和時間有關，而與測試覆蓋率無關。

C03_3：需求可追溯性管理問題：需求和測試之間的可追溯性可以更好，以便在需求變化時輕松確定哪些測試用例需要更新。此外，缺乏可追溯性使定義測試覆蓋范圍變得更加困難。缺乏可追溯性的原因是需求有時過于抽象，無法將它們與具體功能及其測試用例聯系起來。

C04：測試的資源限制：這些挑戰與熟練測試人員的可用性及其知識有關。

C04_1：缺乏專門的測試人員：并非所有項目都有專門的測試員，而是開發人員解釋需求、實現軟件和編寫測試。缺乏獨立的驗證和確認（不同的人編寫軟件并測試軟件）導致測試中存在偏見。

C04_2：測試人員不可用：考慮到系統的復雜性，積累知識成為一名優秀的測試人員需要時間。如果經驗豐富的測試人員在項目之間輪換，很難找到能夠完成手頭任務的人。一位負責測試的受訪者表示：“很難找到有同樣經驗的人，而且由于產品的復雜性，他們需要很長時間來學習和了解產品。因此，在進行測試之前，需要具備相同的知識?！?/span>

C05：與知識管理相關的測試問題：本案例研究中發現的與知識管理相關的問題包括：

C05_1：關于測試的領域、系統知識轉移和知識共享問題：公司使用的新測試技術（探索性測試）需要大量的知識，而這些知識是不可用的，因為測試人員總是在變化，并且所研究公司雇用的新測試人員來，這些知識是不可用的進入項目。盡管需要達到一個項目不依賴于一個人的狀態，但沒有足夠的信息和培訓材料來說明如何進行測試。從采訪中我們還發現，知識轉移的挑戰被放大了，因為除了軟件之外，它還強調控制工程、機電一體化和電氣工程。

C05_2：缺乏基本測試知識：由于測試人員缺乏基本的測試知識，測試的優先級較低。關于這一背景，一位參與生命周期管理活動的受訪者表示，“我認為缺乏關于測試基礎的信息。我們中的一些人不知道什么時候開始測試，什么時候結束測試，這感覺就像是灰色地帶，在任何地方都沒有明確定義”。

C06：測試中的互動、溝通相關問題：與測試中不同利益相關者之間的溝通相關的實踐中的問題。還包括不適當的溝通形式，如缺乏定期的面對面會議，客戶和測試人員之間缺乏溝通。

C06_1：缺乏與客戶就需求進行的定期互動：在項目開始時，客戶互動更頻繁，就測試中的驗證需求而言，客戶互動太少?？蛻舴矫鏇]有合適的人員就測試要求進行溝通。

C06_2：在測試過程中缺乏與項目中其他角色的互動：缺乏與已轉移到另一個項目的先前團隊成員的溝通，即使他們是需要的（例如，為了驗證和修復已識別的錯誤）。一位受訪者通過以下方式敘述了這件事；“我已經為我們的團隊分配了一個人，然后他必須與我們溝通，但有時這個人很難找到那個人，因為他現在在另一個團隊工作”。

C06_3：與客戶的非正式溝通：總體而言，與客戶缺乏面對面和非正式溝通，客戶通過提供模糊的描述進行溝通，但這些描述沒有得到澄清。一位經理補充道：“我認為最重要的是保持關系（與客戶的非正式關系），并要求客戶在你告訴我們你想要什么之前，我們不能開始工作”。

C07：測試技術、工具和環境相關問題：與當前測試技術、環境和工具的使用有關的問題。

C07_1：缺乏自動化導致返工：單元測試和回歸測試的自動化沒有有效完成。一位受訪者指出，“只要沒有適當的自動化，測試就是返工”。由于缺乏工具支持，生成和有效地自動化測試被視為一項挑戰，導致在想要重新運行測試時返工。

C07_2：整個測試活動沒有統一的工具：一位測試負責人指出需要可用于測試的統一工具“我們有很多工具可供測試，但在決定使用哪種工具時存在一些困難，因為所使用的每種工具都有缺點和優點。有時我們被迫開發定制工具，因為我們無法從市場上獲得任何能為我們做一切的工具”。一個在汽車領域進行所有測試活動的工具可以很容易地使用，而不是管理和組織目前使用的大量工具。

C07_3：測試設備維護不當：需要維護多個測試環境，缺乏維護會導致返工，實際測試開始前的交付周期很長。一位受訪者很好地總結道：“我們有幾個測試環境和測試步驟需要維護。它們并不總是需要維護的，需要很長時間才能開始實際的測試”。

C08：質量方面相關問題：與納入測試質量屬性有關的問題，如可靠性、可維護性、正確性、效率、有效性、可測試性、靈活性、可重用性等。涉及質量和其他活動之間的權衡。

C08_1：可靠性問題：系統的可靠性沒有達到所需的程度。由于缺乏測試流程和硬件組件故障，質量很難整合。正如一位受訪者所指出的那樣，“很難達到一個系統的幾個要求標準，例如工作時間更長、資源密集度較低、在不同平臺上工作的能力等”。

C08_2：從項目一開始就沒有很好地規定質量屬性：質量要求沒有很好的規定，導致復雜系統在現有產品的市場上出現質量問題。

C08_3：沒有質量測量/評估：沒有質量措施，但人們認識到它們的必要性，以提高評估測試結果的能力，一名員工說：“盡管我們的客戶很滿意，但質量曲線必須更好。我認為應該記錄質量措施，以便于更好地分析測試結果”。

C09：缺陷檢測問題：與使測試人員無法追蹤缺陷，或缺陷產生的根本原因的實踐相關的問題，也包括與缺陷預防相關的問題。

C09_1：過程中的后期測試使得修復缺陷的成本很高：由于系統的復雜性和后期測試，系統中的缺陷數量隨著系統的發展和規模的增加而增加。由于之前版本中缺少許多缺陷，導致客戶在接下來的版本中報告了大量需要糾正的缺陷，這使得修復缺陷的成本很高。

C09_2：難以跟蹤先前版本中未修復的缺陷：對于復雜零件的開發（即涉及處理時間問題和其他關鍵問題），兩個不同版本之間的系統行為差異需要相同。但這種情況并不總是發生，因為在當前版本中觸發了以前版本中未修復的錯誤。這是因為當這些錯誤在如此龐大的系統中無法追蹤時，它們可能會在下一個版本中變得嚴重。

C10：與文檔相關的問題：與測試文檔相關的執行不力的實踐，如文檔不足、沒有文檔或文檔過多，無法為維護測試過程中的質量提供適當的支持，都是該挑戰領域的主題。

C10_1：關于測試工件的文檔沒有持續更新：受訪者強調，提供的文檔（如測試用例和其他測試工件）不足以進行測試，不能信任；一位受訪者補充道，“測試文件沒有持續更新，所以我們發現它們不可靠”。提到的原因之一是對測試工件進行了一些小的更改，但這些更改并沒有相應地更新測試文檔。未更新文檔導致返工。

C10_2：沒有關于某些特定測試方法和工具的詳細手冊：在這方面的另一個觀察結果是缺乏關于工具和方法如何工作的文件。一位受訪者很好地總結道：“有對工具的支持，但我們總是找不到可以用它們解決問題的人。我想它可以被更好地記錄下來”。然而，據觀察，組織內有一些手冊可以達到這一目的。但對于一些特定的工具（如定制工具）或方法，這是行不通的。當進行測試的人不能理解手冊中的術語或他們不知道這些手冊時，就會出現這個問題。

更多內容，請關注“汽車EBSE測試流程分析（三）：EBSE步驟二，通過系統文獻綜述確定改進”，關注牛喀網，學習更多汽車科技。有興趣的朋友，可以添加牛小喀微信：NewCarRen，加入專家社群參與討論。

文末福利！

軟件靜態和動態代碼測試工具免費試用申請，掃碼添加牛小喀企業微信，回復"軟件測試"

作者：?？W專欄作者
?？W文章，未經授權不得轉載！