九九热这里直有精品,1区二区三区在线播放,玖玖爱在线观看资源,国产aⅴ综合网,午夜福利男女,日本亚洲欧美三级,日韩无码黄色导航,内射少妇13区,中文字幕高清网

測試在軟件開發(fā)過程中一直都是備受關(guān)注的，即使在傳統(tǒng)的軟件工程中，也有一個明確、獨立的測試階段。隨著軟件危機的頻頻出現(xiàn)以及人們對于軟件本質(zhì)的進(jìn)一步認(rèn)識，測試的地位得到了前所未有的提高。測試已經(jīng)不僅僅局限于軟件開發(fā)中的一個階段，它已經(jīng)開始貫穿于整個軟件開發(fā)過程，人們已經(jīng)開始認(rèn)識到：測試開始的時間越早，測試執(zhí)行的越頻繁，所帶來的整個軟件開發(fā)成本的下降就會越多。Extreme Programming更是把測試推到了極限的位置，一切軟件開發(fā)活動都要從首先編寫測試代碼開始。 
    由于人們對于軟件質(zhì)量的重視程度越來越高，就導(dǎo)致了測試在軟件開發(fā)中的地位越來越重要。是的，測試是目前用來驗證軟件是否能夠完成所期望的功能的唯一有效的方法。在這一趨勢的引導(dǎo)下，現(xiàn)在很多軟件相關(guān)的公司都非常重視對于他們所開發(fā)的軟件的測試，甚至不惜花費巨資購買商用的測試工具，但是效果卻不一定理想。究其原因主要是存在著對于軟件測試的諸多誤解。
    但是，相對于測試這個詞的流行程度而言，有關(guān)測試教育方面的工作做的還遠(yuǎn)遠(yuǎn)不夠，很多關(guān)于測試的文章都是針對某種測試工具使用方面的，而測試工具廠商也往往出于商業(yè)的目的對于測試工具的作用夸大其詞。這樣，很多的軟件從業(yè)者就很容易陷入一些誤區(qū)，導(dǎo)致了測試并沒有在他們所在的軟件開發(fā)項目中起到有效的作用。下面幾個小節(jié)將對于一些比較具有代表性的誤區(qū)進(jìn)行剖析，并對于測試背后所蘊含的一些設(shè)計思考進(jìn)行了闡述，希望能夠起到拋磚引玉的作用。 
誤區(qū)之一：使用了測試工具，就是進(jìn)行了有效的測試 
    這個誤區(qū)可以說是一種通病，幾乎每一個領(lǐng)域中的CASE工具剛剛出現(xiàn)時都會帶來這個問題，比如：如果一個軟件開發(fā)團(tuán)隊在軟件的開發(fā)中使用了Rational Rose工具來進(jìn)行UML圖的繪制，他們可能就會聲稱他們采用了面向?qū)ο蟮姆椒?，也不管他們的設(shè)計和代碼實際上是多么的過程化。 
    在測試領(lǐng)域中也一樣如此，一個軟件開發(fā)團(tuán)隊往往認(rèn)為只要自己使用了某種軟件測試工具，那么就應(yīng)該可以獲取測試帶來的種種好處，這種想法當(dāng)然是錯誤的。因為，要想對一個軟件或者模塊進(jìn)行有效的測試，首先該軟件或者模塊應(yīng)該是可測試的?？蓽y試性是反映軟件質(zhì)量的一個內(nèi)在屬性，不會因為你使用了某種測試工具進(jìn)行了測試行為，就使得被測試的軟件具有了可測試性。如果被測試的軟件本身并不具備可測試性，那么使用多么昂貴的測試工具進(jìn)行測試所能夠帶來的收益都是微乎其微的。 
巧的是，可測試性和好的軟件品質(zhì)的其他方面有天然的關(guān)聯(lián)，一個具有可測試性的軟件必然是一個強內(nèi)聚、弱耦合、接口明確、意圖明晰的軟件，而不可測試的軟件往往具有過強的耦合和混亂的邏輯。
    要想真正獲取測試帶來的巨大好處，并且使得測試工具能夠發(fā)揮最大的效率，關(guān)鍵就是要使軟件本身具有很好的可測試性。這種能力的獲取是一個逐步的過程，是不可能一蹴而就的。最關(guān)鍵的一點就是要不斷實踐，不斷學(xué)習(xí)一些優(yōu)秀的經(jīng)驗，不斷的反思。要想獲取好的結(jié)果，就必須要付出努力，這是亙古不變的真理。
    對于測試工具的選擇，只要滿足需要并能夠自動運行測試用例就可以了。不要一味的追求復(fù)雜的功能和不必要的靈活性。對于大多數(shù)項目來說，一些非常著名的源碼開放的測試工具就足夠了。關(guān)于驗收測試方面，目前沒有比較好的滿足各方面需要通用的測試工具，不過使用腳本語言，循序漸進(jìn)的自行開發(fā)一個適合自己的驗收測試工具也不是一件困難的事情，一句話：只有提高了自身團(tuán)隊內(nèi)在的素質(zhì)，外在的工具才能夠發(fā)揮作用。
