軟件工程畢業(yè)設(shè)計(jì)（論文）AutomaticFunctionalTesting在SAP系統(tǒng)中的應(yīng)用

1、同濟(jì)大學(xué)學(xué)士學(xué)位論文automatic functional testing在sap系統(tǒng)中的應(yīng)用本科生：學(xué) 號(hào)：導(dǎo) 師：專 業(yè)：軟件工程tongji universitypaper for bachelor degreeimplementation of automatic functional testing in sap systemcandidate : zhou junweiadvisor : du qingfengmajor : software engineeringmay 2004【摘要】 在當(dāng)今軟件開發(fā)中，軟件測試已經(jīng)越來越被人們所重視。它直接影響著軟件整個(gè)生命周期。但是軟件也

2、出現(xiàn)了越來越龐大、復(fù)雜和靈活等新的趨勢，這就給測試帶來一系列新的問題。對(duì)于軟件的復(fù)雜，靈活，軟件測試正采用自動(dòng)化測試來逐步取代軟件手工測試，這樣可以節(jié)省大量人力、物力和時(shí)間。本文主要討論對(duì)當(dāng)今大型軟件進(jìn)行自動(dòng)化功能測試時(shí)的一些問題，并據(jù)此對(duì)測試過程的各個(gè)方面如創(chuàng)建測試計(jì)劃，設(shè)計(jì)測試案例，錄制、優(yōu)化和執(zhí)行腳本，如何確認(rèn)和報(bào)告缺陷等都作了一些改進(jìn)，并通過實(shí)例表明了該過程的有效性?！娟P(guān)鍵字】 自動(dòng)化測試，功能測試，sap(system application product)【外文摘要】 in software development today, software testing as a fie

3、ld has become more and more important. it has influence on the whole lifecycle of software. however, as the software is becoming larger, more complex and more agile, which has brought a series of new problems. automated testing is more and more taking the place of manual testing, which can help to s

4、ave lots of human and material resource and valuable test cycle. the paper focuses on how to do the automated testing on large scale software, and showed a whole process of automated testing, including test plan setup, test case design, test scripts creation, optimization and execution, test report

5、confirmation and test defects reporting, based on a example to prove the effectiveness of this process.【key words】 automated testing，functional testing, sap(system application product)目 錄第一章 概述51.1 簡介51.2 sap簡介5第二章 功能性測試的一般流程分析62.1 軟件測試概要描述62.2 基于功能性增強(qiáng)流程62.3 對(duì)大型軟件測試遇到的問題8第三章 對(duì)測試工具的選擇的重要性10第四章 對(duì)sap進(jìn)行

6、功能性回歸測試114.1 項(xiàng)目簡介114.2 需求分析114.3 創(chuàng)建測試案例134.4 錄制和優(yōu)化腳本164.5 完成最終報(bào)表194.6 做好腳本的配置管理214.7 建立培訓(xùn)機(jī)制和腳本維護(hù)21總結(jié)與展望23致謝24參考文獻(xiàn)25第一章 概述1.1 簡介隨著計(jì)算機(jī)在越來越多的領(lǐng)域中發(fā)揮著重要的作用和計(jì)算機(jī)各種技術(shù)的發(fā)展，當(dāng)今軟件的發(fā)展也出現(xiàn)了新的趨勢：越來越龐大、復(fù)雜和靈活，例如大多erp(enterprise resource planning企業(yè)資源計(jì)劃)軟件諸如：sap都將人力資源、后勤管理、銷售分銷、財(cái)務(wù)管理和控制都包含在應(yīng)用范圍之內(nèi)，其各個(gè)應(yīng)用模塊之間的通訊和聯(lián)系越來越緊密，相互共享

