前言：軟件迅猛發(fā)展凸現(xiàn)軟件測(cè)試問(wèn)題

　　隨著軟件業(yè)蓬勃發(fā)展，各種軟件需求紛繁而來(lái)，在潮起潮落的IT洪流中，軟件項(xiàng)目越來(lái)越凸現(xiàn)大型化、復(fù)雜化的發(fā)展趨勢(shì)。幾十人上百人的開(kāi)發(fā)團(tuán)隊(duì)、成千上萬(wàn)的模塊與接口、跨地域、跨系統(tǒng)的使用用戶等情況早已屢見(jiàn)不鮮，所有這些，對(duì)項(xiàng)目質(zhì)量管理提出了更高要求，如何滿足各方需求，做出更好的軟件系統(tǒng)？測(cè)試管理逐漸成了大家目光的焦點(diǎn)。

　　軟件的質(zhì)量靠什么，靠管理、靠各個(gè)軟件過(guò)程的嚴(yán)密配合。但勿庸置疑，質(zhì)量的守護(hù)是靠測(cè)試。它就象一只看門(mén)狗，認(rèn)真守護(hù)著軟件質(zhì)量這個(gè)“家”。

　　軟件測(cè)試的重要性

　　測(cè)試是什么？測(cè)試就是對(duì)項(xiàng)目開(kāi)發(fā)過(guò)程的產(chǎn)品（編碼、文檔等）進(jìn)行差錯(cuò)審查，保證其質(zhì)量的一種過(guò)程。

　　軟件業(yè)的迅猛發(fā)展也就是近幾十年的過(guò)程，時(shí)間雖短，但許多誤解似乎已根深蒂固，對(duì)測(cè)試的偏見(jiàn)也是如此。“軟件的重點(diǎn)在于需求、在于分析、在于設(shè)計(jì)、在于開(kāi)發(fā)，而測(cè)試，容易，沒(méi)什么技術(shù)含量，找一些用戶，對(duì)照需求盡力去測(cè)就行了；有時(shí)間多測(cè)點(diǎn)，沒(méi)時(shí)間就少測(cè)點(diǎn)。”這種看法在許多項(xiàng)目經(jīng)理、軟件負(fù)責(zé)人的心中固守著，難以改變。

　　這種觀念的結(jié)果有目共睹，是什么？很簡(jiǎn)單，是大量軟件BUG、缺陷的“流失”，從測(cè)試人員手中悄然而過(guò)，流失到用戶手中，流失進(jìn)項(xiàng)目維護(hù)階段。隨之而來(lái)的，便是用戶無(wú)休止的抱怨、維護(hù)人員無(wú)休止的“救火”、維護(hù)成本無(wú)休止的增加。這是軟件人員的夢(mèng)魘！

　　惡夢(mèng)總有醒來(lái)時(shí)，經(jīng)過(guò)無(wú)數(shù)教訓(xùn)的重?fù)簦诓豢盎厥锥坏没厥椎慕?jīng)歷中，軟件業(yè)的管理者發(fā)現(xiàn)：是他們錯(cuò)了，軟件測(cè)試是不可忽視的。

　　“所有這些問(wèn)題，假如在項(xiàng)目中測(cè)試到的話，便不會(huì)有造成不可收拾的結(jié)果了。”――人們終于意識(shí)到測(cè)試簡(jiǎn)單而純真的真諦。

　　軟件測(cè)試

　　軟件測(cè)試從直觀上來(lái)講是對(duì)測(cè)試對(duì)象進(jìn)行檢查、驗(yàn)證，似乎很簡(jiǎn)單，但實(shí)際不然，它是由許多處理環(huán)節(jié)構(gòu)成的。根據(jù)測(cè)試目標(biāo)、質(zhì)量控制的要求，它被劃分為以下各類環(huán)節(jié)（如下圖），并被設(shè)置了不同的準(zhǔn)入、準(zhǔn)出標(biāo)準(zhǔn)。

　　測(cè)試的主要過(guò)程及活動(dòng)如上圖所示，內(nèi)容一目了然，在此就不一一詳述了，只希望通過(guò)對(duì)測(cè)試重點(diǎn)問(wèn)題、關(guān)注熱點(diǎn)的介紹，幫助大家對(duì)測(cè)試管理有一個(gè)總體的把握。

