華為解決方案測試面試_第1頁
華為解決方案測試面試_第2頁
華為解決方案測試面試_第3頁
華為解決方案測試面試_第4頁
華為解決方案測試面試_第5頁
已閱讀5頁,還剩18頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、精選優(yōu)質(zhì)文檔-傾情為你奉上華為解決方案測試面試篇一:華為測試面試題華為測試面試題1怎么來設計測試方案根據(jù)測試需求(包括功能需求和非功能性需求),識別測試要點,識別測試環(huán)境要求,安排測試輪次,根據(jù)項目計劃和開發(fā)計劃做整體的測試安排。被測試的特性:通過對需求規(guī)格說明書進行分析,列出本次測試需要進行測試的各部分特性(如要測試的功能需求、性能需求、安全性需求等等);不被測試的特性:由于資源、進度等方面原因,本次測試不列入測試范圍的特性; 測試組網(wǎng)圖:進行本次系統(tǒng)測試所需要的軟硬件設備、配置數(shù)據(jù)已及相互間的邏輯、物理連接。今后測試執(zhí)行時需要依據(jù)這個組網(wǎng)圖來進行環(huán)境的搭建。 2如果給你一個B/S系統(tǒng)你怎么

2、來進行測試此題答案還可用于回答測試流程,測試流程題亦可參考15題。閱讀系統(tǒng)需求,充分理解需求,記錄問題,并與項目需求人員充分溝通。編寫測試需求,包括系統(tǒng)功能和非功能測試要點、測試類型、測試進度質(zhì)量要求等。制定測試計劃,包括熟悉測試業(yè)務、設計測試用例、執(zhí)行測試用例、進行測試小結、編寫測試報告,任務顆粒度一般應小于5人天編寫測試用例,根據(jù)測試方案設計用例,即便沒有明確的性能和安全測試要求,也應識別進行此兩項測試。執(zhí)行軟件測試。進行測試小結,如果測試持續(xù)時間較長,每個版本間隙總結本輪測試。 編寫測試報告,總結測試過程,匯總度量數(shù)據(jù)。3怎么進行工作流的測試把握需求,找準結點,理清流程,畫出流轉(zhuǎn)圖,弄清

3、節(jié)點間的數(shù)據(jù)流轉(zhuǎn),設計測試用例的時候必須覆蓋所有可能的流程。工作流:如果問到有沒有做過,根據(jù)對工作流的了解情況回答,如果比較了解,可以把參與的某個項目中說上一些有工作流的,如果不是很了解就說沒有做過,但是學習過相關知識。4做性能測試的時候都需要關注哪些參數(shù)并發(fā)訪問量,服務器響應時間(最小、平均、最大)并發(fā)性能測試的過程是一個負載測試和壓力測試的過程,即逐漸增加負載,直到系統(tǒng)的瓶頸或者不能接收的性能點,通過綜合分析交易執(zhí)行指標和資源監(jiān)控指標來確定系統(tǒng)并發(fā)性能的過程。負載測試(Load Testing)是確定在各種工作負載下系統(tǒng)的性能,目標是測試當負載逐漸增加時,系統(tǒng)組成部分的相應輸出項,例如通過

4、量、響應時間、CPU負載、內(nèi)存使用等來決定系統(tǒng)的性能。負載測試是一個分析軟件應用程序和支撐架構、模擬真實環(huán)境的使用,從而來確定能夠接收的性能過程。壓力測試(Stress Testing)是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點,來獲得系統(tǒng)能提供的最大服務級別的測試。疲勞測試是采用系統(tǒng)穩(wěn)定運行情況下能夠支持的最大并發(fā)用戶數(shù),持續(xù)執(zhí)行一段時間業(yè)務,通過綜合分析交易執(zhí)行指標和資源監(jiān)控指標來確定系統(tǒng)處理最大工作量強度性能的過程。 疲勞強度測試可以采用工具自動化的方式進行測試,也可以手工編寫程序測試,其中后者占的比例較大。一般情況下以服務器能夠正常穩(wěn)定響應請求的最大并發(fā)用戶數(shù)進行一定時間的疲勞測試,