7、和交換的數(shù)據(jù)也越來越多，圖形用戶界面也隨之繁多而復(fù)雜。另外，為適應(yīng)市場的迅速變化，大多erp軟件都具有相當(dāng)?shù)撵`活性和二次開發(fā)性。軟件的這種變化趨勢使軟件測試越來越重要，但同時(shí)也對(duì)其提出了嚴(yán)峻的挑戰(zhàn)。軟件測試在軟件生命周期中占據(jù)重要的地位，事實(shí)上，對(duì)于軟件來講，不論采用什么技術(shù)和什么方法，軟件中仍然會(huì)有錯(cuò)。采用新的語言、先進(jìn)的開發(fā)方式、完善的開發(fā)過程，可以減少錯(cuò)誤的引入，但是不可能完全杜絕軟件中的錯(cuò)誤，這些引入的錯(cuò)誤需要測試來找出，軟件中的錯(cuò)誤密度也需要測試來進(jìn)行估計(jì)。測試是所有工程學(xué)科的基本組成單元，是軟件開發(fā)的重要部分。1.2 sap介紹sap是全球領(lǐng)先的商務(wù)軟件解決方案提供商。sap解決方

8、案可以滿足各種規(guī)模公司的需要從小型到中型及跨國企業(yè)。借助sapnetweaver開放集成與應(yīng)用平臺(tái)來降低復(fù)雜性和總體擁有成本并鼓勵(lì)企業(yè)變革創(chuàng)新，mysap商務(wù)套裝軟件正幫助全球的企業(yè)改善客戶關(guān)系、增強(qiáng)合作伙伴協(xié)作，并提高供應(yīng)鏈與業(yè)務(wù)運(yùn)行效率。sap的超過25款行業(yè)解決方案為各種不同行業(yè)（從航空到公共設(shè)施）的核心運(yùn)營提供著強(qiáng)有力的支持。目前，全球有120多個(gè)國家的超過22,600個(gè)用戶運(yùn)行著76,100多套sap軟件。sap在全球50多個(gè)國家設(shè)有子公司，并在多家交易所上市，包括法蘭克福證券交易所和nyse，交易代碼為“sap”。第二章 功能性測試的一般流程分析2.1 軟件測試概要描述軟件測試的方

9、法主要有兩種：黑盒測試和白盒測試。一般在進(jìn)行結(jié)構(gòu)性測試時(shí)，使用白盒測試較多。白盒測試需要全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對(duì)所有邏輯路徑進(jìn)行測試。測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。在功能性測試時(shí)，大都采用黑盒測試。黑盒測試不需要了解程序的內(nèi)部結(jié)構(gòu)，只針對(duì)軟件界面和軟件的功能進(jìn)行測試。黑盒測試只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當(dāng)?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。它不需要知道軟件如何運(yùn)行，為什么會(huì)這樣，只知道程序做什么。對(duì)于sap系統(tǒng)，每個(gè)月都要進(jìn)行更新，如果使用白盒測試，要測試人員不光要懂sap系

10、統(tǒng)，甚至要讀懂源代碼。對(duì)于每個(gè)月sap的大量測試任務(wù)來說，將要花費(fèi)大量的人力、物力，再者社會(huì)上這種人才缺乏，實(shí)現(xiàn)的可能性不大。所以采用功能性回歸測試，這樣測試人員只需要懂簡單的sap知識(shí)和測試技術(shù)就可以了。由于每個(gè)月都要測試同樣的功能，為了節(jié)省人力，時(shí)間，把要測試的功能編成腳本，實(shí)現(xiàn)自動(dòng)化。一般的功能性測試流程：需求分析 - 測試案例 - 測試案例執(zhí)行 - 測試結(jié)果。2.2 基于功能性增強(qiáng)流程測試管理者根據(jù)功能性測試的一般流程，提出了有計(jì)劃、可持續(xù)改進(jìn)，功能性增強(qiáng)的測試過程：（圖1） 1) 分析測試流程, 準(zhǔn)備分析文檔和最終報(bào)表。確認(rèn)客戶的需求并準(zhǔn)確的傳達(dá)給測試人員。目的是要從建立文檔轉(zhuǎn)移到建

11、立工程，重點(diǎn)不是編寫而是計(jì)劃。其格式可有測試組自己來定義，但內(nèi)容上應(yīng)包括范圍、時(shí)間和成本方面的內(nèi)容，由于不確定的因素較多，通常需要將時(shí)間和成本要略大于實(shí)際的估計(jì)值。還要制定一個(gè)合理的測試目標(biāo)。測試員、管理部門都要知道和同意這個(gè)目標(biāo)。軟件測試員的目標(biāo)應(yīng)該是：找出軟件缺陷，盡可能早一些，保證起得到修復(fù)，并在正確的時(shí)機(jī)結(jié)束測試。測試員不能僅滿足于找出缺陷，卻忽略了要確保其得到修復(fù)這個(gè)目的。但當(dāng)測試組沒有足夠的時(shí)間、軟件不算真正的缺陷、修復(fù)的風(fēng)險(xiǎn)大大或不值得去修復(fù)時(shí)，就不需要修復(fù)軟件缺陷。測試組往往希望“通過測試的軟件產(chǎn)品是沒有問題的產(chǎn)品”，因?yàn)槿绻荒苷业藉e(cuò)誤，客戶就會(huì)遲早找到它們。但實(shí)際上對(duì)于測試

12、人員來說不可能真正達(dá)到而只能盡量地接近這個(gè)目標(biāo)，這個(gè)度往往是：當(dāng)時(shí)間或資金不夠用的時(shí)候，就完成了測試。2) 測試案例測試案例主要包括：確定案例執(zhí)行前所需要的測試環(huán)境和先決條件；確定所要測試的目標(biāo)；確定對(duì)輸入數(shù)據(jù)的要求和期望的輸出。設(shè)計(jì)測試案例時(shí)要注意：努力提高重用率，盡量減少執(zhí)行、調(diào)試和結(jié)果分析的工作量；加強(qiáng)測試案例的獨(dú)立性、并精確地文檔化等來加強(qiáng)其可維護(hù)性。好的測試案例可以極大提高測試的效率。目前的軟件是比較復(fù)雜的，客戶端服務(wù)器、瀏覽器服務(wù)器、數(shù)據(jù)通信、巨大的關(guān)系數(shù)據(jù)庫技術(shù)的利用以及規(guī)模龐大，所有這一切都造成軟件的復(fù)雜性提高，以至于沒有一定基礎(chǔ)的人不可能全面地掌握它。軟件本身的復(fù)雜性和相互之

13、間頻繁的聯(lián)系使軟件的出錯(cuò)概率提高，也使測試的難度提高，給測試人員的素質(zhì)提出更高的要求。分析測試流程, 準(zhǔn)備分析文檔和最終報(bào)表測試案例測試腳本end測試案例編寫人員測試腳本編寫人員測試腳本工程師分析文檔詳細(xì)測試案例腳本最終報(bào)表腳本優(yōu)化 圖1：功能性測試流程另外，測試案例應(yīng)該盡可能精簡而又能達(dá)到測試目標(biāo)。如果測試案例包含了很多測試步驟，就會(huì)使測試案例的復(fù)雜度大大增加，從而增加測試案例的可維護(hù)性和理解性。3) 測試腳本 錄制腳本前，測試員必須對(duì)測試工具能夠進(jìn)行非常熟練的操作，否則會(huì)大大增加編輯測試腳本的成本。錄制腳本之前應(yīng)該進(jìn)行相應(yīng)的配置，按照測試案例錄制測試腳本，否則可能會(huì)給腳本的優(yōu)化、執(zhí)行帶來很

14、大的麻煩，甚至要重新進(jìn)行錄制。對(duì)于大型軟件，其業(yè)務(wù)流程的復(fù)雜，數(shù)據(jù)依賴很多，所以要對(duì)其進(jìn)行參數(shù)化。因此要有一份文件詳細(xì)描述：什么值需要參數(shù)化，如何對(duì)全局的、過程的參數(shù)命名、傳遞和聯(lián)系。優(yōu)化腳本時(shí)可以安排兩個(gè)人一組來共同做好分支和循環(huán)，對(duì)對(duì)象屬性的取舍和設(shè)置，設(shè)置檢查點(diǎn)和輸出，以使腳本能按照測試案例的要求適應(yīng)各種情況。4) 對(duì)于測試結(jié)果缺陷的判斷由于使用了測試腳本，所以不可避免有一些錯(cuò)誤是由測試腳本引起的，需要有經(jīng)驗(yàn)的測試工程師加以區(qū)分。在報(bào)告軟件缺陷時(shí)，測試員要：a. 盡快報(bào)告軟件缺陷。軟件測試員發(fā)現(xiàn)一個(gè)問題后往往滿足于發(fā)現(xiàn)了問題，而把已發(fā)現(xiàn)的問題簡單處理后放在一旁。盡快報(bào)告能使問題早點(diǎn)被解決

15、，從而使中斷了的測試在同一測試周期內(nèi)能被繼續(xù)下去，可以使測試發(fā)現(xiàn)更多有意義的問題，縮短整個(gè)測試周期。b. 在軟件缺陷的描述上要簡短、易懂，有一個(gè)統(tǒng)一的格式，還要給出再現(xiàn)這個(gè)缺陷的條件或步驟，并對(duì)軟件缺陷劃分其重要性和優(yōu)先級(jí)。一個(gè)報(bào)告僅描述一個(gè)問題，因?yàn)檫@樣缺陷便于跟蹤和解決。c. 在報(bào)告軟件缺陷時(shí)不做評(píng)價(jià)。測試員雖然也可能猜測到問題出現(xiàn)在哪里，但測試員這么做肯定是低效的，評(píng)價(jià)不應(yīng)是測試員的責(zé)任。d. 補(bǔ)充完善軟件缺陷報(bào)告。測試員發(fā)現(xiàn)并記錄了大量軟件缺陷之后，要繼續(xù)監(jiān)視其修復(fù)的全過程，確保軟件缺陷得以修復(fù)并最終解決，盡量縮短軟件缺陷的生命周期。2.3 對(duì)大型軟件測試遇到的問題軟件功能測試是用來驗(yàn)

16、證軟件是否具有滿足用戶需求的的功能，在軟件測試的各個(gè)階段，尤其是確認(rèn)測試階段功能測試都相當(dāng)重要。在軟件發(fā)布后的每次改動(dòng)或升級(jí)后，也都需要對(duì)其進(jìn)行回歸行功能測試以保證起原有功能無誤。測試技術(shù)主要使用動(dòng)態(tài)黑盒測試技術(shù)。目前對(duì)軟件測試方法主要有手工測試和自動(dòng)化測試。自動(dòng)化測試與手工測試相比有著明顯的優(yōu)點(diǎn)，自動(dòng)化測試一般更準(zhǔn)確、更精確，具有更快的速度和更高的效率，而且測試工具不會(huì)疲勞，因此是測試技術(shù)未來的發(fā)展趨勢?，F(xiàn)在很多測試就在用自動(dòng)化測試技術(shù)。為了達(dá)到更好的測試效果和節(jié)約測試成本，對(duì)軟件的測試一般由獨(dú)立的測試組進(jìn)行，但這對(duì)于大型軟件的測試卻非常困難。因?yàn)闇y試組應(yīng)該熟悉至少要理解被測試的軟件，組內(nèi)最

17、好有一些熟悉此軟件的專家參與或作為顧問，但大型軟件卻給人們認(rèn)識(shí)、了解和使用等提出了許多困難，測試組若不經(jīng)過有效的培訓(xùn)很難能熟悉它，熟悉此軟件的專家成了社會(huì)上的稀缺人才。而且自動(dòng)化測試在某些方面還不成熟，不能完全代替手工測試，因此在對(duì)大型軟件進(jìn)行自動(dòng)化測試時(shí)往往會(huì)出現(xiàn)許多困難，如：1) 制定測試案例困難。有限的人力、時(shí)間內(nèi)，測試組不可能發(fā)現(xiàn)軟件中的所有問題，軟件測試員就必須在選擇測試案例時(shí)就從廣度和深度上權(quán)衡。這就要求對(duì)被測試軟件很熟悉，否則難以制定出有效的測試案例。2) 缺陷難以確認(rèn)。軟件經(jīng)常變更，而目前自動(dòng)化工具靈活性不足，智能化程序不高，其腳本難以及時(shí)適應(yīng)變更，這可能導(dǎo)致自動(dòng)化失敗或造成潛

18、在的問題。由于不熟悉被測試軟件，測試員難以把這寫腳本問題同缺陷區(qū)分開來。另外，如果測試員對(duì)自動(dòng)化測試工具不熟悉也會(huì)影響測試員的判斷力。3) 腳本的變更管理和配置管理。由于自動(dòng)化腳本很多都很大，往往是包含有許多文件和子文件夾的文件，而且腳本經(jīng)常要被改動(dòng)，而每次改動(dòng)往往會(huì)影響多個(gè)文件或文件夾，因此一般的版本控制軟件不適合管理它們，這常常導(dǎo)致測試員所用的腳本不是最新或不一致的情況，以致測試效果低下。4) 與技術(shù)相關(guān)的問題所有這寫問題都會(huì)導(dǎo)致測試員士氣低下、主動(dòng)性降低、工作效率低下。本文將針對(duì)測試案例制定困難、缺陷難以確認(rèn)、配置管理等問題提出一個(gè)功能測試流程，并在sap系統(tǒng)的功能測試中加以應(yīng)用。第三章

19、 對(duì)測試工具的選擇的重要性在測試中，對(duì)于測試工具的選擇也是很重要的。好的測試工具可以很好地幫助測試人員完成工作，實(shí)現(xiàn)測試自動(dòng)化。測試工具選擇過程的最終目的是要證明一個(gè)工具能使測試者在自己的公司里對(duì)測試進(jìn)行自動(dòng)化。在選擇過程中，對(duì)測試工具可能有一大堆的需求。有些需求與測試者現(xiàn)在具有且希望用測試工具來解決或至少是減輕的測試問題有關(guān)。其他需求還包括限制工具選擇的技術(shù)和非技術(shù)原因。首先需要明確這些對(duì)工具的需求，以便有評(píng)估候選工具的依據(jù)。當(dāng)然還要考慮到效益和風(fēng)險(xiǎn)，即值不值得使用測試工具，因?yàn)榫帉懞途S護(hù)測試腳本需要大量的工作量，對(duì)于長遠(yuǎn)來說是有價(jià)值的，但是對(duì)于短期的測試是沒有多大的價(jià)值。至于風(fēng)險(xiǎn)，由于使用

20、了測試工具，缺陷的發(fā)現(xiàn)數(shù)量肯定比手工測試發(fā)現(xiàn)缺陷的數(shù)量要少，這或多或少地影響了測試的最終結(jié)果?，F(xiàn)在市面上比較好的測試工具往往都不是免費(fèi)的，需要購買license，這無形中又增加了投資，所以測試組要綜合考慮以上因素，做出正確的決定，選擇既價(jià)廉又實(shí)用的測試工具。普通的測試工具能夠進(jìn)行錄制，但是對(duì)于像sap這樣復(fù)雜的系統(tǒng)，普通測試工具不能滿足要求，比如，要在一個(gè)表中輸入某一項(xiàng)，由于輸入這項(xiàng)的位置時(shí)常發(fā)生變化（包括列數(shù)和行數(shù)），普通測試工具無法捕捉，甚至無法識(shí)別這個(gè)表。win runner 雖然能實(shí)現(xiàn)以上功能，但是它在實(shí)際應(yīng)用中對(duì)于sap的table tree control對(duì)象的操作有誤。而qtp

21、6.0能滿足以上的要求，它擁有專門針對(duì)sap系統(tǒng)測試的插件。在比較了各種測試軟件后，發(fā)現(xiàn)qtp 6.0能滿足測試的需要，所以qtp6.0是最佳的選擇。第四章 qtp 6.0在sap系統(tǒng)回歸測試中的應(yīng)用4.1 項(xiàng)目簡介e2e (end to end)是sap模塊之一，在每次更新或升級(jí)sap系統(tǒng)后都要對(duì)齊進(jìn)行回歸性功能測試。測試工具使用mercury interactive 公司的quick test professional for sap 6.0。e2e主要包括整個(gè)業(yè)務(wù)的流程：報(bào)價(jià)(quote)，合同(contract)，合同組(group contract)，開發(fā)票(invoice)，縮短售

22、后服務(wù)(short life of items)，重新開發(fā)票(re-invoice) 和信用卡付帳(credit)。還包括象收貨(delivery interface)等相關(guān)系統(tǒng)。這是最基本的一個(gè)流程，從對(duì)客戶報(bào)價(jià)到簽合同，開票，交貨和收錢一系列過程。對(duì)于sap系統(tǒng)，每個(gè)月都會(huì)進(jìn)行更新，對(duì)于每次更新都要進(jìn)行大量的測試，包括新添加的功能和原來的功能。e2e就是其中之一，每個(gè)月更新后測試其是否能按正常流程工作，能不能得出期望的結(jié)果。至于e2e的缺陷范圍也很廣，不光是編程錯(cuò)誤，還包括報(bào)價(jià)和合同能否一一對(duì)應(yīng)，開票能否成功，稅和總價(jià)是否都正確，交貨與收錢能否正確地反應(yīng)，對(duì)于售后服務(wù)縮短的操作能否實(shí)現(xiàn)等等

23、。在分析需求時(shí)，這些缺陷都要加以一一說明并驗(yàn)證。由于sap的復(fù)雜性，測試人員不可能對(duì)其完整的了解，所以在測試的各個(gè)階段，都需要專家的參與。4.2 測試需求需求分析由于現(xiàn)在對(duì)軟件測試的概念有所轉(zhuǎn)變，不再是簡單的測試。還包括對(duì)文檔的評(píng)審。文檔很重要，它關(guān)系到測試的最終效果和測試缺陷的發(fā)現(xiàn)。對(duì)文檔進(jìn)行評(píng)審時(shí)，應(yīng)包括對(duì)所要測試的功能點(diǎn)的評(píng)審，使其盡量能覆蓋所要測試的所有功能點(diǎn)。要找出測試的功能點(diǎn)，就要列出所有要測試的功能項(xiàng)，凡是沒有出現(xiàn)在這個(gè)清單里的功能項(xiàng)都排除在測試的范圍之外。需求分析必須要把客戶要求準(zhǔn)確地理解。對(duì)于e2e，必須了解其基本業(yè)務(wù)流程，也可以叫做“這個(gè)過程到底在干什么”。只有在了解的基礎(chǔ)

24、上，整理寫成文檔。文檔中應(yīng)包括： 根據(jù)需求確定測試目標(biāo) 根據(jù)需求分成不同的測試案例 定義每個(gè)測試案例的動(dòng)作 定義每個(gè)測試案例所使用的數(shù)據(jù)分析還必須對(duì)測試的資源要求，文檔、測試工具、腳本、等的存放位置，哪些要測試或不要測試（含理由），測試階段，測試策略，測試員的任務(wù)分配，測試進(jìn)度的安排和培訓(xùn)計(jì)劃等，為測試組提供了方向。同時(shí)也應(yīng)確定最終的測試報(bào)告，測試報(bào)告是反映給客戶的測試結(jié)果。所以使用的是excel形式，而且要經(jīng)過客戶的認(rèn)同才行。scenario iterations always create 2 or more quotes and link to a group contract situ

25、ations/variationsspecific data to usestep variations reprice contract (zcrp) renewal contract (zcrn) create f/l & quote header create data structure set the portfolio id to “s” for system support make sure 2 or more documents are created for each variation, for group contract functionality. billing

26、process invoice amendments short life 2 items on 1 contract within group contract in middle of settlement period credit request & credit memo process credit request/credit memo invoice next settlement period renewal/workflow use contracts created and process through workflow as standard renewal. wor

27、kflow is to create a standard system support renewal quote (that is, a blue renewal quote).表1：測試案例由表1可見，將這個(gè)流程分成五個(gè)測試案例，并確定每個(gè)測試案例所應(yīng)該做的動(dòng)作。表2：需求分析(不在自動(dòng)化測試范圍內(nèi)的部分)out-of-scope stepremarks create high level functional location an existing cle will be used, not possible to create new high-level fl when runn

28、ing scripts every time. create equipment via astro activities in amp by transaction zamp corresponding transaction codes will be used to replace the activities in zamp. verify pricing, tax, and discounts manually check scan customer po a manually check check customer doc images and printouts manuall

29、y check check dor and ei manually check check interface and sca manually check check workflow and validate quote created from workflow manually check對(duì)于測試工具來說，其對(duì)于測試結(jié)果只能進(jìn)行簡單的比較，所以有很多對(duì)于測試結(jié)果的確認(rèn)需要人工參與，表2列出了哪些人工去確認(rèn)或者有些不在測試范圍之內(nèi)的部分。4.3 創(chuàng)建測試案例根據(jù)需求分析，需要編寫測試案例。簡單地說就是把客戶的商業(yè)描述變成測試員能看懂的描述。所以測試案例必須包括在sap中，對(duì)于每一個(gè)步驟的

30、變量使用的結(jié)果、所產(chǎn)生的結(jié)果、確定哪些數(shù)據(jù)屬于全局、哪些屬于本地表中并定義變量名。在定義數(shù)據(jù)的引用關(guān)系時(shí)，要符合規(guī)約： 對(duì)于每一個(gè)步驟的輸入數(shù)據(jù)，都要在本地或者從全局表里進(jìn)行引用。 所有輸出數(shù)據(jù)，都先輸出到本地，然后在全局表里進(jìn)行引用。 對(duì)于多個(gè)動(dòng)作需要使用的數(shù)據(jù)或者在每次測試時(shí)都要改變的數(shù)據(jù)，都要放在全局表里，并從全局表引用并加以使用。 為了方便測試報(bào)告產(chǎn)生，建立一個(gè)全局輸出表。 對(duì)于輸出的數(shù)據(jù)，必須在變量名上表明是從哪個(gè)步輸出的，以便于跟蹤。圖2：數(shù)據(jù)引用關(guān)系在編寫測試案例時(shí)，應(yīng)寫清所處的屏幕狀態(tài)，步驟，輸入數(shù)據(jù)，輸出數(shù)據(jù)。對(duì)于一些可選的步驟（也就是，可能會(huì)出現(xiàn)，可能不會(huì)出現(xiàn)的步驟）用綠色

31、加以標(biāo)注。圖3所示的是在整個(gè)測試過程中，全局預(yù)輸入變量，命名都以 gl_in_xxxxxxx(description)。對(duì)于日期更要加以注明，由于在sap系統(tǒng)中對(duì)于時(shí)間的檢查非常嚴(yán)格，關(guān)系到合同是否能生成等等。圖3：全局輸入數(shù)據(jù)表3 所示amendments的詳細(xì)測試案例。它所執(zhí)行的任務(wù)是縮短售后服務(wù)。在測試案例中每個(gè)步驟要寫得盡量詳細(xì)，這樣能確保測試人員不會(huì)因?yàn)檎`操作而導(dǎo)致測試假失敗。 表3：詳細(xì)測試案例step no.screendescriptioninputoutput000sap easy access1. transaction code set va422. click ente