　　測(cè)試方式中普遍存在的問(wèn)題與點(diǎn)評(píng)

　　談到測(cè)試，我們無(wú)法回避的是當(dāng)前軟件過(guò)程普遍存在的測(cè)試問(wèn)題：

　　1、 手工過(guò)多，缺少測(cè)試工具，自動(dòng)化測(cè)試方式缺失

　　傳統(tǒng)的項(xiàng)目測(cè)試還是以手工為主，測(cè)試人員根據(jù)需求規(guī)格說(shuō)明書(shū)的要求，與測(cè)試對(duì)象進(jìn)行“人機(jī)對(duì)話”。隨著軟件業(yè)的不斷發(fā)展及軟件規(guī)模的擴(kuò)大，這種測(cè)試的弊端日益明顯：
　　· 大量的手工使項(xiàng)目人力成本、溝通成本居高不下；
　　· 人工操作的低效率使項(xiàng)目耗時(shí)增加，帶來(lái)進(jìn)度風(fēng)險(xiǎn)；
　　· 人員素質(zhì)及其他不確定因素會(huì)影響手工測(cè)試的結(jié)果，導(dǎo)致差錯(cuò)率的增加。
　　· 在測(cè)試過(guò)程中，需要對(duì)測(cè)試案例庫(kù)進(jìn)行統(tǒng)一配置管理，項(xiàng)目規(guī)模的激增使手工管理案例庫(kù)的難度日益加大，尤其是在需求變更、回歸測(cè)試頻繁發(fā)生的時(shí)候。

　　從古到今，當(dāng)生產(chǎn)率阻礙了生產(chǎn)力的發(fā)展的時(shí)候，必然會(huì)引入更高級(jí)的生產(chǎn)工具及方式。項(xiàng)目測(cè)試也是這個(gè)道理，引入工具，引入自動(dòng)化測(cè)試及管理，是項(xiàng)目測(cè)試的一大趨勢(shì)。

　　2、 缺乏文檔測(cè)試、檢查

　　文檔是項(xiàng)目的重要產(chǎn)品之一，產(chǎn)品需求、功能分析、架構(gòu)設(shè)計(jì)、詳細(xì)設(shè)計(jì)、用戶手冊(cè)、維護(hù)手冊(cè)等等，對(duì)于項(xiàng)目的測(cè)試、上線、維護(hù)等過(guò)程起到至關(guān)重要的參考、指導(dǎo)作用，所以它們的質(zhì)量應(yīng)該是項(xiàng)目重點(diǎn)關(guān)注點(diǎn)之一。令人遺憾的是，許多軟件項(xiàng)目對(duì)于文檔的重視只停留在口頭上，“編碼第一”的觀念似乎根深蒂固。

　　隨著需求不斷變更、補(bǔ)充，業(yè)務(wù)、技術(shù)人員忙于應(yīng)付，無(wú)法騰出精力來(lái)進(jìn)行文檔內(nèi)容的修改及完善，往往是將包含需求變更內(nèi)容的工作聯(lián)系單往需求文檔后一附了事，而不去更新需求與其他相關(guān)文檔；另一方面，項(xiàng)目變更管理還不夠完善，管理重點(diǎn)往往集中于開(kāi)發(fā)，而輕視文檔質(zhì)量管理，未留出充分的文檔更新時(shí)間，導(dǎo)致文檔更新嚴(yán)重滯后于編碼進(jìn)度。為保證文檔質(zhì)量，必須定期進(jìn)行文檔測(cè)試，但測(cè)試要花成本，項(xiàng)目高層不愿意付此代價(jià)。

　　文檔若可讀性低，便會(huì)影響用戶的理解；若與編碼不一致，便起不到參考作用，編碼測(cè)試就沒(méi)有可靠的測(cè)試依據(jù)。路都看不清楚，怎么往前走呀？所以，強(qiáng)烈建議進(jìn)行文檔測(cè)試，并將其置于測(cè)試管理的首位。

　　當(dāng)前文檔測(cè)試的方法沒(méi)有什么特別的形式，還缺乏測(cè)試工具支持，通常是通過(guò)靜態(tài)審查方式――“走查”來(lái)進(jìn)行的，主要查看文檔的可讀性，內(nèi)容真實(shí)性、可靠性、全面性。另外，在項(xiàng)目里程碑時(shí)期召集相關(guān)領(lǐng)域?qū)＜覍?duì)重要文檔進(jìn)行集中審核，也是一種檢查方式。

