劉雪霞

摘要：軟件測(cè)試是軟件開(kāi)發(fā)生命周期中最重要的組成部分，在軟件開(kāi)發(fā)的整個(gè)生命周期中舉足輕重。敏捷測(cè)試是針對(duì)敏捷開(kāi)發(fā)的一種測(cè)試方式，注重團(tuán)隊(duì)的持續(xù)反饋和質(zhì)量保證，促進(jìn)傳統(tǒng)的軟件測(cè)試流程的改進(jìn)。針對(duì)目前主流的測(cè)試流程中存在的難點(diǎn)，文章從測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行、質(zhì)量評(píng)估、自動(dòng)化防護(hù)網(wǎng)等幾個(gè)方面提出改進(jìn)意見(jiàn)，可有效解決當(dāng)前軟件測(cè)試流程中存在的一些問(wèn)題，為一線的軟件測(cè)試人員和軟件測(cè)試的項(xiàng)目管理人員提供思路和方法。

關(guān)鍵詞：軟件測(cè)試流程；測(cè)試設(shè)計(jì)；測(cè)試執(zhí)行；自動(dòng)化防護(hù)

中圖分類號(hào)：TP3 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2024）11-0042-03

0 引言

軟件測(cè)試通常消耗40%～50%的軟件開(kāi)發(fā)時(shí)間，對(duì)于可靠性要求更高的系統(tǒng)，它消耗更多的精力[1]。軟件測(cè)試流程在有限的時(shí)間、成本和人力資源的條件下，如果測(cè)試流程設(shè)置正確，分配總資源的15%就可以實(shí)現(xiàn)適當(dāng)?shù)臏y(cè)試[2]。軟件測(cè)試并非在軟件產(chǎn)品的代碼編寫完成之后開(kāi)始，而是在整個(gè)軟件產(chǎn)品的研發(fā)過(guò)程中一直存在。軟件測(cè)試對(duì)軟件產(chǎn)品系統(tǒng)地、全面地進(jìn)行檢驗(yàn)，以確保軟件產(chǎn)品滿足功能和性能的要求。測(cè)試流程主要包括五個(gè)環(huán)節(jié)，分別是測(cè)試需求分析、測(cè)試計(jì)劃制定、測(cè)試用例設(shè)計(jì)、執(zhí)行測(cè)試用例，編寫測(cè)試報(bào)告。隨著敏捷開(kāi)發(fā)的流行，敏捷軟件測(cè)試越來(lái)越受到青睞，敏捷測(cè)試常采用迭代和增量的方式進(jìn)行測(cè)試。隨著敏捷開(kāi)發(fā)節(jié)奏的加快，敏捷測(cè)試對(duì)整個(gè)測(cè)試流程和測(cè)試人員提出了更高的要求，從而暴露了測(cè)試流程中的一些問(wèn)題，本文著重針對(duì)敏捷測(cè)試流程在實(shí)際的生產(chǎn)中存在的問(wèn)題提出改進(jìn)的方案和方法。

1 軟件測(cè)試

1.1 軟件測(cè)試定義

軟件測(cè)試是對(duì)軟件需求分析、設(shè)計(jì)規(guī)格說(shuō)明和編碼的最終檢查，是保證軟件質(zhì)量的關(guān)鍵步驟[3]。軟件測(cè)試是一種用來(lái)判定軟件的完整性、正確性、安全性和質(zhì)量的過(guò)程。1983年，IEEE定義的軟件測(cè)試是使用人工或自動(dòng)化的手段來(lái)運(yùn)行或測(cè)定某個(gè)軟件系統(tǒng)的過(guò)程[5]。其目的在于檢驗(yàn)它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實(shí)際結(jié)果之間的差別。

1.2 軟件測(cè)試流程

軟件測(cè)試的流程管理非常重要，它關(guān)系到軟件質(zhì)量是否達(dá)標(biāo)。軟件測(cè)試的生命周期覆蓋整個(gè)軟件開(kāi)發(fā)階段，且有一套完整嚴(yán)格的流程來(lái)保證項(xiàng)目產(chǎn)品的正確準(zhǔn)時(shí)交付，軟件測(cè)試介入得越早，越能節(jié)約整個(gè)開(kāi)發(fā)的成本。測(cè)試流程主要包含：需求分析評(píng)審、測(cè)試計(jì)劃制定、測(cè)試設(shè)計(jì)、測(cè)試用例評(píng)審、測(cè)試用例執(zhí)行、測(cè)試報(bào)告編寫，每一個(gè)環(huán)節(jié)都至關(guān)重要。

