當前位置:首頁 » 數據倉庫 » 資料庫用例設計
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

資料庫用例設計

發布時間: 2022-05-04 21:55:00

Ⅰ 如何對和資料庫交互的功能進行測試用例設計

如何對和資料庫交互的功能進行測試用例設計
1、這個界面能夠輸出(文字、圖片之類的)

2、界面後台能夠連接資料庫(crud操作)
實現上面兩點就可以實現了。 測試用例建議先做模塊單體測試,輸入數據
要涵蓋所有情況。單體測試之後集成測試。輸入大量數據 然後通過腳本測試,
根據輸出的log、輸出 判斷是否存在bug。--》之後就是該bug。循環,直到
沒有bug 或者 bug 幾乎沒有不影響

Ⅱ 資料庫課程設計實例

資料庫課程設計

題目:小型超市管理系統
1、項目計劃
1.1系統開發目的
(1)大大提高超市的運作效率;
(2)通過全面的信息採集和處理,輔助提高超市的決策水平;
(3)使用本系統,可以迅速提升超市的管理水平,為降低經營成本, 提高效益,增強超市擴張力, 提供有效的技術保障。
1.2背景說明
21世紀,超市的競爭也進入到了一個全新的領域,競爭已不再是規模的競爭,而是技術的競爭、管理的競爭、人才的競爭。技術的提升和管理的升級是超市業的競爭核心。零售領域目前呈多元發展趨勢,多種業態:超市、倉儲店、便利店、特許加盟店、專賣店、貨倉等相互並存。如何在激烈的競爭中擴大銷售額、降低經營成本、擴大經營規模,成為超市營業者努力追求的目標。
1.3項目確立
針對超市的特點,為了幫助超市解決現在面臨的問題,提高小型超市的競爭力,我們將開發以下系統:前台POS銷售系統、後台管理系統,其中這兩個子系統又包含其它一些子功能。
1.4應用范圍
本系統適應於各種小型的超市。
1.5 定義
(1)商品條形碼:每種商品具有唯一的條形碼,對於某些價格一樣的商品,可以使用自定義條形碼。
(2)交易清單:包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號。
(3)商品積壓:在一定時期內,遠無法完成銷售計劃的商品會造成積壓。
(4)促銷:在一定時期內,某些商品會按低於原價的促銷價格銷售。
庫存告警提示:當商品的庫存數量低於庫存報警數量時發出提示。
(5)盤點:計算出庫存、銷售額、盈利等經營指標。
1.6 參考資料
《資料庫原理及設計》 陶宏才編 清華大學出版社
《SQL Server 2000 實用教程》范立南編 清華大學出版社
《SQL Server 2000 編程員指南》李香敏編 北京希望電子出版社
《輕松搞定 SQL Server 2000 程序設計》Rebecca M.Riordan編
《軟體工程規范》Watts S.Humphrey編 清華大學出版社
《軟體工程理論與實踐》 Shari Lawrence Pfleeger編 清華大學出版社
《軟體需求分析》 Swapna Kishore編 機械工業出版社
《軟體工程思想》 林銳編

2、邏輯分析與詳細分析
2.1系統功能
(1)、零售前台(POS)管理系統,本系統必須具有以下功能:
 商品錄入:根據超巿業務特點制定相關功能,可以通過輸入唯一編號、掃描條形碼、商品名稱等來實現精確或模糊的商品掃描錄入。該掃描錄入方法可以充分保證各種電腦操作水平層次的人員均能准確快速地進行商品掃描錄入。
 收銀業務:通過掃描條形碼或者直接輸入商品名稱(對於同類多件商品採用一次錄入加數量的方式)自動計算本次交易的總金額。在顧客付款後,自動計算找零,同時列印交易清單(包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號)。如果顧客是本店會員並持有本人會員卡,則在交易前先掃描會員卡,並對所購物品全部實行95折優惠,並將所購物品的總金額累計到該會員的總消費金額中。 會員卡的有效期限為一年,滿一年未續卡者,該會員卡將被注銷。
 安全性:OS登陸、退出、換班與操作鎖定等許可權驗證保護;斷電自動保護最大限度防止意外及惡意非法操作。
 獨立作業:有的斷網收銀即在網路伺服器斷開或網路不通的情況下,收銀機仍能正常作業
