功能測試、性能測試、自動化測試區(qū)別

時間：2022-01-18作者：中山立訊檢測有限公司瀏覽：259

1、功能測試

根據(jù)產(chǎn)品特性、操作描述和用戶方案，測試一個產(chǎn)品的特性和可操作行為以確定它們滿足設(shè)計需求。

功能測試又稱為黑盒測試，是把測試對象看作一個黑盒子。利用黑盒測試法進行動態(tài)測試時，需要測試軟件產(chǎn)品的功能，不需測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程。

黑盒測試試圖發(fā)現(xiàn)以下類型的錯誤：

（1）功能錯誤或遺漏

（2）界面錯誤

（3）數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯誤

（4）性能錯誤

（5）初始化和終止錯誤

用例設(shè)計方法

（1）等價類劃分方法

（2）邊界值分析方法

（3）錯誤推測方法

（4）因果圖方法

（5）判定表驅(qū)動分析方法

（6）正交實驗設(shè)計方法

（7）功能圖分析方法

2、性能測試：

性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進行。

通過負載測試，確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)各項性能指標的變化情況。

壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接受的性能點，來獲得系統(tǒng)能提供的較大服務(wù)級別的測試。

性能測試目的：驗證軟件系統(tǒng)是否能夠達到用戶提出的性能指標，同時發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸，優(yōu)化軟件，最后起到優(yōu)化系統(tǒng)的目的。

包括以下幾個方面

1．評估系統(tǒng)的能力，測試中得到的負荷和響應(yīng)時間數(shù)據(jù)可以被用于驗證所計劃的模型的能力，并幫助作出決策。

2．識別體系中的弱點：受控的負荷可以被增加到一個較端的水平，并突破它，從而修復(fù)體系的瓶頸或薄弱的地方。

3．系統(tǒng)調(diào)優(yōu)：重復(fù)運行測試，驗證調(diào)整系統(tǒng)的活動得到了預(yù)期的結(jié)果，從而改進性能。

檢測軟件中的問題：長時間的測試執(zhí)行可導(dǎo)致程序發(fā)生由于內(nèi)存泄露引起的失敗，揭示程序中的隱含的問題或沖突。

4．驗證穩(wěn)定性（resilience）可靠性（reliability）：在一個生產(chǎn)負荷下執(zhí)行測試一定的時間是評估系統(tǒng)穩(wěn)定性和可靠性是否滿足要求的一方法。

性能測試類型包括：負載測試（指標變化），壓力測試（性能點），強度測試，容量測試，基準測試，滲入測試，峰谷測試

性能測試概括為三個方面：

應(yīng)用在客戶端性能的測試：負載測試和壓力測試應(yīng)用在網(wǎng)絡(luò)上性能的測試：應(yīng)用在服務(wù)器端性能的測試： Avg Rps: 平均每秒鐘響應(yīng)次數(shù)=總請求時間 / 秒數(shù)；Avg time to last byte per terstion （mstes）：平均每秒業(yè)務(wù)腳本的迭代次數(shù)，有人會把這兩者混淆；Successful Rounds：成功的請求；Failed Rounds ：失敗的請求；Successful Hits ：成功的點擊次數(shù)；Failed Hits ：失敗的點擊次數(shù)；Hits Per Second ：每秒點擊次數(shù)；Successful Hits Per Second ：每秒成功的點擊次數(shù)；Failed Hits Per Second ：每秒失敗的點擊次數(shù)；Attempted Connections ：嘗試鏈接數(shù)；

我們知道軟件架構(gòu)在實際測試中制約著測試策略和工具的選擇。如何選擇性能測試策略是我們在實際工作中需要了解的。一般軟件可以按照系統(tǒng)架構(gòu)分成幾種類型：

c/s

client/Server 客戶端/服務(wù)器架構(gòu)

基于客戶端/服務(wù)器的三層架構(gòu)

