測試項目總結(jié)精選(九篇)

前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的測試項目總結(jié)主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：測試項目總結(jié)范文

1 試驗?zāi)康?/p>

我市是傳統(tǒng)的花生生產(chǎn)大市，每年花生種植面積有10多萬畝，是我市人民解決食用油來源的主要渠道之一。為了建立我市花生生產(chǎn)中施肥的技術(shù)指標(biāo)體系，提高花生的產(chǎn)量和品質(zhì)，降低施肥成本，減少因盲目施肥對生態(tài)環(huán)境造成的危害，特進(jìn)行了本試驗。

2 試驗地點

試驗地為桂平市蒙圩鎮(zhèn)新建村第五村民小組張桂明戶承包的水田，經(jīng)度109°59′，緯度23°19′，海撥47.9米。

3 試驗材料

3.1 肥料 尿素N：46.5%；過磷酸鈣P2O5：14%；氯化鉀K2O：60%。

3.2 花生種 本地良種82號。

4 試驗地情況

沖積沙壤土，耕層厚度20厘米，排灌方便，前作為水稻。整地前按“五點”取樣采集混合樣本進(jìn)行分析化驗：PH：5.1；有機質(zhì)：20.6g/kg；全氮：1.37g/kg；有效磷：38.3mg/kg；緩效鉀：118.7 mg/kg；速效鉀64 mg/kg。

5 試驗設(shè)計

5.1 試驗采用 《農(nóng)業(yè)部測土配方施肥技術(shù)規(guī)程》3414完全實施方案設(shè)置田間小區(qū)肥效試驗

見表（一）。

“3414”設(shè)計方案指氮、磷、鉀3個因素，高、中、低，空白4個水平，14個處理。2水平指當(dāng)?shù)刈罴咽┓柿康耐扑]值（本試驗為：N：P2O5：K2O=6：3：9），1水平=2水平×0.5，3水平=2水平×1.5，0水平指不施肥。

5.2 試驗小區(qū)形狀 試驗小區(qū)長21米、寬2×0.8米=1.6米。面積33.6平方米。

5.3 種植規(guī)格 80×16.7厘米，雙行雙粒均勻點播，雙行間距20厘米，畝播花生仁1.8-2.0萬粒。每小區(qū)點播花生仁1000粒。試驗小區(qū)四周設(shè)不少于1.0米的保護(hù)行。

5.4 施肥 所有肥料全部用做基肥，在播種時于雙行間開溝施下。

6 試驗過程

3月11日播種，3月18日出苗，3月21日齊苗，4月28日始花，5月10日盛花，7月16日成熟收獲。

7 試驗結(jié)果和肥料產(chǎn)量效應(yīng)回歸分析

7.1 試驗的產(chǎn)量結(jié)果和主要經(jīng)濟(jì)性狀見表二

7.2 回歸方程肥料效應(yīng)擬合結(jié)果見表

8 試驗結(jié)論：

（1）試驗中氮、磷、鉀各養(yǎng)份單因素或綜合因素對花生產(chǎn)量的影響均達(dá)到顯著水平。說明花生栽培中增施N、P、K養(yǎng)份是有顯著增產(chǎn)效果的。

（2）氮、磷、鉀各元素對花生產(chǎn)量的影響遵循著拋物線模型。即。

氮：每畝N的施用量在04.31―5.85公斤之間時，花生產(chǎn)量會隨著N施用量的增加而增加，當(dāng)每畝N 的施用量大于5.85公斤時，N的產(chǎn)量效應(yīng)則會隨著N施用量的增加而減少。

磷：每畝P2O5的施用量在O1.35―2.48公斤之間時，花生產(chǎn)量會隨著磷施用量的增加而增加，當(dāng)磷的施用量大于每畝2.48公斤時，P2O5的產(chǎn)量效應(yīng)則會隨著磷養(yǎng)份施用量的增加而減少。

鉀：每畝K2O施用量在O4.23―7.68公斤之間時，花生的產(chǎn)量會隨著鉀養(yǎng)份施用量的增加而增加，當(dāng)鉀的施用量大于每畝7.68公斤時，K2O的產(chǎn)量效應(yīng)會隨著鉀養(yǎng)份施用量的增加而減少。

第2篇：測試項目總結(jié)范文

關(guān)鍵詞：國產(chǎn)化平臺；信息系統(tǒng)；軟件測試

計算機軟硬件實現(xiàn)自主可控是國家重要的發(fā)展規(guī)劃，近年來國產(chǎn)化軟件平臺取得了長足發(fā)展，操作系統(tǒng)、數(shù)據(jù)庫、辦公軟件、中間件等均已出現(xiàn)不少商用國產(chǎn)化產(chǎn)品，為信息系統(tǒng)能夠采用國產(chǎn)化平臺進(jìn)行研發(fā)奠定了基礎(chǔ)。軟件測試作為軟件研發(fā)領(lǐng)域中的重要一環(huán)，直接影響軟件產(chǎn)品質(zhì)量，一直備受重視［1］。軟件測試與軟件開發(fā)緊密相連，軟件研發(fā)采用國產(chǎn)化平臺實現(xiàn)，這對軟件測試有著重要的影響，決定著軟件測試所需要的技術(shù)，因此研究國產(chǎn)化平臺下的軟件測試具有重要意義。相比于非國產(chǎn)化軟件平臺，國產(chǎn)化軟件平臺起步晚，發(fā)展時間短，其對應(yīng)的軟件測試技術(shù)也比較欠缺，尤其是在配套的測試軟件方面。本文通過分析軟件測試關(guān)鍵活動，根據(jù)國產(chǎn)化軟件測試技術(shù)現(xiàn)狀，提出一種適應(yīng)于國產(chǎn)化平臺信息系統(tǒng)軟件測試技術(shù)。

1信息系統(tǒng)軟件測試分析

信息系統(tǒng)軟件測試在不同研發(fā)模型中所分階段不同，而區(qū)別于不同的研發(fā)模型，整個軟件測試過程一般都需要經(jīng)過測試策劃、測試設(shè)計、測試執(zhí)行、測試總結(jié)四個基本活動。測試策劃活動主要進(jìn)行需求分析，識別軟件測試項、測試所需軟硬件、人力資源等；測試設(shè)計活動主要根據(jù)識別的軟件測試項設(shè)計測試用例，包括手工測試用例、自動化測試用例等；測試執(zhí)行活動通過手工、自動執(zhí)行測試，發(fā)現(xiàn)軟件缺陷，進(jìn)行軟件缺陷歸零驗證；測試總結(jié)活動對測試執(zhí)行結(jié)果進(jìn)行整理分析，編寫測試報告。同樣的，基于國產(chǎn)化平臺研發(fā)的信息系統(tǒng)軟件測試亦需要經(jīng)過測試策劃、測試設(shè)計、測試執(zhí)行、測試總結(jié)四個活動。1）測試策劃活動進(jìn)行需求分析、識別軟件測試項依賴于軟件自身需求，其與研發(fā)平臺具有無關(guān)性，識別測試所需的軟硬件則取決于研發(fā)平臺。目前國產(chǎn)化平臺的測試工具也面臨著起步晚、發(fā)展時間短的問題，應(yīng)用于國產(chǎn)化平臺的軟件測試工具種類遠(yuǎn)沒有豐國產(chǎn)化平臺軟件測試工具豐富［2］。測試策劃過程中需要識別出可用于國產(chǎn)化平臺的測試軟件是其要解決的重要問題，一方面取決于已有的測試軟件，另一方面取決于信息系統(tǒng)的技術(shù)實現(xiàn)。2）測試設(shè)計活動所編寫的手工測試用例取決于被測信息系統(tǒng)軟件自身，而編寫自動化測試用例則取決于所使用的自動化測試平臺，不同的自動化測試平臺所適用的軟件類別不同?；趪a(chǎn)化的自動化測試平臺選擇范圍小，且成熟度相比于非國產(chǎn)化平臺并不高。因此測試設(shè)計階段所面臨的是被測信息系統(tǒng)軟件的可實現(xiàn)自動化測試的用例覆蓋程度問題。3）測試執(zhí)行活動一方面是執(zhí)行測試用例，另一方面還需要對軟件缺陷進(jìn)行分析定位，對被測信息系統(tǒng)的內(nèi)存、CPU、網(wǎng)絡(luò)、磁盤IO等指標(biāo)進(jìn)行監(jiān)控，其對國產(chǎn)化平臺依賴性較高。國產(chǎn)化平臺的操作系統(tǒng)、數(shù)據(jù)庫、中間件乃至辦公軟件所提供的分析、監(jiān)控工具直接影響著軟件測試的執(zhí)行和軟件缺陷的分析定位。目前，國產(chǎn)計算機環(huán)境的應(yīng)用面、規(guī)模相對較小，應(yīng)對復(fù)雜環(huán)境時，兼容性、綜合性能、可靠性驗證不充分，缺乏有效的診斷分析工具和測試評估環(huán)境［1］。測試執(zhí)行過程中面臨著如何充分利用國產(chǎn)化平臺所提供的分析和監(jiān)控工具完成測試執(zhí)行、如何通過第三方輔助軟件解決國產(chǎn)化平臺自身不具備的功能完成測試執(zhí)行的問題。4）測試總結(jié)活動為測試過程的最后一個活動，對測試執(zhí)行的結(jié)果進(jìn)行整理分析。對于國產(chǎn)化平臺研發(fā)的信息系統(tǒng)，測試總結(jié)需要分析前幾項測試活動的結(jié)果形成測試報告，還需要對測試技術(shù)形成積累，為基于國產(chǎn)化平臺信息系統(tǒng)的軟件測試持續(xù)發(fā)展提供經(jīng)驗。圖1為信息系統(tǒng)軟件測試活動圖以及基于國產(chǎn)化平臺進(jìn)行軟件測試活動的所要解決的關(guān)鍵問題。

2軟件測試技術(shù)應(yīng)用

2．1測試策劃

國產(chǎn)化平臺信息系統(tǒng)軟件測試策劃活動所面臨的主要問題是識別測試所需軟件項，應(yīng)用于項目，需要結(jié)合項目自身特點。每個項目的系統(tǒng)架構(gòu)、軟件開發(fā)語言、運行環(huán)境等各不一樣，因此在識別時結(jié)合被測軟件，從三個方面解決測用所需軟件：開源軟件［3］、商用軟件、自研軟件。圖2所示在項目測試過程中開源軟件、商用軟件、自研軟件選擇比重，其中開源軟件選擇優(yōu)先，其次可通過自研軟件、商用軟件覆蓋測試所需。1）開源軟件具有成本低、靈活性高、自由的優(yōu)勢，國產(chǎn)化平臺信息系統(tǒng)識別測試所需軟件項可以優(yōu)先從開源軟件中選擇，獲取滿足項目軟件功能測試、性能測試、接口測試、安全測試、可靠性測試等測試類型的開源軟件。2）開源軟件在支持方面、文檔方面、穩(wěn)定性方面不如商業(yè)軟件，對于測試軟件要求高的項目可選擇商用軟件進(jìn)行支撐。商用軟件具有支持度高、日常更新、技術(shù)難度低的優(yōu)勢，采用商用軟件可以避免測試過程中的一些無法解決問題。3）商用軟件所提供的是適用于大多數(shù)用戶需求的接口，對于被測軟件，在不同的測試階段、不同測試類型中，存在商用軟件無法實現(xiàn)測試內(nèi)容的場景，需要項目通過研發(fā)專用測試工具以實現(xiàn)測試覆蓋，解決測試軟件問題。

2．2測試設(shè)計

