ERP軟件測試實例及分析-01

ERP軟件測試實例及分析-01

ERP軟件測試相對于其他的軟件測試有業(yè)務(wù)流程較復(fù)雜、功能點較多、集成性較高的特點，那么ERP 是什么樣的軟件來著呢？

1.ERP軟件簡介：

企業(yè)資源計劃(Enterprise Resource Planning，ERP)即 ERP 企業(yè)資源計劃是一種先進的企業(yè)管理理念，它將企業(yè)各個方面的資源進行充分地調(diào)配和平衡，為企業(yè)提供多重解決方案，使企業(yè)在激烈的市場競爭中取得競爭的優(yōu)勢。ERP主要側(cè)重于對企業(yè)內(nèi)部人、財、物等資源的管理，并且擴展了管理范圍，它把企業(yè)需求和制造活動以及供應(yīng)商的制造資源整合在一起，形成了一個完整的供應(yīng)鏈，并且將供應(yīng)鏈上所有環(huán)節(jié)如訂單、采購、庫存、計劃、生產(chǎn)、發(fā)貨和財務(wù)等所需的所有資源進行統(tǒng)一的計劃和管理。ERP軟件的特點是業(yè)務(wù)流、數(shù)據(jù)流、資金流、管理流集成化程度高，并且各模塊聯(lián)系緊密。其主要功能包括生產(chǎn)制造控制、物流控制、財務(wù)管理、人力資源管理、設(shè)備管理、質(zhì)量管理、庫存管理等。

2.ERP軟件測試的難點：

ERP軟件是一種流程復(fù)雜、功能點多且關(guān)聯(lián)性強的系統(tǒng)。如果按照對一般應(yīng)用軟件的方法進行測試，即使耗費很大的人力、物力進行測試，保證大部分功能點都正確，也不能保證可以正常地使用，因為ERP軟件的業(yè)務(wù)流順暢、集成性高是更重要的要求。針對這樣的難點，我們將測試重點應(yīng)該放在流程正確集成上。

測試ERP軟件，要求測試人員不僅要掌握ERP業(yè)務(wù)流程和ERP管理思想，還要了解行業(yè)及企業(yè)的需求。在項目實施過程中要求測試工程師協(xié)同工作，共同來設(shè)計ERP軟件的測試用例，并進行測試。

這里我們提出以業(yè)務(wù)流和數(shù)據(jù)流為主驅(qū)動的方法設(shè)計用例。

3.ERP軟件測試實例及分析：

本實例以適用于制造業(yè)、面向訂單的生產(chǎn)方式的一類ERP軟件為例，對其基礎(chǔ)數(shù)據(jù)模塊、銷售管理模塊、計劃管理模塊、采購管理模塊、生產(chǎn)管理模塊的主要功能和基本流程測試進行介紹。實例模擬了銷售部門簽訂銷售訂單，之后轉(zhuǎn)到計劃部門對銷售訂單進行物料需求計算，采購部門和生產(chǎn)部門根據(jù)計劃部門下達的計劃進行生產(chǎn)和采購，最終完成發(fā)貨并關(guān)閉銷售訂單的基本流程。該實例采用的流程圖的方式，側(cè)重于業(yè)務(wù)流、數(shù)據(jù)流、資金流以及管理流的測試。

用例設(shè)計首先使用場景法，對系統(tǒng)運行流程進行分析，從宏觀考慮用例應(yīng)該包括的那些基本流和被選流，其次在設(shè)計具體的數(shù)據(jù)流時以業(yè)務(wù)流為驅(qū)動，結(jié)合等價類劃分、邊界值分析、因果圖等方法進行具體數(shù)據(jù)的設(shè)計。

3.1前期分析：

由于ERP軟件的流程比較復(fù)雜，如何選擇有限的有代表性的流程達到測試需求，在設(shè)計測試用例前，利用場景法對軟件的流程進行分析，通過用例場景并結(jié)合各路徑的觸發(fā)條件來確定用例應(yīng)遵從的流程。

所謂用例場景，就是在測試用例設(shè)計方法中介紹過的，通過描述流經(jīng)用例的路徑來確定測試用例的過程，這個流經(jīng)路徑要從用例開始到結(jié)束，遍歷其中所有基本流和備選流。