32、r010change contract: initial screen1. enter corresponding data2. click entergl_out_016_contract_01020information1. click enter030change renewal/limited auth *: overview1. select item 202. menu extras technical objects3. output functional location and equipment field.4. click backgl_out_024_function_

33、location_01gl_out_024_equipment_01040change renewal/limited auth *: overview1. select item 302. menu extras technical objects3. output functional location and equipment field.4. click backgl_out_024_function_location_02gl_out_024_equipment_02050change renewal/limited auth *: overview1. select item 2

34、0 and 302. menu edit fast change of contract data060fast change - contract data1. enter corresponding data2. click copyin_reason_for_canc1gl_in_request_canc_dategl_in_receipt_date070process cancellation data1. click enter080warning1. click enter090process cancellation data2. click enter100warning2.

35、click enter110change renewal/limited auth *: overview1. click save120document lines: display messages1. click enter130create contract: initial screen1. output document number2. click backgl_out_024_changed_contract圖4：global output表的組成（部分）對(duì)于global output表（圖4)，完全是為了方便聲稱最終的測試報(bào)表。對(duì)于這個(gè)表的構(gòu)成，也應(yīng)該有相應(yīng)的說明。表中的數(shù)據(jù)

36、是從每一步所產(chǎn)生的輸出中引用過來，并說明其驗(yàn)證條件。4.4 錄制和優(yōu)化腳本由于測試案例對(duì)每個(gè)步驟的描述非常詳細(xì)，所以使錄制腳本變得非常方便。一般在錄制中只要注意以下幾個(gè)問題，就可以順利錄制腳本： 每次錄制前，檢查qtp6.0是否設(shè)置正確。對(duì)sap的master data做檢查，使其不出現(xiàn)諸如某些聯(lián)系人或某些物品不存在的現(xiàn)象。 錄制時(shí)應(yīng)做到認(rèn)真，仔細(xì)。 對(duì)于錄制中系統(tǒng)出現(xiàn)的默認(rèn)值，應(yīng)加以清除，并重新輸入。如果默認(rèn)值等于要重新輸入的值，也要重新輸入。如果某些地方應(yīng)為空，要加以清空，如果本來為空，也要按del鍵，確保qtp能重復(fù)該動(dòng)作。 測試人員錄制腳本應(yīng)一次錄制盡量完成對(duì)整個(gè)流程的錄制，不能隔天錄

