BuildDatabase

在一些文檔規(guī)范嚴(yán)格的公司，實(shí)際上是同時(shí)有一份開發(fā)文檔和測試文檔的。但開發(fā)人員在整個(gè)開發(fā)過程中，并沒有參考測試文檔，所以最后就很容易造成測試階段開發(fā)人員不斷地返工，開發(fā)人員和測試人員之間矛盾尖銳。但最終80%的情況，還是開發(fā)的問題，畢竟你是做事的人，人家是檢查的人。所以為什么不從一開始，就把需求文檔、測試文檔和開發(fā)文檔合其為一呢？（當(dāng)然，分開寫，會(huì)有一些“監(jiān)督”的作用，但我始終覺得，這種監(jiān)督效率不高，投入產(chǎn)出不劃算）

?

而且我發(fā)現(xiàn)，這些測試文檔，都有一個(gè)問題：操作繁瑣不經(jīng)濟(jì)。

仍以“用戶名不能重復(fù)”為例，我看到的測試文檔大致就是這樣寫的：

以test-1112為用戶名注冊(cè)一個(gè)新用戶

再使用test-1112為用戶名進(jìn)行注冊(cè)

頁面顯示錯(cuò)誤提示：用戶名重復(fù)

……

表面上看起來沒有問題，但是如果測試次數(shù)多了的話，就會(huì)感覺每次先去注冊(cè)一個(gè)新用戶很麻煩。而且，這只是最簡單的功能，如果功能復(fù)雜，要求準(zhǔn)備的數(shù)據(jù)多/難/特殊，怎么辦？我們又講一個(gè)故事吧。

?

項(xiàng)目上線前夕，測試人手不夠，我們開發(fā)過去幫忙。我跑一個(gè)test case，跑了一個(gè)多星期！你信不信？我的問題就在于測試的這個(gè)數(shù)據(jù)做不出來。測試文檔是一步步寫清楚了的，但你這樣做不下去：權(quán)限不夠、數(shù)據(jù)已有變化、文檔模糊……到處找人問。找到懂這事的人，中途又發(fā)現(xiàn)，程序（頁面）發(fā)生了更改，有些功能跑不起來……最后一個(gè)workaround，得改數(shù)據(jù)庫，數(shù)據(jù)庫又得找DBA啊……總之，這個(gè)test case搞得雞飛狗跳，好在最后還是跑出來了——但以后（下一次）怎么辦， 我就不知道了。

?

本質(zhì)上，這種做法，測試數(shù)據(jù)是要測試人員自己“做”，或者“找”的，有很多問題。所以，從那時(shí)開始，我就在想：能不能把測試用的數(shù)據(jù)“固化”下來？讓測試人員就基本上不用“做”，或者很方便的就能“找”打測試數(shù)據(jù)。比如：“用戶名不能重復(fù)”的文檔就直接寫成：

使用test-1112為用戶名進(jìn)行注冊(cè)

頁面顯示錯(cuò)誤提示：用戶名重復(fù)

最多加一個(gè)說明：test-1112是已有用戶名，用戶名不能重復(fù)。

?

這個(gè)誘惑一直吸引著我，最后我在solution中就引入了一個(gè)BuildDatatase項(xiàng)目，專門為開發(fā)測試準(zhǔn)備數(shù)據(jù)。毫無疑問，這個(gè)決定也遭到了開發(fā)人員的抵制。因?yàn)檫@個(gè)數(shù)據(jù)也不是那么好做的，具體我們將在項(xiàng)目詳解里談。

我鐵腕推行，大概經(jīng)過了兩件事，他們慢慢的就習(xí)慣/認(rèn)同了這種做法。

?

第一件事，是任務(wù)列表頁面。開發(fā)代碼之前是寫好了的，而且已經(jīng)跑了一段時(shí)間了。我讓他為該頁面重新創(chuàng)建測試數(shù)據(jù)，他一臉不可置信：這種篩選排序，天？要準(zhǔn)備多少數(shù)據(jù)？！怎么準(zhǔn)備？代碼都寫好了，跑得好好的，有必要嗎？

我讓他先冷靜一下。然后有以下對(duì)話：

“如果你不準(zhǔn)備這些數(shù)據(jù)，你怎么保證你代碼的正確性？”我問。

“就直接在頁面上建幾個(gè)任務(wù)啊，然后跑一下。”他想了想。

“要建幾個(gè)呢？”我繼續(xù)追問。

“……”，他一時(shí)答不出來。

