日本无码免费高清在线|成人日本在线观看高清|A级片免费视频操逼欧美|全裸美女搞黄色大片网站|免费成人a片视频|久久无码福利成人激情久久|国产视频一二国产在线v|av女主播在线观看|五月激情影音先锋|亚洲一区天堂av

  • 手機站
  • 小程序

    汽車測試網(wǎng)

  • 公眾號

    • 汽車測試網(wǎng)

    • 在線課堂

    • 電車測試

功能測試用例 VS. 結(jié)構(gòu)測試用例

2020-01-20 23:48:30·  來源：BTC貝騰軟件  
　
當談到汽車行業(yè)的單元測試時，大多數(shù)人首先想到的測試場景就是功能測試。功能測試即是獲取屬于某個單元的所有需求并編寫測試用例來驗證單元是否按預期功能工作。
當談到汽車行業(yè)的單元測試時，大多數(shù)人首先想到的測試場景就是功能測試。功能測試即是獲取屬于某個單元的所有需求并編寫測試用例來驗證單元是否按預期功能工作。
 
功能測試用例
功能測試用例來源于需求，一個測試用例代表了被測系統(tǒng)一次“良好的運行”，覆蓋了單元功能的某一方面。為了驗證預期行為，測試人員通過定義特定的輸入來激勵被測系統(tǒng)，然后比較預期結(jié)果和模型或代碼的仿真實際結(jié)果是否一致。由此，測試用例是將需求文本轉(zhuǎn)換為可用于仿真的數(shù)據(jù)流。 
 
由于其特性，測試用例可以寫得很長來涵蓋特定的行為，并且需求通常只是描述相關(guān)的輸出信號以及中間觀測信號的預期行為。此外，即使需求描述了輸出信號的預期行為，它也可能只是提供整個測試用例中的即時信息。而不相關(guān)的信號通常被視為“Don’t care”，并且也沒有定義其即時信息。
 
一條需求關(guān)聯(lián)的所有測試用例一旦都被成功地執(zhí)行了，這條需求就可認為被測試到了。盡管現(xiàn)在市場上有很多新的測試技術(shù)，但是功能測試是驗證被測系統(tǒng)功能行為的標準測試方法。
 
結(jié)構(gòu)測試用例
 
現(xiàn)在有一些工具可以自動生成測試用例，主要可以分為兩類，一是隨機測試用例生成，其中測試用例是通過隨機選擇輸入數(shù)據(jù)來生成的，然后再檢查達到的覆蓋率。這種方法的優(yōu)點是能快速地生成測試用例，但是生成的測試用例是不完整的，并且測試用例的長度可能是非常長，很難進行調(diào)試?；旧纤邢嚓P(guān)測試工具都提供了這種方法。另一類是基于Model-Checking的測試用例生成。這種智能方法生成的測試用例是完整的，而且盡可能生成最短的測試用例去覆蓋某個覆蓋目標，甚至可以證明某個覆蓋目標永遠無法達到。所以它比隨機測試用例生成花費時間長一些。目前只有很少的工具能提供這種高級智能方法。
 
那么您可能會問，這會取代手工創(chuàng)建測試用例的過程嗎？
粗略的答案是：不會！
完整的答案是：視情況而定！
如果有機器可讀的需求即形式化需求，那么Model-Checking技術(shù)就能生成功能測試用例。具體信息請查看BTC EmbeddedSpecifier
假設(shè)我們現(xiàn)在沒有機器可讀的形式化需求，那些自動生成的結(jié)構(gòu)測試用例如果不是來替換功能測試，那么它們的目的是什么呢？
 
什么是結(jié)構(gòu)測試用例？
對于功能測試，需求是測試用例的信息來源，即便對于形式化需求也是如此，這點與自動生成的結(jié)構(gòu)測試用例類似，但信息來源卻不同。
這些工具不考慮需求，而是將被測試系統(tǒng)的結(jié)構(gòu)屬性作為測試用例生成的來源。自動生成的測試用例可以考慮許多可能的結(jié)構(gòu)特性?；旧?，它們都是關(guān)于模型或代碼覆蓋率的。最常見的覆蓋目標是語句、分支或決策、條件和修改的決策/條件覆蓋(MC/DC)，其中ISO26262中在軟件單元層級提出的結(jié)構(gòu)覆蓋目標如下圖所示
還有很多類似于函數(shù)覆蓋、等價類或單獨指定的覆蓋目標，如下圖所示為ISO26262中在軟件架構(gòu)層級提出的結(jié)構(gòu)覆蓋目標
為了避免誤解，這類測試用例就被稱為結(jié)構(gòu)測試用例，當然它們的特性也有所不同。它們不是驗證需求，而是通過改變輸入和標定參數(shù)來“應(yīng)激”被測系統(tǒng)。通常，這些測試用例很短，它們考慮了所有步中的所有信號，沒有“Don’t care”的信號。
但是，如果這些測試用例來自于被測系統(tǒng)，然后又在被測系統(tǒng)上執(zhí)行，這難道不是一個自我實現(xiàn)的預言嗎?
 