(2)、後台管理系統,本系統必須具備以下功能
 進貨管理: 根據銷售情況及庫存情況,自動制定進貨計劃(亦可手工制定修改),可以避免盲目進貨造成商品積壓。 按計劃單有選擇性地進行自動入庫登記。 綜合查詢列印計劃進貨與入庫記錄及金額。
 銷售管理: 商品正常銷售、促銷與限量、限期及禁止銷售控制。 綜合查詢各種銷售明細記錄、各地收銀員收銀記錄以及交結賬情況等。 按多種方式統計生成銷售排行榜,靈活察看和列印商品銷售日、月、年報表。
 庫存管理: 綜合查詢庫存明細記錄。 庫存狀態自動告警提示。如庫存過剩、少貨、缺貨等。軟體為您預警,避免庫存商品積壓損失和缺貨。 庫存自動盤點計算。
 人員管理: 員工、會員、供貨商、廠商等基本信息登記管理。 員工操作許可權管理。 客戶銷售許可權管理。

(3)系統結構
系統總體結構

模塊子系統結構

功能描述:商品錄入子系統要求能快速錄入商品,因此必須支持條形碼掃描。

功能描述:收銀業務子系統能計算交易總額,列印交易清單,並根據會員卡打折。

功能描述:進貨管理子系統可以根據庫存自動指定進貨計劃,進貨時自動等級,以及提供查詢和列印計劃進貨與入庫記錄的功能。

功能描述:銷售管理子系統可以控制某商品是否允許銷售,查詢每種商品的銷售情況並產生年、月、日報表,同時可以生成銷售排行榜。

功能描述:庫存管理子系統提供查詢庫存明細記錄的基本功能,並根據庫存的狀態報警,以及自動盤點計算。

功能描述:人員管理子系統提供基本信息登記管理,員工操作許可權管理,客戶銷售許可權管理的功能。
2.2、流程圖
前台管理系統

頂層DFD圖

第0層DFD圖

第1層DFD圖

2.3、戶類型與職能
(1)、員工(營業員):
 通過商品條形碼掃描輸入商品到購買清單
 操作軟體計算交易總金額
 操作軟體輸出交易清單
 對會員進行會員卡掃描以便打折
(2)、:超市經理
 操作軟體錄入商品,供貨商,廠商
 操作軟體制定進貨計劃
 查詢列印計劃進貨與入庫記錄
 操作軟體控制商品銷售與否
 查詢列印銷售情況
 操作軟體生成銷售排行榜
 查詢庫存明細記錄
 根據軟體發出的庫存告警進行入貨
 操作軟體進行盤點計算
(3)、總經理:
 基本信息登記管理
 員工操作許可權管理
 客戶銷售許可權管理
2.4、統開發步驟
 確定參與者和相關的用況
 為每個用況設計過程
 建立順序圖,確定每個腳本中對象的協作
 創建類,確定腳本中的對象
 設計, 編碼, 測試, 集成類
 為過程編寫系統測試案例
 運行測試案例,檢驗系統
2.5、系統環境需求
 系統模式

本系統採用C/S模式作為開發模式
 硬體環境
伺服器端:
高性能的計算機一台,
普通的雙絞線作為連接。
客戶端: 普通的計算機或者工作站,
普通的雙絞線作為連接。
 軟體環境
伺服器端:安裝SQL Server 2000的伺服器版本,
安裝windows 2000伺服器版本,
配置了諾頓等必須的防毒軟體。
客戶端: 安裝SQL Server2000的伺服器版本,
安裝了VB等可視化開發工具軟體,
安裝windows2000伺服器版本。

