ERP功能測試最佳實踐10個步驟確保ERP系統(tǒng)的可_第1頁
ERP功能測試最佳實踐10個步驟確保ERP系統(tǒng)的可_第2頁
ERP功能測試最佳實踐10個步驟確保ERP系統(tǒng)的可_第3頁
ERP功能測試最佳實踐10個步驟確保ERP系統(tǒng)的可_第4頁
ERP功能測試最佳實踐10個步驟確保ERP系統(tǒng)的可_第5頁
已閱讀5頁,還剩6頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

1、.ERP功能測試最正確實踐 10個步驟確保ERP系統(tǒng)的可ERP功能測試最正確理論:10個步驟確保ERP系統(tǒng)的可靠性2020-05-18 21:47企業(yè)資源規(guī)劃ERP軟件應用為企業(yè)提供管理大規(guī)模關鍵業(yè)務功能的才能,包括產(chǎn)品規(guī)劃、部件采購、庫存維護、和供給商的互動交流、提供客戶效勞,以及訂單跟蹤等。有些ERP解決方案還可能包括一些財政和人力資源方面的應用模塊。盡管這些應用通常不會直接生成效益,但是它們能讓企業(yè)以一種有效的、切合實際的方式使用現(xiàn)有的客戶數(shù)據(jù),幫助合理化企業(yè)的業(yè)務活動,為企業(yè)新的和當前的客戶提供高質(zhì)量的效勞。ERP應用通常使用一個單一的、中央數(shù)據(jù)存儲器來效勞于所有的模塊。因此,當這些應

2、用產(chǎn)生了性能問題時,很有可能影響到使用同一存儲器的所有業(yè)務領域。ERP和共享數(shù)據(jù)構(gòu)造間的這種關系決定了它必須施行穩(wěn)固的測試和監(jiān)測程序才能確保企業(yè)關鍵應用的安康運行。由于業(yè)務流程交易跨越企業(yè)中的多個部門和區(qū)域,并且涉及ERP應用本身的多個模塊,因此測試ERP應用應該采用一種整體的方式。當驗證這些業(yè)務流程的功能時,關鍵在于捕獲自動化測試解決方案中的業(yè)務流程測試,用于實現(xiàn)快速的測試重復。由于ERP應用跨越多個業(yè)務領域,存在不可防止的復雜性,因此,對每個ERP應用以及每個應用發(fā)布版本展開功能測試是非常重要的。每個ERP施行中都會面臨的主要挑戰(zhàn)之一就是確保應用在上線之前能滿足所有的業(yè)務需求。關鍵在于測試

3、和驗證這些應用的運作情況是否符合設計要求。在數(shù)千個客戶施行根底上,美科利已經(jīng)編纂了一套最正確理論,來確保關鍵業(yè)務應用的功能。在下文中將詳細描繪10個關鍵步驟,使用這些步驟能為企業(yè)的關鍵ERP應用來設計和施行有效的功能測試程序步驟1:初始規(guī)劃和搜集需求在任何一個環(huán)境中,功能測試的最重要階段之一就是規(guī)劃。對于ERP應用來說,這個步驟就更為重要了,因為其中涉及環(huán)境的復雜性以及推動這些應用施行的錯綜復雜的業(yè)務需求。不完善的規(guī)劃可能導致絕望的結(jié)果和不完好的測試覆蓋面。經(jīng)過深思熟慮的規(guī)劃使您能防止一種"垃圾進,垃圾出garbage in,garbage out"的場面,使企業(yè)能衡量和最

4、大化他們的測試工作,獲取更多的投資回報ROI。許多公司購置預先打包的ERP解決方案,希望能實現(xiàn)業(yè)務管理各個領域的快速整合。然而,這種被稱之為"vanilla"的ERP打包方案必須經(jīng)過客戶定制,才能部署到它所要支持的業(yè)務中去。從邏輯上來說,搜集需求是規(guī)劃階段的起點,因為開發(fā)人員通常根據(jù)需求來定制ERP應用;測試人員使用它來測試系統(tǒng)和客戶定制工程;而最終用戶使用它進展用戶承受測試和終結(jié)測試。通過提早仔細地定義需求,測試人員可以規(guī)劃和管理那些更加注重業(yè)務需要的測試。接著,需求可以同測試和實際測試結(jié)果被識別的缺陷相結(jié)合,以全面覆蓋所有的功能測試。步驟2:定義測試目的和選擇適宜的測試