激勵向量生成
 
推導結(jié)構(gòu)測試用例可以分為兩步。首先，（我們稱之為）引擎生成激勵向量。激勵向量只包含輸入數(shù)據(jù)，即每個輸入信號和每個標定參數(shù)的數(shù)據(jù)，不包含任何關(guān)于輸出和中間觀測量的信息。所以這些激勵向量只描述了如何達到一定的覆蓋目標。
 
因此，通常激勵向量是來自模型還是來自代碼并不重要。如果我們深入研究這個話題，那么將代碼作為源頭有幾個很好的理由，但是要注意的是如果使用一般的方法，由模型還是由代碼推導出激勵向量并沒有什么區(qū)別。
 
這些生成的激勵向量的首要好處就是，它們可能已經(jīng)指出了模型或代碼中的一些結(jié)構(gòu)性問題，這些問題與被測系統(tǒng)的魯棒性有關(guān)，比如溢出、除零、值超出范圍或無效值等。
 
背靠背等效性
 
第二步是要從激勵向量派生出結(jié)構(gòu)測試用例。由測試人員決定，應(yīng)該從哪個源實現(xiàn)派生出輸出行為。在基于模型的開發(fā)中，這通常是模型。因此，所有生成的激勵向量都在模型上執(zhí)行，并記錄仿真的輸出。這樣激勵部分和記錄的仿真輸出行為一起構(gòu)成了一個結(jié)構(gòu)測試用例。
結(jié)構(gòu)測試用例的使用場景
  • 模型和代碼或目標代碼之間的背靠背等效性測試
  • 新舊版模型、代碼或目標代碼之間的回歸測試
  • 遷移到新的開發(fā)環(huán)境
  • 新舊處理器之間的比較
現(xiàn)在可以在代碼上再次執(zhí)行這些結(jié)構(gòu)測試用例，以驗證代碼的結(jié)構(gòu)行為是否與模型相同。換句話說，它驗證模型是否正確地轉(zhuǎn)換為代碼。最常見的問題比如精度誤差、數(shù)據(jù)溢出甚至編譯器差異等，這些都可能導致模型和代碼之間的行為不同。因此，ISO 26262強烈推薦進行背靠背測試。
 
由于這種方法依賴于模型或代碼以及所選的覆蓋率目標，所以它不需要來自測試人員的額外輸入或交互。因此，這種測試方法可以完全自動化，并可應(yīng)用于開發(fā)和測試過程的持續(xù)集成環(huán)境中去。
結(jié)構(gòu)測試用例并不是為了…
 
自動生成結(jié)構(gòu)測試用例是一種很方便的方法，但這也引出了一個問題，是否生成的測試用例能隨機地符合一條需求。即使這在理論上是可能的并且有白皮書在理論上討論過這種方法，但幾乎絕對肯定不可能這樣做。
但是讓我們暫時假設(shè)一些生成的結(jié)構(gòu)測試用例符合需求。這意味著測試人員必須手動檢查所有生成的測試用例，并檢查其中一個是否符合需求中的一條。由于模型或代碼仍然可能包含錯誤，因此這種方法可能無法發(fā)現(xiàn)功能上的錯誤。
此外，隨著需求的增加和生成的結(jié)構(gòu)測試用例的增加，該任務(wù)的工作量和復雜性將明顯成倍地增加。一旦完成了這一步，測試人員仍然必須為尚未覆蓋的需求編寫額外的功能測試用例。最后從工作和復雜性的角度來看，這種方法并不適用于實際的測試工作流。
 
總結(jié)
盡管自動生成的結(jié)構(gòu)測試用例和手工編寫的功能測試用例之間有很大的區(qū)別，但是它們是功能測試的有效補充，能發(fā)現(xiàn)模型和代碼之間的結(jié)構(gòu)問題。另外，試圖將自動生成的結(jié)構(gòu)測試用例映射到需求并不是一個合適的方法。
 
功能測試用例檢查功能設(shè)計是否正確且與預期是否一致。而結(jié)構(gòu)測試用例則查看語法并檢查它是否被正確地翻譯成另一種語言。最后，將結(jié)構(gòu)測試用例自動生成應(yīng)用到測試工作流中，可以提高測試的深度和魯棒性。 
分享到：
 
反對 0 舉報 0 收藏 0 評論 0
滬ICP備11026917號-25