測試設(shè)計過程中可以通過編寫自動化測試用例代替手工測試的反復(fù)操作，自動化測試用例覆蓋率高可以有效地提高測試用例復(fù)用率和執(zhí)行效率?；趪a(chǎn)化平臺信息系統(tǒng)軟件自動化測試在采用的自動化測試平臺上，可以通過不同維度的測試用例設(shè)計增加自動化測試用例覆蓋率，即分別從單元測試、接口測試、GUI測試分別設(shè)計自動化測試用例［4］。自動化軟件測試用例設(shè)計一般遵循圖3所示的三角形用例覆蓋率比例，單元測試與代碼直接相關(guān)，軟件代碼改動對單元自動化用例的影響較小，單元測試自動化用例覆蓋率最高，其次是接口測試自動化用例。GUI自動化測試用例實現(xiàn)難度高，且受代碼改動影響大，因此其自動化測試用例覆蓋率最低。國產(chǎn)化平臺信息系統(tǒng)軟件自動化測試平臺缺少Q(mào)TP、Loadrunner等工具，目前只有少數(shù)自動化平臺支持國產(chǎn)化操作系統(tǒng)，如kylinTOP自動化測試工具，除此之外，還可以采用Selenium、Python等實現(xiàn)自動化測試。此類軟件對于GUI自動化測試與非國產(chǎn)化軟件類似，因此國產(chǎn)化平臺信息系統(tǒng)自動化測試用例亦需要遵循圖3的測試用例覆蓋率。

2．3測試執(zhí)行

在測試執(zhí)行過程中需要對信息系統(tǒng)軟件缺陷進(jìn)行分析定位、對信息系統(tǒng)的指標(biāo)進(jìn)行監(jiān)控。信息系統(tǒng)的缺陷分析和指標(biāo)監(jiān)控包括兩部分，一部分與依賴的國產(chǎn)化平臺相關(guān)，另一部分與信息系統(tǒng)軟件自身相關(guān)。與國產(chǎn)化平臺相關(guān)的缺陷分析和指標(biāo)監(jiān)控可以采用國產(chǎn)化平臺自持軟件，目前國產(chǎn)操作系統(tǒng)、國產(chǎn)數(shù)據(jù)庫軟件、國產(chǎn)中間件軟件等均具備滿足監(jiān)控平臺自身指標(biāo)的工具［5］?；趪a(chǎn)化平臺的第三方測試工具如WGCLOUD、PIGOSS、SugarNMS等可以實現(xiàn)多平臺、分布式監(jiān)控。表1為這三款工具軟件可支持的國產(chǎn)化平臺以及可用于信息系統(tǒng)軟件測試的監(jiān)控項。

2．4測試總結(jié)

測試總結(jié)活動是對之前幾項測試活動的總結(jié)，在測試執(zhí)行完成后對各項測試活動進(jìn)行整理分析，形成測試報告?；趪a(chǎn)化平臺的信息系統(tǒng)軟件研發(fā)還未廣泛開展，對應(yīng)的軟件測試技術(shù)也需要不斷的探索與研究，相比于非國產(chǎn)化平臺的軟件測試，國產(chǎn)化平臺信息系統(tǒng)的軟件測試不再僅限于單一項目，還需要與其他項目的測試策劃相關(guān)聯(lián)。因此測試總結(jié)活動還需要以資源池的形式進(jìn)行技術(shù)積累，將整個測試過程中的軟件測試方法、測試工具、測試分析等進(jìn)行技術(shù)儲備與傳播，為其他國產(chǎn)化平臺的軟件測試提供借鑒。同樣的，在其他項目的軟件測試策劃活動中，可以從資源池中的技術(shù)儲備選取用于支撐整個項目測試的技術(shù)。

第3篇：測試項目總結(jié)范文

以下對我在xxxx年所做的工作進(jìn)行全面總結(jié)：

1、團(tuán)隊管理

我的團(tuán)隊，以現(xiàn)在的表現(xiàn)和對我的關(guān)懷與安慰而讓我感動。

測試人員是一個比較特殊的群體，以發(fā)現(xiàn)缺陷和保障質(zhì)量為根本目標(biāo)。這就要求我們在公司并不規(guī)范的項目管理與工作流程背景下，測試既要服從于現(xiàn)狀、又不能安于現(xiàn)狀。自xxxx年x月被正式提升為測試團(tuán)隊負(fù)責(zé)人之后，我將絕大部分時間和精力傾注在團(tuán)隊建設(shè)上，主要體現(xiàn)為團(tuán)隊成員的技術(shù)提升與培養(yǎng)、部門制度建設(shè)和文檔標(biāo)準(zhǔn)建設(shè)、測試與開發(fā)的工作交互流程等。

在團(tuán)隊管理上逐漸嘗試，本著先理后管的原則，將原本人心渙散的團(tuán)隊建設(shè)為一支相互關(guān)心、相互幫助的高凝聚力團(tuán)隊。坦白的講，因為自身管理經(jīng)驗的欠缺，這個摸索過程中我走了許多彎路，但結(jié)果卻使我受益良多。是我的團(tuán)隊教會了我這些，讓我初步懂得了什么是管理，讓我明白管的是理而并非是人。如果事情難以理通，那么在此之上的管只能是強制的，僅僅在表象上完成事情而已。所以一定要先理清楚然后再管，這時其實已經(jīng)不需要管了，因為已經(jīng)理順，大家都會去積極主動的執(zhí)行。有理的同時，還要幫助整個團(tuán)隊去整理，給予團(tuán)隊每位成員必要的工作幫助，比如工作思路和工作資源。除此之外，還包括適當(dāng)?shù)娜粘贤ê退枷胍龑?dǎo)，通過績效考核、部門例會、部門培訓(xùn)、單人交談和部門聚會等形式，在工作時間和非工作時間進(jìn)行交流，實現(xiàn)了團(tuán)隊成員之間的相互信任和相互認(rèn)可。

在這個過程中，我的性格優(yōu)勢得以充分體現(xiàn)，我能夠在第一時間發(fā)覺團(tuán)隊成員的狀態(tài)異常，并通過及時的交談予以解決，同時也體現(xiàn)出了我的性格劣勢。記得在一次例會結(jié)束后，我要求每位團(tuán)隊成員寫出5條關(guān)于我的意見和建議，結(jié)果讓我非常欣慰，這說明團(tuán)隊成員對我的信任，也期望我有所成長。我也會以此為戒，逐漸改進(jìn)。

2、團(tuán)隊工作

對工作模式進(jìn)行改進(jìn)，在團(tuán)隊工作的執(zhí)行模式上完全改變了之前測試人員歸屬項目組的不規(guī)范情況。統(tǒng)一測試管理平臺增強了測試人員的溝通頻度，促進(jìn)了大家的相互交流和相互幫助，并使得測試工作可以根據(jù)實際情況執(zhí)行交互性測試。

綜合xxxx年的測試結(jié)果，我至少為整個團(tuán)隊的表現(xiàn)打90分，可以說這一年的工作結(jié)果是令人滿意的，當(dāng)然主要是指經(jīng)歷了八月調(diào)整之后的測試團(tuán)隊。最讓人難忘的是xxxx年的八月、九月和十月期間，測試團(tuán)隊剛剛經(jīng)歷了八月末的人員調(diào)整，以3舊1新的4人陣容承擔(dān)了原來7人的工作量，并在高強度的工作壓力下順利的度過了團(tuán)隊調(diào)整期。面對這一充滿壓力的過程，我想，只有兔子在哪里的故事是讓大家難以忘記的。

如今的測試團(tuán)隊有著完備的內(nèi)部機制和運作方式，我們已經(jīng)做好了相應(yīng)準(zhǔn)備，隨時應(yīng)對公司發(fā)展所必須的各種調(diào)整。

3、個人工作

xxxx年xx月初，我已向郭總提交一份xxxx年xx月x日到xxxx年3月的工作總結(jié)，其中所描述的工作內(nèi)容均為當(dāng)時參與的arpt項目的工作進(jìn)展情況。自xxxx年x月開始，我與項目組全體成員參與了arpt奧運項目的投標(biāo)文件編寫工作，這也是我第一次參與標(biāo)書編寫，但從自身來講，我已經(jīng)傾盡全部所能。

在標(biāo)書編寫結(jié)束后，除繼續(xù)負(fù)責(zé)arpt軟件的測試外，逐漸將工作重心向團(tuán)隊建設(shè)偏移。在合理分配工作任務(wù)的前提下，適當(dāng)從事部分模塊的測試工作。關(guān)于團(tuán)隊管理內(nèi)容，之前已經(jīng)有所介紹，在此不再贅述。

4.、總結(jié)

年終結(jié)束，我的人生觀和價值觀也隨著時間的推移而逐步發(fā)生改變，更加清晰的了解了自身優(yōu)勢與不足，包括職業(yè)發(fā)展過程中的一些必要能力，我也會在此經(jīng)驗的基礎(chǔ)上漸漸的總結(jié)和調(diào)整。

第4篇：測試項目總結(jié)范文

測試管理人員：我與企業(yè)共成長

校園回憶如一夢，遇見你仿佛很久。測試工作在中采購和網(wǎng)絡(luò)建設(shè)中發(fā)揮重要作用，2018年5月，我有幸加入測試中心這個大家庭。測試中心，顧名思義承擔(dān)著絕大部分測試工作，尤其是采購和網(wǎng)絡(luò)建設(shè)項目測試，測試工作在網(wǎng)絡(luò)建設(shè)中發(fā)揮重要作用，為現(xiàn)網(wǎng)運營及質(zhì)量提升提供技術(shù)保障。測試中心通過多年的測試經(jīng)驗積累，持續(xù)建設(shè)測試管理體系并逐步推廣到全院。2016年歸口全院測試質(zhì)量管理，建立獨立測試質(zhì)量監(jiān)督團(tuán)隊，測試工作管理辦法進(jìn)一步規(guī)范測試工作，明確了十三項管理措施，通過三項創(chuàng)新管理方式，做到行為有依據(jù)、監(jiān)督有抓手、提升有建議。

紙上得來終覺淺，絕知此事要躬行。作為研究院測試管理團(tuán)隊的一員，入職伊始我就參與了《管理辦法》第二次修訂工作，小小的一本《管理辦法》，卻是研究院的重大制度，我的工作也圍繞它展開了。難以忘記萍慧姐親自為我細(xì)細(xì)解讀難懂的業(yè)務(wù)用語，難以忘記秦倩帶我去測試現(xiàn)場查看測試項目及文檔檢查，難以忘記新妍與我共同梳理百條測試澄清信息、整理歸檔測試文件，短短幾個月仿佛經(jīng)歷了很多，讓我對于測試管理工作越來越熟悉，也逐漸體會到測試管理的要旨是為了讓測試工作越來越好，流程質(zhì)量有保證，工作效率才能真正得到提升，意義非凡。

欲窮千里目，更上一層樓。測試管理發(fā)現(xiàn)問題要有處理機制，通過不斷的理論研究和實踐經(jīng)驗，我們建立“建章立制-有效監(jiān)督-數(shù)據(jù)挖掘-階梯上升”四步走的測試澄清閉環(huán)模型，深入測試澄清全生命周期，覆蓋率100%。測試管理不能只執(zhí)行不總結(jié)，通過深入分析2017年以來全部121個測試澄清，總結(jié)歸納提升建議40余條，規(guī)范測試執(zhí)行，加強測試管理，并通過事后改進(jìn)，事先預(yù)警機制針對性解決項目存在問題，部分測試澄清問題復(fù)現(xiàn)率下降70%，測試項目質(zhì)量大大提升，測試領(lǐng)域也從有投訴到無投訴，測試人員從被動響應(yīng)到主動實施，得到專業(yè)部所領(lǐng)導(dǎo)、研究院院領(lǐng)導(dǎo)和集團(tuán)采購共享中心等需求部門的一致認(rèn)可。測試管理也要配合公司IT進(jìn)程戰(zhàn)略，實現(xiàn)自動化，通過不斷總結(jié)修改需求、設(shè)計流程，我們的測試管理系統(tǒng)終于初建模型，即將上線了，相信它一定可以發(fā)揮不凡的作用。測試管理不能只懂管理更要懂得技術(shù)，新一年的工作計劃中，我為自己制定了技術(shù)學(xué)習(xí)路線，感謝移動研究院這個很好的平臺，讓我可以學(xué)習(xí)和接觸到很多通信領(lǐng)域的知識，深入測試現(xiàn)場，切身體會測試工程師日常工作，才能更好地做好測試管理，而不是讓管理飄在云端。

