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