chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

軟件單元測試真的有必要嗎?(上)

上海控安 ? 來源:上??匕? ? 作者:上??匕? ? 2023-11-03 14:58 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

作者 |包丹珠上??匕伯a(chǎn)品總監(jiān)

版塊 |鑒源論壇 · 觀模

社群 |添加微信號TICPShanghai”加入“上海控安51fusa安全社區(qū)”

“軟件單元測試真的有必要嗎?”專題將分為上下兩期,深度詳解軟件單元測試的重要意義,分享目前行業(yè)內(nèi)進行的單元測試探索與實踐。本文著重探討單元測試的重要性及其正面臨的困境,并介紹功能安全標準中羅列的單元測試方法。

01

前 言


元宇宙虛擬世界被大家探討得越來越深入。隨著Facebook公司更名為Meta,這場未來之戰(zhàn)已經(jīng)吹響號角。元宇宙是虛擬的一個世界,核心是軟件創(chuàng)造的世界。那么,軟件定義一切對普羅大眾來說將不再是個空想,而是正在抵達的不久的將來。

如果在讀的你對軟件還沒有成熟的認知,對產(chǎn)品體驗始終停留在有形的實體的執(zhí)念上的話,那么你要注意更新自己的認知了,要盡快做好抓住虛擬未來各種機遇的準備哦。

如果說軟件成為未來世界的基礎(chǔ),那么軟件單元將是基礎(chǔ)中的基礎(chǔ)。當我們在談論軟件單元測試時,我們實際在談的是如何打好軟件基礎(chǔ)。讓我們把視角從未來切回到當下,一起來探討目前關(guān)于軟件單元測試所面臨的實際困境,以及如何正確面對這些困境,從而期待為基礎(chǔ)的軟件研發(fā)過程做好堅實的技術(shù)支撐。

02

靈魂拷問:單元測試耗時費力、成效模糊難以直觀預見,功能安全標準為何將其作為關(guān)鍵過程進行要求?

wKgaomVEmaiAAmSYAAC2PPFUBJw738.png

軟件單元測試不是一個新的概念。不論是工業(yè)領(lǐng)域,還是金融、互聯(lián)網(wǎng)的軟件從業(yè)人員,相信對單元測試都或多或少有一定的認知,甚至已經(jīng)產(chǎn)生了相關(guān)的實踐。隨著IEC 61508功能安全標準體系的不斷擴充發(fā)展,安全攸關(guān)的領(lǐng)域最先對其引起了重視。

在快速軟件交付為王的背景之下,研發(fā)人員對單元測試的態(tài)度是認為基礎(chǔ)且重要,但是存在較大負擔的。

1. 首先,單元測試任務瑣碎繁重,會占用大量時間。通常情況下,對于一個小型10萬行規(guī)模的軟件,大約需要設(shè)計10000條用例去進行測試?;旧?,在沒有工具支撐的情況,需要消耗同寫代碼同樣的時間去撰寫測試驅(qū)動并測試;在有工具支持的情況會有所緩解,但也至少多花費一半的時間。

2. 其次,單元測試預期能產(chǎn)生的效果不是能立即直觀體現(xiàn)出來的。軟件單元測試是在軟件開發(fā)過程中進行,軟件還未集成在一起,那么對于單元測試發(fā)現(xiàn)的問題不能立即直觀地體現(xiàn)在軟件的整體功能上的,因此一開始缺乏直觀可見的對比證據(jù)來說服開發(fā)人員或者領(lǐng)導單元測試的重要意義。也就是說,單元測試的好處就好比保養(yǎng),在軟件開發(fā)階段是不能直觀體現(xiàn)出來的,需要到了軟件投入使用之后,經(jīng)過同類對比,才能真正的直觀體現(xiàn)出來。舉個例子,兩個負責不同模塊的程序員,一個總能快速完成開發(fā),另一個就要花較長的時間才能給出。從效率上講似乎快的能力更強。但是當給到客戶之后,你會發(fā)現(xiàn)完成快的模塊反饋出來奇奇怪怪的各種問題,需要很大的后期維護成本;慢的問題相對較少,漸漸地變得沒有新問題反饋出來。整體上來講,快的反而要花更長的時間,并且還消耗了口碑,投入了更多關(guān)系維護成本。

3. 再次,測試標準如何定義,何種程度可以認為是測試充分的是一個很關(guān)鍵的問題。單元測試通常會設(shè)定一些覆蓋率的指標,比如要求達到語句、分支覆蓋率100%。但是做到這些覆蓋率的指標就能證明沒有問題了嗎?很顯然不能,這是測試理論本身的通病,即只能發(fā)現(xiàn)問題,不能證明沒有問題。但這不是不進行單元測試的理由。這些指標要求是基礎(chǔ)要求,能夠完成這些指標,軟件的質(zhì)量會有一個質(zhì)的提升。