基于客戶端/服務(wù)器的分布式架構(gòu)

b/s

基于瀏覽器/Web服務(wù)器的三層架構(gòu)

基于中間件應(yīng)用服務(wù)器的三層架構(gòu)l

基于Web服務(wù)器和中間件的多層架構(gòu)l

由于工程和項目的不同，所選用的度量，評估方法也有不同之處。不過仍然有一些通用的步驟幫助我們完成一個性能測試項目。

步驟如下：

1． 制定目標和分析系統(tǒng)

2． 選擇測試度量的方法

3． 學(xué)習(xí)的相關(guān)技術(shù)和工具

4． 制定評估標準

5． 設(shè)計測試用例

6． 運行測試用例

7． 分析測試結(jié)果

具體：通過量、響應(yīng)時間、CPU負載、內(nèi)存使用

工具：QALoad、LoadRunner、Bench ** rk Factory、Webstress

過程：測試需求與測試內(nèi)容，測試案例制定，測試環(huán)境準備，測試腳本錄制、編寫與調(diào)試，腳本分配、回放配置性能測試圖像，性能測試圖像與加載策略，測試執(zhí)行跟蹤，結(jié)果分析與定位問題所在，測試報告與測試評估。

原則：

1）情況許可時，應(yīng)使用幾種測試工具或手段分別獨立進行測試，并將結(jié)果相互印證，避**一工具或測試手段自身缺陷影響結(jié)果的準確性；

2）對于不同的系統(tǒng)，性能關(guān)注點是有所區(qū)別的，應(yīng)該具體問題具體分析；

3）查找瓶頸的過程應(yīng)由易到難逐步排查：

服務(wù)器硬件瓶頸及網(wǎng)絡(luò)瓶頸（局域網(wǎng)環(huán)境下可以不考慮網(wǎng)絡(luò)因素）

應(yīng)用服務(wù)器及中間件操作系統(tǒng)瓶頸（數(shù)據(jù)庫、WEB服務(wù)器等參數(shù)配置）

應(yīng)用業(yè)務(wù)瓶頸（SQL語句、數(shù)據(jù)庫設(shè)計、業(yè)務(wù)邏輯、算法、數(shù)據(jù)等）

4）性能調(diào)優(yōu)過程中不宜對系統(tǒng)的各種參數(shù)進行隨意的改動，應(yīng)該以用戶配置手冊中相關(guān)參數(shù)設(shè)置為基礎(chǔ)，逐步根據(jù)實際現(xiàn)場環(huán)境進行優(yōu)化，一次只對某個領(lǐng)域進行性能調(diào)優(yōu)（例如對CPU的使用情況進行分析），并且每次只改動一個設(shè)置，避免相關(guān)因素互相干擾；

5）調(diào)優(yōu)過程中應(yīng)仔細進行記錄，保留每一步的操作內(nèi)容及結(jié)果，以便比較分析；

6）性能調(diào)優(yōu)是一個經(jīng)驗性的工作，需要多思考、分析、交流和積累；

7）了解“有限的資源，無限的需求”；

8）盡可能在開始前明確調(diào)優(yōu)工作的終止標準。

自動化測試

自動化測試是把以人為驅(qū)動的測試行為轉(zhuǎn)化為機器執(zhí)行的一種過程。通常，在設(shè)計了測試用例并通過評審之后，由測試人員根據(jù)測試用例中描述的規(guī)程一步步執(zhí)行測試，得到實際結(jié)果與期望結(jié)果的比較。在此過程中，為了節(jié)省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。

前提條件

實施自動化測試之前需要對軟件開發(fā)過程進行分析，以觀察其是否適合使用自動化測試。通常需要同時滿足以下條件：

1) 需求變動不頻繁