3.1.1業(yè)務(wù)流程圖

（圖1）

3.1.2主備選流圖

根據(jù)上面的流程圖和用戶使用手冊，我們可用歸納出一個看上去比較清晰的主備選流關(guān)系圖，如下面所示以及各路徑與觸發(fā)條件的對照表：

（圖2）

各路徑的觸發(fā)條件對照表如下（表1）：

路徑

觸發(fā)條件

基本流

庫存可用產(chǎn)品數(shù)量不滿足銷售需求

庫存可用零部件數(shù)量不能滿足生產(chǎn)要求

所采購的部件入庫質(zhì)檢全部合格

所生產(chǎn)的部件及產(chǎn)品全部合格

備選流1

庫存可用產(chǎn)品數(shù)量滿足銷售要求

備選流2

庫存可用產(chǎn)品數(shù)量不滿足銷售需求

庫存可用零部件數(shù)量能滿足生產(chǎn)需求

備選流3

庫存可用產(chǎn)品數(shù)量不滿足銷售要求

庫存可用零部件數(shù)量不滿足生產(chǎn)需求

所采購的部件入庫質(zhì)檢部分不合格

備選流4庫存可用產(chǎn)品數(shù)量不滿足銷售需

求所生產(chǎn)的部件及產(chǎn)品需要返工

備選流5

庫存可用產(chǎn)品數(shù)量不滿足銷售需求

所生產(chǎn)的部件及產(chǎn)品有廢品
3.1.3場景分析

從上面所示的路徑，可用確定不同的用例場景，從基本流開始，將基本流和備選流結(jié)合起來，可以確定各種場景（如圖2中只是列出部分的場景）。

場景路徑表（表2）

場景1

基本流；

場景2

基本流；備選流1；

場景3

基本流；備選流2；

場景4

基本流；備選流3；

場景5

基本流；備選流4；

場景6

基本流；備選流5；

場景7

基本流；備選流2；備選流4；

場景8

基本流；備選流3；備選流4；

場景9

基本流；備選流5；備選流1；

場景10

基本流；備選流2；備選流5；

場景11

基本流；備選流3；備選流5；

場景12

基本流；備選流5；備選流4；

場景13

基本流；備選流5；備選流2；備選流4；

場景14

基本流；備選流5；備選流3；備選流4；

場景15

基本流；備選流2；備選流4；備選流5；備選流3；

以上我們討論了ERP幾個子模塊之間的業(yè)務(wù)流程圖，同時模塊內(nèi)部還有較復(fù)雜的業(yè)務(wù)流程，在實際測試時我們不可能對所有流程一一驗證，這就引出一個問題：如何選擇”性價比“較高的業(yè)務(wù)流程，使它們盡量覆蓋較多的場景，然后根據(jù)所選業(yè)務(wù)流設(shè)計數(shù)據(jù)流，為了解決這個問題，我們建立了路徑觸發(fā)條件與場景關(guān)系表，如表3所示。

（表3路徑觸發(fā)條件與場景關(guān)系表）

序號

路徑觸發(fā)條件組合

覆蓋的場景

1庫存無可用產(chǎn)品數(shù)量庫存無可用零部件

所采購的部件入庫質(zhì)檢全部合格

所生產(chǎn)的部件及產(chǎn)品全部合格

場景1

2

庫存可用產(chǎn)品數(shù)量滿足銷售要求

場景2

3

庫存中有可用產(chǎn)品但不滿足銷售需求

庫存無可用零部件

所采購的部件入庫質(zhì)檢全部合格

所生產(chǎn)的部件及產(chǎn)品全部合格

場景1、場景2

4

庫存中有可用產(chǎn)品但不滿足銷售需求

庫存有可用零部件但不滿足生產(chǎn)需求

所采購的部件入庫質(zhì)檢全部合格

所生產(chǎn)的部件及產(chǎn)品全部合格

場景1、場景2、場景3

5

庫存中有可用產(chǎn)品但不滿足銷售需求

庫存有可用零部件但不滿足生產(chǎn)需求

所采購的部件入庫質(zhì)檢全部不合格

