不管做什么事情，都需要提前進(jìn)行檢查，那么，其檢查的意義是什么呢？是為了該事情能夠順利進(jìn)展。那么，軟件的測(cè)試也是一樣，都是為了確保該產(chǎn)品能夠正式上線所做的一些準(zhǔn)備。上一篇中，米么信息給大家介紹了用戶(hù)體驗(yàn)，那么，今天就來(lái)說(shuō)一說(shuō)測(cè)試對(duì)于一款軟件的意義吧。

一、什么是軟件測(cè)試？

軟件測(cè)試是一項(xiàng)檢查實(shí)際結(jié)果是否符合預(yù)期結(jié)果并確保軟件系統(tǒng)沒(méi)有缺陷的活動(dòng)。軟件測(cè)試還有助于識(shí)別不符合實(shí)際需求或缺少項(xiàng)目的產(chǎn)品。測(cè)試活動(dòng)可以手動(dòng)或自動(dòng)化工具進(jìn)行。有些人喜歡稱(chēng)軟件測(cè)試為白盒測(cè)試和黑盒測(cè)試。

二、為什么需要測(cè)試

往往許多人都使用自動(dòng)化工具進(jìn)行測(cè)試，原因主要有兩點(diǎn)：

1、保證這個(gè) commit不會(huì)影響其他部分的邏輯。

2、保證這個(gè) commit的功能代碼沒(méi)有任何 bug。

第一點(diǎn)是最重要的因素。想象一下，你還記得一個(gè)月前在一個(gè)大項(xiàng)目中寫(xiě)的代碼嗎？您記得小伙伴提交的是什么代碼嗎？您知道這個(gè)代碼對(duì)上下游之間的影響嗎？到那時(shí)，自動(dòng)化測(cè)試的好處就很明顯了，它可以在更短的時(shí)間內(nèi)確定 commit對(duì)整個(gè)邏輯的影響，如果整個(gè)自動(dòng)化測(cè)試用例都被忽略，那么它影響其他業(yè)務(wù)邏輯部分的可能性就很小。假如我們正在建造一座大廈，自動(dòng)化測(cè)試將確保每一塊磚頭、每一粒沙子都符合質(zhì)檢要求。

《快速軟件開(kāi)發(fā)》指出，修正bug的代價(jià)是bug出生時(shí)修正的代價(jià)的10倍。小編認(rèn)為，對(duì)于比較復(fù)雜的系統(tǒng)，成本遠(yuǎn)遠(yuǎn)不止10倍。磨刀不誤砍柴，在研發(fā)過(guò)程中，自動(dòng)化測(cè)試是銳利的寶劍，在一定程度上有效地保證了合并代碼的可靠性，是快速反復(fù)的基礎(chǔ)之一，最終提高了研發(fā)效率，保證了產(chǎn)品質(zhì)量。

防火勝于救火，我們必須用各種手段盡量避免bug，不要制作漸進(jìn)、有成就感的開(kāi)發(fā)狀態(tài)，制作出不同的shit，每個(gè)人都成為救火隊(duì)員。

三、測(cè)試的分類(lèi)

從層次的緯度，可以將測(cè)試分為三類(lèi)：單元測(cè)試、集成測(cè)試、性能測(cè)試

1、單元測(cè)試是面向函數(shù)級(jí)的、由開(kāi)發(fā)者編寫(xiě)的、用于測(cè)試一個(gè)或多個(gè)函數(shù)功能的測(cè)試用例。單元測(cè)試環(huán)境應(yīng)該易于構(gòu)建和運(yùn)行，通常運(yùn)行時(shí)不依賴(lài)其他服務(wù)：例如數(shù)據(jù)庫(kù)、緩存、第三方服務(wù)等等，因此 mock框架常常需要生成其他依賴(lài)項(xiàng)，這樣有助于提高開(kāi)發(fā)效率。單元測(cè)試集中于覆蓋范圍，通常大約70-80%的覆蓋范圍能夠滿(mǎn)足大多數(shù)場(chǎng)景。