誤區(qū)之二：存在太多的無法測試的東西 
    在軟件開發(fā)領(lǐng)域，確實存在一些東西看起來要比另外一些東西難測試一些，但是遠(yuǎn)非無法測試。并且在大多數(shù)的情況下，還是由于被測試的軟件本身在設(shè)計時沒有考慮到可測試性的問題。只不過這種不可測試性不是由于被測試的軟件內(nèi)部的過緊耦合造成的，而是和外部某些很難測試的部分耦合過緊，從而表現(xiàn)出被測試的軟件本身很難測試。這些很難測試的部分比較常見的有：圖形界面、硬件、數(shù)據(jù)庫等。下面以圖形界面為例進(jìn)行說明。 
    如果一個軟件模塊必須要通過圖形界面才能夠觸發(fā)它的應(yīng)用邏輯時，那么要對這個軟件模塊進(jìn)行測試時就必須要使用圖形界面。但是圖形界面又是很難測試的?？雌饋砗孟窈茈y辦。讓我們換一個角度考慮一下，其實我們真正想要測試的是軟件模塊本身的應(yīng)用邏輯，而不是圖形界面的觸發(fā)邏輯。如果我們在設(shè)計時能夠把被測試的軟件模塊本身進(jìn)行很好的封裝，定義良好的服務(wù)提供接口，那么我們就完全可以通過軟件模塊本身提供的接口進(jìn)行測試。這樣就可以繞過難以測試的圖形界面。造成上述軟件模塊很難測試的原因正是由于在設(shè)計時把軟件模塊本身的應(yīng)用邏輯和圖形界面這兩個無關(guān)的邏輯耦合在了一起。把這兩個邏輯分離，不僅可以對該軟件模塊進(jìn)行更容易、更有效的測試，而且也使得該軟件模塊具有了很好的可重用性和可移植性。 
    那么對于不好測試的圖形界面，我們該怎么辦呢？原則很簡單，如果某種東西不好測試，那么就讓它做肯定不會出錯的事情，而把可能會出錯的邏輯剝離出來，放到一個可以測試的模塊中。對于圖形界面來說，就是僅僅保持一個很薄的圖形界面邏輯，它的工作就是把用戶的請求簡單的轉(zhuǎn)發(fā)給真正處理該請求的軟件模塊。轉(zhuǎn)發(fā)邏輯足夠簡單以至于它肯定不會出錯，所以我們也無需對它進(jìn)行測試。 
    如果在進(jìn)行軟件開發(fā)時能夠首先編寫測試代碼，那么就會迫使你從易使用性，易測試性的角度開考慮問題，從而你就會專注于軟件模塊的高層抽象和職責(zé)。這樣就會定義出清晰的、明確反映意圖的模塊接口來，另外，為了使得測試能夠進(jìn)行，你就會主動把那些導(dǎo)致不好測試的耦合去掉。這樣的結(jié)果不僅僅是獲得了可測試性，并且也產(chǎn)生了更好的設(shè)計和系統(tǒng)架構(gòu)。 
    但是確實存在一些不好測試的東西并且很難只讓它執(zhí)行一些非常簡單的邏輯，比如嵌入式系統(tǒng)中的BSP。開發(fā)它們所使用的語言、環(huán)境以及它們本身的特性等決定了它們是很難測試的。這里說的難測試其實是一個測試代價問題，具體的說就是要付出更多的時間和努力。這就需要你在付出的代價和測試帶來的收益之間進(jìn)行平衡。如果付出的代價所帶來的收益是巨大的，那么付出的代價就是非常值得的。 