愛她的人與好風(fēng)光。我司除了完善的技術(shù)平臺更有豐富的文娛活動。精彩的新員工培訓(xùn)讓我感受到欣欣向榮、朝氣勃發(fā)的企業(yè)文化；測試中心黨支活動，讓我很快融入，感受到大家庭的溫暖；研究院工會數(shù)不清的文藝課程，全方面關(guān)照員工訴求，水彩課上我有了人生總第一幅藝術(shù)作品。感謝我的組織，我與企業(yè)共成長！

第5篇：測試項目總結(jié)范文

關(guān)鍵詞：CMM；軟件開發(fā)；軟件測試

中圖分類號：TP311文獻(xiàn)標(biāo)識碼：A文章編號：1009-3044(2007)17-31397-02

Based on CMM Software Development and Testing

YANG Guang

(Northeastern University College of Software,Shenyang 110004,China)

Abstract:Demand for software development, including design, programming and testing, and software quality assurance testing software is the key steps have been more and more people's attention. Currently, the CMM (Capability Maturity Model, Capability Maturity Model) has become the world's most popular, most practical kind of software production process standards, received international recognition software industry has become in today's enterprise-scale software as an indispensable. In software development and testing process, the characteristics of the enterprise itself, using the CMM software development management processes, to improve software development quality and efficiency.

Key words:CMM;software development;software testing

1 引言

軟件開發(fā)包括需求、設(shè)計、編程和測試，而軟件測試是軟件質(zhì)量保證的關(guān)鍵步驟，已經(jīng)得到人們越來越多的重視。目前，CMM （Capability Maturity Model，能力成熟度模型）已經(jīng)成為國際上最流行、最實用的一種軟件生產(chǎn)過程標(biāo)準(zhǔn)，得到了國際軟件產(chǎn)業(yè)界的認(rèn)可，成為當(dāng)今企業(yè)從事規(guī)模軟件生產(chǎn)不可缺少的一項內(nèi)容。2000年，國務(wù)院的《鼓勵軟件產(chǎn)業(yè)和集成電路產(chǎn)業(yè)發(fā)展的若干政策》中第17條中表示，將對軟件出口型企業(yè)CMM認(rèn)證費用予以適當(dāng)支持。如今，國內(nèi)企業(yè)也越來越重視基于CMM的軟件開發(fā)和測試。

2 CMM簡介

20 世紀(jì) 80 年代中期，國際軟件產(chǎn)業(yè)界對軟件過程的研究十分重視，因為在采用軟件工程方法克服軟件危機的過程中，人們已認(rèn)識到，軟件過程是否完善是軟件風(fēng)險大小的決定因素。1986 年 11 月，美國卡內(nèi)基梅隆大學(xué)的軟件工程研究所（ Software Engineering Institute ， SEI ）應(yīng)美國聯(lián)邦政府的要求，針對美國國防部對軟件承包商的能力評價問題，研究 “ 過程成熟度框架 ”。1987 年 9 月， SEI 開發(fā)了一套軟件能力成熟度框架和軟件成熟度問卷，用來評估軟件供應(yīng)商的能力。1991 年， SEI 自己總結(jié)了成熟度框架和初版成熟度問卷的實踐經(jīng)驗，并以此為基礎(chǔ)推出了 “軟件能力成熟度模型（ Capability Maturity Model For Software ， CMM ） 1.0 版 ”。1993 年， SEI 在廣泛聽取美國政府和各界軟件專家的意見后，推出了目前世界上比較流行的通用的 CMM1.1 版。

CMM是一個用來描述軟件組織的模型，用于評價軟件承包能力并幫助其改善軟件質(zhì)量的方法。CMM是評估軟件能力與成熟度的一套標(biāo)準(zhǔn)，它側(cè)重于軟件開發(fā)過程的管理和工程能力的提高與評估。CMM表現(xiàn)了軟件組織能力成熟度的特稱，確切的說，CMM是在軟件流程上的能力成熟度。 CMM將軟件組織抽象為能力成熟度模型。能力成熟度是軟件組織解決“按時，按計劃，高質(zhì)量”這一問題的關(guān)鍵因素，而CMM的目的，就是要幫助軟件組織在進(jìn)度和預(yù)算范圍之內(nèi)生產(chǎn)出高質(zhì)量的軟件產(chǎn)品。

CMM標(biāo)準(zhǔn)共分五個等級（5級為最高級別），是一個動態(tài)的過程，企業(yè)可根據(jù)不同級別的要求，循序漸進(jìn)，不斷改進(jìn)。從第一級到第五級分別為：初始級、可重復(fù)級、定義級、管理級和優(yōu)化級，從低到高，軟件開發(fā)生產(chǎn)的計劃精度越來越高，每單位工程的生產(chǎn)周期越來越短，每單位工程的成本也越來越低。

3 基于CMM的軟件開發(fā)與測試

CMM是一種管理方法，是一個軟件過程改進(jìn)框架，這個框架與軟件生命周期無關(guān)，也與采用的技術(shù)無關(guān)。CMM目前代表著軟件發(fā)展的一種思路，一種提高軟件過程能力的途徑。盡管它存在著某些不足。例如，成熟級別、關(guān)鍵過程域、公共屬性和關(guān)鍵實踐還需要在軟件行業(yè)進(jìn)一步深入地討論和修訂，但它確實為軟件行業(yè)的發(fā)展提供了一個良好的框架，而且是濃度軟件過程能力提高的有用工具。增強我國軟件企業(yè)的競爭力，提高國產(chǎn)軟件的水平是國人的共同愿望，但目前我國軟件水平，尤其是軟件開發(fā)能力和軟件生產(chǎn)能力還很差。那么，如何提高我國軟件的開發(fā)和生產(chǎn)能力，從而提高軟件整體水平？軟件企業(yè)實施基于CMM的軟件開發(fā)與測試也許不失為一條有效的途徑。

按照CMM要求將開發(fā)分為九個階段：項目規(guī)劃、小組啟動、需求分析、概要設(shè)計、詳細(xì)設(shè)計、編碼調(diào)試、系統(tǒng)集成與測試、驗收、項目關(guān)閉。其中軟件的測試是軟件開發(fā)過程的重要組成部分，是用來確認(rèn)一個程序的品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求。軟件測試就是在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼的最終復(fù)審。

下面從各個階段主要項目活動、階段交付文檔和評審點出發(fā)，詳細(xì)描述項目開發(fā)的各個階段。

(1)項目規(guī)劃

項目規(guī)劃要對所要解決的問題進(jìn)行總體定義，包括了解用戶的要求及現(xiàn)實環(huán)境。計劃階段要從技術(shù)、經(jīng)濟(jì)和社會等3個方面研究并論證本軟件項目的可行性，編寫可行性研究報告，探討解決問題的方案，并對可供使用的資源（如計算機硬件、系統(tǒng)軟件、人力等）成本，可取得的效益和開發(fā)進(jìn)度做出估計，以制訂完成開發(fā)任務(wù)的實施計劃。另外，項目的相關(guān)人員提出創(chuàng)新性的想法，并對自己的想法進(jìn)行可行性分析，研究新想法的問題范圍，探索這個問題是否值得去解決，是否有大概的解決辦法，并對需要的資源進(jìn)行估計。

本階段的交付文檔是立項說明書，立項說明書必須提交工程委員會進(jìn)行評審。如果評審不通過，項目就此結(jié)束。

(2)小組啟動

在項目立項評審后，根據(jù)先前的資源估計成立項目開發(fā)小組，確立開發(fā)小組中各個角色的成員，然后對項目開發(fā)需要的軟件和硬件資源進(jìn)行分配，并搭建好項目開發(fā)環(huán)境。結(jié)合項目最后的期限要求以及分析CMM 歷史度量庫，確立項目開發(fā)的一級計劃，確定以下各個開發(fā)階段的評審點。本階段的交付文檔主要有項目計劃書和小組啟動說明書。項目計劃書必須經(jīng)過工程委員會的評審，如果評審?fù)ú贿^，必須參考CMM的歷史度量庫來修改項目計劃直至通過評審。

(3)需求分析

需求分析是一個對用戶的需求進(jìn)行去粗取精、去偽存真、正確理解，然后把需求用軟件工程開發(fā)語言（形式功能規(guī)約，即需求規(guī)格說明書）表達(dá)出來的過程。分析階段的基本任務(wù)是和用戶一起確定要解決的問題，建立軟件的邏輯模型，編寫需求規(guī)格說明書文檔并最終得到用戶的認(rèn)可。需求分析的主要方法有結(jié)構(gòu)化分析方法、數(shù)據(jù)流程圖和數(shù)據(jù)字典等方法。

基于CMM的需求分析階段更注重項目的管理流程。首先項目組要確立在該階段的二級計劃，然后開始需求分析，明確需要開發(fā)系統(tǒng)必須具備的功能。并要主動與用戶交流，獲取需求并分析需求。制定相應(yīng)的系統(tǒng)測試計劃，在這以后的每個階段項目組長都必須提交階段工作報告。

CMM的需求分析階段主要交付的文檔有更新后的項目計劃書、需求跟蹤矩陣、需求分析說明書、系統(tǒng)測試計劃書、項目詞匯表和階段工作報告。需求分析說明書必須提交給工程委員會評審，只有在評審?fù)ㄟ^后，才能進(jìn)入下一個開發(fā)階段。

(4)概要設(shè)計

一般軟件設(shè)計可以分為概要設(shè)計和詳細(xì)設(shè)計兩個階段。實際上軟件設(shè)計的主要任務(wù)就是將軟件分解成模塊。概要設(shè)計就是結(jié)構(gòu)設(shè)計，其主要目標(biāo)就是給出軟件的模塊結(jié)構(gòu)，用軟件結(jié)構(gòu)圖表示。

基于CMM的概要設(shè)計階段不但要為系統(tǒng)描述系統(tǒng)流程圖、構(gòu)建系統(tǒng)的可能方案、確立的系統(tǒng)總體方案和進(jìn)行模塊劃分及設(shè)計。而且還有進(jìn)行一些系統(tǒng)的集成測試計劃和設(shè)計評審等工作。該階段主要的交付文檔為更新的項目計劃書、更新的需求跟蹤矩陣、編程規(guī)范、概要設(shè)計說明書(包含總體方案)、集成測試計劃書、意見反饋單、階段工作報告。各個模塊的概要設(shè)計說明書和總體方案必須經(jīng)過評審。

(5)詳細(xì)設(shè)計

詳細(xì)設(shè)計階段是對概要設(shè)計的結(jié)果的細(xì)化，概要設(shè)計已經(jīng)達(dá)到函數(shù)級的分解，詳細(xì)設(shè)計是對分解的函數(shù)進(jìn)行實現(xiàn)的描述。一般詳細(xì)設(shè)計的首先要設(shè)計模塊的程序流程、算法和數(shù)據(jù)結(jié)構(gòu)，其次，要設(shè)計數(shù)據(jù)庫，常用方法還是結(jié)構(gòu)化程序設(shè)計方法。