2 當(dāng)前軟件測(cè)試流程深度剖析與改進(jìn)

2.1 測(cè)試設(shè)計(jì)場(chǎng)景不全

測(cè)試設(shè)計(jì)活動(dòng)一般分為針對(duì)產(chǎn)品新需求的測(cè)試設(shè)計(jì)和產(chǎn)品繼承功能的測(cè)試設(shè)計(jì)。測(cè)試設(shè)計(jì)與功能需求的關(guān)系如圖1所示。測(cè)試策略包含測(cè)試設(shè)計(jì)策略和測(cè)試執(zhí)行策略，根據(jù)新需求、繼承功能特性及場(chǎng)景測(cè)試來(lái)設(shè)計(jì)測(cè)試用例庫(kù)，從新需求和繼承特性測(cè)試設(shè)計(jì)測(cè)試用例的基線庫(kù)，同時(shí)考慮測(cè)試因子和可靠性測(cè)試，提高測(cè)試用例的復(fù)用性。

針對(duì)測(cè)試設(shè)計(jì)場(chǎng)景不全問(wèn)題，可以從以下幾個(gè)方面著手改進(jìn)。

2.1.1 梳理測(cè)試特性樹(shù)

需求是客戶提出的問(wèn)題，包括需求背景、應(yīng)用場(chǎng)景等；特性是客戶需求的系統(tǒng)實(shí)現(xiàn)，通過(guò)開(kāi)發(fā)活動(dòng)把客戶問(wèn)題轉(zhuǎn)變?yōu)橄到y(tǒng)功能。梳理特性樹(shù)可以幫助準(zhǔn)確把握客戶需求。測(cè)試特性樹(shù)與軟件開(kāi)發(fā)的功能樹(shù)同源，如圖2所示，測(cè)試特性樹(shù)中的一級(jí)、二級(jí)、三級(jí)特性分別對(duì)應(yīng)全量功能樹(shù)中的一級(jí)、二級(jí)、三級(jí)特性，針對(duì)三級(jí)特性詳細(xì)設(shè)計(jì)測(cè)試用例，盡量避免測(cè)試場(chǎng)景遺漏問(wèn)題。

2.1.2 梳理測(cè)試因子庫(kù)

測(cè)試因子是指測(cè)試設(shè)計(jì)中需要考量的影響因素，如環(huán)境與測(cè)試難易程度等。正確地梳理測(cè)試因子有助于避免測(cè)試遺漏。測(cè)試設(shè)計(jì)本身是一個(gè)先發(fā)散后綜合的過(guò)程，在發(fā)散階段，盡可能地考慮所有可能會(huì)對(duì)測(cè)試產(chǎn)生影響的因素，提取測(cè)試影響因子；綜合階段通過(guò)合適的覆蓋方法，把前者整合成測(cè)試用例。從幾個(gè)方面提取測(cè)試因子庫(kù)：分析待測(cè)試的新特性，分析繼承特性、以往積累的經(jīng)驗(yàn)，分析測(cè)試遺漏等，然后基于測(cè)試因子庫(kù)去做測(cè)試設(shè)計(jì)和測(cè)試用例的輸出，同時(shí)在測(cè)試設(shè)計(jì)過(guò)程中提取測(cè)試因子，通過(guò)對(duì)提取的測(cè)試因子評(píng)審取舍，填充豐富當(dāng)前的測(cè)試因子庫(kù)。測(cè)試因子庫(kù)需要不斷的維護(hù)和豐富，便于后續(xù)測(cè)試設(shè)計(jì)的可持續(xù)使用。

2.1.3 梳理故障模式庫(kù)

可靠性測(cè)試的主要目的是評(píng)估產(chǎn)品或系統(tǒng)在特定條件下的可靠性和穩(wěn)定性。測(cè)試軟件功能的異常情況，可以幫助確定產(chǎn)品或系統(tǒng)在正常使用期間的故障率，并確定是否需要進(jìn)行改進(jìn)以提高可靠性和穩(wěn)定性。針對(duì)可靠性測(cè)試梳理故障模式庫(kù)，在后續(xù)版本中復(fù)用，提高測(cè)試效率和軟件版本質(zhì)量。

2.1.4 現(xiàn)網(wǎng)問(wèn)題回溯改進(jìn)