測試腳本的穩(wěn)定性決定了自動化測試的維護成本。如果軟件需求變動過于頻繁，測試人員需要根據(jù)變動的需求來較新測試用例以及相關(guān)的測試腳本，而腳本的維護本身就是一個代碼開發(fā)的過程，需要修改、調(diào)試，必要的時候還要修改自動化測試的框架，如果所花費的成本不**利用其節(jié)省的測試成本，那么自動化測試便是失敗的。

項目中的某些模塊相對穩(wěn)定，而某些模塊需求變動性很大。我們便可對相對穩(wěn)定的模塊進行自動化測試，而變動較大的仍是用手工測試。

2) 項目周期足夠長

自動化測試需求的確定、自動化測試框架的設(shè)計、測試腳本的編寫與調(diào)試均需要相當長的時間來完成，這樣的過程本身就是一個測試軟件的開發(fā)過程，需要較長的時間來完成。如果項目的周期比較短，沒有足夠的時間去支持這樣一個過程，那么自動化測試便成為笑談。

3) 自動化測試腳本可重復(fù)使用

如果費盡心思開發(fā)了一套近乎**的自動化測試腳本，但是腳本的重復(fù)使用率很低，致使其間所耗費的成本大于所創(chuàng)造的經(jīng)濟**，自動化測試便成為了測試人員的練手之作，而并非是真正可產(chǎn)生效益的測試手段了。

另外，在手工測試無法完成，需要投入大量時間與人力時也需要考慮引入自動化測試。比如性能測試、配置測試、大數(shù)據(jù)量輸入測試等。

適用場合

通常適合于軟件測試自動化的場合：

(1)回歸測試，重復(fù)單一的數(shù)據(jù)錄入或是擊鍵等測試操作造成了不必要的時間浪費和人力浪費；

(2)此外測試人員對程序的理解和對設(shè)計文檔的驗證通常也要借助于測試自動化工具；

(3)采用自動化測試工具有利于測試報告文檔的生成和版本的連貫性；

(4)自動化工具能夠確定測試用例的覆蓋路徑，確定測試用例集對程序邏輯流程和控制流程的覆蓋。

工具介紹：

QTP：創(chuàng)建測試、插入檢查點、檢驗數(shù)據(jù)、增強測試、運行測試、分析結(jié)果和維護測試等方面。（回歸測試）

WinRunner：企業(yè)級的功能測試工具，用于檢測應(yīng)用程序是否能夠達到預(yù)期的功能及正常運行。通過自動錄制、檢測和回放用戶的應(yīng)用操作。

QA Run：通過鼠標移動、鍵盤點擊操作被測應(yīng)用，繼而得到相應(yīng)的測試腳本，對該腳本可以進行編輯和調(diào)試。

AutoRunner：功能測試、回歸測試。

手機自動化測試：Monkey，Monkeyrunner，Appium（常用）

過程

自動化測試與軟件開發(fā)過程從本質(zhì)上來講是一樣的，無非是利用自動化測試工具（相當于軟件開發(fā)工具），經(jīng)過對測試需求的分析（軟件過程中的需求分析），設(shè)計出自動化測試用例（軟件過程中的需求規(guī)格），從而搭建自動化測試的框架（軟件過程中的概要設(shè)計），設(shè)計與編寫自動化腳本（詳細設(shè)計與編碼），測試腳本的正確性，從而完成該套測試腳本（即主要功能為測試的應(yīng)用軟件）。

1) 自動化測試需求分析。

當測試項目滿足了自動化的前提條件，并確定在該項目中需要使用自動化測試時，我們便開始進行自動化測試需求分析。此過程需要確定自動化測試的范圍以及相應(yīng)的測試用例、測試數(shù)據(jù)，并形成詳細的文檔，以便于自動化測試框架的建立。

2)自動化測試框架的搭建。

所謂自動化測試框架便是像軟件架構(gòu)一般，定義了在使用該套腳本時需要調(diào)用哪些文件、結(jié)構(gòu)，調(diào)用的過程，以及文件結(jié)構(gòu)如何劃分。

