高效的測試確?？筛櫺院万?yàn)證要求(第1部分)

集成汽車電子硬件和軟件測試的需求，可以是開發(fā)更為流暢，成本更為低廉。對要求可跟蹤性和驗(yàn)證的需要像一個(gè)契約要求給汽車電子供應(yīng)商施加著影響。隨著頻率的提高，廠商逐漸意識到以要求為基礎(chǔ)的測試通常是軟件開發(fā)工程成功的重要要素。

作為一種可交付使用的合同，或更一般地說，作為一種勞動產(chǎn)品，要求可跟蹤性的任務(wù)生成了一個(gè)測試驗(yàn)證矩陣(TVM)，TVM是一個(gè)很難制成的產(chǎn)品，這個(gè)過程消耗著從其他生產(chǎn)率更高的活動中轉(zhuǎn)移過來的有價(jià)值的資源。

在人們試圖通過項(xiàng)目的測試、集成和展開階段去維護(hù)TVM之時(shí)，TVM的真實(shí)重要性才會顯現(xiàn)出來。當(dāng)缺陷出現(xiàn)時(shí)，TVM的固有不足和它代表的人工處理就會以缺陷的形式暴露出來。確切的說，大部份這類缺點(diǎn)都?xì)w因于對要求管理，包括要求確認(rèn)、分配和正確的實(shí)現(xiàn)。事實(shí)上，記錄顯示高達(dá)70% 的此類缺陷被歸類為與要求管理相關(guān)!

下個(gè)挑戰(zhàn)是生成一個(gè)專門面向開發(fā)和測試團(tuán)隊(duì)的、工作在現(xiàn)有工具和程序環(huán)境中的要求可跟蹤性方案。目前，大多數(shù)的客戶LDRA擁有要求數(shù)據(jù)庫或扁平的文檔處理能力，在此，他們定義并且維護(hù)系統(tǒng)或高級別的需求。

延遲映射

一些客戶把這些高級別的要求映射到頂層的設(shè)計(jì)；甚至較少把這些要求映射為實(shí)際建造設(shè)計(jì)和源代碼。大體上，客戶至少要把要求映射到驗(yàn)證這些要求的測試用例。然而，當(dāng)用戶等待測試以執(zhí)行要求可跟蹤性之前，錯(cuò)誤映射出現(xiàn)的可能性非常大，尤其在系統(tǒng)測試中。

出現(xiàn)這么晚的要求映射的原因在于，項(xiàng)目經(jīng)理的辦公室和開發(fā)工程師工作站的測試環(huán)境或在實(shí)驗(yàn)室目標(biāo)系統(tǒng)上的要求數(shù)據(jù)庫對操作約束施加了影響?；蛘咴谶h(yuǎn)端，轉(zhuǎn)包商正在執(zhí)行測試。在最小程度上，這些操作約束規(guī)定，要在要求數(shù)據(jù)庫和該測試環(huán)境之間進(jìn)行某種級別的集成，以引入一種自動的解決方案。。

一種更有效的方法是至少把要求映射到(或詳細(xì)的)實(shí)際建造設(shè)計(jì)和嵌入式源代碼。映射已構(gòu)建的系統(tǒng)是測試資格或測試預(yù)備過程的組成部分，測試預(yù)備程序決定要求和代碼之間的合適關(guān)系；這種檢查得到的一個(gè)推論就是，要消除源代碼中的廢棄代碼(用不上的代碼)。此外，可能引起爭議的是，行不通的代碼或在任何測試數(shù)據(jù)組合之下不能運(yùn)行的代碼，也應(yīng)該在測試準(zhǔn)備就緒之前校正或清除。

要求可跟蹤性的最佳解決方法包括：第一步，把系統(tǒng)要求映射為最高層設(shè)計(jì)，在使用一個(gè)設(shè)計(jì)建模工具時(shí)適當(dāng)?shù)貓?zhí)行(該選項(xiàng)在 LDRA 白皮書“LDRA Tool Suite/ Telelogic I-logix Rhapsody Integration ”)。

原型設(shè)計(jì)

現(xiàn)有的低級和引伸要求迫使對實(shí)際建造設(shè)計(jì)做進(jìn)一步的要求可跟蹤性，開發(fā)團(tuán)隊(duì)要在詳細(xì)制定系統(tǒng)要求(或原型設(shè)計(jì))的過程中定義這些要求，并定義可工作和可測試的系統(tǒng)構(gòu)造。該產(chǎn)品進(jìn)化的模式在嵌入式軟件任務(wù)的開發(fā)過程中最為顯著，其中，也必須考慮目標(biāo)約束和硬件需求。