針對(duì)現(xiàn)網(wǎng)問(wèn)題及時(shí)復(fù)盤，進(jìn)行測(cè)試的回溯和改進(jìn)，完成測(cè)試遺漏，考慮是否加入因子庫(kù)，防止后續(xù)出現(xiàn)類似現(xiàn)網(wǎng)問(wèn)題，確保不斷提升軟件產(chǎn)品質(zhì)量。

2.1.5 知識(shí)技能地圖

軟件測(cè)試是一個(gè)知識(shí)密集型的過(guò)程，因而可使用對(duì)知識(shí)管理的原則和技術(shù)來(lái)管理軟件測(cè)試知識(shí)[5]。針對(duì)團(tuán)隊(duì)業(yè)務(wù)，梳理測(cè)試人員需要掌握的技能和知識(shí)，以此構(gòu)建測(cè)試知識(shí)地圖，便于團(tuán)隊(duì)成員業(yè)務(wù)能力的提升，提高測(cè)試效率，同時(shí)需要定期維護(hù)和更新知識(shí)技能地圖。

2.2 測(cè)試執(zhí)行進(jìn)展跟蹤煩瑣

測(cè)試執(zhí)行是軟件測(cè)試過(guò)程中的重要環(huán)節(jié)，很多原因會(huì)導(dǎo)致測(cè)試執(zhí)行進(jìn)展跟蹤煩瑣，比如測(cè)試過(guò)程中，測(cè)試人員需要對(duì)不同平臺(tái)和不同版本的功能模塊進(jìn)行測(cè)試；測(cè)試工具的不完善，已有的測(cè)試工具不足以覆蓋當(dāng)前的測(cè)試內(nèi)容，需要手工測(cè)試，并詳細(xì)記錄測(cè)試過(guò)程和結(jié)果，無(wú)疑增加了測(cè)試的難度；多個(gè)開(kāi)發(fā)迭代，測(cè)試用例多及用例可自動(dòng)化率低等?？梢詮囊韵聨讉€(gè)方面改善測(cè)試執(zhí)行進(jìn)展跟蹤煩瑣。

1） 提前準(zhǔn)備測(cè)試環(huán)境。提前準(zhǔn)備測(cè)試環(huán)境，可提高測(cè)試人員的執(zhí)行效率，縮短測(cè)試執(zhí)行時(shí)間，從而有效提高產(chǎn)品質(zhì)量。

2） 跟蹤開(kāi)發(fā)人員轉(zhuǎn)測(cè)，提前反饋風(fēng)險(xiǎn)。有效的溝通和協(xié)作是確保軟件質(zhì)量的關(guān)鍵之一。及時(shí)準(zhǔn)確地跟蹤開(kāi)發(fā)的需求轉(zhuǎn)測(cè)具體時(shí)間，有助于軟件質(zhì)量的保證，若有風(fēng)險(xiǎn)，提前反饋，避免時(shí)間和人力成本的過(guò)度投入，節(jié)約成本。

3） 重視測(cè)試進(jìn)展同步，嚴(yán)把回歸測(cè)試。迭代開(kāi)發(fā)周期短，任務(wù)緊，確保每個(gè)版本所有需求，例行同步測(cè)試的進(jìn)展，識(shí)別阻塞問(wèn)題，并及時(shí)組織開(kāi)發(fā)人員合入解決，嚴(yán)把回歸測(cè)試。

2.3 自動(dòng)化防護(hù)網(wǎng)

自動(dòng)化防護(hù)網(wǎng)能有效解決修改引入問(wèn)題，軟件開(kāi)發(fā)的過(guò)程中，經(jīng)常會(huì)出現(xiàn)開(kāi)發(fā)版本修改某些bug之后，需要測(cè)試人員再次測(cè)試版本的情況。這個(gè)過(guò)程引入的一些修改，有可能導(dǎo)致一些潛在的問(wèn)題或錯(cuò)誤，甚至影響修改前軟件的正常運(yùn)行。解決此問(wèn)題，重點(diǎn)關(guān)注建立健全自動(dòng)化防護(hù)網(wǎng)，確保全量用例自動(dòng)化每版本例行運(yùn)行，實(shí)時(shí)發(fā)現(xiàn)修改引入問(wèn)題，這將極大地提高軟件質(zhì)量和交付效率。

2.4 用例自動(dòng)化完成緩慢

