黑盒測試的總結與反思
黑盒測試總結和反思
從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