37、制，會(huì)造成數(shù)據(jù)丟失。由于sap業(yè)務(wù)流程比較復(fù)雜，創(chuàng)建的腳本不可能直接執(zhí)行（比如有些數(shù)據(jù)只能執(zhí)行一次），必須要進(jìn)行修改和優(yōu)化。主要是在腳本中添加各種分支和循環(huán)結(jié)構(gòu)，將可能出現(xiàn)的步驟設(shè)置可選，修改腳本中對(duì)象的參數(shù)等。修改和優(yōu)化腳本應(yīng)主要由有經(jīng)驗(yàn)的測試員來進(jìn)行，因?yàn)檫@會(huì)涉及到大量的細(xì)節(jié)。如由于sap的改變，其gui的窗口、組件等在標(biāo)題、名稱、位置或行、列值都可能發(fā)生變化，因而要清楚如何取舍某些屬性，如何認(rèn)定屬性的類型（如強(qiáng)制性的或是可選性的），否則會(huì)產(chǎn)生各種問題。圖6是一段循環(huán)9次的腳本，功能是讀取9個(gè)不同的物品的equipment號(hào)。圖5：優(yōu)化后的腳本（部分）如圖5 active screen顯示

38、在錄制腳本的時(shí)候，屏幕的標(biāo)題是 change new/amendment quote 40248085: overview但是在下次運(yùn)行時(shí)，報(bào)價(jià)（quote）就不是40248085，所以運(yùn)行腳本時(shí)會(huì)顯示object cant identify. 對(duì)于上述情況，需要對(duì)找到該屬性，把40248085替換成0-9*8，這樣就可以匹配8個(gè)字符，這8個(gè)字符都是由0-9數(shù)字組成的（如圖6）。對(duì)于一些可能出現(xiàn)的步驟，只要把該步驟變?yōu)閛ptional step 即可。圖6：腳本優(yōu)化范例對(duì)上述測試過程的每一步都作了詳細(xì)的規(guī)定，使得測試員在組織測試時(shí)很方便地執(zhí)行腳本，順利地進(jìn)行測試。例如：對(duì)于如何確認(rèn)和報(bào)告sap

