【正文】 和管理的雙重功能十分利于剛進入測試領(lǐng)域的人員?！　ational Robot作為業(yè)界最頂尖的自動化功能測試工具，它可以在測試人員學(xué)習(xí)高級腳本技術(shù)同時幫助其進行成功的測試?！　inRunner是Mercury Interactive公司的一種企業(yè)級的功能測試工具，用于檢測應(yīng)用程序是否能夠達(dá)到預(yù)期的功能及正常運行。自動化工具出現(xiàn)目的是想用它來執(zhí)行重復(fù)的手動測試，主要是用于回歸測試和測試同一軟件的新版本。在選擇測試方案的時候，要參照下列因素[4]：（1） 項目的影響：制定的方案是否對整個項目有積極作用，或者讓開發(fā)更敏捷（2） 復(fù)雜度：自動化是否容易實現(xiàn)（3） 時間：自動化測試的實現(xiàn)需要多少時間（4） 早期需求和代碼的穩(wěn)定性：如果不能穩(wěn)定，那么自動化測試介入會很尬尷（5） 覆蓋率：能否覆蓋程序中的關(guān)鍵特性和功能（6） 資源：有沒有足夠的人力資源、數(shù)據(jù)資源、硬件資源來支持自動化的開展在確定方案后，測試腳本的編碼階段，編寫方法也左右著自動化測試的效率和質(zhì)量?？梢栽陔r形期做一些準(zhǔn)備，考慮測試工具的選擇。同樣，在一個非常緊迫的項目中也是不合適的，因為需要測試人員開發(fā)編寫測試腳本，并需要開發(fā)人員的配合使得整個進程更加緊張倉促，適得其反。首先要確定所開發(fā)的軟件項目采用自動化測試是否適用。而在借助計算機強大的計算能力下，可以不知疲倦、重復(fù)的運行，對于大量的數(shù)據(jù)也能在短時間內(nèi)處理結(jié)束。伴隨著產(chǎn)品的完善，軟件功能的逐步完善，需要測試的內(nèi)容有時候會呈現(xiàn)幾何倍數(shù)增長，人工進行回歸測試便顯得捉襟見肘。軟件測試的一個顯著特點就是重復(fù)性，重復(fù)的工作除了機器人沒人忍受的了。敏捷方法則打破了傳統(tǒng)的自動化測試方法，第一個破壞點集中在自動化的可接受性測試，很難被其他類型的自動化重用。如果在需求定義方面做得很好，對自動化測試十分有益，可以盡早的選擇測試策略，讓自動化測試高層次整體地進行。在不同的開發(fā)模式中，軟件測試的地位和作用略有不同，但卻不可能消失。1983年，ANSI IEEE STD729給出了軟件質(zhì)量的定義[ 6]，包括：（1） 軟件產(chǎn)品質(zhì)量滿足用戶要求的程度；（2） 軟件各種屬性的組合程度；（3） 用戶對軟件產(chǎn)品的綜合反映程度；（4） 軟件在使用過程中滿足用戶要求的程度。而在IBM RUP（統(tǒng)一過程）中，質(zhì)量被定義為“滿足或超出認(rèn)定的一組要求，并使用經(jīng)過的認(rèn)可的評測方法和標(biāo)準(zhǔn)來評估，還使用認(rèn)定的流程生產(chǎn)”。軟件質(zhì)量也是軟件項目管理的重要組成部分，在不同的開發(fā)模式中，都會圍繞軟件質(zhì)量管理提出相應(yīng)的做法。如果將這這些用例轉(zhuǎn)化為可被自動化測試工具執(zhí)行的腳本，那么就成了一個自動化測試用例，使用自動化的方式執(zhí)行，提高效率。在測試用例中，主要分為兩種。也因此軟件測試成為了軟件缺陷的主要控制手段和解決方法。 如何通過軟件測試發(fā)現(xiàn)軟件缺陷手工測試仍然是主要的查找錯誤的方式，自動化測試能部分地解決覆蓋面的問題和測試效率的問題，但是不能從根本上解決問題。軟件缺陷的可預(yù)見性就沒有那么強，其一個重要特點就是隱蔽性。因此，軟件缺陷與硬件缺陷一樣，都需要人們重視他們可能造成的危害與損失。但是軟件缺陷在一般情況下，不會對用戶造成直接的人身傷害或經(jīng)濟損失，也因此很多人意識不到軟件缺陷的危害性和嚴(yán)重性。 課題研究目的本文旨在通過QTP在具體案例中的使用，包括設(shè)計測試案例、錄制、優(yōu)化腳本功能等，來具體認(rèn)識自動化測試對于普通應(yīng)用軟件，都可以發(fā)揮其功能測試和回歸測試的優(yōu)點，省去了手工測試的繁瑣，更加低成本，便捷而快速的找出軟件的BUG所在，是軟件開發(fā)中一個不可或缺的重要的一部分。南京大學(xué)和航空局計算研究所開發(fā)的靜態(tài)分析工具和測試用例自動生成工具，在嵌入式系統(tǒng)測試方面取得了較大的成功[10]。西北工業(yè)大學(xué)在C/S系統(tǒng)的測試方面進行了許多的研究工作，并且取得了一定的成績。這些測試工具融入了許多新的技術(shù)，如面向?qū)ο蠹夹g(shù)，當(dāng)針對不同的測試重點，可以采用相應(yīng)的工具[3]。為了更好的實現(xiàn)測試的自動化，用自動化測試代替手工勞動，許多IT廠商推出了以工具為中心的測試，是測試人員只需要關(guān)注腳本技術(shù)和配置文件的編寫。在美國北卡羅來納大學(xué)召開的軟件測試的正式技術(shù)會議，是軟件測試技術(shù)發(fā)展歷史上的一個轉(zhuǎn)折點，它標(biāo)志著軟件測試成為了軟件工程領(lǐng)域中一個獨立而重要的分支。在許多大型的軟件公司，其測試人員和開發(fā)人員比例達(dá)到了1:1，甚至更多[4]。它為軟件開發(fā)團隊節(jié)約了測試成本，提高了軟件質(zhì)量，縮短了產(chǎn)品發(fā)布周期。這些都在極大程度上降低了測試的覆蓋率，增加了測試的成本，影響了軟件質(zhì)量的可靠性[4]。傳統(tǒng)的軟件測試方式大多停留在內(nèi)部測試、手工測試階段，并不能完全適用于應(yīng)用測試。于是，軟件測試便扮演了極其重要的角色，貫穿于整個軟件生命周期，檢驗各個階段的成果是否符合質(zhì)量要求和達(dá)到預(yù)先定義的目標(biāo)。基于QTP的自動化測試畢業(yè)論文目 錄1 概 述 1 課題研究背景 1 國內(nèi)外研究現(xiàn)狀 1 課題研究目的 22軟件缺陷與軟件測試 3 3 軟件缺陷與硬件缺陷異同 3 如何通過軟件測試發(fā)現(xiàn)軟件缺陷 3 4 4 5 5 5 6 63 QuickTest Professional的簡介 9 QTP的安裝與配置 9 QTP的使用 10 11 11 11 114 基于QTP自動化測試的實施 13 登錄功能測試 13 測試用例 13 腳本錄制 14 測試腳本 15 執(zhí)行結(jié)果 16 訂票功能測試 18 錄制腳本過程 18 調(diào)試測試腳本及注解 19 執(zhí)行結(jié)果 21 修改訂單功能測試 21 測試用例 21 錄制腳本過程 22 調(diào)試測試腳本及注解 24 執(zhí)行結(jié)果 25 刪除訂單功能測試 26 測試用例 26 錄制腳本過程 26 調(diào)試測試腳本及注解 28 執(zhí)行結(jié)果 28 傳真功能測試 29 錄制腳本過程 29 調(diào)試測試腳本及注解 30 執(zhí)行結(jié)果 315 測試結(jié)果分析 33 測試用例匯總表 33 檢查項 34 對比與分析 34 分析與建議 35結(jié) 論 37參考文獻 38致 謝 391 概 述 課題研究背景按時、高質(zhì)量地發(fā)布軟件產(chǎn)品是軟件開發(fā)的最基本要求，而軟件測試是軟件質(zhì)量保證的最重要的手段之一。對于軟件，不論采用什么技術(shù)和方法來進行開發(fā)，軟件產(chǎn)品中都會存在或多或少的錯誤和問題[1]。據(jù)大量統(tǒng)計資料顯示，在典型的軟件開發(fā)的項目中，軟件測試投入的成本和工作量往往占到軟件的總成本和總工作量的40%以上。由于較多的企業(yè)采用瀑布模型進行開發(fā)，往往在軟件開發(fā)結(jié)束后才開始進行測試。因此，軟件測試自動化技術(shù)的出現(xiàn)，從真正意義上把測試人員從簡單重復(fù)的勞動中解放出來，彌補了手動測試在應(yīng)付大規(guī)模測試中疲態(tài)的缺陷，尤其是面對大量的數(shù)據(jù)需要檢查時，人工的比較和搜索不僅效率低，而且容易出錯，覆蓋面偏低。 國內(nèi)外研究現(xiàn)狀軟件測試是軟件質(zhì)量的護航者，只有通過了測試軟件的設(shè)計、編碼和規(guī)約的評審才能通過，在軟件的整個生命周期中具有與軟件開發(fā)相同的地位。然而，在早期軟件測試常常被忽視，軟件經(jīng)過開發(fā)人員簡單的單元測試后進行發(fā)布，導(dǎo)致的后果可想而知。此后，Gerhart進一步總結(jié)原來的測試?yán)碚?，將軟件測試提升到理論的高度，作為實踐性學(xué)科的參考[2]。常用的測試工具有Mercury Interactive公司的QTP、LoadRunner、TestDirectior，IBM的Web自動化測試工具Rational Function Tester，Segue Software公司的Segue，Compuware公司的QACenter。國內(nèi)的軟件測試技術(shù)起步較晚，但隨著國內(nèi)軟件企業(yè)規(guī)模的壯大，人才的引進和培養(yǎng)，越來越多的軟件生產(chǎn)商開始在自動化測試領(lǐng)域中進行軟件分析和測試工具的研究和開發(fā)。北京航空航天大學(xué)和北京大學(xué)經(jīng)過技術(shù)的攻關(guān)，共同研制了一系列測試工具和程序理解工具，例如具有典型代表的SafePro/javao和SafePro C/C++。擁有自主知識產(chǎn)權(quán)的澤眾軟件是國內(nèi)領(lǐng)先的專業(yè)功能測試工具、測試管理工具的供應(yīng)商，從2004年起就推出了AutoRunner、TestCenter等優(yōu)秀產(chǎn)品。2軟件缺陷與軟件測試 軟件缺陷與硬件缺陷異同對于用戶來說，軟件缺陷與硬件缺陷一樣，會對用戶在使用時造成困擾。然而在一些比較依賴軟件進行業(yè)務(wù)處理的領(lǐng)域，便可能造成重大的經(jīng)濟損失，甚至危及生命，例如2007年4月，某個軟件缺陷導(dǎo)致某地鐵系統(tǒng)的列車火災(zāi)，軟件未能檢測和防止剩余動力在設(shè)備中的使用，導(dǎo)致車過熱而起火。不同在于，硬件缺陷大多是可預(yù)見的，比較容易被發(fā)現(xiàn)。由于軟件的復(fù)雜度高，狀態(tài)空間廣闊，因此，要覆蓋軟件所有的可能行為幾乎是不可能的。而在軟件測試之前的開發(fā)環(huán)節(jié)中，開發(fā)人員已經(jīng)對對軟件進行缺陷控制，盡管大多停留在“調(diào)試”階段的測試水平。測試人員通過產(chǎn)品需求，以及用戶的實際業(yè)務(wù)背景，設(shè)計出各種測試用例，通過執(zhí)行測試用例，判斷被測試的應(yīng)用程序是否滿足用戶需求。一是驗證軟件功能正確的；另一種適用于證明軟件錯誤的。軟件質(zhì)量是軟件產(chǎn)品的核心價值體現(xiàn)，也是企業(yè)競爭力的體現(xiàn)，重視軟件質(zhì)量的企業(yè)通常能獲得更多的收益。1986年，ISO8492給出了質(zhì)量定義：質(zhì)量是產(chǎn)品或服務(wù)滿足明示或暗示需求能力的固有特性和特征的集合。因此，質(zhì)量不是簡單地滿足用戶需求，還得包含證明質(zhì)量達(dá)標(biāo)所使用的評測方法及標(biāo)準(zhǔn)，以及如何實施可管理、可重復(fù)使用的流程，以確保由此流程生產(chǎn)的產(chǎn)品已達(dá)到預(yù)期的、穩(wěn)定的質(zhì)量水平。簡而言之，功能、性能和可靠性是衡量軟件質(zhì)量的三個維度指標(biāo)。在傳統(tǒng)的瀑布開發(fā)模型中，軟件測試作為一個獨立的階段出現(xiàn)，在進入測試階段之前，應(yīng)該完成編碼并且提供完善的需求、設(shè)計和文檔。而在RUP迭代模型中，實施自動化測試時，需要與開發(fā)策略緊密結(jié)合