5、獲取交易執(zhí)行指標數(shù)據(jù)和系統(tǒng)資源監(jiān)控數(shù)據(jù)。如出現(xiàn)錯誤導致測試不能成功執(zhí)行,則及時調(diào)整測試指標,例如降低用戶數(shù)、縮短測試周期等。還有一種情況的疲勞測試是對當前系統(tǒng)性能的評估,用系統(tǒng)正常業(yè)務情況下并發(fā)用戶數(shù)為基礎,進行一定時間的疲勞測試。大數(shù)據(jù)量測試可以分為兩種類型:針對某些系統(tǒng)存儲、傳輸、統(tǒng)計、查詢等業(yè)務進行大數(shù)據(jù)量的獨立數(shù)據(jù)量測試;與壓力性能測試、負載性能測試、疲勞性能測試相結合的綜合數(shù)據(jù)量測試方案。大數(shù)據(jù)量測試的關鍵是測試數(shù)據(jù)的準備,可以依靠工具準備測試數(shù)據(jù)。5客戶沒給性能指數(shù),怎么開展性能測試如果客戶沒有提出明確的性能指標,可以按照慣例和經(jīng)驗設置,需要和PM協(xié)商,一般由PM確認,QA負責給出

6、建議。舉例說一個Server端程序,要求峰值時CPU和MEM消耗在75以下,而一個頁面的訪問響應時間一般認為用戶的忍耐時間是35秒以內(nèi),這些要參考實際的應用來確定用戶規(guī)模、操作頻率、同時在線數(shù)等。6有沒有做過接口測試,是如何做的通過編寫測試程序, 獲得接口指針, 逐個調(diào)用接口函數(shù)驗證其正確性, 及失敗操作7測試過程中是如何來保證軟件質(zhì)量的測試用例編寫完畢后要加強評審的力度,確保測試用例覆蓋所有需求點執(zhí)行測試過程中注意做小結檢查覆蓋情況、審視所提缺陷質(zhì)量,復測時應注意相關模塊的測試測試時間寬裕的話可以做交叉測試,用以確保測試質(zhì)量。8.測試方案都寫什么內(nèi)容1概述2被測對象分析3應測試的特性4不被測

7、試的特性5總體設計方法6測試模型測試組網(wǎng)圖結構/對象關系圖測試原理操作規(guī)程7測試需求環(huán)境需求被測對象需求測試工具需求測試代碼需求數(shù)據(jù)需求其它需求8測試設計工具設計測試代碼設計用例設計設計原則測試項目9.附錄(測試方案要求根據(jù)SRS上的每個需求點設計出包括需求點簡介,測試思路和詳細測試方法三部分的方案) 以往華為測試方案 目錄如下:第1章 技術方案 測試需求描述 測試類型分析 測試內(nèi)容 缺陷分類 缺陷級別第2章 SOW及規(guī)格的應答 測試需求應答 交付件應答 軟件交付件應答 非軟件交付件應答 項目里程碑項目完成時間應答 質(zhì)量目標應答 驗收標準應答 限制應答 合作供應商人員組織應答 硬件設備應答 合

8、作項目開發(fā)場地應答第3章 類似項目成功案例第4章 項目詳細工作計劃第5章 項目估算9測試方案和測試計劃的區(qū)別測試方案是技術性的;測試計劃更多是管理性的。測試計劃主要要考慮測試的技術可行性、關鍵技術、資源投入、進度安排、風險管理、配置管理、輸入輸出等。測試計劃更多地供高層 管理者決策時做參考;同時對后續(xù)測試工作開展起指導作用。在一些小項目中,可能只需要一個測試方案,測試計劃內(nèi)容相對較少,可以與測試方案合并進行;而一些大項目中,也許要設計數(shù)十個測試方案,這就需要一個提綱挈領的東西了,這就是測試計劃的作用。10.測試用例是根據(jù)什么寫的系統(tǒng)測試用例根據(jù)需求和設計編寫(華為的SDV測試用例是根據(jù)測試方案

9、和測試策略來編寫的)11是怎么來設計測試用例的?答:先熟悉系統(tǒng)需求,把握測試要點,設計用例的原則首先是要覆蓋每個需求點,可以通過填寫需求跟蹤矩陣來保證覆蓋。黑盒測試的測試用例設計方法:等價類劃分法、 邊界值分析法、錯誤推測法、因果圖。12有沒有測過手機終端的項目根據(jù)實際情況回答,如果沒有測試過,可以回答,公司有過類似業(yè)務。 手機終端測試13.對測試工作的認識答:軟件測試是軟件開發(fā)過程的重要組成部分,是用來確認一個程序的品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測試就是在軟件投入運行前,對軟件需求分析、設計規(guī)格說明和編碼的最終復審,是軟件質(zhì)量保證的關鍵步驟。軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序

