摘要：本文結合實踐，主要探討了在中小型軟體企業中，在測試資源不是很充足的情 況下的軟體測試管理。文中前兩部分簡要介紹了軟體測試管理及測試的範圍，方法及重要性，之後對當前國內中小型軟體企業在測試及測試管理中可能存在的問題進 行了簡單的介紹與分析，最後介紹了一些較好的解決方法。

1、軟體測試及測試管理的範圍

1.1 測試的範圍

下面主要就測試的參與者，測試要素，測試開始時應確定的工作，測試過程簡要介紹軟體測試的工作範圍。

參與者

1）使用者方代表

2）軟體最終使用者

3）軟體開發人員

4）軟體測試人員

5）高層經理的支援

6）過程保證人員（SQA）

測試要素

1）正確性：資料輸入，過程處理和輸出的正確性（IPO）。

2）檔案完整性：檔案被正確使用，恢復和儲存的資料正確。

3）授權：特殊的授權可以執行一個特殊的操作。

4）程序追蹤：當程序執行中，程式有能力證實程序在正常工作。

5）系統執行的連續性：當有非致命性問題發生後，系統有能力繼續執行關鍵的任務。

6）服務水平：系統有緊急情況發生時，要求程式的輸出結果不經或進行簡單的處理後就可以直接使用。

7）許可權控制：防止系統被誤用（意外或者有意的）。

8）一致性：確保最終設計和使用者需求完全一致。

9）可靠性：在規定的時間內都可以正常運轉。

10）易於使用：多數人均感覺易於使用。

11）可維護性：可以很容易的定位問題，並且進行修改。

12）可移植性：資料或者程式易於移至到其它系統上。

13）耦合性：系統中的元件可以很容易的聯接。

14）效能：系統資源的佔用率，響應時間，併發處理。

15) 操作性：易於操作（Operator）。

測試開始時應確定的工作

1）需求階段

--確定測試策略

--確定收集了足夠的需求

--產生功能性的測試用例

2）設計階段

--確定設計和需求之間的聯絡

--確定進行了足夠的設計

--產生結構和功能的測試用例

3） 編碼階段

確定和設計之間的聯絡

確定擁有執行的足夠條件

產生結構和功能的測試用例

4）測試階段

確定設計了足夠的測試用例

測試應用系統已經完成

關鍵資源已經到位

5）安裝階段

將測試完成的系統變為產品

6）維護階段

修改和重新測試

軟體的測試過程

7）估算：對軟體工作量的估算；對軟體系統的狀況的評估。

測試計劃：詳細的描述怎樣能成功的完成測試工作，其中應包含必須的資源和實施計劃。

需求測試：在軟體開發的所有階段進行測試，測試應該儘早，在需求和設計階段發現的缺陷修正的花費最小。

設計測試：給測試要素打分；分析測試要素；對設計進行評審；檢查修改的部分。

編碼測試：編碼是否按照既有的標準進行，過程是否易於實踐；是否編制了足夠的文件。

測試總結：表示出目前專案的實際狀況；明確測試所做的工作，給出系統的操作效能的評價，明確什麼時候系統可以進行產品化的工作。

安裝，交付測試：檢驗檢查表和產品的正確性；使用測試標準去檢驗發生的問題。

維護階段的測試：開發一些測試用例，預先發現一些問題；對使用者進行培訓。

1.2 測試管理的範圍

軟體測試管理要解決的課題是如何確保軟體測試技術能在軟體專案在軟體生命內得到順利實施，併產生預期的效果。按照管理的物件不同，軟體測試管理大致分為軟體測試團隊組織管理、軟體測試計劃管理、軟體缺陷（錯誤）跟蹤管理以及軟體測試件管理四大部分。