基于CMM的詳細(xì)設(shè)計階段必須依次補充完善需求跟蹤矩陣，并確立單元測試計劃和進(jìn)行評審。該階段的交付文檔為更新的項目計劃書、更新的需求跟蹤矩陣、詳細(xì)設(shè)計說明書、單元測試計劃書、意見反饋單和階段工作報告。各個模塊的詳細(xì)設(shè)計必須經(jīng)過評審。

(6)編碼調(diào)試

軟件編碼是指把軟件設(shè)計轉(zhuǎn)換成計算機可以接受的程序，即寫成以某一程序設(shè)計語言表示的"源程序清單"。充分了解軟件開發(fā)語言、工具的特性和編程風(fēng)格，有助于開發(fā)工具的選擇以及保證軟件產(chǎn)品的開發(fā)質(zhì)量。當(dāng)前軟件開發(fā)中除在專用場合，已經(jīng)很少使用二十世紀(jì)80年代的高級語言了，取而代之的是面向?qū)ο蟮拈_發(fā)語言。而且面向?qū)ο蟮拈_發(fā)語言和開發(fā)環(huán)境大都合為一體，因此大大提高了開發(fā)的速度。

基于CMM的編碼調(diào)試階段的任務(wù)包括：①項目組制定出在本階段的二級計劃；②學(xué)習(xí)確認(rèn)編程規(guī)范，再開始編碼，同時必須進(jìn)行同行檢查和走讀檢視；③進(jìn)行單元測試。一般認(rèn)為單元測試應(yīng)緊接在編碼之后，當(dāng)源程序編制完成并通過復(fù)審和編譯檢查，便可開始單元測試。測試用例的設(shè)計應(yīng)與復(fù)審工作相結(jié)合，根據(jù)設(shè)計信息選取測試數(shù)據(jù)，將增大發(fā)現(xiàn)上述各類錯誤的可能性。在確定測試用例的同時，應(yīng)給出期望結(jié)果。該階段的交付文檔為更新的項目計劃書、更新的需求跟蹤矩陣、代碼、單元測試報告、意見反饋單和問題跟蹤單。所有代碼必須經(jīng)過工程委員會的評審，以確認(rèn)是否符合編程規(guī)范要求。

(7)系統(tǒng)集成和測試

軟件測試的目的是以較小的代價發(fā)現(xiàn)盡可能多的錯誤。要實現(xiàn)這個目標(biāo)的關(guān)鍵在于設(shè)計一套出色的測試用例（測試數(shù)據(jù)和預(yù)期的輸出結(jié)果組成了測試用例）。如何才能設(shè)計出一套出色的測試用例，關(guān)鍵在于理解測試方法。不同的測試方法有不同的測試用例設(shè)計方法。兩種常用的測試方法是白盒法和黑盒法。

一般測試分為：單元測試、集成測試和系統(tǒng)測試。單元測試階段通常是屬于開發(fā)項目組編碼調(diào)試的范疇。單元測試階段后要將系統(tǒng)集成成一個可運行版本。此后，就進(jìn)入系統(tǒng)集成和測試階段，系統(tǒng)測試應(yīng)該由若干個不同測試組成，目的是充分運行系統(tǒng)，驗證系統(tǒng)各部件是否都能政黨工作并完成所賦予的任務(wù)。該階段主要的交付文檔為集成測試報告和系統(tǒng)測試報告、問題跟蹤單和階段工作報告。在測試階段完成后，必須經(jīng)過內(nèi)部驗收的評審才可以提交進(jìn)入正式的驗收階段。

(8)驗收

在驗收階段，項目組主要是配合客戶進(jìn)行驗收。首先準(zhǔn)備好用戶手冊以及相關(guān)文檔，并提交系統(tǒng)驗收檢查單，協(xié)助客戶進(jìn)行驗收測試。本階段的交付文檔為驗收報告，客戶簽署的驗收報告也就是對本階段的評審。

(9)項目關(guān)閉

本開發(fā)過程最后強調(diào)的是項目關(guān)閉階段，這個階段是對項目開發(fā)的總結(jié)。針對CMM 中關(guān)鍵過程域的實施執(zhí)行情況，各個角色必須提交相應(yīng)的角色總結(jié)報告。在項目組長匯總后，總結(jié)項目開發(fā)中的不足和經(jīng)驗，提交過程改進(jìn)意見和CMM度量庫。這個過程有助于項目開發(fā)組織改進(jìn)自己的軟件開發(fā)過程。

4 總結(jié)

CMM 是國際公認(rèn)的 “ 事實 ” 標(biāo)準(zhǔn)，是中國軟件業(yè)走向國際市場的通行證。CMM的目的是幫助軟件企業(yè)對軟件工程過程進(jìn)行管理和改進(jìn),增強開發(fā)與改進(jìn)能力,從而能按時地、不超預(yù)算地開發(fā)出高質(zhì)量的軟件。因此在軟件的開發(fā)和測試的過程中，針對企業(yè)自身的特點，采用CMM軟件開發(fā)管理流程，能夠提高軟件開發(fā)的質(zhì)量和效率。

參考文獻(xiàn)：

[1]何新責(zé).軟件能力成熟度模型[M].北京:清華大學(xué)出版社,2000.

[2]劉莉,傅英亮,陶強.基于CMM的軟件開發(fā)和維護(hù)過程的研究[J].信息技術(shù)與信息化,2006,(05).

第6篇：測試項目總結(jié)范文

2009年2月25日至4月17日，禮平老師提出將學(xué)院大三的“軟件項目管理”和“軟件項目開發(fā)實踐”兩項課程相結(jié)合，讓學(xué)生完成一個網(wǎng)上書城系統(tǒng)。項目歷時52天，在兩位老師的悉心指導(dǎo)下，整個學(xué)院的同學(xué)組成20多個團(tuán)隊，開始了開發(fā)歷程，在這個過程中，著重培養(yǎng)了學(xué)生獲取知識、共享知識、應(yīng)用知識、總結(jié)知識和傳播知識的能力。

作為其中一個團(tuán)隊的小組長，我深為自己所在的團(tuán)隊“喜羊羊與灰太狼”感到自豪，它對于我以及我們組員的影響都是“前所未有”，并且是長遠(yuǎn)的。說其前所未有，緣于這次開發(fā)就如大學(xué)前幾年的一次總結(jié)，幫助我們匯總學(xué)習(xí)方法，融會貫通所學(xué)知識；說其影響深遠(yuǎn)，緣于其對我們后期課程乃至下一屆或下幾屆學(xué)弟學(xué)妹們的幫助。

“喜羊羊與灰太狼”是一個由5個女生、2個男生組成的團(tuán)隊。這是一個奇怪而又強大的組合，這7個人沒有任何相關(guān)領(lǐng)域的開發(fā)經(jīng)驗，沒有任何組隊共同開發(fā)的合作經(jīng)驗。在團(tuán)隊中，有的活潑可愛，有的深沉內(nèi)斂，有的認(rèn)真細(xì)致，有的想法獨特，當(dāng)組合在一起之后，我們有過爭執(zhí)，有過失望，但是最終我們卻提交了一份令人滿意的成果，包括7個完整版本的源代碼和32萬字的文檔，還有每一位成員在未來學(xué)習(xí)中取之不盡的開發(fā)經(jīng)驗。

2　實際開發(fā)結(jié)果

2.1　產(chǎn)品

產(chǎn)品功能如圖1所示。

2.2工作量

編碼工作完成情況：

?C#代碼：9712行：

?數(shù)據(jù)庫代碼：299行；

?CSS代碼： 633行；

?存儲過程：1711行。

預(yù)計的生產(chǎn)效率：70行／人／日

程序的平均生產(chǎn)效率為：12355／7／14=126行／人／日

實際效率大于預(yù)計效率原因：

(1)開發(fā)團(tuán)隊中有技術(shù)很好的成員，當(dāng)遇到問題后，可以通過請教相互溝通，能夠很快地解決問題，不落下進(jìn)度。

(2)開發(fā)人員自學(xué)能力好，通過第一、第二階段的開發(fā)，積累了一定的經(jīng)驗，在后期三四階段的開發(fā)中將效率提高。

(3)所有成員都十分努力，同時團(tuán)隊的管理機制很好，項目開發(fā)嚴(yán)格按照計劃進(jìn)行，按時完成任務(wù)甚至超前完成，工作效率很高。

2.3　對生產(chǎn)效率的評價

經(jīng)過統(tǒng)計，整個網(wǎng)站系統(tǒng)的代碼數(shù)量為：C#代碼9712行，數(shù)據(jù)庫代碼299行，CSS代碼633行，存儲過程1711行，此部分都是開發(fā)人員手動開發(fā)的代碼，總共為12355行。前期的開發(fā)時間為14天。那么程序的平均生產(chǎn)效率為12355／7／14=126行，人／日，這已經(jīng)大大超出我們所預(yù)計的生產(chǎn)效率70行／A／日。雖然量增多了，但是質(zhì)量依舊控制在計劃之內(nèi)。

經(jīng)過統(tǒng)計，所產(chǎn)生文檔字?jǐn)?shù)大約為：75870字。所統(tǒng)計的文檔包括需求、概要設(shè)計、詳細(xì)設(shè)計、數(shù)據(jù)庫設(shè)計、開發(fā)計劃、測試計劃等項目所需文檔。那么文件的平均生產(chǎn)效率為：75870／1000／7／7／=1.5千字?jǐn)?shù)／人／日，這明顯不足于我們所預(yù)期的2.5千字?jǐn)?shù)／人／日。這是因為我們還有其他很多文檔并沒有統(tǒng)計進(jìn)去，例如小組的溝通，小組每周的會議記錄，小組每周的總結(jié)，個人總結(jié)等。因此，如果包括所有的文檔，估計能有3千字?jǐn)?shù)／人／日左右。

因此我們的生產(chǎn)效率是能達(dá)到我們預(yù)期的要求的。

3　開發(fā)歷程

從以上的開發(fā)成果看，這已經(jīng)是一個完整的開發(fā)項目。這不同于課程的開發(fā)作業(yè)，也不同于科技創(chuàng)新項目，課程初期，禮平老師接受同學(xué)們的建議，結(jié)合同一學(xué)期著重技術(shù)講解“軟件開發(fā)實踐”課程，提出共同完成同一個項目的觀點，兩門課程從不同的角度，即技術(shù)講解和項目管理指導(dǎo)兩個方面指導(dǎo)項目開發(fā)。這樣大大減少了課程內(nèi)容的重復(fù)和沖突，集中了同學(xué)的時間和精力，讓我們更加具體細(xì)致地完成一個項目。

3.1　相關(guān)課程的結(jié)合，集中學(xué)生經(jīng)歷

隨著學(xué)校對于學(xué)生動手能力的要求提高，每一門專業(yè)課程基本都要求學(xué)生開發(fā)一個小型項目以增加對于專業(yè)知識的了解。然而過多的課程導(dǎo)致了較大的項目壓力，最后學(xué)院的同學(xué)們都不堪重負(fù)。實際上，學(xué)生一直在忙于完成各種不同的項目，并沒有達(dá)到實際的學(xué)習(xí)效果。

因此，當(dāng)我們對禮平老師的教育理念還沒有理解時，我們只是覺得能夠?qū)⒂嘘P(guān)的課程相結(jié)合，是多么令人開心的事情。

“軟件項目開發(fā)實踐”課程老師由淺入深地對我們所遇到的技術(shù)問題進(jìn)行指導(dǎo)：“軟件項目管理”課程隨著軟件生命周期的進(jìn)行講述不同階段應(yīng)該要采用的軟件工程項目管理方法。

然而，這不只是兩門課程的結(jié)合。在后期的軟件測試課程中，我們再次將自己完成的系統(tǒng)作為測試對象，對其中重要的功能點采用一套完整的測試方案，對其進(jìn)行測試評估。因為被測系統(tǒng)是由自己開發(fā)，在測試過程中，我們可以很順利地對缺陷進(jìn)行修復(fù)。