2.6、系統安全問題
信息系統盡管功能強大,技術先進,但由於受到自身體系結構,設計思路以及運行機制等限制,也隱含許多不安全因素。常見因素有:數據的輸入,輸出,存取與備份,源程序以及應用軟體,資料庫,操作系統等漏洞或缺陷,硬體,通信部分的漏洞,企業內部人員的因素,病毒,「黑客」等因素。因此,為使本系統能夠真正安全,可靠,穩定地工作,必須考慮如下問題:為保證安全,不致使系統遭到意外事故的損害,系統因該能防止火,盜或其他形式的人為破壞。
 系統要能重建
 系統應該是可審查的
 系統應能進行有效控制,抗干擾能力強
 系統使用者的使用許可權是可識別的
3、基於UML的建模
3.1語義規則
用例模型(use cases view)(用例視圖)的基本組成部件是用例(use case)、角色(actor)和系統(system)。用例用於描述系統的功能,也就是從外部用戶的角度觀察,系統應支持哪些功能,幫助分析人員理解系統的行為,它是對系統功能的宏觀描述,一個完整的系統中通常包含若干個用例,每個用例具體說明應完成的功能,代表系統的所有基本功能(集)。角色是與系統進行交互的外部實體,它可以是系統用戶,也可以是其它系統或硬體設備,總之,凡是需要與系統交互的任何東西都可以稱作角色。系統的邊界線以內的區域(即用例的活動區域)則抽象表示系統能夠實現的所有基本功能。在一個基本功能(集)已經實現的系統中,系統運轉的大致過程是:外部角色先初始化用例,然後用例執行其所代表的功能,執行完後用例便給角色返回一些值,這個值可以是角色需要的來自系統中的任何東西。
UML:是一種標準的圖形化建模語言,它是面向對象分析與設計的一種標准表示;它不是一種可視化的程序設計語言而是一種可視化的建模語言;不是工具或知識庫的規格說明而是一種建模語言規格說明是一種表示的標准;不是過程也不是方法但允許任何一種過程和方法使用它。

用例(use case):

參與者(actor):

3.2、UML模型
3.21、系統UML模型

3.22、子系統UML模型
(1)零售前台(POS)管理系統用例視圖

(2)後台管理系統用例視圖

3.3、系統實現圖

4、超市銷售系統概念設計文檔
(1)、系統ER圖

(2)、系統ER圖說明
1) 商店中的所有用戶(員工)可以銷售多種商品,每種商品可由不同用戶(員工)銷售;
2) 每個顧客可以購買多種商品,不同商品可由不同顧客購買;
3) 每個供貨商可以供應多種不同商品,每種商品可由多個供應商供應。
(3)、視圖設計
1) 交易視圖(v_Dealing)——用於查詢交易情況的視圖;
2) 計劃進貨視圖(v_PlanStock)——用於查詢進貨計劃的視圖;
3) 銷售視圖(v_Sale)——用於查詢銷售明細記錄的視圖;
4) 入庫視圖(v_Stock)——用於查詢入庫情況的視圖。
5、邏輯設計文檔
(1)、系統關系模型
a) 商品信息表(商品編號,商品名稱,價格,條形碼,促銷價格,促銷起日期,促銷止日期,允許打折,庫存數量,庫存報警數量,計劃進貨數,允許銷售,廠商編號,供貨商編號)
b) 用戶表(用戶編號,用戶名稱,用戶密碼,用戶類型)
c) 會員表(會員編號,會員卡號,累積消費金額,注冊日期)
d) 銷售表(銷售編號,商品編號,銷售數量,銷售金額,銷售日期)
e) 交易表(交易編號,用戶名稱,交易金額,會員卡號,交易日期)
f) 進貨入庫表(入庫編號,入庫商品編號,入庫數量,單額,總額,入庫日期,計劃進貨日期,入庫狀態)
g) 供貨商表(供貨商編號,供貨商名稱,供貨商地址,供貨商電話)
h) 廠商表(廠商編號,廠商名稱,廠商地址,廠商電話)