“隨便做幾個(gè)數(shù)據(jù)，隨便的跑一跑，然后就不管了，是吧？你以前就是這樣做的？”，我接著說，“所以我們的代碼沒有質(zhì)量。然后如果沒有專門的測試呢，就讓用戶當(dāng)免費(fèi)測試員；有測試呢，我們就把這些臟活累活扔給他們。他們一遍遍的報(bào)bug跑不過，我們還不服氣還有怨氣……為什么我們不一開始就把它做好呢？”

首先確定要做，然后再想辦法！很快我們就想到了一個(gè)辦法，反過來做：滿足所有篩選條件的任務(wù)就一條，然后逐個(gè)的減少篩選條件，每少一個(gè)篩選條件，就增加一個(gè)適格任務(wù)。這樣理下來，共計(jì)25條數(shù)據(jù)就夠了，并沒有我們想象的多。從構(gòu)思到文檔再到最后“造”完所有任務(wù)，差不多花了一個(gè)下午的時(shí)間而已。最后，戲劇性的是：出效果了！跑一遍，我們立馬發(fā)現(xiàn)了代碼里面的兩個(gè)bug。因?yàn)檫@種query查詢寫代碼的時(shí)候都“復(fù)制粘貼”的，十幾個(gè)條件，難免出錯(cuò)。如果不是這樣跑一次，這些bug不知道什么時(shí)候能冒出來——因?yàn)槲覀冏约河玫暮Y選條件比較固定的，某些篩選條件從來沒用過。所以我問他：你之前說“跑得好好的”？他只能呵呵了。

?

第二件事，是在任務(wù)編輯頁面，我們要測試父子任務(wù)關(guān)系之間的自動(dòng)化功能，這就需要比較復(fù)雜的一個(gè)“任務(wù)樹”做開發(fā)測試數(shù)據(jù)，好在我們是做了的。代碼review的時(shí)候，我在我這邊一跑，不對(duì)，就直接打回去了；過了一會(huì)，他跑過來，代碼沒問題啊？當(dāng)時(shí)我們腦子都短路，沒想到其他，就先去看代碼去了，折騰了好久。在他電腦上跑，然后又在我電腦上跑，又是設(shè)斷點(diǎn)，又是看邏輯。

后來我突然靈光一閃，“是不是數(shù)據(jù)的問題？”

“嗯，有可能。但怎么確定呢？”

“你重新BuildDatabase再跑！”

果不其然，原來他自己跑的時(shí)候改動(dòng)了數(shù)據(jù)，然后就忘了呀，一直就在已變動(dòng)的數(shù)據(jù)上跑，當(dāng)然沒問題了。虧得我們有BuildDatabase，可以隨時(shí)重建“基準(zhǔn)”數(shù)據(jù)，否則，這種問題是相當(dāng)花冤枉時(shí)間的！

這類似的情況其實(shí)很多很多，測試人員報(bào)bug之后，我估計(jì)開發(fā)人員最常用的一句臺(tái)詞就是：“我這里都能跑啊？！”所以問題80%都出在數(shù)據(jù)上——那為什么我們的數(shù)據(jù)就不能規(guī)范統(tǒng)一起來呢？

通過BuildDatabase，建立一個(gè)有序的可控的數(shù)據(jù)庫，我們才能夠在此基礎(chǔ)上進(jìn)行一系列的（測試驅(qū)動(dòng)的）文檔編寫、開發(fā)和測試活動(dòng)。所以說，BuildDatabase是“測試驅(qū)動(dòng)”的基石和保障。除此以外，BuildDatabase還可以在項(xiàng)目發(fā)布、模擬展示等方面發(fā)揮重要作用。

?

（我以前公司的集成測試環(huán)境這些，數(shù)據(jù)庫都是從生產(chǎn)環(huán)境中copy或截取的，我們需要的數(shù)據(jù)都是“自己造”，或者“自己找”的。這樣做能基本滿足開發(fā)測試需要，但中間總是很容易“出簍子”——正如我前面所說，一個(gè)test case可以跑一周。而且隨著數(shù)據(jù)增加，這個(gè)copy也越來越難啊，一次導(dǎo)幾百個(gè)G終究很累，所以好像是到了一定時(shí)候，還是得自行維護(hù)測試數(shù)據(jù)庫——但維護(hù)主要是數(shù)據(jù)結(jié)構(gòu)上的，比如增減列之類的，數(shù)據(jù)本身是無法維護(hù)的。

我很好奇，除了我的builddatabase以外，有沒有其他比較可行的辦法？歡迎大家踴躍交流！）

轉(zhuǎn)載于:https://www.cnblogs.com/zourui4271/p/4991615.html

總結(jié)

以上是生活随笔為你收集整理的创建测试数据的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。