4. 最后,當詳細設(shè)計文檔不完善時,研發(fā)人員缺乏明確的測試依據(jù),導致工作難以開展。軟件單元測試需要比較強的前置條件,即需要有詳細的軟件設(shè)計文檔作為測試的需求依據(jù)。然而,這個前置條件本身如果不具備的話,那么就失去了做單元測試的基礎(chǔ)。這種情況下,企業(yè)可能需要考慮先下決心建立軟件質(zhì)量保證的流程體系,再來進一步細化具體的單元測試工作(敏捷開發(fā)對文檔沒有強制要求,敏捷開發(fā)依賴的是成員高度的共識和信息通暢,低文檔,高溝通。單元測試依據(jù)的內(nèi)容本質(zhì)上沒有區(qū)別,只不過更多通過溝通結(jié)果來作為無形的依據(jù)。這個有機會可以深入探討)。

因此,耗時費力,成效模糊難以直觀預見是軟件研發(fā)人員進行單元測試時需要排除的困難,而不是單元測試沒有意義的原因。在來談困難以及解決辦法之前,我們應當先明確什么是對的。單元測試是很有必要的,功能安全標準制定者將其作為關(guān)鍵的軟件驗證過程是有很高的指導意義的。軟件單元測試可以有效提升軟件整體的質(zhì)量和健壯性。除非極簡單的軟件系統(tǒng),單元測試如果不充分,做再多的系統(tǒng)測試也是不夠的,就好比掃雷不徹底,始終有觸雷的隱患。

03

單元測試到底在做什么,要做到什么程度?

軟件單元是軟件最小的設(shè)計單位,軟件單元的實現(xiàn)需要依據(jù)軟件設(shè)計需求。根據(jù)IEC 61508的要求,即“每個軟件模塊應當按軟件設(shè)計所規(guī)定的進行測試。這些測試應當表明每個軟件模塊將執(zhí)行其預期功能,且不會執(zhí)行非預期功能”。因此單元測試的核心目標是確保軟件單元同軟件設(shè)計的一致性。

為了確保一致性,功能安全標準列出了多種單元測試的方法。其中等價類測試和基于結(jié)構(gòu)的測試對于單元測試來說是充足的。邊界值測試和控制流程分析可以有效降低測試用例的數(shù)目。用盡可能少的用例來完成充足的測試是單元測試的最高追求。

1. 等價類測試

等價類測試指的是將測試的輸入分成幾類,每一類提供一個有代表性的輸入進行測試即可。這種方法免除了窮盡所有可能性的不切實際的測試方法,通過減少測試用例的數(shù)目到可接受的程度,可以有效提升測試的成效。

等價類劃分的方法有兩種:

1)從設(shè)計需求推導等價類。可以從輸入數(shù)據(jù)的角度,或者從輸出數(shù)據(jù)的角度進行劃分。

2)

從程序的內(nèi)部結(jié)構(gòu)推導等價類。可以根據(jù)靜態(tài)分析后的程序路徑來進行劃分。

2. 基于結(jié)構(gòu)的測試

基于結(jié)構(gòu)的測試,又稱白盒測試,是基于代碼來進行測試的一種技術(shù)。該測試方法關(guān)注代碼的內(nèi)部結(jié)構(gòu),需要研發(fā)或測試人員詳細了解代碼的內(nèi)部結(jié)構(gòu)。同時測試充分性有確定的覆蓋度量方法,可以通過系統(tǒng)性的增加測試用例來提升覆蓋率。

基于結(jié)構(gòu)的測試方法有多種,比較基礎(chǔ)的包含以下四種。

1)調(diào)用圖覆蓋。也叫做入口點測試,或者調(diào)用覆蓋測試。調(diào)用圖指的是子程序調(diào)用的樹形圖。該測試方法的目的是確保所有的子程序都被至少調(diào)用一次。

2)語句覆蓋。語句覆蓋是最基礎(chǔ)的測試方法,需要確保所有的語句都至少被測試一次。該方法較為簡單,然而對于測試來講精確度不是很高。

3)分支覆蓋。分支覆蓋指的是對于代碼的分支結(jié)構(gòu),需要確保所有的分支都被至少測試一次。該方法相對語句覆蓋,其測試精確度有較明顯的提升。

4)