所生產(chǎn)的部件及產(chǎn)品全部合格

場景2、場景3、場景4

6

庫存中有可用產(chǎn)品但不滿足銷售需求

庫存有可用零部件打但不滿足生產(chǎn)需求

所采購的部件入庫質(zhì)檢部分不合格

所生產(chǎn)的部件及產(chǎn)品全部合格

場景1、場景2、場景3、場景4

7

庫存中有可用產(chǎn)品但不滿足銷售要求

庫存有可用零部件但不滿足生產(chǎn)需求

所采購的部件入庫質(zhì)檢部分不合格

所生產(chǎn)的部件及產(chǎn)品全部返修

場景2、場景5、場景7、場景8

8庫存中有可用產(chǎn)品但不滿足銷售要求

庫存有可用零部件但不滿足生產(chǎn)需求

所采購的部件入庫質(zhì)檢部分不合格

所生產(chǎn)的部件及產(chǎn)品全部為廢品

場景2、場景6、場景10、場景11

9庫存中有可用產(chǎn)品但不滿足銷售需求

庫存有可用零部件但不滿足生產(chǎn)需求

所采購的部件入庫質(zhì)檢部分不合格

所生產(chǎn)的部件及產(chǎn)品部分為廢品，其余部分需要返修

場景2、場景5、場景6、場景7、促進、場景10、場景11

10

庫存中有可用產(chǎn)品但不滿足銷售需求

庫存有可用零部件但不滿足生產(chǎn)需求

所采購的部件入庫質(zhì)檢部分不合格

所生產(chǎn)的部件及產(chǎn)品部分為廢品，其余部分需要返修；部分合格

場景1、場景2、場景3、場景4、場景5、場景6、場景7、場景8、場景10、場景11

分析：從表3中可用看出第10組條件組合所覆蓋的場景很多，應(yīng)該按照這個組合設(shè)計案例（實際測試中可以根據(jù)軟件需求和測試需求的不同，添加或減少觸發(fā)條件），但其同時存在著優(yōu)點和缺點。

缺點：對循環(huán)執(zhí)行業(yè)務(wù)考慮得不全，如未覆蓋9、12、13、14、15，歸其原因是在于沒有考慮執(zhí)行備選流5以后的場景觸發(fā)條件。

優(yōu)點：覆蓋了全部流程分支，且可以按照實際測試需求，根據(jù)這個條件組合循環(huán)執(zhí)行案例，達到要求的場景覆蓋率。

通過以上工作我們確定了在設(shè)計該ERP軟件案例時”性比價“較高的流程，以及觸發(fā)流程所需的基本條件，這樣在準備案例的數(shù)據(jù)流時就有了”根基“，使一套測試數(shù)據(jù)能夠覆蓋盡量多的流程分支及功能點，反之，如果盲目的選擇流程進行案例設(shè)計，結(jié)果可能是重要的流程分支及功能點沒有覆蓋到，或者是雖然流程分支及功能點覆蓋到了，但進行了大量重復(fù)性勞動，造成了人力、物力的浪費。

下期我們就以表3中的第10組條件組合為列，進行案例設(shè)計。

軟件測試用例怎么寫，有簡單的例子嗎？

本回答以ECShop前臺應(yīng)用中用戶注冊、用戶登陸、商品搜索等功能為例介紹測試用例設(shè)計活動。

1 用戶注冊

用戶注冊功能需求如圖1所示。

圖1用戶注冊需求

用戶注冊需求共涉及4個輸入項和1個選擇項。針對于輸入項，利用等價類及邊界值用例設(shè)計方法進行設(shè)計，選擇項則無須設(shè)計在步驟中，在測試執(zhí)行時分別執(zhí)行勾選與不勾選即可。

01.用戶名

用戶名共有三個條件：必填、不少于3個字符、不能重復(fù)，分別構(gòu)造有效等價類及無效等價類，具體如表4-1所示。

敏捷測試用例根據(jù)實際測試需要，不一定寫的非常細致，如“用戶名”包含字符類型，此處無須再劃分純字母、純漢字、特殊符號等，構(gòu)造數(shù)據(jù)時可混搭。

02.email