3.2　軟件產(chǎn)品的開發(fā)生命周期同課程的結(jié)合

以軟件開發(fā)周期作為課程的大環(huán)境，兩位老師由淺入深，從需求分析開始，到設(shè)計、實現(xiàn)、測試和維護(hù)，一步一步帶領(lǐng)我們進(jìn)行開發(fā)。

這像是對所有課程的總結(jié)，其中包括編程的基礎(chǔ)課程、Web開發(fā)的相關(guān)技術(shù)、軟件工程的相關(guān)課程、項目管理。在這樣一個短暫的不到兩個月的時間內(nèi)，我們實現(xiàn)了基礎(chǔ)課程中的理論知識，我們重現(xiàn)各類開發(fā)和設(shè)計模型。在需求分析中，我們采用“面向?qū)ο蟆闭n程中的需求分析方法，力求通過標(biāo)準(zhǔn)的需求建模方法，明確系統(tǒng)功能和性能要求：在設(shè)計和開發(fā)過程中，我們采用迭代的開發(fā)方法，運用所學(xué)的Web開發(fā)課程和C#編程的內(nèi)容；在測試階段，我們采用軟件測試課程中學(xué)到的測試策略，對每一個階段的測試，運用有關(guān)的測試工具開展測試過程。

現(xiàn)在課程結(jié)束已經(jīng)快一年了，但在后期的像“軟件開發(fā)實習(xí)”這樣的課程中，我們卻總是不自覺地會將這次開發(fā)的經(jīng)驗作為我們開發(fā)的依據(jù)。通過這樣一次完整的項目開發(fā)過程，我們了解了整個產(chǎn)品的開發(fā)周期，明確每個階段應(yīng)該完成的任務(wù)，熟悉各個階段所可能遇到的問題以及應(yīng)該采用的方法，甚至對于風(fēng)險的估計都更加準(zhǔn)確了。

3.3　老師的指導(dǎo)，我們前行的指明燈

摒棄了傳統(tǒng)的教授方式，在禮平老師的教育理念指導(dǎo)下，我們開始走上講臺講述自己所遇到的問題、采用的解決方法，老師讓我們開展討論，讓我們團(tuán)隊內(nèi)部或者不同團(tuán)隊之間共同交流來尋求解決方案。另一位“軟件工程實踐”課程教師，他采用問題驅(qū)動的教學(xué)方式，對我們不同開發(fā)階段遇到的技術(shù)問題進(jìn)行匯總統(tǒng)一，提供出可選的技術(shù)解決方案，不同的團(tuán)隊可以依據(jù)自己項目的特點采用合適的解決方案，并通過自學(xué)的方式了解該解決方案的技術(shù)細(xì)節(jié)，從而順利解決問題。同時我們也了解到了相關(guān)其他解決方案適用的情景，讓我們在今后的開發(fā)中“有法可依”。

在這場互動式的教學(xué)中，老師并沒有因為學(xué)生的主動而減輕了工作壓力，他們需要及時調(diào)整我們到合適的方向上，這得益于老師自身豐富的開發(fā)經(jīng)驗。禮平老師會在我們停滯不前的時候，建議我們應(yīng)該先完 成一個靜態(tài)Demo來幫助了解需求：在我們對項目計劃感覺茫然的時候，他會拿出自己多年的開發(fā)經(jīng)驗告訴我們，應(yīng)該如何在計劃和開發(fā)上平衡時間；當(dāng)我們對自身網(wǎng)站的特色定位不清楚的時候，他會讓我們注重細(xì)節(jié)的完善而不是新穎的功能，讓我們最終以一個穩(wěn)定而完整的系統(tǒng)獲勝。當(dāng)初的我們甚至以為一個項目開發(fā)就是一次集體編寫代碼，然而老師卻教會我們需要確定需求，將設(shè)計工作做得完整，實際的開發(fā)時間只需要兩個星期，事實確實是如此，在嚴(yán)格的項目進(jìn)度控制中，組員在兩周之內(nèi)竟然基本完成了系統(tǒng)功能。

就是這樣，起初懵懂的我們對“項目”的過程完全不知所措，而現(xiàn)在，任何項目到我們手中，無論其采用的技術(shù)如何，無論其要求時間是多久，我們總能得心應(yīng)手地為其制定開發(fā)計劃并開展工作來實現(xiàn)它。這些知識在別人看來就像是與生俱來的，然而只有我們知道，正是通過了這樣一次完整的開發(fā)過程，讓軟件工程領(lǐng)域的知識成為我們自己的“天賦”，隨手拿來，即人們常說的“經(jīng)驗”。

在這個成長的過程中，老師并沒有說，如果遇到了這樣的問題，有多少偉大的人發(fā)明了多少模型我們可以采用，這種模型的構(gòu)建過程是這樣，那種模型的適用情況又是如何。若老師僅是這樣用生硬的文字告訴我們，用我們做20年學(xué)生的經(jīng)驗來看，不出一個月這些知識就會模糊，不出半年這些知識又會變成新的知識。而在這一次的開發(fā)過程中，老師卻像路標(biāo)，告訴我們正確的方向，或者可能的路線，而其中探索的過程卻是由我們來實現(xiàn)，前進(jìn)的道路由我們自己來選擇。我們變得習(xí)慣于獨立思考，我們變得善于表達(dá)，我們開始熟悉這條成功之道。

3.4　綜合性學(xué)習(xí)經(jīng)驗，我們最終的目標(biāo)

獲取知識(自學(xué))、共享知識(團(tuán)隊工作)、應(yīng)用知識(解決問題)、總結(jié)知識(創(chuàng)新)和傳播知識(溝通)的能力，這是CDIO要求學(xué)生在基于項目的學(xué)習(xí)過程中需要得到的綜合能力。

我們從不糾結(jié)于某一個技術(shù)問題，從不局限使用某一種開發(fā)模型，項目的內(nèi)容也不限定，通過一次完整的項目開發(fā)過程，著眼于學(xué)生綜合能力的提高，培養(yǎng)學(xué)生成為能夠與國際接軌的高等工程師。

禮平老師強調(diào)我們要不斷總結(jié)，并把這個過程運用到其他地方，不僅是軟件產(chǎn)品的開發(fā)，從確定需求、制定計劃、設(shè)計和實現(xiàn)的過程來看，我們可以將各種模型甚至運用到制定個人規(guī)劃，還有那些需要考研的同學(xué)的考研計劃中。在項目完成后，老師欣喜地翻閱每一位同學(xué)的心得體會。作為小組長我也看過組內(nèi)每一位成員的總結(jié)，每個人的教訓(xùn)和經(jīng)驗都不盡相同，也許這就是我們學(xué)習(xí)的目的，每個人都能有所收獲，從不同的角度，不同的領(lǐng)域培養(yǎng)不同的能力，收獲不同的知識。

3.5課程考核，不僅僅是分?jǐn)?shù)

與往常的課程考試不同，我們采用的考核方式是多樣的，包括平時的討論、組內(nèi)的互評，答辯的結(jié)果和最終的產(chǎn)品質(zhì)量。

平時討論作為考核的內(nèi)容之一，增加了平時課堂討論的參與度，使得同學(xué)們更加積極地投入到課堂交流，為每一次的成果匯報作好充分的準(zhǔn)備，積極主動地思考解決方案。

組內(nèi)互評是我們的一大特色，我們采用禮平老師號稱的“雷達(dá)圖”來評定每一位成員在開發(fā)過程中的表現(xiàn)。這種評定方法通過不同方面評定每個人的能力，讓每位成員能夠更加清楚地認(rèn)識自己，并依據(jù)其在組內(nèi)的貢獻(xiàn)作為評分依據(jù)，計算出組內(nèi)互評的最終得分，“雷達(dá)圖”示意圖如圖2所示。

答辯是最后的考驗，我們?yōu)榇俗鲎懔藴?zhǔn)備，甚至排練了多次。經(jīng)過之前多次的中期檢查，我們慢慢學(xué)著如何更好地展示和表達(dá)我們的成就，讓老師和其他項目組在答辯的短暫十分鐘之內(nèi)看到我們的努力和優(yōu)秀的產(chǎn)品。終期答辯推動著我們不斷完善系統(tǒng)，因為考慮到老師要進(jìn)行任何操作，提出各種疑問，所以我們從用戶的角度考慮一切有可能出現(xiàn)的操作，盡可能地保證系統(tǒng)的實用性、便捷性和穩(wěn)定性，這樣大大提高了產(chǎn)品的質(zhì)量。在后期的總結(jié)中，我們發(fā)現(xiàn)這樣的方式運用到實際的產(chǎn)品開發(fā)中也是如此的有效，因為時刻從客戶的角度考慮，是保證產(chǎn)品質(zhì)量的重要因素。

正是這樣的考核方式，不僅讓我們學(xué)會如何有效表達(dá)、了解自己，更在一定程度上學(xué)會考慮如何成就一個成功的項目。

3.6　團(tuán)隊合作，我們最寶貴的經(jīng)驗

人際交往技能即團(tuán)隊協(xié)作和交流，是CDIO工程教育模式所提倡的應(yīng)該培養(yǎng)學(xué)生的技能。對我們來說，團(tuán)隊培養(yǎng)的協(xié)作關(guān)系是我們寶貴的財富，團(tuán)隊合作也成為我們最寶貴的經(jīng)驗。

為了能夠順利完成每個階段的計劃，我們的小組成員常在一起整合到凌晨，為問題開會討論好幾個小時，我們會將設(shè)計制定的細(xì)致再細(xì)致，只為其他隊員能夠減少理解時間。當(dāng)然，因為我們性格各異，所以也會對他人的行事風(fēng)格不理解，也會出現(xiàn)推脫責(zé)任的時候，也有不能達(dá)成一致意見而發(fā)生爭執(zhí)的時候?？墒且驗榇蠹矣泄餐哪繕?biāo)，抱著對項目負(fù)責(zé)的態(tài)度，我們逐漸建立起默契，漸漸開始為對方考慮。每個小組成員都很細(xì)致地對待自己負(fù)責(zé)開發(fā)的模塊，盡量減少出現(xiàn)缺陷，避免其他功能的開發(fā)遭到停滯或者增加整合人員的工作量。

很多人都知道，團(tuán)隊合作會保證項目的順利進(jìn)行，減少項目風(fēng)險，構(gòu)建一種良好的團(tuán)隊氛圍，而對于我們來說，團(tuán)隊合作更讓我們關(guān)注自己的工作，在很大程度上保證了產(chǎn)品開發(fā)的質(zhì)量。通過團(tuán)隊開發(fā)的方式，讓我們在開發(fā)過程發(fā)現(xiàn)協(xié)作的意義，更讓我們收獲了友誼。

4　CDIO之我見

禮平老師的課堂帶給我們收獲和成果，作為軟件學(xué)院的學(xué)生，作為CDIO工程教育理念的受益者，我們有自己的理解和感受。

在有限的大學(xué)4年教育中，我們希望自己能夠承受一定的壓力并收獲有用的知識，能讓我們在未來的職業(yè)領(lǐng)域有所發(fā)展。同時我們了解，作為工科學(xué)生，工程實踐經(jīng)驗尤為重要，而從小學(xué)到中學(xué)，理論為主的教學(xué)模式讓我們深感自己經(jīng)驗不足，動手能力不強，對于實際的公司項目更是束手無策。成為社會肯定的具有良好綜合素質(zhì)的畢業(yè)生，這是我們對自身的要求，也是我們對于學(xué)校教育的期望。

第7篇：測試項目總結(jié)范文

1軟件測試過程中的質(zhì)量管理

