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

1、裝訂線automatic functional testing在sap系統(tǒng)中的應(yīng)用畢業(yè)設(shè)計（論文）報告紙同濟大學學士學位論文automatic functional testing在sap系統(tǒng)中的應(yīng)用本科生：學 號：導 師：專 業(yè)：軟件工程tongji universitypaper for bachelor degreeimplementation of automatic functional testing in sap systemcandidate : zhou junweiadvisor : du qingfengmajor : software engineeringmay 20

2、04【摘要】 在當今軟件開發(fā)中，軟件測試已經(jīng)越來越被人們所重視。它直接影響著軟件整個生命周期。但是軟件也出現(xiàn)了越來越龐大、復雜和靈活等新的趨勢，這就給測試帶來一系列新的問題。對于軟件的復雜，靈活，軟件測試正采用自動化測試來逐步取代軟件手工測試，這樣可以節(jié)省大量人力、物力和時間。本文主要討論對當今大型軟件進行自動化功能測試時的一些問題，并據(jù)此對測試過程的各個方面如創(chuàng)建測試計劃，設(shè)計測試案例，錄制、優(yōu)化和執(zhí)行腳本，如何確認和報告缺陷等都作了一些改進，并通過實例表明了該過程的有效性?！娟P(guān)鍵字】 自動化測試，功能測試，sap(system application product)【外文摘要】 in s

3、oftware development today, software testing as a field 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 tak

4、ing the place of manual testing, which can help to save 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 script

5、s creation, optimization and execution, test report 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 基于功

6、能性增強流程62.3 對大型軟件測試遇到的問題8第三章 對測試工具的選擇的重要性10第四章 對sap進行功能性回歸測試114.1 項目簡介114.2 需求分析114.3 創(chuàng)建測試案例134.4 錄制和優(yōu)化腳本164.5 完成最終報表194.6 做好腳本的配置管理214.7 建立培訓機制和腳本維護21總結(jié)與展望23致謝24參考文獻25第一章 概述1.1 簡介隨著計算機在越來越多的領(lǐng)域中發(fā)揮著重要的作用和計算機各種技術(shù)的發(fā)展，當今軟件的發(fā)展也出現(xiàn)了新的趨勢：越來越龐大、復雜和靈活，例如大多erp(enterprise resource planning企業(yè)資源計劃)軟件諸如：sap都將人力資源、后