軟體測試團隊組織管理通俗的講就是測試團隊應該如何組建以及測試人員管理。在實際專案開發中，我們常常看到有些單位忽視測試團隊存在的意義，當要實施測試 時，往往臨時找幾個程式設計師充當測試人員；也有些單位儘管認識到了組建測試團隊的重要性，但在具體落實的時候往往安排一些毫無開發經驗的行業新手去做測試工 作，這常常導致測試效率的低下，測試人員對測試工作索然無味。一個好的測試團隊首先要有好的帶頭人，他必須具有極為豐富的開發經驗，對開發過程中常見的缺 陷或錯誤瞭然於胸，此外，他還應具有親和力和人格魅力。其次，測試團隊還應有具備一技之長的成員，如對某些自動化測試工具運用嫻熟或能輕而易舉地編寫自動 化測試指令碼。另外，測試團隊還應有兼職成員。如驗證測試實施過程中，同行評審是最常使用的一種形式，這些同行專家就屬於兼職測試團隊成員的範疇。測試團隊 裡往往不乏缺乏開發經驗軟體新手，這部分人可以安排去從事交付驗證或黑盒測試之類的工作。

軟體測試計劃管理通俗地講就是安排好測試流程。這部分內容具體涵蓋軟體測試策劃、軟體測試技術剪裁、測試進度管理、成本管理等幾個部分。其中測試策劃工作 主要是指具體測試活動實施之前做好策劃工作，如起草測試大綱以及測試計劃；軟體測試技術剪裁工作主要是指測試團隊應根據軟體專案的具體實際剪裁出所要實施 的測試技術；測試進度管理工作主要是指排出各項測試的時間進度及人員安排，如有變動時應做相應調整；測試成本管理工作的內容即開列出測試活動中會涉及到的 資源需求。

軟體缺陷（錯誤）跟蹤管理通俗地講就是確保發現的缺陷（錯誤）已經被開發團隊糾正或處理過並且沒有引入新的缺陷（錯誤）。具體來講，當測試團隊通過各種途 徑發現了文件或程式碼中的缺陷或錯誤以後，並不是交一份測試報告就草草了事，而是在遞交報告以後繼續督促開發團隊及時關閉已知缺陷或錯誤（當然，如有必要應 對這些缺陷、錯誤做嚴重程度排序，以便開發團隊能視輕重緩急安排處理順序）。當開發團隊關閉了測試報告中的缺陷（錯誤）以後，測試團隊還需驗證開發團隊在 關閉過程中有沒有引入新的錯誤。通常，這個過程稱為迴歸測試。迴歸測試如發現問題，繼續報開發團組，按上述流程迴圈，直至迴歸測試最終通過。

軟體測試件管理通俗地講就是指努力建設好測試團隊的財富庫並對測試團隊成員進行技能培訓以幫助他們能使用好這個財富庫。這裡，財富庫是指軟體測試件。測試 件（Testware，指測試工作形成的產品）是一個不常見到的詞彙，它包括是測試團隊在長期實踐過程中逐步積累起來的經驗教訓、測試技巧、測試工具、規 格文件以及一些經過少量修改能推廣至通用的測試指令碼程式。測試件管理工作做得越好，測試團隊在實際測試過程中就能越少走彎路，測試團隊內部的知識交流和傳 遞就越充分，測試指令碼或規格文件的重複開發工作也就能被有效地避免。軟體測試件管理工作包括兩部分，一是建設，另一個是培訓。建設工作大抵是收集各類測試 外文件、測試工具、測試指令碼，也包括收集整理測試人員的會議發言、總結報告、技術心得等等。培訓工作大抵是通過技術講座、正式或非正式團隊會議、印發學習 資料等形式進行。

1.3 軟體測試管理內容

具體的測試管理內容有：

1）測試方案管理：單元測試、整合測試和產品測試的測試計劃的錄入、修改、刪除、查詢和列印。

2）測試案例管理

測試案例的增、刪、改、拷貝和查詢；

測試案例測試情況的管理，如測試狀態包括：未測試、測試中、已測試；

測試結果分為：通過、未實現、存在問題等；

測試案例輸人、編號和歸檔。

3）測試流程管理：測試進度管理；測試流程標識；測試日誌及狀態報告。

4）問題報告管理：問題報告處理流程（問題報告、整改報告）、實現問題報告與測試案例的關聯。

5）測試報告管理：生成單元測試、整合測試和產品測試的測試報告。

除了以上這些，在側試管理過程中還應對人員和環境資源進行管理。

3、測試及測試管理中的問題及分析