軟件測試貫穿于軟件開發(fā)流程的各個角落，能夠讓工作人員及時在軟件工程階段中發(fā)現(xiàn)漏洞所在，確保最終交付的產(chǎn)品無論是功能還是性能，都能得到客戶對品質(zhì)的需求，軟件測試需要在軟件開發(fā)各個階段進(jìn)行，工作人員在進(jìn)行軟件測試的時候需要作出相應(yīng)的軟件測試文檔。軟件測試中質(zhì)量管理尤為重要，產(chǎn)品需要滿足驗收交付要求，需要根據(jù)軟件開發(fā)實際情況，從不同的角度進(jìn)行度量，軟件測試最主要的問題是軟件質(zhì)量問題，在保證質(zhì)量的基礎(chǔ)上從不同角度度量產(chǎn)品最終質(zhì)量。有的人在軟件測試時可以意識到重要性，但是卻沒有辦法清晰地找到提升質(zhì)量的有效方式，隨著軟件測試研究的深入，人們開始建立起軟件質(zhì)量度量模型。通過對模型的分析，得知軟件質(zhì)量從以下幾方面衡量：（1）開發(fā)出來的軟件是否符合用戶的需求，軟件整體結(jié)構(gòu)是否良好，軟件是否容易讀取，修改是否容易；（2）軟件系統(tǒng)有沒有友好用戶界面，用戶在使用該軟件的時候是否方便，需不需要進(jìn)行其他操作；（3）軟件生存周期內(nèi)各個階段文檔是否齊全，存儲是否得當(dāng)，所有文檔是否被規(guī)范配置管理，工作人員進(jìn)行軟件測試需要根據(jù)客戶需求，以此作為參考，從對方的角度去看待產(chǎn)品，想象客戶會如何使用產(chǎn)品，使用的時候可能會遇到什么問題。軟件測試質(zhì)量管理方面還需要進(jìn)行軟件質(zhì)量保證，分階段的對開發(fā)的軟件進(jìn)行科學(xué)評審，根據(jù)評審結(jié)果制定相應(yīng)計劃，將軟件分成幾個階段，根據(jù)不同階段呈現(xiàn)出來的特點制定評審要求。隨后，工作人員在審查軟件開發(fā)過程時，需要為每一個過程制定規(guī)范，不管是文檔還是編程都要達(dá)到相應(yīng)的規(guī)范需求，要求軟件測試人員做好質(zhì)量評估報告，內(nèi)容豐富詳細(xì)，評估軟件測試的整個過程，對存在不足的地方提出有效改進(jìn)建議。某測試工作人員在進(jìn)行軟件測試的時候，為了確保質(zhì)量管理工作到位，特別完成了軟件測試環(huán)境的科學(xué)搭建，由于不同的軟件對測試環(huán)境有著不同角度的需求，如C/S及B/S架構(gòu)相關(guān)的軟件產(chǎn)品，測試人員會有不同操作系統(tǒng)，如Windows系列、Unix、Iinux甚至蘋果OS等，這些測試環(huán)境都是必須的。對于一些嵌入式軟件，如手機軟件，如果測試人員想測試一下有關(guān)功能模塊的耗電情況，手機待機時間等，可能需要搭建相應(yīng)的電流測試環(huán)境。

2軟件測試過程中的風(fēng)險應(yīng)對分析

2.1風(fēng)險識別與風(fēng)險量化

對軟件進(jìn)行項目風(fēng)險管理，可以在最短時間內(nèi)得到項目目標(biāo)，項目風(fēng)險管理以潛在風(fēng)險最小化作為目標(biāo)，軟件測試項目風(fēng)險管理中包含軟件風(fēng)險識別、軟件風(fēng)險量化、軟件風(fēng)險應(yīng)對計劃制定以及軟件風(fēng)險控制。其中，軟件風(fēng)險識別需要工作人員在軟件測試項目風(fēng)險管理開始之前進(jìn)行，并在整個項目執(zhí)行中不斷完成，軟件風(fēng)險識別在項目整個生命周期以內(nèi)屬于連續(xù)過程。軟件風(fēng)險識別包含了風(fēng)險來源確定、風(fēng)險產(chǎn)生條件辨別，測試人員要詳細(xì)表述風(fēng)險特征，確定這些風(fēng)險是否會影響到軟件測試項目的正常運行，對于軟件測試項目風(fēng)險管理來說，風(fēng)險識別不是一次就能完成的，而是應(yīng)該在項目的全過程進(jìn)行。

2.2風(fēng)險應(yīng)對計劃與風(fēng)險監(jiān)控

針對風(fēng)險量化結(jié)果，為了降低軟件測試項目的負(fù)面效應(yīng)，測試人員會制定相應(yīng)的解決措施和技術(shù)手段，做好風(fēng)險管理計劃，完成風(fēng)險認(rèn)知，為風(fēng)險監(jiān)控提供技術(shù)基礎(chǔ)。人們可以使用多種方式作為風(fēng)險控制方法，利用核對表對項目進(jìn)行定期評估與凈值分析，風(fēng)險監(jiān)控的輸出包含對風(fēng)險的錯誤糾正和軟件測試項目管理計劃更新，軟件測試項目中發(fā)現(xiàn)風(fēng)險以后對其加以分析，確定相對重要性與影響程度，為來自內(nèi)部與外部的風(fēng)險提供標(biāo)識，對每一種風(fēng)險進(jìn)行科學(xué)評估，計算出風(fēng)險發(fā)生的可能性與最終結(jié)果，對風(fēng)險進(jìn)行分類，為風(fēng)險處理提供可操作信息。在經(jīng)典風(fēng)險管理過程中，主要會使用到Boehm、CRM、Leavitt、Boehm等多種模型，使用這種方式很有可能造成人員不足或者成本不夠的問題，測試人員在開始進(jìn)行軟件項目開發(fā)的時候就要對潛在風(fēng)險進(jìn)行總結(jié)，將所有的風(fēng)險形成表格形式，并在軟件測試項目生命周期內(nèi)進(jìn)行會議討論，更新表格。應(yīng)當(dāng)對可能出現(xiàn)的惡劣后果因素進(jìn)行準(zhǔn)確評估，對于當(dāng)前最緊急的風(fēng)險進(jìn)行決定和處理，制定控制風(fēng)險的基本應(yīng)對措施，評測和保證風(fēng)險策略開展的有效性。

3總結(jié)

總而言之，人們從第三方軟件測試角度進(jìn)行軟件測試時，不僅要進(jìn)行完善的質(zhì)量管理，還會進(jìn)行項目風(fēng)險管理，對風(fēng)險進(jìn)行評估與排序，確定不同風(fēng)險給軟件帶來的影響，探究風(fēng)險發(fā)生概率，進(jìn)一步保證軟件的質(zhì)量，降低產(chǎn)品維護(hù)費用，提高用戶滿意程度，降低軟件責(zé)任風(fēng)險，提高經(jīng)濟(jì)效益。

參考文獻(xiàn)

[1]徐莉.基于項目管理角度的軟件測試流程及管理[J].網(wǎng)絡(luò)安全技術(shù)與應(yīng)用,2018(03):38-39.

第8篇：測試項目總結(jié)范文

關(guān)鍵字：軟件；測試過程；管理

軟件開發(fā)過程的質(zhì)量決定軟件的質(zhì)量，軟件測試過程的質(zhì)量直接影響測試結(jié)果的準(zhǔn)確性和有效性。

1 軟件測試過程常用的模型

1、V模型

V模型反映出測試活動與分析設(shè)計活動的關(guān)系，指出單元測試和集成測試應(yīng)檢測程序的執(zhí)行是否滿足軟件設(shè)計的要求。系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo)。驗收測試確定軟件的實現(xiàn)是否滿足用戶需求或合同的要求。

2、W模型

W模型指出軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗證和確認(rèn)活動，即測試與開發(fā)也應(yīng)是同步進(jìn)行的。W模型有利于盡早和全面的發(fā)現(xiàn)問題。

3、H模型

V模型與W模型有不妥，即它們都把軟件的開發(fā)視為需求、設(shè)計和編碼等一系列串行的活動，而事實上，這些活動可以交叉進(jìn)行的。H模型揭示這一點：軟件測試是一個獨立的流程，貫穿于產(chǎn)品的整個生命周期中，與其他流程并發(fā)進(jìn)行。

除了上面的幾種常見模型外，還有X模型、前置測試模型等。在實踐中，建議以W模型作為框架，及早全面地開展測試，同時靈活運用H模型獨立測試的思想，在達(dá)到恰當(dāng)?shù)木途w點時就應(yīng)該開展獨立的測試工作，同時將測試工作進(jìn)行迭代，最終保證完成測試目標(biāo)。

2 測試階段中的測試活動

軟件測試過程主要包括以下四項基本活動：

1、測試策劃

在測試策劃中的活動有：制定測試計劃，以確定測試范圍、測試策略和測試方法，規(guī)劃測試任務(wù)日程表，對測試資源進(jìn)行安排，并提前評估測試風(fēng)險，制定風(fēng)險控制策略。

2、測試設(shè)計與實現(xiàn)

在測試設(shè)計與實現(xiàn)中的活動有：制定測試的技術(shù)方案，選擇測試工具，并根據(jù)測試技術(shù)方案設(shè)計測試用例。

3、測試執(zhí)行

在測試執(zhí)行中的活動有：建立相關(guān)測試環(huán)境、配置測試數(shù)據(jù)、按日程安排執(zhí)行測試用例并記錄測試執(zhí)行結(jié)果，對發(fā)現(xiàn)的軟件缺陷進(jìn)行報告，并配合開發(fā)人員進(jìn)行軟件缺陷的分析、處理和追蹤。

4、測試總結(jié)

在測試總結(jié)中的活動有：對測試結(jié)果進(jìn)行綜合分析，以確定軟件產(chǎn)品質(zhì)量的當(dāng)前狀態(tài)，為產(chǎn)品的改進(jìn)和提供數(shù)據(jù)和依據(jù)，同時編制測試報告，提交相關(guān)的測試文檔。

3 軟件測試過程管理的特點

軟件測試過程管理的基本內(nèi)容包括計劃、組織和監(jiān)控；測試過程中存在的問題有：

1.軟件質(zhì)量標(biāo)準(zhǔn)定義不準(zhǔn)確、任務(wù)邊界模糊。

2.軟件測試項目的變化控制和預(yù)警分析要求高。

3.軟件測試項目具有智力密集，勞動密集的特點，受人力資源的影響最大。

4.測試任務(wù)的分配比較困難。

5.測試要求的人力資源十分穩(wěn)定。

6.軟件測試人員在待遇、地位上可能會受到一些不公平的待遇。

軟件測試項目的過程管理能否成功，通常受到三方面的影響：項目組內(nèi)的環(huán)境，項目所處的組織環(huán)境，整個開發(fā)流程所控制的全局環(huán)境。

4 軟件測試過程管理的原則

1、有關(guān)測試需求，應(yīng)當(dāng)有一個經(jīng)各方同意的、完整的、清楚的、詳細(xì)的、整體的、可實現(xiàn)的和可測試性的需求并文檔化，盡可能堅持最初的需求。

2、測試計劃先行。軟件項目管理過程從項目的計劃活動開始，軟件測試項目也不例外，也是從測試計劃開始。

3、建立任務(wù)優(yōu)先級。在測試任務(wù)較多的情況下，應(yīng)該為各項任務(wù)建立測試優(yōu)先級，這樣也可以根據(jù)優(yōu)先級來先后處理各項任務(wù)。

4、建立客觀的評估標(biāo)準(zhǔn)。這樣使得整個項目過程具有良好的可測性和可跟蹤性，強調(diào)以數(shù)據(jù)說話。

5、盡早測試。這是從W模型中抽象出來的理念。一方面指測試人員盡早參與測試項目，另一方面指盡早開展測試執(zhí)行任務(wù)。

