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