我的測試生活感悟

第第頁我的測試生活感悟我的測試生活感悟

發(fā)表于：2023-11-18來源：未知：領(lǐng)測軟件測試網(wǎng)采編點(diǎn)擊數(shù)：標(biāo)簽：軟件測試

1.真的是萬事開頭難，但我覺得更難的是，每天都堅(jiān)持做同一件事情。在不被強(qiáng)迫的情況下(如：上班、吃飯、睡覺...)，在可自由支配的時(shí)間里，現(xiàn)在我每天堅(jiān)持做的貌似只有GoogleReader。希望我的測試感悟系列也能堅(jiān)持下來。2.在做模塊的接口測試過程中

1.真的是萬事開頭難，但我覺得更難的是，每天都堅(jiān)持做同一件事情。在不被強(qiáng)迫的情況下(如：上班、吃飯、睡覺...)，在可自由支配的時(shí)間里，現(xiàn)在我每天堅(jiān)持做的貌似只有GoogleReader。希望我的（測試）感悟系列也能堅(jiān)持下來。

2.在做模塊的接口測試過程中，發(fā)現(xiàn)開發(fā)所犯的錯(cuò)誤大多是一些低級的，深刻領(lǐng)悟到：復(fù)制粘貼是代碼最大的隱患!

3.最近發(fā)現(xiàn)一個(gè)（BUG），是（開發(fā)）解析xml錯(cuò)了，導(dǎo)致有的節(jié)點(diǎn)內(nèi)容未讀上來。就這樣一個(gè)（BUG）描述，根本看不出它對產(chǎn)品有多大的影響，也許最了解的人，就是（開發(fā)）自己了。

4.寫的模塊接口測試案例多了，漸漸發(fā)現(xiàn)了一些自己的代碼風(fēng)格，也許以后可以開專題來講解一下。測試代碼和產(chǎn)品代碼是有很大區(qū)別的，測試代碼其實(shí)是有通用的一些模式的，不然就不會出現(xiàn)XUnit之類的東西。可以說XUnit也是一種風(fēng)格約束。我總結(jié)出來的自己的測試代碼都會分成以下幾個(gè)部分：

*Caller

對開發(fā)接口函數(shù)調(diào)用的包裝，使得案例有一個(gè)統(tǒng)一的入口調(diào)用開發(fā)的函數(shù)。開發(fā)接口函數(shù)變動，只需要變動我們的Caller。(封裝變化)

*Checker

對接口函數(shù)調(diào)用的驗(yàn)證方式的封裝。對被測函數(shù)的返回值檢查是最基本的，更多的時(shí)候，返回值并不能告訴你一切，返回值告訴你它做了什么，但它沒有證明給你看它確實(shí)做到了

*DataDefine

測試數(shù)據(jù)是必不可缺的，我將測試數(shù)據(jù)單獨(dú)抽離出來，方便管理和組織。

*TestFixtureBases

TestFixture的基類，這是我喜歡使用的方式，定義某一類案例的基類，它們做同樣的SetUp和TearDown，共享同樣的函數(shù)調(diào)用。

*TestCases

最終到了測試案例這一分類，如果我們把上面的四個(gè)分類都做好了，就會發(fā)現(xiàn)，測試案例都可以使用一種非常簡潔的方式來表達(dá)。在我看來，一個(gè)測試案例代碼，五行左右代碼是最優(yōu)美的。

*(附加)CommonSpec

有時(shí)候，為了讓測試案例更加容易理解，我還喜歡使用BDD的方式表述測試案例。因此，我個(gè)人可能還會有一個(gè)分類叫CommonSpec，定義的一些自然語言相關(guān)的函數(shù)?？赡苓@個(gè)并不一定適合每個(gè)人。

5.上周五去聽了一個(gè)關(guān)于軟件架構(gòu)師的課程，總結(jié)一下大約有如下幾點(diǎn)收獲：

*架構(gòu)師首先要明白真正需要解決的問題是什么。例子：老太太買梨

*一個(gè)優(yōu)秀的架構(gòu)師，必須有一套自己明確的方法論。

*政治-經(jīng)濟(jì)-技術(shù)，架構(gòu)師容易只看到技術(shù)上的問題，其實(shí)有時(shí)技術(shù)問題并不是最大的問題。

*架構(gòu)師是參謀長，也是輔導(dǎo)員。有了自己的架構(gòu)設(shè)計(jì)，還要將自己的架構(gòu)設(shè)計(jì)描述清楚，并推動設(shè)計(jì)方案的實(shí)施。