email有兩個條件：必填、符合規(guī)定格式，分別構(gòu)造有效等價類及無效等價類，如表4- 2所示。

03.密碼

密碼有兩個條件：必填、不少于6個字符，分別構(gòu)造有效等價類及無效等價類，如表4- 3所示。

04.確認密碼

確認密碼有兩個條件：必填、與密碼一致，分別構(gòu)造有效等價類及無效等價類，如表4- 4所示。

測試工程師利用禪道設(shè)計用例，如圖4- 5所示。

圖4- 5用戶注冊功能測試用例

2 .用戶登錄

用戶登陸需求如圖4- 6所示。

圖4- 6用戶登陸需求

用戶登陸共有三個字段：用戶名、密碼、保存登陸信息，其中用戶名、密碼為輸入框，保存登陸信息為選擇框。因該需求比較簡單，故無須分析過程，直接進行用例設(shè)計，如圖4- 7所示。

圖4- 7用戶登陸功能測試用例

3. 商品搜索

商品搜索需求如圖4- 8所示。

圖4- 8商品搜索需求

通過需求分析，商品搜索功能較為簡單，測試用例設(shè)計時只需考慮一個搜索條件的測試，測試工程師從搜索功能開發(fā)角度考慮。

對于系統(tǒng)而言，如果數(shù)據(jù)庫中存在某個關(guān)鍵字的商品，則應(yīng)該顯示，否則應(yīng)當提示沒有匹配的商品，故搜索用例設(shè)計不需要使用復(fù)雜的用例設(shè)計方法，測試工程師只需根據(jù)經(jīng)驗設(shè)計用例即可。

對于顯示方式，存在顯示方式、排序條件、排序方式三種，顯示方式又分為小圖列表、大圖列表、文字，排序條件有按上架時間、按價格、按更新時間，排序方式有升序與降序，如果完全組合則有3*3*2=18種組合，測試工程師可利用正交試驗用例設(shè)計方法進行設(shè)計。

通過分析，共有3個參數(shù)，每個參數(shù)分別有3、3、2個取值，因此需選擇因子數(shù)、水平數(shù)都3，且試驗次數(shù)最少的正交表。查詢正交表，4因子3水平正交表符合條件，如表4- 5所示。

替換參數(shù)，得到表4- 6。

多余因子4舍棄不用，排序方式中的3，可使用升序或降序任意填充，由于4因子3水平表中沒有全部取2與3的情況，因此根據(jù)經(jīng)驗再補充兩條，最終得到表4- 7所示的正交表。

表4- 7優(yōu)化后的商品顯示測試組合

結(jié)合搜索條件，利用禪道設(shè)計用例如圖4- 9所示。

圖4- 9商品搜索功能測試用例

通過上述過程，測試工程師完成測試用例的設(shè)計工作，評審?fù)ㄟ^后等待測試版本發(fā)布，然后進行測試用例執(zhí)行、跟蹤處理缺陷等活動。

軟件測試用例怎么寫

1.測試用例的定義

測試用例就是設(shè)計一種情況，軟件程序在這種情況下，能夠正常運行且達到程序所設(shè)計的運行結(jié)果。如果軟件程序在這種情況下不能正常運行且反復(fù)出現(xiàn)這種問題，則可以判定軟件有缺陷，可以記錄在缺陷跟蹤系統(tǒng)中，待問題修復(fù)，新版本部署，軟件測試工程師利用同一個用例來回歸測試這個問題，確保問題被修復(fù)。

2.?測試用例設(shè)計方法

（1）等價類劃分法

（2）邊界值分析法

（3）因果圖法

（4）錯誤推薦法

（5）判定表法

（6）正交試驗法

（7）功能圖法

（8）場景法

3.?測試用例編寫

測試用例格式：用例編號、所屬模塊、用例名稱、前置條件、用例步驟、預(yù)期結(jié)果、實際結(jié)果、編寫人員、編寫時間

求軟件測試計劃的詳細案例