通過以上的簡單總結與分析，可以看到軟體測試及測試管理的重要性，及其複雜、廣泛的組織管理工作，所以在實施起來，難免與理論有些出入。另外，國內的軟體 企業大多起步晚，技術基礎薄弱，應用與管理經驗缺乏，在測試上更是如此。於是國內的一些中小型的軟體企業，在軟體測試方面存在諸多問題，不僅與理論要求相 差甚遠，與實際的應用需求也相差很多。下面將簡要介紹與分析當前國內中小型軟體企業在測試及測試管理中存在的問題和問題原因，並在之後提出一些解決辦法。

3.1 軟體本身的複雜性與企業自身的不足

這裡複雜性包括軟體使用者需求的複雜與難確定性，軟體開發過程的組織管理的難控制性等，使得軟體開發過程必然會存在諸多問題，開發出的產品也必然存在一些缺 陷與不足。而由於生產與管理經驗的不足，缺乏高效的開發與測試團隊，往往是開發人員又是測試人員，或測試人員質量管理；缺乏有效的測試技術，程式碼走查室最 常用的方法；測試開始較晚，往往在開發完成之後；對使用者反饋資訊缺乏整理總結等；使得不僅難以控制產品的缺陷數量，而且對於缺陷的定位與修補也很難到位。

3.2 測試的特性

3.2.1 測試是不完全的（測試不完全）

由於軟體需求的不完整性、軟體邏輯路徑的組合性、輸入資料的大量性及結果多樣性等因素，哪怕是一個極其簡單的程式，要想窮盡所有邏輯路徑，所有輸入資料和驗證所有結果是非常困難的一件事情。

3.2.2 測試具有免疫性（軟體缺陷免疫性）

軟體缺陷與病毒一樣具有可怕的“免疫性”，測試人員對其採用的測試越多，其免疫能力就越強，尋找更多軟體缺陷就更加困難。在軟體測試中採用單一的方法不能 高效和完全的針對所有軟體缺陷，因此軟體測試必須採用不同的測試方式和測試資料，應該儘可能的多采用多種途徑進行測試。

3.2.3 測試是“泛型概念”（全程測試）

如果單純的只將程式設計階段後的階段稱之為軟體測試的話，需求階段和設計階段的缺陷產生的放大效應會加大。這非常不利於保證軟體質量。需求缺陷、設計缺陷 也是軟體缺陷，記住“軟體缺陷具有生育能力”。軟體測試應該跨越整個軟體開發流程。需求驗證（自檢）和設計驗證（自檢）也可以算作軟體測試（建議稱為：需 求測試和設計測試）的一種。軟體測試應該是一個泛型概念，涵蓋整個軟體生命週期，這樣才能確保週期的每個階段禁得起考驗。同時測試本身也需要有第三者進行 評估（資訊系統審計和軟體工程監理），即測試本身也應當被測試，從而確保測試自身的可靠性和高效性。

3.2.4 軟體缺陷具有空間聚集性（80-20 原則）

80%的軟體缺陷常常生存在軟體20%的空間裡。這個原則告訴我們，如果你想使軟體測試有效地話，記住常常光臨其高危多發“地段”。在那裡發現軟體缺陷的 可能性會大的多。這一原則對於軟體測試人員提高測試效率及缺陷發現率有著重大的意義。聰明的測試人員會根據這個原則很快找出較多的缺陷而愚蠢的測試人員卻 仍在漫無目的地到處搜尋。

80-20 原則的另外一種情況是，我們在系統分析、系統設計、系統實現階段的複審，測試工作中能夠發現和避免80%的軟體缺陷，此後的系統測試能夠幫助我們找出剩餘 缺陷中的80%，最後的5%的軟體缺陷可能只有在系統交付使用後用戶經過大範圍、長時間使用後才會曝露出來。因為軟體測試只能夠保證儘可能多地發現軟體缺 陷，卻無法保證能夠發現所有的軟體缺陷。

3.2.5 為效益而測試

為什麼我們要實施軟體測試，是為了提高專案的質量效益最終以提高專案的總體效益。為此我們不難得出我們在實施軟體測試應該掌握的度。軟體測試應該在軟體測 試成本和軟體質量效益兩者間找到一個平衡點。這個平衡點就是我們在實施軟體測試時應該遵守的度。單方面的追求都必然損害軟體測試存在的價值和意義。一般說 來，在軟體測試中我們應該儘量地保持軟體測試簡單性，切勿將軟體測試過度複雜化。