*(概念部分)架構(gòu)師的定義，分類，架構(gòu)設(shè)計(jì)的過程等等。

ArtOfUnitTesting

今天把《ArtOfUnitTesting》的前四個(gè)章節(jié)讀完了，以自己的親身經(jīng)歷，使用簡潔清晰的語言，為我們展現(xiàn)了單元測試的藝術(shù)。

1.怎么定義一個(gè)好的測試案例呢?好的測試案例應(yīng)該是在N年后還能運(yùn)行良好并易于維護(hù)的。

2.TOOD-TestabledObject-OriendedDesign。也提到了這個(gè)頗有爭議的問題，許多人認(rèn)為，增加代碼的可測性的同時(shí)，會使得代碼變得更加丑陋。而不認(rèn)為是這樣，認(rèn)為這樣的修改是另外一種面向?qū)ο?，同樣的也是?yōu)美的，這就是TOOD。

3.為了代碼的可測性增加的一些代碼，常常不希望編譯到最后的產(chǎn)品中?？梢杂泻芏噢k法，比如用宏判斷，如果使用的是.NE，還有一種辦法，就是在相應(yīng)的函數(shù)或類上面使用這個(gè)Attribute：[Conditional(DEBUG)]

4.Action-DrivenTesting與Result-DrivenTesting，兩種不同的測試流派，一種檢測行為本身，一種檢查最后結(jié)果。不能說一定誰優(yōu)誰劣，但作為（單元測試），更多的應(yīng)該是Action-DrivenTesting，因?yàn)檫@樣可以隔離一些其他外部的不穩(wěn)定因素，當(dāng)你的案例失敗時(shí)，能夠更加準(zhǔn)備的定位問題所在。(事實(shí)上，集成測試就是Result-DrivenTesting，一個(gè)很大的困惑就是集成測試案例失敗了，通常是很難馬上定位到原因的。)

5.Stubs和Mocks的區(qū)別，這兩個(gè)東西看起來幾乎是一樣的，事實(shí)上也確實(shí)很相似。但是，他們的區(qū)別也同樣明顯：Stubs不會導(dǎo)致案例失敗，而Mocks會。換成我的理解就是，Stubs是一些假的東西，它能模擬一些我們想要的結(jié)果，而Mock呢，它就是一間諜(TestSpy)，告訴我們被測代碼做了些什么，于是，我們通過Mock對象來進(jìn)行檢查。

6.OneMockPerTest，一個(gè)測試案例中，通常的模式是N個(gè)Stub對應(yīng)1個(gè)Mock。如果一個(gè)測試案例有多于一個(gè)的Mock對象，說明你的案例感情不夠?qū)Ｒ?。而一個(gè)測試案例，是可以有多個(gè)Stub對象的，他們共同協(xié)作模擬一些特定的虛擬場景，然后通過Mock對象，驗(yàn)證我們的被測對象是否對此做出了反應(yīng)。

淘寶的接口測試白皮書

今天晚上回來后看到淘寶測試團(tuán)隊(duì)發(fā)出來的《接口測試白皮書》，一口氣將它讀完，寫的還是相當(dāng)不錯(cuò)的，有非常多值得借鑒和學(xué)習(xí)的地方。

1.在工作的流程上，各個(gè)測試角色是可以互補(bǔ)的，接口測試的設(shè)計(jì)、（用例）可以跟功能和性能測試共享，從而構(gòu)建出整個(gè)產(chǎn)品各個(gè)環(huán)節(jié)的測試案例覆蓋程度。

這一點(diǎn)之前感觸并不深，現(xiàn)在看來，同一產(chǎn)品的不同測試團(tuán)隊(duì)，像共享（bug）一樣，將所有人的案例都組織在一起，一起共享是一件非常值得去做的事情。

2.我們的客戶是調(diào)用接口的人，不是開發(fā)接口的人。

說的好!之前一直以為是為開發(fā)服務(wù)，看來是上面的話總結(jié)的比較好，為調(diào)用接口的人服務(wù)。

3.測試用例設(shè)計(jì)出來以后應(yīng)該經(jīng)過評審，并將評審結(jié)果以某種形式記錄下來，作為測試實(shí)施的最終方案。評審最好由以下這些人員共同參與：需求方、設(shè)計(jì)人員、開發(fā)人員、功能測試人員、接口（測試人員）