簡(jiǎn)要解析軟件測試的認識誤區 軟件測試
由于人們對于軟件質(zhì)量的重視程度越來(lái)越高，就導致了測試在軟件開(kāi)發(fā)中的地位越來(lái)越重要。測試是目前用來(lái)驗證軟件是否能夠完成所期望的功能的唯一有效的方法。在這一趨勢的引導下，現在很多軟件相關(guān)的公司都非常重視對于他們所開(kāi)發(fā)的軟件的測試，甚至不惜花費巨資購買(mǎi)商用的測試工具，但是效果卻不一定理想。究其原因主要是存在著(zhù)對于軟件測試的諸多誤解。本文試圖對一些比較普遍的關(guān)于測試的誤解進(jìn)行剖析，并且在測試對于軟件產(chǎn)品質(zhì)量可能帶來(lái)的更深遠的影響方面，也進(jìn)行了論述。
測試在軟件開(kāi)發(fā)過(guò)程中一直都是備受關(guān)注的，即使在傳統的軟件工程中，也有一個(gè)明確、獨立的測試階段。隨著(zhù)軟件危機的頻頻出現以及人們對于軟件本質(zhì)的進(jìn)一步認識，測試的地位得到了前所未有的提高。測試已經(jīng)不僅僅局限于軟件開(kāi)發(fā)中的一個(gè)階段，它已經(jīng)開(kāi)始貫穿于整個(gè)軟件開(kāi)發(fā)過(guò)程，人們已經(jīng)開(kāi)始認識到：測試開(kāi)始的時(shí)間越早，測試執行的越頻繁，所帶來(lái)的整個(gè)軟件開(kāi)發(fā)成本的下降就會(huì )越多。Extreme Programming更是把測試推到了極限的位置，一切軟件開(kāi)發(fā)活動(dòng)都要從首先編寫(xiě)測試代碼開(kāi)始。
但是，相對于測試這個(gè)詞的流行程度而言，有關(guān)測試教育方面的工作做的還遠遠不夠，很多關(guān)于測試的文章都是針對某種測試工具使用方面的，而測試工具廠(chǎng)商也往往出于商業(yè)的目的對于測試工具的作用夸大其詞。這樣，很多的軟件從業(yè)者就很容易陷入一些誤區，導致了測試并沒(méi)有在他們所在的軟件開(kāi)發(fā)項目中起到有效的作用。下面幾個(gè)小節將對于一些比較具有代表性的誤區進(jìn)行剖析，并對于測試背后所蘊含的一些設計思考進(jìn)行了闡述，希望能夠起到拋磚引玉的作用。
誤區之一：使用了測試工具，就是進(jìn)行了有效的測試
這個(gè)誤區可以說(shuō)是一種通病，幾乎每一個(gè)領(lǐng)域中的CASE工具剛剛出現時(shí)都會(huì )帶來(lái)這個(gè)問(wèn)題，比如：如果一個(gè)軟件開(kāi)發(fā)團隊在軟件的開(kāi)發(fā)中使用了Rational Rose工具來(lái)進(jìn)行UML圖的繪制，他們可能就會(huì )聲稱(chēng)他們采用了面向對象的方法，也不管他們的設計和代碼實(shí)際上是多么的過(guò)程化。
在測試領(lǐng)域中也一樣如此，一個(gè)軟件開(kāi)發(fā)團隊往往認為只要自己使用了某種軟件測試工具，那么就應該可以獲取測試帶來(lái)的種種好處，這種想法當然是錯誤的。因為，要想對一個(gè)軟件或者模塊進(jìn)行有效的測試，首先該軟件或者模塊應該是可測試的�？蓽y試性是反映軟件質(zhì)量的一個(gè)內在屬性，不會(huì )因為你使用了某種測試工具進(jìn)行了測試行為，就使得被測試的軟件具有了可測試性。如果被測試的軟件本身并不具備可測試性，那么使用多么昂貴的測試工具進(jìn)行測試所能夠帶來(lái)的收益都是微乎其微的。
巧的是，可測試性和好的軟件品質(zhì)的其他方面有天然的關(guān)聯(lián)，一個(gè)具有可測試性的軟件必然是一個(gè)強內聚、弱耦合、接口明確、意圖明晰的軟件，而不可測試的軟件往往具有過(guò)強的耦合和混亂的邏輯。關(guān)于可測試性方面更多的內容不在本文的論述范圍，請自行參見(jiàn)相關(guān)的文獻(本文所附的參考文獻中有關(guān)于可測試性的更深入的信息)。
要想真正獲取測試帶來(lái)的巨大好處，并且使得測試工具能夠發(fā)揮最大的效率，關(guān)鍵就是要使軟件本身具有很好的可測試性。這種能力的獲取是一個(gè)逐步的過(guò)程，是不可能一蹴而就的。最關(guān)鍵的一點(diǎn)就是要不斷實(shí)踐，不斷學(xué)習一些優(yōu)秀的經(jīng)驗，不斷的反思。要想獲取好的結果，就必須要付出努力，這是亙古不變的真理。Extreme Programming中的測試先行的實(shí)踐倒是一個(gè)很好的起點(diǎn)，具體可以參見(jiàn)參考文獻[3]。
對于測試工具的選擇，只要滿(mǎn)足需要并能夠自動(dòng)運行測試用例就可以了。不要一味的追求復雜的功能和不必要的靈活性。對于大多數項目來(lái)說(shuō)，一些非常著(zhù)名的源碼開(kāi)放的測試工具就足夠了，比如：Java方面的單元測試工具JUnit和C++方面的單元測試工具CppUnit。關(guān)于驗收測試方面，目前沒(méi)有比較好的滿(mǎn)足各方面需要通用的測試工具，不過(guò)使用腳本語(yǔ)言，循序漸進(jìn)的自行開(kāi)發(fā)一個(gè)適合自己的驗收測試工具也不是一件困難的事情，一句話(huà)：只有提高了自身團隊內在的素質(zhì)，外在的工具才能夠發(fā)揮作用。
誤區之二：存在太多的無(wú)法測試的東西
在軟件開(kāi)發(fā)領(lǐng)域，確實(shí)存在一些東西看起來(lái)要比另外一些東西難測試一些，但是遠非無(wú)法測試。并且在大多數的情況下，還是由于被測試的軟件本身在設計時(shí)沒(méi)有考慮到可測試性的問(wèn)題。只不過(guò)這種不可測試性不是由于被測試的軟件內部的過(guò)緊耦合造成的，而是和外部某些很難測試的部分耦合過(guò)緊，從而表現出被測試的軟件本身很難測試。這些很難測試的部分比較常見(jiàn)的有：圖形界面、硬件、數據庫等。下面以圖形界面為例進(jìn)行說(shuō)明。
如果一個(gè)軟件模塊必須要通過(guò)圖形界面才能夠觸發(fā)它的應用邏輯時(shí)，那么要對這個(gè)軟件模塊進(jìn)行測試時(shí)就必須要使用圖形界面。但是圖形界面又是很難測試的�？雌饋�(lái)好像很難辦。讓我們換一個(gè)角度考慮一下，其實(shí)我們真正想要測試的是軟件模塊本身的應用邏輯，而不是圖形界面的觸發(fā)邏輯。如果我們在設計時(shí)能夠把被測試的軟件模塊本身進(jìn)行很好的封裝，定義良好的服務(wù)提供接口，那么我們就完全可以通過(guò)軟件模塊本身提供的接口進(jìn)行測試。這樣就可以繞過(guò)難以測試的圖形界面。造成上述軟件模塊很難測試的原因正是由于在設計時(shí)把軟件模塊本身的應用邏輯和圖形界面這兩個(gè)無(wú)關(guān)的邏輯耦合在了一起。把這兩個(gè)邏輯分離，不僅可以對該軟件模塊進(jìn)行更容易、更有效的測試，而且也使得該軟件模塊具有了很好的可重用性和可移植性。
那么對于不好測試的圖形界面，我們該怎么辦呢?原則很簡(jiǎn)單，如果某種東西不好測試，那么就讓它做肯定不會(huì )出錯的事情，而把可能會(huì )出錯的邏輯剝離出來(lái)，放到一個(gè)可以測試的模塊中。對于圖形界面來(lái)說(shuō)，就是僅僅保持一個(gè)很薄的圖形界面邏輯，它的工作就是把用戶(hù)的請求簡(jiǎn)單的轉發(fā)給真正處理該請求的軟件模塊(一般稱(chēng)之為Application Facade)。轉發(fā)邏輯足夠簡(jiǎn)單以至于它肯定不會(huì )出錯，所以我們也無(wú)需對它進(jìn)行測試。關(guān)于這方面更多的信息，請參見(jiàn)參考文獻[5]。
如果在進(jìn)行軟件開(kāi)發(fā)時(shí)能夠首先編寫(xiě)測試代碼，那么就會(huì )迫使你從易使用性，易測試性的角度開(kāi)考慮問(wèn)題，從而你就會(huì )專(zhuān)注于軟件模塊的高層抽象和職責。這樣就會(huì )定義出清晰的、明確反映意圖的模塊接口來(lái)，另外，為了使得測試能夠進(jìn)行，你就會(huì )主動(dòng)把那些導致不好測試的耦合去掉。這樣的結果不僅僅是獲得了可測試性，并且也產(chǎn)生了更好的設計和系統架構。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