MC/DC 覆蓋。修正的條件判定覆蓋,其針對的是程序的分支結(jié)構(gòu),并且影響分支走向的是多種條件的組合判定。該方法需要確保所有條件均能夠至少影響分支走向一次。該測試方法相對分支覆蓋,其測試精確度有了更高的提升。并且可以確保以最少的用例數(shù)目,達到更精確化測試的目的。以上是IEC 61508功能安全標準對基于結(jié)構(gòu)測試的基礎(chǔ)推薦方法。其中每一種測試覆蓋方法,均要達到100%的覆蓋。更高級的基于結(jié)構(gòu)的測試方法還有LCSAJ線性代碼序列和跳轉(zhuǎn)測試、數(shù)據(jù)流、基本路徑等覆蓋測試方法。有興趣的讀者可以進一步研究,并結(jié)合代碼特征靈活進行選用。

3. 邊界值測試

通常軟件錯誤通常會出現(xiàn)在軟件參數(shù)的邊界點。邊界值測試要求測試應涵蓋等價類的邊界和極端情況,同時還要檢查需求中的邊界同程序中的邊界是否一致。通常情況下,零值特別容易引起錯誤,需要特別注意零值的測試。如:

1)除零錯誤

2)空ASCII字符

3)空?;蛘弑碓?/p>

4)滿矩陣

5)

0表項

4. 控制流分析