39、問題，要求測試員一旦發(fā)現(xiàn)問題，立即暫停腳本的執(zhí)行，并先根據(jù)自己經(jīng)驗(yàn)來排除腳本問題，對(duì)于是否是sap缺陷，必要時(shí)送交sap專家來盡快確定。若是需要報(bào)告的sap問題，測試員要停下腳本的執(zhí)行，按照統(tǒng)一的格式寫出缺陷報(bào)告并立即匯報(bào)，包括統(tǒng)一的命名、對(duì)問題的簡單描述、重現(xiàn)步驟或條件和出現(xiàn)問題時(shí)的gui 界面。最后跟蹤并確保問題得以解決。圖7 所示的是在sap測試中，缺陷的確認(rèn)和報(bào)告機(jī)制。除了得到sap專家確認(rèn)的缺陷外，還有很多假缺陷，它們產(chǎn)生的原因大都由于：1. 測試環(huán)境導(dǎo)致假失敗2. 應(yīng)用程序改變導(dǎo)致假失敗3. 測試錯(cuò)誤導(dǎo)致假失敗4. 重復(fù)失敗5. 測試缺陷導(dǎo)致假成功為了預(yù)防上述可能發(fā)生的情況，需要測

40、試人員非常熟悉測試工具，并做出正確的判斷，必要時(shí)，可以請(qǐng)教sap專家。圖7：缺陷確認(rèn)報(bào)告機(jī)制對(duì)于測試缺陷的跟蹤，需要測試員每天對(duì)所上報(bào)的缺陷進(jìn)行跟蹤確認(rèn)，直到缺陷被修復(fù)。4.5 完成最終測試報(bào)表把腳本global output表輸出的結(jié)果填入report 中，即生成測試報(bào)告。在測試中遇到任何問題，在sap專家的幫助下，進(jìn)行確認(rèn)并報(bào)告。表4 是一份最終報(bào)表的范例。表4：最終報(bào)表范例case purpose: the purpose of this case is to test blue contract, end-to-end process.running environment:nt1ma

