測試分為什麼,白盒,黑盒,單元,集成測試?
測試分為單元測試,壓力測試,黑盒測試,性能測試等等。自己看了很亂希望專業的人士給我講到底測試分為什麼。還有測試工具一類的。
其實測試工作不一定只能通過軟體工程進行理解,實際上,現實生活里我們都沒有逃脫測試的魔爪,咱們就通過「陪老婆/女友逛商場」這個示例,比較一下幾種測試方法之間的區別~~
黑盒測試:
老婆從商場的某一個入口進入,你在商場外面等待,這時候商城對你來說就像一個不透明的黑盒子,你並不知道商場內發生了什麼,你也不去關心裏面發生什麼,你只知道如果一切運轉正常,結果是老婆帶著一堆商品從某一個出口(可以與入口相同)出來。
這是原定正常的情況,這時候我們就不需要管商場裡面發生了什麼,只需要知道老婆進去轉了一圈,你的這月工資報銷了,一切正常,這就OK了。
否則,在多次逛商場(多次黑盒測試)過程中,頻繁發生無法達到正常結果的情況,例如老婆與人發生爭執、老婆帶的錢不夠、老婆有選擇困難需要與你協商等情況的發生,這就需要相關人員(你)通過別的檢測手段進到商場(黑盒)里進行檢查解決了。
白盒測試:
老婆從商場的某一個入口進入,你隨著陪同進入商場,全程陪伴,這時商場對你來說是個白盒子,就是透明的,你可以看到他內部的全部細節。
這時你要觀察老婆購物的每個細節,了解其走過的每一步,發生的每個小情況,隨時準備應對支付、拎包、與人對罵、按摩揉腿(我。。。已經寫不下去了。。。)等突發事件,記錄整個期間出現錯誤需要修正的問題(當然,整個過程你也不免出現走神情況,例如偷看別的美女,錯過老婆喜歡某種商品的信號,結果可能就是重測。。。也就是再逛一遍),最後結果是,你抱著一堆商品陪著老婆從某一個出口出來,這月工資還是報銷了。
單元測試:
老婆進入商場後,專門盯著某一個專賣店,查看其是否有新品、是否有活動,一天去三次,一周去三天,一月去三周,各級別VIP全辦齊,面對任何一個店員都可以刷臉,達到對該專賣店了如指掌,對店鋪的任何細節都確保萬無一失之後,再轉向下一個專賣店……
壓力測試:
響應打折號召,原本互不認識的老婆們瞬間組成聯盟,組團進入商場進行大量掃貨,每天進行,天天堅持,持續一段時間,看商場是否頂得住,觀察這種壓力下商場是否會出現斷貨、服務員暴走、刷卡機宕機等問題。
性能測試:
這個概念比較廣,包括整個商場的運轉穩定性,如能否做到每天開業、24小時開業、服務員被大媽折磨後的情緒控制能力等;商場安全性,保安能否保護顧客安全、防火防盜措施、小三專用逃生通道(例如程序里的特殊值、邊界值處理)等。
因此,其實軟體測試並不是什麼新鮮的概念,我們在現實生活中,一直在對各大商場進行「集成測試」,大量的商場被老婆團們以各種苛刻的測試手段所淘汰。因此,各位都是偉大的測試人員,並且,這項測試是永久存在的,永不宕機的,不要幻想產品終版發布的那天到來。
共勉。
--------------------------------------------------------
2015.9.20補充
吸收@Jasin Yip的建議,提一下回歸測試:
每當店鋪根據顧客需求(bug記錄)上線了新品(修改bug)之後,老婆們需要到該店鋪,進行全方位從新檢查是否出現新的購物機會,並體驗該店鋪全部功能是否正常,如刷卡。。。不放過任何一絲消費的機會。。。
2015.10.12補充
@Julia Jo 冒煙測試(Smoke Testing):
經過我認真閱讀(你信嗎)冒煙測試的概念,我腦中浮現出如下畫面。
當我跟隨老婆進入商場後,發現有幾處新裝修或新開張的店面,我與老婆立刻呈現出截然相反的面部表情,歡喜與驚恐,接下來進入店面(不可能出現無視路過的情況。。。),由於對這個新店面所知較少,所以沒有既定計劃,只是根據店面應該提供的服務(軟體功能),進行隨意閑逛、隨意詢問店員、挑選商品、瘋狂砍價(如果具備此服務~)、完成支付(在劫難逃啊)等行為,整個過程並無特殊針對性,只是圍繞店面應該存在的服務隨意體驗(測試),這好像是女生逛街的基本模式吧~如果發現哪裡不合心意(無意中發現bug,即冒煙),基本上會立刻失去興趣,呈斜眼撅嘴狀(停止測試),等待再次裝修後再來閑逛~
UAT測試:
版本1. 老婆對長期堅守的某個商場非常有信心,因此就對家人、朋友、同事、陌生人一致推薦此處,於是各路被忽悠組隊而來的「某某」觀光團進入商場進行購物(測試),並表達購物感言(反饋)。
版本2. 換個角色~
你的男/女友,對你完成長期測試(我也不知道都要測試什麼--)後,感覺這段感情可以上線運行了,於是就將男/女友帶到家中,由家人進行測試審核(感覺有點跑題。。。),然後家人群體表達測試結果~
總之:
不同的測試方法有不同的側重點,雖然名稱差別很大,也許實際上只是細微的形式上的差異。然而如同陪老婆逛街一樣,雖然各種形式差別不大,並且結果都是一樣(當月工資報銷~),但是當我們對這些事情(我真的指的是測試。。。)從事過大量的重複體驗之後,會發現,就是這一點點細微的差異,在面對不同的測試需求時卻是那麼的恰如其分。
反正這些測試方式不是強硬規定出來的,而是剛好這種測試能夠測出當前存在的問題,所以需要進行某個方式的測試。所以,深入了解不同測試方式的側重點,然後在適當的時候選擇最合適的測試方式,最終發現隱藏的問題,這,才是核心價值。哪怕你用在教科書中沒有的方式也是可以的,比如自己寫測試腳本等。
就這樣吧,看我寫的多認真(完全沒看出來),給個贊再走啊~
至於為什麼要這麼分,我看只能去問這個的創始人了,不過估計你也問不到了……
在分享我的看法之前,我覺得需要先指明一點:任何主張都受限於其所處時代。也即是說,也許在當時很適用、很正確的觀念和做法,放到如今的時代背景中來看待,卻顯得不合理、不正確了,但這並不代表這些觀念和做法本身有問題,只是它們已經不再適合。
1. 設計測試時的思路問題
白盒、黑盒:是指我們看待所測試對象時的位置,是以「身處其中」(白盒)也即可以知曉其內部運作機制的角度看待並設計和執行測試用例,還是以「置身事外」(黑盒)也即只知道外面可以看見的情況完全不知道內部情況如何的方式看待並設計和執行測試用例。在往年那個生產力匱乏、工具也欠缺的年代,這種說法還很有啟發作用,畢竟要去觀察和跟蹤系統內部運行狀態並不那麼容易,但在如今這個時代,哪還有什麼白盒、黑盒之分?難道你在白盒測試編程語言本身的時候,會深入到編譯器內部去觀察語言執行情況?或者是檢查硬體的數字或脈衝信號?
2. 跟被測對象強相關的測多大東西、測哪個方面的問題
單元測試、系統測試等:是我們所選定的測試對象的範圍或規模的不同,單元測試就是關注一個類、一個函數這個級別的表現的測試,系統測試則是關注系統整體的行為。每個公司可能都會有自己的一些測試範圍的名詞,例如模塊測試之類的。
功能、壓力、性能等:是我們所測試對象的不同面或者說不同的屬性,或者說是被測對象在不同維度所表現出來的不同行為,也可以簡稱為測試類型。就好像一個人,會不會洗碗(功能)?能夠連續洗碗4個小時嗎(壓力)?最快能夠在10分鐘內洗幾個碗(性能)?
3. 跟整體研發方式強相關的測試時間點問題
集成測試、回歸測試等:其實是測試的階段,也即是說我們在計劃一個項目時,按照時間順序以及自身測試水平和能力所需要的中間過程,並非是必須的,也會因為不同的測試開展方式而有極大的不同。例如,在敏捷方式下開展測試,就沒有單獨的集成測試和回歸測試階段,可以認為是無時無刻不再進行集成和回歸。又例如,在傳統方式(例如瀑布)下,由於需求分析和測試用例設計進行方式的原因,集成和回歸則會被看作是一種測試類型,以覆蓋其他測試類型沒有覆蓋的部分。
4. 跟整體測試活動相關的生產力問題
測試工具:測試工具這個詞本身是很泛(也即很廣義)的,簡單來講,就是測試工作中用到的任何工具都可以稱之為測試工具。而測試工作又包含了很多活動,例如分析需求、擬訂測試計劃、設計測試用例、執行測試用例、編寫測試報告、提交缺陷等等,這也意味著會有很多種不同用途的測試工具,甚至,可能還有不同廠商打包不同用途的(狹義)測試工具而提供的測試工具包(也被稱為測試工具)……
如果你們的需求文檔是用Word編寫的,那麼你可以認為Word是你們的一種需求工具。如果你們用DOORS或其他工具保存,那你可以認為DOORS是你們的需求管理工具。
如果你們用了Lotus Notes或者QC等來管理你們的測試計劃和測試用例,那麼你可以認為它們是測試管理工具。
如果你使用了Jira或Bugzilla等來管理你們的缺陷,那麼你可以認為它們是你們的缺陷追蹤系統。
如果你們用了Redmine、VersionOne等敏捷項目管理工具來管理你們的測試工作任務,那麼你可以認為它們也是你們的項目管理工具。
如果你們使用了Robotframework、Watir、Robotium、LoadRunner等各種工具來編寫自動化測試用例和執行,那麼你可以認為它們就是你們的測試自動化工具。
等等,太多了,不一而足。這樣的區分,是為了照顧某些測試工作的面子,比如黑盒測試。
測試本來就不應該這麼區分,也不應該是現在這個樣子。1. 設計測試時的思路問題
2. 跟被測對象強相關的測多大東西、測哪個方面的問題
3. 跟整體研發方式強相關的測試時間點問題
4. 跟整體測試活動相關的生產力問題
單元測試屬於測試級別,壓力、性能測試屬於測試類型,黑盒測試屬於測試方法或要求
....…..............................
測試級別,單元測試、部件測試、配置項測試、系統測試測試類型,文檔審查、靜態分析、代碼審查、代碼走查、功能、性能、介面、邊界、恢復性、安全性、數據處理、邊界、強度、壓力、安裝性等測試方法或要求,文檔審查,靜態分析與代碼審查,配置項測試,系統測試,也可以說為階段,這塊東西如果涉及到工程,只能意會理解,沒辦法書面化因為需要驗證是否所有的代碼都可以正確工作(白盒,代碼覆蓋率),因為需要驗證是否代碼完成了它需要實現的功能(黑盒,功能測試,介面測試),因為需要驗證多個系統模塊組合在一起是否能正常工作(集成測試),因為需要驗證系統架構能否滿足預設性能要求(壓力測試,伺服器性能),因為需要驗證或者判斷用戶最基本的使用體驗(客戶端性能測試,用戶測試)。每個測試都有它存在的意義,為什麼會有是因為有需求。
最近正好想了一下相關的概念:
首先要明確,測試是整個軟體過程的一部分,當你從軟體過程來看測試,就知道為什麼測試會有那麼多種類了。比如大型軟體開發中經常用到的持續集成過程,軟體被分成多個增量過程,代碼開發者不停的將自己的開發代碼checkin到代碼樹,為了保障質量差的代碼不被引入到代碼樹,就需要代碼review和單元測試。當多個模塊由底向上集成的時候,為了保證集成後的集合質量,就有了集成測試。等整個系統完成了,就需要做各種系統測試,驗收測試。
根據各種測試的特性,有些測試適合用白盒的方法設計,這些測試就都叫做白盒測試,比如一般的單元測試;有些測試適合用黑盒的方法設計,就有了黑盒測試,比如系統測試。而自動化測試則是為了緩解測試覆蓋和測試成本之間的矛盾,移除回歸測試中的重複僵化的部分而來的。總之,想要想清楚在什麼時候需要什麼測試,就必須要用一種工程的眼光來看待軟體過程。
白盒和黑盒的定義是很久很久之前的了,單元和集成和這2個都不是1個層面的東西。。。不說別的了,byte code做靜態詞法的時候就有的,時隔很久很久很久,但是現在國內在研究的公司極少,這個算不算吐槽。。。
理論上說,每一種測試方法都可以做到發現同樣多的bug!但是針對某類bug,不同的測試方法能夠發現的難以程度不同。例如:應用在程序初始化流程的代碼裡面有一個隱患:如果通過走查代碼或者單元測試的方法,可以很快定位到問題,但是如果是黑盒手工測試的話,需要在應用啟動過程中,剛好執行到那一段代碼的時候才能出現問題,難以定位,會變成一個不可重現或者機會重現的問題
有沒有想學測試的558055909
推薦閱讀:
※伺服器端測試主要包含什麼?
※測試人力不足時,測試技術層面有什麼方法可以提高測試效率?
※性能測試是不是只要學習LR就可以了,還需要學習其他什麼知識?
※在校生想成為軟體測試工程師自學需要學什麼?
※嵌入式系統如何進行測試?