3.2.6 缺陷的必然性

軟體測試中，由於錯誤的關聯性，並不是所有的軟體缺陷都能夠得以修復。某些軟體缺陷雖然能夠得以修復但在修復的過程中我們會難免引入新的軟體缺陷。很多軟 件缺陷之間是相互矛盾的，一個矛盾的消失必然會引發另外一個矛盾的產生。比如我們在解決通用性的缺陷後往往會帶來執行效率上的缺陷。更何況在缺陷的修復過 程中，我們常常還會受時間、成本等方面的限制因此無法有效、完整地修復所有的軟體缺陷。因此評估軟體缺陷的重要度、影響範圍，選擇一個折中的方案或是從非 軟體的因素（比如提升硬體效能）考慮軟體缺陷成為我們在面對軟體缺陷時一個必須直面的事實。

3.3 測試組織管理不專業

1、測試人員不獨立於開發者，測試人員獨立於開發者的程度將影響測試結果。

人很容易用自己已經非常仔細地做過測試來欺騙自己，開發人員做測試容易受到個人的習慣性想法的影響，程式中可能包含由於程式設計師對問題的敘述或說明的誤解而 產生的錯誤。如果是這種情況，當開發人員測試自己的程式時，往往還會帶著同樣的誤解致使問題難以發現。開發和測試是兩種不同的活動，開發人員對自己的程式 進行一定的審查、除錯是必要的，但是一般情況下還需要另外的專業測試者進行測試。不過，由於有的企業中，人力有限，或者認為沒有足夠的資源或理由支援一支 測試隊伍，有時不得不由開發人員測試；那麼，開發者對自己的程式的測試需要注意許多問題，或者應由另外的開發者對自己的程式進行測試。

2、測試時間安排往往計劃不周，測試計劃有時受制於開發計劃。

3、測試等級以及在那個等級上的測試時間往往選擇不當。

4、測試輔助裝置和測試工具將影響開發者的測試效率及測試徹底性。

5、測試策略文件的普遍缺失。

6、測試範圍的確認經常被其他文件或經驗所取代。

7、測試任務應該像BUG 一樣有明確的分級，不同型別的測試應該有相應的測試用例集合與之對應。

8、關鍵路徑概念在測試規劃時容易被專案經理弱化。

9、測試用例不科學，測試用例在實際中沒有起多大作用；在實際測試時根本沒有按用例執行；往往測試執行後沒有把新的用例補充到用例庫中。

3.4 測試人員的影響

1）測試人員入門容易學習困難，無章可循；人員增加可能有重複工作。

2）測試人員對現實應用與需求的理解可能有偏差。

3）測試人員可能對測試存在一些不正確的看法和錯誤的態度，如下：

（1） 認為測試工作不如設計和編碼那樣容易取得進展難以給測試人員某種成就感；

（2） 以發現軟體錯誤為目標的測試是非建設性的，甚至是破壞性的，測試中發現錯位是對責任者工作的一種否定；

（3） 測試工作枯燥無味，不能引起人們的興趣；

（4） 測試工作是艱苦而細緻的工作；

（5） 對自己編寫的程式盲目自信，在發現錯誤後，顧慮別人對自己的開發能力的看法。

4）提交以後對使用者反饋資訊缺乏及對缺乏足夠的重視，對於有大量使用者有持久生命力的軟體產品（如Microsoft Office），使用者反饋資訊較全面，便於開發和測試人員進行軟體的修補和維護；而一些中小軟體企業的產品卻遠遠無法和Microsoft Office 相比；於是可能缺乏足夠的使用者反饋資訊，或沒有足夠的時間或人力處理使用者反饋資訊。

5）開發及測試人員工作習慣，程式設計習慣，測試習慣等也影響測試的效果；由於測試人員短期的學習與培訓，一般能提高的只是方法和技巧；而其自身能力與習慣可能的負面影響卻一時難以消除。

4、測試管理問題的解決

4.1 建立軟體測試管理體系

建立軟體測試管理體系的主要目的是確保軟體測試在軟體質量保證中發揮應有的關鍵作用，包括以下工作：

軟體產品的監視和測量：對軟體產品的特性進行監視和測量，主要依據軟體需求規格說明書，驗證產品是否滿足要求。所開發的軟體產品是否可以交付，要預先設定質量指標，並進行測試，只有符合預先設定的指標，才可以交付。

