項(xiàng)目管理綜合輔導(dǎo)之測(cè)試過程中的配置管理

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

軟件測(cè)試需要進(jìn)行充分的測(cè)試準(zhǔn)備，需要科學(xué)的，規(guī)范的測(cè)試過程管理。有效的配置管理對(duì)跟蹤和提高測(cè)試質(zhì)量和效率起到十分重要的作用。測(cè)試過程中的配置管理工作不僅包括搭建滿足要求的測(cè)試環(huán)境，還包括獲取正確的測(cè)試、發(fā)布版本。但是在實(shí)際軟件測(cè)試工作中，配置管理并沒有得到相應(yīng)的重視。
　　軟件測(cè)試的“泥潭”
　　可能有讀者會(huì)覺得奇怪，軟件測(cè)試就是發(fā)現(xiàn)軟件中隱藏的缺陷，和配置管理有啥關(guān)系呢。但是，不知道大家在實(shí)際工作中有沒有發(fā)現(xiàn)，我們?cè)谲浖y(cè)試工作中碰到的一些問題，實(shí)際上就是由于配置管理工作沒做好而產(chǎn)生的。
　　在軟件測(cè)試工作中，我們經(jīng)常碰到以下三個(gè)問題：
缺陷只能在測(cè)試環(huán)境出現(xiàn)，但是在開發(fā)環(huán)境中無法重現(xiàn)；
已經(jīng)修復(fù)的缺陷在測(cè)試時(shí)又重現(xiàn)；
發(fā)布程序在內(nèi)部確認(rèn)測(cè)試中測(cè)試通過，但是發(fā)布時(shí)卻發(fā)生系統(tǒng)運(yùn)行失效的情況。
　　產(chǎn)生原因
　　不考慮缺陷報(bào)告描述不清楚這種情況，究其原因，上述三個(gè)問題的產(chǎn)生主要有以下七點(diǎn)原因：
　　測(cè)試環(huán)境配置的復(fù)雜性
　　由于不同（版本）的操作系統(tǒng)、不同（版本）的數(shù)據(jù)庫，不同（版本）的網(wǎng)絡(luò)服務(wù)器、應(yīng)用服務(wù)器，再加上不同的系統(tǒng)架構(gòu)等組合，使得要構(gòu)建的軟件測(cè)試環(huán)境多種多樣、不勝枚舉；而且現(xiàn)在隨著軟件運(yùn)行環(huán)境的多樣性、配置各種相關(guān)參數(shù)的“浩大工程”和測(cè)試軟件的兼容性等方面的需要，使得構(gòu)建軟件測(cè)試環(huán)境的工作變得較為復(fù)雜和頻繁，而軟件測(cè)試環(huán)境的構(gòu)建是否合理、穩(wěn)定和具有代表性，將直接影響到測(cè)試結(jié)果的真實(shí)性、可靠性和正確性。在筆者曾經(jīng)做過的一個(gè)項(xiàng)目中，考試/大由于測(cè)試環(huán)境使用了和開發(fā)系統(tǒng)不同版本的 JDK（測(cè)試環(huán)境使用 JDK1.5，而開發(fā)環(huán)境為 JDK1.4），導(dǎo)致測(cè)試中出現(xiàn)了在開發(fā)環(huán)境不會(huì)出現(xiàn)的缺陷。
測(cè)試產(chǎn)品與開發(fā)產(chǎn)品之間的密切關(guān)系
　　在一個(gè)項(xiàng)目的軟件測(cè)試過程中，會(huì)有大量的“產(chǎn)品”產(chǎn)生，典型的如文檔（包括測(cè)試計(jì)劃、測(cè)試用例、測(cè)試報(bào)告、日常管理文檔等）、數(shù)據(jù)、腳本等。軟件測(cè)試的一個(gè)獨(dú)特的特征，就是他的產(chǎn)品都是基于開發(fā)產(chǎn)品（如源代碼、文檔、安裝文件等）產(chǎn)生和變化的。而開發(fā)產(chǎn)品都是以“信息”的形式存放在計(jì)算機(jī)中，因此，較硬件而言，開發(fā)產(chǎn)品比較容易被修改和變化。一旦開發(fā)產(chǎn)品發(fā)生改變，測(cè)試產(chǎn)品也需要相應(yīng)發(fā)生改變。如何有效的管理測(cè)試產(chǎn)品，維護(hù)測(cè)試產(chǎn)品與開發(fā)產(chǎn)品之間的關(guān)系成為測(cè)試過程中的一個(gè)棘手的問題。
開發(fā)人員在處理新的開發(fā)任務(wù)時(shí)間接修復(fù)了缺陷
　　由于缺少工具的支撐，開發(fā)人員不能詳細(xì)的、準(zhǔn)確的獲取提交測(cè)試的缺陷涉及修改的源碼，所以在有些項(xiàng)目組中，每次測(cè)試時(shí)，開發(fā)人員將個(gè)人開發(fā)的所有源碼提交給測(cè)試人員，由測(cè)試人員采用完全覆蓋的方式更新測(cè)試環(huán)境。但是由于開發(fā)人員的工作環(huán)境仍在進(jìn)行新變更、新功能或缺陷的處理，而修改新變更、新功能或缺陷的同時(shí)，很容易將原來存在的缺陷一并修復(fù)。這就可能導(dǎo)致測(cè)試環(huán)境中存在的缺陷在開發(fā)環(huán)境中無法重現(xiàn)問題的發(fā)生。
　　開發(fā)人員漏提交待測(cè)試的源碼
　　假設(shè)項(xiàng)目組意識(shí)到完全覆蓋方式的不合理，要求開發(fā)人員只能提交修改缺陷或變更對(duì)應(yīng)的源碼供測(cè)試?？墒怯捎谌鄙俟ぞ叩闹危_發(fā)人員只能手工記錄、追蹤變更和缺陷對(duì)應(yīng)修改的源碼，這種方式一是記錄和追蹤的工作量大，二是很容易漏提交源碼。由于開發(fā)人員漏提交源碼，就很容易發(fā)生測(cè)試環(huán)境的缺陷在開發(fā)環(huán)境無法重現(xiàn)或者已經(jīng)修復(fù)的缺陷又重現(xiàn)的情況。
公共參數(shù) / 基礎(chǔ)數(shù)據(jù) / 配置文件未進(jìn)行配置管理
　　一些項(xiàng)目組未將公共參數(shù) / 基礎(chǔ)數(shù)據(jù) / 配置文件等全局文件納入配置管理。由于沒有將其納入配置管理，考試/大所以這部分全局文件的變更也同樣的未進(jìn)行變更管理。當(dāng)這些全局文件發(fā)生變更時(shí)，很容易出現(xiàn)測(cè)試環(huán)境、開發(fā)環(huán)境，甚至包括生產(chǎn)環(huán)境配置不一致的情況。一旦出現(xiàn)這種情況，那么即使發(fā)布程序在內(nèi)部確認(rèn)測(cè)試時(shí)測(cè)試通過，但是部署到生產(chǎn)環(huán)境后系統(tǒng)運(yùn)行失效的情況就在所難免。這實(shí)際上是因配置項(xiàng)缺失而帶來的問題。
　　很多人可能不認(rèn)為公共參數(shù)或者基礎(chǔ)數(shù)據(jù)應(yīng)該作為配置項(xiàng)納入配置管理，實(shí)際上這種想法是錯(cuò)誤的。假設(shè)沒有將這些公共參數(shù)等信息納入配置管理，那么試想一下，假設(shè)有一天系統(tǒng)意外崩潰，我們拿什么去恢復(fù)生產(chǎn)環(huán)境？所以說，系統(tǒng)運(yùn)行支撐的所有內(nèi)容（包括基礎(chǔ)數(shù)據(jù)、配置文件等）都需要納入配置庫進(jìn)行配置管理。
　　曾經(jīng)有這樣一個(gè)案例：某審批系統(tǒng)的公司組織機(jī)構(gòu)信息是通過數(shù)據(jù)庫進(jìn)行維護(hù)的。項(xiàng)目組在處理某個(gè)需求變更時(shí)，需要相應(yīng)修改公司組織機(jī)構(gòu)信息，但是項(xiàng)目組未將組織機(jī)構(gòu)的修改作為一個(gè)變更單獨(dú)提出，測(cè)試組也不知道有這個(gè)潛在變更的存在。系統(tǒng)測(cè)試通過后如期部署上線，但是上線后發(fā)生審批流程節(jié)點(diǎn)出錯(cuò)的問題。假如項(xiàng)目組將這個(gè)組織機(jī)構(gòu)信息作為配置項(xiàng)納入配置庫，它的變更也經(jīng)過變更管理，那么怎么可能發(fā)生這種情況呢？
上線的源碼版本組合為未經(jīng)測(cè)試的版本組合
　　在項(xiàng)目已定義的發(fā)布流程中，可能因?yàn)橐恍┛此坪侠淼牟襟E，導(dǎo)致系統(tǒng)部署到生產(chǎn)環(huán)境后出現(xiàn)系統(tǒng)運(yùn)行失效的情況。
　　在圖一中，假設(shè) F1 和文件 F2 在修改之前的版本都是 1，在實(shí)現(xiàn)了需求 1 和缺陷 1 后，版本均變?yōu)榘姹?nbsp;2，表示為 F1（v2），F(xiàn)2（v2）。在測(cè)試環(huán)境測(cè)試時(shí)，測(cè)試的源碼版本均為 F1 和 F2 的版本 2，但是需求 1 沒有通過測(cè)試，最后只部署了缺陷 1 這個(gè)活動(dòng)對(duì)應(yīng)的源碼到生產(chǎn)環(huán)境。那么部署到生產(chǎn)系統(tǒng)的版本將是 F1（v1）和 F2（v2）。F1（v1）是原來生產(chǎn)系統(tǒng)的版本，F(xiàn)2（v2）是包含了缺陷 1 所對(duì)應(yīng)的版本。但是，和 F1（v1）匹配的版本組合應(yīng)該是 F2（v1），和 F2（v2）匹配的版本組合應(yīng)是 F1（v2）。這時(shí)上線帶來的結(jié)果是在生產(chǎn)系統(tǒng)上運(yùn)行的是未經(jīng)測(cè)試的版本組合。這潛在的質(zhì)量陷阱可能導(dǎo)致發(fā)布時(shí)系統(tǒng)運(yùn)行失效的情況。
上線的源碼版本為未經(jīng)測(cè)試的版本
　　除了上線的源碼版本組合是未經(jīng)測(cè)試的版本組合這種質(zhì)量陷阱外，在發(fā)布流程中，還可能存在另一種質(zhì)量陷阱。
　　在圖二中，假設(shè)文件 F1 和文件 F2 在修改之前的版本都是 1，在實(shí)現(xiàn)了需求 1 后 F1 的版本變成了 2，F(xiàn)2 的版本為 3。開發(fā)任務(wù) 1 在需求 1 修改的基礎(chǔ)上進(jìn)行了開發(fā)，生成 F2（v4）。在測(cè)試環(huán)境測(cè)試的源碼版本為 F1（v2）和 F2（v4）。但是開發(fā)任務(wù) 1 沒有通過測(cè)試，最后部署到生產(chǎn)系統(tǒng)的版本將是 F1（v2）和 F2（v3），F(xiàn)1（v2）和 F2（v3）是包含了需求 1 所對(duì)應(yīng)的版本。但是，F(xiàn)2（v3）是未經(jīng)過測(cè)試的版本，這潛在的質(zhì)量陷阱也可能導(dǎo)致發(fā)布時(shí)系統(tǒng)運(yùn)行失效的情況。
　　解決方案
　　為了避免上述的問題的產(chǎn)生，筆者從以下七點(diǎn)出發(fā)給出測(cè)試過程中配置管理問題的解決方案。
　　選取合適的配置管理工具
　　整理配置項(xiàng)，明確相應(yīng)管理流程
　　將配置項(xiàng)作為一個(gè)整體進(jìn)行配置管理
　　增加發(fā)布前驗(yàn)收測(cè)試環(huán)節(jié)
　　采用并行開發(fā)方式區(qū)分不同的開發(fā)活動(dòng)
　　定制文件開發(fā)方式
　　明確角色與職責(zé)
　　選取合適的配置管理工具
　　為了能讓開發(fā)人員不用手工記錄和追蹤缺陷修改的源碼，我們引入 IBM Rational ClearCase。考試/大通過使用 ClearCase 的 UCM 模式，我們實(shí)現(xiàn)了一個(gè)可以立即用于軟件開發(fā)項(xiàng)目的一致并基于活動(dòng)的變更管理流程。UCM（統(tǒng)一變更管理）是 IBM Rational 提出的用于管理軟件開發(fā)過程（包括從需求到版本發(fā)布）中所有變更的“最佳實(shí)踐”流程。UCM 通過抽象層次的提升簡(jiǎn)化了軟件開發(fā)，從而使得軟件開發(fā)團(tuán)隊(duì)從更高的層次根據(jù)活動(dòng)（activity）來管理變更。通過 UCM，一個(gè)開發(fā)活動(dòng)可以自動(dòng)地同其變更集（封裝了所有用于實(shí)現(xiàn)該活動(dòng)的項(xiàng)目工件）相關(guān)聯(lián)，這樣避免了項(xiàng)目成員手動(dòng)跟蹤所有文件變更。
　　ClearCase 管理員利用 ClearCase 提供的命令進(jìn)行二次開發(fā)，可實(shí)現(xiàn)獲取某個(gè)指定活動(dòng)或一批活動(dòng)變更集包含的源碼集合，這為開發(fā)人員提交開發(fā)活動(dòng)變更集包含的源碼集合，測(cè)試人員 / 配置管理員增量更新測(cè)試環(huán)境、生產(chǎn)環(huán)境提供了方便。
　　整理配置項(xiàng)，明確相應(yīng)管理流程
　　為了避免因配置項(xiàng)缺失導(dǎo)致開發(fā)環(huán)境、測(cè)試環(huán)境和生產(chǎn)環(huán)境的不一致，我們需要對(duì)系統(tǒng)中所有的配置項(xiàng)（如公共參數(shù) / 基礎(chǔ)數(shù)據(jù) / 配置信息等）進(jìn)行整理，明確各種類型配置項(xiàng)的存放方式、控制流程。例如：某項(xiàng)目的 SQL 建表文件、UNIX 操作系統(tǒng)的配置參數(shù)文件屬于系統(tǒng)的全局文件，其存放方式為文本文件。根據(jù)項(xiàng)目測(cè)試與配置管理要求，項(xiàng)目相關(guān)負(fù)責(zé)人針對(duì)全局文件定義了相應(yīng)的控制流程。
　　同樣的，對(duì)于源碼這類文件，我們也需要規(guī)范相應(yīng)的管理流程。通過使用 ClearCase UCM 方式，開發(fā)人員在修改源碼時(shí)，可以使用 ClearCase 的“處理活動(dòng)”功能，快速切換當(dāng)前處理的活動(dòng)，使他們可以選擇正確的活動(dòng)進(jìn)行源碼修改。采用 UCM 方式的好處之一，就是項(xiàng)目成員對(duì)于配置庫的修改必須有活動(dòng)關(guān)聯(lián)，如果沒有分配給操作用戶的活動(dòng)，用戶就無法對(duì)配置庫進(jìn)行任何修改。這對(duì)于正在運(yùn)行的系統(tǒng)而言，源碼的修改獲得批準(zhǔn)是非常重要的。
　　將配置項(xiàng)作為一個(gè)整理進(jìn)行配置管理
　　配置管理工作是整個(gè)軟件開發(fā)過程的生命線，對(duì)于測(cè)試人員來講，由于測(cè)試產(chǎn)品與開發(fā)產(chǎn)品之間的密切關(guān)系（參見“產(chǎn)生原因”一節(jié)），測(cè)試人員必須得到自己關(guān)心的程序的任意一個(gè)測(cè)試版本，以便可以在正確的版本上執(zhí)行正確的測(cè)試用例。
　　由于上述原因，我們需要將配置項(xiàng)作為一個(gè)整體進(jìn)行配置管理，方便進(jìn)行測(cè)試版本的回溯。我們可以通過 ClearCase 的基線來實(shí)現(xiàn)這個(gè)功能。UCM 將項(xiàng)目活動(dòng)嵌入到各個(gè)基線中，這樣測(cè)試人員可以確切地知道他們將測(cè)試什么，而開發(fā)人員則確切地知道其他開發(fā)人員做了什么。在其他一些配置管理工具中，基線只是一個(gè)文件版本的快照，并沒有將該快照關(guān)聯(lián)修改這些文件對(duì)應(yīng)的活動(dòng)。
　　增加發(fā)布前驗(yàn)收測(cè)試環(huán)節(jié)
　　由于缺少獨(dú)立的發(fā)布前的確認(rèn)測(cè)試環(huán)節(jié)，而將程序潛在的質(zhì)量陷阱（見圖一和圖二）遺留到在生產(chǎn)環(huán)境部署后才爆發(fā)。為了避免這種風(fēng)險(xiǎn)的發(fā)生，筆者建議在項(xiàng)目的配置管理流程中增加發(fā)布前驗(yàn)收測(cè)試環(huán)節(jié)。所有上線的發(fā)布包，必須將上線包在發(fā)布前驗(yàn)收測(cè)試環(huán)境中進(jìn)行驗(yàn)收測(cè)試。待驗(yàn)收測(cè)試通過后，方可在生產(chǎn)環(huán)境部署（見圖六）。
　　采用并行開發(fā)方式區(qū)分不同的開發(fā)活動(dòng)
　　在項(xiàng)目實(shí)際開發(fā)中，開發(fā)人員會(huì)面臨不同類型的開發(fā)活動(dòng)，如變更、缺陷、新增特性等。而不同類型的開發(fā)活動(dòng)，它的緊急程度不一樣，如果將這些開發(fā)活動(dòng)混在一起工作，那么可能因?yàn)榘姹鹃g的依賴影響項(xiàng)目的上線進(jìn)度。另外，這種工作方式也會(huì)影響項(xiàng)目測(cè)試工作的開展。由于上線計(jì)劃可能只包含部分開發(fā)活動(dòng)，導(dǎo)致測(cè)試環(huán)境有不同上線階段的開發(fā)活動(dòng)需要測(cè)試，這種方式無形中增加了運(yùn)行在生產(chǎn)環(huán)境的源碼組合為未經(jīng)測(cè)試的版本組合（見圖一）和未測(cè)試的版本（見圖二）的幾率。
　　針對(duì)這種情況，筆者建議將不同類型的開發(fā)活動(dòng)按照緊急性或類型將工作區(qū)分開來，這就涉及多個(gè)版本的并行開發(fā)，如項(xiàng)目 V1.0 的缺陷修復(fù)、V1.0 的新增功能版本 V1.1、新版本 V2.0。IBM Rational ClearCase 可以很好的支持這種并行開發(fā)模式。在 ClearCase 中，我們可以在項(xiàng)目 V1.0 的發(fā)布基線（V1.0_rel01_20071101）的基礎(chǔ)上分別創(chuàng)建針對(duì)三種版本（V1.0_bugfix、V1.1、V2.0）的開發(fā)項(xiàng)目（見圖七）。在 ClearCase 管理下，這三種版本位于不同的分支下，他們的開發(fā)是獨(dú)立的，互不影響，并且版本 V1.0_bugfix 中的缺陷修復(fù)可以及時(shí)的合并到版本 V1.1 和 V2.0 中，版本 V1.1 的新增功能也可以在需要的時(shí)候合并到版本 V2.0 中。
　　定制文件開發(fā)方式
　　在項(xiàng)目實(shí)際開發(fā)中，通常需要對(duì)文件進(jìn)行并行開發(fā)，因此存在因?yàn)槎嗳送瑫r(shí)修改同一個(gè)文件而需要對(duì)文件進(jìn)行合并的情況。對(duì)于大部分格式的源碼，配置管理工具都提供不同程度的自動(dòng)合并功能。但是對(duì)于不能合并的二進(jìn)制文件或不允許合并的文本文件（例如通過第三方開發(fā)工具導(dǎo)出的文本文件，ClearQuest 模式文件等），就不適合使用并行開發(fā)方式。因?yàn)檫@些文件或者不能合并，或者是不能通過簡(jiǎn)單的合并來實(shí)現(xiàn)版本的合并。對(duì)于這類文件如果處理不當(dāng)，就會(huì)導(dǎo)致測(cè)試時(shí)使用了錯(cuò)誤內(nèi)容的版本，導(dǎo)致測(cè)試不通過。
　　但是，在項(xiàng)目實(shí)際開發(fā)中又不能因?yàn)榇嬖谶@類特定類型的文件，而限制使用并行開發(fā)方式。串行開發(fā)與并行開發(fā)是矛盾的，如何解決這個(gè)問題是存在這類文件的項(xiàng)目在開發(fā)和測(cè)試過程中很頭痛的一個(gè)問題。IBM Rational ClearCase 可以很好的解決這個(gè)問題。我們可以利用 ClearCase 提供的強(qiáng)大的二次開發(fā)功能，為這些不能進(jìn)行合并的二進(jìn)制文件或不允許合并的文件創(chuàng)建特定的文件類型。在執(zhí)行檢出操作時(shí)，判斷該文件是否屬于已定義的特定類型文件。如果是，則判斷該文件是否已經(jīng)被檢出。如果已經(jīng)被檢出則不允許執(zhí)行檢出操作。通過這種方式，我們既可以保證大部分的源碼可以進(jìn)行并行開發(fā)，又能解決這類特定類型文件的串行開發(fā)問題。
　　明確角色與職責(zé)
　　在整個(gè)測(cè)試過程與配置管理過程中，要非常清晰項(xiàng)目的角色劃分，及角色對(duì)應(yīng)的職責(zé)，并要求相關(guān)角色人員嚴(yán)格履行各自的職責(zé)。某個(gè)大型已上線系統(tǒng)在進(jìn)行升級(jí)時(shí)就有過一次因角色與職責(zé)混淆的教訓(xùn)。在這次升級(jí)上線手冊(cè)中有“檢查四個(gè)參數(shù) A、B、C、D”這么一個(gè)步驟，測(cè)試人員在測(cè)試時(shí)發(fā)現(xiàn)測(cè)試環(huán)境因沒有這四個(gè)參數(shù)而導(dǎo)致了測(cè)試失敗，于是測(cè)試人員聯(lián)系開發(fā)人員，得知?jiǎng)?chuàng)建這四個(gè)參數(shù)的方法，以及需要設(shè)置的參數(shù)值。然后測(cè)試人員在測(cè)試環(huán)境自行創(chuàng)建了這四個(gè)參數(shù)。由于正確設(shè)置了這四個(gè)參數(shù)后，此次升級(jí)測(cè)試通過。當(dāng)該升級(jí)包提交運(yùn)維組部署到生產(chǎn)環(huán)境時(shí)，運(yùn)維組按照上線手冊(cè)要求檢查了生產(chǎn)環(huán)境，發(fā)現(xiàn)生產(chǎn)環(huán)境有這四個(gè)參數(shù)（但不是開發(fā)人員期望設(shè)置的值），并且有測(cè)試組提供的測(cè)試報(bào)告，于是他們將升級(jí)包按照上線手冊(cè)步驟部署到生產(chǎn)環(huán)境。但是上線后由于這四個(gè)參數(shù)設(shè)置了錯(cuò)誤的值，導(dǎo)致系統(tǒng)停產(chǎn) 40 多分鐘。
　　在這個(gè)事故中，開發(fā)人員與開發(fā)人員都有責(zé)任。測(cè)試人員未按照上線手冊(cè)要求完成他的工作（只是“檢查”，而不是“創(chuàng)建”），這本身就是一個(gè)違規(guī)操作。另外，他沒有將實(shí)際情況與上線手冊(cè)的不一致向開發(fā)組提出并由開發(fā)組更新上線手冊(cè)，在開發(fā)組提交更新后的上線手冊(cè)后，測(cè)試組重新檢查測(cè)試環(huán)境并測(cè)試。開發(fā)人員則未在上線手冊(cè)寫明參數(shù)具體設(shè)置的值，上線手冊(cè)存在不明確信息。
　　所以在項(xiàng)目的各個(gè)過程，包括軟件測(cè)試過程和配置管理過程中，一定需要明確各角色相應(yīng)的職責(zé)及工作范圍，避免類似事故的發(fā)生。
　　配置管理貫穿于項(xiàng)目所有過程中，本文主要從軟件測(cè)試的角度分析了測(cè)試中經(jīng)常碰到的問題，闡述了軟件測(cè)試和配置管理之間的密切關(guān)系。為了解決測(cè)試中存在的配置管理問題，筆者針對(duì)測(cè)試過程常見問題產(chǎn)生的原因，從配置管理角度給出了相應(yīng)的解決方案。筆者希望通過本文，能夠改變軟件測(cè)試工作中不需要關(guān)注配置管理的錯(cuò)誤思想。
項(xiàng)目管理師考試資料庫
點(diǎn)擊進(jìn)入：考試大項(xiàng)目管理師考試在線模擬測(cè)試
考試大項(xiàng)目管理師考試網(wǎng)校課堂