5、測試人員通過創(chuàng)立主要的測試目的,將決定所需的特定測試類型。測試目的、工程方案和團隊構(gòu)造也將從這些測試目的中形成。當功能測試一個ERP施行時,有多種不同的驗證測試需要執(zhí)行:數(shù)據(jù)映射:由于許多ERP施行和后端大機系統(tǒng)嚴密地集成在一起,因此測試ERP應用所顯示的數(shù)據(jù)和在大機系統(tǒng)中被發(fā)現(xiàn)的數(shù)據(jù)之間的數(shù)據(jù)映射是非常關鍵的。很可能在大機系統(tǒng)中隱藏著一些陳舊的或無效的數(shù)據(jù),這些數(shù)據(jù)會引起應用當中的問題。業(yè)務流程測試:應該使用測試來驗證各種業(yè)務流程是否正確運作。由于工作流對強化業(yè)務規(guī)那么來說是非常重要的,因此測試應該覆蓋整個整合系統(tǒng)中的所有導航工程和直接功能。應用的業(yè)務規(guī)那么和啟動項必須通過全面地測試,確保所

6、有規(guī)那么能被正確地執(zhí)行。權(quán)限控制系統(tǒng):ERP權(quán)限控制系統(tǒng)決定了用戶可以使用哪些信息,用戶在這些信息中可以看到哪些數(shù)據(jù)。當涉及到供給鏈和合作伙伴入口時,將會增加平安方面的考慮。從用戶界面的角度出發(fā)測試平安性可以確保嚴格執(zhí)行驗證規(guī)那么。數(shù)據(jù)驅(qū)動的測試使IT人員能使用具有不同登錄憑證的一樣腳本去驗證平安規(guī)那么?;貧w測試:每次部署一個"Code Drop"時,對位于這些程序的每個對象的功能進展回歸測試是非常重要的。這其中包括測試它的存在、功能、值等等。"code drop"指的是任何一次新的ERP應用、補丁程序和/或hot fix的發(fā)布。步驟3:定義目的,以滿足

7、測試目的當完成所有的目的定義,選擇好測試類型,接下去就要創(chuàng)立一系列的階段目的來實現(xiàn)所定義的目的。一套最普通的初始階段目的包括:分析應用功能,并識別關鍵業(yè)務流程。在一個ERP應用中的關鍵業(yè)務流程實例就是"效勞懇求"的創(chuàng)立。建立"冒煙測試",在開發(fā)周期中快速執(zhí)行該類測試。冒煙測試不應深化被測試應用的功能,而是應該測試關鍵的業(yè)務功能。例如,用戶是否可以創(chuàng)立可以和"Trouble Ticket"相應的活動。在每次正式發(fā)布形成后運行冒煙測試。著手創(chuàng)立自動化測試來降低手動運行冒煙測試的本錢。實現(xiàn)了這些初始階段目的之后,應該建立一套后續(xù)階段目的。分

8、析應用,展開功能識別,這將擴大測試范圍,涵蓋超過75%的總的應用功能數(shù)量。獲得100%的腳本自動化測試是非常困難的,因為自動化測試工具無法進展如可用性測試這樣的事宜。建立可持續(xù)運作的自動化測試,從而降低測試的工作量。步驟4:區(qū)分功能測試案例在區(qū)分測試案例時,關鍵要記住,重要的業(yè)務功能必須在應用中才能發(fā)揮作用。由于每個企業(yè)具有獨特的業(yè)務需求,大多數(shù)企業(yè)即使完成了根本的或標準的施行,也無法上線。因為那些客戶定制的區(qū)域必須經(jīng)過徹底地測試才能保證上線時功能的穩(wěn)定。ERP應用的主要優(yōu)勢之一就是能和現(xiàn)有的大機系統(tǒng)集成,來滿足必要的業(yè)務需求。再者,因為這些集成不是標準非客戶定制施行,它們必須經(jīng)過嚴格地測試。

