我的測試生活感悟

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

發(fā)表于：2023-11-18來源：未知：領測軟件測試網采編點擊數(shù)：標簽：軟件測試

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

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

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

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

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

*Caller

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

*Checker

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

*DataDefine

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

*TestFixtureBases

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

*TestCases

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

*(附加)CommonSpec

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

5.上周五去聽了一個關于軟件架構師的課程，總結一下大約有如下幾點收獲：

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

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

*政治-經濟-技術，架構師容易只看到技術上的問題，其實有時技術問題并不是最大的問題。

*架構師是參謀長，也是輔導員。有了自己的架構設計，還要將自己的架構設計描述清楚，并推動設計方案的實施。

*(概念部分)架構師的定義，分類，架構設計的過程等等。

ArtOfUnitTesting

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

1.怎么定義一個好的測試案例呢?好的測試案例應該是在N年后還能運行良好并易于維護的。

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

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

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

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

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

淘寶的接口測試白皮書

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

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

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

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

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

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