(2)、系統資料庫表結構
資料庫表索引
表名 中文名
MerchInfo 商品信息表
User 用戶表
Menber 會員表
Sale 銷售表
Dealing 交易表
Stock 進貨入庫表
Provide 供貨商表
Factory 廠商表

商品信息表(MerchInfo)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MerchID int 4 P Not null 商品編號
MerchName Varchar 50 Not null 商品名稱
MerchPrice Money 4 Not null 價格
MerchNum Int 4 Not null 庫存數量
CautionNum Int 4 Not null 庫存報警數量
PlanNum Int 4 null 計劃進貨數
BarCode Varchar 50 Not null 條形碼
SalesProPrice Money 4 促銷價格
SalesProDateS Datetime 8 促銷起日期
SalesProDateE Datetime 8 促銷止日期
AllowAbate Int 4 Not null 允許打折
AllowSale Int 4 Not null 允許銷售
FactoryID Varchar 10 F Not null 廠商編號
ProvideID Varchar 10 F Not null 供貨商編號

用戶表(User)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
UserID varchar 10 P Not null 用戶編號
UserName Varchar 25 Not null 用戶名稱
UserPW Varchar 50 Not null 用戶密碼
UserStyle Int 4 Not null 用戶類型

會員表(Menber)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MemberID Varchar 10 P Not null 會員編號
MemberCard Varchar 20 Not null 會員卡號
TotalCost Money 4 Not null 累積消費金額
RegDate Datetime 8 Not null 注冊日期

銷售表(Sale)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
SaleID Varchar 10 P Not null 銷售編號
MerChID Varchar 10 F Not null 商品編號
SaleDate Datetime 8 Not null 銷售日期
SaleNum Int 4 Not null 銷售數量
SalePrice Money 4 Not null 銷售單額

交易表(Dealing)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
DealingID Varchar 10 P Not null 交易編號
DealingPrice Money 4 Not null 交易金額
DealingDate Money 4 Not null 交易日期
MemberID Varchar 10 會員卡號
UserName Varchar 10 F Not null 用戶名稱

入庫紀錄表(Stock)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
StockID Varchar 10 P Not null 入庫編號
MerchID Varchar 10 F Not null 入庫商品編號
MerchNum Int 4 Not null 入庫數量
MerchPrice Money 4 Not null 單額
TotalPrice Money 4 Not null 總額
StockDate Datetime 8 Datetime 入庫日期
PlanDate Datetime 8 Datetime 計劃進貨日期
StockState Int 4 Not null 入庫狀態

供貨商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
ProvideID varchar 10 P Not null 供貨商編號
ProvideName Varchar 50 Not null 供貨商名稱
ProvideAddress Varchar 250 供貨商地址
ProvidePhone Varchar 25 供貨商電話

廠商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
FactoryID varchar 10 P Not null 廠商編號
FactoryName Varchar 50 Not null 廠商名稱
FactoryAddress Varchar 250 廠商地址
FactoryPhone Varchar 25 廠商電話
6、物理設計文檔
/*----------創建資料庫----------*/
create database SuperMarketdb
on primary
(
name=SuperMarketdb,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.mdf',
size=100MB,
maxsize=200MB,
filegrowth=20MB
)
log on
(
name=SuperMarketlog,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.ldf',
size=60MB,
maxsize=200MB,
filegrowth=20MB
)
go