9、最初,要防止用各種不同的方法去測試一樣的功能。開發(fā)團隊經(jīng)常會強調(diào)一個應用應具有完美架構(gòu),可以靈敏地讓用戶通過不同的方式來完成他們的日常任務。關鍵在于要經(jīng)常部署測試案例,確保需求驅(qū)動、user-path的覆蓋面。初期測試應該具有一些共有的特性:它們應該測試關鍵的業(yè)務功能。它們應該測試應用的關鍵業(yè)務流程。它們應該識別出經(jīng)客戶定制過的ERP應用的測試區(qū)域。應用功能應該穩(wěn)定,不在主要開發(fā)范圍之內(nèi)。初期測試應該是冒煙測試的候選方式。一旦初期自動化測試創(chuàng)立完成,并成功地運行后,測試目的通常會改變,測試包會擴張。這種擴張通常表現(xiàn)為在功能成熟之后,增加更多的測試到測試包中。還可以在應用問題區(qū)域,如和大機系統(tǒng)的

10、界面中增加測試,從而對該區(qū)域展開持續(xù)地檢查。步驟5:文檔記錄關鍵的業(yè)務流程當記錄那些將要成為測試腳本的業(yè)務流程時,搜集所有和測試案例相關的信息是非常重要的。每個測試案例需要具備一份和被測業(yè)務區(qū)域相關的目的說明。測試案例的目的應該是和滿足一個需求或一系列需求有關。關鍵之處還在于,要文檔記錄下邏輯步驟,在整個系統(tǒng)中執(zhí)行這些步驟可以實現(xiàn)測試的需求。由于使用測試案例可以衡量業(yè)務流程的成功與否,因此,文檔中應該指出,需要驗證哪些內(nèi)容才能保證測試的成功。除了為測試案例而展開的執(zhí)行和驗證操作外,還需要在測試案例中成功地執(zhí)行適用的數(shù)據(jù)值。這種數(shù)據(jù)可以是來自數(shù)據(jù)庫的主數(shù)據(jù)master data、或是可以憑空增加

11、的用戶創(chuàng)立輸入數(shù)據(jù)、或者在腳本創(chuàng)立之前被置入數(shù)據(jù)庫的準備數(shù)據(jù)。步驟6:開發(fā)模塊化的測試組件創(chuàng)立模塊化測試腳本是非常重要的。測試的模塊化可以使開發(fā)人員創(chuàng)立單元測試unit test,在整個系統(tǒng)完成之前,測試ERP應用模塊和模塊的定制工程。接著,被用于單元測試的模塊測試會移交給QA測試人員,他們會將模塊測試和測試包結(jié)合在一起,來滿足特定的測試目的。美科利提供一款最新的功能測試解決方案即"業(yè)務流程測試",它能幫助企業(yè)管理與業(yè)務組件和端到端流程驗證有關的所有測試案例。步驟7:建立測試實驗室建議建立一個QA測試實驗室,作為ERP應用的測試和調(diào)優(yōu)整體戰(zhàn)略的一個組成部分。在一個獨立的測試

12、實驗室中運行測試的主要優(yōu)勢在于,機器配置可以到達一種理想的狀態(tài),因此減少了由于機器配置不完善而引起的各類問題。此外,當模塊定制完成之后,開發(fā)人員和測試人員可以在新代碼發(fā)布之前,使用該實驗室來運行單元測試。步驟8:掌握和利用"冒煙測試"在大多數(shù)ERP應用中,不完善的發(fā)布浪費了大量的測試工作。通常,當開發(fā)團隊完成一個發(fā)布版本后將移交給測試團隊,接著展開為期數(shù)天的測試過程。而測試結(jié)果往往是軟件的發(fā)布版本存在重大的和根本的問題,不值得再進展深化地測試。不幸地是,當開發(fā)人員著手為該發(fā)布版本增加新的功能時,測試團隊已經(jīng)浪費了幾天的時間去發(fā)現(xiàn)其薄弱之處。改變這種情況的捷徑就是建立一種&q

