


摘要:隨著嵌入式系統(tǒng)應(yīng)用的不斷拓展,軟件復(fù)雜度不斷提升,傳統(tǒng)的開發(fā)模式已無法保證軟件開發(fā)的進(jìn)度與質(zhì)量。針對這一現(xiàn)狀,文章通過引入測試驅(qū)動(dòng)先行的設(shè)計(jì)理念,提出了一種嵌入式軟件敏捷測試平臺(tái)的設(shè)計(jì)方案,通過接口仿真、交聯(lián)關(guān)系、自動(dòng)化測試設(shè)計(jì)等方面闡明了方案可行性。該敏捷測試平臺(tái)可擺脫硬件平臺(tái)對核心軟件邏輯測試的約束,快速完成軟件開發(fā)與維護(hù)階段的功能測試及回歸測試,大幅提升了軟件測試的效率,能夠更好地完成持續(xù)集成、持續(xù)測試。
關(guān)鍵詞:嵌入式系統(tǒng);接口測試;測試驅(qū)動(dòng)開發(fā);敏捷測試;自動(dòng)化測試
中圖分類號:TP273文獻(xiàn)標(biāo)志碼:A
0 引言
隨著計(jì)算機(jī)技術(shù)的蓬勃發(fā)展,嵌入式系統(tǒng)逐漸在國防、航空、航天、航海等領(lǐng)域得到廣泛應(yīng)用,而在嵌入式軟件規(guī)模日益擴(kuò)大的同時(shí),用戶對于開發(fā)進(jìn)度、軟件質(zhì)量等方面的要求愈來愈高,對于產(chǎn)品軟件已經(jīng)不僅僅滿足于功能性需求,需要綜合考慮可靠性、安全性、維護(hù)性、測試性等各方面的非功能性需求。對于規(guī)模達(dá)到上萬甚至十余萬行的嵌入式軟件代碼,僅靠傳統(tǒng)的“即開即用”開發(fā)模式已無法滿足使用需求,系統(tǒng)而完備的測試方法是保證產(chǎn)品軟件質(zhì)量和滿足用戶需求的重要保障。目前,嵌入式產(chǎn)品的測試方式多以手工測試為主,開發(fā)人員對系統(tǒng)邏輯及接口進(jìn)行測試時(shí)均需要手工編碼完成用例設(shè)計(jì)執(zhí)行,對于復(fù)雜系統(tǒng)的嵌入式軟件,由于交聯(lián)關(guān)系復(fù)雜、接口類型多樣的特點(diǎn),靠手工測試難以滿足快速迭代的需求以及壓力測試需求。針對該情況,開發(fā)人員需要結(jié)合產(chǎn)品生命周期,研究一種與研發(fā)流程并行開展的全自動(dòng)化敏捷測試平臺(tái)設(shè)計(jì)方案,從測試平臺(tái)構(gòu)建、需求分解、用例設(shè)計(jì)、自動(dòng)測試驗(yàn)證等方面完成從需求到測試的全覆蓋閉環(huán)過程,實(shí)現(xiàn)防患于未然,提升產(chǎn)品的質(zhì)量。
1 嵌入式軟件敏捷測試需求分析
目前,常見的軟件開發(fā)模型包括瀑布模型、V模型、W模型、敏捷開發(fā)模型[1-2],基本均包含了需求、設(shè)計(jì)、開發(fā)、測試、交付的全過程。以汽車行業(yè)廣泛應(yīng)用的V模型為例,其開發(fā)過程如圖1所示。
V模型左側(cè)是需求分析及設(shè)計(jì)的過程,右側(cè)表示左側(cè)對應(yīng)的驗(yàn)證工作[3-4]。軟件開發(fā)過程引入多級測試的目的是及早發(fā)現(xiàn)軟件中潛藏的缺陷,在產(chǎn)品生命周期中越早發(fā)現(xiàn)問題,對問題進(jìn)行糾正所產(chǎn)生的質(zhì)量成本越低。軟件缺陷一般包括顯性功能性缺陷(與需求不符或?qū)崿F(xiàn)錯(cuò)誤)、隱性功能缺陷(需求文檔中未明確但應(yīng)該實(shí)現(xiàn)的要求)、非功能缺陷(使用維護(hù)性不佳、用戶體驗(yàn)不好)。軟件測試根據(jù)測試級別可分為單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試等[5],根據(jù)測試方式可分為手動(dòng)測試、自動(dòng)測試2類。其中,手動(dòng)測試需要花費(fèi)大量的時(shí)間來構(gòu)造測試用例及不斷修改與執(zhí)行測試過程,而自動(dòng)測試可通過測試用例的復(fù)用以及一鍵自動(dòng)運(yùn)行方法來提升測試效率,極大地節(jié)約了人力物力,成為現(xiàn)行測試手段中不可或缺的方法。
在嵌入式系統(tǒng)產(chǎn)品研發(fā)過程中,測試的一大難點(diǎn)是過于依賴硬件環(huán)境[6-8],容易出現(xiàn)“等、靠、搶”測試資源的問題,尤其在產(chǎn)品首套交付過程中,往往會(huì)出現(xiàn)硬件測試環(huán)境不足的情況,導(dǎo)致有效的測試時(shí)間由于進(jìn)度原因被嚴(yán)重壓縮。在測試不充分的情況下,開發(fā)人員僅能針對軟件的典型需求開展基礎(chǔ)性功能測試,而無法開展完備的正向/邊界/異常測試,對后續(xù)產(chǎn)品交付效率與實(shí)物質(zhì)量均造成了不利的影響,往往會(huì)導(dǎo)致問題集中暴露在后續(xù)產(chǎn)品調(diào)試過程而非軟件開發(fā)過程,造成軟件問題及硬件問題耦合在一起,極大地提升了問題排查的復(fù)雜度。傳統(tǒng)的系統(tǒng)級測試環(huán)境往往依賴于半實(shí)物或者實(shí)物激勵(lì)設(shè)備,由于產(chǎn)品研制與測試設(shè)備研制進(jìn)度的不同步、界面不統(tǒng)一、測試數(shù)據(jù)定制化難以復(fù)用等原因,即使在已有類似產(chǎn)品的開發(fā)運(yùn)行維護(hù)過程中已經(jīng)開展了一系列煩瑣復(fù)雜的測試工作,在同類型其他產(chǎn)品的測試階段也無法對已有測試用例高效復(fù)用,導(dǎo)致大量低水平工作重復(fù)出現(xiàn)。
針對上述問題,可采用測試驅(qū)動(dòng)開發(fā)(Test-Driven Development,TDD)[9-10]的思想來提前開展嵌入式系統(tǒng)軟件的敏捷測試。TDD思想顛倒了傳統(tǒng)“先設(shè)計(jì)后編碼再測試”的方法,提倡測試先行的理念,在編寫功能代碼之初即提前構(gòu)造測試代碼,通過提早測試來避免代碼質(zhì)量越來越糟的隱患。完全可測試的代碼能夠保證在代碼增量開發(fā)時(shí)提前發(fā)現(xiàn)軟件問題,大幅節(jié)約后續(xù)的產(chǎn)品調(diào)試時(shí)間,在調(diào)試時(shí)僅針對嵌入式系統(tǒng)的硬件接口特性進(jìn)行重點(diǎn)測試即可,通過將測試工作前移來提升產(chǎn)品交付的質(zhì)量和效率。
結(jié)合TDD思想,本文提出一種自動(dòng)化敏捷測試平臺(tái)[11-12]設(shè)計(jì)方案,在產(chǎn)品研發(fā)過程中首先由軟件開發(fā)人員提前搭建好全數(shù)字仿真環(huán)境,依據(jù)功能需求和接口完成軟件的黑盒測試,形成“邊開發(fā)邊測試”的研發(fā)模式,極大地將風(fēng)險(xiǎn)提前暴露在開發(fā)階段;其次,針對快速迭代的需求,該平臺(tái)能夠快速實(shí)現(xiàn)需求變更的回歸測試,針對每一條需求變更項(xiàng)均開展正向及反向驗(yàn)證,保證代碼更改對其他功能不產(chǎn)生次生影響;最后,針對需求條目形成可復(fù)用的測試用例,有助于不斷積累,快速構(gòu)造自動(dòng)化敏捷測試平臺(tái)復(fù)用庫,提升測試效率。
2 軟件敏捷測試平臺(tái)設(shè)計(jì)方案
產(chǎn)品敏捷開發(fā)與測試的要求是需要具備快速迭代能力,能夠及時(shí)持續(xù)地響應(yīng)用戶的需求頻繁反饋,通過測試策略的正確建立,持續(xù)確保用戶有效需求能夠貫穿和落實(shí)到產(chǎn)品的整個(gè)研發(fā)周期,從而保證最終輸出物的正確性。
結(jié)合上述需求,要實(shí)現(xiàn)嵌入式軟件的敏捷測試平臺(tái)構(gòu)建,需從以下幾個(gè)方面進(jìn)行綜合考慮:接口仿真、交聯(lián)關(guān)系、自動(dòng)化用例執(zhí)行。
2.1 接口仿真
真實(shí)嵌入式系統(tǒng)所涉及的接口類型種類繁多[13-15],包括FC總線、GJB289A總線、CAN總線、RS422總線、離散量、模擬量等接口。要實(shí)現(xiàn)敏捷測試平臺(tái)對各類接口的覆蓋,本文通過數(shù)據(jù)消息仿真的方法來模擬外部激勵(lì)數(shù)據(jù)[16],被測軟件及敏捷測試平臺(tái)底層均按照用戶數(shù)據(jù)報(bào)協(xié)議(User Datagram Protocl,UDP)進(jìn)行不同節(jié)點(diǎn)間的全數(shù)字仿真通信。節(jié)點(diǎn)間均通過協(xié)議封裝的形式來模擬各種總線通信的數(shù)據(jù)交互,在消息發(fā)送端發(fā)送數(shù)據(jù)時(shí),封裝不同的消息包頭(包括消息類型、消息長度、消息ID等),采用“消息包頭+消息內(nèi)容”的格式進(jìn)行發(fā)送,消息接收端在收到UDP數(shù)據(jù)時(shí),先對消息包頭進(jìn)行解析,確認(rèn)對應(yīng)的數(shù)據(jù)類型,再根據(jù)協(xié)議解析對應(yīng)的消息內(nèi)容,即可完成對各種接口的數(shù)據(jù)內(nèi)容傳輸與解析,從而方便快捷地實(shí)現(xiàn)不同節(jié)點(diǎn)間的全數(shù)字仿真通信。
2.2 交聯(lián)關(guān)系
敏捷測試環(huán)境交聯(lián)關(guān)系如圖2所示。在被測軟件按照敏捷測試平臺(tái)仿真驅(qū)動(dòng)進(jìn)行替換后,即可解決測試環(huán)境的通信問題。敏捷測試平臺(tái)作為測試用例導(dǎo)入和執(zhí)行的核心節(jié)點(diǎn),可以依據(jù)接口完成對被測軟件的激勵(lì)仿真,按照系統(tǒng)真實(shí)運(yùn)行的業(yè)務(wù)場景將控制命令發(fā)送給待測軟件,將待測軟件對外輸出的接口反饋結(jié)果進(jìn)行實(shí)時(shí)顯示,存儲(chǔ)到測試結(jié)果文件中進(jìn)行記錄。對于簡單嵌入式系統(tǒng),被測軟件可作為仿真節(jié)點(diǎn)直接與敏捷測試平臺(tái)進(jìn)行點(diǎn)對點(diǎn)式交互來完成軟件的配置項(xiàng)測試;對于復(fù)雜嵌入式系統(tǒng),僅須保證各節(jié)點(diǎn)仿真驅(qū)動(dòng)的一致性,除了被測軟件與敏捷測試平臺(tái)外,系統(tǒng)內(nèi)其他配套軟件也可作為仿真節(jié)點(diǎn)插入網(wǎng)絡(luò),從而完成對整個(gè)嵌入式系統(tǒng)多個(gè)配置項(xiàng)軟件之間的系統(tǒng)級仿真測試。
2.3 自動(dòng)化執(zhí)行
單個(gè)測試用例在設(shè)計(jì)時(shí)應(yīng)能覆蓋功能邏輯中總線/離散量等接口類數(shù)據(jù)連通性和內(nèi)容正確性、消息發(fā)送間隔、消息回復(fù)間隔等方面的測試內(nèi)容,對檢測過程、延時(shí)間隔、判讀窗口等內(nèi)容進(jìn)行通用約束,讓測試人員能夠通過測試結(jié)果直觀判斷軟件中對應(yīng)需求實(shí)現(xiàn)的正確性。
要實(shí)現(xiàn)各測試用例的快速自動(dòng)化測試[17-19],提升測試效率,需要敏捷測試平臺(tái)具備以下能力。
2.3.1 系統(tǒng)接口控制文件的自動(dòng)導(dǎo)入功能
接口控制文件(Interface Control Document,ICD)作為系統(tǒng)與外部交互的頂層依據(jù),也是開展黑盒測試的輸入文件指導(dǎo),根據(jù)需求衍生出每個(gè)功能點(diǎn)輸入接口需求及輸出接口需求,敏捷測試平臺(tái)通過直接對導(dǎo)入的不同ICD接口的數(shù)據(jù)內(nèi)容進(jìn)行配置來快速模擬輸入接口激勵(lì),判斷輸出接口的數(shù)據(jù)內(nèi)容及時(shí)間特性是否符合系統(tǒng)要求。
2.3.2 測試用例快速設(shè)計(jì)功能
該平臺(tái)無需通過手動(dòng)編碼的方式實(shí)現(xiàn)用例編輯,僅通過配置接口消息中對應(yīng)數(shù)據(jù)的數(shù)值即可實(shí)現(xiàn)測試用例的快速設(shè)計(jì)與實(shí)現(xiàn)。一方面可快速完成首輪手動(dòng)測試用例的編輯,另一方面可依據(jù)手動(dòng)測試通過時(shí)敏捷測試平臺(tái)與產(chǎn)品軟件間運(yùn)行所產(chǎn)生的真實(shí)交互數(shù)據(jù)作為期望值基準(zhǔn),測試人員只需要對用例的期望數(shù)據(jù)內(nèi)容和時(shí)間范圍進(jìn)行確認(rèn)和調(diào)整,即可快速根據(jù)自動(dòng)用例生成邏輯完成自動(dòng)測試用例的生成和固化,避免了傳統(tǒng)方式下反復(fù)手動(dòng)調(diào)整期望值的過程。
2.3.3 測試用例集的配置、修改、存儲(chǔ)、導(dǎo)入等功能
通過需求使用場景進(jìn)行分解,該測試平臺(tái)將不同的測試用例通過組合的方式關(guān)聯(lián)固化為某一項(xiàng)業(yè)務(wù)場景下的用例集,該用例集可直接對不同測試用例間的時(shí)序關(guān)系進(jìn)行配置,消息激勵(lì)可配置為事件觸發(fā)或者周期觸發(fā),對于周期觸發(fā)應(yīng)能配置消息的具體時(shí)間間隔。
2.3.4 一鍵式自動(dòng)執(zhí)行功能
敏捷測試平臺(tái)可以按照提前現(xiàn)有測試用例集中所固化的用例激勵(lì)順序和時(shí)序特性對被測軟件進(jìn)行測試交互,通過模擬用戶一系列的操作和激勵(lì)輸入,完成對應(yīng)需求的場景還原和測試覆蓋。
3 測試結(jié)果管理分析
為減輕測試人員負(fù)擔(dān),測試結(jié)果應(yīng)能實(shí)現(xiàn)自動(dòng)分析功能,包含實(shí)時(shí)顯示、報(bào)告一鍵生成、測試結(jié)果回放等功能。因此,敏捷測試平臺(tái)設(shè)計(jì)時(shí)需要有效分割測試業(yè)務(wù)核心邏輯與人機(jī)界面,為項(xiàng)目人員提供簡單易用、可視化的測試用例開發(fā)環(huán)境;梳理共性需求,分離關(guān)注點(diǎn),對業(yè)務(wù)進(jìn)行合理切割,可以提高整體工作效率并有效提升工作質(zhì)量;可結(jié)合產(chǎn)品運(yùn)行數(shù)據(jù),對測試過程的條件和產(chǎn)品的性能參數(shù)進(jìn)行記錄和復(fù)盤分析;通過測試用例及結(jié)果的累積,形成可復(fù)用的組織知識(shí),提升整體的測試水平。具體功能如下。
3.1 具備實(shí)時(shí)顯示對比功能
在測試用例集自動(dòng)執(zhí)行時(shí),應(yīng)能提供實(shí)際測試結(jié)果與預(yù)期測試結(jié)果的對比顯示,能夠直觀顯示是否測試通過,標(biāo)注出具體錯(cuò)誤項(xiàng)。
3.2 具備測試結(jié)果自動(dòng)記錄功能
平臺(tái)應(yīng)能支持測試結(jié)果一鍵生成,導(dǎo)入數(shù)據(jù)記錄文件中,記錄中包括每個(gè)測試用例的執(zhí)行結(jié)果是否正確,用例的期望值與實(shí)測值以及最終執(zhí)行結(jié)果的統(tǒng)計(jì)情況匯總信息。
3.3 具備測試結(jié)果報(bào)告的導(dǎo)入、回放、分析等功能
測試人員通過敏捷測試平臺(tái)完成測試用例的執(zhí)行后,自動(dòng)生成測試記錄供開發(fā)人員進(jìn)行問題分析,同時(shí)通過測試用例、不通過率、缺陷數(shù)等數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析,反復(fù)提煉測試用例設(shè)計(jì)關(guān)鍵點(diǎn),有助于形成典型需求所配套的測試用例知識(shí)庫,便于后續(xù)類似產(chǎn)品測試用例的高效復(fù)用。
4 應(yīng)用實(shí)踐
以某型機(jī)載嵌入式設(shè)備為例,軟件開發(fā)、迭代過程的應(yīng)用場景及流程如圖3所示。
在軟件開發(fā)階段,一方面,設(shè)計(jì)人員應(yīng)重點(diǎn)保證軟件功能需求實(shí)現(xiàn)的正確性,可根據(jù)系統(tǒng)頂層文件、接口控制文件、軟件研制任務(wù)書、軟件需求規(guī)格說明等對需求進(jìn)行分解,衍生出不同的測試用例集,在對產(chǎn)品軟件進(jìn)行編碼實(shí)現(xiàn)時(shí)完成驅(qū)動(dòng)層的封裝,保證可同時(shí)兼容真實(shí)嵌入式環(huán)境驅(qū)動(dòng)及仿真驅(qū)動(dòng)[20-21]。另一方面,軟件開發(fā)人員通過根據(jù)系統(tǒng)接口控制文件完成敏捷測試平臺(tái)的接口配置,依據(jù)需求規(guī)格說明衍生出的測試用例完成用例設(shè)計(jì)及錄入功能,形成“邊開發(fā)邊測試”的模式后,每完成一個(gè)軟件功能點(diǎn)的開發(fā)及單元測試后,可通過敏捷測試平臺(tái)快速完成該功能的黑盒測試,可通過全數(shù)字仿真環(huán)境下單步跟蹤等方式來快速定位代碼問題。本階段形成的測試用例可按功能點(diǎn)配置為自動(dòng)測試用例集,形成可供后續(xù)復(fù)用的組織資產(chǎn)。
在軟件已完成開發(fā)交付,處于運(yùn)行階段時(shí),軟件維護(hù)人員往往面臨系統(tǒng)需求的頻繁迭代變化,此時(shí)一方面應(yīng)保證需求變更實(shí)現(xiàn)的正確性,另一方面應(yīng)確保軟件變更對其他功能模塊無影響。此時(shí)針對新增/變更需求,敏捷測試平臺(tái)可充分利用現(xiàn)有測試用例集進(jìn)行新增或修改,完成新增功能的自動(dòng)測試,同時(shí)可確保已有代碼的功能不受影響。若在產(chǎn)品已大規(guī)模部署運(yùn)行時(shí)出現(xiàn)軟件原因?qū)е碌墓收希_發(fā)人員能夠足不出戶,遠(yuǎn)程了解故障發(fā)生時(shí)的運(yùn)行場景,利用敏捷測試平臺(tái)快速完成對應(yīng)用例設(shè)計(jì)、場景復(fù)現(xiàn)、故障排查等工作,大幅節(jié)約了質(zhì)量問題處理的人力成本及時(shí)間成本。
通過敏捷測試平臺(tái)的實(shí)踐落實(shí),開發(fā)人員能夠快速對軟件變更內(nèi)容進(jìn)行自動(dòng)化測試,將精力集中在軟件設(shè)計(jì)、測試用例覆蓋以及提升代碼質(zhì)量上,一鍵式完成批量測試用例的統(tǒng)一自動(dòng)執(zhí)行,測試結(jié)果自動(dòng)記錄,無需逐一核對,通過測試結(jié)果分析可以提前規(guī)避質(zhì)量風(fēng)險(xiǎn)。實(shí)踐證明,該測試平臺(tái)相對比人工測試,環(huán)境搭建的效率提升了約60%,測試用例設(shè)計(jì)效率提升了70%,用例執(zhí)行效率提升了65%左右,將整個(gè)項(xiàng)目的測試周期大幅壓縮。
5 結(jié)語
結(jié)合嵌入式系統(tǒng)的應(yīng)用發(fā)展趨勢,針對嵌入式系統(tǒng)測試環(huán)境的特殊性,分析了嵌入式軟件敏捷測試相關(guān)的需求,本文提出了一種嵌入式軟件敏捷測試平臺(tái)的設(shè)計(jì)方案,通過接口仿真、交聯(lián)關(guān)系、自動(dòng)化測試設(shè)計(jì)與結(jié)果分析等方面闡明了方案可行性。該敏捷測試平臺(tái)可適應(yīng)不同嵌入式系統(tǒng),快速完成軟件開發(fā)迭代的功能測試及回歸測試,有效避免了傳統(tǒng)手動(dòng)測試反復(fù)開發(fā)難以復(fù)用的低效性,大幅提升了軟件測試的效率,有利于保證產(chǎn)品軟件的質(zhì)量。該嵌入式軟件敏捷測試平臺(tái)已在多個(gè)項(xiàng)目上得到了充分驗(yàn)證。實(shí)踐結(jié)果表明相對于傳統(tǒng)人工測試手段,能夠?qū)⒃械臏y試周期壓縮為十分之一,可以有效實(shí)現(xiàn)測試先行的設(shè)計(jì)理念,擺脫硬件平臺(tái)對核心軟件邏輯測試的約束,更好地完成持續(xù)集成、持續(xù)測試,后續(xù)可從全數(shù)字仿真環(huán)境擴(kuò)展到半實(shí)物測試環(huán)境,有較好的應(yīng)用前景。
參考文獻(xiàn)
[1]高明,李明,陳慶貴.基于系統(tǒng)工程V模型的航空發(fā)動(dòng)機(jī)正向設(shè)計(jì)方法[J].海軍航空大學(xué)學(xué)報(bào),2023(3):294-300.
[2]邢家茂,何平,王志成.基于V模型的伺服系統(tǒng)開發(fā)方法[J].小型微型計(jì)算機(jī)系統(tǒng),2012(1):183-187.
[3]申曉彥,郭佳旭,曹春芳,等.基于改進(jìn)V模型的軟件測試過程研究[J].電腦知識(shí)與技術(shù),2021(9):81-82,87.
[4]王帥,藍(lán)啟亮,陳聰,等.基于汽車嵌入式軟件的持續(xù)集成和持續(xù)測試分析[J].汽車實(shí)用技術(shù),2023(10):156-162.
[5]王樹義,南建國,黃雷.航空軟件測試過程模型應(yīng)用研究[J].計(jì)算機(jī)測量與控制,2013(6):1443-1445.
[6]張翔,彭琿,張曉娜,等.基于全數(shù)字仿真的飛控嵌入式軟件測試方法與實(shí)現(xiàn)[J].無線互聯(lián)科技,2023(5):73-76.
[7]劉宏偉.基于半實(shí)物仿真的抄表系統(tǒng)自動(dòng)化測試平臺(tái)設(shè)計(jì)[J].計(jì)算機(jī)測量與控制,2022(12):51-57,63.
[8]涂步華,鄭洪波,劉演超.基于半實(shí)物仿真的嵌入式軟件測試平臺(tái)的設(shè)計(jì)[J].信息技術(shù)與信息化,2023(11):24-27.
[9]馬寶英,董政昊,袁茂才,等.敏捷回歸測試中關(guān)鍵技術(shù)發(fā)展現(xiàn)狀研究[J].軟件,2023(4):74-77.
[10]劉先博,沈小侖.面向敏捷開發(fā)的軟件測試技術(shù)[J].電腦知識(shí)與技術(shù),2015(18):70-72.
[11]趙光星.面向敏捷開發(fā)的軟件測試技術(shù)研究與應(yīng)用[D].湘潭:湖南科技大學(xué),2011.
[12]孟琪,韓曉晶.敏捷測試在軟件項(xiàng)目中的應(yīng)用研究與實(shí)踐[J].數(shù)字技術(shù)與應(yīng)用,2020(13):24-25.
[13]范義杰,趙昶宇.通用嵌入式測試平臺(tái)技術(shù)研究[J].科技與創(chuàng)新,2023(21):108-110.
[14]王向暉,李林.星載嵌入式軟件自動(dòng)化測試技術(shù)研究[J].計(jì)算機(jī)測量與控制,2012(1):267-269.
[15]邢浩,胡佳貝,李碧涵,等.一種基于機(jī)載嵌入式軟件的自動(dòng)化測試方法[J].信息技術(shù)與信息化,2022(2):17-20.
[16]耿嘉祺,李鑫麗,祝小蘭.支持用例集并行測試的接口測試平臺(tái)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用,2023(6):91-98.
[17]金虎.自動(dòng)化軟件測試技術(shù)研究[D].成都:四川大學(xué),2008.
[18]齊永龍,宋斌,劉道煦.國外自動(dòng)測試系統(tǒng)發(fā)展綜述[J].國外電子測量技術(shù),2015(12):1-47.
[19]李賀,鄧學(xué)文,朱奎寶,等.基于腳本驅(qū)動(dòng)的光纖陀螺自動(dòng)化測試系統(tǒng)設(shè)計(jì)[J].計(jì)算機(jī)工程與設(shè)計(jì),2016(2):552-555,561.
[20]陽長永,王月波,代林.嵌入式軟件自動(dòng)化測試及管理系統(tǒng)研究[J].計(jì)算機(jī)測量與控制,2019(9):57-60,75.
[21]高化琦.虛擬仿真環(huán)境下嵌入式軟件高效自動(dòng)化測試技術(shù)及應(yīng)用研究[D].杭州:杭州電子科技大學(xué),2021.
Design of sharp testing platform for embedded software based on interface test driver
Abstract: With the continuous expansion of embedded system applications and the increasing complexity of software, traditional development models can no longer guarantee the progress and quality of software development. In response to this situation, a design scheme for an embedded software agile testing platform is proposed by introducing the design concept of first test driver. The feasibility of the scheme is elucidated through interface simulation, cross-linking relationships and automated testing design. This agile testing platform can break free from the constraints of hardware platforms on core software logic testing, quickly complete functional testing and regression testing during software development and maintenance stages, greatly improving the efficiency of software testing and enabling better continuous integration and testing.
Key words: embedded system; interface test; test-driven development; sharp test; auto test