版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)
文檔簡介
第7章
軟件實現(xiàn)與測試?掌握軟件質(zhì)量的概念?了解代碼規(guī)范?了解代碼重構(gòu)?理解軟件測試的相關(guān)概念和模型?理解測試自動化?掌握幾種重要的黑盒和玻璃盒測試方法?了解測試驅(qū)動的開發(fā)TDD?了解軟件集成方式軟件實現(xiàn)并不等同于編碼。軟件實現(xiàn)包括編碼、代碼審查、單元測試、集成測試、缺陷跟蹤和糾錯等一系列過程。學(xué)習(xí)目標(biāo)高質(zhì)量軟件開發(fā)基本方法1代碼規(guī)范2軟件測試3測試驅(qū)動開發(fā)TDD4集成57.1高質(zhì)量軟件開發(fā)的基本方法軟件質(zhì)量是貫穿軟件生命周期的一個極為重要的問題。(1)建立軟件過程規(guī)范
一個軟件過程定義了軟件開發(fā)中采用的方法,還包含該過程、
中應(yīng)用的技術(shù)方法和自動化工具。(2)軟件復(fù)用
復(fù)用(Reuse)簡單來說就是指“利用現(xiàn)成的東西”。早期的軟件復(fù)用主要是代碼級復(fù)用,后來逐步擴(kuò)大到需求、設(shè)計、代碼、文檔、領(lǐng)域知識、開發(fā)經(jīng)驗、設(shè)計決策、體系結(jié)構(gòu)等與軟件產(chǎn)品相關(guān)的各方面。(3)軟件評審
軟件評審(Review)是在軟件生命周期內(nèi)所實施的對軟件本身的評審,是對軟件元素或者項目狀態(tài)的一種評估,以確定其是否與計劃的結(jié)果保持一致,并使其得到改進(jìn)。評審方法已經(jīng)被業(yè)界廣泛采用并取得了很好的效果,它被普遍認(rèn)為是軟件開發(fā)的最佳實踐之一。評審可以比測試更早地發(fā)現(xiàn)并消除工作成果中的缺陷,而越早消除缺陷就越能降低開發(fā)成本。7.1高質(zhì)量軟件開發(fā)的基本方法(4)軟件測試
軟件測試(SoftwareTesting)是一種實際輸出與預(yù)期輸出之間審核或者比較的過程。測試與評審的主要區(qū)別是前者要運行軟件而后者不必執(zhí)行軟件。(5)軟件質(zhì)量保證
軟件質(zhì)量保證的目的是提供一種有效的人員組織形式和管理方法,通過客觀地檢查和監(jiān)控“過程質(zhì)量”與“產(chǎn)品質(zhì)量”,從而實現(xiàn)持續(xù)地改進(jìn)質(zhì)量。軟件質(zhì)量保證小組在項目開始時就一起參與建立計劃、標(biāo)準(zhǔn)和過程。7.1高質(zhì)量軟件開發(fā)的基本方法7.2代碼規(guī)范7.2.1代碼規(guī)范的重要性每一個高質(zhì)量代碼的背后,一定存在著一份優(yōu)秀的代碼規(guī)范。代碼規(guī)范是針對特定編程語言約定的一系列規(guī)則,包括開發(fā)約定、編程實踐、編程原則和最佳實踐等。代碼規(guī)范的重要性體現(xiàn)在以下幾個方面:
(1)促進(jìn)團(tuán)隊合作
(2)有效減少軟件缺陷數(shù)量、降低維護(hù)成本
(3)有助于代碼審查
(4)有助于程序員自身的成長代碼規(guī)范7.2.2常見的代碼規(guī)范代碼規(guī)范的制定往往包含命名規(guī)則、格式、控制語句、面向?qū)ο缶幊蹋∣OP)規(guī)約、集合處理、并發(fā)處理、注釋、異常處理、日志、數(shù)據(jù)庫相關(guān)規(guī)約等多個方面,部分可能的代碼規(guī)范。
1)命名規(guī)范①類名使用UpperCamelCase風(fēng)格(大駝峰形式)。例如TonyHall、XmlService、TcpUdpDeal,避免使用tonyHall、XMLService、TCPUDPDeal。②方法名、參數(shù)名、成員變量、局部變量都統(tǒng)一使用lowerCamelCase風(fēng)格(小駝峰形式)。例如localInput、getMessage()、outputUserId。7.2代碼規(guī)范③常量命名全部大寫,單詞間用下劃線隔開。例如MAX_USER_COUNT。④抽象類命名使用Abstract或Base開頭;異常類命名使用Exception結(jié)尾;測試類命名以它要測試的類的名稱開始,以Test結(jié)尾。⑤包名統(tǒng)一使用小寫,點分隔符之間有且僅有一個自然語義的英語單詞。例如com.baidu.map.util。⑥如果使用到了設(shè)計模式,建議在類名中體現(xiàn)出具體模式,有利于代碼閱讀者快速理解架構(gòu)設(shè)計思想。例如ProductFactory(工廠模式)、DataObserver(觀察者模式)。
7.2代碼規(guī)范2)格式規(guī)范①大括號的使用約定。如果是大括號內(nèi)為空,則寫成{}即可,不需要換行;如果是非空代碼塊則:左大括號前不換行;左大括號后換行;右大括號前換行;右大括號后還有else等代碼則不換行;右大括號后為空必須換行。②if/for/while/switch/do等保留字與左右括號之間必須加空格。③任何運算符左右必須加一個空格。運算符包括賦值運算符、邏輯運算符、加減乘除符號等。④代碼塊縮進(jìn)4個空格。⑤單行字符數(shù)不超過120個,超出需要換行,換行時相對上一行縮進(jìn)4個空格。⑥方法參數(shù)在定義和傳入時,多個參數(shù)逗號后邊必須加空格。7.2代碼規(guī)范(3)OOP規(guī)范(針對Java編程語言)①避免通過一個類的對象引用訪問此類的靜態(tài)變量或靜態(tài)方法,直接用類名訪問即可。②所有的覆寫方法,必須加@Override注解。③所有的相同類型的包裝類對象之間值的比較,全部使用equals方法比較。④構(gòu)造方法里面禁止加入任何業(yè)務(wù)邏輯,如果有初始化邏輯,放在init方法中。⑤類成員與方法訪問控制從嚴(yán):a.如果不允許外部直接通過new來創(chuàng)建對象,構(gòu)造方法必須是private。b.類非static成員變量并且與子類共享,必須是protected。c.類非static成員變量并且僅在本類使用,必須是private。d.類static成員變量如果僅在本類使用,必須是private。e.若是static成員變量,必須考慮是否為final。f.類成員方法只供類內(nèi)部調(diào)用,必須是private。g.類成員方法只對繼承類公開,那么限制為protected。7.2代碼規(guī)范(4)控制語句規(guī)范①在一個switch塊內(nèi),每個case或者通過break/return來終止,或者利用注釋說明程序?qū)⒗^續(xù)執(zhí)行到哪一個case為止;在每個switch塊內(nèi),都必須包含一個default語句并且放在最后,即使該語句后沒有代碼。②在if/else/for/while/do語句中必須使用大括號,即使只有一行代碼,避免使用下面的形式:if(condition)statements。③循環(huán)體中的語句要考量性能,以下操作盡量移至循環(huán)體外處理,如定義對象、變量、獲取數(shù)據(jù)庫連接、不必要的try-catch操作。④當(dāng)一個條件判斷(if、while)比較復(fù)雜,請寫好注釋。⑤盡量少采用取反邏輯運算符。取反邏輯不利于快速理解。例如使用if(x<365)來表達(dá)x小于365,避免使用if(!(x>=365))。7.2代碼規(guī)范(5)注釋規(guī)范(針對Java編程語言)①類、類屬性、類方法的注釋必須使用/*內(nèi)容*/格式。②所有的抽象方法(包括接口中的方法)必須要注釋、除了返回值、參數(shù)、異常說明外,還必須指出該方法做什么事情,實現(xiàn)什么功能。③方法內(nèi)部單行注釋,在被注釋語句上方另起一行,使用//注釋。方法內(nèi)部多行注釋使用/**/注釋,注意與代碼對齊。④所有的枚舉類型字段必須要有注釋,說明每個數(shù)據(jù)項的用途。⑤代碼修改的同時,注釋也要進(jìn)行相應(yīng)的修改。⑥謹(jǐn)慎注釋掉代碼。⑦注釋力求精簡準(zhǔn)確、表達(dá)到位,避免過多過濫的注釋。7.2代碼規(guī)范7.2.3代碼重構(gòu)代碼重構(gòu)通常是指在不改變代碼對外表現(xiàn)的情況下,修改代碼的內(nèi)部功能特征,從而改善軟件質(zhì)量,使程序的設(shè)計模式和架構(gòu)更趨合理,更容易被理解,提高軟件的可擴(kuò)展性和可維護(hù)性。很多人認(rèn)為重構(gòu)浪費時間,影響項目進(jìn)度,其實重構(gòu)不僅可以讓代碼更加健壯,而且從長遠(yuǎn)來看,還可以加快項目進(jìn)度。7.2代碼規(guī)范(1)以查詢?nèi)〈R時變量:圖7-1以查詢?nèi)〈R時變量7.2代碼規(guī)范(2)搬移函數(shù)或字段:圖7-2搬移函數(shù)或字段7.2代碼規(guī)范(3)提煉類:圖7-3提煉類7.2代碼規(guī)范(4)以常量取代字面數(shù)值:圖7-4以常量取代字面數(shù)值7.2代碼規(guī)范(5)簡化嵌套條件表達(dá)式:圖7-5簡化嵌套條件表達(dá)式7.2代碼規(guī)范(6)使用異常替換返回錯誤碼:圖7-6使用異常替換返回錯誤碼7.27.3軟件測試GlenfordJ·Myers在《軟件測試的藝術(shù)》中提出了關(guān)于軟件測試的多個重要觀點,對該領(lǐng)域產(chǎn)生了深遠(yuǎn)的影響:(1)測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程。(2)好的測試方案在于它能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤。(3)成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。(4)測試并不僅僅是為了找出錯誤。(5)沒有發(fā)現(xiàn)錯誤的測試也是有價值的。
7.3.1軟件測試介紹軟件測試為了盡可能發(fā)現(xiàn)軟件中的錯誤,提高軟件產(chǎn)品的質(zhì)量,在軟件測試的實踐中應(yīng)把握以下基本測試原則:(1)測試用例中的一個必需部分是對預(yù)期輸出或結(jié)果進(jìn)行定義。(2)程序員應(yīng)當(dāng)避免測試自己編寫的程序。(3)編寫軟件的組織不應(yīng)當(dāng)測試自己編寫的軟件。(4)應(yīng)當(dāng)徹底檢查每個測試的執(zhí)行結(jié)果。7.3軟件測試(5)測試用例的編寫不僅應(yīng)當(dāng)根據(jù)有效和預(yù)期的輸入情況,而且也應(yīng)當(dāng)根據(jù)無效和未預(yù)料到的輸入情況。(6)檢查程序是否“未做其應(yīng)該做的”僅是測試的一半,測試的另一半是檢查程序是否“做了其不應(yīng)該做的”。(7)應(yīng)避免測試用例用后即棄,除非軟件本身是一個一次性的軟件。(8)計劃測試工作時不應(yīng)默許假定不會發(fā)現(xiàn)錯誤。(9)程序某部分存在更多錯誤的可能性,與該部分已發(fā)現(xiàn)錯誤的數(shù)量成正比。7.3軟件測試廣義的軟件測試必須貫穿在軟件生命周期的始終,測試對象應(yīng)該包括軟件設(shè)計開發(fā)的各個階段的內(nèi)容。狹義的軟件測試的分類,即開發(fā)階段的測試和程序測試,如下:(1)按照開發(fā)階段劃分
①單元測試
②集成測試
③系統(tǒng)測試
④確認(rèn)測試
⑤驗收測試
7.3.2軟件測試分類7.3軟件測試(2)按照測試實施組織劃分
①開發(fā)方測試:也叫α測試
②用戶測試:也叫β測試
③第三方測試(3)按照測試與需求的關(guān)系劃分
①功能測試
②非功能測試7.3軟件測試(4)按照是否需要運行程序劃分
①靜態(tài)測試
②動態(tài)測試(5)按照測試技術(shù)劃分
①玻璃盒測試
②黑盒測試
③灰盒測試7.3軟件測試為了節(jié)省人力、時間或硬件資源,提高測試效率,自動化測試往往是十分必要的。但是自動化測試不適用于一些特殊定制型項目、周期很短的項目以及包含有復(fù)雜業(yè)務(wù)規(guī)則的項目,或者其涉及物理交互的部分。目前對自動化測試?yán)斫膺€存在如下誤區(qū):(1)自動化測試可以完成一切測試工作。(2)測試工具可適用于所有的測試。(3)測試工具能使工作量大幅降低。(4)測試工具能實現(xiàn)百分百的測試覆蓋率。(5)自動化測試工具容易使用。
7.3.3自動化測試7.3軟件測試自動化測試工具有很多,其大致分類如下:(1)負(fù)載壓力測試工具(2)功能測試工具(3)玻璃盒測試工具(4)網(wǎng)絡(luò)測試工具(5)測試管理工具
7.3軟件測試測試模型將測試活動進(jìn)行抽象,明確了測試與開發(fā)之間的關(guān)系,是軟件測試管理的重要依據(jù)。(1)V模型
7.3.4軟件測試模型單元測試集成測試系統(tǒng)測試驗收測試編碼詳細(xì)設(shè)計概要設(shè)計需求分析圖7-7V模型7.3軟件測試(2)W模型圖7-8W模型開發(fā)組工作測試組工作詳細(xì)設(shè)計測試編碼實現(xiàn)單元測試集成測試系統(tǒng)測試驗收測試概要設(shè)計測試需求測試模塊集成系統(tǒng)構(gòu)建系統(tǒng)安裝詳細(xì)設(shè)計概要設(shè)計需求分析7.3軟件測試(3)H模型圖7-9H模型7.3軟件測試(1)黑盒測試
①等價類劃分法等價類劃分主要解決如何選擇適當(dāng)?shù)臄?shù)據(jù)子集來代表整個數(shù)據(jù)集的問題,通過降低測試用例的數(shù)量去實現(xiàn)合理的“覆蓋”,以此來發(fā)現(xiàn)更多的軟件缺陷。例如:一個基于整數(shù)運算的簡單計算器程序。當(dāng)需要測試它是否能正確運行時,如果程序能夠正確地計算“1+1”和“2+3”的和,那么是否還有必要測試“8+9”的和,或者“80000+90000”的和呢?
7.3.5黑盒和玻璃盒測試7.3軟件測試②邊界值分析法長期的測試經(jīng)驗告訴我們,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入或輸出范圍的內(nèi)部。邊界值(BoundaryValues)分析法就是對輸入或輸出的邊界值進(jìn)行測試的一種黑盒測試方法。7.3軟件測試邊界值分析法與等價類劃分的區(qū)別為:a.邊界值分析不是從某等價類中任意選擇一個作為代表,而是使這個等價類的每個邊界都要作為測試條件。b.邊界值分析不僅要考慮輸入條件,還要考慮輸出空間產(chǎn)生的邊界情況。例如程序包含一個輸入值,其合法取值是從1到10的數(shù)字,那么顯然邊界值測試會取0和11這兩個不合法的數(shù)字,以及1和10這兩個“剛好”合法的數(shù)字,來驗證位于輸入邊界附近的數(shù)值會不會被系統(tǒng)接受。7.3軟件測試(2)玻璃盒測試玻璃盒測試關(guān)注的是測試用例執(zhí)行的程度或覆蓋程序邏輯結(jié)構(gòu)的程度。玻璃盒測試的測試方法有代碼檢查、靜態(tài)分析法、邏輯覆蓋法、基本路徑測試法、符號測試等。邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋。publicvoidRoutine(intA,intB,intX){ if(A>1&&B==0) X=X+B; if(A==2||X>1) X=X*A;}7.3軟件測試①語句覆蓋最初的邏輯覆蓋想法是將程序中的每條語句至少執(zhí)行一次,即語句覆蓋。這雖然是玻璃盒測試中較弱的覆蓋標(biāo)準(zhǔn),但是同樣也具備了初步檢查出錯誤的能力。要實現(xiàn)語句覆蓋,上述程序只需要一個測試用例,(A=5,B=0,X=8)就可以遍歷到每一條語句。②判定覆蓋判定覆蓋(也稱分支覆蓋)相對語句覆蓋而言是較強(qiáng)一些的邏輯覆蓋。判定覆蓋要求必須編寫足夠的測試用例,使得每一個判斷都至少有一個為真和為假的輸出結(jié)果。也就是說,每條判定路徑都必須至少遍歷一次。在小程序Routine中,滿足判定覆蓋的兩個測試用例可以是(A=3,B=0,X=3)和(A=1,B=0,X=1)。7.37.4測試驅(qū)動開發(fā)TDD
測試驅(qū)動開發(fā)(TestDrivenDevelopment,簡稱TDD)是敏捷開發(fā)中的一項核心實踐和技術(shù)。測試驅(qū)動開發(fā)的基本思想就是在開發(fā)功能代碼之前,先編寫測試代碼,然后只編寫使測試通過的功能代碼,從而以測試來驅(qū)動整個開發(fā)過程的進(jìn)行。這種開發(fā)方式與傳統(tǒng)開發(fā)方式剛好相反。在明確要開發(fā)某個功能后,TDD首先要思考如何對這個功能進(jìn)行測試,并快速編寫出針對該功能的測試代碼,測試代碼只定義這個功能的外部接口,而非具體的實現(xiàn)細(xì)節(jié)。7.4.1TDD基本概念測試驅(qū)動開發(fā)TDD7.4.2TDD實施步驟開始成功增加一個測試運行一個測試改變一些代碼運行這個測試失敗失敗成功圖7-10TDD開發(fā)過程7.4測試驅(qū)動開發(fā)TDD7.4.3基于單元測試的TDD實例(Java)需求描述:通過一個矩形的長和寬來計算其面積和周長。(1)打開Eclipse。(2)創(chuàng)建RectangleTest類。publicclassRectangleTestextendsjunit.framework.TestCase{}7.4測試驅(qū)動開發(fā)TDD(3)根據(jù)需求描述,在RectangleTest中創(chuàng)建矩形對象,分別添加計算矩形面積和周長的測試方法,以及長和寬分別為2和3的具有正確輸入和輸出的測試用例。publicclassRectangleTestextendsjunit.framework.TestCase{Rectanglerectl=newRectangle();publicvoidtestArea(){assertEquals(6,rectl.Area(2,3));}publicvoidtestPerimeter(){assertEquals(10,rectl.Perimeter(2,3));}}7.4測試驅(qū)動開發(fā)TDD(4)運行測試用例,編譯失敗,錯誤提示為缺少Rectangle類的定義。于是增加Rectangle類的定義,創(chuàng)建Rectangle.java文件。publicclassRectangle{publicintArea(intlength,intwidth){return0;}publicintPerimeter(intlength,intwidth){return0;}}(5)編譯成功,但是運行這個程序,斷言顯示測試用例失敗,因為計算面積和周長的方法的返回值始終為0。7.4測試驅(qū)動開發(fā)TDD(6)先“傻瓜式”地修改兩個函數(shù)的返回值,改為return6和return10。重新編譯、運行,斷言結(jié)果為通過。publicclassRectangle{publicintArea(intlength,intwidth){return6;}publicintPerimeter(intlength,intwidth){return10;}}7.4測試驅(qū)動開發(fā)TDD(7)在RectangleTest中,增加測試用例數(shù)據(jù)。publicclassRectangleTestextendsjunit.framework.Testcase{Rectanglerectl=newRectangle();publicvoidtestArea(){assertEquals(6,rectl.Area(2,3));assertEquals(2,rectl.Area(1,2));}publicvoidtestPerimeter(){assertEquals(10,rectl.Perimeter(2,3));assertEquals(6,rectl.Perimeter(1,2));}}7.4測試驅(qū)動開發(fā)TDD(8)編譯成功,但是運行這個程序,斷言顯示新增加的測試用例失敗。(9)重構(gòu)Rectangle類的Area和Perimeter函數(shù)如下,重新編譯、運行,運行通過。publicclassRectangle{publicintArea(intlength,intwidth){returnlength*width;}publicintperimeter(intlength,intwidth){return2*(length+width);}}7.4測試驅(qū)動開發(fā)TDD(10)在RectangleTest中,利用邊界值增加新的測試用例。publicclassRectangleTestextendsjunit.framwork.TestCase{Rectanglerectl=newRectangle();publicvoidtestArea(){assertEquals(6,rectl.Area(2,3));assertEquals(2,rectl.Area(1,2));assertEquals(0,rectl.Area(0,1));assertEquals(0,rectl.Area(1,0));assertEquals(0,rectl.Area(0,0));assertEquals(0,rectl.Area(-1,2));assertEquals(0,rectl.Area(-1,0));assertEquals(0,rectl.Area(-1,-1));assertEquals(0,rectl.Area(0,-1));}7.4測試驅(qū)動開發(fā)TDD(10)在RectangleTest中,利用邊界值增加新的測試用例。publicvoidtestPerimeter(){assertEquals(6,rectl.Perimeter(2,3));assertEquals(2,rectl.Perimeter(1,2));assertEquals(0,rectl.Perimeter(0,1));assertEquals(0,rectl.Perimeter(1,0));assertEquals(0,rectl.Perimeter(0,0));assertEquals(0,rectl.Perimeter(-1,2));assertEquals(0,rectl.Perimeter(-1,0));assertEquals(0,rectl.Perimeter(-1,-1));assertEquals(0,rectl.Perimeter(0,-1));}}7.4測試驅(qū)動開發(fā)TDD(11)編譯成功,但是運行這個程序,斷言顯示新的測試用例失敗。(12)根據(jù)測試用例的數(shù)據(jù),重構(gòu)Rectangle類的Area和Perimeter方法,如下:publicclassRectangle{publicintArea(intlength,intwidth){if((length>0)&&(width>0)){returnlength*width;}return0;}publicintPerimeter(intlength,intwidth){if((length>0)&&(width>0)){return2*(length+width);}return0;}}(13)重新編譯,運行所有測試用例,全部運行通過。7.47.5集成7.5.1軟件集成軟件集成是指根據(jù)軟件需求,把現(xiàn)有軟件模塊進(jìn)行組合,以較低的成本、較高的效率實現(xiàn)目的的技術(shù)。軟件集成是軟件復(fù)用的成功實踐和技術(shù)應(yīng)用之一。圖7-11某產(chǎn)品模塊圖集成(1)自頂向下的集成自頂向下的集成從頂層模塊開始,采用同設(shè)計順序一樣的思路對被測系統(tǒng)進(jìn)行測試。自上而下按照深度或者廣度優(yōu)先策略,對各個模塊一邊組裝一邊進(jìn)行測試。若圖7-11中的產(chǎn)品,一種可能的自頂向下的次序是M1、M2、M3、M4、M5、M6和M7。例如,對M1編碼并用作為存根實現(xiàn)的M2、M3和M4模塊來測試M1。(2)自底向上的集成自底向上的集成從依賴性最小
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 2025年液壓電磁閥項目規(guī)劃申請報告模式
- 2025年Γ-FE2O3項目立項申請報告
- 2024-2025學(xué)年延安市宜川縣數(shù)學(xué)三年級第一學(xué)期期末調(diào)研試題含解析
- 2025年多協(xié)議通信適配器項目規(guī)劃申請報告模板
- 2024-2025學(xué)年夏邑縣三年級數(shù)學(xué)第一學(xué)期期末學(xué)業(yè)水平測試模擬試題含解析
- 2024-2025學(xué)年文山壯族苗族自治州丘北縣三年級數(shù)學(xué)第一學(xué)期期末復(fù)習(xí)檢測模擬試題含解析
- 2024-2025學(xué)年濰坊市寒亭區(qū)三上數(shù)學(xué)期末綜合測試模擬試題含解析
- 成都2024年四川成都市教育局所屬事業(yè)單位招聘高層次人才13人筆試歷年典型考點(頻考版試卷)附帶答案詳解
- 關(guān)于工程建筑實習(xí)報告合集九篇
- 員工工作自我鑒定15篇
- 《智能網(wǎng)聯(lián)汽車智能傳感器測試與裝調(diào)》電子教案
- 羽毛球歷史-探究羽毛球的歷史和文化
- 2024年單位內(nèi)部治安保衛(wèi)制度范本(四篇)
- GB/T 11017.1-2024額定電壓66 kV(Um=72.5 kV)和110 kV(Um=126 kV)交聯(lián)聚乙烯絕緣電力電纜及其附件第1部分:試驗方法和要求
- 八年級語文上冊-成語運用練習(xí)-試題
- 華為任職資格體系介紹
- 主持人培訓(xùn)課件
- 專題06手拉手模型(原卷版+解析)
- HY/T 0273.2-2023海洋災(zāi)害風(fēng)險評估和區(qū)劃技術(shù)導(dǎo)則第2部分:海浪
- Pep小學(xué)英語六年級上冊教案-全冊
- 北師大版二年級數(shù)學(xué)下冊全冊10套試卷(附答案)
評論
0/150
提交評論