10、的過程。軟件測試在軟件生存期中橫跨兩個階段:通常在編寫出每一個模塊之后就對它做必要的測試(稱為單元測試)。編碼和單元測試屬于軟件生命周期中的同一個階段。在結束這個階段后對軟件系統(tǒng)還要進行各種綜合測試,這是軟件生命周期的另一個獨立階段,即測試階段。華為獨立外包測試一般包括ST(系統(tǒng)測試)和SDV(詳細設計驗證)兩個階段。14缺陷是怎么管理的答:我們采用了Rational ClearQuest來管理缺陷。測試人員執(zhí)行測試,發(fā)現(xiàn)缺陷,錄入CQ,要求填寫項目名稱、子系統(tǒng)名稱、模塊名稱、缺陷標題、缺陷描述(描述場景、現(xiàn)象)、缺陷級別、提出人等。狀態(tài):已提交。項目經(jīng)理或開發(fā)組長確認缺陷后分配給開發(fā)人員,狀

11、態(tài):已分配。開發(fā)人員修復缺陷完成后,將修復缺陷所花費的時間填寫的Schedule中,缺陷的產(chǎn)生原因填寫在備注中,因采用UCM模式,所有造成該缺陷的錯誤代碼文件,在UCM視圖中可以統(tǒng)計。狀態(tài):已處理。測試人員復測,如缺陷已經(jīng)修復,則關閉缺陷,狀態(tài):已關閉。如缺陷仍然存在,則修改狀態(tài)為已分配。當缺陷存在爭議時,開發(fā)組長或開發(fā)人員可以申請否決,由項目經(jīng)理、技術經(jīng)理、測試負責人、相關開發(fā)人員和測試人員共同決定缺陷是否可以否決。狀態(tài):已申請否決、已否決。當前不能修復,或當前版本無法解決的缺陷可以申請延期,狀態(tài):已申請延期、已延期。15介紹一下測試流程答:項目啟動后進行需求培訓,測試人員盡早的參與到項目需

12、求的培訓和評審,也就是測試工作應該從需求階段開始介入。項目經(jīng)理編寫項目計劃,開發(fā)人員產(chǎn)出需求規(guī)格說明書,這時測試組長就要根據(jù)項目計劃開始編寫測試計劃,其中包括人員,軟件硬件資源,測試點,進度安排和風險識別等內(nèi)容。測試計劃編寫完成后需要進行評審,參與人員有項目經(jīng)理,測試經(jīng)理。測試組長需要根據(jù)評審意見修改測試計劃,并上傳到CC上,由配置管理員管理。待開發(fā)人員把需求規(guī)格說明書歸納好并打了基線,測試組長開始組織測試成員編寫測試方案,測試方案編寫完成后也需要進行評審,評審人員包括項目經(jīng)理,開發(fā)人員,測試經(jīng)理,測試組長,測試成員;測試組長組織測試成員修改測試方案,直到評審通過后才進入下個階段編寫測試用例。

13、測試用例是根據(jù)測試方案來編寫的,通過測試方案階段,測試人員對整個系統(tǒng)需求有了詳細的理解。這時開始編寫用例才能保證用例的可執(zhí)行和對需求的覆蓋。測試用例需要包括測試項,用例級別,預置條件,操作步驟和預期結果。其中操作步驟和預期結果需要編寫詳細和明確。測試用例應該覆蓋測試方案,而測試方案又覆蓋了測試需求點,這樣才能保證客戶需求不遺漏。同樣,測試用例也需要通過開發(fā)人員,測試人員的評審,測試組長也需要組織測試人員對測試用例進行修改,直到評審通過。在我們編寫測試用例的階段,開發(fā)人員基本完成代碼的編寫,同時完成單元測試。提交測試中心后根據(jù)測試計劃進度安排,測試組長組織進行多輪次的測試,每輪測試完成后測試組長

