遞推循環(huán)在軟件測(cè)試管理的應(yīng)用與研究

◆劉 陽

（江蘇無線電有限公司 江蘇 210022）

1 引言

隨著信息化時(shí)代的高速發(fā)展，計(jì)算機(jī)軟件在其中占據(jù)了舉足輕重的地位，軟件測(cè)試及其開發(fā)作為軟件工程中保證和控制產(chǎn)品質(zhì)量的有效活動(dòng)，也發(fā)揮著越來越重要的作用。那么面對(duì)種類繁多的軟件產(chǎn)品和不同級(jí)別的設(shè)計(jì)階段，如何在盡量節(jié)省時(shí)間和成本的基礎(chǔ)上更加高效全面地完成測(cè)試工作呢？將遞推循環(huán)原理應(yīng)用于軟件測(cè)試開發(fā)管理工作將能夠解決這一問題。

2 軟件測(cè)試概述

2.1 軟件測(cè)試的現(xiàn)狀

目前國內(nèi)軟件測(cè)試行業(yè)處于起步階段，正是蓬勃發(fā)展的時(shí)期，市場對(duì)軟件測(cè)試崗位的需求日益增多，每年的從業(yè)人員也越來越多，軟件測(cè)試在整個(gè)產(chǎn)品生命周期中的重要性日益顯著。然而，也因?yàn)樘幱诔跏茧A段，所以軟件測(cè)試行業(yè)還存在許多不完善之處，主要表現(xiàn)為以下幾點(diǎn)[1]：

（1）軟件測(cè)試過程管理混亂，統(tǒng)一規(guī)范化體系不夠健全；

（2）測(cè)試自動(dòng)化集成化程度比較低；

（3）測(cè)試人員的整體素質(zhì)參差不齊。

2.2 軟件測(cè)試的原則[2]

（1）測(cè)試說明缺陷的存在，而不能說明缺陷不存在；

（2）窮盡測(cè)試是不可能的；

（3）測(cè)試的盡早介入可以節(jié)省時(shí)間和成本；

（4）缺陷的群集效應(yīng)；

（5）殺蟲劑悖論；

（6）測(cè)試活動(dòng)依賴于測(cè)試周境；

（7）不存在缺陷的謬論。

3 常見的組織方式

目前不同性質(zhì)的軟件行業(yè)中，常見的組織方式主要有無規(guī)則分組式管理模式、重點(diǎn)式管理模式和分級(jí)式管理模式。

3.1 無規(guī)則分組式管理模式

軟件測(cè)試過程中沒有確定的分組規(guī)則，或者過程中分組標(biāo)準(zhǔn)經(jīng)常性改變。

此方式下測(cè)試人員只熟悉自己負(fù)責(zé)的模塊，對(duì)于其他的軟件模塊了解將不深入，最后導(dǎo)致遺漏部分測(cè)試點(diǎn)。倘若不停地變換分組規(guī)則，意圖每個(gè)人均深入掌握整個(gè)軟件系統(tǒng)，那么在總體代碼規(guī)模較多的情況下工作將會(huì)費(fèi)時(shí)費(fèi)力、可行度差；還會(huì)導(dǎo)致后期測(cè)試人員將無所適從，集成化測(cè)試腳本開發(fā)和應(yīng)用變得困難。

3.2 重點(diǎn)式管理模式

重點(diǎn)式測(cè)試是指在軟件測(cè)試過程中只測(cè)試核心部分或者在某一階段時(shí)只執(zhí)行節(jié)點(diǎn)緊急而又必須要進(jìn)行的測(cè)試。

這種方式絕大部分出現(xiàn)在軟件測(cè)試時(shí)間緊張、測(cè)試任務(wù)遠(yuǎn)遠(yuǎn)大于節(jié)點(diǎn)安排的情況下，選取軟件的核心代碼和重要功能、問題較多的部分、軟件臨時(shí)修改的部分等進(jìn)行重點(diǎn)測(cè)試執(zhí)行。這種方式的弊端是沒有全量測(cè)試軟件，軟件測(cè)試是不充分的。

3.3 分級(jí)式管理模式

分級(jí)式模式常見于第三方測(cè)試性質(zhì)的公司，通常包括三方測(cè)試、鑒定/定型測(cè)試等。也是較為正規(guī)的測(cè)試模式，但是在每一級(jí)別測(cè)試都是對(duì)軟件完全覆蓋的、獨(dú)立的測(cè)試，通常前后階段是不同組織去執(zhí)行，造成時(shí)間成本上的浪費(fèi)，而且各個(gè)級(jí)別測(cè)試成果在后續(xù)的過程中失去了作用。通常每個(gè)測(cè)試人員責(zé)任明確，人員的突然調(diào)動(dòng)對(duì)整個(gè)項(xiàng)目進(jìn)度與效果的影響也非常大[3]。

4 基本概念

4.1 遞推循環(huán)