/*----------創建基本表----------*/
use [SuperMarketdb]
go
/*創建交易表*/
CREATE TABLE Dealing (
DealingID int identity(1,1) Primary key ,
DealingDate datetime NOT NULL ,
DealingPrice money NOT NULL ,
UserName varchar(25) NULL ,
MemberCard varchar(20) NULL
)
GO
/*創建廠商表*/
CREATE TABLE Factory (
FactoryID varchar(10) Primary key ,
FactoryName varchar(50) NOT NULL ,
FactoryAddress varchar(250) NULL ,
FactoryPhone varchar(50) NULL
)
GO
/*創建會員表*/
CREATE TABLE Member (
MemberID varchar(10) Primary key ,
MemberCard varchar(20) NOT NULL ,
TotalCost money NOT NULL ,
RegDate datetime NOT NULL
)
GO
/*創建商品信息表*/
CREATE TABLE MerchInfo (
MerchID int identity(1,1) Primary key ,
MerchName varchar(50) Unique NOT NULL ,
MerchPrice money NOT NULL ,
MerchNum int NOT NULL ,
CautionNum int NOT NULL ,
PlanNum int NOT NULL ,
BarCode varchar(20) Unique NOT NULL ,
SalesProPrice money NULL ,
SalesProDateS datetime NULL ,
SalesProDateE datetime NULL ,
AllowAbate int NOT NULL ,
AllowSale int NOT NULL ,
FactoryID int NOT NULL ,
ProvideID int NOT NULL
)
GO
/*創建供應商表*/
CREATE TABLE Provide (
ProvideID varchar(10) Primary key ,
ProvideName varchar(50) NOT NULL ,
ProvideAddress varchar(250) NULL ,
ProvidePhone varchar(25) NULL
)
GO
/*創建銷售表*/
CREATE TABLE Sale (
SaleID int identity(1,1) Primary key ,
MerChID int NOT NULL ,
SaleDate datetime NOT NULL ,
SaleNum int NOT NULL,
SalePrice money NOT NULL
)
GO
/*創建入庫表*/
CREATE TABLE Stock (
StockID int identity(1,1) Primary key ,
MerchID int NOT NULL ,
MerchNum int NOT NULL ,
MerchPrice money NULL ,
TotalPrice money NULL ,
PlanDate datetime NULL ,
StockDate datetime NULL,
StockState int NOT NULL
)
GO
/*創建用戶表*/
CREATE TABLE User (
UserID varchar(10) Primary key ,
UserName varchar(25) NOT NULL ,
UserPW varchar(50) NOT NULL ,
UserStyle int NOT NULL ,
)
GO

/*----------創建表間約束----------*/
/*商品信息表中廠商編號、供應商編號分別與廠商表、供應商表之間的外鍵約束*/
ALTER TABLE MerchInfo ADD
CONSTRAINT [FK_MerchInfo_Factory] FOREIGN KEY
(
[FactoryID]
) REFERENCES Factory (
[FactoryID]
),
CONSTRAINT [FK_MerchInfo_Provide] FOREIGN KEY
(
[ProvideID]
) REFERENCES Provide (
[ProvideID]
)
GO
/*銷售表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Sale ADD
CONSTRAINT [FK_Sale_MerchInfo] FOREIGN KEY
(
[MerChID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*入庫表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Stock ADD
CONSTRAINT [FK_Stock_MerchInfo] FOREIGN KEY
(
[MerchID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO

/*----------創建索引----------*/
/*在交易表上建立一個以交易編號、交易日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Dealing ON Dealing(DealingID, DealingDate)
GO
/*在商品信息表上建立一個以商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_MerchInfo ON MerchInfo(MerchID)
GO
/*在銷售表上建立一個以銷售編號、銷售日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Sale ON Sale(SaleID, SaleDate)
GO
/*在入庫表上建立一個以入庫編號、入庫日期、商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Stock ON Stock(StockID, StockDate, MerchID)
GO

/*----------創建視圖----------*/
/*創建用於查詢交易情況的視圖*/
CREATE VIEW v_Dealing
AS
SELECT DealingDate as 交易日期,
UserName as 員工名稱,
MemberCard as 會員卡號,
DealingPrice as 交易金額
FROM Dealing
GO
/*創建用於查詢進貨計劃的視圖*/
CREATE VIEW v_PlanStock
AS
SELECT Stock.StockID as SID,
MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchNum as 計劃進貨數量,
Stock.PlanDate as 計劃進貨日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=0
GO
/*創建用於查詢銷售明細記錄的視圖*/
CREATE VIEW v_Sale
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
MerchInfo.MerchPrice as 商品價格,
Sale.SalePrice as 銷售價格,
Sale.SaleNum as 銷售數量,
Sale.SaleDate as 銷售日期
FROM Sale INNER JOIN
MerchInfo ON Sale.MerChID = MerchInfo.MerchID
GO
/*創建用於查詢入庫情況的視圖*/
CREATE VIEW v_Stock
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchPrice as 入庫價格,
Stock.MerchNum as 入庫數量,
Stock.TotalPrice as 入庫總額,
Stock.StockDate as 入庫日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=1
GO