對不符合要求的產品的識別和控制：對於軟體測試中發現的軟體缺陷，要認真記錄它們的屬性和處理措施，並進行跟蹤，直至最終解決。在排除軟體缺陷之後，要再次進行驗證。

產品設計和開發的驗證：通過設計測試用例對需求分析、軟體設計、程式程式碼進行驗證，確保程式程式碼與軟體設計說明書的一致，以及軟體設計說明書與需求規格說明書的一致。對於驗證中發現的不合格現象，同樣要認真記錄和處理，並跟蹤解決。解決之後，也要再次進行驗證。

軟體過程的監視和測量：從軟體測試中可以獲取大量關於軟體過程及其結果的資料和資訊，它們可用於判斷這些過程的有效性，為軟體過程的正常執行和持續改進提供決策依據。

一般應用過程方法和系統方法來建立軟體測試管理體系，也就是把測試管理作為一個系統，對組成這個系統的各個過程加以識別和管理，以實現設定的系統目標。同 時要使這些過程協同作用、互相促進，從而使它們的總體作用大於各過程作用之和。其主要目標是在設定的條件限制下，儘可能發現和排除軟體缺陷。測試系統主要 由下面6 個相互關聯、相互作用的過程組成：測試規劃、測試設計、測試實施、配置管理、資源管理和測試管理；確定這些過程的順序和相互作用，前一過程的輸出是後一過 程的輸入。其中，配置管理和資源管理是這些過程的支援性過程，測試管理則對其他測試過程進行監視、測試和管理；確定這些過程所需的準則和方法，一般應制訂 這些過程形成檔案的程式，以及監視、測量和控制的準則和方法；確保可以獲得必要的資源和資訊，以支援這些過程的執行和對它們的監測；監視、測量和分析這些 過程；實施必要的改進措施。

4.2 建立配置管理系統，規範專案管理流程

建立配置管理系統 CVS，CVS 的全稱是Current Version Control。在軟體質量體系的諸多支援活動中，配置管理系統處在支援活動的中心位置，它有機地把其它支援活動結合起來，形成一個整體，相互促進，相互 影響，有力地保證了質量體系的實施。建立公司配置管理系統很容易得到公司領導層的支援，幾乎沒人反對。更重要的是建立配置管理系統後測試人員的工作有了系 統保證，測試工作的“礦藏資源”有了明確的位置，可以主動積極開展測試工作。

4.3 測試過程分階段執行

將測試過程分成幾個階段執行，即：程式碼審查、單元測試、整合測試、確認測試和系統測試。

單元測試是針對軟體設計的最小單位-模組進行正確性檢驗的測試工作，其目的在於發現各模組內部可能存在的各種差錯。在單元測試之後，需要按照設計時做出的 結構圖，將它們聯結起來，進行整合測試。是檢驗所開發的軟體是否按使用者要求執行。確認測試應檢查軟體能否按合同要求進行工作，即是否滿足軟體需求說明書中 的確認標準。軟體開發完成後，還要與系統中其他部分配套執行，進行系統測試，包括恢復測試、安全測試、強度測試和效能測試等。

4.4 做好過程管理

過程管理須做好以下工作：分階段設立里程碑，按里程碑計劃工作和總結工作；加強稽核，測試過程的中間結果要進行充分的稽核；注重風險管理和規避風險，任何決定和過程都存在風險，尤其是質量好壞的風險，通過稽核管理風險。

4.5 制定成功的測試管理計劃及測試計劃

一個成功的測試開始於一個全面的測試管理計劃。因此在每次測試之前應做好詳細的測試管理計劃：

首先，應該瞭解被測物件的基本資訊，選擇測試的標準級別，明確測試管理計劃標識和測試管理項。在定義了被測物件的測試管理目標、範圍後必須確定測試管理所 使用的方法，即提供技術性的Ali 試管理策略和測試管理過程。在測試管理計劃中管理者應該全面瞭解被測試物件的系統方法、語言特徵、結構特點、操作方法和特殊需求等，以便確定必要的側試環 境，包括測試硬體/軟體及測試環境的建立等等。而且.在測試管理計劃中還應該制訂一份詳細的進度計劃如：側試管理的開始段、中間段、結束段及測試管理過程 每個部分的負責人等。由於任何一個軟體不可能沒有缺陷、系統執行時不出現故障，所以在測試管理計劃中還必須考慮到一些意外情況、也就是說，當問題發生時應 如何處理。因為測試管理具有一定難度，所以對測試管理者應進行必要的測試設計、工具、環境等的培訓。最後，還必須確定認可和審議測試管理計劃的負責人員。

