版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)
文檔簡介
PAGE12軟件測試管理辦法職責(zé)劃分1.1測試組長1.參與軟件需求設(shè)計的評審及項目可行性分析,風(fēng)險預(yù)估,測試資源的申請;2.編制軟件測試計劃、軟件測試用例,定期進行維護更新;3.根據(jù)測試組的冒煙測試結(jié)果判定是否接受該測試版本;如果達到測試標(biāo)準(zhǔn)則進入測試;4.實施軟件測試并對測試過程進行跟蹤監(jiān)控,對軟件質(zhì)量進行控制;5.參與搭建測試環(huán)境;6.編寫測試腳本;7.與其他部門的協(xié)調(diào)和合作。1.2軟件測試工程師1.按照測試計劃進行測試用例的執(zhí)行,維護;2.測試記錄的整理,提交、驗證、關(guān)閉缺陷;3.跟蹤缺陷退回的問題,必須有詳細的原因分析我們才可以進行缺陷退回缺陷的否決;4.完成性能與壓力測試。1.3質(zhì)量保證QA組1.對測試過程進行質(zhì)量監(jiān)督;2.保證項目按照正常的計劃執(zhí)行;3.并進行階段性的質(zhì)量評估。作業(yè)流程詳細規(guī)定了測試組在整個項目中各個階段的職責(zé)及相關(guān)測試輸出文檔:STAGE作業(yè)過程名作業(yè)內(nèi)容/管理方法PIC輸出結(jié)果項目啟動了解和識別軟件要求了解<<產(chǎn)品定義>>中規(guī)定的軟件相關(guān)的主要功能。參加軟件項目啟動大會,搜集、分析軟件測試輸入內(nèi)容。測試組長軟件需求分析報告測試相關(guān)文檔準(zhǔn)備測試計劃相關(guān)測試人員參加<<軟件開發(fā)計劃>>,<<軟件開發(fā)時間表>><<軟件需求規(guī)格說明>><<軟件功能菜單樹>>的評審會議。測試組長依據(jù)<<軟件開發(fā)計劃>><<軟件開發(fā)時間表>>編寫<<軟件測試計劃>>測試組長<<軟件測試計劃>>測試計劃測試用例評審、封板1.測試組長依據(jù)<<軟件需求規(guī)格說明>>,<<軟件功能菜單樹>>編寫<<冒煙測試用例>><<測試用例>>并組織評審。2.升級項目的測試用例選擇依據(jù)<<測試用例管理辦法>>測試組長<<軟件測試用例>>更新測試用例完成模塊的軟件測試用例,性能測試用例、壓力測試用例;軟件需求變更時,根據(jù)更新的軟件開發(fā)計劃和需求文檔相應(yīng)變更和修改<<軟件測試用例>>和<<軟件測試計劃>>。當(dāng)軟件需求發(fā)生變更時,要及時更新測試用例。測試組長測試工程師更新后的<<軟件測試計劃>>、<<軟件測試用例>>測試版本準(zhǔn)備新版本發(fā)布1.開發(fā)部準(zhǔn)備測試版本;2.軟件配置管理工程師進行系統(tǒng)冒煙測試版本的編譯;軟件配置管理工程師冒煙測試冒煙測試3.項目測試組進行系統(tǒng)的冒煙測試;并記錄測試結(jié)果;整理測試報告并發(fā)送給相關(guān)人員;計算FailRatio并判斷該版本是否可以進行測試;(判定標(biāo)準(zhǔn):模塊實現(xiàn)100%;FailRatio≤10%;);如果達到測試要求;軟件配置管理工程師正式發(fā)布測試版本,測試組長《冒煙測試報告》測試執(zhí)行測試記錄缺陷提交1.測試組長在項目經(jīng)理處申請相關(guān)測試資源。項目測試人員依據(jù)測試用例對該版本進行全面的測試,確保軟件所有功能的正確性,性能測試和壓力測試達到預(yù)期結(jié)果。測試工程師測試組長項目測試日報;項目測試周報;2.要求測試工程師將當(dāng)天發(fā)現(xiàn)的缺陷在下班前提交到QC;測試工程師QC缺陷記錄缺陷處理缺陷確定缺陷報告缺陷修改缺陷關(guān)閉3.軟件項目經(jīng)理組織對缺陷管理系統(tǒng)中提交的各個缺陷討論和分析,確定每個缺陷是否是真正的軟件問題,缺陷所屬的模塊,嚴重程度和修改緊急度等,同時把每個缺陷分配給相應(yīng)的開發(fā)人員。軟件項目經(jīng)理開發(fā)工程師測試工程師QC缺陷記錄4.開發(fā)人員修改缺陷后,及時將QC數(shù)據(jù)庫中的狀態(tài)置為解決狀態(tài)。測試人員在收到新的測試版本后及時(1天內(nèi))地驗證解決狀態(tài)的缺陷是否確實可以關(guān)閉。如果確認缺陷已經(jīng)修改后,將QC上相應(yīng)的缺陷置為關(guān)閉狀態(tài)。測試任務(wù)表5.測試組長每周一在8:30將測試任務(wù)表發(fā)送給組內(nèi)成員;組內(nèi)成員按照測試任務(wù)表執(zhí)行測試;測試組長接收到開發(fā)組要求的臨時加急任務(wù)時需要更新任務(wù)表;測試組長在周五統(tǒng)計本周的測試完成狀態(tài)并安排下周任務(wù);測試組長<測試任務(wù)表>測試報告6.軟件測試組長匯總相關(guān)測試人員的測試結(jié)果,定期總結(jié)項目測試報告;測試報告提交給軟件項目經(jīng)理和部門經(jīng)理。7.測試組在測試時,對變動比較大的功能;測試組長安排測試經(jīng)驗豐富的測試工程師執(zhí)行測試,確保軟件功能沒有衰退現(xiàn)象。測試組長測試工程師<項目測試日報><項目測試周報>退回缺陷的處理8.對于被軟件項目經(jīng)理置為缺陷退回狀態(tài)的記錄;要求有詳細的原因分析;測試組才可以進行缺陷的關(guān)閉。軟件項目經(jīng)理測試工程師QC缺陷記錄測試工具開發(fā)測試工具開發(fā)和維護1.軟件測試工具研發(fā)組;根據(jù)具體測試需求進行測試工具研發(fā)。測試工具開發(fā)組項目總結(jié)項目總結(jié)1.開發(fā)項目結(jié)束后,軟件測試組應(yīng)進行軟件測試總結(jié),對軟件測試管理過程,活動進行分析,為將來的項目和持續(xù)改進積累經(jīng)驗數(shù)據(jù).測試組長《項目測試總結(jié)報告》維護測試項目上線后客戶反饋1.當(dāng)項目上線后,對產(chǎn)品的軟件進行維護和售后服務(wù),在此期間,測試組根據(jù)客戶的反饋的問題列表進行專項測試;測試組長<<軟件專項測試報告>>問題分析和修改2.軟件項目經(jīng)理組織對缺陷管理系統(tǒng)中提交的各個缺陷討論和確定每個缺陷是否是真正的軟件問題,缺陷所屬的模塊,嚴重程度和修改緊急度等,同時把每個缺陷分配給相應(yīng)的開發(fā)人員。軟件項目經(jīng)理開發(fā)工程師問題驗證和關(guān)閉3.開發(fā)人員修改缺陷后,及時通知軟件測試人員,測試人員及時(1天內(nèi))地驗證開發(fā)人員修改的缺陷是否確實可以關(guān)閉。然后對所有功能進行全面的測試,確保產(chǎn)品基本功能的正確性;測試工程師<測試報告>測試類型和策略按照目前的產(chǎn)品類型和規(guī)模,需要執(zhí)行的測試類型及策略如下:測試類型實施標(biāo)準(zhǔn)類型描述通過標(biāo)準(zhǔn)責(zé)任人冒煙測試系統(tǒng)功能集成度80%以上。剩余未集成功能不影響已集成功能。在版本進入系統(tǒng)測試之前需要執(zhí)行的基本功能通過性驗證。發(fā)現(xiàn)的缺陷95%已經(jīng)解決,其中2級以上的缺陷100%解決。測試組長功能測試冒煙測試通過。未集成模塊有明確的完成日期。全部功能系統(tǒng)測試,包括:通過性、失效性、兼容性、;視測試系統(tǒng)的成熟度,缺陷的分布及解決情況安排測試輪次及各輪次的內(nèi)容。1.所有的模塊全部集成且測試完成。2.沒有遺留的功能性Bug。3.發(fā)現(xiàn)的缺陷95%已經(jīng)解決,其中2級以上的缺陷100%解決。測試工程師兼容測試可以在功能測試完成第一輪后開始軟件在各個產(chǎn)品平臺上面都能夠正常的下載、安裝、運行、卸載無缺陷測試工程師升級測試可以在功能測試完成第一輪后開始產(chǎn)品的升級功能測試,全包及部分更新文件的測試。無缺陷測試工程師性能測試視系統(tǒng)的穩(wěn)定情況,可以在功能測試完成第一輪后開始注冊、登錄、評論等與服務(wù)器有頻繁交互的壓力測試,性能評估。滿足軟件設(shè)計時的性能標(biāo)準(zhǔn)測試主導(dǎo),開發(fā)配合用戶模擬測試功能測試完成模擬用戶日常使用,綜合各類用戶的使用習(xí)慣設(shè)計專門的測試案例。無遺留的的用戶體驗類缺陷測試組長自由測試回歸測試通過用戶體驗測試,小范圍用戶的實際使用,主要關(guān)注:易用性、實用性。使用者的反饋全部解答或修改測試組長回歸測試以上所有的測試類型通過且軟件版本不再會有較大變化產(chǎn)品上線之前對項目中Level3,4級的Bug進行回歸驗證;全部通過測試組長缺陷級別定義等級說明描述4嚴重錯誤由于程序所引起的死機,非法退出死循環(huán)導(dǎo)致數(shù)據(jù)庫發(fā)生死鎖數(shù)據(jù)通訊錯誤:系統(tǒng)與其他系統(tǒng)進行數(shù)據(jù)傳遞時出現(xiàn)錯誤交易類的數(shù)值計算錯誤,分析類的數(shù)值計算偏差在0.2%以上沒有達到性能指標(biāo)3較嚴重錯誤功能不符數(shù)據(jù)流錯誤:數(shù)據(jù)在系統(tǒng)內(nèi)部流轉(zhuǎn)中計算錯誤程序接口錯誤2一般性錯誤界面錯誤,與詳細文檔不符界面內(nèi)容、格式錯誤簡單的輸入限制未放在前臺進行控制刪除、保存操作未給出確認提示信息輔助說明描述不清楚顯示格式不規(guī)范長時間操作未給用戶進度提示或提示信息1較小錯誤窗口文字未采用行業(yè)術(shù)語可輸入\點擊區(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志系統(tǒng)處理未優(yōu)化:系統(tǒng)易用性方面的問題,例如查詢條件值為空時通常默認為查詢?nèi)?,如果還需要用戶選擇查詢條件為“全部”則可以認為系統(tǒng)處理未優(yōu)化0測試建議(非缺陷)系統(tǒng)設(shè)計之外的優(yōu)化建議缺陷管理流程缺陷描述中要包括詳細、準(zhǔn)確的操作步驟、預(yù)期結(jié)果、實際結(jié)果、測試環(huán)境。缺陷提交時在“實際結(jié)果”欄目中填寫測試數(shù)據(jù)、執(zhí)行結(jié)果內(nèi)容,盡量將缺陷的界面截圖作為附件上傳至對應(yīng)的記錄?!胺駴Q缺陷”、“暫緩處理”此兩類缺陷要求在缺陷“注釋”中注明否決原因或后續(xù)處理方案。對“緊急”級別的缺陷,測試人員應(yīng)進行隨時地檢查并驗證,及時修改對應(yīng)缺陷的狀態(tài)。缺陷跟蹤遵循:誰發(fā)現(xiàn)誰跟蹤;開發(fā)管理組進行確認、分配缺陷;開發(fā)人員及時修改缺陷或反饋意見。開發(fā)管理組人員在自己無法及時分配缺陷的情況下要提前找到代理人員完成該工作,避免缺陷在此環(huán)節(jié)滯留。開發(fā)人員必須對缺陷進行及時修改,缺陷提交后,24小時內(nèi)必須進行處理。如果開發(fā)人員沒有及時修改缺陷,則將缺陷嚴重程度的等級升級(低級->中級,中級->高級,高級->緊急)。如果缺陷經(jīng)開發(fā)人員多次修改(修改次數(shù)>2次),測試驗證后仍存在問題,則將缺陷的嚴重程度的等級升級(低級->中級,中級->高級,高級->緊急)。開發(fā)人員必須隨時查看QC中的缺陷狀態(tài)變化信息,每天最低查看次數(shù)不得少于5次。缺陷管理跟蹤流程如下: 軟件測試工作規(guī)范1
目的
統(tǒng)一公司所有項目的軟件測試流程;
提供一套適合公司所有項目并可裁減的軟件測試工具;2
范圍
本規(guī)范中單元測試適用于所有的JAVA項目;
本規(guī)范中集成測試、系統(tǒng)測試和性能測試適用于所有項目。3
測試階段與軟件開發(fā)階段的對應(yīng)關(guān)系1
過程描述1.1
單元測試活動該活動包括以下環(huán)節(jié):
編寫單元測試計劃;
設(shè)計單元測試用例;
執(zhí)行單元測試過程;
記錄單元測試缺陷;
編寫單元測試報告;1.1.1
活動目的驗證軟件系統(tǒng)模塊內(nèi)功能、容錯、界面和報表測試和樁模塊、子模塊之間的接口測試。1.1.2
角色與職責(zé)角色職責(zé)項目經(jīng)理監(jiān)控單元測試過程;開發(fā)組長開發(fā)人員編寫單元測試計劃;對單元代碼進行檢查,設(shè)計單元測試用例;執(zhí)行測試用例;記錄單元測試缺陷,修改缺陷并關(guān)閉缺陷;編寫單元測試分析報告;配置管理員管理測試需要的資源,包括軟硬件環(huán)境,版本管理和Bug管理。1.1.3
測試范圍
單元模塊的功能性測試
單元模塊內(nèi)和模塊之間的接口測試
單元模塊的容錯性測試
單元模塊的界面測試
單元模塊內(nèi)的權(quán)限1.1.4
進入條件已經(jīng)完成被測模塊的編碼工作1.1.5
輸入《詳細設(shè)計說明書》1.1.6
活動說明對于結(jié)構(gòu)化的編程語言,程序單元指程序中定義的函數(shù)或子程序。單元測試是指對函數(shù)或子程序所進行的測試。對于面向?qū)ο蟮木幊陶Z言,程序單元指特定的一個具體的類或相關(guān)的多個類。單元模塊之間的接口等。(1)
開發(fā)人員依據(jù)詳細設(shè)計編寫單元測試計劃和和單元測試用例,《詳見junit使用說明》和《jprobe使用說明》,需詳細描述該用例的輸入、輸出和預(yù)期結(jié)果等相關(guān)內(nèi)容;(2)
開發(fā)人員編寫程序代碼;(3)
開發(fā)人員執(zhí)行單元測試用例,并記錄執(zhí)行結(jié)果;(4)
開發(fā)人員執(zhí)行測試用例過程中發(fā)現(xiàn)的缺陷,必須提交到缺陷跟蹤工具中;(5)
開發(fā)組長完成單元測試后,編寫單元測試分析報告,項目經(jīng)理審核《單元測試分析報告》。1.1.7
輸出已通過回歸測試、打標(biāo)簽單元級的代碼《單元測試分析報告》1.1.8
退出條件
被測代碼語句覆蓋率滿足單元測試計劃中制定的代碼覆蓋率要求;
測試用例執(zhí)行覆蓋率應(yīng)達100%;
《單元測試分析報告》通過評審;
A類缺陷、B類缺陷、C類缺陷為零,D類缺陷少于10%,E類缺陷少于15%。1.1.9
工具與方法
JAVA項目Junit3.7以上版本:利用Junit提供的組件測試代碼的功能邏輯;Jprobe5.0以上版本:使用Coverage組件檢查代碼覆蓋率。
工具使用參見《Junit使用簡明手冊》,《Jprobe使用簡明手冊》。1.2
集成測試活動該活動包括以下環(huán)節(jié):
編寫集成測試計劃;
設(shè)計集成測試用例;
執(zhí)行集成測試過程;
記錄集成測試缺陷;
編寫集成測試分析報告;1.2.1
活動目的
1.2.2
角色與職責(zé)角色職責(zé)項目經(jīng)理協(xié)調(diào)軟硬件和人力資源、風(fēng)險控制等;測試經(jīng)理協(xié)調(diào)相關(guān)測試資源,風(fēng)險控制等;跟蹤集成測試執(zhí)行過程;測試組長測試工程師制定集成測試計劃;編寫編寫測試用例;執(zhí)行集成測試用例;提交缺陷;回歸測試;編寫集成測試分析報告;架構(gòu)師協(xié)助測試組長制定集成測試計劃。確認測試缺陷,并分發(fā)測試缺陷于開發(fā)人員進行修改;評審集成測試計劃、測試用例、集成測試分析報告;開發(fā)人員修改缺陷;提交缺陷修改程序代碼;配置管理員管理測試需要的資源,包括軟硬件環(huán)境,版本管理和缺陷跟蹤管理。建立代碼基線,配合進行配置檢查。1.2.3
測試范圍
系統(tǒng)集成后的功能性測試;
系統(tǒng)集成后的容錯性測試;
系統(tǒng)集成后的界面測試;
系統(tǒng)集成后的安全(權(quán)限)測試;
系統(tǒng)集成后的系統(tǒng)的內(nèi)部接口測試;
系統(tǒng)集成后的可用性測試;
系統(tǒng)集成后的數(shù)據(jù)完整性測試。1.2.4
進入條件《概要設(shè)計說明書》通過評審1.2.5
輸入《概要設(shè)計說明書》1.2.6
活動說明(1)
測試組長制定《集成測試計劃》;(2)
測試人員負責(zé)組織編寫集成測試用例,編寫測試腳本,編寫測試用例。(3)
測試人員執(zhí)行測試用例。(4)測試過程中發(fā)現(xiàn)缺陷提交到缺陷跟蹤系統(tǒng);(5)架構(gòu)師對缺陷進行評估并分發(fā),若判斷是缺陷則指定相關(guān)開發(fā)人員進行修改;(6)
開發(fā)人員修改完缺陷后,由測試人員進行回歸測試,測試通過則缺陷關(guān)閉,檢驗未通過,則轉(zhuǎn)給開發(fā)人員,繼續(xù)修改;(7)
測試人員編寫集成測試分析報告。1.2.7
輸出
已通過回歸測試、打標(biāo)簽系統(tǒng)級的代碼;
《集成測試分析報告》;
A類缺陷、B類缺陷、C類缺陷為零,D類缺陷少于5%,E類缺陷少于10%。1.2.8
退出條件《集成測試分析報告》通過評審代碼基線化1.2.9
工具與方法因具體項目而定1.3
系統(tǒng)測試該活動包括以下環(huán)節(jié):
編寫系統(tǒng)測試計劃;
設(shè)計系統(tǒng)測試用例;
執(zhí)行系統(tǒng)測試過程;
記錄系統(tǒng)測試缺陷;
編寫系統(tǒng)測試分析報告;1.3.1
活動目的通過與系統(tǒng)的需求規(guī)格作比較,從功能和非功能兩方面,發(fā)現(xiàn)軟件與系統(tǒng)需求規(guī)格不相符合或與之矛盾之處。1.3.2
角色與職責(zé)角色職責(zé)項目經(jīng)理協(xié)調(diào)軟硬件和人力資源、風(fēng)險控制等;測試經(jīng)理協(xié)調(diào)相關(guān)測試資源,風(fēng)險控制等跟蹤系統(tǒng)測試執(zhí)行過程;測試組長、測試工程師制定系統(tǒng)測試計劃;在架構(gòu)師的協(xié)助下,搭建系統(tǒng)測試環(huán)境;編寫系統(tǒng)測試用例;執(zhí)行系統(tǒng)測試用例;提交缺陷;回歸測試;編寫系統(tǒng)測試分析報告;架構(gòu)師協(xié)助測試組長制定系統(tǒng)測試計劃。確認測試缺陷,并分發(fā)測試缺陷于開發(fā)人員進行修改;評審系統(tǒng)測試計劃、測試用例、測試分析報告;開發(fā)人員修改缺陷;提交缺陷修改程序代碼;配置管理員管理測試需要的資源,包括軟硬件環(huán)境,版本管理和缺陷跟蹤管理。建立代碼基線,配合進行配置檢查。1.3.3
系統(tǒng)測試范圍
系統(tǒng)的功能性測試;
系統(tǒng)的初始化測試;
系統(tǒng)的(負載,性能,并發(fā))測試;
系統(tǒng)的配置測試;
系統(tǒng)的安全性測試(防火墻,TLS,SSL安全機制,加密);
系統(tǒng)的外部接口測試;
系統(tǒng)的數(shù)據(jù)完整性測試;
系統(tǒng)的可用性測試;
系統(tǒng)的安裝部署測試;
系統(tǒng)的恢復(fù)性測試;
系統(tǒng)的可移植性測試
系統(tǒng)的文檔測試。1.3.4
進入條件
《需求說明書》經(jīng)過評審;1.3.5
活動說明(1)
測試組長制定《系統(tǒng)測試計劃》;(2)
測試組長負責(zé)組織編寫系統(tǒng)測試用例、編寫測試腳本,編寫測試用例;(3)
測試組長在架構(gòu)師的協(xié)助下搭建與用戶需求一致的測試環(huán)境,質(zhì)量管理部配合確認測試環(huán)境,參見《系統(tǒng)環(huán)境確認單》;(4)
測試人員執(zhí)行測試用例;(5)
測試過程中發(fā)現(xiàn)缺陷提交到缺陷跟蹤系統(tǒng);(4)
架構(gòu)師對缺陷進行評估,若判斷是缺陷則指定相關(guān)開發(fā)人員進行修改;(5)
開發(fā)人員修改完問題后,由問題提出人進行回歸測試,測試通過則缺陷關(guān)閉,檢驗未通過,則轉(zhuǎn)給開發(fā)人員,繼續(xù)修改;(6)
測試組長編寫《系統(tǒng)測試分析報告》。1.3.6
輸出已通過回歸測試、打標(biāo)簽系統(tǒng)級的代碼《系統(tǒng)測試分析報告》1.3.7
退出條件
系統(tǒng)測試報告通過評審;
代碼基線化;
A類缺陷、B類缺陷、C類缺陷為零,D類缺陷少于3%,E類缺陷少于6%。1.3.8
工具與方法因項目的需求而定。1.4
性能測試該活動包括以下環(huán)節(jié):
編寫性能測試計劃;
設(shè)計性能測試用例;
搭建性能測試環(huán)境;
執(zhí)行性能測試過程;
記錄性能測試缺陷;
編寫性能測試報告;
溫馨提示
- 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)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
- 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 婚前承諾協(xié)議模板
- 抹灰施工勞務(wù)分包合同示例
- 聲學(xué)裝飾合作協(xié)議
- 借款合同范本擔(dān)保協(xié)議
- 墻繪設(shè)計施工合同樣本
- 市政工程分包合同的管理與監(jiān)督
- 培養(yǎng)領(lǐng)導(dǎo)力的研學(xué)合作協(xié)議
- 工業(yè)設(shè)備采購協(xié)議
- 抵押合同終止還款責(zé)任支付條件協(xié)議
- 通風(fēng)空調(diào)系統(tǒng)勞務(wù)分包協(xié)議
- 多西他賽化療方案
- 中職學(xué)校專業(yè)建設(shè)指導(dǎo)委員會
- 2024年度醫(yī)院內(nèi)窺鏡科述職報告課件
- 醫(yī)院保安提升服務(wù)方案
- 小紅書app創(chuàng)業(yè)計劃書
- 采煤安全管理知識課件
- 人工智能在通信網(wǎng)絡(luò)中的應(yīng)用
- 高頻電灼儀產(chǎn)品技術(shù)要求深圳半島醫(yī)療
- 年度委托代理記賬服務(wù) 投標(biāo)方案
- 卵圓孔未閉封堵術(shù)術(shù)前宣教
- 中建室外落地式卸料平臺施工方案
評論
0/150
提交評論