保證測試有效性的方法

除了提供嵌入式領(lǐng)域最好的測試工具之一外，我們還為汽車行業(yè)的客戶測試軟件產(chǎn)品(包括駕駛輔助功能、驅(qū)動(dòng)組件、充電和電池系統(tǒng)的控制軟件)。

隨著時(shí)間的推移，我們也遇到了測試過程中的錯(cuò)誤。為了避免過程錯(cuò)誤，我們制定了各種策略和方法。始終以快速為客戶的開發(fā)模型提供高質(zhì)量的報(bào)告為目標(biāo)。

下面，我們將詳細(xì)解釋其中一種方法。它是由我們的測試工程師開發(fā)的，并在日常實(shí)踐中使用。

此方法的目的是確保測試用例在任何時(shí)候都實(shí)際測試鏈接到它的需求。

這里有一個(gè)簡單的例子來說明為什么這件事如此重要。

在用于控制車輛外燈的軟件中，當(dāng)燈開關(guān)處于on位置時(shí)，外燈應(yīng)始終打開。在最壞的情況下，這個(gè)需求只與從未包含條件“燈開關(guān)處于ON位置”的測試用例相關(guān)聯(lián)。如果這些測試用例成功地測試了另一個(gè)方面(例如，燈開關(guān)關(guān)閉，外部燈保持關(guān)閉)，那么可以認(rèn)為鏈接的需求已經(jīng)被充分測試了。

錯(cuò)誤的鏈接會(huì)以不同的方式出現(xiàn):

1. 測試人員在測試用例和需求之間創(chuàng)建了一個(gè)錯(cuò)誤的鏈接。
2. 隨著時(shí)間的推移，由于測試項(xiàng)的更改，現(xiàn)有鏈接將失去其意義

有一個(gè)簡單且可快速實(shí)現(xiàn)的解決方案可以解決這個(gè)問題。

在我們的方法中，如果每個(gè)測試用例沒有正確地測試鏈接的需求，那么它將被報(bào)告為“失敗”。由于錯(cuò)誤鏈接導(dǎo)致的失敗在報(bào)告中有詳細(xì)說明。我們的方法本質(zhì)上是基于分別定義測試數(shù)據(jù)和期望值的可能性。

在TPT中，測試項(xiàng)的預(yù)期結(jié)果(在這里我們也說測試預(yù)言)可以在Assesslet的幫助下描述。Assesslets可以同時(shí)用于幾個(gè)測試用例的評(píng)估。

該方法的實(shí)現(xiàn)分為5個(gè)步驟:

1. 將需求導(dǎo)入TPT
2. 根據(jù)單個(gè)需求創(chuàng)建1個(gè)Assesslet
3. 創(chuàng)建檢查腳本
4. 創(chuàng)建測試用例
5. 測試用例與導(dǎo)入需求的鏈接.

步驟1:將需求導(dǎo)入到TPT

導(dǎo)入可以通過幾種方式完成。對(duì)于這種方法，只有需求在TPT中可用才是有意義的。

步驟2:為每個(gè)需求創(chuàng)建一個(gè)Assesslet

一個(gè)Assesslet的目的是在定義的條件下指定測試對(duì)象的預(yù)期行為。這個(gè)單一數(shù)據(jù)源的定義可以用于多個(gè)測試用例。

如何做到這一點(diǎn)?

在Assesslet文件夾中為每個(gè)需求創(chuàng)建一個(gè)新的腳本Assesslet，相應(yīng)地命名并實(shí)現(xiàn)它。

一個(gè)Assesslet的實(shí)現(xiàn)包含以下元素:

1. 定義條件或情況區(qū)別(通常來自需求)
2. 定義每個(gè)條件的期望值(有些簡單，有些復(fù)雜)
3. 添加一個(gè)注釋，說明哪個(gè)期望值涵蓋了哪個(gè)需求

對(duì)于上面的燈控制示例，這里是一個(gè)評(píng)估Assesslet的參考實(shí)現(xiàn)，它使用ID 2018檢查需求“如果燈開關(guān)是打開的，那么大燈應(yīng)該立即打開”:

Assesslet檢查需求2018：條件“當(dāng)燈開關(guān)位于位置1(3號(hào)線)”。我們的期望值記錄在第4行:TPT.CheckAlways()檢查大燈是否== true。使用REQUIREMENTS.checked()，附加到需求2018的屬性將被結(jié)果覆蓋(從第4行開始)。

其他請(qǐng)求的過程是相同的。

步驟3:創(chuàng)建檢查腳本

然后使用另一個(gè)Assesslet腳本檢查鏈接到測試用例的所有需求是否具有定義好的屬性。對(duì)于Assesslet，這是在第5行中使用REQUIREMENTS.checked()函數(shù)完成的。當(dāng)調(diào)用這個(gè)函數(shù)時(shí)，默認(rèn)值將被更改。

換句話說，對(duì)于每個(gè)測試用例，對(duì)于鏈接到該測試用例的每個(gè)需求，我們檢查默認(rèn)值的屬性。如果存在默認(rèn)值，則要么沒有測試Assesslet，要么是需求的測試Assesslet不正確。

下面是一個(gè)參考實(shí)現(xiàn):

您需要將該腳本移動(dòng)到報(bào)告部分。然后它將在Assesslet之后運(yùn)行以檢查需求。

步驟4:創(chuàng)建測試用例

步驟5:將測試用例與導(dǎo)入的需求鏈接起來

需求與測試之間的鏈接或者測試與需求的鏈接，都可以通過拖拽來完成。選擇一些測試用例并將它們拖到需求上即可。

優(yōu)點(diǎn)是什么?

這個(gè)過程的優(yōu)點(diǎn)是報(bào)告中不正確的鏈接可以立即和容易地看到。在報(bào)告中，每個(gè)錯(cuò)誤鏈接的測試用例都被標(biāo)識(shí)為失敗的測試用例。

因此，該報(bào)告為用戶提供了一個(gè)關(guān)于是否為所有需求創(chuàng)建了相關(guān)測試用例的快速概述。與此同時(shí)，這提高了生產(chǎn)率，因?yàn)榭梢允÷詫?duì)完成度的分析。

在應(yīng)用這種方法時(shí)必須考慮什么?

應(yīng)該檢查Assesslet的正確性和與需求的一致性。只有當(dāng)Assesslet是正確的，它們才有意義。這是測試過程中的實(shí)際工程工作。我們(目前)還不能從你們手中接過這個(gè)任務(wù)。

進(jìn)一步的提示和建議:

在我們的一些項(xiàng)目中，我們沒有將腳本Assesslet直接鏈接到需求。然而，映射是通過命名約定完成的:每個(gè)“需求-測試”腳本Assesslet都有以下結(jié)構(gòu)“Ass_”& 。雙向可追溯性的要求(例如來自ASPICE)在原則上得到了滿足，因?yàn)榕鋵?duì)可以在任何時(shí)候確定。

總結(jié)

我們確保測試重要性的方法符合ASPICE和ISO26262的要求。

在它的應(yīng)用中，它需要使用測試自動(dòng)化的基本功能，例如用于刺激的測試數(shù)據(jù)的分離和測試對(duì)象預(yù)期行為的單獨(dú)定義。幾年來，我們一直在安全關(guān)鍵型汽車項(xiàng)目中成功地使用這種方法。

我們的工程師被直觀的程序所說服，不再想沒有它，因?yàn)橘M(fèi)時(shí)的手工檢查鏈接正確性的工作可以省略。

編寫腳本和檢查Assesslets及需求的正確性的工作是可管理的，并且顯著低于諸如審查和演練之類的替代指標(biāo)。