控制流分析是為了尋找程序結(jié)構(gòu)潛在錯誤的一種測試方法。它通過采用靜態(tài)測試技術(shù)來分析程序的控制流程圖,然后進一步分析控制流程圖來發(fā)現(xiàn)不良的程序?qū)嵺`。通過控制流程圖分析,可以發(fā)現(xiàn)以下問題。

1)

不可達代碼。也被稱為死代碼,指的是永遠不會被觸發(fā)執(zhí)行到的代碼。

2)

打結(jié)的代碼。良好的代碼通??梢詫⑵淇刂屏鞒虉D簡化為一個單節(jié)點,相反的,不良的代碼則會簡化為一個環(huán)狀結(jié)構(gòu)。

因此,軟件單元測試是一項有明確的測試方法指導,并且具備充分性度量的標準的一項測試工作。在設(shè)定測試方法時,可以根據(jù)待測軟件的質(zhì)量或安全要求級別,選取適合的測試方法組合。

在下一期“軟件單元測試真的有必要嗎?(下)”中,將深入探討單元測試過程中,如何在保質(zhì)保量完成測試任務的同時,縮減時間成本、提高測試效率,并分享目前行業(yè)內(nèi)的實踐經(jīng)驗以及相關(guān)自動化測試工具。

審核編輯 黃宇


聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 單元測試
    +關(guān)注

    關(guān)注

    0

    文章

    53

    瀏覽量

    3479
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    資料] 汽車軟件質(zhì)量躍遷的系統(tǒng)性路徑:基于ISO 26262標準的單元測試體系重構(gòu)與中日實踐深度對比(2026學術(shù)研究報告)

    各位伙伴,請問一個問題,[資料] 汽車軟件質(zhì)量躍遷的系統(tǒng)性路徑:基于ISO 26262標準的單元測試體系重構(gòu)與中日實踐深度對比(2026學術(shù)研究報告),這份數(shù)據(jù)誰有源參考文獻,酬感謝
    發(fā)表于 01-08 10:09

    汽車軟件質(zhì)量躍遷的系統(tǒng)性路徑:基于ISO 26262標準的單元測試體系重構(gòu)與中日實踐深度對比(2026學術(shù)研究報告)

    %源于軟件邏輯錯誤,其中32%因單元測試邊界條件未覆蓋(TüV SüD《2024汽車軟件召回分析》)。典型案例包括某新勢力車企因制動模塊未測試導致1.2萬輛召回,損失超5億元。 1.2
    發(fā)表于 01-05 14:58

    嵌入式軟件單元測試中AI自動化與人工檢查的協(xié)同機制研究:基于專業(yè)工具的實證分析

    ? ?摘要****? 本文系統(tǒng)探討嵌入式軟件相較于通用軟件單元測試層面的特殊性,分析其對高覆蓋率、可追溯性與實時性驗證的嚴苛需求,并以專業(yè)工具winAMS為技術(shù)載體,深入研究AI驅(qū)動的自動化
    發(fā)表于 12-31 11:22

    C語言單元測試在嵌入式軟件開發(fā)中的作用及專業(yè)工具的應用

    平臺和操作系統(tǒng)運行,無需進行大量的修改 二、C語言單元測試在嵌入式開發(fā)中的關(guān)鍵作用 嵌入式系統(tǒng)對實時性和可靠性要求極高,單元測試是確保代碼質(zhì)量的關(guān)鍵手段。單元測試在嵌入式開發(fā)中的作用
    發(fā)表于 12-18 11:46

    嵌入軟件單元測試的全面研究與實踐

    引言 嵌入軟件單元測試是確保嵌入式系統(tǒng)質(zhì)量和可靠性的關(guān)鍵環(huán)節(jié)。嵌入式系統(tǒng)廣泛應用于汽車電子、工業(yè)控制、醫(yī)療設(shè)備等關(guān)鍵領(lǐng)域,其軟件直接操控硬件,任何微小的錯誤都可能導致嚴重后果。單元測試
    的頭像 發(fā)表于 12-01 14:31 ?375次閱讀

    新能源汽車質(zhì)量保證體系與傳統(tǒng)汽車單元測試規(guī)范的融合研究

    摘要 隨著新能源汽車產(chǎn)業(yè)的快速發(fā)展,其質(zhì)量保證體系面臨前所未有的挑戰(zhàn)。本文探討了將傳統(tǒng)汽車成熟的單元測試規(guī)范應用于新能源汽車領(lǐng)域的可行性,重點分析了ISO 26262標準體系在新能源汽車電子控制系統(tǒng)
    的頭像 發(fā)表于 11-07 10:10 ?199次閱讀

    單元測試專業(yè)工具在新能源開發(fā)中的作用研究

    單元測試的歷史由來與發(fā)展 單元測試的概念可以追溯到20世紀60年代,伴隨著計算機科學和軟件工程學科的發(fā)展而逐步形成。早期的計算機科學研究(20世紀60年代)中,程序員意識到僅依靠手工調(diào)試和集成
    的頭像 發(fā)表于 11-03 16:03 ?412次閱讀

    嵌入式軟件測試與專業(yè)測試工具的必要性深度解析

    ?:單元測試、集成測試、系統(tǒng)測試等不同階段可能需要不同的工具組合16。 ?軟件特性?:實時性要求、安全等級等特性決定工具的功能需求。 ?環(huán)境適配性?:工具是否支持目標硬件平臺和開發(fā)
    發(fā)表于 09-28 17:42

    邊聊安全 | 軟件單元測試的設(shè)計方法

    上海磐時PANSHI“磐時,做汽車企業(yè)的安全智庫”軟件單元測試的設(shè)計方法寫在前面:軟件單元測試的設(shè)計是一個系統(tǒng)化的過程,旨在驗證代碼的最小可測試
    的頭像 發(fā)表于 09-05 16:18 ?6395次閱讀
    邊聊安全 | <b class='flag-5'>軟件</b><b class='flag-5'>單元測試</b>的設(shè)計方法

    HarmonyOSAI編程單元測試用例

    根據(jù)選中的ArkTS方法名稱,CodeGenie支持自動生成對應單元測試用例,提升測試覆蓋率。 在ArkTS文檔中,光標放置于方法名稱或框選完整的待測試方法代碼塊,右鍵選擇CodeG
    發(fā)表于 08-27 14:33

    HarmonyOS AI輔助編程工具(CodeGenie)代碼測試

    放置于方法名稱或框選完整的待測試方法代碼塊,右鍵選擇CodeGenie > Generate UT,開始生成單元測試用例。 說明 最多支持解讀20000字符以內(nèi)的代碼片段。ArkUI
    發(fā)表于 07-14 17:33

    新能源車軟件單元測試深度解析:自動駕駛系統(tǒng)視角

    ?第一部分:新能源車軟件單元測試的戰(zhàn)略重要性 ?汽車電子架構(gòu)的范式轉(zhuǎn)變? 隨著新能源車的普及,汽車電子架構(gòu)從傳統(tǒng)的分布式ECU(電子控制單元)向集中式域控制器(Domain Controller
    發(fā)表于 05-12 15:59

    新能源車背后的隱形守護者:軟件單元測試的生死較量?

    。這個教科書級的避讓動作背后,是超過8000萬行代碼的精密協(xié)作,而確保這些代碼絕對可靠的秘密武器,正是我們今天要揭秘的軟件單元測試。 ?一、代碼世界的顯微鏡:單元測試為何重要? 如果把整車軟件
    的頭像 發(fā)表于 05-12 11:00 ?514次閱讀

    單元測試在嵌入式軟件中的關(guān)鍵作用及winAMS工具的卓越貢獻

    1.?單元測試概述 ?定義與核心目標? 單元測試軟件開發(fā)過程中針對程序模塊(如函數(shù)、類或組件)的最小可測試單元進行的驗證活動。其核心目標在
    的頭像 發(fā)表于 04-11 14:31 ?933次閱讀

    嵌入式軟件單元測試必要性、核心方法及工具深度解析

    一、為什么嵌入式軟件必須重視單元測試? ?嵌入式系統(tǒng)的特殊性? 在汽車 ECU、醫(yī)療設(shè)備控制器等場景中,軟件直接操控硬件,?單比特錯誤可能導致剎車失靈或呼吸機故障?。不同于 PC?軟件
    的頭像 發(fā)表于 03-21 14:53 ?1182次閱讀