軟件自動(dòng)化測(cè)試是目前軟件開(kāi)發(fā)生命周期中應(yīng)用最廣泛的方法，這是確保軟件質(zhì)量的主要手段。軟件測(cè)試用例自動(dòng)化完成緩慢的原因可能有多種：測(cè)試用例復(fù)雜度高、缺乏統(tǒng)一的測(cè)試框架和測(cè)試規(guī)范、自動(dòng)化依賴配置和測(cè)試環(huán)境問(wèn)題?？梢詮囊韵聨讉€(gè)方面著手加速測(cè)試用例的自動(dòng)化完成：1） 測(cè)試團(tuán)隊(duì)成員賦能，納入測(cè)試人員必備能力，測(cè)試執(zhí)行完成的同時(shí)要求自動(dòng)化寫作完成。2） 制定明確可行的測(cè)試計(jì)劃和測(cè)試預(yù)期目標(biāo)。3） 采用合適的自動(dòng)化框架，提升代碼復(fù)用率。4） 測(cè)試用例優(yōu)先級(jí)排序，將優(yōu)先級(jí)高的用例先完成自動(dòng)化，有助于更早地發(fā)現(xiàn)問(wèn)題。

2.5 測(cè)試質(zhì)量評(píng)估

軟件測(cè)試過(guò)程中的關(guān)鍵任務(wù)之一是測(cè)試質(zhì)量評(píng)估，測(cè)試質(zhì)量評(píng)估是為了說(shuō)明某個(gè)階段的測(cè)試開(kāi)展的充分性和質(zhì)量目標(biāo)是否達(dá)標(biāo)，并且給出質(zhì)量總結(jié)結(jié)論輸出，幫助測(cè)試團(tuán)隊(duì)改進(jìn)測(cè)試策略和流程，為軟件質(zhì)量提供有力的支撐和保證。測(cè)試質(zhì)量評(píng)估除了常規(guī)的測(cè)試用例設(shè)計(jì)和覆蓋、測(cè)試執(zhí)行的有效性、缺陷的管理、測(cè)試結(jié)果的分析報(bào)告等，還可以通過(guò)側(cè)重以下質(zhì)量度量指標(biāo)，提升測(cè)試質(zhì)量評(píng)估的有效性。

2.5.1 代碼覆蓋率

基于代碼覆蓋率提升產(chǎn)品測(cè)試質(zhì)量和測(cè)試工程能力。代碼覆蓋率著重顯示未覆蓋的代碼有多少。開(kāi)發(fā)人員借助代碼覆蓋率分析未覆蓋的代碼，以此幫助測(cè)試人員完善和補(bǔ)充測(cè)試用例和場(chǎng)景，通過(guò)代碼覆蓋率，測(cè)試人員和開(kāi)發(fā)人員建立協(xié)同和紐帶。

2.5.2 代碼缺陷密度

軟件代碼缺陷密度用來(lái)評(píng)估軟件代碼中缺陷的數(shù)量，它統(tǒng)計(jì)在特定代碼范圍內(nèi)，缺陷數(shù)量與代碼行數(shù)或者函數(shù)數(shù)量的比率。缺陷密度值越大，代碼范圍內(nèi)存在的缺陷數(shù)量越多，代碼質(zhì)量越低，反之，缺陷密度值越小，代碼質(zhì)量越高，對(duì)項(xiàng)目進(jìn)展影響相對(duì)較小。

2.5.3 缺陷分析

缺陷數(shù)據(jù)是最有效的質(zhì)量分析手段之一，反映被測(cè)對(duì)象的質(zhì)量信息。缺陷分析是對(duì)軟件產(chǎn)品質(zhì)量進(jìn)行定量表示和定性分析，缺陷分析可以更準(zhǔn)確地把控產(chǎn)品的開(kāi)發(fā)成本、進(jìn)度和質(zhì)量。缺陷分析的作用和目的是：理解、評(píng)估、預(yù)測(cè)、改進(jìn)。通過(guò)對(duì)缺陷數(shù)據(jù)的定量和定性分析，獲得對(duì)軟件產(chǎn)品的內(nèi)在規(guī)律的認(rèn)識(shí)，便于預(yù)測(cè)后續(xù)的基線。對(duì)比實(shí)際缺陷與質(zhì)量目標(biāo)的偏差，評(píng)估產(chǎn)品質(zhì)量。建立缺陷模型，為后續(xù)制定測(cè)試計(jì)劃和調(diào)整測(cè)試策略提供依據(jù)?；谌毕莘治鼋Y(jié)果提煉改進(jìn)點(diǎn)，對(duì)問(wèn)題進(jìn)行溯源，并制定改進(jìn)措施。缺陷分析的方法可分為以下維度：根因分析、過(guò)程改進(jìn)、分類分析、質(zhì)量評(píng)估。