13、uot;冒煙測試",它可以覆蓋關鍵的業(yè)務功能。冒煙測試結(jié)合了手動測試和自動化測試,可以在短時間內(nèi)被創(chuàng)立和運行通常在1個小時之內(nèi)。運行冒煙測試可以為開發(fā)團隊提供發(fā)布版本質(zhì)量方面的快速信息反響,幫助他們集中力量解決嚴重阻滯的問題,而不是一些新的特性。冒煙測試所利用的腳本可以從開發(fā)人員已經(jīng)創(chuàng)立的單元測試中獲取。步驟9:執(zhí)行回歸測試回歸測試包應該覆蓋關鍵的業(yè)務流程,應該在每個新的ERP應用版本發(fā)布時運行?;貧w測試不同于冒煙測試注重測試核心的業(yè)務功能,它能更加深化地測試應用的功能。正如前文所提到的,由供給商和任何定制所帶來的應用更新都可能對應用功能和性能產(chǎn)生負面影響,必須在每次發(fā)布版本之后進展

14、測試。步驟10:分析缺陷和創(chuàng)立測試報告ERP應用準備就緒的重要指標之一就是被識別的系統(tǒng)缺陷數(shù)量。在執(zhí)行測試時,測試中產(chǎn)生的失誤必須被跟蹤和分析。一種穩(wěn)固的功能測試解決方案應該能跟蹤和匯報所有存在于業(yè)務流程中的缺陷。測試團隊可以利用這類信息來衡量和管理缺陷是如何被優(yōu)先級劃分、修復、重復測試和關閉的。用全面的報告來完好記錄所有的測試流程和結(jié)果,這也是非常重要的一項工作,可以使測試團隊能正確分析測試結(jié)果,同時在將來測試中重復使用測試案例和腳本。美科利QuickTest Professional Mercury QuickTest Professional?提供功能和回歸測試自動化方面的業(yè)界最正確解決

15、方案可覆蓋每個主要的軟件應用和環(huán)境,包括來自Oracle、PeopleSoft、SAP和Sieble的ERP應用。這種新款的自動化測試解決方案采用一種關鍵詞驅(qū)動測試的理念,可以完全簡化測試的創(chuàng)立和維護。有了美科利QuickTest Professional的關鍵詞驅(qū)動方式,測試自動化專家就能通過一種和關鍵詞視圖Keyword View互一樣步的、集成的腳本和糾錯環(huán)境,進入到基層測試和目的領域中去。美科利QuickTest Professional同時滿足了技術和非技術用戶的需要。它使高質(zhì)量應用部署的過程變得更為快捷和經(jīng)濟,同時風險也更小。它和Mercury Business Process T

16、esting?美科利業(yè)務流程測試協(xié)同工作,使非技術型的對象專家subject matter expert也能參與到質(zhì)量流程中。美科利業(yè)務流程測試使對象專家無需任何編程知識,就能創(chuàng)立、數(shù)據(jù)驅(qū)動和執(zhí)行測試自動化。它降低了自動化測試維護的經(jīng)常性費用,將測試自動化和文檔記錄兩個流程合并為一。它使對象專家和業(yè)務分析人員可以根據(jù)業(yè)務流程測試框架中所定義的業(yè)務概念來衡量應用施行的質(zhì)量。ERP應用的功能測試通過使用美科利QuickTest Professional和美科利業(yè)務流程測試,QA團隊可以開發(fā)和利用統(tǒng)一的、可重復的測試流程,更快、更經(jīng)濟和更便捷地對ERP應用就緒情況提早作出決策。當初期功能測試方案完成