　　3、 單元測(cè)試應(yīng)引入交叉測(cè)試方法

　　單元測(cè)試是對(duì)軟件基本組成單元進(jìn)行的測(cè)試，測(cè)試對(duì)象是軟件模塊。通常，單元測(cè)試是由開(kāi)發(fā)人員來(lái)完成，而且往往是各人測(cè)各人的。這存在問(wèn)題隱患。

　　為什么呢，技術(shù)人員是軟件模塊的制造者，自己來(lái)測(cè)自己的軟件的話，角色便從制造者變成了審查者，而前一個(gè)角色的目的是為了保證軟件正確，后一個(gè)角色的目的是為了發(fā)現(xiàn)更多的缺陷，讓一個(gè)人同時(shí)來(lái)扮演兩種目的不同的角色，好比讓他既當(dāng)裁判員又當(dāng)運(yùn)動(dòng)員，怎么能做好呢？
    解決方法通常有兩種，一種是：由測(cè)試人員來(lái)進(jìn)行單元測(cè)試，這種方式要求測(cè)試人員要有較高的軟件技術(shù)知識(shí)；另一種是：將軟件人員分組，在模塊開(kāi)發(fā)告一段落時(shí)進(jìn)行交叉測(cè)試，這種方法只需要測(cè)試者了解被測(cè)方的軟件需求，不需要另外的知識(shí)培訓(xùn)，而且測(cè)試出發(fā)點(diǎn)較為客觀，所以被較普遍的推廣使用。

　　4、 測(cè)試在開(kāi)發(fā)基本完成才啟動(dòng)

　　在傳統(tǒng)的瀑布型開(kāi)發(fā)模式中，軟件測(cè)試位于編碼階段之后，是作為一個(gè)獨(dú)立階段存在的，許多人便一刀切地認(rèn)為應(yīng)該將所有的測(cè)試工作在編碼完成后再開(kāi)始。這個(gè)觀點(diǎn)要不得，原因有二：

　　首先，若將測(cè)試工作細(xì)分，有許多工作是可以提前先期執(zhí)行的，如：需求書(shū)與設(shè)計(jì)書(shū)的學(xué)習(xí)、測(cè)試計(jì)劃的制定、測(cè)試人員的培訓(xùn)、測(cè)試腳本的建立、測(cè)試資源的搭建、測(cè)試模板的創(chuàng)建、測(cè)試工具的選擇等等，都是可以與其他階段并行處理的，這將大大縮短項(xiàng)目開(kāi)發(fā)時(shí)間，為測(cè)試提供充分的時(shí)間保障，提高測(cè)試質(zhì)量。

　　其次，軟件缺陷發(fā)現(xiàn)的越晚，修改、補(bǔ)救所耗費(fèi)的成本越高。引用Boehm在《Software Engineering Economics》一書(shū)中的話――“平均而言，如果在需求階段修證一個(gè)錯(cuò)誤的代價(jià)是1，那么，在設(shè)計(jì)階段就是它的3－6倍，在編程階段是它的10倍，在內(nèi)部測(cè)試階段是它的20—40倍，在外部測(cè)試階段是它的30－70倍，而到了產(chǎn)品發(fā)布出去時(shí)，這個(gè)數(shù)字就是40－1000倍。”由此可見(jiàn)，測(cè)試目標(biāo)的最佳定位應(yīng)該是：在錯(cuò)誤第一次出現(xiàn)的時(shí)候就捕捉到它。所以，在盡可能的情況下，測(cè)試越早展開(kāi)越好。

　　在項(xiàng)目的各個(gè)進(jìn)行階段，都有不同的項(xiàng)目產(chǎn)品產(chǎn)生，他們質(zhì)量的好壞，對(duì)后續(xù)開(kāi)發(fā)影響重大，所以，現(xiàn)在國(guó)際上比較流行的做法是：將測(cè)試融合到各個(gè)開(kāi)發(fā)環(huán)節(jié)中去，盡早測(cè)試。

　　5、 測(cè)試案例、測(cè)試方案的重用率低下