而根據(jù)自動化測試用例，我們很*能夠定位出自動化測試框架的典型要素：

a. 公用的對象。

不同的測試用例會有一些相同的對象被重復(fù)使用，比如窗口、按鈕、頁面等。這些公用的對象可被抽取出來，在編寫腳本時隨時調(diào)用。當這些對象的屬性因為需求的變更而改變時，只需要修改該對象屬性即可，而*修改所有相關(guān)的測試腳本。

b. 公用的環(huán)境。

各測試用例也會用到相同的測試環(huán)境，將該測試環(huán)境獨立封裝，在各個測試用例中靈活調(diào)用，也能增強腳本的可維護性。

c. 公用的方法。

當測試工具沒有需要的方法時，而該方法又會被經(jīng)常使用，我們便需要自己編寫該方法，以方便腳本的調(diào)用。

d. 測試數(shù)據(jù)。

也許一個測試用例需要執(zhí)行很多個測試數(shù)據(jù)，我們便可將測試數(shù)據(jù)放在一個獨立的文件中，由測試腳本執(zhí)行到該用例時讀取數(shù)據(jù)文件，從而達到數(shù)據(jù)覆蓋的目的。

在該框架中需要將這些典型要素考慮進去，在測試用例中抽取出公用的元素放入已定義的文件，設(shè)定好調(diào)用的過程。

性能和自動化的區(qū)別

常常有剛接觸自動化和性能測試的同學(xué)問我，感覺性能測試和自動化測試是差不多的，我自己剛接觸的時候認為也是差不多的，區(qū)別就是：自動化一個用戶再跑，性能測試需要并發(fā)，需要設(shè)計各種場景。慢慢的做的多了，發(fā)現(xiàn)兩者區(qū)別還是挺大的。

共同點：

接口的自動化測試和性能測試在處理腳本的方式上差不多，特別是使用JMeter、LR 這些工具測試的時候，例如測http協(xié)議的請求，只需模擬發(fā)送get或post方式的請求，接口腳本很*轉(zhuǎn)成性能測試腳本。但對于Web應(yīng)用來說，自動化測試和接口測試就大相徑庭了。

下面說下具體的差異吧。

差異：

1、測試角度不同

自動化測試和性能測試的出發(fā)點不一樣，也就是較終的目的不一樣。自動化測試是基于功能測試，案例也是來自功能測試，通常用做回歸測試，其實測的是業(yè)務(wù)，是功能。

性能測試考慮單個接口的性能，有時候不會太考慮整體的業(yè)務(wù)通不通，只需考慮需要壓測接口的性能表現(xiàn)，比如處理的tps、平均響應(yīng)時間、支持的并發(fā)用戶數(shù)。當然性能測試也會關(guān)注整個流程的測試。

比如有個做性能測試的小伙伴去做接口測試，就某一個產(chǎn)品的下單操作來說，做接口測試是為了查看下單這個功能是不是正常，他寫的接口測試腳本跟性能測試腳本一樣，只有一個下單的接口，下單之**些商品的查詢，賬戶的查詢都沒有做，這在業(yè)務(wù)上是不連貫的。

2、使用框架不同

如果說接口的自動化測試和性能測試在腳本處理上有些相同，就Web測試來說，二者就大相徑庭了。首先使用的框架就不一樣，Web自動化測試使用的是Selenium Webdriver，模擬的是點擊頁面的元素，性能測試還是錄腳本、發(fā)請求。一個主要是關(guān)注頁面元素，后端做了些什么完全是黑盒；一個需要關(guān)注發(fā)的請求有哪些，是post還是get，傳的參數(shù)是什么，后端的一些知識還是要了解下，有點像灰盒。

3、要掌握的技能不同