測試計劃
測試概述:
測試背景:
測試手段:
手工測試
測試范圍:
功能測試 界面測試 接口測試 容錯測試 安全測試 性能測試 穩(wěn)定性測試 恢復(fù)測試 配置測試 安裝測試 文檔測試 可用性測試
測試環(huán)境:
軟件環(huán)境
操作系統(tǒng)
被測軟件 其他軟件
硬件配置
PC 配置：CPU
內(nèi)存 ：1G
外部設(shè)備
測試策略:
一．功能測試
1．菜單點擊相應(yīng)標題菜單，驗證其功能是否能實現(xiàn)
2．工具欄 點擊相應(yīng)工具欄，驗證其功能是否實現(xiàn)
3．按鈕
4．快捷鍵
5.下拉框
6．單選按鈕
7. 復(fù)選按鈕
8.切換按鈕
9.編輯按鈕
10.觸發(fā)鍵：
11．鏈接：
二 .界面測試 點擊相應(yīng)按鈕是否滿足UI設(shè)計
1登陸界面
2總界面
3 輸入界面
4處理界面
5輸出界面
6提示界面
三. 容測測試 是否滿足數(shù)據(jù)庫設(shè)計要求
主鍵容錯
非空容錯
四、接口測試 點擊相應(yīng)的菜單 按鈕 工具欄按鈕 彈出相應(yīng)的接口界面，驗證其功能是否能正確實現(xiàn) 模塊之間的調(diào)用 是否滿足概要設(shè)計的要求
1.內(nèi)部接口
2.業(yè)務(wù)流程測試
3.外部接口
五、安全測試
1.應(yīng)用級安全測試
2.系統(tǒng)級安全測試 點擊相應(yīng)菜單，驗證其功能是否實現(xiàn)
六．性能側(cè)試
七．負載測試
八.穩(wěn)定性測試
九 .恢復(fù)測試
十.配置測試
十一. 安裝測試
十二.文檔測試
軟件需求 概要設(shè)計 測試計劃 測試用例 技術(shù)文檔的 質(zhì)量通過評審 來保障
在線幫助
安裝手冊
使用手冊
七.測試進度安排
工作內(nèi)容 開始時間 結(jié)束時間 責任人 提交的結(jié)果 備注
編寫測試計劃
設(shè)計發(fā)短信測試用例
設(shè)計資費測試用例
搭建測試環(huán)境
集成測試 執(zhí)行發(fā)短信測試用例
執(zhí)行資費測試用例
集成測試分析報告
系統(tǒng)測試 性能測試
恢復(fù)測試
配置測試
系統(tǒng)測試分析報告

軟件測試用例的幾種設(shè)計方法

一、等價類劃分法

所謂「等價」，就是具有相同屬性或者方法的集合，這個集合中某個個體所表現(xiàn)的特征與其他個體完全一致。

由此可知，等價類劃分就是將所有可能的輸入數(shù)據(jù)，劃分成若干個等價類，然后從每個部分中選取具有代表性的數(shù)據(jù)當做測試用例進行合理的分類，分為有效等價類和無效等價類。

例如，規(guī)定的用戶名長度區(qū)間為4～8個字，那么它的有效等價類是用戶名長度在[4,8]，無效等價類為用戶名長度大于8位，或用戶名長度小于4位。

二、邊界值

測試經(jīng)驗告訴我們，在測試有時會涉及到大量的數(shù)據(jù)，遍歷所有數(shù)據(jù)會使測試效率低下，如果是手工執(zhí)行，更加難以覆蓋所有數(shù)據(jù)。這時更有效率的做法是，先劃分等價類，再從等價類中選擇部分參數(shù)測試，邊界值是等價類所有可選參數(shù)中最容易出問題的地方，所以我們一般會選擇邊界值作為測試的重點，邊界值法的應(yīng)用步驟如下：

1.先根據(jù)等價類法劃分有效等價類和無效等價類，確定上點、離點及內(nèi)點。上點是邊界上的點，離點是離上點最近的點，內(nèi)點則是邊界有效范圍內(nèi)的任意一點。同樣以用戶名長度為4～8位為例，4和8為上點，3和9為離點，6則為內(nèi)點。

2.設(shè)計一個新的測試用例，使其盡可能地覆蓋所有尚未覆蓋的有效等價類，直到所有有效等價類完全覆蓋。