7、小結
和傳統管理模式相比較,使用本系統,毫無疑問會大大提高超市的運作效率,輔助提高超市的決策水平,管理水平,為降低經營成本, 提高效益,減少差錯,節省人力,減少顧客購物時間,增加客流量,提高顧客滿意度,增強超市擴張能力, 提供有效的技術保障。
由於開發者能力有限,加上時間倉促,本系統難免會出現一些不足之處,例如:
 本系統只適合小型超市使用,不能適合中大型超市使用;
 超市管理系統涉及范圍寬,要解決的問題多,功能復雜,實現困難,但由於限於時間,本系統只能做出其中的一部分功能;
對於以上出現的問題,我們深表歉意,如發現還有其它問題,希望老師批評指正。
請採納。

Ⅲ 資料庫應用系統設計的四個層次分別包含的內容是什麼它們屬於哪個設計階段求詳細解答,跪謝~~

  1. 表示層

負責直接跟用戶進行交互,一般也就是指系統的界面,用於數據錄入,數據顯示等。意味著只做與外觀顯示相關的工作,不屬於他的工作不用做。

概念設計

  1. 業務邏輯層

    用於做一些有效性驗證的工作,以更好地保證程序運行的健壯性。不允許指定的文本框中輸入空字元串,數據格式是否正確及數據類型驗證;用戶的許可權的合法性判斷等等

    邏輯設計

  2. 數據訪問

    就是用於專門跟資料庫進行交互。執行數據的添加、刪除、修改和顯示等。所有的數據對象只在這一層被引用。

    邏輯設計

  3. 數據持久層

    數據的組織存儲等方面的設計

    物理設計階段

    來自川理-jax-朱哥哥的回答。

Ⅳ 現在有一個界面,一個資料庫,實現的功能是界面與資料庫交互,進行增刪改查,如何設計測試用例

1、這個界面能夠輸出(文字、圖片之類的)

2、界面後台能夠連接資料庫(crud操作)
實現上面兩點就可以實現了。 測試用例建議先做模塊單體測試,輸入數據
要涵蓋所有情況。單體測試之後集成測試。輸入大量數據 然後通過腳本測試,
根據輸出的log、輸出 判斷是否存在bug。--》之後就是該bug。循環,直到
沒有bug 或者 bug 幾乎沒有不影響。

Ⅳ 高質量的軟體測試用例設計要考慮哪些方面

簡單的概括來說:首先,對於高質量的軟體測試用例設計,不僅需要考慮明確的顯性功能性需求,還要涉及兼容性方面、安全性方面和性能方面等一系列的非功能性需求,這些非功能性需求對軟體系統的質量保障也同樣有著舉足輕重的作用。
其次,測試工程師也只有在具有寬廣的知識面的前提下,才能設計出具有針對性、更易於發現問題的測試用例。最後,軟體測試的用例設計是不可窮盡的,在工作實踐中難免受制於時間成本和經濟成本的制約,所以也需要測試工程師能夠兼顧缺陷風險和研發成本之間的平衡關系。具體內容可以從黑馬程序員獲取資料進行進一步了解。