6、全面測試。這也是W模型的重要思想，其含義一方面只要對軟件所有產(chǎn)品進(jìn)行全面的測試；另一方面指軟件開發(fā)人員與測試人員全面參與到測試工作中。

7、全過程測試。這是從W模型中抽象出來的另一理念。其含義一方面指測試人員要充分關(guān)注開發(fā)過程；另一方面指測試人員要對測試的全過程進(jìn)行全程的跟蹤。

8、獨立的、迭代的測試。這是H模型的重要思想，強調(diào)只要達(dá)到測試就緒點，即測試條件成熟，測試準(zhǔn)備活動完成，測試執(zhí)行活動就可以開展。

5 軟件測試過程的人員組織

測試團(tuán)隊的組織直接關(guān)系到測試團(tuán)隊的工作效率和生產(chǎn)力，其組織方式由測試團(tuán)隊的規(guī)模、具體任務(wù)和技術(shù)來決定。

一個測試團(tuán)隊的基本角色有：測試經(jīng)理、實驗室管理人員、內(nèi)審員、測試組長、測試設(shè)計人員、資深測試工程師、一般測試工程師。

若測試團(tuán)隊規(guī)模較大，則測試工程師分為三個層次：初級測試工程師、測試工程師和資深測試工程師，同時設(shè)置自動化測試工程師、系統(tǒng)測試工程師和架構(gòu)工程師。

測試過程人員組織的一個方面是考慮測試團(tuán)隊的規(guī)模，測試團(tuán)隊的規(guī)?？梢钥紤]在整個開發(fā)部門所占的比重，或相對開發(fā)人員所占的比例。從經(jīng)驗看，不同的應(yīng)用，軟件測試和軟件開發(fā)人員的比例也是不同的，大致可分為三類。

1、操作系統(tǒng)類型的產(chǎn)品，對測試要求最高，測試人員和開發(fā)人員的比例為2：1。

2、應(yīng)用平臺、支持系統(tǒng)類型的產(chǎn)品，對測試要求比較高，通常測試人員和開發(fā)人員的比例為1：1。

3、對于特定應(yīng)用系統(tǒng)一類產(chǎn)品，由于以后對象清楚、范圍小，甚至可對應(yīng)用平臺或應(yīng)用環(huán)境加以限制，所以測試人員可以再減少，但測試人員和開發(fā)人員的比例至少保證在1：2的水平以上。

6 結(jié)束語

相比之下，目前中國軟件企業(yè)在軟件測試方面與國際水準(zhǔn)仍存在較大差距。首先，在認(rèn)識上重開發(fā)、輕測試，沒有認(rèn)識到軟件項目的如期完成不僅取決于開發(fā)人員，更取決于測試人員；其次，在管理上隨意、簡單，沒有建立有效、規(guī)范的軟件測試管理體系；另外，缺少自動化工具的支持，大多數(shù)企業(yè)在軟件測試時并沒有采用軟件測試管理系統(tǒng)。所以對國內(nèi)軟件企業(yè)來說，不僅要提高對軟件測試過程管理的認(rèn)識，同時要建立起完善的軟件測試過程管理體系，確保軟件測試管理在軟件質(zhì)量保證中發(fā)揮應(yīng)有的關(guān)鍵作用。

參考文獻(xiàn)

[1]朱少民. 軟件測試方法和技術(shù) [M].北京：清華大學(xué)出版社， 2005年

[2]鄭文強，馬均長. 軟件測試管理[M].北京：電子工業(yè)出版社， 2010年

[3]布萊克（美）.軟件測試過車管理[M].北京：機械工業(yè)出版社，2003年

第9篇：測試項目總結(jié)范文

 

 

0引言

 

如今，軟件產(chǎn)品被廣泛應(yīng)用于各個領(lǐng)域，如航空、機械、電子產(chǎn)品等，軟件產(chǎn)品質(zhì)量成為軟件開發(fā)中重點關(guān)注的方向。在一些對于安全性要求較高的領(lǐng)域，對軟件產(chǎn)品的質(zhì)量要求更高。例如，在2011年溫州發(fā)生的7.23動車追尾事故，導(dǎo)致212人傷亡;1996年阿里亞娜5型火箭發(fā)射39秒后爆炸，直接經(jīng)濟(jì)損失3.7億美元;2002年首都機場電腦系統(tǒng)出現(xiàn)故障，導(dǎo)致6000多人滯留機場等。軟件中存在的缺陷是造成這些嚴(yán)重后果的根源。因此，軟件測試的重要性不言而喻。

 

傳統(tǒng)的軟件開發(fā)流程越來越無法滿足當(dāng)下軟件需求的頻繁變動，如傳統(tǒng)的瀑布模型，測試人員在一定的控制點之前不能測試，所以在此之前無法找到缺陷。等到所有開發(fā)完成，即過了該控制點后再進(jìn)行測試，缺陷數(shù)量會急劇增加，同時任何缺陷的修復(fù)都需要對一連串代碼進(jìn)行變動，修復(fù)時間難以確定，軟件遲遲不能，損失將難以估量。

 

敏捷軟件開發(fā)是基于一種更接近人類活動現(xiàn)實情況的方法論，采用以人為本、迭代、增量的開發(fā)過程，逐步滿足軟件不斷變更的需求[1]。敏捷主要提倡個人為團(tuán)隊所作的貢獻(xiàn)，注重各個職位的權(quán)利下發(fā)，發(fā)揮個人的主觀能動性，保證隨時都有可供交付的軟件產(chǎn)品。敏捷開發(fā)更容易在項目早期控制缺陷數(shù)目。軟件測試是保證軟件質(zhì)量與可靠性的重要手段，敏捷開發(fā)能充分發(fā)揮軟件測試的重要作用。

 

1敏捷開發(fā)思想

 

敏捷開發(fā)是以用戶的需求進(jìn)化為核心，采用逐步迭代、循序漸進(jìn)的方式進(jìn)行軟件開發(fā)。在敏捷開發(fā)模式中，軟件項目在開發(fā)前，先將整體項目切分成多個子項目，迭代過程中根據(jù)需要可以對子項目進(jìn)行拆分或同時進(jìn)行多個子項目，每一個子項目都要經(jīng)過測試，保證項目能運行成功。換言之，就是把一個大的軟件項目分成許多小項目，每個項目獨立完成，但相互之間又有聯(lián)系，在該過程中軟件始終處于可用狀態(tài)。

 

敏捷開發(fā)本身更多的是一種概念，它是一種循序漸進(jìn)的迭代開發(fā)方式，強調(diào)團(tuán)隊成員間的溝通。2001年，敏捷開發(fā)創(chuàng)始人了敏捷宣言：個體和交互勝過流程和工具，可用的軟件勝過完備的文檔，客戶協(xié)作勝過合同談判，響應(yīng)變化勝過遵循計劃[2]。也即，雖然后半部分的條目也具有價值，但是更看重前半部分的條目。他們希望這將成為成功的軟件開發(fā)的基礎(chǔ)。敏捷開發(fā)的方法很多，主要包括快速應(yīng)用開發(fā)(RAD)[3]、極限編程(XP)[4]、動態(tài)系統(tǒng)開發(fā)方法(DSDM)[5]與Scrum[6]。本文構(gòu)建的測試模型借鑒敏捷開發(fā)過程中的迭代思想，以漸進(jìn)的方式完成測試工作，不僅可使測試工作具有更好的靈活性，同時也能更好地適用于現(xiàn)有的敏捷開發(fā)過程。

 

軟件是一種非常特殊的產(chǎn)品，開發(fā)出的軟件通常會存在一些缺陷，而有些缺陷會造成非常嚴(yán)重的損失。軟件測試則成為保障軟件質(zhì)量的一種重要手段[7]。根據(jù)不同標(biāo)準(zhǔn)有多種測試方式，如集成測試、單元測試、系統(tǒng)測試、驗收測試和回歸測試。傳統(tǒng)的V測試模型和W測試模型成為指導(dǎo)人們進(jìn)行測試的方法，而不同于這兩種測試模型的H模型，則強調(diào)測試的獨立性。另外目前很多開發(fā)團(tuán)隊已經(jīng)開始使用敏捷開發(fā)方式，敏捷開發(fā)方式非常注重客戶的交互以及團(tuán)隊中的溝通，同時開發(fā)過程中會有許多迭代過程。本文提出的測試模型借鑒敏捷開發(fā)中的迭代思想，測試流程是一個漸進(jìn)的過程。然而，即使有成功的敏捷開發(fā)方法，開發(fā)人員和測試人員依然要尋求最適合的敏捷方法，并將相關(guān)技術(shù)融入到自己的敏捷方法中。

 

2敏捷開發(fā)中的軟件測試

 

2.1敏捷測試

 

敏捷測試沒有已經(jīng)確定的唯一定義，原有的測試定義“通過在規(guī)定條件下對程序進(jìn)行操作，發(fā)現(xiàn)錯誤，衡量軟件質(zhì)量”仍然適用，核心思想可以理解為“遵循敏捷開發(fā)的宣言，接納敏捷核心價值觀，基于敏捷開發(fā)的軟件測試”。敏捷開發(fā)宣言中提到敏捷開發(fā)的4個核心價值觀：簡明(Simplicity)、溝通(Communication)、反饋(Feedback)、勇氣/決斷(Courage)。符合敏捷核心價值觀的測試實踐活動都可以稱為敏捷測試，敏捷不僅是一種過程，更多的是一種理念[8]。

 

2.2敏捷測試方法

 

圖1為敏捷開發(fā)測試流程，此流程是一個結(jié)合了Scrum和XP方法，并加上一些基于計劃性流程原則后的產(chǎn)物。虛線箭頭兩端是開發(fā)過程中與軟件測試相關(guān)的部分，敏捷開發(fā)的測試人員全程參與完整的迭代開發(fā)。

 

(1)需求分析：測試工程師可以根據(jù)測試經(jīng)驗以及需求的測試難度對需求列表提出問題或意見，以期團(tuán)隊能共同提供建議或方案，在之后的實際測試過程中有助于提高測試效率。

 

(2)迭代計劃：包括對需求的詳細(xì)分析以及任務(wù)表等，軟件工程師和測試工程師對需求進(jìn)行討論。

 

(3)迭代啟動會議：項目經(jīng)理、產(chǎn)品經(jīng)理、軟件工程師、測試工程師對此代計劃進(jìn)行討論、完善。

 

(4)測試計劃：測試工程師根據(jù)需求以及測試經(jīng)驗完成詳細(xì)的測試計劃書，團(tuán)隊對測試計劃進(jìn)行研討并確認(rèn)驗收測試。

 

(5)測試驅(qū)動開發(fā)：測試工程師相當(dāng)于軟件的第一批用戶，測試過程中要重視反饋，這也是敏捷開發(fā)的原則之一。

 

(6)驗收測試：測試工程師對此次迭代的所有功能進(jìn)行演示，測試產(chǎn)品功能是否合格。如果產(chǎn)品合格，則此次驗收通過，可以進(jìn)入下一環(huán);如果產(chǎn)品不合格，則此次驗收失敗，重新返回開發(fā)階段，找出失敗的原因及bug并解決，并確認(rèn)下一次驗收測試。

 

(7)提交與驗證：由測試工程師為產(chǎn)品負(fù)責(zé)人與參與項目的人進(jìn)行演示，包括此次迭代的主要功能、產(chǎn)生的未解決bug，然后由產(chǎn)品負(fù)責(zé)人核準(zhǔn)迭代成功。

 

(8)迭代后的研討：對此次迭代過程中產(chǎn)生的問題進(jìn)行討論，對于亮點可以進(jìn)行表揚，錯誤要分析原因。

 