誤區(qū)之三：測試代碼可以隨意寫 
    大家肯定知道測試代碼是不能隨意編寫的，并且在編寫測試代碼時也不是抱著一種隨意的態(tài)度，但是你編寫出來的測試代碼以及測試代碼運行的情況卻表現(xiàn)出了一種隨意性和無序性。因為你可能并沒有弄清楚測試的真正意圖所在。 
    測試的目的是用來檢驗軟件系統(tǒng)是否滿足了需求。所以，你的測試代碼一定要明確的表達(dá)出這一點來。就那上面的案例來說，如果測試者真正從用戶的需求出發(fā)，那么他寫出來的測試腳本肯定不會是那樣的，而因該是每一個測試用例都清晰的刻畫了一項用戶的需求，然后檢驗系統(tǒng)是否實現(xiàn)了用戶期望的功能。這樣的測試才是有明確目的，才是最有效的測試。和把界面邏輯和應(yīng)用邏輯隔離，采用明確表現(xiàn)用戶需求測試用例進(jìn)行測試相比，上面的測試方法不能不說是隨意了一點。 
    在針對類進(jìn)行的單元測試中，也經(jīng)常會看到一些錯誤的測試方法。很多的測試者往往針對類中的每個特定的實現(xiàn)細(xì)節(jié)進(jìn)行測試。類中的特定的實現(xiàn)細(xì)節(jié)是很容易變化的，在快速的迭代式開發(fā)中更是如此。一旦你測試的類中的某個實現(xiàn)細(xì)節(jié)發(fā)生了變化，你原先的測試代碼就要進(jìn)行相應(yīng)的更改，否則就失去了意義。這種頻繁更改的代價是巨大的。類是一種抽象，它反映了更高層面的內(nèi)聚性，它應(yīng)該有明確的職責(zé)和定義良好的服務(wù)接口，它的職責(zé)和對外的接口相對于內(nèi)部的實現(xiàn)細(xì)節(jié)來說要穩(wěn)定的多，并且我們要驗證的正是這個類是否具備了它的職責(zé)。因此，在對類進(jìn)測試時，我們應(yīng)該針對類的接口來驗證類是否實現(xiàn)了它的職責(zé)而不是其他。這樣寫出來的測試代碼要穩(wěn)定的多，也有效的多。 
    細(xì)想一下，造成容易陷入針對實現(xiàn)細(xì)節(jié)測試的原因主要是由于先實現(xiàn)了類，然后才去進(jìn)行測試。如果先實現(xiàn)了類的功能，然后在去對類進(jìn)行測試，潛意識中就會不由自主的想去驗證已經(jīng)完成的類的某種實現(xiàn)細(xì)節(jié)。如果能夠在編寫實際類前，首先編寫針對該類的測試代碼，情況就會有很大的不同，因為這會迫使你從類的使用者的角度去考慮問題。結(jié)果就是會把關(guān)注點放在類的易用性上，放在類的職責(zé)上面，放在類提供服務(wù)的接口上面，而不是某種實現(xiàn)細(xì)節(jié)。 總之，測試代碼的編寫應(yīng)該從被測試的對象是否滿足需要的層面進(jìn)行，而不是其他。 
誤區(qū)之四：單元測試和驗收測試沒有什么區(qū)別 
    我們還以經(jīng)常用來和軟件進(jìn)行類比的建筑為例，首先給大家一個感性的認(rèn)識。單元測試可以類比為一個建筑的質(zhì)檢人員對建筑進(jìn)行的檢測， 他關(guān)注的重點是建筑的內(nèi)部結(jié)構(gòu)、地基、框架以及墻壁是否垂直等。他的檢測是要保證建筑的各個部分是正常的、安全的，換句話說，就是要保證施工滿足建筑上面的質(zhì)量標(biāo)準(zhǔn)。驗收測試可以類比為建筑的使用者來對建筑進(jìn)行的檢測。首先，他認(rèn)為這個建筑是滿足規(guī)定的工程質(zhì)量的，這是有建筑的質(zhì)檢人員來保證的。使用者關(guān)注的重點是住在這個建筑的中的感受。他關(guān)心建筑的外觀是否美觀、各個房間的大小是否合適，窗戶的位置是否合適，是否能夠滿足家庭的需要等。這里，建筑的使用者執(zhí)行的就是驗收測試，他是從用戶的角度出發(fā)的。建筑的質(zhì)檢人員執(zhí)行的就是單元測試，他是從構(gòu)建者的角度出發(fā)的。 
    正是這種角度的不同決定了單元測試和驗收測試之間的區(qū)別。它們是對系統(tǒng)的不同的方面進(jìn)行的測試，二者是互相補充的。不管我們在系統(tǒng)的構(gòu)建中使用了多么聰明的方法，不管我們的系統(tǒng)是多么的靈活，但是首先我們的產(chǎn)品必須是可用的，否則我們所做的就是浪費時間，從這一點上來說驗收測試要比單元測試顯得更加重要。 
    關(guān)于單元測試和驗收測試之間的明確劃分，沒有一個通用的標(biāo)準(zhǔn)，只有通過自己的不斷實踐來增加這方面的經(jīng)驗。你進(jìn)行的有關(guān)測試的實踐越多，你就會越清晰的感覺到單元測試和驗收測試之間的界限所在。下面給出一些指導(dǎo)原則，在你編寫測試代碼時可能會有幫助。 
l  如果一個單元測試要跨越類的邊界，那么它可能應(yīng)該是一個驗收測試；如果一個單元測試變的非常復(fù)雜，那么它可能應(yīng)該是一個驗收測試；如果一個單元測試經(jīng)常要隨著用戶需求的變化而改變，那么它可能應(yīng)該是一個驗收測試；如果一個單元測試比它要測試的代碼本身要難以編寫，那么它可能應(yīng)該是一個驗收測試 。
    測試是用來保證軟件開發(fā)過程的高效性，以及保證開發(fā)出來的軟件產(chǎn)品的高質(zhì)量和可用性的。軟件開發(fā)本身就是一件非常困難的事情，這也決定了有效的測試決不是簡單的依靠一些測試工具就可以進(jìn)行的。在使用工具的同時，我們更要加強關(guān)于測試的培訓(xùn)、教育，使大家對于測試首先有一個正確的認(rèn)識。只有這樣，我們才能夠更加有效、高效的使用工具，才能夠使測試真正起到它應(yīng)有的作用。

• 關(guān)于我們

• 開發(fā)優(yōu)勢

• 法律聲明

•