2.6 云測(cè)試報(bào)告

軟件測(cè)試的主要工作除了測(cè)試計(jì)劃制定、測(cè)試方案和用例設(shè)計(jì)、測(cè)試執(zhí)行、回歸測(cè)試等，測(cè)試報(bào)告輸出也是關(guān)鍵性的工作之一，且必不可少。測(cè)試報(bào)告要詳細(xì)記錄測(cè)試過(guò)程和結(jié)果，包括測(cè)試用例的執(zhí)行情況、缺陷的發(fā)現(xiàn)和修復(fù)情況等。為了確保報(bào)告的準(zhǔn)確性和完整性，測(cè)試團(tuán)隊(duì)需要投入大量的時(shí)間和精力，對(duì)測(cè)試數(shù)據(jù)進(jìn)行收集、分析和整理。由于軟件版本迭代快和測(cè)試場(chǎng)景的復(fù)雜性等，測(cè)試報(bào)告單純由人工輸出，勢(shì)必占用太多時(shí)間，需要采取有效的方法應(yīng)對(duì)。

采用自動(dòng)化云平臺(tái)或者工具，自動(dòng)統(tǒng)計(jì)需求編號(hào)，管理用例執(zhí)行情況，需求發(fā)現(xiàn)的問(wèn)題及閉環(huán)情況，做到一鍵式生成測(cè)試報(bào)告，從而減輕測(cè)試工作人員的負(fù)擔(dān)。云測(cè)試報(bào)告平臺(tái)，如圖3所示，由三個(gè)模塊組成：云測(cè)試報(bào)告模塊、云文檔管理模塊、云測(cè)試數(shù)據(jù)源管理模塊。其中，云測(cè)試報(bào)告模塊是核心模塊。云文檔管理模塊負(fù)責(zé)管理上傳的測(cè)試報(bào)告模板，云測(cè)試數(shù)據(jù)源管理模塊負(fù)責(zé)管理測(cè)試數(shù)據(jù)，如測(cè)試用例、缺陷匯總、缺陷分析等，云測(cè)試報(bào)告模塊通過(guò)模板新建云測(cè)試報(bào)告，使用云測(cè)試數(shù)據(jù)源導(dǎo)入相關(guān)測(cè)試數(shù)據(jù)，并進(jìn)行云測(cè)試報(bào)告的在線編輯，最終生成測(cè)試報(bào)告。

3 結(jié)束語(yǔ)

本文針對(duì)軟件測(cè)試的部分流程進(jìn)行了深刻的分析，并對(duì)測(cè)試流程中的痛點(diǎn)提出了改進(jìn)的措施和方法，對(duì)測(cè)試場(chǎng)景設(shè)計(jì)不全，測(cè)試執(zhí)行進(jìn)展的跟蹤、自動(dòng)化防護(hù)網(wǎng)建立與維護(hù)、用例自動(dòng)化完成緩慢、測(cè)試質(zhì)量評(píng)估、云測(cè)試報(bào)告等分別進(jìn)行分析，提出改進(jìn)措施，為一線的軟件測(cè)試人員和軟件測(cè)試的項(xiàng)目管理人員提供思路和方法。

參考文獻(xiàn)：

[1] BHADAURIA S S，KOTHARI A，PRASAD L. Design architecture class diagram for a comprehensive testing tool[J]. Oriental Journal of Computer Science and Technology，2011，4（2）：281-292.

[2] VUKOVIC V，DJURKOVIC J，TRNINIC J. A business software testing process-based model design[J]. International Journal of Software Engineering and Knowledge Engineering，2018，28（5）：701-749.

[3] 宮云戰(zhàn). 軟件測(cè)試教程[M]. 3版. 北京：機(jī)械工業(yè)出版社，2022.

[4] 王娜，萬(wàn)嵩，胡君. 軟件測(cè)試：雙色版[M]. 哈爾濱：東北林業(yè)大學(xué)出版社，2020.

[5] DE SOUZA ? F，DE ALMEIDA FALBO R，VIJAYKUMAR N L. Knowledge management initiatives in software testing：a mapping study[J]. Information and Software Technology，2015，57：378-391.

【通聯(lián)編輯：朱寶貴】