14、需要編寫測試報告,其中包括用例執(zhí)行通過情況,缺陷分布情況,缺陷產(chǎn)生原因,測試中的風險等等,這時測試人員就修改增加測試用例。待到開發(fā)修改完bug并轉(zhuǎn)來新的測試版本,測試人員開始進行第二輪的系統(tǒng)測試,首先回歸完問題單,再繼續(xù)進行測試,編寫第二輪的測試報告,如此循環(huán)下去,直到系統(tǒng)測試結束。16一個關于測試方案評審的分歧我們原本的流程是完成方案包括用例后進行評審,華為的建議是,在測試方案(即測試人員總結出測試重點等)之后,即進行評審,不能等全部用例完成。關于版本缺陷密度的問題:問有沒有統(tǒng)計。如果CQ中正常登記的話,是可以利用工具統(tǒng)計出來。CQ還可以根據(jù)需要定制查詢。關于測試提交標準:我講了公司的標準,

15、他說客戶也會有自己的標準。我回復說是可以依據(jù)客戶標準進行調(diào)整,17Unix系統(tǒng)熟識,運用Informix 數(shù)據(jù)庫。ls 列出指定目錄下的文件,缺省目錄為當前目錄 ./pwd 顯示當前的工作目錄cd 回到注冊進入時的目錄 cd /tmp 進入 /tmp 目錄 cd ./ 進入上級目錄 mkdir -m 模式 -p 目錄名 建立目錄mkdir tmp 在當前目錄下建立子目錄 tmpmkdir -m 777 /tmp/abc 用所有用戶可讀可寫可執(zhí)行的存取模式建立目錄 /tmp/aaa ,存取模式參看命令 chmodmkdir -p /tmp/a/b/c 建立目錄 /tmp/a/b/c ,若不存在目

16、錄 /tmp/a及/tmp/a/b 則建立之mv -f -i 文件1 文件2. 目標 將文件移動至目標,若目標是文件名,則相當于文件改名rm -f -i 文件.或 rm -r -f -i 目錄名. 文件 用來刪除文件或目錄cmp -l -s 文件1 文件2 比較兩個文件。diff -be 文件1 文件2 比較兩個文本文件,將不同的行列出來pack 文件. 將指定文件轉(zhuǎn)儲為壓縮格式,文件名后加 .z , 文件存取模式,訪問時間,修改時間等均不變pcat 文件. 顯示輸出壓縮文件unpack 文件. 將壓縮后的文件解壓后轉(zhuǎn)儲為壓縮前的格式vi -wn -R 文件.vi 是一個基于行編輯器 ex 上

17、的全屏幕編輯器,可以在vi 中使用 ex,ed的全部命令,vi選項中 -wn 指將編輯窗口大小置為n行,-R 為將編輯的文件置為只讀模式, vi 工作模式分為命令模式和輸入模式,一般情況下在命令模式下,可敲入vi命令,進入輸入模式下時可以編輯要編輯的文本,命令 a A i I o O cC s S R 可進入輸入模式,在輸入模式下按 ESC 鍵可推出輸入模式,回到命令模式,在命令模式中敲入: 命令,則可進入ex方式,在屏幕底部出現(xiàn)提示符 : 。篇二:求職華為經(jīng)歷軟件開發(fā)性格測試-機試-面試-offer去華為面試之前,就想著把這份經(jīng)歷寫下來,幫別人也幫自己。注冊簡歷:我很早就在華為網(wǎng)站上注冊了簡