41、ster data used in this scenario:color legend:auto filling/check135050457auto filling/checkmanual check by cssch5355amanual check by csscmanual check by hpsa3336a, a3499a, a3581a, a3660amanual check by hpsb3919ea, b3919ea#agl, b3920ea, b3920ea#abac1064gx, c2477sztest result:output resultinterval 1 ma

42、ster datamid level functional location:ml-b-0101-0010interval 2 quotelow level functional location 1:ll-b-0101-0010quote 1:40248605low level functional location 2:ll2b-0101-0010quote 2:40248606group contract:60025063verify channel relationship has been copied:okverify equipment is linked to quote it

43、ems:okverify sales metric code is set to n:okverify portfolio id is s:okprint quotationokcheck pdf symbol in ampokcheck pdf files created are viewableokcheck pricing, tax and discountsokcheck printoutokinterval 3 contractcontract 1 (copied from quote1)50361767contract 2 (copied from quote2)50361768v

44、alidate billing plan copied from quote:okverify channal relationship has been copied:okvalidate amp link:okverify sales metric code is set to n:okprint contractokcheck document flowokcheck pdf symbol in ampokcheck pdf files created are viewableoktest scanning customer po and pdf image in ampokcheck

45、pricing, tax and discountsokcheck printoutokinterval 4 billinginvoice420337851interval 5 amendmentscontract changed50361767exclude equipment from install baseokinterval 6 credit request/credit memo/new invoicecredit request80012815credit memo420337852new invoice420337853print credit memookvalidate n