遞推法是根據(jù)某一確定的規(guī)律公式逐級(jí)推導(dǎo)，最后得出正確結(jié)果的過程。遞推循環(huán)可以認(rèn)為遞推過程是一個(gè)閉環(huán)，至少需要一個(gè)往復(fù)的運(yùn)算[4]。比如，秒表計(jì)數(shù)就是一個(gè)簡單的舉例。因此在遞推循環(huán)的過程中必然需要迭代的運(yùn)算方式[5]，即繼承之前運(yùn)算/活動(dòng)的成果，修改完善當(dāng)前的運(yùn)算/活動(dòng)繼續(xù)執(zhí)行，達(dá)到一個(gè)不斷提升的效果。

4.2 統(tǒng)計(jì)分組法

統(tǒng)計(jì)分組法是一種常用的解決問題的方法，屬于統(tǒng)計(jì)學(xué)范疇。統(tǒng)計(jì)分組法就是根據(jù)確定的標(biāo)準(zhǔn)將總體分解為若干個(gè)體的方式。依據(jù)分組標(biāo)準(zhǔn)的種類數(shù)量來劃分，可以分為簡單分組和復(fù)合分組[6]。為軟件工程提供高效的測(cè)試執(zhí)行管理方式，前期需要對(duì)測(cè)試對(duì)象→軟件系統(tǒng)進(jìn)行合理的分組。

4.2.1 分組的類型

基于軟件產(chǎn)品本身具有多方向、多特性的特點(diǎn)，對(duì)軟件系統(tǒng)分組往往不能局限于某一個(gè)標(biāo)準(zhǔn)，所以對(duì)軟件分組應(yīng)是一個(gè)復(fù)合分組的過程。

4.2.2 分組標(biāo)準(zhǔn)的選擇

（1）對(duì)軟件系統(tǒng)分解的組數(shù)與實(shí)際軟件測(cè)試人員人數(shù)一致； （2）代碼規(guī)模是表征軟件工作量的主要參數(shù)； （3）代碼中函數(shù)和類的數(shù)量是反映軟件結(jié)構(gòu)的主要參數(shù)； （4）軟件需求決定了測(cè)試類型，也決定了測(cè)試難易程度； （5）測(cè)試的自動(dòng)化程度，測(cè)試腳本和工具開發(fā)的工作量；等等。

5 建立模型

假設(shè)目前具備一套軟件系統(tǒng)、測(cè)試人員甲、測(cè)試人員乙、測(cè)試人員丙、配置管理人員丁、質(zhì)量保證人員戌。軟件測(cè)試的環(huán)境及其他前提條件均滿足。

本模型以3 元為一組建立，理想情況下以平分工作量的標(biāo)準(zhǔn)將軟件系統(tǒng)分為軟件分系統(tǒng)1、軟件分系統(tǒng)2、軟件分系統(tǒng)3 共三組；將軟件測(cè)試過程分為軟件研發(fā)、軟件測(cè)試、軟件發(fā)布、軟件維護(hù)四個(gè)階段。模型元素表見表1。

表1 模型元素表

遞推公式：an= an-1+ 1；

遞推循環(huán)管理流程圖如圖1：

圖1 模型流程圖

5.1 模型分析

根據(jù)上圖可以看出：模型的主體在于測(cè)試人員甲、乙、丙3人對(duì)應(yīng)各個(gè)分系統(tǒng)之間的遞推循環(huán)方式[7]。在軟件研發(fā)階段需要執(zhí)行的測(cè)試任務(wù)，由甲負(fù)責(zé)分系統(tǒng)1、乙負(fù)責(zé)分系統(tǒng)2、丙負(fù)責(zé)分系統(tǒng)3，各人的工作閉環(huán)后進(jìn)入下一階段；在軟件測(cè)試階段的主要測(cè)試時(shí)間，由丙、甲、乙分別繼承甲、乙、丙完成的用例和腳本等成果迭代執(zhí)行測(cè)試，各人的工作閉環(huán)后進(jìn)入下一階段；在軟件發(fā)布前的測(cè)試則由乙、丙、甲分別繼承軟件測(cè)試階段丙、甲、乙的成果補(bǔ)充完善測(cè)試內(nèi)容。由此一級(jí)一級(jí)的遞推循環(huán)，在最后的維護(hù)階段時(shí)，達(dá)到整個(gè)系統(tǒng)均可由甲/乙/丙中任何一人去執(zhí)行的效果。

5.2 模型推廣

眾所周知，實(shí)際的軟件測(cè)試的影響因素是多樣的，尤其是工作量和時(shí)間。如果對(duì)于較大規(guī)模、結(jié)構(gòu)復(fù)雜的軟件而言，測(cè)試工作量相對(duì)比較多的情況，可以進(jìn)行二次分組設(shè)置，即在以最小單元組的基礎(chǔ)上再次分成若干大組，然后在每個(gè)小組內(nèi)執(zhí)行遞推循環(huán)的過程（如果有必要可以繼續(xù)執(zhí)行在大組內(nèi)遞推循環(huán)），如此一來可以化整為零，大大分擔(dān)了較多的工作量，達(dá)到預(yù)期效果。