3.設(shè)計一個新的測試用例，使其僅覆蓋一個無效等價類，直到所有無效等價類都被覆蓋。

三、判定表法

判定表又稱策略表、決策表，能表示輸入條件的組合，以及與每一輸入組合對應(yīng)的動作組合。判定表法適合邏輯判斷比較復(fù)雜的場景，通過窮舉條件獲得結(jié)果，對結(jié)果再進行優(yōu)化合并，具體又明確地表達復(fù)雜地邏輯關(guān)系和多種條件組合情況。

判定表主要由條件樁和動作樁兩部分組成。條件樁是功能要滿足地所有條件，動作樁則是所有可能的操作以及產(chǎn)生的結(jié)果。

判定表能夠?qū)?fù)雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。其缺點是判定表的建立過程較煩雜，當條件過多時，需要分析的邏輯組合呈2的倍數(shù)增長。測試工程師可根據(jù)實際情況與等價類劃分法、邊界值法結(jié)合使用。

四、正交試驗法

正交試驗法是研究多因素、多水平組合的一種實驗法，它是利用正交表來對實驗進行設(shè)計，通過少數(shù)的實驗替代全面實驗。正交表中所有參與試驗的、影響試驗結(jié)果的條件成為因子，影響試驗因子的取值或輸入的成為水平。

在設(shè)計測試用例時，采用正交試驗法能夠有效地、合理地減少測試的工作量與和成本。正交試驗的一般流程包括以下幾個步驟：

1）分析測試需求，獲取因子和水平

2）根據(jù)因子和水平選擇合適的正交表

3）替換正交表中的因子和水平，獲取試驗次數(shù)

4）根據(jù)經(jīng)驗或者其他因素補充試驗次數(shù)

5）細化輸出獲得測試用例

以上是一些常見的測試用例設(shè)計方法，希望能夠解答你的問題。

軟件測試的測試用例怎么寫？

●
測試用例編號
◇
規(guī)則：編號具有唯一性、易識別性，由數(shù)字和字符組合成的字符串
◇
約定：
系統(tǒng)測試用例：產(chǎn)品編號-ST-系統(tǒng)測試項名-系統(tǒng)測試子項名-XXX
集成測試用例：產(chǎn)品編號-IT-集成測試項名-集成測試子項名-XXX
單元測試用例：產(chǎn)品編號-UT-單元測試項名-單元測試子項名-XXX
●
測試項目
◇
規(guī)則：當前測試用例所屬測試大類、被測需求、被測模塊、被測單元等
◇
約定：
系統(tǒng)測試用例測試項目：軟件需求項
如：測試手機在沒有SIM卡的情況下，可以撥打緊急電話
集成測試用例測試項目：集成后的模塊名或接口名
如：測試模塊A提供的文件接口
單元測試用例測試項目：被測試的函數(shù)名
如：測試函數(shù)int
ReadFile(char
*pszFileName)
●
測試標題
規(guī)則：測試用例的概括簡單的描述用例的出發(fā)點、關(guān)注點，原則上不能重復(fù)。
●
重要級別
規(guī)則
高：保證系統(tǒng)基本功能、核心業(yè)務(wù)、重要特性、實際使用頻率高的測試用例；
中：重要程度介于高和低之間的測試用例；
低：實際使用頻率不高、對系統(tǒng)業(yè)務(wù)功能影響不大的模塊或功能的測試用例。
●
預(yù)置條件
規(guī)則：執(zhí)行當前測試用例需要的前提條件，是后續(xù)步驟的先決條件
●
輸入
規(guī)則：用例執(zhí)行過程中需要加工的外部信息，輸入、文件、數(shù)據(jù)庫等
●
操作步驟
規(guī)則：執(zhí)行當前測試用例需要經(jīng)過的操作步驟，保證操作步驟的完整性。
●
預(yù)期輸出
規(guī)則：當前測試用例的預(yù)期輸出結(jié)果，包括返回值的內(nèi)容、界面的響應(yīng)結(jié)果、輸出結(jié)果的規(guī)則符合度等

以上就是本文全部內(nèi)容，愿我們?nèi)缁ň`放，不負韶華，學員們，加油！（來源：培訓啦 http://m.trustlankalog.com）文章共9836字