17、之后,測試團隊可以使用美科利解決方案來自動驗證ERP應用中所有業(yè)務交易的完好性。美科利解決方案從業(yè)務流程的角度出發(fā),展開ERP應用測試。這些解決方案通過執(zhí)行分步操作如更新庫存信息,或從供給商處定購某部分商品,就像在實際消費操作中一樣來測試ERP應用。當在測試創(chuàng)立階段捕獲了業(yè)務流程后,美科利QuickTest Professional和美科利業(yè)務流程測試將ERP業(yè)務相關信息與輸入數(shù)據(jù)互相別離。測試人員可以根據(jù)選擇列表,改變選擇項和數(shù)據(jù)條目。使用同一數(shù)據(jù)對應用展開反復測試通常不會獲得實際結(jié)果。要真實地驗證應用的功能,測試人員需要不同的數(shù)據(jù)包來模擬多個用戶的實際操作行為。美科利產(chǎn)品允許用戶直接輸入測

18、試數(shù)據(jù),或從一個數(shù)據(jù)庫中導入數(shù)據(jù),從而創(chuàng)立一個實際的、數(shù)據(jù)驅(qū)動的測試方案。通過這種方式,測試人員就能使用可變的輸入數(shù)據(jù),分析實際的ERP業(yè)務流程。打包的ERP應用通常具有很高的復雜性。創(chuàng)立一個簡單的記錄定制可能會對其它記錄或整體性能產(chǎn)生無法意料的影響。當更新發(fā)布甚至是簡單的定制更新,都需要對所有業(yè)務流程展開全面徹底地測試,而不僅僅是測試變更所發(fā)生的區(qū)域。這樣,測試人員就能衡量更新會對應用產(chǎn)生的影響,確保不會引起缺陷的產(chǎn)生。更多信息美科利解決方案使機構(gòu)能采用穩(wěn)固的功能測試程序來展開他們所有的ERP解決方案。解決方案讓整個測試團隊可以以最少的培訓,創(chuàng)立成熟的測試系列;確保在整個環(huán)境、數(shù)據(jù)包和業(yè)務流

19、程中應用功能的正確運作;并為開發(fā)人員提供全面記錄和復制缺陷的才能幫助團隊盡快修復缺陷,跟上苛刻的消費進度。想獲取更多有關美科利QuickTest Professional、美科利業(yè)務流程測試,或其它美科利效勞和解決方案的信息,請聯(lián)絡當?shù)氐拿揽评N售代表或訪問 mercury 。2功能測試功能測試是驗收測試中的主要內(nèi)容。ERP功能測試要包含以下工程:單個模塊的查詢、增加、刪除、修改、保存等操作;數(shù)據(jù)的輸入與輸出;數(shù)據(jù)處理操作,如導入、結(jié)轉(zhuǎn)等;根底數(shù)據(jù)定義的精度;計算的準確性,如倉庫的歷史庫存、當前庫存、貨位庫存是否準確;數(shù)據(jù)共享才能;身份驗證和權(quán)限管理;接口參數(shù)和系統(tǒng)控制參數(shù);單據(jù)流轉(zhuǎn)情況;狀態(tài)

20、控制,如系統(tǒng)是否對MPS在執(zhí)行MRP分解、工單下達、車間任務調(diào)度等操作前后的狀態(tài)做了標識,狀態(tài)的改變是否正確;報表的打印輸出;審批流程定義及各種審批、反審批操作;短信發(fā)送及管理;崗位及部門業(yè)務的操作,如從請購管理、采購方案到采購訂單管理,再到采購到貨管理;跨部門的業(yè)務操作,如從銷售訂單到主消費方案,從車間領料到倉庫出庫等等。ERP功能測試的用例設計要注意以下幾點:第一,測試工程的輸入域要全面。要有合法數(shù)據(jù)的輸入,也要有非法數(shù)據(jù)的輸入。如,在測試根底數(shù)據(jù)的定義時,假設規(guī)定是數(shù)字,那么既要輸入數(shù)字進展測試,也要輸入字母、空格等非數(shù)字進展測試。數(shù)字包含整數(shù)、負數(shù)、小數(shù),因此還要輸入這些不同的數(shù)字驗證