18、歷,華為宣講會投的簡歷可有可無,網(wǎng)申必須要有。性格測試:華為有提前批,我就是跟著提前批一起做的性格測試,性格測試不難,但是不過是肯定不行的,不管什么崗位都要通過才行。性格測試大概三十分鐘,我的建議是不要想太多,誠實就好,如果前后矛盾,可能就過不了。如果不過的話,機試或者簡歷優(yōu)秀,還有重測的機會。機試:軟件機試一共三道題,總共600分,只要100分就夠了。第一題很簡單,基本都會,所以基本都會過。機試之前可以在華為OJ上好好練練,都沒問題。機試現(xiàn)場有技術人員,有問題他們也會指導,態(tài)度都很好。聽說硬件、結構都有機試,不過是上機答題,只有選擇和判斷,沒有參加,具體不了解。面試:研發(fā)類一共兩面,技術面和

19、綜合面(boss面),我所見到的面試官都很好,很和藹,一般就是自我介紹,然后談談項目,分別半小時左右,也有時間很長的,但是時間長短和結果關系不大。因為我是跨專業(yè),技術面沒有問我專業(yè)的問題,但是同行的專業(yè)對口的據(jù)說問的挺深入。hr反復強調(diào),面試官主要考察品質(zhì)和學習能力,技術面自我感覺不是很好,但是最后面試官說“我這里沒問題,你去等一下,待會會有人叫你”,瞬間輕松多了。然后吃了個華為的午餐,還不錯。下午的時候叫去綜合面。hr說的是,走到綜面,意味著已通過全部環(huán)節(jié),但是有些崗位也有先綜合面試,最后做性格測試的,所以說Hr的話也不是很靠譜。我遇到的面試官很和藹,看了簡歷,還有成績單,讓我說了下項目,聊

20、了一會兒就給我承諾過了。也有面試官說讓回去等消息的。ps:1. 面試官很可能會問簡歷上的東西,所以應確保真實2. 會就是會,不會就不會,面試官見的人太多,真誠一點好3. 技術面不過的話,還可以改崗位,再面試其他的崗位;綜面不過基本沒機會了另外,供應鏈和銷服的面試環(huán)節(jié)多些,有集體面試,英語測試等?,F(xiàn)場的工作人員很多,態(tài)度也很好,有問題及時問。offer:因為有了面試官的口頭承諾,面試完我是很放松的,但是面試完第三天卻收到一條疑似備胎的短信,驚出一身冷汗,難受了大半天,發(fā)誓說要去找更好的工作時候,又收到了正式的offer。所幸華為的效率還挺高的,不然我該失眠了。希望大家都找到好工作。篇三:20XX

21、華為軟件測試筆試題華為軟件測試筆試題試題一一、判斷題1軟件測試的目的是盡可能多的找出軟件的缺陷。(Y)2Beta 測試是驗收測試的一種。(Y)3驗收測試是由最終用戶來實施的。(N)4項目立項前測試人員不需要提交任何工件。(Y)5單元測試能發(fā)現(xiàn)約80%的軟件缺陷。(Y)6代碼評審是檢查源代碼是否達到模塊設計的要求。(N)7自底向上集成需要測試員編寫驅(qū)動程序。(Y)8負載測試是驗證要檢驗的系統(tǒng)的能力最高能達到什么程度。(N)9測試人員要堅持原則,缺陷未修復完堅決不予通過。(N)10代碼評審員一般由測試員擔任。(N)11我們可以人為的使得軟件不存在配置問題。(N)12集成測試計劃在需求分析階段末提交

22、。(N)二、選擇1軟件驗收測試的合格通過準則是:(ABCD)A 軟件需求分析說明書中定義的所有功能已全部實現(xiàn),性能指標全部達到要求。B 所有測試項沒有殘余一級、二級和三級錯誤。C 立項審批表、需求分析文檔、設計文檔和編碼實現(xiàn)一致。D 驗收測試工件齊全。2軟件測試計劃評審會需要哪些人員參加?(ABCD)A項目經(jīng)理BSQA 負責人C配置負責人D測試組3下列關于alpha 測試的描述中正確的是:(AD)Aalpha 測試需要用戶代表參加Balpha 測試不需要用戶代表參加Calpha 測試是系統(tǒng)測試的一種Dalpha 測試是驗收測試的一種4測試設計員的職責有:(BC)A制定測試計劃B設計測試用例C設