Ⅵ 如何設計一個完整的測試用例

軟體測試的W模型,就要求測試與開發同步,在開發設計需求設計說明書的時候就開始測試流程,一般情況下,討論需求設計的時候需要測試主管或者組員的參與,了解這個項目設計的總體情況。事實上,測試用例的編寫一般是在需求設計說明書定下來之後才真正的開始的。因為測試用例的內容要以需求設計說明書為依據,設計說明書上沒體現的功能,不需要在測試用例中體現。編寫測試用例(這里指功能測試用例的編寫),首先要做的就是設計測試用例的模板。每個公司都有適合自己公司用例編寫的模板,各有各的特點。測試用例的格式包括,測試用例摘要、測試用例需求編號(一個需求設計說明書可以分好幾個用例編寫)、編寫用例的日期、編寫人員、編寫日期、前置條件、准備數據等等。格式沒有固定的要求,可以根據自己測試用例設計的思路,對測試用例的格式作相應的改變。下面以一個登陸窗口為例,說說我設計登陸界面的思路和方法。我把這個測試用例分為三層結構,表單測試、邏輯判斷、業務流程。第一層,表單測試為最底層(最基礎的)。這部分的測試用例是對登陸窗口這個界面的輸入框、按鈕功能、界面等最基本功能的測試。一般來說登陸用戶名和登陸用戶密碼是輸入框的形式體現,那麼,我們需要的是針對這兩個輸入框進行功能的測試。這時,我們只要考慮這個輸入框的功能,而不需要考慮業務方面的內容。這樣,我們考慮就是這個輸入框的長度限制是多少?能否輸入特殊字元?能否輸入全形字元?當然,登陸窗口還有其他按鈕,例如登陸按鈕、退出按鈕、界面設計等,這一層的測試用例只對他們最簡單的功能的測試。我覺得這一層的測試用例對新開發項目很重要,也必須執行,因為這些是最基本的功能保證,當項目進入維護階段後,如果沒有修改就不需要執行這部分的測試了或者說把這層的用例優先順序置為最低,時間不充足的情況就不用去執行。第二層,邏輯判斷層。根據需求的設計,各功能之間的簡單邏輯聯系。以登陸窗口為例,賬號登錄,賬號和密碼必須對應才能登錄,否則登錄失敗。根據這一點,我們就可以從這個要求設計這一層測試用例。例如,賬號和密碼不一致時;賬號為空時;密碼為空時;賬號密碼對應時等等情況。輸入這些情況時,程序是作怎麼樣的邏輯控制的?控制是否正確?是否有相應的提示信息?我覺得,這一層的用例時最常規的一層,平時使用這個軟體用經常碰到的一些情況,在常規測試或修改這部分的功能之後,這一部分的測試用例也必須執行。第三層,業務流程層。這部分不關心軟體的本身的基本功能,而是關心這個軟體的業務有沒有實現,不同的需求就有不同的業務需求。以登陸窗口為例,就可能有不同的需求,可能用戶要求停用的賬號能夠登錄系統(可能要求登錄後不允許進行其他操作),也可能用戶直接要求停用的用戶賬號不準登錄系統。根據不同的業務需求,就有不同的業務流程。這樣這層的測試用例,我們就只要考慮業務需求,仍然以登錄窗口為例,我們就只要考慮刪除的用戶能否登錄?停用的用戶能否登錄?超級用戶是如何登錄的?普通用戶是何種方式登錄的?簡單的說,這層的用例只描述業務流程,不關心具體這個業務是怎麼實現的,執行這部分用例時,不要考慮哪個輸入框控制了多少長度,能否輸入空格等其他功能,因為這部分的測試需要基於上面兩層的測試用例都已經測試通過了,所以在項目維護階段或者說時間很緊迫的階段,我們只需要執行這部分的用例,保證業務能夠通暢的完成。其實個人覺得在執行這部分用例時,對包含了對基本功能的測試,一些明顯的問題應該能被發現,雖然嚴格來說測試覆蓋率很低,但是基本能達到要求。這三層的組合起來才是一個完整的測試用例。這是我個人對測試用例設計的一個思路和方法。真正設計這個測試用例的時候,可能會使用到黑盒測試用例的方法,例如等價類劃分、邊界值分析、錯誤猜測法(主要是個人經驗)、正交分解等方法針對具體情況設計測試用例。分層測試用例的思路主要來自對自動測試實現的考慮。因為我覺得,如果需要實現自動化測試就必須對測試用例進行細分,劃分得越細就越有利於自動化的實現。以上三層的劃分也並不是很全面,需要在實踐中不斷完善,例如可以增加對資料庫的部分功能的數據校驗的分析。總之,測試用例寫的細致、全面、步驟清晰,那麼無論是用手工測試的方法還是用自動化測試的方法實現,只要能完整的跑完整個測試用例,就達到了測試的目標了。