21、數(shù)字的精度。第二,劃分等價類,進步測試效率。在考慮測試域全面性的根底上,要劃分等價類,選擇有代表意義的少數(shù)用例進展測試,進步測試效率。如,假設MRP記錄有"剛形成"、"已派工""正執(zhí)行"、"已完成"四種狀態(tài),系統(tǒng)只允許對剛形成的MRP記錄做部分性修改或刪除操作,那么在測試時,將MRP記錄劃分為四類,每種狀態(tài)對應一類,每類各選一條記錄作為測試用例即可。第三,要適時利用邊界值進展測試。如"訂單預排"中一般要求預排的數(shù)量大于0,那么測試數(shù)據(jù)可以分別為0,-1,1,10000000一個非常大的正數(shù)。第四

22、,重復遞交一樣的事務。第五,不按照常規(guī)的順序執(zhí)行功能操作。第六,驗證實體關系,實體間的關系有三種:一對一,一對多,多對多。如,一個MPS對應多個MRP,一個MRP對應多個車間任務。第七,執(zhí)行正常操作,觀察輸出結(jié)果的異常性。如,刪除某條記錄對排序的影響;執(zhí)行審批后,單據(jù)的狀態(tài)是否改變。3界面測試ERP界面要符合現(xiàn)行標準和用戶習慣。軟件企業(yè)可以形成自己的特色,但要確保整個軟件風格一致。界面測試要從友好性、易操作性、美觀性、布局合理、分類科學、標題描繪準確等方面入手。測試用例的設計要重點掌握以下幾點:第一,背景和前景的顏色是否協(xié)調(diào),顏色反差是否用得恰當。第二,軟件得圖標、按鈕、對話框等外觀風格是否一

23、致,美觀效果所要求的屏幕分辨率。第三,窗口元素的布局是否合理,并保持一致。第四,各種字段標題的信息描繪是否準確。第五,快捷鍵、按鈕、鼠標等操作在軟件中是否一致。第六,窗口及報表的顯示比例和格式是否能適應用戶的預期需求。第七,誤操作引起的錯誤提示是否友好。第八,活動窗口和被選中的記錄是否高亮顯示。第九,是否有幫助信息,菜單導航能否正常執(zhí)行。第十,檢查一些特殊域和特殊控件能否運行。4性能測試性能測試主要測試軟件的運行速度和對資源的消耗。通過調(diào)整ERP所依賴的軟硬件配置、網(wǎng)絡拓補構(gòu)造、工作站點數(shù)、數(shù)據(jù)量和效勞懇求數(shù)來測試軟件的移植性、運行速率、穩(wěn)定性和可靠性。一般借助WinRunner之類的企業(yè)級自

24、動化測試工具來輔助測試,通過極限測試來分析評估軟件性能。5文檔測試文檔是軟件的重要組成部分,也是軟件質(zhì)量保證和軟件配置管理的重要內(nèi)容。文檔測試主要通過評審的方式檢查文檔的完好性、準確性、一致性、可追溯性和可理解性。ERP作為一個大規(guī)模軟件,覆蓋了企業(yè)的各種業(yè)務。它至少要具備需求定義、開發(fā)設計、測試評估、工程管理、用戶應用這五類文檔,詳細而言,應包含GB8567-88中規(guī)定的14種軟件文檔。在文檔復審時,要特別注意以下幾點:第一,要明確文檔驗收的標準,軟件企業(yè)和用戶企業(yè)要達成一致。第二,確定文檔的重要性和工程文檔需求,比方,在驗收階段,用戶文檔用戶手冊、操作手冊、維護手冊、聯(lián)機幫助文件顯得特別重要,需要認真評審。第三,檢驗文檔完好性,主要是文檔的種類和內(nèi)容的完好性。第四,檢驗文檔的一致性和可追溯性,主要是:軟件的設計描繪是否按照需求定義進展

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論