黑盒測試的總結與反思
黑盒測試總結和反思
從2月初寫黑盒測試程式碼,到現在已經有超過寫了超過50個測試類、700個測試方法的程式碼,從最開始的不知道怎麼寫、為什麼寫,到後來的為什麼這樣寫、怎樣把測試寫好、思考背後的邏輯方法的執行(結合MyBatis)。在這裡寫下自己對黑盒測試的體會。
黑盒測試也稱功能測試,它是通過測試來檢測每個功能是否都能正常使用。在測試中,把程式看作一個不能開啟的黑盒子,在完全不考慮程式內部結構和內部特性的情況下,在程式介面進行測試,它只檢查程式功能是否按照需求規格說明書的規定正常使用,程式是否能適當地接收輸入資料而產生正確的輸出資訊。黑盒測試著眼於程式外部結構,不考慮內部邏輯結構,主要針對
我寫的測試是程式碼,省略了產品的頁面輸入環節,直接在程式碼上“賦值”輸入資料,下一步就呼叫已經寫好的CRUD方法對資料庫進行操作,測試的目的也是檢查每一個“方法”是否能成功執行,也就是產品的需求細節有沒有達到預期目標。
從最單一的方法說起,以在資料庫裡面新增一個數據為例:
新增銀行資料
publicvoid AddBank()
{
string token = "";
Bank bank = newBank();
bank.Abbreviation =
bank.AccessToken = "AccessToken";//fangwenlingpai
bank.AlipayFinanceAccountCode = "0001";
bank.BankCode = "0001";
bank.BankName = "中國建設銀行";
_svr.AddBank(token, bank);
}
AddBank(token, bank)方法返回值為Void,無法通過測試屬性直接檢查該銀行資料是否插入資料庫,在這種情況下,我們看似寫了測試程式碼,實際上並沒有真正的檢測出
/// 獲取銀行
///</summary>
[Test]
publicvoid GetBank()
{
string token = "";
string code = "0001";
Bank ret = _svr.GetBank(token, code);
Assert.IsNotNull(ret, "執行失敗");
}
根據銀行的唯一標識查出銀行資訊,GetBank()方法返回的是一個“銀行”物件,但由於Assert.IsNotNull(ret, "執行失敗")方法只能檢查查詢結果是否為空,也不能檢查出資料是否與原始資料相同,此時,我們可以採用一下方法來判斷資料的真實性:
//這裡的”0001”為原始資料
if (ret.AlipayFinanceAccountCode=="0001")
{
Assert.IsNotNull(ret, "執行失敗");
}
else {
ret = null;
Assert.IsNotNull(ret, "執行失敗");
}
以上是我在測試過程中總結的測試技巧,由於是黑盒測試,我們並不能看見執行過程,更不可能隨意新增測試介面,只能在現有的基礎上,儘可能的讓測試程式碼完善。但如果測試程式碼沒有相應的“查詢邏輯”,那麼插入到資料庫的資料是很難檢測到的。
當寫完一個測試類後,就可以按照分類,對資料進行測試,比如一個測試類有銀行,物業小區,居委會等模組,那麼可以給銀行類的方法新增字首“A_01”,物業類的就為“B_01”,以此類推。
以上是單一“物件”問題,但我們在測試中會經常遇到對個物件同時出現,即物件依賴問題
,比如說建立報修單:建立保修單物件需要一個eaAreaCode資料,而這個資料沒有,不管以前有沒有過eaAreaCode物件資料,都最好是自己在該測試程式碼裡面自己建立一個,如果你以前測試過eaAreaCode類的相關方法,一方面我們去找這個資料時會耽擱時間(測試資料越多越耽擱),另一方面每個測試類幾乎都有增刪查改方法,我們可能在當時測試的時候刪除了測試資料,所以哪怕就算你拿到了當時的資料,也會出現各種問題。
/// 建立報修單
///</summary>
[Test]
publicvoid A01CreateRepairOrders()
{ //建立eaAreaCode物件
EaAreaQueryParaEx queryPara = newEaAreaQueryParaEx();
var eaAreaList = _iEstateAreaBaseSvr.GetAllEaAreaList("", queryPara,true,0,100,true);
Assert.True(eaAreaList.Count > 0);
var eaArea = (EaArea)eaAreaList[0];
/*************************************************/
string token = "";
string eaAreaCode = eaArea.EaAreaCode;//"0001";
string repairContent = "abc";
AttachMentList list = newAttachMentList();
var attachMent = newAttachMent();
attachMent.KeyID = Guid.NewGuid().ToString();
attachMent.FileType = ".jpeg";
attachMent.FileName = "file.jpeg";
list.Add(attachMent);
string repPeople = "張三";
string ret = _svr.CreateRepairOrders(token, eaAreaCode, repairContent, list, repPeople);
Assert.IsNotNull(ret, "執行失敗");
}
最後來說一下資料的包含邏輯:
如圖,可以看出兩個方法之間的關係:表決物件作為表決物件列表的一個屬性儲存在列表中。在新增表決物件方法裡面,沒有把具體的儲存方法實現(這裡就檢測出方法錯誤了),而在增加列表中,只需要建立列表List,list中存的元素必為VoteObject物件(見後面的程式碼)。
public void AddVoteObjectList()
{
string token = "";
//VoteObjectList是 VoteObject 的List集合,所以List中儲存的是VoteObject物件
VoteObjectList data = new VoteObjectList();
VoteObject obj = new VoteObject();
obj.Address = "aaa";
obj.AreaName = "天府二街";
obj.BuildId = "0001";
obj.CantonCode = "0001";
obj.CreateTime = DateTime.Now;
obj.KeyId = "0001";
obj.TopicVoteId = "0001";
data.Add(obj);
_svr.AddVoteObjectList(token, data);
}
總結:在測試的時候要儘量做到測試資料的範圍廣闊,通過寫測試程式碼,不僅要測試出程式碼的問題,更要讓自己達到以下幾點目標:
1. 在專案邏輯上,能夠理解專案的模組劃分,比如銀行、街道、物業公司等模組,理清楚他們之間的聯絡,在沒有看專案說明書之前,能大致預測他們的功能,更深刻的理解專案本身;
2. 由於是黑盒測試,看不到程式碼執行的邏輯(過程),但對每一次的CRUD,結合專案所用的ORM框架,要知道邏輯是怎麼實現的,資料庫語句是怎麼寫的;
3. 要養成良好的測試習慣,每發現一次錯誤,及時記錄下來,反饋到專案組。
2018.3.5