Ⅶ 做好測試用例設計工作的關鍵是什麼

1.明確測試的目標,增強測試計劃的實用性
編寫軟體測試計劃得重要目的就是使測試過程能夠發現更多的軟體缺陷,因此軟體測試計劃的價值取決於它對幫助管理測試項目,並且找出軟體潛在的缺陷。因此,軟體測試計劃中的測試范圍必須高度覆蓋功能需求,測試方法必須切實可行,測試工具並且具有較高的實用性,便於使用,生成的測試結果直觀、准確
2.堅持「5W」規則,明確內容與過程
「5W」規則指的是「What (做什麼)」、「Why (為什麼做)」、「When (何時做)」、「Where(在哪裡)」、「How (如何做)」。利用「5W」規則創建軟體測試計劃,可以幫助測試團隊理解測試的目的(Why ),明確測試的范圍和內容(What ),確定測試的開始和結束日期(When ),指出測試的方法和工具(How ),給出測試文檔和軟體的存放位置(Where )。
3.採用評審和更新機制,保證測試計劃滿足實際需求
測試計劃寫作完成後,如果沒有經過評審,直接發送給測試團隊,測試計劃內容的可能不準確或遺漏測試內容,或者軟體需求變更引起測試范圍的增減,而測試計劃的內容沒有及時更新,誤導測試執行人員。
4.分別創建測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔,把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理資料庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系,測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置,而測試詳細規格、測試用例是完成測試任務的具體戰術

Ⅷ 軟體測試用例怎麼寫,有簡單的例子嗎

本回答以ECShop前台應用中用戶注冊、用戶登陸、商品搜索等功能為例介紹測試用例設計活動。

1 用戶注冊

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

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

通過上述過程,測試工程師完成測試用例的設計工作,評審通過後等待測試版本發布,然後進行測試用例執行、跟蹤處理缺陷等活動。

Ⅸ 一個測試用例編寫要從哪些方面考慮

1. 軟體或項目的名稱

2. 軟體或項目的版本(內部版本號)

3. 功能模塊名

4. 測試用例的簡單描述,即該用例執行的目的或方法

5. 測試用例的參考信息(便於跟蹤和參考)

6. 本測試用例與其他測試用例間的依賴關系

7. 本用例的前置條件,即執行本用例必須要滿足的條件,如對資料庫的訪問許可權

8. 用例的編號(ID),如可以是 軟體名稱簡寫-功能塊簡寫-NO.。

9. 步驟號、操作步驟描述、測試數據描述

10.預期結果(這是最重要的)和實際結果(如果有BUG管理工具,這條可以省略)

11.開發人員(必須有)和測試人員(可有可無)

12.測試執行日期