46、ew invoice for accuracyokinterval 7 dor, ei & accountingcheck dorokcheck eiokinterval 8 delivery interfaces, im & scacheck interfacesokcheck scaokinterval 9 renewal/workflowtrigger workflow and validate new quotesok對(duì)于每個(gè)月的功能性測試的最終報(bào)表應(yīng)上報(bào)并備份在測試組的結(jié)果目錄中，以備查閱。4.6 做好腳本的配置管理對(duì)于腳本需將每次修改的腳本根據(jù)日期和修改次數(shù)命名后放在一個(gè)共享目錄中

47、，并定期備份。對(duì)腳本的數(shù)據(jù)引用作統(tǒng)一的設(shè)置，這樣測試員在不同的計(jì)算機(jī)得到新的腳本時(shí)就不必再重新設(shè)置了，減少了錯(cuò)誤，提高了效率。對(duì)于其它文件如計(jì)劃、報(bào)告等則用cvs對(duì)其進(jìn)行版本控制，并記錄與共享測試過程中發(fā)現(xiàn)的問題。問題跟蹤和規(guī)劃并建立一個(gè)合適的目錄結(jié)構(gòu)，用文檔來介紹測試中所用到的文檔、測試工具、腳本、測試對(duì)象等放在哪里，使得重復(fù)勞動(dòng)和出錯(cuò)率大幅度減少，測試效率大大提高，并使知識(shí)得以共享。對(duì)于sap系統(tǒng)，在測試中往往會(huì)遇到一些問題，而這些問題不是缺陷，只是系統(tǒng)的一些設(shè)定。比如說，對(duì)于月度結(jié)算來說，實(shí)際情況往往是一個(gè)月一次，而對(duì)于測試來說，往往一天內(nèi)都要完成；不可避免地在做結(jié)算時(shí)會(huì)出現(xiàn)錯(cuò)誤，需要設(shè)置將來好幾個(gè)月允許結(jié)算。關(guān)于這種問題需要使用文檔記錄下來，以備將來發(fā)生時(shí)可以正常修改，不需要麻煩sap專家來進(jìn)行解決，這樣可以節(jié)省測試時(shí)間。所以說，這種文檔也應(yīng)該放在cvs 中進(jìn)行版本控制，供測試員使用、學(xué)習(xí)。4.7 建立培訓(xùn)機(jī)制和腳本維護(hù)測試員要能