23、計測試過程、腳本D評估測試活動5軟件實施活動的進入準則是:(ABC)A需求工件已經(jīng)被基線化B詳細設計工件已經(jīng)被基線化C構架工件已經(jīng)被基線化D項目階段成果已經(jīng)被基線化三、添空1.軟件驗收測試包括: 正式驗收測試,alpha測試,beta測試。2.系統(tǒng)測試的策略有:功能測試,性能測試,可靠性測試,負載測試,易用性測試,強度測試,安全測試,配置測試,安裝測試,卸載測試,文擋測試,故障恢復測試,界面測試,容量測試,兼容性測試,分布測試,可用性測試,(有的可以合在一起,分開寫只要寫出15就滿分哦)3.設計系統(tǒng)測試計劃需要參考的項目文擋有:軟件測試計劃,軟件需求工件和迭代計劃。4.對面向過程的系統(tǒng)采用的集

24、成策略有:自頂向下,自底向上兩種。四、簡答(資料是搜集整理的,感謝前輩的解題)無1.區(qū)別階段評審的與同行評審同行評審目的:發(fā)現(xiàn)小規(guī)模工作產(chǎn)品的錯誤,只要是找錯誤;同行評審人數(shù):3-7人人員必須經(jīng)過同行評審會議的培訓,由SQA指導同行評審內(nèi)容:內(nèi)容小一般文檔 < 40頁, 代碼 < 500行同行評審時間:一小部分工作產(chǎn)品完成階段評審目的:評審模塊階段作品的正確性 可行性 及完整性階段評審人數(shù):5人左右評審人必須是專家 具有系統(tǒng)評審資格階段評審內(nèi)容: 內(nèi)容多,主要看重點階段評審時間: 通常是設置在關鍵路徑的時間點上!2.什么是軟件測試為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程3簡述集成測試的

25、過程系統(tǒng)集成測試主要包括以下過程:1. 構建的確認過程。2. 補丁的確認過程。3. 系統(tǒng)集成測試測試組提交過程。4. 測試用例設計過程。5. 測試代碼編寫過程。6. Bug的報告過程。7. 每周/每兩周的構建過程。8. 點對點的測試過程。9. 組內(nèi)培訓過程。4 怎么做好文檔測試1.仔細閱讀,跟隨每個步驟,檢查每個圖形,嘗試每個示例。2,。檢查文檔的編寫是否滿足文檔編寫的目的3.內(nèi)容是否齊全,正確4.內(nèi)容是否完善 5.標記是否正確5 白盒測試有幾種方法總體上分為靜態(tài)方法和動態(tài)方法兩大類。靜態(tài):關鍵功能是檢查軟件的表示和描述是否一致,沒有沖突或者沒有歧義動態(tài):語句覆蓋、判定覆蓋、條件覆蓋、判定條件

26、覆蓋、條件組合覆蓋、路徑覆蓋。6系統(tǒng)測試計劃是否需要同行審批,為什么需要,系統(tǒng)測試計劃屬于項目階段性關鍵文檔,因此需要評審。7 Alpha測試與beta的區(qū)別Alpha測試在系統(tǒng)開發(fā)接近完成時對應用系統(tǒng)的測試;測試后仍然會有少量的設計變更。這種測試一般由最終用戶或其它人員完成,不能由程序或測試員完成。Beta測試當開發(fā)和測試根本完成時所做的測試,最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其它人員完成,不能由程序員或測試員完成。8比較負載測試,容量測試和強度測試的區(qū)別負載測試:在一定的工作負荷下,系統(tǒng)的負荷及響應時間。強度測試:在一定的負荷條件下,在較長時間跨度內(nèi)的系統(tǒng)連續(xù)運行給系統(tǒng)性能所造成的影響。9測試結束的標準是什么?用例全部測試。 覆蓋率達到標準。 缺陷率達到標準。 其他指標達到質(zhì)量標準10描述軟件測試活動的生命周期?測試周期分為計劃、設計、實現(xiàn)、執(zhí)行、總結。其中:計劃:對整個測試周期中所有活動進行規(guī)劃,估計工作量、風險,安排人力物力資源,安排進度等;設計:完成測試方案,從技術層面上對測試進行規(guī)劃;實現(xiàn):進行測試用例和測試規(guī)程設計;執(zhí)行:根據(jù)前期完成的計劃、方案、用例、規(guī)程等文檔

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論