還需要一個成功的測試計劃，專業的測試必須以一個好的測試計劃作 為基礎。儘管測試的每一個步驟都是獨立的，但是必定要有一個起到框架結構作用的測試計劃。測試的計劃應該作為測試的起始步驟和重要環節。一個測試計劃應包 括：產品基本情況調研、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結果等等。

4.6 測試人員及早介入

測試人員應從軟體生命週期的需求階段就開始介入，這樣可以在這些需求基礎上生成一份測試計劃，並將測試用例對應於需求。這樣便於提高測試用例的有效性和可用性，並且方便測試用例的設計和管理。

4.7 測試檔案的使用

在軟體的需求分析階段，就開始測試檔案的編制工作，各種測試檔案的編寫應按一定的格式進行。測試檔案的重要性表現在以下幾個方面：

a、驗證需求的正確性：測試檔案中規定了用以驗證軟體需求的測試條件，研究這些測試條件對弄清使用者需求的意圖是十分有益的。

b、檢驗測試資源：測試計劃不僅要用檔案的形式把測試過程規定下來，還應說明測試工作必不可少的資源，進而檢驗這些資源是否可以得到，即它的可用性如何。如果某個測試計劃已經編寫出來，但所需資源仍未落實，那就必須及早解決。

c、明確任務的風險：有了測試計劃，就可以弄清楚測試可以做什麼，不能做什麼。瞭解測試任務的風險有助於對潛伏的可能出現的問題事先作好思想上和物質上的準備。

d、生成測試用例：測試用例的好壞決定著測試工作的效率，選擇合適的測試用例是作好測試工作的關鍵。在測試檔案編制過程中，按規定的要求精心設計測試用例有重要的意義。

e、評價測試結果：測試檔案包括測試用例，即若干測試資料及對應的預期測試結果。完成測試後，將測試結果與預期的結果進行比較，便可對已進行的測試提出評價意見。

f、再測試：測試檔案規定的和說明的內容對維護階段由於各種原因的需求進行再測試時，是非常有用的。

g、決定測試的有效性：完成測試後，把測試結果寫入檔案，這對分析測試的有效性，甚至整個軟體的可用性提供了依據。同時還可以證實有關方面的結論。

4.8 測試團體的建設與測試人員的學習及培訓

要注重建立一支高效的測試團隊，不利用各種方法對測試人員進行培訓。測試人員須加強自身學習，測試人員必須和程式設計師、使用者、市場人員、技術作者以及任何的可能為實現更好測試提供線索的人進行交流。充分利用網路，及時地不斷地學習，充分利用軟體測試的技巧等。

4.9 經濟的測試

作為軟體開發企業來說，投入人力，資金搞軟體測試的最終目的還是離不開經濟效益。而對與測試專案的管理也不能離開這個大前提。軟體測試的經濟效益主要來自 以下兩個方面。一是滿足使用者需求，提高產品的競爭力，最終提高產品的銷售量。二是儘早發現缺陷，降低售後服務成本。而軟體測試的最終目的就是使它帶來的經 濟效益最大化。

有時候使用者應用機率越大的那些軟體業務功能，應該越少有差錯；對某些關鍵功能，應該不允許有差錯；經常不用的，甚至基本不用的那些軟體業務功能，則可以容忍它有差錯，甚至有較多的差錯。

5、總結

軟體測試工作在軟體開發過程中佔有重要地位，在各種規模的軟體的開發中，測試工作都必不可少。關於軟體測試的研究與技術探討可以說都有成熟的成果，但是在 實際應用中，由於軟體開發的時間的影響或軟體專案中人員的不足等等各種因素的影響，使得在國內的中小型軟體企業中軟體測試工作存在一些問題，本文對這些問 題進行了總結和分析，並提出了一些解決方法。