低級要求的流行和上下文環(huán)境對要求可跟蹤性來說是另外一個(gè)重大挑戰(zhàn)。這些要求不考慮系統(tǒng)或客戶需求；它們解決軟件系統(tǒng)“如何”工作的問題，而客戶需求定義的是系統(tǒng)應(yīng)該“做什么”的問題。結(jié)果，低級和引伸要求常常與系統(tǒng)要求脫節(jié)。這就提出了另一個(gè)數(shù)據(jù)管理需求。

低級要求管理、跟蹤和驗(yàn)證的一個(gè)關(guān)鍵方面，就是怎樣把這些要求劃分給開發(fā)工程師和測試工程師。開發(fā)工程師要完全掌握他們將實(shí)現(xiàn)的代碼的接口規(guī)范以及該代碼將要調(diào)用的程序。這些規(guī)范必須明確連接到相關(guān)的高級要求，以便開發(fā)工程師正確地理解實(shí)現(xiàn)的上下文環(huán)境。獲得了合適的信息，開發(fā)工程師就可以針對可測性開展設(shè)計(jì)，并考慮必須在多個(gè)測試級使用的功能。

關(guān)鍵軟件在汽車工業(yè)以及全球其他的商業(yè)和政府部門方面都有許多應(yīng)用，例如安全關(guān)鍵、任務(wù)關(guān)鍵和商業(yè)關(guān)鍵的應(yīng)用。下面列舉了一組常用的此類應(yīng)用程序。

如果人們考慮“消費(fèi)者關(guān)鍵”的應(yīng)用，那么，這些軟件的應(yīng)用領(lǐng)域更寬，包括ATM和游戲機(jī)(特別是花自己錢的時(shí)候)。大多數(shù)這些應(yīng)用都是為工業(yè)和政府組織開發(fā)的，他們定義和出版自己的軟件開發(fā)和測試標(biāo)準(zhǔn)。下列為此類標(biāo)準(zhǔn)的代表：

MISRA: 車載軟件開發(fā)指南，3.6， “測試”

IEEE 1012: 軟件驗(yàn)證和確認(rèn)標(biāo)準(zhǔn)

IEEE 829: 軟件測試文檔編制標(biāo)準(zhǔn)

IEC 61508: 電氣/電子/可編程安全性相關(guān)系統(tǒng)的功能安全性

FDA: 軟件驗(yàn)證的通用原則， 5.2.5， “由軟件開發(fā)工程師進(jìn)行的測試”

EN 50128: 鐵路應(yīng)用， “鐵路控制和保護(hù)系統(tǒng)的軟件”

RTCA DO-178B: 航彈系統(tǒng)和設(shè)備認(rèn)證要求中的軟件考慮， 6.x， “軟件驗(yàn)證過程”

Def Stan 00-55:國防設(shè)備(第2部分)中安全性相關(guān)軟件的要求，第五節(jié)，“測試和集成”

這些標(biāo)準(zhǔn)的共同之處是運(yùn)行以要求為基礎(chǔ)的測試。 在這些標(biāo)準(zhǔn)之中最顯著的是航彈系統(tǒng)標(biāo)準(zhǔn)，DO-178B。這個(gè)標(biāo)準(zhǔn)主要定義了兩個(gè)基于測試的要求活動作為功能測試或黑盒測試(下圖)，以及結(jié)構(gòu)覆蓋或白盒測試。

功能測試需要開發(fā)工程師或測試工程師掌握確定被測代碼行為的軟件要求。更確切的說，開發(fā)工程師(或測試工程師)必須根據(jù)輸出和預(yù)期的結(jié)果來定義輸入和條件，以便制定出測試規(guī)范。該測試規(guī)范可能會以一或多個(gè)測試用例的形式給出，以便完全遍歷測試規(guī)范的要求。

結(jié)構(gòu)覆蓋或白盒測試有助于驗(yàn)證黑盒測試的完整性。結(jié)構(gòu)測試也有助于確定實(shí)際建造設(shè)計(jì)的正確性；例如，如果所必的軟件功能已經(jīng)全部運(yùn)行過，但仍然有未覆蓋的代碼，那么，這段多余的代碼的作用就是問題所在，代碼運(yùn)行時(shí)間的可預(yù)測性也一樣。

本文第2部分將討論能力成熟度模型(CMMI)標(biāo)準(zhǔn)在改善軟件開發(fā)過程中的作用，從中引出把測試信息映射為要求的工具。

Bill St. Clair

LDRA

bstclair@ldra-usa.com