自動化測試偏重開發(fā)，對開發(fā)語言要求相對高些，如果只是配置現(xiàn)成的框架做自動化測試，那要求并不高。性能測試要了解的知識很多，腳本語言（C或者java等等）、操作系統(tǒng)（Linux，常用的監(jiān)控命令，出問題時分析線程）、數(shù)據(jù)庫（查詢語句、表的關(guān)聯(lián)、索引、Oracle的AWR 報表）；如果是**的性能測試，那還要懂架構(gòu)方面的知識。

總的來說，自動化測試偏向于開發(fā)，但要有測試的思維；性能測試要懂的知識點很多，真正**的性能測試也跟開發(fā)架構(gòu)師的水平差不多了。


中山立訊檢測有限公司專注于汽車零部件檢測,零部件可靠性測試,無損檢測,汽車零部件可靠性測試,立訊檢測等, 歡迎致電 13827624779

• 詞條

  詞條說明

• 亞馬遜歐洲站要求上傳新ERP能源標簽，否則會下掉listing

  今年以來，亞馬遜新規(guī)頻出，令人眼花繚亂。近期，賣家M向立訊檢測爆料一些歐洲站又收到一封郵件，亞馬遜告知，如果歐洲各大站點，2021年9月起需符合當?shù)谽RP標準，需要及時上傳能效標簽，不符要求的賣家將被暫停在相關(guān)品類下發(fā)布不合規(guī)商品。各位賣家請注意，歐盟能效法規(guī)指令即將實施，您必須要重視！01 歐盟能效標簽新規(guī)臨近，亞馬遜突發(fā)公告提醒賣家日前亞馬遜歐洲站發(fā)布重要公告，提醒賣家注意Listing新的能

• 什么是歐洲ERP能效標簽？不合規(guī)將面臨被亞馬遜下架風(fēng)險？

  今年以來，亞馬遜新規(guī)頻出，令人眼花繚亂。近期，賣家M向立訊檢測爆料一些歐洲站又收到一封郵件，亞馬遜告知，如果歐洲各大站點，2021年9月起需符合當?shù)谽RP標準，需要及時上傳能效標簽，不符要求的賣家將被暫停在相關(guān)品類下發(fā)布不合規(guī)商品。各位賣家請注意，歐盟能效法規(guī)指令即將實施，您必須要重視！01 歐盟能效標簽新規(guī)臨近，亞馬遜突發(fā)公告提醒賣家日前亞馬遜歐洲站發(fā)布重要公告，提醒賣家注意Listing新的能

• 德國站亞馬遜嚴查燈泡燈具EPREL注冊的能源標簽

  今年以來，亞馬遜新規(guī)頻出，令人眼花繚亂。近期，賣家M向立訊檢測爆料一些歐洲站又收到一封郵件，亞馬遜告知，如果歐洲各大站點，2021年9月起需符合當?shù)谽RP標準，需要及時上傳能效標簽，不符要求的賣家將被暫停在相關(guān)品類下發(fā)布不合規(guī)商品。各位賣家請注意，歐盟能效法規(guī)指令即將實施，您必須要重視！01 歐盟能效標簽新規(guī)臨近，亞馬遜突發(fā)公告提醒賣家日前亞馬遜歐洲站發(fā)布重要公告，提醒賣家注意Listing新的能

• 亞馬遜能效標簽新規(guī)，燈具燈泡歐洲ERP認證要求來了

  近日，有部分歐洲站賣家在某平臺反饋稱，他們的產(chǎn)品都遭到亞馬遜下架，而且都是因為產(chǎn)品無標簽原因。據(jù)了解，這部分賣家所銷售產(chǎn)品被亞馬遜認定缺少未展示或不符合能源標簽信息（EPREL），因此被亞馬遜做出下架處理。但是，也有一部分賣家反饋稱，他們遭到了亞馬遜誤判“我運營的是亞馬遜歐洲站，可是產(chǎn)品（例如彩色燈泡）并不需要此類標簽卻被平臺要求提供，之后進行申訴，客服卻讓我將剩余庫存全部移除之后才能進行后面的流