7、勤管理、銷售分銷、財務(wù)管理和控制都包含在應(yīng)用范圍之內(nèi)，其各個應(yīng)用模塊之間的通訊和聯(lián)系越來越緊密，相互共享和交換的數(shù)據(jù)也越來越多，圖形用戶界面也隨之繁多而復雜。另外，為適應(yīng)市場的迅速變化，大多erp軟件都具有相當?shù)撵`活性和二次開發(fā)性。軟件的這種變化趨勢使軟件測試越來越重要，但同時也對其提出了嚴峻的挑戰(zhàn)。軟件測試在軟件生命周期中占據(jù)重要的地位，事實上，對于軟件來講，不論采用什么技術(shù)和什么方法，軟件中仍然會有錯。采用新的語言、先進的開發(fā)方式、完善的開發(fā)過程，可以減少錯誤的引入，但是不可能完全杜絕軟件中的錯誤，這些引入的錯誤需要測試來找出，軟件中的錯誤密度也需要測試來進行估計。測試是所有工程學科的基本

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

9、所和nyse，交易代碼為“sap”。第二章 功能性測試的一般流程分析2.1 軟件測試概要描述軟件測試的方法主要有兩種：黑盒測試和白盒測試。一般在進行結(jié)構(gòu)性測試時，使用白盒測試較多。白盒測試需要全面了解程序內(nèi)部邏輯結(jié)構(gòu)、對所有邏輯路徑進行測試。測試者必須檢查程序的內(nèi)部結(jié)構(gòu)，從檢查程序的邏輯著手，得出測試數(shù)據(jù)。在功能性測試時，大都采用黑盒測試。黑盒測試不需要了解程序的內(nèi)部結(jié)構(gòu)，只針對軟件界面和軟件的功能進行測試。黑盒測試只檢查程序功能是否按照需求規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)鋸而產(chǎn)生正確的輸出信息，并且保持外部信息（如數(shù)據(jù)庫或文件）的完整性。它不需要知道軟件如何運行，為什么會

10、這樣，只知道程序做什么。對于sap系統(tǒng)，每個月都要進行更新，如果使用白盒測試，要測試人員不光要懂sap系統(tǒng)，甚至要讀懂源代碼。對于每個月sap的大量測試任務(wù)來說，將要花費大量的人力、物力，再者社會上這種人才缺乏，實現(xiàn)的可能性不大。所以采用功能性回歸測試，這樣測試人員只需要懂簡單的sap知識和測試技術(shù)就可以了。由于每個月都要測試同樣的功能，為了節(jié)省人力，時間，把要測試的功能編成腳本，實現(xiàn)自動化。一般的功能性測試流程：需求分析 - 測試案例 - 測試案例執(zhí)行 - 測試結(jié)果。2.2 基于功能性增強流程測試管理者根據(jù)功能性測試的一般流程，提出了有計劃、可持續(xù)改進，功能性增強的測試過程：（圖1） 1)

11、分析測試流程, 準備分析文檔和最終報表。確認客戶的需求并準確的傳達給測試人員。目的是要從建立文檔轉(zhuǎn)移到建立工程，重點不是編寫而是計劃。其格式可有測試組自己來定義，但內(nèi)容上應(yīng)包括范圍、時間和成本方面的內(nèi)容，由于不確定的因素較多，通常需要將時間和成本要略大于實際的估計值。還要制定一個合理的測試目標。測試員、管理部門都要知道和同意這個目標。軟件測試員的目標應(yīng)該是：找出軟件缺陷，盡可能早一些，保證起得到修復，并在正確的時機結(jié)束測試。測試員不能僅滿足于找出缺陷，卻忽略了要確保其得到修復這個目的。但當測試組沒有足夠的時間、軟件不算真正的缺陷、修復的風險大大或不值得去修復時，就不需要修復軟件缺陷。測試組往往

12、希望“通過測試的軟件產(chǎn)品是沒有問題的產(chǎn)品”，因為如果不能找到錯誤，客戶就會遲早找到它們。但實際上對于測試人員來說不可能真正達到而只能盡量地接近這個目標，這個度往往是：當時間或資金不夠用的時候，就完成了測試。2) 測試案例測試案例主要包括：確定案例執(zhí)行前所需要的測試環(huán)境和先決條件；確定所要測試的目標；確定對輸入數(shù)據(jù)的要求和期望的輸出。設(shè)計測試案例時要注意：努力提高重用率，盡量減少執(zhí)行、調(diào)試和結(jié)果分析的工作量；加強測試案例的獨立性、并精確地文檔化等來加強其可維護性。好的測試案例可以極大提高測試的效率。目前的軟件是比較復雜的，客戶端服務(wù)器、瀏覽器服務(wù)器、數(shù)據(jù)通信、巨大的關(guān)系數(shù)據(jù)庫技術(shù)的利用以及規(guī)模龐

13、大，所有這一切都造成軟件的復雜性提高，以至于沒有一定基礎(chǔ)的人不可能全面地掌握它。軟件本身的復雜性和相互之間頻繁的聯(lián)系使軟件的出錯概率提高，也使測試的難度提高，給測試人員的素質(zhì)提出更高的要求。分析測試流程, 準備分析文檔和最終報表測試案例測試腳本startend測試案例編寫人員測試腳本編寫人員測試腳本工程師分析文檔詳細測試案例腳本最終報表腳本優(yōu)化 圖1：功能性測試流程另外，測試案例應(yīng)該盡可能精簡而又能達到測試目標。如果測試案例包含了很多測試步驟，就會使測試案例的復雜度大大增加，從而增加測試案例的可維護性和理解性。3) 測試腳本 錄制腳本前，測試員必須對測試工具能夠進行非常熟練的操作，否則會大大增

14、加編輯測試腳本的成本。錄制腳本之前應(yīng)該進行相應(yīng)的配置，按照測試案例錄制測試腳本，否則可能會給腳本的優(yōu)化、執(zhí)行帶來很大的麻煩，甚至要重新進行錄制。對于大型軟件，其業(yè)務(wù)流程的復雜，數(shù)據(jù)依賴很多，所以要對其進行參數(shù)化。因此要有一份文件詳細描述：什么值需要參數(shù)化，如何對全局的、過程的參數(shù)命名、傳遞和聯(lián)系。優(yōu)化腳本時可以安排兩個人一組來共同做好分支和循環(huán)，對對象屬性的取舍和設(shè)置，設(shè)置檢查點和輸出，以使腳本能按照測試案例的要求適應(yīng)各種情況。4) 對于測試結(jié)果缺陷的判斷由于使用了測試腳本，所以不可避免有一些錯誤是由測試腳本引起的，需要有經(jīng)驗的測試工程師加以區(qū)分。在報告軟件缺陷時，測試員要：a. 盡快報告軟件

15、缺陷。軟件測試員發(fā)現(xiàn)一個問題后往往滿足于發(fā)現(xiàn)了問題，而把已發(fā)現(xiàn)的問題簡單處理后放在一旁。盡快報告能使問題早點被解決，從而使中斷了的測試在同一測試周期內(nèi)能被繼續(xù)下去，可以使測試發(fā)現(xiàn)更多有意義的問題，縮短整個測試周期。b. 在軟件缺陷的描述上要簡短、易懂，有一個統(tǒng)一的格式，還要給出再現(xiàn)這個缺陷的條件或步驟，并對軟件缺陷劃分其重要性和優(yōu)先級。一個報告僅描述一個問題，因為這樣缺陷便于跟蹤和解決。c. 在報告軟件缺陷時不做評價。測試員雖然也可能猜測到問題出現(xiàn)在哪里，但測試員這么做肯定是低效的，評價不應(yīng)是測試員的責任。d. 補充完善軟件缺陷報告。測試員發(fā)現(xiàn)并記錄了大量軟件缺陷之后，要繼續(xù)監(jiān)視其修復的全過程

16、，確保軟件缺陷得以修復并最終解決，盡量縮短軟件缺陷的生命周期。2.3 對大型軟件測試遇到的問題軟件功能測試是用來驗證軟件是否具有滿足用戶需求的的功能，在軟件測試的各個階段，尤其是確認測試階段功能測試都相當重要。在軟件發(fā)布后的每次改動或升級后，也都需要對其進行回歸行功能測試以保證起原有功能無誤。測試技術(shù)主要使用動態(tài)黑盒測試技術(shù)。目前對軟件測試方法主要有手工測試和自動化測試。自動化測試與手工測試相比有著明顯的優(yōu)點，自動化測試一般更準確、更精確，具有更快的速度和更高的效率，而且測試工具不會疲勞，因此是測試技術(shù)未來的發(fā)展趨勢?，F(xiàn)在很多測試就在用自動化測試技術(shù)。為了達到更好的測試效果和節(jié)約測試成本，對軟

17、件的測試一般由獨立的測試組進行，但這對于大型軟件的測試卻非常困難。因為測試組應(yīng)該熟悉至少要理解被測試的軟件，組內(nèi)最好有一些熟悉此軟件的專家參與或作為顧問，但大型軟件卻給人們認識、了解和使用等提出了許多困難，測試組若不經(jīng)過有效的培訓很難能熟悉它，熟悉此軟件的專家成了社會上的稀缺人才。而且自動化測試在某些方面還不成熟，不能完全代替手工測試，因此在對大型軟件進行自動化測試時往往會出現(xiàn)許多困難，如：1) 制定測試案例困難。有限的人力、時間內(nèi)，測試組不可能發(fā)現(xiàn)軟件中的所有問題，軟件測試員就必須在選擇測試案例時就從廣度和深度上權(quán)衡。這就要求對被測試軟件很熟悉，否則難以制定出有效的測試案例。2) 缺陷難以確

18、認。軟件經(jīng)常變更，而目前自動化工具靈活性不足，智能化程序不高，其腳本難以及時適應(yīng)變更，這可能導致自動化失敗或造成潛在的問題。由于不熟悉被測試軟件，測試員難以把這寫腳本問題同缺陷區(qū)分開來。另外，如果測試員對自動化測試工具不熟悉也會影響測試員的判斷力。3) 腳本的變更管理和配置管理。由于自動化腳本很多都很大，往往是包含有許多文件和子文件夾的文件，而且腳本經(jīng)常要被改動，而每次改動往往會影響多個文件或文件夾，因此一般的版本控制軟件不適合管理它們，這常常導致測試員所用的腳本不是最新或不一致的情況，以致測試效果低下。4) 與技術(shù)相關(guān)的問題所有這寫問題都會導致測試員士氣低下、主動性降低、工作效率低下。本文將

19、針對測試案例制定困難、缺陷難以確認、配置管理等問題提出一個功能測試流程，并在sap系統(tǒng)的功能測試中加以應(yīng)用。第三章 對測試工具的選擇的重要性在測試中，對于測試工具的選擇也是很重要的。好的測試工具可以很好地幫助測試人員完成工作，實現(xiàn)測試自動化。測試工具選擇過程的最終目的是要證明一個工具能使測試者在自己的公司里對測試進行自動化。在選擇過程中，對測試工具可能有一大堆的需求。有些需求與測試者現(xiàn)在具有且希望用測試工具來解決或至少是減輕的測試問題有關(guān)。其他需求還包括限制工具選擇的技術(shù)和非技術(shù)原因。首先需要明確這些對工具的需求，以便有評估候選工具的依據(jù)。當然還要考慮到效益和風險，即值不值得使用測試工具，因為

20、編寫和維護測試腳本需要大量的工作量，對于長遠來說是有價值的，但是對于短期的測試是沒有多大的價值。至于風險，由于使用了測試工具，缺陷的發(fā)現(xiàn)數(shù)量肯定比手工測試發(fā)現(xiàn)缺陷的數(shù)量要少，這或多或少地影響了測試的最終結(jié)果。現(xiàn)在市面上比較好的測試工具往往都不是免費的，需要購買license，這無形中又增加了投資，所以測試組要綜合考慮以上因素，做出正確的決定，選擇既價廉又實用的測試工具。普通的測試工具能夠進行錄制，但是對于像sap這樣復雜的系統(tǒng)，普通測試工具不能滿足要求，比如，要在一個表中輸入某一項，由于輸入這項的位置時常發(fā)生變化（包括列數(shù)和行數(shù)），普通測試工具無法捕捉，甚至無法識別這個表。win runner

21、 雖然能實現(xiàn)以上功能，但是它在實際應(yīng)用中對于sap的table tree control對象的操作有誤。而qtp 6.0能滿足以上的要求，它擁有專門針對sap系統(tǒng)測試的插件。在比較了各種測試軟件后，發(fā)現(xiàn)qtp 6.0能滿足測試的需要，所以qtp6.0是最佳的選擇。第四章 qtp 6.0在sap系統(tǒng)回歸測試中的應(yīng)用4.1 項目簡介e2e (end to end)是sap模塊之一，在每次更新或升級sap系統(tǒng)后都要對齊進行回歸性功能測試。測試工具使用mercury interactive 公司的quick test professional for sap 6.0。e2e主要包括整個業(yè)務(wù)的流程：報價

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

23、和合同能否一一對應(yīng)，開票能否成功，稅和總價是否都正確，交貨與收錢能否正確地反應(yīng)，對于售后服務(wù)縮短的操作能否實現(xiàn)等等。在分析需求時，這些缺陷都要加以一一說明并驗證。由于sap的復雜性，測試人員不可能對其完整的了解，所以在測試的各個階段，都需要專家的參與。4.2 測試需求需求分析由于現(xiàn)在對軟件測試的概念有所轉(zhuǎn)變，不再是簡單的測試。還包括對文檔的評審。文檔很重要，它關(guān)系到測試的最終效果和測試缺陷的發(fā)現(xiàn)。對文檔進行評審時，應(yīng)包括對所要測試的功能點的評審，使其盡量能覆蓋所要測試的所有功能點。要找出測試的功能點，就要列出所有要測試的功能項，凡是沒有出現(xiàn)在這個清單里的功能項都排除在測試的范圍之外。需求分析必

24、須要把客戶要求準確地理解。對于e2e，必須了解其基本業(yè)務(wù)流程，也可以叫做“這個過程到底在干什么”。只有在了解的基礎(chǔ)上，整理寫成文檔。文檔中應(yīng)包括： 根據(jù)需求確定測試目標 根據(jù)需求分成不同的測試案例 定義每個測試案例的動作 定義每個測試案例所使用的數(shù)據(jù)分析還必須對測試的資源要求，文檔、測試工具、腳本、等的存放位置，哪些要測試或不要測試（含理由），測試階段，測試策略，測試員的任務(wù)分配，測試進度的安排和培訓計劃等，為測試組提供了方向。同時也應(yīng)確定最終的測試報告，測試報告是反映給客戶的測試結(jié)果。所以使用的是excel形式，而且要經(jīng)過客戶的認同才行。scenario iterations always

25、create 2 or more quotes and link to a group contract situations/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 e

26、ach variation, for group contract functionality. billing 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 crea

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

28、 used, not possible to create new high-level fl when running 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 manua

29、lly check check customer doc images and printouts manually check check dor and ei manually check check interface and sca manually check check workflow and validate quote created from workflow manually check對于測試工具來說，其對于測試結(jié)果只能進行簡單的比較，所以有很多對于測試結(jié)果的確認需要人工參與，表2列出了哪些人工去確認或者有些不在測試范圍之內(nèi)的部分。4.3 創(chuàng)建測試案例根據(jù)需求分析，需要

30、編寫測試案例。簡單地說就是把客戶的商業(yè)描述變成測試員能看懂的描述。所以測試案例必須包括在sap中，對于每一個步驟的變量使用的結(jié)果、所產(chǎn)生的結(jié)果、確定哪些數(shù)據(jù)屬于全局、哪些屬于本地表中并定義變量名。在定義數(shù)據(jù)的引用關(guān)系時，要符合規(guī)約： 對于每一個步驟的輸入數(shù)據(jù)，都要在本地或者從全局表里進行引用。 所有輸出數(shù)據(jù)，都先輸出到本地，然后在全局表里進行引用。 對于多個動作需要使用的數(shù)據(jù)或者在每次測試時都要改變的數(shù)據(jù)，都要放在全局表里，并從全局表引用并加以使用。 為了方便測試報告產(chǎn)生，建立一個全局輸出表。 對于輸出的數(shù)據(jù)，必須在變量名上表明是從哪個步輸出的，以便于跟蹤。圖2：數(shù)據(jù)引用關(guān)系在編寫測試案例時，

31、應(yīng)寫清所處的屏幕狀態(tài)，步驟，輸入數(shù)據(jù)，輸出數(shù)據(jù)。對于一些可選的步驟（也就是，可能會出現(xiàn)，可能不會出現(xiàn)的步驟）用綠色加以標注。圖3所示的是在整個測試過程中，全局預輸入變量，命名都以 gl_in_xxxxxxx(description)。對于日期更要加以注明，由于在sap系統(tǒng)中對于時間的檢查非常嚴格，關(guān)系到合同是否能生成等等。圖3：全局輸入數(shù)據(jù)表3 所示amendments的詳細測試案例。它所執(zhí)行的任務(wù)是縮短售后服務(wù)。在測試案例中每個步驟要寫得盡量詳細，這樣能確保測試人員不會因為誤操作而導致測試假失敗。 表3：詳細測試案例step no.screendescriptioninputoutput00

32、0sap easy access1. transaction code set va422. click enter010change 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 locat

33、ion and equipment field.4. click backgl_out_024_function_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_020

34、50change renewal/limited auth *: overview1. select item 20 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 ent

35、er090process cancellation data2. click enter100warning2. 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表的組成（部分）對于glo

36、bal output表（圖4)，完全是為了方便聲稱最終的測試報表。對于這個表的構(gòu)成，也應(yīng)該有相應(yīng)的說明。表中的數(shù)據(jù)是從每一步所產(chǎn)生的輸出中引用過來，并說明其驗證條件。4.4 錄制和優(yōu)化腳本由于測試案例對每個步驟的描述非常詳細，所以使錄制腳本變得非常方便。一般在錄制中只要注意以下幾個問題，就可以順利錄制腳本： 每次錄制前，檢查qtp6.0是否設(shè)置正確。對sap的master data做檢查，使其不出現(xiàn)諸如某些聯(lián)系人或某些物品不存在的現(xiàn)象。 錄制時應(yīng)做到認真，仔細。 對于錄制中系統(tǒng)出現(xiàn)的默認值，應(yīng)加以清除，并重新輸入。如果默認值等于要重新輸入的值，也要重新輸入。如果某些地方應(yīng)為空，要加以清空，如果

37、本來為空，也要按del鍵，確保qtp能重復該動作。 測試人員錄制腳本應(yīng)一次錄制盡量完成對整個流程的錄制，不能隔天錄制，會造成數(shù)據(jù)丟失。由于sap業(yè)務(wù)流程比較復雜，創(chuàng)建的腳本不可能直接執(zhí)行（比如有些數(shù)據(jù)只能執(zhí)行一次），必須要進行修改和優(yōu)化。主要是在腳本中添加各種分支和循環(huán)結(jié)構(gòu)，將可能出現(xiàn)的步驟設(shè)置可選，修改腳本中對象的參數(shù)等。修改和優(yōu)化腳本應(yīng)主要由有經(jīng)驗的測試員來進行，因為這會涉及到大量的細節(jié)。如由于sap的改變，其gui的窗口、組件等在標題、名稱、位置或行、列值都可能發(fā)生變化，因而要清楚如何取舍某些屬性，如何認定屬性的類型（如強制性的或是可選性的），否則會產(chǎn)生各種問題。圖6是一段循環(huán)9次的腳本

38、，功能是讀取9個不同的物品的equipment號。圖5：優(yōu)化后的腳本（部分）如圖5 active screen顯示在錄制腳本的時候，屏幕的標題是 change new/amendment quote 40248085: overview但是在下次運行時，報價（quote）就不是40248085，所以運行腳本時會顯示object cant identify. 對于上述情況，需要對找到該屬性，把40248085替換成0-9*8，這樣就可以匹配8個字符，這8個字符都是由0-9數(shù)字組成的（如圖6）。對于一些可能出現(xiàn)的步驟，只要把該步驟變?yōu)閛ptional step 即可。圖6：腳本優(yōu)化范例對上述測試過

39、程的每一步都作了詳細的規(guī)定，使得測試員在組織測試時很方便地執(zhí)行腳本，順利地進行測試。例如：對于如何確認和報告sap問題，要求測試員一旦發(fā)現(xiàn)問題，立即暫停腳本的執(zhí)行，并先根據(jù)自己經(jīng)驗來排除腳本問題，對于是否是sap缺陷，必要時送交sap專家來盡快確定。若是需要報告的sap問題，測試員要停下腳本的執(zhí)行，按照統(tǒng)一的格式寫出缺陷報告并立即匯報，包括統(tǒng)一的命名、對問題的簡單描述、重現(xiàn)步驟或條件和出現(xiàn)問題時的gui 界面。最后跟蹤并確保問題得以解決。圖7 所示的是在sap測試中，缺陷的確認和報告機制。除了得到sap專家確認的缺陷外，還有很多假缺陷，它們產(chǎn)生的原因大都由于：1. 測試環(huán)境導致假失敗2. 應(yīng)用

40、程序改變導致假失敗3. 測試錯誤導致假失敗4. 重復失敗5. 測試缺陷導致假成功為了預防上述可能發(fā)生的情況，需要測試人員非常熟悉測試工具，并做出正確的判斷，必要時，可以請教sap專家。圖7：缺陷確認報告機制對于測試缺陷的跟蹤，需要測試員每天對所上報的缺陷進行跟蹤確認，直到缺陷被修復。4.5 完成最終測試報表把腳本global output表輸出的結(jié)果填入report 中，即生成測試報告。在測試中遇到任何問題，在sap專家的幫助下，進行確認并報告。表4 是一份最終報表的范例。表4：最終報表范例case purpose: the purpose of this case is to test bl

41、ue contract, end-to-end process.running environment:nt1master 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#

42、abac1064gx, c2477sztest result:output resultinterval 1 master 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

43、 has been copied:okverify equipment is linked to quote items: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 fro

44、m quote1)50361767contract 2 (copied from quote2)50361768validate 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 viewabl

45、eoktest scanning customer po and pdf image in ampokcheck pricing, tax and discountsokcheck printoutokinterval 4 billinginvoice420337851interval 5 amendmentscontract changed50361767exclude equipment from install baseokinterval 6 credit request/credit memo/new invoicecredit request80012815credit memo4

46、20337852new invoice420337853print credit memookvalidate new invoice for accuracyokinterval 7 dor, ei & accountingcheck dorokcheck eiokinterval 8 delivery interfaces, im & scacheck interfacesokcheck scaokinterval 9 renewal/workflowtrigger workflow and validate new quotesok對于每個月的功能性測試的最終報表應(yīng)上報并備份在測試組的結(jié)

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