從流程圖和測試人員參與項目的簡單描述中，可以總結(jié)出敏捷測試的方法主要有兩種：與傳統(tǒng)軟件測試相似的測試和測試驅(qū)動開發(fā)(TDD，Test-DrivenDevelopment)。

 

圖2展示的是測試驅(qū)動開發(fā)流程，開發(fā)人員在編寫產(chǎn)品代碼之前，要先編寫單元測試代碼，在進(jìn)行單元測試后才能進(jìn)行產(chǎn)品代碼的編寫，以保證產(chǎn)品代碼能完全符合要求。產(chǎn)品代碼編寫完成后進(jìn)行單元測試和集成測試，測試代碼和產(chǎn)品代碼都要進(jìn)行代碼審查，保證代碼的簡潔、統(tǒng)一，方便以后維護(hù)。在敏捷測試中，測試驅(qū)動開發(fā)的重要目的不僅僅是測試軟件，同時在開發(fā)過程中幫助客戶和程序員確定需求。測試驅(qū)動開發(fā)應(yīng)該運用于每一個迭代中，逐步開發(fā)完成所有軟件功能。

 

傳統(tǒng)軟件測試的種類非常多，在敏捷測試中應(yīng)當(dāng)根據(jù)當(dāng)前迭代的需求進(jìn)行測試[9]。某車削軟件有這樣一個需求，能支持直徑40mm的刀具路徑生成。該需求一定配備了相應(yīng)的刀具路徑生成方法，然后只需確定刀路生成中的一些參數(shù)，然后設(shè)計數(shù)量足夠的不同表面形態(tài)的圓面即可。由于TestPart數(shù)量過多，可能會用到自動化測試，也有可能會用到一些特殊的TestPart，如圓面面型變化大，甚至不是圓面等。迭代最后一定有整體的性能測試，在整個項目進(jìn)行過程中，傳統(tǒng)的軟件測試方法同樣適用于敏捷開發(fā)。

 

2.3敏捷測試特點

 

在瀑布開發(fā)模式中，要求流程規(guī)范、文檔齊全，測試進(jìn)行時再根據(jù)軟件需求總結(jié)、測試所有功能點，直到軟件中沒有明顯bug。在傳統(tǒng)的軟件測試開始時，軟件的缺陷會達(dá)到頂點，同時如果有需求變化，則需要重新編寫文檔，可能必須將之前的工作推翻重來，費時費力。而在敏捷測試中，一切都發(fā)生了改變。

 

敏捷開發(fā)模式中測試不是一個單獨階段，它和編碼一樣是軟件開發(fā)的重要組成部分。敏捷開發(fā)使用一個“完整團(tuán)隊”的方法來保證軟件產(chǎn)品質(zhì)量。敏捷團(tuán)隊中的測試人員從客戶需求中提煉要求，然后與開發(fā)團(tuán)隊合作，把這些要求變成可執(zhí)行的規(guī)范，用于指導(dǎo)代碼編寫。隨著測試和編碼的逐漸進(jìn)行與交互，將建立一些產(chǎn)品特性，直到提供足夠的產(chǎn)品價值。

 

敏捷測試包括以下幾個主要特點：①周期性的迭代開發(fā)方式。不同于傳統(tǒng)測試的一次性集成或功能測試，敏捷測試在迭代進(jìn)行過程中要通過及時響應(yīng)客戶反饋來修正軟件測試策略，以此修正軟件的質(zhì)量指標(biāo);②每日立會，密切溝通。傳統(tǒng)測試提供了大量文檔描述產(chǎn)品需求，并通過文檔進(jìn)行測試。敏捷測試則需要團(tuán)隊每天進(jìn)行交流，測試人員與客戶持續(xù)溝通，以保證產(chǎn)品質(zhì)量符合客戶預(yù)期，并與開發(fā)人員溝通來確定需求認(rèn)識的統(tǒng)一;③測試方法多樣，貫穿整個項目開發(fā)過程。敏捷測試包括測試人員對軟件的自動化測試、集成測試、功能測試等，還包括開發(fā)人員對代碼的單元測試、代碼評審等工作，從最底層和基礎(chǔ)的測試來保證軟件整體質(zhì)量;④確?？蛻粜枨髨A滿實現(xiàn)?？蛻粜枨笫敲艚蓍_發(fā)中最核心的內(nèi)容，敏捷測試同樣需圍繞客戶需求實現(xiàn)。

 

2.4敏捷測試優(yōu)勢

 

目前大多數(shù)軟件項目的共同特點是用戶需求變化快、風(fēng)險高，同時還能快速搶占市場，這剛好是敏捷開發(fā)能夠解決的。

 

(1)良好的持續(xù)溝通可減少缺陷產(chǎn)生，降低風(fēng)險。在敏捷開發(fā)模式下，測試人員的溝通尤為重要。一個迭代從開始到結(jié)束，測試人員都需要參與。迭代開始時，所有人都要對該階段軟件的成型有統(tǒng)一認(rèn)識，滿足用戶需求的同時還要符合一次迭代的時間要求;迭代進(jìn)行中，測試對開發(fā)人員的反饋非常重要，軟件開發(fā)初期，測試工具十分缺乏，對測試工作的進(jìn)行造成很大阻礙，這時需要和開發(fā)人員持續(xù)溝通，必要時可共同開發(fā)一些輔助測試工具，在此期間要把握好迭代進(jìn)行的時間;迭代后期，也可以作為bug反饋期，測試人員不但要站在用戶角度考慮需求，同時能和開發(fā)人員站在技術(shù)角度討論問題，達(dá)到溝通的目的。

 

(2)合理的測試用例。敏捷最直接的特點就是快速，如果涉及的用例粒度太細(xì)，很難開展敏捷測試。一個合理的測試用例不僅能包含所有可能產(chǎn)生缺陷的地方，同時還能快速地響應(yīng)需求變化。

 

(3)更多人參與測試。敏捷測試中的測試人員不再是一個獨立的測試個體，研發(fā)人員、產(chǎn)品負(fù)責(zé)人、用戶都可以參與測試。研發(fā)人員的測試可以減少編程中的bug，產(chǎn)品負(fù)責(zé)人的測試可以更好、更全面地把握產(chǎn)品現(xiàn)狀，用戶的測試則可以提供來自真正用戶的反饋，以更好地促進(jìn)軟件開發(fā)。

 

3敏捷開發(fā)中的軟件測試實例

 

本章結(jié)合一個具體的軟件項目，詳細(xì)介紹項目中的敏捷測試。

 

3.1項目介紹

 

針對3軸超精密加工車床，提供針對光學(xué)自由曲面進(jìn)行加工的刀路軌跡計算的CAM(ComputerAidedManufacturing，計算機輔助制造)軟件。該軟件的目標(biāo)是比UGNX中的相同功能有更快的計算速度和更高的精度。

 

3.2需求分析和項目規(guī)劃階段

 

項目經(jīng)理和產(chǎn)品經(jīng)理根據(jù)客戶給定的需求進(jìn)行分類，包括框架、加工方式、加工質(zhì)量、刀具選擇、仿真等需求，并對項目可能產(chǎn)生的需求進(jìn)行判斷和規(guī)劃，形成項目計劃書。項目計劃書包括項目背景、、需求以及預(yù)期完成時間。項目計劃書完成之后即可開始進(jìn)行第一個迭代，并以第一個迭代為基礎(chǔ)不斷進(jìn)行下去，直到完成所有需求。由于整體項目過于龐大，這里只對第一個迭代進(jìn)行介紹。

 

項目實例：第一個迭代中有2個需求，同時根據(jù)工作量分配任務(wù)天數(shù)以及每個需求的參與人員，如表1所示。

 

3.3迭代進(jìn)行階段

 

迭代開始時，項目經(jīng)理制定迭代的具體開發(fā)任務(wù)和測試任務(wù)。在迭代啟動會議中，每個人都要對此次迭代任務(wù)有統(tǒng)一認(rèn)識，并且能夠承載相應(yīng)的任務(wù)量，在需求確定完畢后進(jìn)行任務(wù)分配。

 

.

 

開發(fā)人員進(jìn)行編碼時，測試人員的工作重點包括：編寫測試計劃、測試用例、驗收測試以及提交和驗證。測試計劃和測試用例的編寫同時完成，且在迭代初期完成。驗收測試一般是在迭代后期進(jìn)行集成測試，迭代過程中也可以協(xié)助開發(fā)人員進(jìn)行單獨的功能測試。

 

3.3.1編寫測試計劃和測試用例

 

測試計劃需要具體的操作步驟以及相對完善的測試用例來涵蓋需求，因此需要測試人員有比較豐富的測試經(jīng)驗。

 

項目實例如下：

 

表2和表3中的TestParts需要填寫測試工件名稱。測試計劃編寫完成后要經(jīng)過開發(fā)人員和項目經(jīng)理確認(rèn)，保證開發(fā)人員認(rèn)同并能夠達(dá)到計劃的目標(biāo)。敏捷開發(fā)是不斷迭代的過程，對于一些比較簡單的功能，盡量設(shè)計簡潔的測試用例。如果TestParts比較多，可以采用自動化測試，而對于一些比較復(fù)雜的功能，可以先采用手動測試，在功能更加完善后再考慮自動化測試。

 

3.3.2驗收測試

 

驗收測試要嚴(yán)格按照迭代前期寫好的測試計劃進(jìn)行，在開發(fā)人員開發(fā)完此次迭代所有功能后，測試人員對所有功能進(jìn)行集成測試、功能測試、自動化測試等，完成所有測試工作后形成測試報告。報告內(nèi)容包括此次迭代基本功能完成情況、缺陷產(chǎn)生情況以及測試過程中的一些詳細(xì)數(shù)據(jù)。

 

3.3.3提交和驗證

 

團(tuán)隊全體成員參加驗收會議，由測試工程師對迭代成果進(jìn)行演示，產(chǎn)品經(jīng)理和項目經(jīng)理進(jìn)行驗收，項目需求全部完成則此次迭代成功，然后再對此次迭代中的不足之處進(jìn)行討論和改進(jìn)，或者提出創(chuàng)新之處。如果項目需求未達(dá)標(biāo)，或產(chǎn)生了過多缺陷，則此次迭代不予通過，全員討論延后驗收或?qū)⑷毕萃晟蒲雍蟮较乱粋€迭代。

 

項目實例：針對需求R1、R2的基本功能測試達(dá)到了計劃的標(biāo)準(zhǔn)，框架的視圖操作和顯示功能以及CAD模型輸入功能均正常運行且無缺陷。雖然框架本身存在一些缺陷，仍能滿足迭代的基本需求。經(jīng)過討論此次迭代成功，產(chǎn)生的bug在下一個迭代進(jìn)行完善。

 

3.4迭代后研討和下一次迭代討論

 

迭代完成后要對迭代過程進(jìn)行回顧，測試人員需要對bug進(jìn)行總結(jié)，包括測試過程中產(chǎn)生的問題，以及需要改進(jìn)的地方，然后對下一次迭代的需求進(jìn)行初步討論，決定下一個周期的工作內(nèi)容。

 

4結(jié)語

 

敏捷開發(fā)中的軟件測試應(yīng)當(dāng)遵循敏捷開發(fā)的基本原則，面對不同的開發(fā)方法和應(yīng)用環(huán)境，軟件測試方法也不同。敏捷測試作為從敏捷開發(fā)中成長起來的測試方法，與敏捷過程密不可分，本文對敏捷開發(fā)中的軟件測試特點和方法進(jìn)行了詳細(xì)描述。然而，真正在面對軟件測試時，測試用例的生成與覆蓋標(biāo)準(zhǔn)、測試的充分性和有效性、不同階段的測試關(guān)系等，以及如何將傳統(tǒng)測試中的一些方法應(yīng)用到敏捷測試中，需要探討的問題及方法仍然很多。