發(fā)布時間：2022-04-28 04:23:38
開篇：寫作不僅是一種記錄，更是一種創(chuàng)造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的1篇軟件測試論文，希望這些內(nèi)容能成為您創(chuàng)作過程中的良師益友，陪伴您不斷探索和進步。
軟件測試是一項需具有較強專業(yè)技術(shù)、學(xué)習(xí)和創(chuàng)新能力的工作,軟件測試人員必須要具有縝密的邏輯思維能力、全面的技術(shù)能力、敢想敢干的創(chuàng)新能力,要有較強的責(zé)任心和團隊合作精神以及出色的溝通能力等專業(yè)素質(zhì)。
國家示范性軟件學(xué)院的一個重要職責(zé)就是要在教學(xué)研究、教學(xué)實踐以及教學(xué)改革方面進行大膽的探索和實踐。因此,在完善已有課程體系及授課的同時,應(yīng)該充分利用優(yōu)秀的教學(xué)資源,總結(jié)教學(xué)經(jīng)驗和科研成果,編寫專業(yè)教材,力爭探索出一條為國家快速培養(yǎng)高素質(zhì)軟件工程人才之路。
北京工業(yè)大學(xué)軟件學(xué)院蔡建平教授長期從事軟件工程、軟件測試及軟件質(zhì)量保證的研究,在多年講授軟件測試課程經(jīng)驗和體會的基礎(chǔ)上,對軟件測試課程教學(xué)內(nèi)的知識點進行調(diào)整、補充和完善等方面的改革,針對軟件質(zhì)量評價和軟件高可靠性的要求,針對國內(nèi)軟件研發(fā)和測試外包的本地化要求,以及針對軟件測試用于各種應(yīng)用領(lǐng)域的要求選擇授課的知識點,并取得了較好的效果。
目前國內(nèi)關(guān)于軟件測試的書籍較多,其中很多書籍是翻譯的、為培訓(xùn)用的或介紹軟件測試技術(shù)和方法,作為教材滿足各類測試人員的學(xué)習(xí)還有一定的距離。本書是在作者長達二十幾年軟件工程、軟件測試和軟件質(zhì)量保證實踐經(jīng)驗和教學(xué)經(jīng)驗的基礎(chǔ)上,借鑒前人成果,參考當前軟件測試方法和技術(shù)應(yīng)用實踐案例進行編寫的。蔡建平教授編寫的《軟件測試大學(xué)教程》一書,以現(xiàn)代軟件測試需求為背景,以現(xiàn)代軟件測試技術(shù)和方法為基礎(chǔ),以當前軟件測試通常應(yīng)用為典型實例,從軟件危機及軟件缺陷開始,全面介紹軟件測試的基本概念,軟件測試的技術(shù)、方法和工具應(yīng)用,以及軟件測試在當前主流應(yīng)用中的具體開展和實施。
其特點如下:
(1) 內(nèi)容全面。突出全生命周期軟件測試概念、軟件質(zhì)量分析手段、現(xiàn)代軟件測試技術(shù)、主流測試工具應(yīng)用以及典型應(yīng)用測試方法等,幫助學(xué)生了解和掌握現(xiàn)代軟件測試的各種原理、方法和技術(shù),并能夠選擇合適的軟件測試工具進行相關(guān)測試。為培養(yǎng)學(xué)生今后成為高素質(zhì)、專業(yè)化的軟件測試人才打下基礎(chǔ)。
(2) 針對性強。針對軟件開發(fā)方法和技術(shù)的發(fā)展變化,針對我國軟件外包服務(wù)的蓬勃興起,針對我國國防工業(yè)如航空、航天、船舶、電子、通訊等大量重要軟件或關(guān)鍵軟件的實際應(yīng)用情況和測試需求,特別是對軟件高可靠性的要求,選擇教材的知識點。
(3) 重實踐性。該書對支撐現(xiàn)代軟件測試技術(shù)應(yīng)用的測試工具進行了全面地介紹,特別是對開源軟件測試工具的介紹,這對高校開設(shè)軟件測試實驗課程是非常有意義的。在教材中給出了軟件測試在幾個典型應(yīng)用領(lǐng)域具體實施的要點和注意事項,這對缺乏實踐經(jīng)驗的培養(yǎng)對象而言具有極好的引領(lǐng)作用,對開闊軟件測試人員的眼界、思路和具體實踐有很大幫助。
(4) 具前瞻性。書中不少內(nèi)容取材于互聯(lián)網(wǎng),在一定程度上體現(xiàn)了軟件測試技術(shù)的最新發(fā)展,具有較強的新穎性和現(xiàn)代性。
該書取材新穎、內(nèi)容翔實、通俗易懂、技術(shù)實用、覆蓋面廣、指導(dǎo)性強,對重點、難點闡述透徹,使其既可以符合現(xiàn)代軟件測試技術(shù)發(fā)展的潮流,又具有相對的穩(wěn)定性,還易于剪裁,以滿足各類符合軟件測試課程的教學(xué)需要和各類軟件測試人員的學(xué)習(xí)需要,同時能夠較好的滿足國內(nèi)企業(yè),特別是國內(nèi)各種測評機構(gòu)或組織對現(xiàn)代軟件測試人才培養(yǎng)的要求。
該書在現(xiàn)代軟件測試技術(shù)的教學(xué)、普及、推廣和軟件測試人才培養(yǎng)以及軟件測試教學(xué)知識體系的建立等方面進行了很好的探索。它的出版有助于國內(nèi)軟件測試人員和計算機相關(guān)專業(yè)的本科生及研究生的培養(yǎng),有益于推動現(xiàn)代軟件測試技術(shù)和方法的研究、教學(xué)和實踐的進一步發(fā)展,同時對我國軟件測試的發(fā)展起到積極的促進作用。
摘要：針對軟件行業(yè)人才供需矛盾和傳統(tǒng)教學(xué)模式局限性，分析問題原因，介紹項目驅(qū)動教學(xué)法的內(nèi)涵和實施辦法，探討基于項目驅(qū)動的軟件測試人才培養(yǎng)模式，從理論教學(xué)體系的改革、實踐教學(xué)體系的建設(shè)和3+1教學(xué)模式的實施進行深入探索。
關(guān)鍵詞：項目驅(qū)動教學(xué)法；軟件測試人才；培養(yǎng)模式；實踐教學(xué)
隨著軟件業(yè)的迅猛發(fā)展，軟件產(chǎn)品的質(zhì)量控制與質(zhì)量管理正逐漸成為企業(yè)生存與發(fā)展的優(yōu)秀。作為軟件產(chǎn)品質(zhì)量控制與質(zhì)量管理者，軟件測試工程師成為軟件開發(fā)企業(yè)必不可少的技術(shù)人才。近年來，軟件人才市場存在一種普遍現(xiàn)象：高校培養(yǎng)的軟件人才大多找不到合適的崗位，而軟件企業(yè)又招不到合適的人才。其根本原因在于學(xué)校的教育培養(yǎng)模式不能很好地適應(yīng)人才市場的需求[1]。軟件測試人才的教育應(yīng)該以培養(yǎng)多層次、應(yīng)用型、復(fù)合型軟件測試人才為目標，全面加強素質(zhì)教育，重點培養(yǎng)學(xué)生的敬業(yè)精神、創(chuàng)新能力和實踐能力，真正實現(xiàn)人才培養(yǎng)與市場需求的一致。傳統(tǒng)的教學(xué)模式在一定程度上已經(jīng)不能適應(yīng)新時期人才培養(yǎng)的需要，本文提出了基于項目驅(qū)動的軟件測試人才培養(yǎng)模式。
1項目驅(qū)動教學(xué)法的內(nèi)涵
傳統(tǒng)的教學(xué)模式按照課程的知識結(jié)構(gòu)組織教學(xué)，按章節(jié)講述，學(xué)生由淺入深逐步掌握知識和技能，然后將知識和技能應(yīng)用于實踐。其優(yōu)點是注重知識的內(nèi)部體系結(jié)構(gòu)，邏輯性較強，學(xué)生循序漸進地學(xué)習(xí)知識。但這種教學(xué)模式不利于培養(yǎng)學(xué)生的實踐技能和綜合素質(zhì)，導(dǎo)致學(xué)生實踐基礎(chǔ)薄弱、適應(yīng)性差，嚴重制約學(xué)生創(chuàng)新能力的發(fā)揮，學(xué)生難以適應(yīng)工程技術(shù)快速發(fā)展的要求。
項目驅(qū)動教學(xué)法來源于建構(gòu)主義學(xué)習(xí)理論，與其相適應(yīng)的項目驅(qū)動教學(xué)模式是以學(xué)生為中心、教師為主導(dǎo)，利用項目創(chuàng)建的情境、協(xié)作、會話、操作等學(xué)習(xí)環(huán)境要素充分發(fā)揮學(xué)生的主動性、積極性和創(chuàng)新精神，使學(xué)生有效地建構(gòu)所學(xué)知識，增強實踐能力[2]。項目驅(qū)動教學(xué)法在教學(xué)過程中以項目為主線展開，把相關(guān)知識點融入到項目的各個環(huán)節(jié)中去，層層推進項目。通過對問題的深化或功能擴充，來拓寬知識的廣度和深度，直至得到一個完整的項目的解決方案，從而達到學(xué)習(xí)知識、培養(yǎng)能力的目的。在這種模式中，教師根據(jù)學(xué)生已有的經(jīng)驗、知識、水平和興趣來選取適合的項目，使學(xué)生置身于探索知識的情境之中，綜合運用知識和技能解決實際問題，并在真實的項目流程中體驗項目管理的思想和團隊協(xié)作精神，提升創(chuàng)新和實踐能力。
2項目驅(qū)動教學(xué)法的實施
實施項目教學(xué)法，首先需要設(shè)計項目。項目的設(shè)計與選取直接影響到該教學(xué)模式的教學(xué)效果及學(xué)生的學(xué)習(xí)興趣，因此在設(shè)計項目時應(yīng)遵循以下幾條原則：
1) 項目涉及的知識面廣。項目應(yīng)涵蓋課程的主要知識要點和基本技能。
2) 項目大小和難易適中。每個項目組的人數(shù)控制在3～5個人，設(shè)計的項目能使學(xué)生通過努力在一定的時間內(nèi)完成。
3) 項目中任務(wù)順序合理。項目各個任務(wù)的順序，一方面要體現(xiàn)實際工作中解決問題的工作流程；另一方面要體現(xiàn)知識技能由淺入深的循序遞進。
4) 項目具有典型性。項目教學(xué)法中選擇的項目就是學(xué)生將來走向工作崗位可能要完成的實際工作任務(wù)，學(xué)校的學(xué)習(xí)就是將來實戰(zhàn)的摸擬演練，使學(xué)生的知識技能輕易就可以遷移到實際工作中去。
5) 項目規(guī)范性。項目開展過程中，每個階段的工作都應(yīng)在文檔中體現(xiàn)出來，文檔撰寫有嚴格的標準和規(guī)范[3]。
項目驅(qū)動教學(xué)法在理論課程和實踐課程的實施過程中所不同。
2.1項目驅(qū)動在理論課程中的實施
在理論課程中實施項目教學(xué)法需注重知識的串聯(lián)。教學(xué)過程中，教師不必在課程的基礎(chǔ)知識和基本技能講解清楚后，再進行項目教學(xué)，而是可以直接面對具體任務(wù)，在教師帶領(lǐng)學(xué)生分析解決每個具體任務(wù)的方法時，將相關(guān)聯(lián)的知識技能要點串聯(lián)起來，講解清楚，并讓學(xué)生理解透徹。由于完成一個具體任務(wù)的方法有多種，教師可只講解一種最實用的方法，其他方法可作為知識技能拓展，以討論、課內(nèi)課外作業(yè)的方式由學(xué)生自行完成。因為新知識新技能的學(xué)習(xí)是在解決具體的工作任務(wù)過程中進行的，這樣做，學(xué)生學(xué)習(xí)興趣濃厚，知識技能掌握牢固，而且容易遷移。在串聯(lián)知識技能要點時，教師要按照“實用”的原則，與完成具體工作任務(wù)無關(guān)的知識技能只作簡單提示，同時，引導(dǎo)學(xué)生自主地查閱文獻和資料的方式來學(xué)習(xí)，此外，教師在進行項目教學(xué)時還要引導(dǎo)學(xué)生對知識和技能進行舉一反三、觸類旁通的遷移。
2.2項目驅(qū)動在實踐課程中的實施
在實踐教學(xué)中，教師給學(xué)生的項目就是一個大任務(wù)，教師將項目分解成一個個小任務(wù)，學(xué)生則主動去求解每一個小任務(wù)，探究性地學(xué)習(xí)相關(guān)的知識和技能，在知識的運用中掌握實踐技能。通過任務(wù)的實施和完成，學(xué)生可以體驗到一種強烈的成就感。這種成就感會進一步增強學(xué)生的學(xué)習(xí)興趣，促使學(xué)生更加積極主動地去探究性地學(xué)習(xí)。
項目驅(qū)動教學(xué)法的實施必須注重學(xué)生開展項目的全過程，必須嚴格按照項目的具體實施流程進行，比如軟件測試項目必須按照測試計劃、測試設(shè)計、測試執(zhí)行和測試結(jié)果分析等來進行，每個階段的工作必須有撰寫規(guī)范的技術(shù)報告。
實施項目教學(xué)法時，教師應(yīng)高度重視對學(xué)生作品的評價。從表面上看，項目教學(xué)的結(jié)果只是學(xué)生完成項目后產(chǎn)生的作品，而實際上，它體現(xiàn)的是學(xué)生對相關(guān)知識技能的掌握水平。教師在評價學(xué)生作品時既要看學(xué)生的作品完成的質(zhì)量，又要看學(xué)生的操作過程是否規(guī)范實用，對任務(wù)完成優(yōu)秀的個人或團隊應(yīng)給予特別鼓勵。
3項目驅(qū)動的軟件測試人才培養(yǎng)模式
項目驅(qū)動教學(xué)法非常重視學(xué)生的主體活動，強調(diào)理論聯(lián)系實際，培養(yǎng)學(xué)生綜合解決問題的能力，增強團隊協(xié)作精神，提高項目管理能力，這與軟件測試人才培養(yǎng)目標相一致。使用項目驅(qū)動法進行軟件測試人才培養(yǎng)，需要從各個教學(xué)環(huán)節(jié)進行改革和創(chuàng)新。
3.1理論教學(xué)體系的改革
在軟件測試課程體系構(gòu)建時，我們將軟件測試人才培養(yǎng)定位于造就熟悉軟硬件基礎(chǔ)理論和測試相關(guān)知識、掌握軟件測試基本技能、具有良好發(fā)展?jié)撡|(zhì)和行業(yè)特色的高級專門人才。
3.1.1課程群的建設(shè)
以課程群的方式構(gòu)建理論教學(xué)體系。課程群是指以現(xiàn)代教育思想和理論為指導(dǎo)，圍繞同一專業(yè)或不同專業(yè)的人才培養(yǎng)目標要求，為完善相應(yīng)專業(yè)學(xué)生的知識、能力、素質(zhì)結(jié)構(gòu)，將相應(yīng)專業(yè)培養(yǎng)方案中的知識、方法、問題等方面具有邏輯聯(lián)系的若干課程重新規(guī)劃、整合構(gòu)建而成的有機的課程系統(tǒng)[4]。課程群建設(shè)具有建設(shè)集約化、系統(tǒng)開放性、成員團隊化等特點，它是以學(xué)生的培養(yǎng)為主線、以課程的邏輯聯(lián)系為紐帶、以教師團隊合作為支撐、以質(zhì)量效益為目標的新型課程建設(shè)模式。軟件測試人才培養(yǎng)課程可分為六個課程群：公共基礎(chǔ)、計算機軟硬件基礎(chǔ)、算法分析與設(shè)計、軟件工程、程序設(shè)計與開發(fā)、軟件測試技術(shù)，不同教師團隊分別承擔(dān)相應(yīng)課程群的教學(xué)和課程建設(shè)。
3.1.2在課程群中推廣測試思想
將軟件測試的思想深入廣泛地滲透到所有的專業(yè)課程中。在各類程序設(shè)計語言基礎(chǔ)課程中引入單元測試的思想，并在實驗教學(xué)中對程序進行單元測試。在軟件工程和軟件項目管理等課程中，強調(diào)軟件質(zhì)量保障和軟件測試的重要性，增強軟件質(zhì)量管理意識。在面向?qū)ο蠓治雠c設(shè)計和UML建模等課程中，引入測試驅(qū)動開發(fā)的思想，強調(diào)測試與設(shè)計并重。在軟件工程專業(yè)綜合實驗中，按照軟件測試模型開展實驗，進行軟件項目管理和軟件測試。在畢業(yè)設(shè)計中，學(xué)生開發(fā)的軟件系統(tǒng)必須進行全面、系統(tǒng)的測試。
3.2實踐教學(xué)體系的建設(shè)
使用項目驅(qū)動教學(xué)法分層次構(gòu)建各類實踐教學(xué)，分步驟分階段實施各類實踐教學(xué)活動。
1) 基礎(chǔ)實驗。
在基礎(chǔ)實驗教學(xué)中，根據(jù)課程知識結(jié)構(gòu)設(shè)計實驗內(nèi)容，然后按照軟件工程 “分而治之”的思想，將一個大的項目按實驗內(nèi)容的要求分解為多個實驗，在每個實驗中設(shè)計任務(wù)和目標，使學(xué)生可以由淺入深循序漸進地掌握基礎(chǔ)知識和技能，為下一步綜合實驗打下基礎(chǔ)。
2) 綜合實驗。
將軟件測試的V模型或W模型引入到綜合實驗教學(xué)中，按照軟件工程的流程開展軟件設(shè)計、開發(fā)、測試、管理的全過程訓(xùn)練。根據(jù)V模型或W模型的各階段劃分和分配訓(xùn)練任務(wù)，使軟件開發(fā)、測試和管理的綜合訓(xùn)練融為一體。通過模型的實施，分階段、分步驟地訓(xùn)練學(xué)生需求分析、概要設(shè)計、詳細設(shè)計、編碼、單元測試、集成測試和系統(tǒng)測試各階段的計劃、設(shè)計、實施、評估、報告等內(nèi)容，培養(yǎng)學(xué)生全方位的軟件開發(fā)、測試和管理的全過程能力。在實驗實施過程中，將學(xué)生分組，采用軟件項目組的模式開展項目。根據(jù)項目劃分不同小組，在小組中為每位成員分配任務(wù)，分別完成設(shè)計、開發(fā)、測試等各個階段的任務(wù)，以提高學(xué)生對軟件開發(fā)全過程的認識，培養(yǎng)學(xué)生軟件開發(fā)綜合應(yīng)用能力，增強軟件項目管理能力和團隊協(xié)作精神，進一步培養(yǎng)工程素養(yǎng)。
3) 學(xué)生科技活動。
以培養(yǎng)學(xué)生實踐能力和創(chuàng)新能力為目標，建設(shè)與課內(nèi)教學(xué)和生產(chǎn)實際相融合的創(chuàng)新實踐基地，搭建完善的軟件開發(fā)和測試平臺，將學(xué)生置于一個更真實的、富有實踐機遇和挑戰(zhàn)的實踐環(huán)境中。以學(xué)生為主體、教師為主導(dǎo)、課內(nèi)與課外結(jié)合、建設(shè)學(xué)生團隊和指導(dǎo)教師團隊。學(xué)生通過申報實驗室開放基金和軟件開發(fā)項目，以軟件項目為載體，任務(wù)為驅(qū)動，參與學(xué)生科技活動。通過軟件項目的實施，提高學(xué)生交流溝通水平和團隊協(xié)作精神；通過做事培養(yǎng)學(xué)生科學(xué)精神和敬業(yè)精神；通過做事培養(yǎng)學(xué)生專業(yè)技能和工程素養(yǎng)，增強創(chuàng)新能力和實踐能力。
4) 畢業(yè)設(shè)計。
畢業(yè)設(shè)計是培養(yǎng)學(xué)生科學(xué)研究能力、工程實踐能力、創(chuàng)新能力，提高綜合素質(zhì)和獲取工作經(jīng)驗的重要手段。畢業(yè)設(shè)計選題要盡可能結(jié)合生產(chǎn)、科研和實驗室建設(shè)的實際任務(wù)，減少虛擬題目的數(shù)量。題目可根據(jù)各專業(yè)的特點，結(jié)合教師的橫向與縱向課題進行課題的選擇、細化，使之成為符合學(xué)生畢業(yè)設(shè)計的課題。畢業(yè)設(shè)計完成的軟件作品必須進行全面系統(tǒng)的軟件測試，提高畢業(yè)設(shè)計作品的質(zhì)量。
3.3 “3+1”教學(xué)模式的實施
為更深入開展和實施基于項目的軟件測試人才培養(yǎng)模式，引入“3+1”教學(xué)模式。“3＋1”的教學(xué)模式就是學(xué)生在大學(xué)的前三年在學(xué)校學(xué)習(xí)，最后一年在企業(yè)實訓(xùn)。“3＋1”的教學(xué)模式是由學(xué)校和企業(yè)聯(lián)合辦學(xué)，培養(yǎng)專門化的技術(shù)人才[5]。該模式計劃大學(xué)前三年在高校學(xué)習(xí)基礎(chǔ)理論知識，最后一年在企業(yè)進行實踐教學(xué)的培養(yǎng)，利用企業(yè)的高級工程技術(shù)人員和設(shè)備進行實地教學(xué)。“3＋1”教學(xué)模式從工程技術(shù)發(fā)展和終身教育的需要出發(fā)，通過深化課程教學(xué)體系改革，強化學(xué)生的實踐能力，增強學(xué)生綜合素質(zhì)，大大開拓了學(xué)生視野[6]。為了培養(yǎng)具有創(chuàng)新精神與創(chuàng)業(yè)意識、基礎(chǔ)扎實、知識全面，適應(yīng)IT產(chǎn)業(yè)和經(jīng)濟信息全球化競爭的高層次、復(fù)合型、應(yīng)用型優(yōu)秀人才，學(xué)院從2009年開始對軟件工程專業(yè)部分學(xué)生實施“3+1”培養(yǎng)方案。與以前的人才培養(yǎng)方案相比，大幅度增加了基礎(chǔ)教學(xué)時間，減少了專業(yè)教學(xué)時間，明顯拓寬了專業(yè)口徑，淡化了專業(yè)界限，增強了社會適應(yīng)性。
4結(jié)語
通過項目驅(qū)動的軟件測試人才培養(yǎng)模式改革與實踐，學(xué)院教學(xué)改革已取得了實質(zhì)性進展和初步積累，學(xué)生創(chuàng)新和實踐能力明顯提高，創(chuàng)新成果明顯增加。如果要廣泛深入采用項目驅(qū)動教學(xué)模式，我們還需要不斷探索創(chuàng)新。為使社會需求和高校的人才培養(yǎng)無縫對接，我們還需要不斷尋求更好的人才培養(yǎng)模式。
摘要：針對軟件測試課程教學(xué)中缺乏系統(tǒng)實例、重技術(shù)實現(xiàn)輕文檔工作、測試工具使用流于產(chǎn)品說明等問題，文章就探索實驗教學(xué)進度和內(nèi)容進行了論述。依據(jù)實際軟件開發(fā)過程中軟件測試實施的方式方法，提出設(shè)計一套系統(tǒng)的軟件測試實驗內(nèi)容。文章還闡述了在教學(xué)過程中采用案例教學(xué)法，提供給學(xué)生完整的案例系統(tǒng)及充分的設(shè)計文檔，讓學(xué)生學(xué)會根據(jù)設(shè)計文檔書寫測試文檔、掌握測試工具的使用及自動化測試工具的開發(fā)。
關(guān)鍵詞：案例教學(xué)法；軟件測試過程；測試文檔
目前我國軟件測試人才嚴重匱乏，人才缺口達到30萬，造成這一結(jié)果的主要原因是國內(nèi)軟件測試人才教育相對滯后[1]。但實際上，很多學(xué)習(xí)了軟件測試課程的學(xué)生卻找不到工作，業(yè)內(nèi)專家稱之為人才的“結(jié)構(gòu)性過剩”[2]，而滯后的原因不僅僅是教育機構(gòu)開設(shè)軟件測試課程時間的滯后，主要是教學(xué)內(nèi)容和教學(xué)效果與實際需要的差距產(chǎn)生的滯后。外包開發(fā)行業(yè)快速發(fā)展，對人才在代碼和文檔方面的規(guī)范性、技能和工具的熟練程度要求越來越高[2]，而這些要求正是軟件測試人才教育的薄弱環(huán)節(jié)。因此，如何順應(yīng)市場需求，培養(yǎng)出企業(yè)所需的軟件測試人員，成為軟件測試課程改革創(chuàng)新的目標。
1教學(xué)現(xiàn)狀
隨著軟件測試人員市場需求的不斷增加，各大高校、職業(yè)技術(shù)學(xué)校及IT培訓(xùn)機構(gòu)紛紛開設(shè)了“軟件測試”課程。然而，在師資方面，講授軟件測試課程的教師多數(shù)是由軟件工程的教師承擔(dān)，這些主講教師能很好地講解軟件測試理論和介紹軟件測試方法，但缺乏軟件測試的系統(tǒng)案例和軟件測試經(jīng)驗[3]。在理論教材方面，雖然各種軟件測試的教材相繼出版發(fā)行，但教材中技術(shù)實現(xiàn)的內(nèi)容較多，對常用的軟件測試文檔書寫介紹很少，且缺乏文檔模板；對自動化測試工具，基本也是簡略介紹其功能。在實驗教材方面，目前還沒有配套的軟件測試實驗教材問世，在教學(xué)過程中基本是任課教師自行設(shè)計實驗教學(xué)內(nèi)容。對于實踐性較強的課程，主講教師如果沒有大量的實際項目開發(fā)經(jīng)驗作為支撐，就難于用恰當?shù)膶嵗齺斫忉屜嚓P(guān)理論，更難設(shè)計出實用有效的實驗內(nèi)容，導(dǎo)致在校學(xué)習(xí)的知識與實際工作脫節(jié)的現(xiàn)象。要順應(yīng)軟件測試人才市場的需求，軟件測試課程的教學(xué)必須面向企業(yè)的實際需要，使學(xué)生能學(xué)到實際工作中常用的技能，以“經(jīng)驗者”的身份進入人才市場參與競爭。
2改革和創(chuàng)新
筆者以日企工程經(jīng)驗為依據(jù)，針對軟件測試課程教學(xué)中缺乏系統(tǒng)案例、重技術(shù)實現(xiàn)輕文檔工作、測試工具流于產(chǎn)品說明等問題[4]，設(shè)計了一套軟件測試實驗，幫助學(xué)生利用軟件測試技術(shù)搭建測試環(huán)境；根據(jù)測試規(guī)格說明書進行測試；練習(xí)測試用例的設(shè)計、執(zhí)行與跟蹤并高效地進行回歸測試；熟悉常用測試文檔的書寫方法；掌握如何保存測試用例和有效的測試結(jié)果；準確地書寫缺陷報告；通過思考題的方式啟發(fā)學(xué)生利用計算機技術(shù)開發(fā)自動化測試工具。
2.1教學(xué)進度的調(diào)整
計算機課程的實驗教學(xué)，通常和理論課同步或延遲幾周進行。對于軟件測試這門課程的實驗教學(xué)，如果與理論課同步進行，前期的實驗內(nèi)容安排就缺乏理論支持，如果比理論課遲后幾次，即在講述白盒測試和黑盒測試后開始實驗教學(xué)，就可以將各種測試方法融入實驗中進行，但由于軟件測試過程及技術(shù)、測試文檔書寫相關(guān)內(nèi)容還未講述，實驗內(nèi)容的安排顯得孤立，沒有整體感。為了讓學(xué)生體驗軟件測試在實際工作環(huán)境中的實施過程，將理論課講述的知識有機地融入到完整的案例中進行實驗，就需要系統(tǒng)地學(xué)習(xí)完理論知識后，再結(jié)合實際案例系統(tǒng)地進行實驗。
我們打破傳統(tǒng)的周四學(xué)時，即“理論2+實驗2”的排課模式，將一個學(xué)期分為理論上半學(xué)期，實驗下半學(xué)期，上半學(xué)期周四學(xué)時用于結(jié)合案例進行理論教學(xué)，下半學(xué)期周四學(xué)時針對理論課講述的案例進行實驗教學(xué)，以便學(xué)生能夠模擬實際工作環(huán)境進行系統(tǒng)的軟件測試實驗。
2.2實驗教學(xué)的創(chuàng)新
2.2.1實驗素材的創(chuàng)新
現(xiàn)有的軟件測試教材，通常會在最后章節(jié)給出一個案例，針對該案例利用教材上介紹的各種測試方法有針對性地進行測試用例設(shè)計。但是教材對案例的描述基本只限于項目背景介紹、子系統(tǒng)介紹、子系統(tǒng)功能分析、子系統(tǒng)性能及可用性要求方面的資料，基本沒有提供可運行案例系統(tǒng)的代碼，同時也缺乏必要的供測試使用的文檔。實際工作中，軟件測試過程與軟件設(shè)計周期有相互對應(yīng)的關(guān)系，軟件測試過程中的單元測試、集成測試、系統(tǒng)測試、驗收測試分別對應(yīng)軟件設(shè)計中的詳細設(shè)計、概要設(shè)計、系統(tǒng)設(shè)計和需求分析[5]。因此，要完成一個系統(tǒng)的較完整測試過程，不僅要提供被測系統(tǒng)的完整代碼及數(shù)據(jù)，還必須提供全套的設(shè)計文檔。
我們以一個開發(fā)完整的以C/S模式實現(xiàn)的“小區(qū)物業(yè)管理系統(tǒng)”和B/S模式實現(xiàn)的“圖書館管理系統(tǒng)”作為測試案例，在理論課教學(xué)中主要以“小區(qū)物業(yè)管理系統(tǒng)”作為案例進行理論知識的講解，與網(wǎng)站測試和面向?qū)ο鬁y試相關(guān)的內(nèi)容以“圖書館管理系統(tǒng)”作為案例進行講解。這樣，進行完理論教學(xué)，學(xué)生對案例系統(tǒng)的功能基本了解。在實驗教學(xué)中，我們提供給學(xué)生在測試中需要的代碼、開發(fā)規(guī)范、需求分析、系統(tǒng)設(shè)計書、概要設(shè)計書、詳細設(shè)計書，具備了以上資料，便可模擬實際工作模式，將理論教學(xué)中講述的測試策略和方法、測試文檔的書寫方法運用到該案例的測試實驗中。
2.2.2實驗內(nèi)容的創(chuàng)新
由于實驗教學(xué)學(xué)時和學(xué)生能力的限制，在本實驗的設(shè)計中，我們主要針對初、中級測試工程師級別設(shè)計實驗內(nèi)容，這些實驗內(nèi)容就是同學(xué)們踏上測試崗位要動手干的實際工作。而針對高級測試工程師和測試管理者擔(dān)當?shù)墓ぷ鳎热鐪y試計劃的制作、各種設(shè)計的驗證、測試評估和總結(jié)，需要經(jīng)歷初中級測試工程師的實戰(zhàn)，積累大量經(jīng)驗才能承擔(dān)，這一部分內(nèi)容，我們只在理論教學(xué)中簡單講述，不在實驗教學(xué)中安排實驗內(nèi)容。
我們設(shè)計了表1所示的實驗內(nèi)容，本設(shè)計旨在讓學(xué)生經(jīng)過實驗的訓(xùn)練，以“經(jīng)驗者”的角色參與求職應(yīng)聘，因此，我們以項目管理者培養(yǎng)“新人”的方式來安排實驗內(nèi)容和進度。雖然軟件測試貫穿于軟件生命周期的全過程，但對于剛畢業(yè)的大學(xué)生來說，從人才培養(yǎng)角度出發(fā)，項目管理者通常是按照以下流程在工作過程中培養(yǎng)人才：單純性測試的實施、測試設(shè)計(書寫測試規(guī)格說明書)、測試環(huán)境搭建等，按照單元測試、集成測試、系統(tǒng)測試的順序循序漸進地深入測試工作，因此我們按如下進度設(shè)計了以下實驗內(nèi)容，并在提供的素材中人為地制造缺陷，以便學(xué)生發(fā)現(xiàn)缺陷、分析缺陷、修改缺陷。
通過上述8個實驗，讓學(xué)生牢固掌握單元測試和集成測試的設(shè)計和實現(xiàn)方法，了解常用測試工具的使用方法，同時對系統(tǒng)測試實施有基本了解。嚴格經(jīng)過這8個實驗的訓(xùn)練，學(xué)生基本能以初級測試工程師的身份投入到測試工作中。
2.2.3實驗過程的創(chuàng)新
為提高實驗教學(xué)效果，有的放矢地做好每一次實驗，我們將每次實驗分為四個階段。第一階段是以學(xué)生為主體的實驗預(yù)習(xí)，要求學(xué)生進入實驗室之前明確實驗?zāi)康摹?nèi)容，并以書面形式完成實驗步驟設(shè)計及實驗時間分配；第二階段是以教師為主體的實驗概述，用10分鐘的時間結(jié)合理論內(nèi)容講解實驗涉及的知識點、實驗素材的作用及注意事項；第三階段是以學(xué)生為主體的實驗實施，實施過程中教師隨堂抽檢學(xué)生進行狀況，對個別問題個別提示，普遍問題全體提示，并解答實驗中學(xué)生遇到的問題；第四階段是以教師為主體的實驗總結(jié)，教師對實驗過程中遇到的問題進行分析總結(jié)，選擇較好的實驗成果進行點評，最后結(jié)合本次實驗，引出思考題，提示學(xué)生靈活應(yīng)用計算機專業(yè)知識，進行自動化測試的探索和創(chuàng)新。
摘要:從目前國內(nèi)研究生“軟件測試理論與技術(shù)”課程教學(xué)實際出發(fā),在分析目前國內(nèi)研究生學(xué)習(xí)基礎(chǔ)、學(xué)習(xí)需求及學(xué)習(xí)能力的基礎(chǔ)上,提出一種緊密結(jié)合測試案例、測試理論與實踐交叉進行的教學(xué)新方法。
關(guān)鍵詞:研究生教學(xué);軟件測試;測試案例;交叉教學(xué);測試實踐
隨著國家信息化建設(shè)步伐的不斷加快,軟件日益成為信息系統(tǒng)中極為重要的組成部分。軟件的可信性已倍受關(guān)注,目前軟件測試仍然是保障和提高軟件質(zhì)量的一種有效方法。同時隨著國內(nèi)軟件產(chǎn)業(yè)的標準化與國際化,越來越需要專門的軟件測試高級人才。當前高校仍然是培養(yǎng)軟件測試專業(yè)人才的重要機構(gòu)。
目前我國高校開設(shè)軟件測試課程按學(xué)歷分主要有三個層次:大專、本科與研究生階段。大專和本科階段的軟件測試課程在我國已經(jīng)開設(shè)有較長時間了,主要是教授基本的軟件測試理論與技術(shù),側(cè)重以基礎(chǔ)知識為優(yōu)秀。一些高校已經(jīng)摸索出一些好的教學(xué)經(jīng)驗和方法,發(fā)表了一些教學(xué)體會[1-3]。但是,研究生(本文特指碩士研究生,下同)階段的軟件測試課程教學(xué)卻面臨很多新的問題。特別是隨著近幾年高校研究生招生規(guī)模的擴大及招生形式的多樣化,各高校研究生生源相差較大,學(xué)習(xí)目的與培養(yǎng)形式也有所差異,使得研究生的軟件測試課程教學(xué)很難采取統(tǒng)一標準,給各校任課老師提出了新的挑戰(zhàn)。從我校研究生軟件測試課程教學(xué)實際出發(fā),筆者分析了近年來研究生在學(xué)習(xí)基礎(chǔ)、學(xué)習(xí)能力及學(xué)習(xí)目的上的諸多變化,提出了一種“緊密結(jié)合測試案例、測試理論與實踐交叉進行”的軟件測試教學(xué)新方法。該方法連續(xù)實施在兩級研究生的教學(xué)實踐中,從課堂反應(yīng)、課程考核、案例測試實踐指標來看,該方法較大程度地激發(fā)學(xué)生的學(xué)習(xí)興趣,提高了研究生測試理論知識及實踐測試動手能力。
1傳統(tǒng)教學(xué)及面臨的新問題
1.1傳統(tǒng)的研究生軟件測試教學(xué)形式
2010年5月我們參加了第四屆全國軟件工程領(lǐng)域碩士培養(yǎng)工作研討會,與會期間我們和軟件測試同行進行了廣泛的交流。大部分院校認為軟件測試教學(xué)大綱仍然沿用研究生招生改革之前的大綱,即教學(xué)對象為傳統(tǒng)的學(xué)術(shù)型研究生,課程教學(xué)仍然以理論教學(xué)為主,教學(xué)內(nèi)容也以書本為主,按章節(jié)進行教學(xué)。課程結(jié)束考試仍以論文報告的形式完成。總結(jié)大部分高校共同的教學(xué)內(nèi)容有:
1) 軟件測試概述;
2) 測試人員的離散數(shù)學(xué);
3) 測試人員的圖論;
4) 功能性測試;
5) 結(jié)構(gòu)式性測試;
6) 集成測試;
7) 系統(tǒng)測試;
8) 面向?qū)ο鬁y試等。
傳統(tǒng)教學(xué)以教授學(xué)生理論知識為主,旨在培養(yǎng)懂理論的學(xué)術(shù)型研究生。未考慮學(xué)生的水平、學(xué)習(xí)需求、學(xué)習(xí)目的及學(xué)習(xí)能力等因素的差異,導(dǎo)致相當一部分同學(xué)失去學(xué)習(xí)興趣。此外教學(xué)過程沒有測試案例及其他實踐測試環(huán)節(jié),導(dǎo)致總體教學(xué)效果不理想,課程結(jié)束后大部分同學(xué)均沒有掌握基本的軟件測試理論與技術(shù)。
1.2研究生教學(xué)的新特點
隨著近年來國家研究生招生及培養(yǎng)方式的改革,研究生的招生規(guī)模、招生形式及培養(yǎng)方案等均變化較大。以前是以工學(xué)碩士為主,重點培養(yǎng)懂理論、會創(chuàng)新的高級學(xué)術(shù)型研究人才。近年來,國家碩士研究生招生已細分為工學(xué)碩士及工程碩士,工學(xué)碩士又分為學(xué)術(shù)型與應(yīng)用型。工程碩士和應(yīng)用型碩士側(cè)重于培養(yǎng)工程開發(fā)、工程應(yīng)用、工程管理等應(yīng)用創(chuàng)新型高級人才。研究生招生及培養(yǎng)制度的改革促使培養(yǎng)方案不一樣,相應(yīng)的課程大綱及教學(xué)方式也應(yīng)不一樣。故研究生軟件測試課程教學(xué)面臨的主要特點有:
1) 理論與實踐并重;
2) 加強工程案例的測試教學(xué);
3) 激發(fā)學(xué)生興趣,互動教學(xué);
4) 側(cè)重于培養(yǎng)學(xué)生的實際測試動手能力。
現(xiàn)階段研究生軟件測試課程應(yīng)考慮所有選修學(xué)生的學(xué)習(xí)基礎(chǔ)、學(xué)習(xí)需求、學(xué)習(xí)目的及學(xué)習(xí)能力的多
樣化,重點學(xué)習(xí)以下內(nèi)容:常用軟件功能性測試方法;面向?qū)ο蟪绦驕y試技術(shù);WEB軟件測試;錯誤注入測試技術(shù);安全性測試、主流軟件自動化測試工具及大公司常用測試方法等。通過課程的學(xué)習(xí),使學(xué)生較好地掌握軟件測試理論、先進的軟件測試技術(shù)和主流測試工具,并能較好地應(yīng)用于實際軟件工程項目中。
2案例交叉教學(xué)法大綱及其教學(xué)過程
基于研究生培養(yǎng)方案的諸多變化,我們提出了一種緊密結(jié)合測試案例、測試理論與實踐交叉進行的教學(xué)新方法。該方法以學(xué)生為中心,旨在激發(fā)學(xué)生的學(xué)習(xí)興趣,提高學(xué)生的理論知識和實際案例測試能力。
2.1江蘇大學(xué)研究生軟件測試教學(xué)大綱
表1是我校現(xiàn)行的研究生軟件測試教學(xué)大綱,全校理工科研究生也可選修。
2.2案例交叉教學(xué)法教學(xué)過程
案例交叉教學(xué)法總體分成兩個階段:課前案例程序編寫和課堂理論與案例交叉教學(xué)。
第一階段:課前案例程序編寫。上課前一周布置實現(xiàn)兩個測試案例,每學(xué)期難度類型與之類似。
案例1:使用C、C++或C#語言編寫一個程序,計算任意兩個正整數(shù)a,b的最大公因數(shù),其中0≤a,b≤1060。并撰寫程序設(shè)計說明書。
案例2:使用ASP或JSP技術(shù),數(shù)據(jù)庫SQL Server實現(xiàn)具有用戶注冊、登陸驗證的簡單B/S結(jié)構(gòu)系統(tǒng)。
當然,可以根據(jù)不同學(xué)生的水平布置不同的案例程序,要求所布置程序難度、功能和工作量與案例1和2相當,即案例1滿足后期單元測試、功能測試、類測試、錯誤注入測試、安全測試及編寫測試驅(qū)動等測試需求,案例2滿足后期GUI測試、WEB測試、錯誤注入測試、安全測試及測試工具的教學(xué)等測試需求。
第二階段:課堂理論與案例交叉教學(xué)。結(jié)合前面兩個案例,自第二章開始結(jié)合測試案例、測試理論與實踐交叉進行教學(xué)。具體教學(xué)流程如圖1所示。
圖1案例交叉教學(xué)流程圖
圖1中,S1代表第1章,其它類似。案例1重點是讓學(xué)生掌握基于程序結(jié)構(gòu)的測試方法,如邊界值測試、等價類測試、類測試、數(shù)據(jù)流與控制流測試方法等。案例2重點讓學(xué)生掌握基于程序規(guī)格說明的測試方法,如GUI測試、錯誤注入測試及基于狀態(tài)的測試等方法。此外,結(jié)合案例1和2,不但教授學(xué)生重要的功能性測試方法,而且教授學(xué)生一些關(guān)于軟件安全
性、可靠性及穩(wěn)定性的測試思路,全面提高學(xué)生的綜合測試能力。
此外,我們的教學(xué)過程中將聯(lián)系國內(nèi)外大型軟件企業(yè)的實際測試方法及測試工具。如我們選用的教材之一便是微軟軟件測試工程師們撰寫的教程,所講授是主流自動化測試工具系列:Parasoft公司AEP方案系列、Mercury Interactive公司系列及IBM Rational系
列。重點講授的自動化測試工具主要有:Parasoft C++Test;Mercury公司主要產(chǎn)品LoadRunner、WinRunner、TestDirector、QuickTestPro、IBM Rational Purify等。同時將結(jié)合程序案例1、2及其他大型測試案例進行工具的演示教學(xué)。
3教學(xué)效果分析
我們連續(xù)對兩級研究生運用了案例交叉教學(xué)法,在課程結(jié)束后對50名學(xué)生進行了問卷調(diào)查,同時結(jié)合學(xué)生考試成績及課程測試報告情況,結(jié)果表明案例交叉教學(xué)法教學(xué)效果明顯好于傳統(tǒng)的按章節(jié)教學(xué)方法。表2從學(xué)生興趣、理論掌握度、測試用例設(shè)計、測試驅(qū)動編寫、測試方案設(shè)計、測試思想及自動化測試工具的掌握等方面進行了教學(xué)效果對比分析。
學(xué)生問卷調(diào)查中的學(xué)生興趣度以調(diào)查結(jié)果為主,其他調(diào)查項均以課程考核結(jié)果為主,調(diào)查結(jié)果為參
照。在課程期末考核中除了考查常規(guī)的測試基本理論與技術(shù)之外,同時還要求學(xué)生交叉測試其他同學(xué)的程序案例,最后撰寫測試用例設(shè)計報告及程序測試報告。
由表2數(shù)據(jù)對比分析可知,案例交叉教學(xué)法在各方面都明顯優(yōu)于傳統(tǒng)的按章節(jié)教學(xué)法,特別是學(xué)生在掌握測試思想及測試自動化工具方面近96%以上的學(xué)生掌握較好。
4結(jié)語
隨著近年來軟件企業(yè)規(guī)模化、正規(guī)化及國際化步伐的加快,社會越來越需要大量的專業(yè)化高級軟件測試人才,這給高等院校及高級軟件人才培訓(xùn)機構(gòu)帶來了新的挑戰(zhàn)。本文提出了一種緊密結(jié)合測試案例、測試理論與實踐交叉進行的教學(xué)新方法。該方法綜合考慮學(xué)生的學(xué)習(xí)要求、學(xué)習(xí)基礎(chǔ)及學(xué)習(xí)目的等諸多因素,以培養(yǎng)學(xué)生的測試興趣為出發(fā)點,以學(xué)生自己編寫的程序為測試案例,將測試理論、測試技術(shù)、測試案例及測試工具結(jié)合起來進行教學(xué)。課程最后介紹了微軟公司常用的一些測試方法。
通過測試能力考核及課后調(diào)查表明,絕大部分學(xué)生認為新方法教學(xué)更有利于他們掌握軟件測試基本理論,提高測試案例實踐編寫能力,特別是學(xué)會了主流自動化測試工具的應(yīng)用。教師們也普遍反映軟件測試課程的教學(xué)質(zhì)量和教學(xué)效果有明顯的提高。
摘要:分析軟件測試課程的教學(xué)背景,從教學(xué)內(nèi)容、教學(xué)資源、教學(xué)方法、實踐方法、師資建設(shè)等方面對軟件測試課程的教學(xué)改革進行探討,提出課程建設(shè)的具體措施,以期對高校軟件測試課程建設(shè)具有參考意義。
關(guān)鍵詞:軟件測試;教學(xué)方法;教學(xué)改革;課程建設(shè)
隨著軟件產(chǎn)業(yè)迅速發(fā)展,軟件測試的作用越來越重要,地位得到前所未有的提高。軟件測試人才需求量劇增,職業(yè)價值日益提升。然而在作為軟件人才的主要培養(yǎng)渠道――傳統(tǒng)的大學(xué)計算機教育中,軟件測試教育存在很多問題。
首先,在很多高校軟件工程相關(guān)專業(yè)中,沒有開設(shè)專門的軟件測試技術(shù)課程,軟件測試技術(shù)只是作為軟件工程的一部分被提及,還有一些學(xué)校只是把軟件測試技術(shù)作為選修課,課時較少,則側(cè)重理論講解和測試方法介紹,忽視了極為重要的實踐環(huán)節(jié)[1]。而軟件測試課程的實踐性很強,如果沒有實驗實訓(xùn)環(huán)節(jié)支持,只是枯燥地講解測試理論和方法,會使學(xué)生產(chǎn)生抵觸和厭學(xué)情緒,影響教學(xué)效果。同時,測試工具和測試對象都是看不見、摸不著的軟件產(chǎn)品,實踐課程的組織和實施有較大的難度。由于缺少基礎(chǔ)理論知識和系統(tǒng)訓(xùn)練,很多高校畢業(yè)生雖然想從事測試工作,卻離軟件公司對測試人才的要求差距較大,從而被拒之門外。
其次,缺乏講授軟件測試課程的教師。高校軟件工程的主講教師能很好的講解軟件測試理論和測試方法,但缺乏較好的軟件測試案例和軟件測試經(jīng)驗,而這正是講授好軟件測試課程的關(guān)鍵所在,也是很多老師不愿意上該課程的原因。
第三,學(xué)生對軟件測試的認識也直接影響他們對軟件測試技術(shù)的掌握。一些不規(guī)范的軟件公司往往讓新進人員和編程能力較差的人員從事軟件測試,這讓很多學(xué)生片面地認為不會編程序的人才從事軟件測試,從而不重視軟件測試技術(shù)的學(xué)習(xí)和訓(xùn)練[2]。
在這種情況下,為培養(yǎng)應(yīng)用型、技能型軟件測試人才,我校計算機與信息學(xué)院自2005年就在軟件工程本科專業(yè)中開設(shè)了軟件測試技術(shù)以及相關(guān)實踐課程,并將其作為該專業(yè)的主干課程來建設(shè),在課程的建設(shè)方面做了一定的探索,積累了一些經(jīng)驗。
1突出培養(yǎng)目標,完善課程內(nèi)容新體系
作為一般本科院校,我們的培養(yǎng)目標是為社會輸送應(yīng)用型高級人才。針對軟件測試技術(shù)課程,教學(xué)目標是通過對軟件測試技術(shù)的理論學(xué)習(xí)和系統(tǒng)訓(xùn)練,使學(xué)生了解軟件測試在軟件開發(fā)過程中的重要作用和地位,理解軟件測試的基本概念和基本理論,掌握軟件測試技術(shù)和方法,能運用軟件測試技術(shù)解決實際問題,并了解軟件測試職業(yè)特點及軟件測試人員素質(zhì)要求。按照這一培養(yǎng)目標,我們結(jié)合實際,在教學(xué)內(nèi)容和教學(xué)資源建設(shè)等方面進行了探索。
1.1合理安排教學(xué)內(nèi)容,適應(yīng)應(yīng)用型人才培養(yǎng)目標
軟件測試技術(shù)課程內(nèi)容應(yīng)體現(xiàn)傳授知識與發(fā)展能力相統(tǒng)一,重視能力發(fā)展,其結(jié)構(gòu)要與學(xué)生認知結(jié)構(gòu)相統(tǒng)一,應(yīng)以軟件測試基本理論為基礎(chǔ),引入案例教學(xué),輔以討論、報告會等方式,突出實踐教學(xué)環(huán)節(jié)。
我們把教學(xué)內(nèi)容分為課堂教學(xué)、實驗教學(xué)和課程設(shè)計三大部分,在教學(xué)過程中采用案例教學(xué),并增加配套實驗和課程設(shè)計學(xué)時。其中課堂教學(xué)在軟件工程概論課程結(jié)束之后開始,安排在第5學(xué)期進行,包括軟件測試基本概念、各種測試技術(shù)和方法、測試用例的設(shè)計、軟件測試項目的組織和管理等,共32學(xué)時;實驗教學(xué)同步安排,主要是一些基礎(chǔ)實驗,包括白盒測試、黑盒測試等,通過學(xué)習(xí)實踐,讓學(xué)生掌握軟件測試最基本的一些方法,共16學(xué)時;課程設(shè)計安排在第6學(xué)期后半學(xué)期集中進行,學(xué)生自由組合為小組,分角色進行,課程設(shè)計強調(diào)學(xué)生的綜合設(shè)計和運用能力,主要是讓學(xué)生掌握各種測試方法在大型項目中的應(yīng)用,熟悉測試項目中的管理,感受大型測試項目的工作流程,共32學(xué)時。
這樣安排的課程內(nèi)容體系,理論與實踐教學(xué)的比例達到1∶1.5,加強了實用性,使教學(xué)內(nèi)容以應(yīng)用為重點,循序漸進,深入淺出,課程結(jié)構(gòu)更加合理。
1.2編寫多種教學(xué)輔助資料,完善配套教學(xué)資源
軟件測試技術(shù)不斷發(fā)展,課程講授的內(nèi)容應(yīng)該與時俱進,我們不能只局限于教材內(nèi)容,應(yīng)在講解基本原理、基本概念和基本方法的同時,注意增加一些前沿技術(shù)的介紹。同時,為配合課堂教學(xué),加強課后指導(dǎo)和實踐環(huán)節(jié),我們編寫了《軟件測試技術(shù)實驗指導(dǎo)》和《軟件測試技術(shù)課程設(shè)計指導(dǎo)書》等內(nèi)部資料。通過這些資料,鞏固、深化課堂教學(xué),啟發(fā)學(xué)生積極思考,提高動手能力,達到舉一反三的目的。
此外,為了增大課堂信息量、提高教學(xué)水平和效果,我們精心制作了全新的多媒體課件,在授課時充分結(jié)合現(xiàn)代教育手段和傳統(tǒng)板書,做到重點突出,直觀易懂,使課時利用率大大提高;同時還向?qū)W生提供大量相關(guān)電子文檔資料、參考文獻和參考網(wǎng)站地址等,使學(xué)生可以進行主動性學(xué)習(xí)。另外,為了便于教師和學(xué)生檢驗學(xué)習(xí)效果,我們還建立考核系統(tǒng)和題庫,搜集了豐富的各種類型題目,并進行了匯總和整理。
2強化實踐教學(xué)環(huán)節(jié),提高學(xué)生的動手能力
軟件測試技術(shù)是一門實踐性很強的課程,有效的實踐教學(xué)是促進知識理解,培養(yǎng)創(chuàng)造力極為重要的一個環(huán)節(jié)。在實踐教學(xué)中,我們重點做到“兩有、兩嚴、一寬”。“兩有”即:有指導(dǎo),在教師的指導(dǎo)下,學(xué)生首先對上機內(nèi)容進行分析,然后做出合理設(shè)計;有目標,對每一部分內(nèi)容,都有培養(yǎng)學(xué)習(xí)能力的具體目標。“兩嚴”即:嚴格要求學(xué)生自己動手設(shè)計方案并調(diào)試,杜絕個別同學(xué)拷貝的現(xiàn)象;嚴格驗收和檢查,要求學(xué)生編寫規(guī)范化文檔,并結(jié)合演示,隨機抽取提問等手段,使學(xué)生在思考―實現(xiàn)―再思考中真正得到提高。“一寬”即為學(xué)生提供寬松的學(xué)習(xí)氣氛,鼓勵學(xué)生發(fā)表自己的見解,充分調(diào)動學(xué)生的主觀能動性。
2.1以提高應(yīng)用能力為出發(fā)點,由淺入深、循序漸進地設(shè)計實驗內(nèi)容
軟件測試作為一門實踐性很強的課程,內(nèi)容眾多,包括多種軟件測試方法和測試工具的使用。為了保證教學(xué)效果,我們按照由淺入深、循序漸進的原則安排了基礎(chǔ)性、綜合性和設(shè)計性3級實驗的方案。
其中,基礎(chǔ)性實驗是較簡單操作性實驗,主要包括白盒測試和黑盒測試,共8學(xué)時,通過學(xué)習(xí),讓學(xué)生掌握軟件測試的一些基本方法,加深對理論的理解。綜合性實驗是對各知識點的綜合應(yīng)用,使學(xué)生理解和掌握軟件測試技術(shù)和各種具體的測試方法在項目中的應(yīng)用,感受軟件測試項目的工作流程和實施細節(jié),共8學(xué)時。基礎(chǔ)性實驗和綜合性實驗穿插與理論課同步進行,與課堂教學(xué)相輔相成,啟發(fā)學(xué)生深入思考,勇于創(chuàng)新,達到理論聯(lián)系實際的教學(xué)效果。最后32學(xué)時的設(shè)計性實驗是本課程最高層次的應(yīng)用性設(shè)計實驗,需要學(xué)生自主設(shè)計、自主管理,分組進行,安排在暑假前的兩周集中進行,目的是使學(xué)生體會軟件測試的規(guī)律,熟悉軟件測試項目中人員、產(chǎn)品、測試用例及缺陷的管理,鍛煉學(xué)生的綜合能力。
通過3級實驗的安排,讓學(xué)生感受到理論與實踐相結(jié)合以培養(yǎng)實踐能力的重要性,徹底改變重理論、輕實踐的傳統(tǒng)教學(xué)模式。教學(xué)實踐表明,學(xué)生通過3級實驗,更牢固地掌握了理論和技術(shù),有效提高了工程設(shè)計能力。
2.2建設(shè)實踐教學(xué)案例庫,扎實執(zhí)行實踐訓(xùn)練
為了保障軟件測試課程的教學(xué)水平,提高教學(xué)效果,我們采用了案例教學(xué)法。以可操作的軟件測試案例為中心,讓學(xué)生能在教學(xué)和實踐的過程中體會實際的測試過程。為了保證案例的有效性和可操作性,以便在課堂教學(xué)中取得應(yīng)有效果,我們收集建設(shè)了實踐教學(xué)案例庫。這些案例有的是從軟件企業(yè)中收集,有的是從學(xué)生畢業(yè)設(shè)計和上機作業(yè)中收集,還有的是從教材及網(wǎng)上收集[3],另外也有教師自己設(shè)計開發(fā)的。有了這些教學(xué)案例,大大方便了學(xué)生的實踐訓(xùn)練。
2.3搭建實驗平臺,實施開放式實驗教學(xué)
為了引導(dǎo)學(xué)生重視所學(xué)知識與行業(yè)發(fā)展、市場需求的結(jié)合,以便在今后的就業(yè)中更具有競爭力,通過比較和論證,我們最后選擇了大多數(shù)企業(yè)測試部門最常用的一些測試工具,包括WinRunner、LoadRunner、JUnit、Rational工具、Bugzilla等,對于大多數(shù)被測軟件來說,這些測試工具完全能夠支撐整個軟件測試過程。
在搭建實驗平臺的同時,全面實施開放式實驗教學(xué),通過軟件工程實驗室,學(xué)生能全天候進行實踐,老師能隨時指導(dǎo)學(xué)生做設(shè)計,以及回答學(xué)生的提問,使學(xué)生的實驗時間更加充分和自由。
3提高教學(xué)效果,加強師資建設(shè)和培養(yǎng)
要培養(yǎng)合格的應(yīng)用型學(xué)生,首先應(yīng)培養(yǎng)合格的教師。為了提高教學(xué)效果,我院經(jīng)常選送任課老師到正規(guī)軟件公司的軟件測試部門實習(xí),學(xué)習(xí)企業(yè)的軟件測試管理和開發(fā)過程,并在企業(yè)許可的情況下,收集測試案例,豐富實踐教學(xué)。另外還派遣任課教師到優(yōu)秀的軟件測試培訓(xùn)機構(gòu)進行培訓(xùn),以及攻讀博士學(xué)位等,在教學(xué)中結(jié)合項目實踐,將第一線的技術(shù)、信息帶進課堂,通過培訓(xùn)和項目實踐,進一步豐富了實踐經(jīng)驗,促進了教學(xué)手段、方法的改進。此外,我院還經(jīng)常不定期地邀請企業(yè)的業(yè)務(wù)骨干和行業(yè)專家為師生開設(shè)專題講座,傳授最新業(yè)務(wù)知識,開展技能培訓(xùn)等。
4引導(dǎo)學(xué)生正確認識軟件測試技術(shù)和軟件測試職業(yè)
軟件測試人員不僅要掌握軟件測試技術(shù),還要具備軟件系統(tǒng)分析、軟件系統(tǒng)設(shè)計和軟件編程等方面的能力。由于軟件測試人員的工作是找出軟件中錯誤,并經(jīng)常同系統(tǒng)設(shè)計者和編程人員交流,因此嚴謹?shù)墓ぷ髁?xí)慣、良好的溝通能力和團隊合作精神也是軟件測試人員所必需的。而學(xué)生對軟件測試技術(shù)的重要性和就業(yè)前景的了解,是激發(fā)和促使他們主動學(xué)習(xí)的重要推動力。為此,在教學(xué)過程中要予以適時介紹,同時邀請經(jīng)驗豐富的工程師來校報告,使學(xué)生清楚地了解職業(yè)要求和廣闊的發(fā)展空間,正確認識軟件測試技術(shù)和軟件測試職業(yè)。
5結(jié)語
軟件測試技術(shù)是軟件工程專業(yè)的重要課程,通過對課程教學(xué)改革的實施,使學(xué)生對課本知識的理解更加深入,主動思考問題能力和實踐應(yīng)用能力也得到提高,為培養(yǎng)高技能應(yīng)用型人才打下良好的基礎(chǔ)。同時,教師們也普遍反映軟件測試技術(shù)的教學(xué)質(zhì)量和教學(xué)效果得到極大的提高。在這個過程中,我們摸索和積累了一些經(jīng)驗,以期對其他專業(yè)的教學(xué)也具有一定的參考價值。
摘要：該文深入分析了DSP匯編語言軟件的測試難點，給出DSP匯編語言軟件的測試策略，對DSP匯編語言軟件測試具有重要的應(yīng)用意義。
關(guān)鍵詞：DSP；匯編語言；測試
1 引言
目前，DSP硬件系統(tǒng)已具有了很高的可靠性，但其軟件系統(tǒng)，特別是用匯編語言設(shè)計編寫的較為復(fù)雜的軟件系統(tǒng)，可靠性總是難以得到保證，更是缺少完整的質(zhì)量保證和評估體系，這已經(jīng)成為DSP應(yīng)用方面亟待解決的一個問題。對DSP匯編語言軟件的測試與一般的軟件測試不同，其自身的特點決定了測試面臨的困難。本文首先對其測試難點進行分析，然后給出了DSP匯編語言軟件的測試方法。
2 DSP匯編語言軟件環(huán)境的復(fù)雜性分析
2.1 與硬件結(jié)合緊密，測試環(huán)境難以搭建和選擇
匯編語言的程序是燒制到DSP芯片中運行的，DSP芯片種類繁多。這些芯片的外部管腳、內(nèi)部存儲器分配都各不相同 。在搭建宿主機測試環(huán)境時必須選擇各種不同的相對應(yīng)的芯片，然后配合仿真器與宿主機連接。這些硬件的配置本身就增加了測試難度，然而這些仿真環(huán)境總是和目標環(huán)境之間有著不小的差異,比如目標環(huán)境的中斷難于模擬等。基于目標的測試消耗較多的經(jīng)費和時間，而基于宿主的測試代價較小，但畢竟是在模擬環(huán)境中進行的。目前的趨勢是把更多的測試轉(zhuǎn)移到宿主環(huán)境中進行，但是，目標環(huán)境的復(fù)雜性和獨特性不可能完全模擬。
2.2 I/O通道少，測試數(shù)據(jù)獲取比較困難
在DSP匯編語言軟件的測試中給主機上載測試數(shù)據(jù)是很困難的。目前主要是基于以下3 種方式：1）實際的物理通道；2）開發(fā)工具IDE的虛擬IO功能；3）直接讀取內(nèi)存區(qū)數(shù)據(jù)。第一種方式就是目標機和主機之間具備物理的通信方式，比如以太網(wǎng)、串口、并口、USB等。這種方式要求系統(tǒng)必須具備這種通信方式和通信軟件，一般只適用于系統(tǒng)級的測試。第二種方式是借助開發(fā)工具，比如TI CCS，這種方式調(diào)試較為復(fù)雜也容易出錯。第三種方式則是需要占用較多的內(nèi)存資源。
2.3 實時性要求較強
DSP軟件一般都用作控制系統(tǒng)的內(nèi)核，所以有很高的實時性要求，而實時性的測試是一般的測試方法和測試工具都難以實現(xiàn)的。
2.4缺少相應(yīng)測試工具
匯編語言結(jié)構(gòu)和語法都比較繁瑣和冗長，這首先使測試人員理解程序變得困難，又因為DSP芯片的多樣性，使得開發(fā)針對DSP匯編語言軟件的通用測試工具幾乎是不可能的。因此，在測試時，只能夠使用一些外圍測試工具（比如覆蓋率分析工具等），而把測試的重點放在人工的代碼審查上面，這就要求測試人員要很熟悉相應(yīng)芯片的用法并且還要與開發(fā)人員充分的溝通。
3 DSP匯編語言軟件的測試策略
DSP匯編語言軟件是最難測試的軟件之一，必須制定有效的測試策略。在搭建測試環(huán)境時，要尋求宿主機與目標機之間的平衡，即要對目標環(huán)境和宿主環(huán)境的測試內(nèi)容有所選擇，在宿主環(huán)境中，可以進行邏輯或界面的測試、以及與硬件無關(guān)的測試。在模擬或宿主環(huán)境中的測試消耗時間通常相對較少，用調(diào)試工具可以更快地完成調(diào)試和測試任務(wù)。而中斷測試、硬件接口測試、系統(tǒng)集成測試等必須要在目標環(huán)境中進行。而在測試環(huán)境搭建完成之后，考慮到重要性以及測試執(zhí)行先后順序，把整個測試依次分為以下幾個不同階段。
1）代碼審查階段。對于DSP匯編語言軟件，代碼審查是整個測試的重點，要占到整個測試周期的60%。同時，代碼審查又是功能測試編寫測試用例之前的必要步驟。代碼審查最好是在開發(fā)環(huán)境中通過硬件仿真進行。
2）功能測試階段。在功能測試階段，采用功能分解法、等價類劃分和猜錯法等方法，根據(jù)軟件需求規(guī)格說明中所規(guī)定的軟件正式合格項設(shè)計并執(zhí)行測試用例，以驗證其功能是否滿足需求規(guī)格說明的要求，并對其功能的適合性和準確性進行驗證。對于DSP匯編語言軟件系統(tǒng)，功能測試必須首先進行模塊化處理，分離出每個模塊的輸入輸出。
在設(shè)計功能測試用例時，也包括對邊界值的測試，即對輸入域(或輸出域)的臨界狀態(tài)、數(shù)據(jù)結(jié)構(gòu)、狀態(tài)轉(zhuǎn)換、功能界限等的邊界或端點情況下的運行狀態(tài)的測試。此外，設(shè)計功能測試用例時運用覆蓋測試工具輔助測試用例的設(shè)計，以達到功能測試的充分性。
3）性能測試階段。在DSP軟件系統(tǒng)中，程序的性能是非常重要的，要嚴格根據(jù)需求中對負載、定時、性能的要求，判斷軟件是否滿足這些需求規(guī)范。在使用環(huán)境中，軟件的失效過程要平穩(wěn)（電機運動慣性問題），所以，不僅要檢查軟件工作過程，也要檢查軟件失效過程。
可以使用測試工具CODETEST主要對DSP下行的伺服驅(qū)動器控制軟件中有時間要求和數(shù)據(jù)處理精度要求的軟件合格性項進行測試，并把重點放在測試其實際時間特性與實際數(shù)據(jù)處理精度上。時間特性主要包括以下幾個：中斷延遲時間、任務(wù)上下文切換時間、任務(wù)響應(yīng)時間、任務(wù)創(chuàng)建/刪除時間、交替信號量時間、取得/釋放信號量時間、交替消息隊列傳輸時間。
4）接口測試階段。為了保證正確地測試，還須要檢驗軟硬件之間的接口。對接口的測試主要利用各種不同類型接口的監(jiān)視工具。比如對TMS320LF2407板匯編軟件串口測試，可以使用串口監(jiān)控器EtherPeek.NX，人工設(shè)置各軟件從RS232串口接收的輸入/輸出，驗證各軟件對輸入/輸出的反應(yīng)，并監(jiān)控其輸入/輸出內(nèi)容的格式與數(shù)據(jù)位是否與接口規(guī)范一致，驗證各接口的正確性和一致性。
5）結(jié)構(gòu)覆蓋測試階段。使用測試工具LDRA TestBed對被測軟件程序進行插裝。插裝可以是在測試環(huán)境中嵌入硬件，也可以是在可執(zhí)行代碼中加入軟件，也可以是二者相結(jié)合。基于測試用例，執(zhí)行插裝后的程序，提取語句/跳轉(zhuǎn)覆蓋信息，將程序的執(zhí)行表現(xiàn)與編碼意圖進行比較，衡量軟件測試工作的充分性。代碼覆蓋分析工具可能侵入代碼的執(zhí)行，影響實時代碼的運行過程。基于硬件的代碼覆蓋分析工具的侵入程度要小一些，但是價格一般比較昂貴，而且限制被測代碼的數(shù)量。
6）強度測試階段。在模擬環(huán)境下，打開被測軟件全部數(shù)據(jù)采集與數(shù)據(jù)通信通道，運行全部模擬外設(shè)，長時間運行功能測試和接口測試等相關(guān)測試用例，檢測交流伺服驅(qū)動器控制軟件在設(shè)計能力下的運行情況。
7 ）安全性測試階段。采用人工測試的方法對被測軟件進行安全性測試。檢測用戶是否能對被測軟件進行災(zāi)難性操作，被測軟件是否具有關(guān)鍵操作的安全性保護等功能。對于電機控制系統(tǒng)的DSP軟件，主要檢查過壓、過流、低壓、低流、斷電、異常復(fù)位等災(zāi)難性操作。
8）可恢復(fù)性測試階段。采用人工測試的方法對被測軟件進行可恢復(fù)性測試。用人工干預(yù)的手段模擬硬件故障、鏈路故障、電源故障等，故意造成系統(tǒng)出現(xiàn)異常，并由此檢查被測軟件是否具有錯誤探測功能，在故障發(fā)生時能否保護正在運行的作業(yè)和系統(tǒng)狀態(tài)。并檢測被測軟件在重啟之后能否正常地繼續(xù)進行工作，并不對系統(tǒng)造成損害。
9）回歸測試階段。對于在測試過程中發(fā)現(xiàn)的問題，開發(fā)方應(yīng)及時對其進行修正。修正后由測試方通過回歸測試進行確認。回歸測試必須將所有功能測試、接口測試等測試用例重新執(zhí)行一遍，以驗證所有問題已經(jīng)全部解決，并且沒有引入新的問題。
4 結(jié)論
此方法研究在一定程度上減輕了DSP匯編語言軟件的測試難點，對以后的測試實踐有重要的參考意義。此策略的充分性和自動化程度是今后工作和研究的方向。
摘要：在軟件測試過程中，因為多方面的因素，常常會導(dǎo)致一些錯誤和失效，為了改善測試過程、使測試過程變得更為有效，需要對軟件測試過程進行一個補充，那就是對軟件測試的有效性進行評價。本文介紹了評價軟件測試有效性工作的一般流程，并提出了一系列用于精確度量測試有效性的度量指標。
關(guān)鍵詞：軟件測試；測試的有效性
1 引言
如同任何產(chǎn)品離不開質(zhì)量檢驗一樣，軟件測試是在軟件投入運行前，對軟件需求分析、設(shè)計規(guī)格說明和編碼實現(xiàn)的最終審定，在軟件生存期中占據(jù)著非常突出的重要位置。在軟件測試過程中，測試人員非常關(guān)心之前的測試過程有沒有得到改善，因為如果沒有，那么在下一次又將犯一樣的錯誤，繼續(xù)執(zhí)行無效的測試。同時由于測試在整個項目研發(fā)過程中占用了相當一部分信息服務(wù)資源，因此，管理人員也常常在思考測試是否有效，是否值得投入那么多資金。因此，要改善測試過程、使測試過程變得更為有效，必須不斷地評價測試結(jié)果。
2 評價軟件測試有效性的工作流程
評價軟件測試有效性的主要目的是評價測試人員的工作和使用評價后的結(jié)果改進測試過程。在軟件測試中，往往會存在一些無效的方面，評價的目標就是識別這些無效和問題以便可以采取修復(fù)措施。
在測試的有效性評價工作中，存在兩個關(guān)鍵的因素：一是評估的目標，目標是對度量過程的恰當指導(dǎo)，無效的目標會使整個評價過程無效；二是實現(xiàn)度量目標所需的信息類別，信息的收集需要建立專門的小組，整個評價過程也應(yīng)指派專門的人員負責(zé)，因為如果沒有專人負責(zé)評價過程，那么就無法確保進行正確的數(shù)據(jù)收集和評估過程。
圖1給出了評價測試有效性的工作流程。本文主要圍繞這個工作流程來進行詳細的闡述。
3 有效性評價的輸入
當所有的軟件測試過程結(jié)束后，軟件測試有效性評價工作就可以開始了，測試階段的最終執(zhí)行結(jié)果是它的入口條件，表1列出了輸入所需的一部分信息類型，根據(jù)具體項目的不同，也會產(chǎn)生其它的輸入。
4 有效性評價的執(zhí)行過程
軟件測試的有效性評價的執(zhí)行過程包含七個方面的內(nèi)容：確定評估目標、確定度量內(nèi)容、制定度量責(zé)任、選擇評估方法、確定所需事實、收集評估數(shù)據(jù)和評估測試有效性。
4.1 確定評估目標
定義目標，是為了使度量過程得到指導(dǎo)。前面提到，評價的目標就是為了識別測試無效的方面，以便采取修復(fù)措施。因此應(yīng)該明確地確定評估執(zhí)行的目標。在測試有效性評價中需要識別的內(nèi)容包括以下六個方面：識別測試弱項、識別新測試工具的需要、評估項目測試、識別良好的測試實踐、識別不好的測試實踐和識別經(jīng)濟的測試實踐。
4.2 確定度量內(nèi)容
明確了評價目標之后，接下來的工作就是確定度量的內(nèi)容，即確定達到度量目標所需信息的類別。應(yīng)用系統(tǒng)的測試中，有五個方面是可度量的：涉及方、測試的程度、資源、有效性和評估。
4.3 制定度量責(zé)任
在測試評價過程中，應(yīng)該指定負責(zé)收集和評估測試性能信息的小組和專門的負責(zé)人員，這時為了確保數(shù)據(jù)收集和評估過程發(fā)生的推動力。
4.4 選擇評估方法
在執(zhí)行測試評估的過程中有一些方法可供選擇，在實際操作過程中，我們推薦采用度量指標方法，因為它一旦建立就很容易使用，并且可以證明它與有效和無效實踐有密切關(guān)系。
因素間的某種關(guān)聯(lián)或關(guān)系稱為度量指標。度量指標的一個主要優(yōu)勢在于可以清晰地定義評估過程，并且對被評估人員來說也是透明的，同時它具有良好的針對性，可以容易地確定哪些測試變量需要調(diào)整以提高有效性、效率和/或測試過程的經(jīng)濟性。測試度量指標方法是指識別那些和好的或不好的測試有密切關(guān)系的標準。
4.5 確定所需事實
確定所需事實是指識別支持所選方法的必要證據(jù)。度量指標方法明確地識別了評估過程所需的數(shù)據(jù)類型。要使用本文后面描述的度量指標，所需確定的信息包括：變更的特征、被測試過程的費用、測試的費用、測試所發(fā)現(xiàn)的缺陷、階段發(fā)現(xiàn)的缺陷、測試后發(fā)現(xiàn)的缺陷、按功能的測試費用、對系統(tǒng)的抱怨、缺陷的量化和恢復(fù)缺陷的量化。
4.6 收集評估數(shù)據(jù)
收集評估數(shù)據(jù)主要是指通過收集機制、存儲機制以及選擇和總結(jié)信息的方法，來建立用于存儲所需評估數(shù)據(jù)的系統(tǒng)。
4.7 評估測試有效性
執(zhí)行過程的最后一步是分析信息以得到關(guān)于系統(tǒng)測試有效性的結(jié)論。通過分析度量指標方法，相應(yīng)的人員可以有針對性地采取措施，并將總結(jié)后的結(jié)果記錄到測試評估表格中。度量指標方法通常會以量化的，表示測試過程好壞的形式給出評估。
下面（見表2）給出30個推薦使用的用于評價應(yīng)用系統(tǒng)測試的度量指標。
5 有效性評價的檢查過程
在檢查過程中，需要建立一個質(zhì)量控制檢查單（見表3），其中的“是”回答表示好的測試實踐；“否”回答表示需要額外的調(diào)查。注釋列用于解釋“否’回答并記錄調(diào)查結(jié)果。當檢查單的項不適用于測試情形時適用“N/A”列。
6 有效性評價的輸出
測試有效性評價的最后輸出是改進后的測試過程。在這個步驟中，主要是對測試結(jié)果進行仔細地分析，然后采取相應(yīng)措施來修復(fù)所確認的薄弱環(huán)節(jié)，使用度量/行動的方法來改善測試過程，最后使得應(yīng)用系統(tǒng)測試更加有效。（度量/行動的方法是指通過改變某種度量指標中的變量來度量另一種度量指標中變量的改變。如果能夠說明通過增加執(zhí)行的指令數(shù)目確實減少了操作的系統(tǒng)中的缺陷數(shù)目，那么可以認為該措施是預(yù)期的，并且應(yīng)該推廣。而如果執(zhí)行指令的增加并沒有減少產(chǎn)品投入運行之前的缺陷的數(shù)目，那么說明那些資源還沒有得到有效的使用，應(yīng)該停止該行動并且嘗試其他措施。）
7 結(jié)束語
本文提出了評測軟件測試有效性的一般工作流程，描述了度量測試的普遍目標，并為執(zhí)行這些度量給出了推薦的標準，是軟件測試的有效充，對實際軟件測試的評價工作具有一定的指導(dǎo)意義。在項目軟件測試過程結(jié)束后，IT組織應(yīng)該結(jié)合各自的特點，通過在軟件過程中積累的經(jīng)驗，運用本文提出的工作流程，逐步對軟件測試過程進行改進，使軟件測試更為有效的發(fā)揮它的積極作用。
摘要：構(gòu)件技術(shù)成為當前軟件工程中的發(fā)展方向，構(gòu)件的軟件測試成為軟件測試中的一個新的研究領(lǐng)域。本文對構(gòu)件技術(shù)做了簡單的介紹后，對構(gòu)件測試中遇到的困難和問題做了比較詳細的描述，并介紹了目前過內(nèi)外在構(gòu)件測試方面的一些成果現(xiàn)狀。
關(guān)鍵字：軟件測試；構(gòu)件技術(shù)；構(gòu)件測試
1 軟件構(gòu)件技術(shù)
自上個80年代以來，面向?qū)ο蠹夹g(shù)的發(fā)展與應(yīng)用，在提高軟件可重用性方面起了積極的推動作用，軟件重用已經(jīng)成軟件工程技術(shù)的一個重要目標，成為開發(fā)出高效、低成本、可重用軟件系統(tǒng)的重要的現(xiàn)實途徑。當今軟件開發(fā)技術(shù)的主流已是基于軟件構(gòu)件技術(shù)。只要遵循軟件構(gòu)件模型規(guī)范，各個軟件開發(fā)商就可以用自己方便的程序語言去實現(xiàn)可重用的軟件構(gòu)件，應(yīng)用程序開發(fā)人員就有可能實現(xiàn)在計算機硬件領(lǐng)域早已實現(xiàn)的夢想：挑選構(gòu)件，組合成新的應(yīng)用軟件系統(tǒng)。oscarNierstrasz提出[1]：Applieations=Components + seripts即應(yīng)用軟件就是構(gòu)件和構(gòu)件描述組成。
2 傳統(tǒng)的軟件測試
2.1 軟件測試的重要性、目的和原則
為了能夠保證交付的軟件使客戶滿意，需要在軟件開發(fā)、集成和形成系統(tǒng)之后進行充分、全面、有效的測試，軟件測試是保證軟件質(zhì)量的重要手段。
測試過程貫穿在軟件開發(fā)的整個生命周期過程，覆蓋范圍是很廣泛的，包括需求分析，設(shè)計文檔、程序代碼等。目前比較俠義的理解是軟件測試就是對程序代碼的測試。
Grenford.J.Myers[2] 就軟件的測試目的提出了如下的觀點：(1)軟件測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)缺陷；(2)一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的缺陷；(3)一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的多個缺陷的測試。因而，測試的目的是在資源消耗合理的情況下，發(fā)現(xiàn)盡可能多的缺陷和錯誤。
軟件測試中應(yīng)該遵循主要原則包括：(1)應(yīng)當把“盡早地和不斷地進行軟件測試”作為軟件開發(fā)者的座右銘；(2)測試用例應(yīng)由測試輸入數(shù)據(jù)和與之對應(yīng)的預(yù)期輸出結(jié)果這兩部分組成；(3)序員應(yīng)避免檢查自己的程序；(4)在設(shè)計測試用例時，應(yīng)當包括合理的輸入條件和不合理的輸入條件；(5)充分重視測試中的群集現(xiàn)象；(6)嚴格執(zhí)行測試計劃，排除測試的隨意性；(7)應(yīng)當對每一個測試結(jié)果做全面的檢查；(8)妥善的保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便[3]。
2.2 傳統(tǒng)的軟件測試主要方法和技術(shù)
通常依照如下方法對軟件測試進行分類：
(1) 軟件開發(fā)過程中的測試：包括單元測試；集成測試；系統(tǒng)測試； 驗收測試。
(2) 軟件產(chǎn)品測試。測試對象是已經(jīng)或即將產(chǎn)品化的軟件。包括：功能測試；性能測試；β測試；Benchmark測試。
(3) 專門的軟件測試：包括可靠性測試；標準符合性測試；互操作性測試；安全性測試；強度測試。
3 構(gòu)件測試方法概述
3.1 構(gòu)件測試技術(shù)發(fā)展現(xiàn)狀
構(gòu)件測試技術(shù)發(fā)展歷史并不長，構(gòu)件繼承了傳統(tǒng)軟件的特點，與傳統(tǒng)軟件相比又具有一定的特殊性，所以構(gòu)件軟件的測試技術(shù)也相應(yīng)的繼承了傳統(tǒng)軟件測試技術(shù)中適用的部分，同時又具有傳統(tǒng)軟件測試所不具備的特性。
正是這些特殊性決定了構(gòu)件軟件的測試方式、方法在某些方面具有自己的特點。為此，在傳統(tǒng)軟件測試技術(shù)的基礎(chǔ)上，對構(gòu)件軟件測試技術(shù)進行挖掘和開拓成為構(gòu)件軟件測試領(lǐng)域的一項主要研究內(nèi)容，并有了一定的發(fā)展。
構(gòu)件軟件作為軟件的一種，是軟件技術(shù)發(fā)展的新階段，面臨著更加復(fù)雜的開發(fā)模式，為此需要對構(gòu)件軟件進行一系列的測試，從而保證構(gòu)件軟件的質(zhì)量要求。
3.2 構(gòu)件測試面臨的主要問題
基于構(gòu)件的軟件開發(fā)所面對的測試單元是構(gòu)件產(chǎn)品，作為構(gòu)件開發(fā)方來說可以針對構(gòu)件的源碼進行測試，而對于構(gòu)件的使用方來說往往構(gòu)件的源碼是不可知的也很難與構(gòu)件的開發(fā)者進行交流。這一差異導(dǎo)致構(gòu)件的測試與傳統(tǒng)的軟件測試相比具有了新的問題，包括：
3.2.1 構(gòu)件生產(chǎn)者所面臨的測試問題
(1) 構(gòu)件的應(yīng)用環(huán)境復(fù)雜多變，作為構(gòu)件開發(fā)者難以考慮所有的構(gòu)件可能運行的環(huán)境，因而也就不能對構(gòu)件進行充分的測試；(2)構(gòu)件軟件測試集的組合爆炸問題導(dǎo)致測試工作量非常大，卻難以覆蓋所有的測試點[4]；(3)構(gòu)件的測試環(huán)境配置困難重重，構(gòu)件生產(chǎn)者不可能搭建構(gòu)件使用的確切環(huán)境；(4)構(gòu)件測試的可重復(fù)性；(5)構(gòu)件測試工具缺乏。
3.2.2 構(gòu)件使用者面臨的測試問題
(1)很難獲得軟件的源程序，因而不能對構(gòu)件的內(nèi)部細節(jié)有詳細的了解，從而對構(gòu)件的測試帶有一定的盲目性；(2)測試數(shù)據(jù)的產(chǎn)生：由于同樣的原因，難以產(chǎn)生合適的測試輸入，使得對底層元素難以達到較高的覆蓋率；(3)組合爆炸問題依然存在，導(dǎo)致測試困難；(4)集成測試中有可能對構(gòu)件單元測試中的測試點造成重復(fù)測試，從而造成測試冗余性；(5)構(gòu)件測試的可重用性：對構(gòu)件的測試應(yīng)該是可重用的；(6)構(gòu)件測試工具的缺乏。
3.3 構(gòu)件測試與傳統(tǒng)的軟件測試的主要區(qū)別
構(gòu)件與傳統(tǒng)軟件從系統(tǒng)設(shè)計開始就是不同的，傳統(tǒng)軟件開發(fā)從需求分析、軟件設(shè)計到編寫代碼一直到測試都是軟件公司獨立完成的，所以具有比較清晰的脈絡(luò)，也能得到軟件的內(nèi)部細節(jié)信息。
基于構(gòu)件的軟件開發(fā)采用的模式也是從需求分析開始的，但是組成軟件的基本單元不再是傳統(tǒng)的軟件模塊（比如類），而是來自于第三方的軟件構(gòu)件。從而面向構(gòu)件的軟件開發(fā)技術(shù)面對的主要問題是如何選擇以及組裝軟件構(gòu)件[5]，經(jīng)過充分的測試，最終形成軟件產(chǎn)品。
因此，傳統(tǒng)軟件測試的軟件設(shè)計詳細信息和軟件的源代碼都是可以得到的，脈絡(luò)十分清晰。軟件構(gòu)件的測試以及軟件構(gòu)件產(chǎn)品集成測試和系統(tǒng)測試需要尋找合適的構(gòu)件產(chǎn)品并組裝，而構(gòu)件設(shè)計以及內(nèi)部代碼對于構(gòu)件使用者來說是不可見的。
傳統(tǒng)軟件測試理論和方法技術(shù)都比較成熟，構(gòu)件測試的測試方法和測試技術(shù)部分可以采用傳統(tǒng)的軟件測試。但是構(gòu)件測試具有自己的特點，需要區(qū)別對待，根據(jù)構(gòu)件的新特性研究構(gòu)件的測試方法。
3.4 國內(nèi)外構(gòu)件測試的研究現(xiàn)狀
國外及國內(nèi)在構(gòu)件測試方面的研究已經(jīng)取得一定的成果，例如：Freedman提出了構(gòu)件的可測性理論[6]；Jerry[7]提出了構(gòu)件可跟蹤性以及構(gòu)件可理解性；浙江大學(xué)提出界面構(gòu)件關(guān)聯(lián)圖的測試方法，等等
從國內(nèi)外構(gòu)件測試技術(shù)研究的現(xiàn)狀來看，具體的軟件構(gòu)件測試方法主要有以下幾種：
(1) 基于元數(shù)據(jù)的構(gòu)件測試
這種測試方法由構(gòu)件開發(fā)者提供包含構(gòu)件信息的元數(shù)據(jù)，這些元數(shù)據(jù)覆蓋了構(gòu)件各個方面的信息。構(gòu)件測試者提取元數(shù)據(jù)中的信息并根據(jù)這些信息來制定合理的測試用例，然后對構(gòu)件進行測試。由于這些元數(shù)據(jù)具有明確的構(gòu)件使用上下文信息，所以通過元數(shù)據(jù)提供的數(shù)據(jù)對構(gòu)件進行測試具有明確的目標和清晰的測試切入點。不過元數(shù)據(jù)的制定比較困難。
(2) 軟件構(gòu)件流程圖
使用數(shù)據(jù)流和控制流的方法，利用從構(gòu)件中獲取的信息將構(gòu)件數(shù)據(jù)和信息的交互做成交互圖，然后根據(jù)此交互圖來制定測試用例。
(3) 錯誤注入的構(gòu)件測試
通過對程序進行錯誤注入來觀察構(gòu)件失效或產(chǎn)生錯誤的狀態(tài)下對整個系統(tǒng)的影響。通過對構(gòu)件功能的限制來發(fā)現(xiàn)系統(tǒng)入侵情況下構(gòu)件的運行狀態(tài)以及由此而產(chǎn)生的對整個軟件系統(tǒng)的危害。
(4) 測試序列技術(shù)
該方法對構(gòu)件間的交互進行測試，通過應(yīng)用需求分離出構(gòu)件交互的序列并不斷集成直到生成整個應(yīng)用系統(tǒng)，因而可以看作是一個漸進的測試過程。但是隨著系統(tǒng)中構(gòu)件數(shù)目和規(guī)模的增加，這種測試的難度也逐漸的增加。
4 總結(jié)
隨著構(gòu)件技術(shù)成為當前軟件工程中的熱點發(fā)展方向，構(gòu)件的軟件測試成為軟件測試中的一個新的研究領(lǐng)域。本文對構(gòu)件技術(shù)做了簡單的介紹后，對構(gòu)件測試中遇到的困難和問題做了比較詳細的描述，并介紹了目前過內(nèi)外在構(gòu)件測試方面的一些成果現(xiàn)狀。所做的工作屬于項目組系統(tǒng)實現(xiàn)的前期熟悉工作的組成部分。
摘要：以軟件工程中面向?qū)ο筌浖_發(fā)模式為參考，具體闡述了面向?qū)ο蠓治觥⒚嫦驅(qū)ο笤O(shè)計、面向?qū)ο缶幊痰臏y試注意點和測試過程，并依照傳統(tǒng)的單元測試、集成測試、系統(tǒng)測試三個測試步驟，借鑒傳統(tǒng)測試方法以及面向?qū)ο筌浖y試層次結(jié)構(gòu)，詳細探討了面向?qū)ο髥卧獪y試、面向?qū)ο蠹蓽y試和面向?qū)ο笙到y(tǒng)測試的測試策略，并對相關(guān)問題進行了探討。
關(guān)鍵詞：面向?qū)ο螅卉浖y試；面向?qū)ο鬁y試模型；測試過程
1 引言
從1982年在美國北卡羅來納大學(xué)召開首次軟件測試的正式技術(shù)會議至今，軟件測試理論迅速發(fā)展，并相應(yīng)出現(xiàn)了各種軟件測試方法，使軟件測試技術(shù)得到極大的提高，軟件測試成為軟件工程方法中保證軟件質(zhì)量的最重要手段。
傳統(tǒng)軟件測試技術(shù)是面向過程的測試，是從輸入/處理/輸出的角度檢驗一個函數(shù)或過程能否正確工作，而面向?qū)ο筌浖y試是針對相互協(xié)作而又彼此獨立的對象的測試。面向?qū)ο筌浖_發(fā)的測試目標與傳統(tǒng)的軟件開發(fā)方法相同，都是為了確保軟件能正確地和一致地解決待解決的問題，但由于過程性測試方法沒有考慮到面向?qū)ο筌浖y試所要涉及的類、繼承和多態(tài)性，因此這兩者是有很大的不同，因而有必要對其進行深入的研究。
2 面向?qū)ο鬁y試模型
面向?qū)ο蟮拈_發(fā)模型突破了傳統(tǒng)的瀑布模型，將開發(fā)分為面向?qū)ο蠓治觯∣OA），面向?qū)ο笤O(shè)計（OOD）和面向?qū)ο缶幊蹋∣OP）三個階段。分析階段產(chǎn)生整個問題空間的抽象描述，在此基礎(chǔ)上，進一步歸納出適用于面向?qū)ο缶幊陶Z言的類和類結(jié)構(gòu)，最后形成代碼。
針對這種開發(fā)模型，結(jié)合傳統(tǒng)的軟件測試步驟的劃分，文獻[1]提出一種整個軟件開發(fā)過程中不斷進行測試的面向?qū)ο筌浖y試模型，使開發(fā)階段的測試與編碼完成后的單元測試、集成測試、系統(tǒng)測試成為一個整體。該測試模型給出了面向?qū)ο鬁y試OOT 與OOA、OOD 和OOP 三者的對應(yīng)關(guān)系，如圖1 所示。
OOA Test 和OOD Test 是對分析結(jié)果和設(shè)計結(jié)果的測試，主要是對分析設(shè)計產(chǎn)生的文本進行測試，是軟件開發(fā)前期的關(guān)鍵性測試。OOP Test主要針對編程風(fēng)格和程序代碼實現(xiàn)進行測試，其主要測試內(nèi)容在面向?qū)ο髥卧獪y試和面向?qū)ο蠹蓽y試中體現(xiàn)。面向?qū)ο髥卧獪y試是進行面向?qū)ο蠹蓽y試的基礎(chǔ)。面向?qū)ο蠹蓽y試主要對系統(tǒng)內(nèi)部的相互服務(wù)進行測試，如成員函數(shù)間的相互作用，類間的消息傳遞等。面向?qū)ο蠹蓽y試不但要基于面向?qū)ο髥卧獪y試，更要參見OOD 或OOD Test 結(jié)果[2]。面向?qū)ο笙到y(tǒng)測試是基于面向?qū)ο蠹蓽y試的最后階段的測試，主要以用戶需求為測試標準，需要借鑒OOA 或OOA Test 結(jié)果。
2.1 面向?qū)ο蠓治龅臏y試（OOA Test）
傳統(tǒng)的面向過程分析是一個功能分解的過程，是把一個系統(tǒng)看成可以分解的功能的集合。這種傳統(tǒng)的功能分解分析法的著眼點在于一個系統(tǒng)需要什么樣的信息處理方法和過程，以過程的抽象來對待系統(tǒng)的需要。而面向?qū)ο蠓治?OOA)是把E-R 圖和語義網(wǎng)絡(luò)模型，即信息造型中的概念，與面向?qū)ο蟪绦蛟O(shè)計語言中的重要概念結(jié)合在一起而形成的分析方法，最后通常是得到問題空間的圖表的形式描述[3，4]。
OOA 階段將問題空間中的實例抽象為對象，用對象的結(jié)構(gòu)反映問題空間的復(fù)雜實例和復(fù)雜關(guān)系，用屬性和服務(wù)表示實例的特性和行為。OOA 的結(jié)果是為后面階段類的選定和實現(xiàn)，類層次結(jié)構(gòu)的組織和實現(xiàn)提供平臺。因此，OOA 對問題空間分析抽象的不完整，最終會影響軟件的功能實現(xiàn)，導(dǎo)致軟件開發(fā)后期大量不可避免的修補工作；而一些冗余的對象或結(jié)構(gòu)會影響類的選定、程序的整體結(jié)構(gòu)或增加程序員不必要的工作量。因此，對OOA 的測試重點應(yīng)該放在完整性和冗余性方面。 OOA階段的測試劃分為以下五個方面：1) 對認定的對象的測試；2) 對認定的結(jié)構(gòu)的測試；3) 對認定的主題的測試；4) 對定義的屬性和實例關(guān)聯(lián)的測試；5) 對定義的服務(wù)和消息關(guān)聯(lián)的測試。
2.2 面向?qū)ο笤O(shè)計的測試（OOD Test）
通常結(jié)構(gòu)化的設(shè)計方法是用面向作業(yè)的設(shè)計方法，它把系統(tǒng)分解以后，提出一組作業(yè)，這些作業(yè)是以過程實現(xiàn)系統(tǒng)的基礎(chǔ)構(gòu)造，把問題域的分析轉(zhuǎn)化為求解域的設(shè)計，分析的結(jié)果是設(shè)計階段的輸入。
而面向?qū)ο笤O(shè)計(OOD)采用“造型的觀點”，以O(shè)OA為基礎(chǔ)歸納出類，并建立類結(jié)構(gòu)或進一步構(gòu)造成類庫，實現(xiàn)分析結(jié)果對問題空間的抽象。OOD 確定類和類結(jié)構(gòu)不僅能滿足當前需求分析的要求，更重要的是通過重新組合或加以適當?shù)难a充，能方便實現(xiàn)功能的重用和擴充，以不斷適應(yīng)用戶的要求。因此，對OOD 的測試，建議針對功能的實現(xiàn)和重用以及對OOA 結(jié)果的拓展，從如下三方面考慮[5]：
1) 對認定的類的測試；
2) 對構(gòu)造的類層次結(jié)構(gòu)的測試；
3) 對類庫的支持的測試。
2.3面向?qū)ο缶幊痰臏y試（OOP Test）
由于面向?qū)ο蟪绦蚓哂欣^承、封裝和多態(tài)等新特征，使得傳統(tǒng)的結(jié)構(gòu)化程序測試策略不能完全適應(yīng)面向?qū)ο蟪绦虻臏y試需要。主要表現(xiàn)在三個方面，即面向?qū)ο蟮姆庋b不能實現(xiàn)傳統(tǒng)測試方法中對數(shù)據(jù)非法操作的測試；面向?qū)ο蟮睦^承，使錯誤的傳播概率提高，增加了測試的復(fù)雜度；面向?qū)ο蟮亩鄳B(tài)特征使程序內(nèi)“同一”函數(shù)的行為復(fù)雜化，增加測試的工作量。
面向?qū)ο蟪绦驅(qū)⒐δ軐崿F(xiàn)分布在類中，類間通過消息傳遞來協(xié)同實現(xiàn)系統(tǒng)的功能。面向?qū)ο蟮倪@種程序風(fēng)格將出現(xiàn)的錯誤精確地確定在一個具體的類中，因此，面向?qū)ο缶幊痰臏y試OOP Test忽略類功能的實現(xiàn)細則，將測試集中在類功能的實現(xiàn)和相應(yīng)的面向?qū)ο蟪绦蝻L(fēng)格，主要體現(xiàn)為兩方面（假設(shè)使用C++語言）：
1) 數(shù)據(jù)成員是否滿足數(shù)據(jù)封裝的要求；
2) 類是否實現(xiàn)了要求的功能。
3 面向?qū)ο蟮能浖y試內(nèi)容及層次
面向?qū)ο筌浖y試即在測試過程中繼續(xù)運用面向?qū)ο蠹夹g(shù)，進行以對象概念為中心的軟件測試。Binder 在研究了面向?qū)ο蟮奶卣鳎绶庋b性、繼承性、多態(tài)和動態(tài)綁定性等，認為這些特征的引入增加了測試的復(fù)雜性。對軟件測試層次一種較為普遍的劃分方法是根據(jù)測試層次結(jié)構(gòu)，面向?qū)ο筌浖y試總體上呈現(xiàn)從單元級、集成級、到系統(tǒng)級的分層測試，測試集成的過程是基于可靠部件組裝系統(tǒng)的過程。測試可用不同的方法執(zhí)行，通常的方法是按設(shè)計和實現(xiàn)的反向次序測試，首先驗證不同層，然后使用事件集成不同的程序單元，最終驗證系統(tǒng)級。根據(jù)測試層次結(jié)構(gòu)確定相應(yīng)的測試活動，并生成相應(yīng)的層次[6]。由于面向?qū)ο筌浖暮暧^上來看是各個類之間的相互作用，因此，將對類層的測試作為單元測試，而對于由類集成的模塊測試作為集成測試，系統(tǒng)測試與傳統(tǒng)測試層相同。測試流程如圖2所示。
3.1 面向?qū)ο蟮膯卧獪y試（OO Unit Test）
傳統(tǒng)的單元測試是針對程序的函數(shù)、過程或完成某一定功能的程序塊，面向?qū)ο髥卧獪y試OO Unit Test 在OOP Test 時進行，是對程序內(nèi)部具體單一的功能模塊的測試。一些傳統(tǒng)的測試方法在面向?qū)ο蟮膯卧獪y試中都可以使用，如等價類劃分法，因果圖法，邊值分析法，邏輯覆蓋法，路徑分析法，程序插裝法等等。
當考慮面向?qū)ο蟮能浖r，模塊單元的概念改變了，封裝規(guī)定了類和對象的定義。這意味在面向?qū)ο髥卧獪y試中，最小的可測試單元是封裝的類或?qū)ο螅皇悄K。
類包含一組不同的操作，并且某特殊操作可能作為一組不同類的一部分存在。同時，一個對象有它自己的狀態(tài)和依賴于狀態(tài)的行為，對象操作既與對象的狀態(tài)有關(guān)，也可能改變對象的狀態(tài)。所以，類操作時不僅要將操作作為類的一部分，同時要把對象與其狀態(tài)結(jié)合起來，進行對象狀態(tài)行為的測試。類測試可以分為以下三個部分：[7]
1) 基于服務(wù)的測試：測試類中的每一個服務(wù)（即方法）；
G是一個有向圖，叫做塊體。它是按照控制流圖的思想修改f的程序流程圖而來的，表示f的控制結(jié)構(gòu)中的符合條件判斷被分解，每個判斷框只有單個條件。
3.2 面向?qū)ο蟮募蓽y試
傳統(tǒng)的集成測試是由底向上通過集成完成的功能模塊進行測試，一般可以在部分程序編譯完成的情況下進行。而對于面向?qū)ο蟪绦颍嗷フ{(diào)用的功能是散布在程序不同的類中，類通過消息相互作用申請和提供服務(wù)，類相互依賴極其緊密，根本無法在編譯時對類進行測試，所以，面向?qū)ο蟮募蓽y試通常需要在整個程序編譯完成后進行。
在面向?qū)ο笙到y(tǒng)中，集成測試屬于應(yīng)用生命周期的一個階段，可在兩個層次上進行。第一層對一個新類進行測試，以及測試在定義中所涉及的那些類的集成。設(shè)計者通常用關(guān)系is a，is part和refers to來描述類與類之間的依賴，并隱含了類測試的順序。首先測試基礎(chǔ)類，然后使用這些類的類接著測試，再按層次繼續(xù)測試，每一層次都使用了以前已定義和測試過的類作為部件塊。
對于面向?qū)ο箢I(lǐng)域中集成測試的特別要求是：應(yīng)當不需要特別地編寫代碼就可把在當前的軟件開發(fā)中使用的元素集合起來，因此其測試重點是各模塊之間的協(xié)調(diào)性，尤其是那些從沒有在一起的類之間的協(xié)調(diào)性。
集成測試的第二層是將各部分集合在一起組成整個系統(tǒng)進行測試。以C++語言編寫的應(yīng)用系統(tǒng)為例，通常應(yīng)在其主程序中創(chuàng)建一些高層類和全局類的實例，通過這些實例的相互通訊從而實現(xiàn)系統(tǒng)的功能。對于這種測試所選擇的測試用例應(yīng)當瞄準待開發(fā)軟件的目標而設(shè)計，并且應(yīng)當給出預(yù)期的結(jié)果，以確定軟件的開發(fā)是否與目標相吻合。
3.3 面向?qū)ο蟮南到y(tǒng)測試
系統(tǒng)測試是對所有類和主程序構(gòu)成的整個系統(tǒng)進行整體測試，以驗證軟件系統(tǒng)的正確性和性能指標等是否滿足需求規(guī)格說明書和任務(wù)書所指定的要求。它與傳統(tǒng)的系統(tǒng)測試一樣，包括功能測試、性能測試、余量測試等，可套用傳統(tǒng)的系統(tǒng)測試方法。通過單元測試和集成測試，僅能保證軟件開發(fā)的功能得以實現(xiàn)，不能確認在實際運行時，它是否滿足用戶的需要，是否大量存在實際使用條件下會被誘發(fā)產(chǎn)生錯誤的隱患。為此，對完成開發(fā)的軟件必須經(jīng)過規(guī)范的系統(tǒng)測試，即開發(fā)完成的軟件僅僅是實際投入使用系統(tǒng)的一個組成部分，需要測試它與系統(tǒng)其他部分配套運行的表現(xiàn)，以保證在系統(tǒng)各部分協(xié)調(diào)工作的環(huán)境下也能正常工作[8]。
在系統(tǒng)測試中，不關(guān)心類的聯(lián)系細節(jié)。同于傳統(tǒng)的系統(tǒng)測試，面向?qū)ο筌浖南到y(tǒng)測試集中在用戶可見的活動與用戶可識別的來自系統(tǒng)的輸出。為了導(dǎo)出測試案例，測試者應(yīng)該使用分析模型中的使用案例，使用案例能夠用于導(dǎo)出測試案例以發(fā)現(xiàn)不能滿足用戶交互需求的錯誤。系統(tǒng)測試應(yīng)該盡量搭建與用戶實際使用環(huán)境相同的測試平臺，應(yīng)該保證被測系統(tǒng)的完整性，對臨時沒有的系統(tǒng)設(shè)備部件也應(yīng)有相應(yīng)的模擬手段。系統(tǒng)測試不僅是檢測軟件的整體行為表現(xiàn)，也是對軟件開發(fā)設(shè)計的再確認。
4 結(jié)束語
面向?qū)ο鬁y試的目標與傳統(tǒng)測試相同，但面向?qū)ο蠓椒ㄅc傳統(tǒng)順序結(jié)構(gòu)式方法在開發(fā)思想上有著根本的不同，尤其是面向?qū)ο笏哂械念悺⒎庋b、繼承、動態(tài)連接等特性，使得面向?qū)ο筌浖y試在測試模型、測試方法、測試層次等方面都有別于傳統(tǒng)的測試思想。從面向?qū)ο蟮臏y試模型可知，測試的視角擴大到包括復(fù)審分析和設(shè)計模型，此外，測試的焦點從過程構(gòu)件(模塊) 轉(zhuǎn)向了對象類。
目前，面向?qū)ο筌浖到y(tǒng)的開發(fā)在不斷的實踐中已逐步形成了自己的方法學(xué)，但對于面向?qū)ο筌浖y試，目前尚無普遍接受的充分性準則。本文根據(jù)傳統(tǒng)軟件測試模型將面向?qū)ο筌浖_發(fā)過程和軟件測試相結(jié)合，形成一種面向?qū)ο鬁y試模型，并對模型的相關(guān)步驟和具體實施提出了一些方法和技術(shù)，雖已在實踐中得到了一定的驗證，但也只是初步的，有必要在今后的研究中得到進一步的完善。
摘要：國內(nèi)軟件項目過程不規(guī)范，導(dǎo)致重視編碼和輕視測試的現(xiàn)象，對于軟件測試的重要性、測試方法和流程等還存在很多認識誤區(qū)，軟件測試所起的作用還沒有人們期望那樣顯著，因此，就需要繼續(xù)加大投入對軟件測試的關(guān)注程度，對軟件測試過程進行持續(xù)的改進。
關(guān)鍵詞：軟件測試；軟件工程；認識誤區(qū)；持續(xù)改進
1 引言
隨著市場對軟件質(zhì)量的不斷提高和國內(nèi)軟件測試行業(yè)的逐漸發(fā)展，軟件測試不斷受到重視，有越來越多的軟件企業(yè)更加重視軟件測試，并已經(jīng)形成了一套基本的軟件測試流程。然而，認識誤區(qū)的存在需要我們進一步改進軟件測試過程。
2 軟件測試概述
軟件測試就是在軟件投入運行前,對軟件需求分析、設(shè)計規(guī)格說明書和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。一般按四個步驟進行，即單元測試、集成測試、確認測試和系統(tǒng)測試及發(fā)版測試。隨著軟件危機的頻頻出現(xiàn)，人們已經(jīng)開始認識到測試開始的時間越早，測試執(zhí)行的越頻繁，所帶來的整個軟件開發(fā)成本的下降就會越多。所以，軟件測試在軟件項目實施過程中的重要性日益突出。
3 軟件測試過程中的認識誤區(qū)
3.1 軟件開發(fā)完成后進行軟件測試
人們一般認為，軟件項目要經(jīng)過以下幾個階段：需求分析，概要設(shè)計，詳細設(shè)計，軟件編碼，軟件測試，軟件。據(jù)此，認為軟件測試只是軟件編碼后的一個過程，這是不了解軟件測試周期的錯誤認識。軟件測試是一個系列過程活動，包括軟件測試需求分析，測試計劃設(shè)計，測試用例設(shè)計，執(zhí)行測試。因此，軟件測試貫穿于軟件項目的整個生命過程。在軟件項目的每一個階段都要進行不同目的和內(nèi)容的測試活動，以保證各個階段的正確性。軟件開發(fā)與軟件測試應(yīng)該是交互進行的，否則，測試的時間將會很短，測試的覆蓋面將很不全面，測試的效果也將大打折扣。
3.2 測試過程不夠完善
在軟件開發(fā)領(lǐng)域，確實存在一些東西看起來要比另外一些東西難測試一些，但是遠非無法測試。只不過這種不可測試性不是由于被測試的軟件內(nèi)部的過緊耦合造成的，而是和外部某些很難測試的部分耦合過緊，從而表現(xiàn)出被測試的軟件本身很難測試。這些很難測試的部分比較常見的有：圖形界面、硬件、數(shù)據(jù)庫等。
3.3 強調(diào)測試用例設(shè)計得越詳細越好
在確定測試用例設(shè)計目標時，一些項目管理人員強調(diào)測試用例“越詳細越好”。這種做法和觀點最大的危害就是耗費了很多的測試用例設(shè)計時間和資源，可能等到測試用例設(shè)計、評審?fù)瓿珊螅艚o實際執(zhí)行測試的時間所剩無幾了。因為當前軟件公司的項目團隊在規(guī)劃測試階段，分配給測試的時間和人力資源是有限的，而軟件項目的成功要堅持“質(zhì)量、時間、成本”的最佳平衡，沒有足夠多的測試執(zhí)行時間，就無法發(fā)現(xiàn)更多的軟件缺陷，測試質(zhì)量更無從談起了。
3.4 追求測試用例設(shè)計“一步到位”
現(xiàn)在軟件公司都意識到了測試用例設(shè)計的重要性了，但是一些人認為設(shè)計測試用例是一次性投入，測試用例設(shè)計一次就“萬事大吉”了，片面追求測試設(shè)計的“一步到位”。這種認識造成的危害性使設(shè)計出的測試用例缺乏實用性，或者誤導(dǎo)測試用例執(zhí)行人員，誤報很多不是軟件缺陷的“Bug”，這樣的測試用例在測試執(zhí)行過程中“形同虛設(shè)”，難免淪為“垃圾文檔”的地步。
4 軟件測試過程的持續(xù)改進
4.1 計劃與風(fēng)險
項目計劃對項目過程的實施有著直接的指導(dǎo)作用，它的重要性是不言而喻的。對于軟件測試來說，測試計劃也是指導(dǎo)后續(xù)測試工作的基礎(chǔ)，只有對過程中各任務(wù)進行更詳細的計劃，才有利于在測試過程中對項目進度的把握有一個明確的目標；同時，風(fēng)險策略的制定，也有利于對及早對測試過程中可能遇到的問題做出分析，以便在問題出現(xiàn)時能夠盡可能的減少規(guī)避風(fēng)險的成本。
4.2 評審
在測試過程中的每個階段結(jié)束前，都會輸出一些資源，文檔、用例等等，這些資源往往是下一個測試階段或軟件開發(fā)的下一個環(huán)節(jié)執(zhí)行的依據(jù)。評和審是結(jié)合在一起的，每個角色根據(jù)自己對項目的了解，從各自角度來審核測試報告的充分性，對質(zhì)量風(fēng)險發(fā)表各種見解。最終，對報告的規(guī)范性也要進行考察。另外，也最好根據(jù)實際情況組織會議評審來對一定規(guī)模的問題統(tǒng)一評審。
4.3 文檔
文檔的編寫對于測試人員來說是一個十分重要的任務(wù)，深入的、充分的投入測試的測試人員能寫出高質(zhì)量的測試文檔。所以，測試文檔的質(zhì)量，往往反映了測試人員執(zhí)行測試的廣度和深度。而在文檔的編寫方面，首先必須形成統(tǒng)一規(guī)范；另外，針對不同項目的測試，可以適當對文檔標題、內(nèi)容進行簡化。總之，文檔模板一旦形成，必須嚴格遵守。
4.4 方法與策略
測試方法和測試策略，測試的重中之重。測試的策略一般要求從全局方面對測試的階段、每個階段的測試類型進行考慮、定義。而測試的方法更多是體現(xiàn)在一個具體的測試中，采取怎樣的測試思路。另外，在測試過程中，對資源的協(xié)調(diào)也非常關(guān)鍵，需要能保證測試資源充分利用，每個測試人員都有適度并且相當?shù)墓ぷ髁俊?
4.5 總結(jié)測試經(jīng)驗
在測試的過程中，測試人員應(yīng)該及時總結(jié)發(fā)現(xiàn)的錯誤并歸類，標明經(jīng)常容易出錯的地方，將意見提交項目經(jīng)理，審核后，制定出一份統(tǒng)一標準并提供給開發(fā)人員，這樣就可以提前避免錯誤、避免重復(fù)錯誤和重復(fù)測試，提高測試效率。不僅如此，項目結(jié)束后的各項總結(jié)報告將是項目的后期維護或二次開發(fā)的寶貴參考資料。
4.6 缺陷分析、度量
對測試活動過程中發(fā)現(xiàn)的缺陷進行分析、度量，尋找軟件開發(fā)過程中存在的問題，并持續(xù)改進開發(fā)過程，提高質(zhì)量。缺陷的分析、度量從時間上分為兩個方面，首先是在軟件開發(fā)過程中發(fā)現(xiàn)的缺陷進行分析、度量；然后就是，對軟件產(chǎn)品后，對用戶提出缺陷進行統(tǒng)計、分析。
5 結(jié)論
測試是用來保證軟件開發(fā)過程的高效性，以及保證開發(fā)出來的軟件產(chǎn)品的高質(zhì)量和可用性的。軟件開發(fā)本身就是一件非常困難的事情，這也決定了有效的測試是非常重要的環(huán)節(jié)，我們要加強對軟件測試的關(guān)注，使大家對于測試首先有一個正確的認識，避免誤區(qū)的存在，并積極探索測試方法的持續(xù)改進問題，真正使軟件測試真正起到它應(yīng)有的作用。
摘要：主要介紹了面向?qū)ο筌浖念悳y試技術(shù)。從基于對象狀態(tài)方面分析UML狀態(tài)圖的組成、并發(fā)的優(yōu)點，描述繼承的對象動態(tài)行為、并發(fā)的動態(tài)行為，給出利用UML狀態(tài)圖構(gòu)造復(fù)合狀態(tài)測試樹算法并產(chǎn)生測試用例的面向?qū)ο筌浖y試方法。
關(guān)鍵詞：UML；測試用例；類測試；面向?qū)ο螅粻顟B(tài)圖
1 引言
面向?qū)ο筌浖y試的主要目標與傳統(tǒng)軟件測試目標相同，既是用最小的工作量發(fā)現(xiàn)最多的錯誤。由于面向?qū)ο笏氂械亩鄳B(tài)、繼承、封裝等新的特點，使面向?qū)ο鬁y試的策略和技術(shù)與傳統(tǒng)測試有所不同，測試的視角擴大到包括復(fù)審分析和設(shè)計模型，測試焦點從模塊轉(zhuǎn)向類。類是構(gòu)成面向?qū)ο蟪绦虻幕境煞郑惖臏y試無疑成為面向?qū)ο?測試的重要環(huán)節(jié)。基于對象狀態(tài)的測試是根據(jù)被測試的類的對象所處的狀態(tài)以及狀態(tài)之間的轉(zhuǎn)移來構(gòu)造測試用例，它側(cè)重于對象的動態(tài)行為，這種動態(tài)行為依賴于對象狀態(tài)。測試對象動態(tài)行為能檢測出對象成員函數(shù)之間通過對象狀態(tài)進行交互式產(chǎn)生的錯誤。
2 基于對象狀態(tài)的測試方法的發(fā)展
現(xiàn)在面向?qū)ο鬁y試中基于對象狀態(tài)的測試方法一般是采用扁平狀態(tài)機和狀態(tài)遷移圖。扁平狀態(tài)機能很好的提示出一些類中的錯誤，但是隨著類的狀態(tài)屬性的增加，對象狀態(tài)的數(shù)目會迅速膨脹，大大增加測試的復(fù)雜度。狀態(tài)轉(zhuǎn)移圖用于刻畫對象響應(yīng)各種事件時狀態(tài)發(fā)生轉(zhuǎn)移的情況，容易借助于自動機理論來選擇測試時所用的時間序列和預(yù)測對象的狀態(tài)變化結(jié)果序列，但是，它難于描述繼承的對象動態(tài)行為、并發(fā)的動態(tài)行為以及由數(shù)據(jù)成員和成員函數(shù)構(gòu)成的對象狀態(tài)和對象狀態(tài)轉(zhuǎn)移。基于UML的狀態(tài)圖可以很好的描述對象動態(tài)行為、并發(fā)的動態(tài)行為，可以把狀態(tài)的復(fù)雜度控制在和狀態(tài)屬性相關(guān)的線性級別，下面我們主要介紹利用UML狀態(tài)圖如何描述對象動態(tài)行為、并發(fā)的動態(tài)行為，以及如何產(chǎn)生測試用例。
3 UML狀態(tài)圖
UML狀態(tài)圖（State Diagram）是UML中對系統(tǒng)的動態(tài)行為進行建模的表示方法，它包括對反應(yīng)型對象的行為建模。它展現(xiàn)了對象生命周期內(nèi)可能處于的狀態(tài)以及在這些狀態(tài)間轉(zhuǎn)換的激發(fā)條件。UML狀態(tài)圖中引起狀態(tài)遷移的原因通常有兩種，一種是在狀態(tài)圖中相應(yīng)的遷移上未指明事件，這表示當位于遷移箭頭源頭的狀態(tài)中的內(nèi)部動作全部執(zhí)行完后，該狀態(tài)遷移被自動觸發(fā)；另一種是，當出現(xiàn)某一事件時會引起狀態(tài)的遷移，在狀態(tài)圖中把這種一起狀態(tài)遷移的事件標在改前一的箭頭上，如圖1。
圖1 狀態(tài)裝換
狀態(tài)遷移的形式化語法為：
event_signsture[guard_condition]/action_expression^send_clause
其中事件特征event_signsture是由事件名后括號括起來的參數(shù)表組成，它指出觸發(fā)遷移的事件以及與該事件相連接的附加數(shù)據(jù)。guard_condition警戒條件是一個布爾表達式，如果狀態(tài)遷移中既有事件又有警戒條件，則表示僅當這個事件發(fā)生并且警戒條件為真時，觸發(fā)狀態(tài)遷移。動作表達式action_expression是一個觸發(fā)狀態(tài)遷移時可執(zhí)行的過程表達式，表達式中可引用該狀態(tài)所擁有的對象中的屬性、操作或事件特征中的參數(shù)。發(fā)送子句send_clause是動作的一種特殊情況，用來說明在兩個狀態(tài)的遷移期間發(fā)送的消息。
UML狀態(tài)圖的優(yōu)點在于它支持嵌套和并發(fā)。UML狀態(tài)圖中包含基本狀態(tài)（basic state）和復(fù)合狀態(tài)（composite state），復(fù)合狀態(tài)分為或狀態(tài)（or-state）和與狀態(tài)（and-state）。或狀態(tài)的子狀態(tài)之間是相互排斥的或關(guān)系，表示在任一時刻這些子狀態(tài)中只有一個子狀態(tài)為真；與狀態(tài)的子狀態(tài)之間是并發(fā)的非相互排斥關(guān)系，與狀態(tài)表示一個狀態(tài)可以有多個并發(fā)的子狀態(tài)，并發(fā)子狀態(tài)之間用虛線分隔，用虛線分隔的每個區(qū)域表示一個并發(fā)的子狀態(tài)。把狀態(tài)屬性看成并發(fā)的子狀態(tài)，從而可以把狀態(tài)圖的復(fù)雜度控制在線性級別上。并發(fā)狀態(tài)圖中一個事件可能引起多個子狀態(tài)的狀態(tài)遷移。如圖2中的CVM就是一個或狀態(tài)，它的子狀態(tài)OFF和ON之間是相互排斥的關(guān)系，ON狀態(tài)就是一個與狀態(tài)，當處于ON狀態(tài)時，就意味著同時處于COFFEE和MONEY兩個子狀態(tài)。
由于UML狀態(tài)圖支持嵌套和并發(fā)，這就使得它比以往的狀態(tài)轉(zhuǎn)移圖能更好的描述繼承的對象動態(tài)行為、并發(fā)的動態(tài)行為以及由數(shù)據(jù)成員和成員函數(shù)構(gòu)成的對象狀態(tài)和對象狀態(tài)轉(zhuǎn)移。UML狀態(tài)圖中可以包含復(fù)合狀態(tài)這就使得它可以把狀態(tài)的復(fù)雜度控制在和狀態(tài)屬性相關(guān)的線性級別。下面我們討論如何從UML狀態(tài)圖構(gòu)造一棵復(fù)合狀態(tài)測試樹。
4 構(gòu)造復(fù)合狀態(tài)測試樹
與以往的測試樹不同的是復(fù)合狀態(tài)測試樹的每個節(jié)點代表對象的復(fù)合狀態(tài)既對象的各個屬性的集合，邊表示狀態(tài)間的遷移，根節(jié)點代表對象的初始屬性集合。
構(gòu)造一個隊列queue來存放復(fù)合狀態(tài)測試樹的各個節(jié)點。
1)把UML狀態(tài)圖的起點讀入隊列queue。
2) 以UML狀態(tài)圖的起點定義根節(jié)點TestTree root，同時把節(jié)點標識treeNode置為對象的初始狀態(tài)，nodelevel置為0，t和childTree置為NULL，把root放入隊列中。
3) 取隊列頭部的節(jié)點設(shè)為head，搜索從head節(jié)點所對應(yīng)的狀態(tài)（head.treeNode）發(fā)出的狀態(tài)前移以及前移置的目標狀態(tài)，分別填充head.t和head.childTree，即把遷移至的狀態(tài)作為head的子節(jié)點；同時置好各個子節(jié)點的屬性值，nodeLevel=head.nodeLevel+1，從root節(jié)點開始層次遍歷測試樹（從第0層至head.nodeLevel層），如果在head的子節(jié)點中存在某個節(jié)點n，其所對應(yīng)的狀態(tài)已經(jīng)在第0層至head.nodeLevel層中出現(xiàn)過，則該節(jié)點n不再擴展，即為葉子節(jié)點。把其他沒有出現(xiàn)過的子節(jié)點加入到隊列的尾部。
4) head指向隊列中的下一個節(jié)點，重復(fù)第二步，直至隊列為空。
在3)中，如果 某個遷移對應(yīng)的目標狀態(tài)已經(jīng)在測試樹中出現(xiàn)過，就不再考慮這個狀態(tài)，不加入到隊列尾部。這樣有效地避免了重復(fù)構(gòu)造節(jié)點，同時又不降低測試的覆蓋率。通過上述步驟就可以構(gòu)造出UML狀態(tài)圖對應(yīng)的測試樹。
復(fù)合狀態(tài)樹構(gòu)造算法能很好的支持多個并發(fā)的子狀態(tài)的情況，只是節(jié)點表示為并發(fā)子狀態(tài)的合集；如果某個事件觸發(fā)其他事件從而引起一系列的狀態(tài)遷移時，只要把最終的狀態(tài)作為節(jié)點加入到測試樹中。比以往的插入樁模塊更容易實現(xiàn)。
通過測試樹可以很容易的構(gòu)造出測試用例。從根節(jié)點開始沿著各個分支往下知道葉子節(jié)點，每條這樣從根節(jié)點開始到某個葉子節(jié)點結(jié)束的路徑上的事件按順序組合在一起，就成為基于對象狀態(tài)測試的一個測試用例。如果增加對象屬性可以很容易的在復(fù)合狀態(tài)測試樹中增加，增加屬性后可以把狀態(tài)的復(fù)雜度控制在和狀態(tài)屬性相關(guān)的線性級別，測試時不僅可以單獨的對對象的每一個屬性和所有屬行進行測試，也可以對對象的所有屬性任意選擇組合進行測試。大大增加了測試的靈活性。
5 結(jié)束語
UML的狀態(tài)圖支持潛逃和并發(fā)，把狀態(tài)的復(fù)雜度控制在和狀態(tài)屬性相關(guān)的線性級別；其次UML狀態(tài)參數(shù)圖是在面向?qū)ο筌浖_發(fā)的生命周期中的早期設(shè)計階段確定的，是對對象狀態(tài)的完整的描述，并不依賴于源代碼，既保證了狀態(tài)描述的完整性，又可以在開發(fā)早期進行測試，盡早發(fā)現(xiàn)與狀態(tài)相關(guān)的錯誤，避免將錯誤帶入到后面的開發(fā)階段。因此可以用UML的狀態(tài)圖來產(chǎn)生有效的測試用例，這大大提高了測試的靈活性和有效性。
摘要:該文對軟件質(zhì)量保證的重要手段――軟件測試進行了論述,給出一些軟件測試的基本理論。隨著軟件測試研究的發(fā)展,軟件測試提出了一些比較前沿的理論,如面向?qū)ο蟮能浖y試,測試驅(qū)動開發(fā)理論,探索性測試等。為了克服手工測試的一些困難,提高軟件質(zhì)量和測試效率,自動化測試被廣泛地引入進來。它以其自動化程度高、實用性強等特點,引起了人們的廣泛重視,成為軟件測試的發(fā)展方向。自動化測試框架產(chǎn)品的出現(xiàn)表明軟件測試自動化技術(shù)正在趨于成熟。早期使用錄制回放和腳本工具的不足正在被克服,使得自動化測試更加經(jīng)濟、有效,更加有利于實現(xiàn)和維護。隨著在開發(fā)和維護腳本上的時間越來越少,更多的時間可用于提高測試的覆蓋范圍和產(chǎn)品質(zhì)量,從而在自動化上的投資能夠更快地得到證明。該文分析討論了自動化測試框架方法以及實現(xiàn),并將其應(yīng)用到軟件測試中。
關(guān)鍵詞:軟件測試;自動化測試;數(shù)據(jù)驅(qū)動;關(guān)鍵字驅(qū)動
1 自動化測試框架
自動化測試在過去的20年中已經(jīng)有了很大的發(fā)展。最初的測試工具只提供了簡單的捕捉/回放功能:記錄并播放鍵盤按鍵,然后捕捉和比較屏幕。這些測試方法雖然最容易應(yīng)用,但是幾乎不可能維護。捕捉/回放工具最終被功能和靈活性更強的測試腳本工具代替。后來,一種新的自動化測試產(chǎn)品出現(xiàn)了。它可以減少實現(xiàn)和維護的成本,使測試人員可以把精力集中在應(yīng)用程序的測試用例設(shè)計上,而不是開發(fā)我們的測試。這些工具提供預(yù)先寫好的測試框架,可以極大的減少,甚至消除學(xué)習(xí)和使用腳本語言的需要。這個測試產(chǎn)品就是自動化測試框架。
自動化測試框架定義了由假設(shè)、概念和制定工作平臺或為自動化測試提供支持的實踐組成的集合[1]。它能有效地彌補單一依靠測試工具所帶來地一些缺陷。自動化測試小組可以考慮吸收幾種測試框架的優(yōu)點,設(shè)計適合自己團隊的混合型測試框架。不是依賴某一種捕獲――回放的自動化測試工具。
基于GUI的捕獲回放工具都有維護性差的缺陷。因為GUI經(jīng)常根據(jù)功能變更或者其他需求而改變,當GUI有重大變化時,會導(dǎo)致自動化測試中斷,結(jié)果需要手工的干預(yù)或全部重新返工。因此更好的方案是引入自動化框架。
自動化測試框架為支持自動化軟件測試設(shè)計了平臺架構(gòu)和最佳的實踐經(jīng)驗。主要有4種基本框架結(jié)構(gòu)類型[2]:腳本模塊化架構(gòu),測試庫架構(gòu),關(guān)鍵詞或表格驅(qū)動架構(gòu),數(shù)據(jù)驅(qū)動架構(gòu)。
1) 腳本模塊化框架創(chuàng)建代表AUT基本模塊和功能的底層腳本。然后以一種層次關(guān)系組合這些小腳本,實現(xiàn)一個特定的測試用例。
2) 測試庫框架和測試腳本模塊化框架非常相似,但是底層由過程和函數(shù)組成,而不是腳本。這種框架要求創(chuàng)建庫文件(如SQABasic libraries, APIs, DLLs等等)代表AUT的模塊和功能。這些庫文件被測試用例腳本直接調(diào)用。每步的指令操作都在表格中維護。
3) 關(guān)鍵詞驅(qū)動或表格驅(qū)動測試框架是一種獨立于應(yīng)用程序的自動化框架,這種框架要求開發(fā)數(shù)據(jù)表和關(guān)鍵字,不依賴于運行的自動化工具和腳本。關(guān)鍵詞驅(qū)動測試看上去與手工測試用例非常相似。在關(guān)鍵詞測試里,應(yīng)用程序的功能特性和每步的指令操作都在表格中維護。
4) 數(shù)據(jù)驅(qū)動測試框架是從數(shù)據(jù)文件中讀取輸入和輸出數(shù)值并載入到捕獲的或手工編碼的腳本變量里的框架。這種框架和表格驅(qū)動測試有些相似,腳本只是一種“驅(qū)動器”(driver )或傳送數(shù)據(jù)的機制,不同的是導(dǎo)航的數(shù)據(jù)不包含在數(shù)據(jù)文件中,而只包含有測試數(shù)據(jù)。
測試框架是用來執(zhí)行測試的總體環(huán)境,其中的優(yōu)秀是一種自動化工具。本文主要介紹一種數(shù)據(jù)驅(qū)動的自動化測試框架WAF,對自動化測試的實施做出嘗試,并對該框架模型做出一些改進。
自動化測試框架WAF是作為一個模塊來設(shè)計和實現(xiàn)的,屬于即插即用的構(gòu)架,是一種數(shù)據(jù)驅(qū)動的軟件自動化測試框架。當測試系統(tǒng),測試數(shù)據(jù)和測試次序改變時不需要修改代碼[3]。數(shù)據(jù)驅(qū)動引擎被設(shè)計并實現(xiàn)來支持現(xiàn)有模塊的復(fù)用。只需要改變配置文件,測試用例表以及數(shù)據(jù)文件就可以實現(xiàn)當測試系統(tǒng),數(shù)據(jù)和測試的次序改變時,不再需要改變其他的程序和函數(shù)等;通過實現(xiàn)新增模塊的功能就可以引入新的測試或者新的驗證行為。新的模塊一旦創(chuàng)建就可以被應(yīng)用,只需要對數(shù)據(jù)驅(qū)動引擎的頭文件做些許的修改即可使用這些功能。
如同圖1描述的那樣,框架本身由WAF主程序,配置文件,WAF GUI映射,數(shù)據(jù)驅(qū)動引擎,測試用例或者測試組合(XML file),以及功能函數(shù)所定義。
2 WAF結(jié)構(gòu)組成
2.1 主程序
當運行一個用WAF來開發(fā)的測試件(testware)時,主程序首先被調(diào)用執(zhí)行。它根據(jù)對配置文件的解析結(jié)果來確定運行什么測試組合或測試用例,同時觸發(fā)數(shù)據(jù)驅(qū)動引擎來解析測試用例文件,并根據(jù)解析結(jié)果來調(diào)用相應(yīng)的數(shù)據(jù)文件同時觸發(fā)相應(yīng)的功能函數(shù)來執(zhí)行測試。
2.2 數(shù)據(jù)驅(qū)動腳本
數(shù)據(jù)驅(qū)動腳本就是那些和應(yīng)用程序相關(guān)聯(lián)的腳本。這些腳本通過錄制或手工編寫成自動化工具私有的語言,然后對其中的變量賦予合適的數(shù)值,作為測試數(shù)據(jù)的輸入[4]。這些變量作為一些關(guān)鍵應(yīng)用程序輸入的媒介,使腳本能通過外部的數(shù)據(jù)來驅(qū)動應(yīng)用程序。
1) 可變數(shù)據(jù),硬編碼組件標志
這些數(shù)據(jù)驅(qū)動的腳本經(jīng)常包含硬編碼的數(shù)據(jù),有時是一些窗口組件中非常脆弱的識別字符串。出現(xiàn)這種情況時,腳本很容易由于程序的更改而失去作用,而且這種情況并不是個別現(xiàn)象。
2) 高度技術(shù)化的、重復(fù)的測試設(shè)計
數(shù)據(jù)驅(qū)動腳本的另一個共同特點就是,所有在測試設(shè)計上所作的努力最終都體現(xiàn)在自動化工具的腳本語言中,或者復(fù)制到手工和自動化測試腳本中。
2.3 模塊
WAF中的模塊包括框架以及公共模塊,專業(yè)模塊,產(chǎn)品特定的模塊。框架和公共模塊包含一些框架和公共函數(shù),例如數(shù)據(jù)驅(qū)動引擎。而產(chǎn)品特定的模塊包括測試待測產(chǎn)品或應(yīng)用所需要調(diào)用的功能函數(shù)。專業(yè)模塊則包括處理特定的功能或者協(xié)議所需要的支持函數(shù)這些功能模塊都放在函數(shù)庫lib中[5]。
2.4WAF GUI映射
自動化測試工具錄制應(yīng)用程序中的每一個對象,并給每個對象命名來識別各對象,這個邏輯名能被修改,將其用在測試表中,測試工具使用他們來識別對象, GUI映射可由自動化測試工具自動產(chǎn)生。
2.5 測試數(shù)據(jù)
數(shù)據(jù)驅(qū)動測試是一種數(shù)據(jù)被包含在輸入測試數(shù)據(jù)文件中,并且數(shù)據(jù)控制自動化測試腳本執(zhí)行的流程和動作的測試。測試數(shù)據(jù)記錄以文檔的形式包含在輸入文件中,輸入文件包含測試數(shù)據(jù)和控制數(shù)據(jù)。測試數(shù)據(jù)進行必要的各種類型的測試,而控制數(shù)據(jù)引導(dǎo)測試腳本到達合適的位置并指示要執(zhí)行的動作。測試數(shù)據(jù)是特定測試產(chǎn)品和測試組合的測試數(shù)據(jù)[6]。對于不同產(chǎn)品測試數(shù)據(jù)是不一樣的。譬如對于文件傳送功能的測試數(shù)據(jù)則表現(xiàn)為各種類型的文件。
2.6 測試用例
測試數(shù)據(jù)定義測試狀態(tài)的初始化,測試步驟,應(yīng)用在每一步中的測試數(shù)據(jù)以及其預(yù)期結(jié)果,是一個基本的測試單元[7]。測試組合是一個測試用例的集合,被指定來完成一個特定的測試目標。它可以被設(shè)計來測試一個函數(shù),一個模塊,或者是執(zhí)行一個類型的測試,例如驗收測試(Release Acceptance Test )。
在WAF框架模型中,測試數(shù)據(jù)是以標簽的形式存放在XML文件中,每個標簽對應(yīng)一個測試數(shù)據(jù),這樣在一個獨立的XML文件中可以對應(yīng)多個測試用例,可以將XML文件看成是多個測試用例的集合。
2.7 測試件配置文件
TESTWARE配置文件記錄執(zhí)行測試件(testware)的一些基本配置項。包括文件目錄,數(shù)據(jù)目錄,測試組合目錄,log目錄以及一些服務(wù)的配置等。
2.8 測試結(jié)果
WAF在執(zhí)行完一個測試后產(chǎn)生三種類型的測試結(jié)果,日志文件,報告和相應(yīng)的測試過程數(shù)據(jù)。
2.9 利用WAF進行自動化測試開發(fā)流程
運行一個使用WAF開發(fā)的TESTWARE時,主程序被執(zhí)行。它初始化測試環(huán)境,解析配置文件,啟動數(shù)據(jù)驅(qū)動引擎(Data-driven engine)。
進行測試時數(shù)據(jù)驅(qū)動引擎調(diào)用XML文件,解析文件中的標簽,通過資源定位符定位到XML文件中的設(shè)計好的測試用例(或者測試組合),根據(jù)解析的結(jié)果調(diào)用函數(shù)庫中相應(yīng)的功能函數(shù)(lib),并通過測試數(shù)據(jù)來對相應(yīng)的應(yīng)用程序執(zhí)行測試。最后將測試結(jié)果返回給主程序輸出。
3WAF在軟件測試應(yīng)用中的實現(xiàn)
當決定把數(shù)據(jù)驅(qū)動的自動化測試框架應(yīng)用于一個具體的項目,首先要確定所有的testWare的一個目錄結(jié)構(gòu)。編寫main程序來初始化環(huán)境,解析配置文件,啟動測試引擎。抽象具體項目需要的Action,編制功能函數(shù),放到lib函數(shù)庫中。組織測試用例,準備測試數(shù)據(jù)。當所有的準備工作做完后,設(shè)置配置文件,運行測試,最后到result目錄查看測試結(jié)果。
這就是把WAF應(yīng)用到一個具體的項目測試的過程。
3.1 TestWare目錄結(jié)構(gòu)
TestWare的目錄結(jié)構(gòu)對于框架來說是很關(guān)鍵的。每一個目錄都有自己的意義而且必須被遵從來向其中加入新的功能。目錄結(jié)構(gòu)包括以下部分。
BIN:包括主程序(main),啟動(launch)腳本和測試配置文件。這是WAF的主要接口。TestConfig.ini文件用來定制和建立測試件(testWare)。啟動腳本用來啟動測試件(TestWare)。
Testdata:這個目錄包括所有的在測試表中使用的測試數(shù)據(jù)。針對不同的測試軟件存放各自的測試數(shù)據(jù),比如各種文件等。
Lib:這個目錄包括testWare的模塊。不僅包括WAF框架的模塊還包被測軟件的特定模塊。
Default config:產(chǎn)品的內(nèi)部架構(gòu)和設(shè)計被定一語這個目錄文件中。被測試軟件的配置文件被存放在這個目錄下。
Testsuites:這個目錄包括所有的測試表。這些測試表以樹形結(jié)構(gòu)來組織。
3.2 編寫功能函數(shù)和組織測試組合/測試用例
lib函數(shù)庫目錄下不僅包括WAF公用的函數(shù)還包括產(chǎn)品特定的功能函數(shù)。數(shù)據(jù)驅(qū)動引擎的代碼也保存在lib中。實現(xiàn)數(shù)據(jù)驅(qū)動引擎的代碼包括解析測試表,運行測試用例,訪問測試數(shù)據(jù),返回測試結(jié)果等[8]。
3.3 組織測試數(shù)據(jù)
圖2詳細的顯示了測試數(shù)據(jù)的組織。在被測軟件的testware中,所有的測試數(shù)據(jù)都存放在一個特定的目錄testdata下。在testdata目錄下,測試數(shù)據(jù)分別存放在相對應(yīng)的目錄下,然后在testware配置文件的相應(yīng)配置項中置上測試數(shù)據(jù)所在的目錄即可。
3.4 檢查測試結(jié)果
TestWare會把測試的全部結(jié)果結(jié)束按照測試執(zhí)行的時間輸出到testWare/results目錄中。圖3是一個測試結(jié)果的索引,它列出了所執(zhí)行的所有測試。
點擊相應(yīng)的測試用例,就會打開具體的測試用例的執(zhí)行情況,是成功還是失敗(success/fail),以及每個測試步的執(zhí)行結(jié)果是成功還是失敗,如下圖4所示。一旦測試執(zhí)行失敗,可以定位到具體的測試步驟。
3.5 WAF的優(yōu)點
跟當前主流的測試工具相比,WAF具有以下優(yōu)點[9]:
1) 實現(xiàn)了數(shù)據(jù)與腳本的分離。使得腳本的維護變得簡單而方便。框架的重用性得到提高,能減少測試成本;
2) 使測試自動化而無需額外技術(shù)支持,減少測試人員學(xué)習(xí)自動化測試的時間;
3) 可以根據(jù)需要指定測試計劃,測試表容易創(chuàng)建且維護簡單,且簡單的表結(jié)構(gòu)重用性高;
4) 不必等到產(chǎn)品穩(wěn)定以后才開始自動化測試。可以盡早的進行自動化測試,節(jié)約大量的手工測試的時間;
5) 測試人員不需要知道測試工具實現(xiàn)的細節(jié),只需要和表打交道和執(zhí)行自動化腳本;
6) 配置項從腳本中分離使得易于實現(xiàn)平臺的轉(zhuǎn)換,測試的移植。
4 工作總結(jié)
本文中主要介紹了自動化軟件測試技術(shù),優(yōu)秀部分在于提出應(yīng)用軟件自動化測試框架實現(xiàn)軟件自動化測試。以某軟件作為應(yīng)用背景提出一個適合該軟件自動化測試的基于關(guān)鍵字和數(shù)據(jù)驅(qū)動的自動化測試框架。并將該框架模型應(yīng)用于軟件開發(fā)過程中的軟件自動化測試。
這是一個最新的也是比較熱門的發(fā)展方向。自動化測試中的自動化測試框架的研究也稱為一個新的發(fā)展趨勢。
現(xiàn)在,己經(jīng)有一些商業(yè)化的自動化測試框架。在大多數(shù)情況下,他們和已有的商業(yè)化測試工具捆綁在一起。他們的主要不同點在于他們的底層的執(zhí)行引擎或腳本庫,是被映射到關(guān)鍵字,窗口還是對象或類,這也是將來自動化測試框架發(fā)展的幾個趨勢。關(guān)鍵字驅(qū)動的測試引擎已經(jīng)實現(xiàn),接下來,窗口引擎,對象引擎和類引擎等底層引擎的實現(xiàn)將會是商業(yè)化自動化測試框架的主要研究方向。
摘要: 軟件測試是保證軟件質(zhì)量的重要手段,本文介紹目前常用的軟件測試技術(shù),給出不同測試技術(shù)的基本思想,討論目前的研究內(nèi)容和存在的不足。
關(guān)鍵詞: 軟件測試;軟件質(zhì)量;Web測試
0引言
軟件測試是保證軟件質(zhì)量和可靠性的重要手段。軟件測試是軟件生命周期的一個重要組成部分,貫穿整個開發(fā)過程。軟件測試是保證軟件達到高質(zhì)量和高可靠性的關(guān)鍵元素。現(xiàn)有的軟件測試技術(shù)通常分為靜態(tài)測試和動態(tài)測試。根據(jù)測試對象和研究側(cè)重點的不同,目前軟件測試技術(shù)的研究大多在以下方面:
1白盒測試
白盒測試是對軟件的過程性細節(jié)做細致的檢查,把測試對象看做一個打開的盒子,允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息,設(shè)計或選擇測試用例,對程序所有邏輯路徑進行測試,因此又被稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。對白盒測試的研究主要在提高軟件的各種覆蓋率上,如文獻[1、2]。目前一般認為,基于同一測試覆蓋準則,測試覆蓋率越高,軟件的可靠性或可信性就越高。
2黑盒測試
黑盒測試[2]將被測對象看作一個打不開的黑盒,測試人員在不考慮程序內(nèi)部結(jié)構(gòu)和內(nèi)部特性的情況下,只依據(jù)需求規(guī)格說明書,設(shè)計測試用例,檢查程序的功能是否按照規(guī)范說明的規(guī)定正確地執(zhí)行。它著重于驗證軟件功能和性能的正確性,典型測試項目包括功能測試、性能測試、邊界側(cè)試、余量測試、強度測試等。黑盒測試主要缺點是:測試結(jié)果取決于測試例的設(shè)計,而測試例的設(shè)計部分來源于經(jīng)驗,沒有狀態(tài)轉(zhuǎn)換的概念,給尋找和確定程序缺陷帶來困難。
3性能測試
性能測試主要測試軟件處理事務(wù)的速度,一是檢驗軟件性能是否符合要求,二是得到某些客戶感興趣的數(shù)據(jù)以供軟件產(chǎn)品宣傳。目前性能測試工具偏向于多用戶的并發(fā)操作,側(cè)重于負載壓力的產(chǎn)生和服務(wù)器的監(jiān)控,忽略負載壓力情況下的功能不穩(wěn)定問題。文獻[3]指出性能測試時中間件的license、數(shù)據(jù)庫的用戶數(shù)有時影響系統(tǒng)的性能,測試時需綜合分析,以得到準確結(jié)果。
4Web測試
基于Web的系統(tǒng)測試與傳統(tǒng)的軟件測試不同,它需要檢查和驗證是否按照設(shè)計的要求運行,而且還測試系統(tǒng)在不同用戶的瀏覽器端的顯示是否合適,并從最終用戶的角度進行安全性和可用性測試。研究人員針對Web應(yīng)用的交互、動態(tài)等特性進行深入分析,探討Web應(yīng)用的相關(guān)測試方法和技術(shù)。
4.1 Web應(yīng)用模型的研究文獻[4]提出一種基于非確定Petri網(wǎng)的鏈接模型;文獻[5]將Web測試模型分為對象內(nèi)部模型、交互關(guān)系模型和體系結(jié)構(gòu)模型3個層次,分別對應(yīng)測試內(nèi)容的不同范圍和階段,即單元測試、交互測試和集成測試。
4.2 Web可用性測試方法文獻[6]針對目前各Web服務(wù)間采用統(tǒng)一的SOAP協(xié)議進行通訊,提出基于協(xié)議對Web服務(wù)程序進行測試的方法;文獻通過分析Web站點服務(wù)器端的日志文件得到的統(tǒng)計數(shù)據(jù),從獨特的角度探討如何進行有效的Web站點測試,提出切實可行的測試方法。
4.3 Web測試自動化的研究目前Web測試的自動化多采用捕捉―回放工具(Capture-Replay)的工作過程和相關(guān)技術(shù),但Web應(yīng)用中有很多動態(tài)生成的頁面且變動非常頻繁,捕捉―回放技術(shù)不能完全勝任。因而文獻提出通過使用具備一定智能的Agent建立起高效的Web應(yīng)用測試執(zhí)行方案。
4.4 其他方面的研究文獻利用語義標注和XML描述技術(shù)實現(xiàn)Web頁面中數(shù)據(jù)與顯示信息的分離,并引入反饋控制機制,把測試結(jié)果反饋給Web應(yīng)用本身。文獻提出一種Web服務(wù)測試數(shù)據(jù)自動生成方法;它基于Web服務(wù)的功能說明隨機地生成初始測試數(shù)據(jù),然后使用合約變異技術(shù)進行測試數(shù)據(jù)選擇,以生成一組達到一定合約變異充分度的有效測試數(shù)據(jù)。
5面向?qū)ο筌浖y試
面向?qū)ο蠹夹g(shù)具有多態(tài)、繼承、封裝等特點,使傳統(tǒng)測試技術(shù)無法對面向?qū)ο筌浖M行有效的測試。宏觀上面向?qū)ο筌浖歉鱾€類之間的相互作用,系統(tǒng)的基本構(gòu)造模塊是封裝的數(shù)據(jù)和方法的類和對象。對象中的數(shù)據(jù)和方法是一個有機的整體,測試過程不僅檢查輸入數(shù)據(jù)產(chǎn)生的輸出結(jié)果是否與預(yù)期的吻合,還考慮對象的狀態(tài)。
為使設(shè)計的軟件測試工具具有良好的語言無關(guān)性,文獻設(shè)計一種程序劃分機制,它針對基于狀態(tài)的面向?qū)ο筌浖念悳y試過程中存在的不可預(yù)測、不可達狀態(tài)、狀態(tài)組合“爆炸”和測試用例“爆炸”等問題,提出基于EDPN(Event-driven petri network)模型的類測試、類的交互測試和類的層次測試框架,設(shè)計相應(yīng)的測試模型。此外,研究人員對面向?qū)ο蟮臏y試策略和面向?qū)ο蟮幕貧w測試等方面,根據(jù)其特點提出相應(yīng)的新的思想和方法,如將多Agent系統(tǒng)引入面向?qū)ο蟮臏y試中等。
6總結(jié)
人類發(fā)展是一個發(fā)現(xiàn)問題,解決問題的改善過程。軟件業(yè)的發(fā)展帶來的問題,需要通過軟件測試來解決,因此軟件測試受到越來越多的關(guān)注和推廣。同時面向?qū)ο蟆gent 等新技術(shù)的應(yīng)用為軟件測試發(fā)展帶來新的機遇。
摘 要
互聯(lián)網(wǎng)信息高速發(fā)展的大背景下，無論硬件軟件的復(fù)雜程度，還是技術(shù)含量都在日益提高，人們對軟件的需求也越來越高。與此同時，軟件中存在的漏洞和缺陷也迅速成為黑客攻擊的對象，因此，建立一套高保障性的技術(shù)體系以保護軟件的研制和可靠性成為當下社會研究的當務(wù)之急。
【關(guān)鍵詞】軟件應(yīng)用 軟件開發(fā) 軟件測試
1 工程實例
1.1 測試過程
軟件開發(fā)是一個常規(guī)的過程，在當今時代環(huán)境下，一般分為4個階段，每個階段中都需要對軟件進行內(nèi)部測試，一般分為：靜態(tài)分析、代碼審查、單元測試、部件測試、配置項測試。
1.1.1 靜態(tài)分析
使用專業(yè)靜態(tài)分析工具，對軟件應(yīng)用的程序，數(shù)據(jù)等參數(shù)進行剖析，并進行深入的數(shù)據(jù)分析，將軟件應(yīng)用內(nèi)部的靜態(tài)信息和代碼信息提取出來，為未來的動態(tài)測試提供參考數(shù)據(jù)，并根據(jù)現(xiàn)在的軟件模型，對軟件的質(zhì)量做出正確評價。
1.1.2 代碼審查
主要是對代碼進行一系列專業(yè)的檢查過程，對代碼的容錯綠，代碼運轉(zhuǎn)結(jié)果的一致性，代碼的可讀性等進行檢查分析。重點對代碼的邏輯性，完整性進行檢查，保證正確率。
1.1.3 單元測試
按照軟件設(shè)計的說明圖，模擬軟件運行環(huán)境和運行部件，針對軟件的環(huán)境進行接口模擬，并創(chuàng)造出軟件的真實運行環(huán)境，進行測試，監(jiān)測軟件的運行結(jié)果。
1.1.4 部件測試
按照被測軟件的說明圖，在單元測試的基礎(chǔ)上，將各個測試成功的單元模塊按需求和設(shè)計組裝成一個符合設(shè)計需求的整體功能模塊，并進行測試，其目的是監(jiān)測軟件各個單元和接口之間的兼容性和容錯率，保證軟件的設(shè)計成功。
1.1.5 配置項測試
所謂配置項是軟件中為滿足不同用戶的不通需求而設(shè)計的，能體現(xiàn)用戶個性化功能的配置功能項，測試的目的是監(jiān)測配置項在軟件中的一致性。
1.2 問題現(xiàn)象
某產(chǎn)品軟件到了后期階段仍在進行頻繁更改，通過對其分析，得出軟件復(fù)雜度高是其存在的主要問題：
（1）模塊在結(jié)構(gòu)上應(yīng)使用單出入口的結(jié)構(gòu)，降低復(fù)雜性。
（2）在模塊的邏輯設(shè)計上進行改進，采用分層次的結(jié)構(gòu)，并在不同層次上設(shè)計不同的扇入扇出數(shù)，保證模塊的扇出數(shù)較低，一般不超過7，并且盡可能的增加模塊的扇入數(shù)，以保證代碼的簡潔性。另外，高層模塊的設(shè)計應(yīng)該采取不同策略，比如高層模塊扇出較高，低層模塊扇入較高等。
（3）軟件單元的圈復(fù)雜度（即McCabe 指數(shù)）應(yīng)小于10。
（4）簡化軟件單元的源代碼數(shù)量，高級語言實現(xiàn)的單元，不應(yīng)超過60行。
1.3 問題分析
測試的目的是為了更正軟件的錯誤，降低風(fēng)險率，一般來說經(jīng)過幾個階段的測試后，軟件中的缺陷基本都能被修復(fù)，但是沒有重視靜態(tài)分析中的軟件圈復(fù)雜度，基本復(fù)雜度超標的現(xiàn)象，軟件在后期的高復(fù)雜性往往會帶來潛在的風(fēng)險。
2 測試指導(dǎo)設(shè)計
2.1 軟件質(zhì)量的pareto原理
pareto原理[2] 指出，20%的軟件模塊包含了軟件中80%的缺陷，20%的軟件改進，需花費80%的適應(yīng)性維護費用。從這里可以得出結(jié)論，高復(fù)雜的模塊會導(dǎo)致軟件中可能出現(xiàn)的絕大部分錯誤，而且不容易修復(fù)。因此，在軟件設(shè)計早起杜絕復(fù)雜度過高的風(fēng)險十分必要。
2.2 降低軟件圈復(fù)雜度
2.2.1 圈復(fù)雜度定義
圈復(fù)雜度作為一個衡量軟件結(jié)構(gòu)復(fù)雜性的標準，數(shù)量上表現(xiàn)為獨立線性路徑條數(shù)，即合理的預(yù)防錯誤所需測試的最少路徑條數(shù)。1976年ThomasMcCabe提出了圈復(fù)雜度（Cyclomatic Complexity）的概念，依據(jù)圈復(fù)雜度定義了軟件的復(fù)雜性。1977年Halstead提出了軟件科學(xué)復(fù)雜度度量。文獻[3]，在這個理念中重點分析了嵌入式軟件的位置的重要性，并通過模型的方式展示了軟件復(fù)雜度的度量對識別代碼錯位的重要性。可以看出，軟件的錯誤和缺陷并非隨機分布的，而是有跡可循，和軟件的個性化，復(fù)雜度息息相關(guān)。
2.2.2 復(fù)雜度計算方法
C語言常用的軟件模塊邏輯結(jié)構(gòu)（結(jié)構(gòu)流圖）有如下幾種，如圖3所示。
2.2.3 降低圈復(fù)雜度
如果圈復(fù)雜度高于標準值的時候，可以提前做出判斷，降低代碼的復(fù)雜度和重復(fù)性。在判斷語句中采取單一的判斷條件，或者將重復(fù)代碼用一個函數(shù)來替代。都是降低代碼復(fù)雜度和重復(fù)性的有力措施。
2.3 降低軟件基本復(fù)雜度
運轉(zhuǎn)正常的語句或代碼應(yīng)帶保證單入口和單出口結(jié)構(gòu)，保證程序的簡潔性，不應(yīng)過多使用異常跳轉(zhuǎn)語句增加程序的運轉(zhuǎn)復(fù)雜度，如果非結(jié)構(gòu)化語句過多，出入口增大，只會導(dǎo)致結(jié)構(gòu)的復(fù)雜度增高，增加軟件后期運行的風(fēng)險。
因此，只要控制程序語句的結(jié)構(gòu)單一化，簡單化，避免各種非正常跳轉(zhuǎn)語句的使用，復(fù)雜度就會在可控制的范圍內(nèi)，有利于程序的運行穩(wěn)定。
2.4 降低軟件扇出數(shù)
扇出的意思是函數(shù)調(diào)用其他函數(shù)的個數(shù)，如果扇出過小，則會導(dǎo)致程序代碼過長，如果扇出過大，則會增加程序內(nèi)函數(shù)的調(diào)用次數(shù)，影響速度，一般來說扇出最好為3或4個，最高不超過7個。
扇入的意思是一個函數(shù)被其他程序調(diào)用的次數(shù)，扇入較多會增加模塊的使用頻率，但是過高的扇入會影響程序的聚合性，如果扇出扇入次數(shù)過高，可以考慮重新調(diào)整該函數(shù)或過程。
3 結(jié)語
本文通過以測試結(jié)果來倒向改進軟件設(shè)計的思路，提高了軟件的設(shè)計質(zhì)量和可靠性，可以看出，在軟件代碼內(nèi)部進行早期分析，在軟件設(shè)計早期對軟件代碼，復(fù)雜度等指標進行優(yōu)化限制，對軟件后期的穩(wěn)定運行，錯誤率降低有非常大的影響和幫助，成為軟件改進的新思路。
作者單位
天津濱海職業(yè)學(xué)院 天津市 300451