2、集成測(cè)試是一個(gè)面向API的測(cè)試用例，由開(kāi)發(fā)人員/測(cè)試人員編寫(xiě)，用來(lái)測(cè)試一個(gè)或多個(gè)API是否正常工作，以及多個(gè)組件是否相互協(xié)作正常工作。集成測(cè)試環(huán)境的構(gòu)建相對(duì)復(fù)雜，可能依賴(lài)于數(shù)據(jù)庫(kù)、緩存、第三方服務(wù)等，而且一般都是大家分享的。

3、性能測(cè)試主要用于測(cè)試性能、分析性能瓶頸等。類(lèi)似于高級(jí)測(cè)試。受各種條件的影響，不同應(yīng)用的性能測(cè)試方法是不一樣的，這里不展開(kāi)。

通常常情況下，每次commit都要先跑單元測(cè)試和集成測(cè)試，然后才能提交。每次發(fā)布上線，都必須確保發(fā)布的版本可以通過(guò)單元測(cè)試和集成測(cè)試，有些應(yīng)用甚至要求跑單性能測(cè)試。

四、什么時(shí)候更需要測(cè)試

1、項(xiàng)目的核心程度

不用說(shuō)，核心項(xiàng)目越多，需要越多的測(cè)試用例來(lái)確保其代碼質(zhì)量。

2、代碼量

測(cè)試用例越多，整個(gè)項(xiàng)目的代碼越多，就越需要保證其質(zhì)量。大量代碼意味著理解所有邏輯變得更加困難，而且每一次 commit都會(huì)產(chǎn)生更多的不確定性。個(gè)別人認(rèn)為，當(dāng)功能代碼在數(shù)千行時(shí)，您可以自己決定是否需要測(cè)試；當(dāng)功能代碼超過(guò)5000行時(shí)，請(qǐng)補(bǔ)充單元測(cè)試；如果應(yīng)用程序具有 API，請(qǐng)補(bǔ)充集成測(cè)試。

3、開(kāi)發(fā)人員數(shù)量

開(kāi)發(fā)人員的數(shù)量越多，測(cè)試用例就越必要。開(kāi)發(fā)人員越多，特別是水平不一致時(shí)，交流成本大幅度增加，研發(fā)效率下降，導(dǎo)入缺陷的概率增加。因此，開(kāi)發(fā)人員越多，就越需要自動(dòng)門(mén)檻，過(guò)濾低質(zhì)量的commit。

4、編程語(yǔ)言

通常情況下，動(dòng)態(tài)類(lèi)型語(yǔ)言在運(yùn)行時(shí)進(jìn)行數(shù)據(jù)類(lèi)型檢查，例如python、ruby，而靜態(tài)類(lèi)型語(yǔ)言需要嚴(yán)格定義數(shù)據(jù)類(lèi)型，并在編譯過(guò)程中檢查數(shù)據(jù)類(lèi)型，例如c。因此python等動(dòng)態(tài)類(lèi)型語(yǔ)言需要測(cè)試的不僅僅是靜態(tài)語(yǔ)言。

5、項(xiàng)目研發(fā)周期

對(duì)開(kāi)放源碼項(xiàng)目來(lái)說(shuō)，一般的開(kāi)放源碼項(xiàng)目都有大量的測(cè)試用例，在進(jìn)行任何開(kāi)發(fā)和迭代之前，建議您先構(gòu)建 CI/CD，然后逐步迭代。

對(duì)于自行開(kāi)發(fā)的項(xiàng)目，在項(xiàng)目開(kāi)發(fā)初期，需要進(jìn)行架構(gòu)設(shè)計(jì)，選擇一些重要的第三方模塊。所以項(xiàng)目初期的不確定性會(huì)比較大。如果測(cè)試框架和用例設(shè)計(jì)得太早，很容易成為絆腳石，降低研發(fā)效率。當(dāng)項(xiàng)目結(jié)構(gòu)相對(duì)穩(wěn)定時(shí)，核心模塊已經(jīng)選定，基本功能可用。需要給項(xiàng)目增加一個(gè)測(cè)試框架，補(bǔ)充測(cè)試用例，達(dá)到一定的覆蓋率，為以后的迭代開(kāi)發(fā)提供堅(jiān)實(shí)的基礎(chǔ)。

以上便是米么信息整理的測(cè)試對(duì)于軟件的意義，如果有軟件開(kāi)發(fā)方面的需求，歡迎上米么信息咨詢(xún)！