摘要:單元測試過后,機器狀態(tài)保持不變。單元測試應該產生可重復一致的結果。然并卵都說國內很多程序員是不寫單元測試的,甚至從來都不寫,筆者當年做的時候也沒寫過幾次捂臉。回歸測試在單元測試的基礎上,我們就能夠建立關于這一模塊的回歸測試。
送給初級程序員的測試認知文
作為開發(fā)同學,一些基本的測試崗位相關知識還是很有必要了解一下,免的某些同學在工作中和測試同學斗嘴、打架、群毆等以及被測試鄙視....。
我們常常聽說的一些測試專業(yè)術語,比如白盒、黑盒、單元測試,相信搞作為程序員的你脫口而出的就是這三個詞匯吧,筆者在前幾年對測試也僅僅停留在這個兩個詞匯上,更多的就不得而知了。后來在一家做跨境電商的公司學到了一些新術語,也見到了測試崗位的一些日常,比如冒煙測試、測試用例(TC)、回歸測試、接口測試以及偶爾和我吵架等等。
白盒黑盒測試是按測試設計方法分類的,是指軟件測試設計的方法,而不是軟件測試的方法,注意這個區(qū)別。
黑盒測試是行為測試,即從軟件的行為而不是內部結構觸發(fā)來設計測試,也就是在軟件上到處點點等。白盒指的是在設計測試的過程中,設計者可以“看到”軟件系統(tǒng)的內部結構,并使用軟件的內部結構和知識來選擇測試數(shù)據(jù)及具體的測試方法。
功能測試和非功能測試按測試的目,分為功能測試和非功能測試,單元測試是功能測試里的一種,每種測試的名稱和內容如下:
一個軟件除了基本功能之外,還有很多功能之外的特性,這些叫非功能需求,或者服務質量需求。然而,若沒有軟件的基本功能,這些特性都將無從表現(xiàn)出來,因此,我們要在軟件開發(fā)的適當階段——基本功能完成后再來做這些非功能測試,非功能測試有如下這些
在開發(fā)軟件的過程中,不少測試起著“烽火臺”的作用,它們告訴我們軟件開發(fā)的流程是否順暢,比如冒煙測試是指測試不通過不能進行下一步工作,是一種基本驗證測試,據(jù)說是從硬件設計行業(yè)流傳過來的說法。當年設計電路板的時候,很多情況下,新的電路板一插上電源就冒起白煙,燒壞了。如果插上電源后沒有冒煙,那就是通過了“冒煙測試”,可以進一步測試電路板的功能了。還有驗證構建是否通過基本測試以及全面考核某方面的功能的驗收測試。
另一些測試名稱則是說明不同的測試方法
對于開發(fā)來講,最最常用和熟悉的還是單元測試,怎樣才算一個好的單元測試?單元測試應該準確、快速地保證程序基本模塊的正確性。下面是驗證單元測試好壞的一系列標準:
單元測試應該在最基本的功能/參數(shù)上驗證程序的正確性。
單元測試必須由最熟悉代碼的人(程序的作者)來寫。
單元測試過后,機器狀態(tài)保持不變。如果單元測試創(chuàng)建了臨時的文件或目錄,應該在Teardown(拆卸)階段刪掉。如果單元測試在數(shù)據(jù)庫中創(chuàng)建或修改了記錄,那么也許要刪除或恢復這些記錄,或者每一個單元測試使用一個新的數(shù)據(jù)庫,這樣可以保證單元測試不受以前單元測試實例的干擾。
單元測試要快(一個測試的運行時間是幾秒鐘,而不是幾分鐘)。
單元測試應該產生可重復、一致的結果。
獨立性—單元測試的運行/通過/失敗不依賴于別的測試,可以人為構造數(shù)據(jù),以保持單元測試的獨立性。
單元測試應該覆蓋所有代碼路徑。
單元測試應該集成到自動化測試的框架中。
單元測試必須和產品代碼一起保存和維護。
然并卵!都說國內很多程序員是不寫單元測試的,甚至從來都不寫,筆者當年做Java的時候也沒寫過幾次(捂臉)。
回歸測試在單元測試的基礎上,我們就能夠建立關于這一模塊的回歸測試(Regression Test)。Regress:return to a worse or less developed state,是倒退、退化、退步的意思。在軟件項目中,如果一個模塊或功能以前是正常工作的,但是在一個新的構建中出了問題,那么這個模塊就出現(xiàn)了一個“退步”(Regression),從正常工作的狀態(tài)退化到不正常工作的狀態(tài)。在一個模塊的功能逐步完成的同時,與此功能有關的測試用例也同樣在完善中。一旦有關的測試用例通過,我們就得到了此模塊的功能基準線(Baseline),一個模塊的所有單元測試就是這個模塊最初的Baseline。
針對一個Bug Fix,我們也要做Regression(海退) Test。目的是:
驗證新的代碼的卻改正了缺陷。
同時要驗證新的代碼有沒有破壞模塊的現(xiàn)有功能,有沒有Regression
對于“回歸測試”中的“回歸”,我們可以將其理解為“回歸到以前不正常的狀態(tài)”。回歸測試最好要自動化,因為這樣就可以對于每一個構建快速運行所有回歸測試,以保證盡早發(fā)現(xiàn)問題。單元測試是回歸測試的基礎。在專注于模塊基本功能的單元測試之外,還有功能測試——從用戶的角度檢查功能完成得怎么樣。
探索性測試探索性測試是為了某一個特定目的而進行的測試,且就這一次,以后一般也不會重復測試。在軟件工程的實踐中,“Ad hoc”大多是指隨機進行的、探索性的測試。
探索式測試的測試流程是不可重復的,因為它的測試都是“特定”測試,沒法重復。這一原因,使得探索式測試不能自動化,就這一點而言,還達不到CMMI二級——可重復級。
作為管理人員來說,如果太多的小強是在探索式測試中找出來的,那我們就要看看測試計劃是否基于實際的場景,開發(fā)人員的代碼邏輯是否完善,等等。
場景/集成/系統(tǒng)測試在軟件開發(fā)的一定階段,我們要對一個軟件進行全面和系統(tǒng)的測試,以保證軟件的各個模塊都能共同工作,各方面均能滿足用戶的要求。這類測試叫系統(tǒng)/集成測試。這一方法的核心思想是:當用戶使用一個軟件時,他/她并不會獨立使用各個模塊,而是把軟件作為一個整體來使用。我們在做場景測試的時候,就需要考慮在現(xiàn)實環(huán)境中用戶使用軟件的流程是怎樣的,然后模擬這個流程,看看軟件能不能滿足用戶的需求。這樣,才能使軟件符合用戶的實際需求。
應該什么時候做集成測試呢?是不是越早越好?原則上是當一個模塊穩(wěn)定的時候,就可以把它集成到系統(tǒng)中,和整個系統(tǒng)一起進行測試。在模塊本身穩(wěn)定之前就提早做集成測試,可能會報告出很多Bug,但是這些由于提早測試而發(fā)現(xiàn)的Bug,有點像汽車司機在等待綠燈時不耐煩而拼命地按喇叭——也就是說,有點像噪音。我們還是要等到適當?shù)臅r機再開始進行集成測試。
了解完這些概念后,我們來看看究竟一個測試工程師的職責是怎么樣的呢,下面列舉一些:
制定測試計劃
設計與編寫測試用例
實施測試
BUG跟蹤
測試報告與總結
其他測試工程活動
很多測試工作并不是說,有了測試工程師,把測試相關的全部事情扔給他們就完事了,需要開發(fā)和測試配合,共同完成某些測試任務,軟件測試也不僅僅是為了發(fā)現(xiàn)bug然后提給開發(fā),測試=質量保障,提升質量相關的都是測試工程師需要關注和負責的,軟件測試的目標是幫助項目打造用戶喜歡的產品。
文章首發(fā)于我的微信公眾號,關注可獲得每次最新推送
《構建之法》讀書筆記之二
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/8776.html
摘要:前言上次聊了關于定義函數(shù)的知識,還有參數(shù)方面的,這次先補充一點參數(shù)小知識,還有簡單的講一下閉包。在這里,函數(shù)包含了一個內部函數(shù),所以可以使用引入的參數(shù)。我們把函數(shù)作為返回值賦給,當然,同時返回的還有。 前言 上次聊了關于定義函數(shù)的知識,還有參數(shù)方面的,這次先補充一點參數(shù)小知識,還有簡單的講一下閉包。 arguments對象 引入的參數(shù)會保存在arguments數(shù)組對象中,第一個引入的參...
摘要:關鍵字在中的變化非常的靈活,如果用的不好就非常惡心,用的好程序就非常的優(yōu)雅,靈活,飄逸所以掌握的用法,是每一個前端工程師必知必會的而且這個也是一些大公司筆試中常見的考察項第一種單獨的,指向的是這個對象注當前的執(zhí)行環(huán)境是所以指向了第二種全局函 this關鍵字在javascript中的變化非常的靈活,如果用的不好就非常惡心,用的好,程序就非常的優(yōu)雅,靈活,飄逸.所以掌握this的用法,是每...
摘要:博客文章鏈接數(shù)組大概知多少判斷一個變量是否為數(shù)組可靠地檢測數(shù)組方法利用的方法利用的方法數(shù)組的原生方法有哪些會改變自身的方法不會改變自身的方法遍歷方法如何將類數(shù)組的變量轉化為數(shù)組如果是,可以用方法。通常用的方法,將類似數(shù)組轉換為數(shù)組。 博客文章鏈接:數(shù)組大概知多少 判斷一個變量是否為數(shù)組? 可靠地檢測數(shù)組方法 1.利用Object的toString方法 var list = [1, 2,...
閱讀 2800·2021-11-22 14:44
閱讀 541·2021-11-22 12:00
閱讀 3683·2019-08-30 15:54
閱讀 1570·2019-08-29 17:15
閱讀 1898·2019-08-29 13:50
閱讀 1107·2019-08-29 13:17
閱讀 3513·2019-08-29 13:05
閱讀 1181·2019-08-29 11:31