• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>

    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>

            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            

    
            

            




            







												


        


            


            牽著老婆滿街逛
            

            嚴以律己,寬以待人. 三思而后行.
            
GMail/GTalk: yanglinbo#google.com;
            
MSN/Email: tx7do#yahoo.com.cn;
            
QQ: 3 0 3 3 9 6 9 2 0 .
            

            




            
	
					
	
            
		
            
			微軟的軟件測試方法
		
            
		
		微軟的軟件測試方法
            國內(nèi)近年來關(guān)于軟件測試的問題和討論越來越活躍。但從總體上說交流軟件測試技術(shù)的多，而探討軟件測試方法的少。這里的“技術(shù)”指的是具體的戰(zhàn)術(shù)問題，比如說如何使用某種工具來解決某一特定測試問題，或者某一類型軟件有哪些測試手段等等。而這里的“方法”指的是宏觀的戰(zhàn)略問題，或者叫方法論，這包括從軟件測試的概念或理念，到企業(yè)軟件質(zhì)量控制體系；從軟件測試的過程，到測試團隊的設(shè)置及其職責(zé)的界定等等。

            作為測試人員，熱衷于“技術(shù)”討論和交流是一件可喜可賀的事。從中可以感覺到軟件測試在中國迅速發(fā)展的開端和潛力。但是作為企業(yè)的管理決策者，是否也應(yīng)該以同樣的熱情來思考“方法”問題呢？特別是當一個軟件企業(yè)的軟件測試從無到有，或者當企業(yè)已有一定的軟件測試的投入，但發(fā)現(xiàn)其實效并不顯著，甚至由于測試的引入而帶來了新的管理上的混亂。這個時候方法論的思考，更有利于發(fā)現(xiàn)問題的根源。即便是一個基層的測試人員，當積累了一定的技術(shù)經(jīng)驗后，也應(yīng)該不時從日常的具體工作中走出來，在一個較高層次上進行回顧總結(jié)和借鑒，并試著提出一些優(yōu)化和改進的措施，這無論對專業(yè)上還是對事業(yè)上的成長都是非常有意義的。

            微軟在軟件測試方面有很多值得一提的經(jīng)驗，在此我想以我個人的體會和思考，同大家一同進行一些探討。這里有一點須要特別說明，盡管微軟的方法已被微軟的實踐多次證明是成功的，非常有效的，但這并不意味著這些方法在中國的軟件企業(yè)中有廣泛的可行性。一種方法是否可行還受到很多其他因素的影響，比如企業(yè)類型（微軟是生產(chǎn)平臺軟件和通用軟件產(chǎn)品的企業(yè)），企業(yè)管理體制，企業(yè)文化等等。所以我的目的只是給大家一些思路和借鑒。



            兩類經(jīng)典的軟件測試方法



            在具體介紹微軟的軟件測試方法之前，我想首先從概念，或理念的層面上來理解究竟甚么是軟件測試，目的是從中導(dǎo)出微軟測試方法的理論根源。

            傳統(tǒng)上認為軟件測試的方法從總體上分為兩類。第一類測試方法是試圖驗證軟件是“工作的”，所謂“工作的”就是指軟件的功能是按照預(yù)先的設(shè)計執(zhí)行的；而第二類測試方法則是設(shè)法證明軟件是“不工作的”。

            提出第一類方法的代表人物是軟件測試領(lǐng)域的先驅(qū)Dr. Bill Hetzel（代表論著《The Complete Guide to Software Testing》），他曾于1972年6月在美國的北卡羅來納大學(xué)組織了歷史上第一次正式的關(guān)于軟件測試的論壇。他首先在1973年給軟件測試一個這樣的定義：“就是建立一種信心，認為程序能夠按預(yù)期的設(shè)想運行。Establish confidence that a program does what it is supposed to do. ”后來在1983年他又將定義修訂為：“評價一個程序和系統(tǒng)的特性或能力，并確定它是否達到預(yù)期的結(jié)果。軟件測試就是以此為目的的任何行為。 Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定義中的“設(shè)想”和“預(yù)期的結(jié)果”其實就是我們現(xiàn)在所說的用戶需求或功能設(shè)計。他還把軟件的質(zhì)量定義為“符合要求”。

            第一類測試可以簡單抽象地描述為這樣的過程：在設(shè)計規(guī)定的環(huán)境下運行軟件的功能，將其結(jié)果與用戶需求或設(shè)計結(jié)果相比較，如果相符則測試通過，如果不相符則視為Bug。這一過程的終極目標是將軟件的所有功能在所有設(shè)計規(guī)定的環(huán)境全部運行，并通過。

            在軟件行業(yè)中一般把第一類方法奉為主流和行業(yè)標準。1990年的IEEE/ANSI標準將軟件測試進行了這樣的定義：“就是在既定的狀況條件下，運行一個系統(tǒng)或組建，觀察記錄結(jié)果，并對其某些方面進行評價的過程。The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component (IEEE/ANSI, 1990 [Std 610.12-1990]”這里所謂“既定的狀況”也可理解為需求或設(shè)計。

            盡管如此，這一方法還是受到很多業(yè)界權(quán)威的質(zhì)疑和挑戰(zhàn)。代表人物是Glenford J. Myers（代表論著《The Art of Software Testing》）。他認為測試不應(yīng)該著眼于驗證軟件是工作的，相反應(yīng)該首先認定軟件是有錯誤的，然后去發(fā)現(xiàn)盡可能多的錯誤。他還從人的心理學(xué)的角度論證，將 “驗證軟件是工作的”作為測試的目的，非常不利于測試人員發(fā)現(xiàn)軟件的錯誤。于是他于1979年提出了他對軟件測試的定義：“就是以發(fā)現(xiàn)錯誤為目的而運行程序的過程。The process of executing a program or system with the intent of finding errors.” 這就是軟件測試的第二類方法，簡單地說就是驗證軟件是“不工作的”，或者說是有錯誤的。他甚至極端地認為，一個成功的測試必須是發(fā)現(xiàn)Bug的測試，不然就沒有價值。這就如同一個病人（假定此人確有病），到醫(yī)院做一項醫(yī)療檢查，結(jié)果各項指標都正常，那說明該項醫(yī)療檢查對于診斷該病人的病情是沒有價值的，是失敗的。我并不完全同意這一看法。

            第二類軟件測試方法在業(yè)界也很流行，受到很多學(xué)術(shù)界專家的支持。大家熟悉的Ron Patton在《軟件測試》（ 中文版由機械工業(yè)出版社出版，具說此書是目前國內(nèi)測試新手入門的經(jīng)典教材）一書的第10頁，有一個明確而簡潔的定義：“軟件測試員的目標是找到軟件缺陷，盡可能早一些，并確保其得以修復(fù)。”有些軟件企業(yè)以Bug數(shù)量來作為考核測試人員業(yè)績的一項指標，其實就是接受了這樣的方法。



            兩類方法的優(yōu)劣對比



            雖然軟件測試總的目的是為了軟件產(chǎn)品的質(zhì)量，但很明顯這兩類測試方法在具體目標、或指導(dǎo)思想上截然相反。由此也決定了它們在思路、過程和測重點上有很大的差別，并各有利弊的。

            第一類測試方法以需求和設(shè)計為本，因此有利于界定測試工作的范疇，更便于部署測試的側(cè)重點，加強針對性。這一點對于大型軟件的測試，尤其是在有限的時間和人力資源情況下顯得格外重要。而第二類測試方法與需求和設(shè)計沒有必然的關(guān)聯(lián)，如果計劃管理不當，測試活動很容易丟失重點，走入歧途。

            第一類測試方法可以與軟件的架構(gòu)和軟件開發(fā)的計劃相配合，使軟件測試活動逐層次的展開，從而使軟件的功能和質(zhì)量有計劃地逐步完善和提高（關(guān)于測試的層次問題，我會在今后的討論中專門介紹）。第二類測試方法不具備這種過程的漸進性。

            第一類測試方法的缺點是缺乏靈活性，不利于測試人員主觀能動性的發(fā)揮，正像Myers先生所說，不容易找到軟件的錯誤（Bug）。而這方面正是第二類測試方法的長處。



            微軟的策略



            正是因為認識到兩類測試方法各有利弊，微軟在軟件測試活動中將兩類方法結(jié)合起來，以第一類測試方法為基礎(chǔ)和主要線索，階段性地運用第二類測試方法。



            微軟的第一類測試



            微軟的第一類測試總體上說分為三個步驟進行：審核需求和設(shè)計—〉設(shè)計測試—〉實施運行測試。

            前文已述，第一類測試是以需求和設(shè)計為本來驗證軟件的正確性。大家很自然的想到，需求和設(shè)計本身也有正確性的問題。依據(jù)不正確的需求和設(shè)計不可能開發(fā)出正確的軟件產(chǎn)品，測試也將是徒勞的。因此驗證需求和設(shè)計是微軟進行第一類測試的第一步。有必要指出的是，這里所說的需求和設(shè)計具體說來它一般包括：（1）由項目經(jīng)理根據(jù)用戶要求（信息來源于市場部門，用戶支持部門等等）而編寫的需求文本（Requirement Specification）；（2）由項目經(jīng)理根據(jù)需求文本而編寫的功能設(shè)計文本（Functional Design Specification）；（3）由開發(fā)人員根據(jù)功能文本而編寫的實施設(shè)計文本（Implementation Design Specification）。微軟的測試人員要參與所有這些文本的審核。作為測試人員，審核重點是檢查文本對用戶需求定義的完整性、嚴密性和功能設(shè)計的可測性。同時這種審核對于測試人員也是一種熱身活動，使他們盡早地進入技術(shù)和業(yè)務(wù)狀態(tài)。

            第二步，測試人員要根據(jù)已審核通過的需求和設(shè)計編制測試計劃，設(shè)計測試用例。在前面提到的三種文本中，功能設(shè)計文本是主要依據(jù)。原因很簡單，這類測試關(guān)心的是軟件是否能正確地實現(xiàn)功能，而不是這些功能如何被具體實施的。從這里大家可以看出這是典型的“黑盒測試”。確實微軟的測試主要是從用戶角度進行的黑盒測試。這一步的完成就意味著“測試計劃”和“測試用例設(shè)計”兩個文本的完成。“測試計劃” 文本主要闡述測試的范疇、領(lǐng)域、方法、工具、資源和計劃時間表等等。“測試用例設(shè)計”文本要列出測試用例、每個用例的設(shè)置、執(zhí)行步驟和預(yù)期結(jié)果。測試的這兩個文本也要被項目經(jīng)理和開發(fā)人員審核。這樣經(jīng)過各種相互的審核，大家對項目形成了基本的共識。

            第三步的實施運行測試是整個開發(fā)過程中最長最復(fù)雜的一個階段。從總體上說就是將上一步設(shè)計的測試用例按計劃付諸實施的過程。這包括編寫自動化測試程序、反復(fù)運行自動化測試程序，也包括階段性執(zhí)行手動測試用例。這一階段的測試必須在周密的計劃下進行，在前面我已提到，這正是第一類測試的特點和長處。這種計劃性首先體現(xiàn)在開發(fā)和測試的相互協(xié)調(diào)配合，根據(jù)產(chǎn)品的架構(gòu)和功能模塊的依賴關(guān)系，按照項目的總體計劃共同推進。從測試的過程來看，總是先運行或執(zhí)行簡單用例，然后再復(fù)雜用例；先驗證單一的基本功能，再綜合的端到端的功能；先發(fā)現(xiàn)解決表面的，影響面大的Bug，再深層的，不容易重現(xiàn)的Bug。因此隨著項目開發(fā)和測試的進程，產(chǎn)品的功能不斷完善，質(zhì)量不斷提高。這里有一點要特別指出，有很多測試用例是要反復(fù)運行的，特別是基本的自動化測試每一天，每一個Build上都要運行。盡管這些測試大多數(shù)情況下都是通過的，很少再發(fā)現(xiàn)新的Bug，但其價值是顯而易見的，就是為了防止質(zhì)量回歸。可見Myers的理論在這里是不適用的。這一階段測試人員還有一項繁瑣但卻很重要的工作，就是對已有的測試用例的維護。比如通常以下兩種情況下要新增一些測試用例，一是對于當初測試設(shè)計不周全的領(lǐng)域，二是對于外部的Bug（比如從Beta客戶報告來的），沒有被現(xiàn)有測試用例所覆蓋。當產(chǎn)品的功能設(shè)計出現(xiàn)更改時（在微軟這是常事），所涉及的測試用例當然也要相應(yīng)地修改。



            微軟的第二類測試



            微軟的第二類測試是階段性的，常常根據(jù)需要而帶有隨機性和突擊性。對于這類測試，在微軟有一個專門的名稱：“Bug Bash（Bug大掃除）”。

            Bug Bash通常發(fā)生在項目開發(fā)各階段（微軟叫里程碑）的末期，比如Beta版發(fā)布前，劃出一個專門的時間段（通常1-3天），在這期間所有參與項目的人員，集中全部精力，運用各方面的知識，盡全部智慧來搜尋項目的Bug。這是一個非常有意思的活動，但要組織好這樣的活動并非易事。一般有以下要點：（1）盡管這是一個測試活動，但參與者并不僅限于測試人員。項目經(jīng)理，開發(fā)人員甚至于高層管理人員都應(yīng)參加，如同全民動員。目的是要集思廣益；（2）要鼓勵各部門，領(lǐng)域交叉搜索，因為新的思路和視角通常有助于發(fā)現(xiàn)更多的Bug；（3）為調(diào)動積極性，增強趣味性，可以適當引入競爭機制，比如當活動結(jié)束時，評出發(fā)現(xiàn)Bug最多，發(fā)現(xiàn)最嚴重Bug的個人，給以物質(zhì)和精神獎勵。（4）可以分專題展開，比如安全性、用戶界面可用性、國際化和本地化等等。

            微軟的第二類測試除了Bug Bash外，經(jīng)常還有一些專業(yè)性的測試，最典型的是針對安全性攻擊測試。一般會邀請公司內(nèi)部，或業(yè)界的專家來搜尋產(chǎn)品的安全漏洞。



            以上我從傳統(tǒng)軟件測試概念的角度，介紹了微軟的策略和兩類傳統(tǒng)測試方法的具體做法，及其側(cè)重點。這其實僅僅是一個基礎(chǔ)，一個很原始的基礎(chǔ)。軟件測試在微軟軟件產(chǎn)品開發(fā)中的作用、地位遠不是這些原始的方法所能達到的，也不是傳統(tǒng)軟件測試概念所函蓋的。微軟在軟件測試方面有很多特有的做法，和概念上的突破，比如“軟件測試的信息服務(wù)功能”、“以用戶為中心的宏觀質(zhì)量體系”、“分級測試”、“項目的質(zhì)量管理系統(tǒng)”、“Bug三方會審”、“測試自動化”和“軟件測試的軟硬件—部門、團隊、人和基礎(chǔ)設(shè)施”等等。這些我會在以后的討論中分專題進行介紹。            

		
            
			posted on 2006-07-27 21:32 楊粼波 閱讀(761) 評論(0)  編輯 收藏 引用  所屬分類: 軟件工程 
		
            
	
            
	
	





            
	    
    




            






            

				

            



    
    







            
	   
	



久久久网中文字幕|
久久99精品久久久久久野外|
嫩草伊人久久精品少妇AV|
狠狠色婷婷综合天天久久丁香|
久久精品这里热有精品|
青青草原综合久久大伊人导航|
亚洲va久久久噜噜噜久久天堂
|
久久精品国产久精国产|
久久久久国产精品嫩草影院|
久久久久久久免费视频|
久久综合丝袜日本网|
久久夜色精品国产噜噜亚洲a|
久久久久一区二区三区|
色播久久人人爽人人爽人人片AV|
 久久综合狠狠综合久久激情 
|
午夜人妻久久久久久久久|
久久国产免费直播|
久久久久久免费一区二区三区|
77777亚洲午夜久久多喷|
久久影院亚洲一区|
国产精品狼人久久久久影院|
国产亚洲精久久久久久无码|
精品国产乱码久久久久软件|
久久精品18|
久久久久久国产精品美女|
国产午夜福利精品久久|
国产精品久久久久…|
久久精品aⅴ无码中文字字幕重口|
久久亚洲精品无码播放|
久久久久亚洲爆乳少妇无|
国产激情久久久久影院老熟女|
91精品国产高清久久久久久io|
久久精品无码一区二区WWW|
久久99精品久久久久久水蜜桃|
国产精品久久久久一区二区三区|
99热热久久这里只有精品68|
久久亚洲精品中文字幕三区|
91精品国产91久久久久久|
久久久WWW成人免费精品|
精品久久久无码中文字幕天天|
久久亚洲国产成人影院网站|