二次分組如圖2。

另外，對(duì)于節(jié)點(diǎn)和時(shí)間充足的軟件執(zhí)行測(cè)試時(shí)，在分組上實(shí)行大于3 的組單元，在階段內(nèi)執(zhí)行多次遞推循環(huán)迭代，增加測(cè)試的準(zhǔn)確性，利用好有效的時(shí)間以達(dá)到最優(yōu)的軟件測(cè)試效果。

5.3 至少三步遞推的必要性

（1）三步遞推法從不同角度入手，針對(duì)之前測(cè)試成果的補(bǔ)充和完善，消除單一角度的片面性。

（2）如果僅執(zhí)行3 次以下，則對(duì)于同一問題生成多種不同結(jié)果時(shí)容易造成誤判，從概率論角度，執(zhí)行活動(dòng)越多越接近正確結(jié)果，所以至少3 步遞推循環(huán)有利于針對(duì)之前的誤判誤報(bào)給出較為正確的分析。

（3）三步法無形中增加了測(cè)試準(zhǔn)確的概率，因此分組的最小單元為3 元[8]。

（4）至少3 元為一組遞推循環(huán)執(zhí)行，使組內(nèi)每一元都能全面了解各組的方法、工作內(nèi)容和軟件架構(gòu)，避免了某個(gè)成員因?yàn)樾菁佟㈦x職等突然因素對(duì)整體工作造成影響，方便后期分擔(dān)維護(hù)，節(jié)省了時(shí)間和人員成本。

圖2 二次分組效果圖

6 模型的最優(yōu)化評(píng)價(jià)

本文的第三章講述了目前常見的組織方式：重點(diǎn)式、分級(jí)式、無規(guī)則分組式，下面對(duì)遞推循環(huán)模式與以上3 種方式進(jìn)行比較。

理想條件下，對(duì)軟件對(duì)象的測(cè)試次數(shù)越多、執(zhí)行有效時(shí)間越長、執(zhí)行腳本用例越完善，則往往逐級(jí)發(fā)現(xiàn)問題bug的難度越大。以某一軟件系統(tǒng)為例，在遞推循環(huán)模型、重點(diǎn)式、分級(jí)式方式下，軟件bug 發(fā)現(xiàn)預(yù)估率和測(cè)試次數(shù)、時(shí)間的關(guān)系如圖3：

圖3 bug 預(yù)估發(fā)現(xiàn)率曲線圖

從圖中可以看出，遞推循環(huán)模型測(cè)試執(zhí)行能夠在最短時(shí)間和次數(shù)下，發(fā)現(xiàn)更多的問題。

分級(jí)式軟件測(cè)試造成每一次測(cè)試都是獨(dú)立的、完全覆蓋的，需要花費(fèi)大量的時(shí)間去做相同的工作、完全覆蓋，而且人員的流動(dòng)對(duì)整個(gè)項(xiàng)目影響較大，違背了缺陷集群性和殺蟲劑悖論的基本原則。遞推循環(huán)模型在每次遞推后均迭代上一次的最新成果，逐步完善用例和腳本工具，對(duì)集群缺陷作深入分析，避免了返工式操作和時(shí)間的浪費(fèi)，而循環(huán)方式有效解決了人員流動(dòng)性的影響。

重點(diǎn)式軟件測(cè)試弊端較大，是以工作效果為代價(jià)解放時(shí)間的過程，造成測(cè)試覆蓋和問題發(fā)現(xiàn)的不充分，違背了測(cè)試可以證明缺陷存在的基本原則。遞推循環(huán)模型在最小組單元分組情況下，符合測(cè)試盡早介入的原則，節(jié)省了時(shí)間和成本，而且在后期時(shí)間緊張的情況下，方便以最少的人力和時(shí)間改進(jìn)軟件測(cè)試工作。

無規(guī)則分組式軟件測(cè)試在中后期易造成責(zé)任管理和執(zhí)行度上的混亂，直接影響工作的效率，進(jìn)而導(dǎo)致差的軟件測(cè)試結(jié)果，違背了窮盡測(cè)試是不可能的這一基本原則。圖3 軟件bug 預(yù)估發(fā)現(xiàn)率曲線圖直觀有力地說明了遞推循環(huán)模型的高效性。

7 結(jié)語

遞推循環(huán)型軟件測(cè)試工程管理模式是一種高效的優(yōu)秀方式，能夠以最少的人力和最短的有效時(shí)間執(zhí)行全面覆蓋、自動(dòng)化程度高的測(cè)試工作，能夠盡可能地發(fā)現(xiàn)并定位更全面、更準(zhǔn)確的軟件問題。過程管理明確、全面、省時(shí)，符合軟件測(cè)試的基本原則。