模板
教程
環境
性能
功能
管理
為盈利而測試-談軟件企業進行軟件測試的經濟目的
所以，作者在本文中著重從測試經濟學的視角，以過程建模的方法，給出了業界普遍存在的六個誤區，一個軟件 “ 變換 ” 過程缺陷導入模型，一個測試和糾錯的成本模型和軟件測試成本最小化停止條件。
【關鍵字】 軟件測試;測試經濟學;測試管理;測試停止條件
引言：
[ 美 ] Grenford J. Myers 在 1978 年所著的《 The Art of Software Testing 》一書中，首先用一章的篇幅論述了程序測試的心理學和經濟學問題。他認為要淡軟件測試問題， “ 最為重要的卻是經濟學問題和心理學問題 ” 。并在列舉了當時大多數人使用的完全錯誤的 “ 測試 ” 定義所導致的危害之后，給出了被業界普遍公認和引用的 “ 較為恰當的定義 ” ，即 “ 程序測試是為了發現錯誤而執行程序的過程 ” 。
Grenford J. Myers 所以把測試經濟學問題和心理學問題看得如此之重，因為軟件測試至今仍是由人為主體的一系列活動，而人類的活動卻具有高度的目的性， 即可以說絕大多數的人類行為是由 “ 目標驅動 ” 的。一個正確的測試目的，可引發一系列為實現該目的的有效測試行為和結果;相反，一個不正確的測試目的，可引發一系列無效的或有害的測試行為和結果。
? 什么是軟件測試
在談到軟件測試時，業界還是都引用 Grenford J. Myers 在《 The Art of Software Testing 》一書中表述的觀點：
?、?程序測試是為了發現錯誤而執行程序的過程;
?、?測試是為了證明程序有錯，而不是證明程序無錯誤;
?、?一個好的測試用例是在于它能發現至今未發現的錯誤;
?、?一個成功的測試是發現了至今未發現的錯誤的測試。
但是軟件測試 決不等同于找 BUG 。 不幸的是，僅憑字面意思理解這些觀點，認為發現錯誤似乎是軟件測試的唯一目的，這樣就可能會產生一些誤導。認為查找不出錯誤的測試就是沒有價值了;一些軟件企業在制定對測試組(人員)的業績考核標準時，簡單地把捕捉到缺陷個數作為主要考核指標。然而事實并非如此簡單。那些把尋找缺陷當作是軟件測試的唯一目的的測試管理人員往往會陷入一個又一個測試管理誤區。
以下列出是作者總結的六個值得業界重視的誤區。
誤區一：忽視對正常輸入的測試。
軟件缺陷最常見的地方是哪里?一般來說軟件缺陷最為密集的地方就是當用戶輸入非正常輸入組合時。一方面軟件設計人員較容易忽略一些極難發生的情況，另一方面設計與開發人員往往會把更多的精力用在功能實現上，容錯與錯誤處理往往是開發上的薄弱環節。所以當測試人員將測試目標訂在缺陷數量上時，重點測試非正常輸入顯然就是最好的手段。
然而對于用戶來說，真正影響使用的卻是正常輸入組合激發的缺陷。而這種缺陷，一個就已經太多了。
例如對于一個記事本軟件，也許沒有人會去注意為什么將字體大小設置到大于 49151 的正整數時，每個字會突然變成一個小點。也許很少人會去在乎若將字體大小設置到超過窗口高度時右方的滾動卷標不能滾動到一個能讓你看到某一個字的下半截的位置。但若使用一般的剪貼功能會將一段話搞成亂碼，那每一個用戶就都會跳起來了。
誤區二：忽視設計階段的參與與評估
在多數企業里，軟件的設計階段往往沒有軟件測試人員的參與，甚至有些企業在編碼幾乎完成了才開始組織測試團隊。原因無他，設計還沒定型呢，怎么找缺陷哪?
事實上設計上的缺陷往往是耗用成本最高，也是最難在開發后期修復的缺陷。而一個軟件的質量與它有多大的設計缺陷有著密不可分的聯系。而有經驗的測試人員的質量意識，安全意識，對用戶需求的了解及分析能力，對于打造高品質的軟件設計都有著不可忽視的作用。
同時對于技術可行性與用戶需求之間的設計妥協，測試人員也必須要有充分的評估和理解。這樣在最緊張的開發后期，才不會把大量的(測試及開發人員的)寶貴時間用于記錄和處理那些已在設計階段確定放棄的功能。
誤區三：忽視測試計劃與測試文檔的建立及維護。
設計測試計劃與建立測試文檔常常會被看作是浪費時間。即使做了也只是為了交差，要么敷衍了事，要么找個范本一抄，略作修改便萬事大吉。真正測試起來還是全靠靈感與直覺。
但軟件測試的另一個重要目的是確認及評估一個軟件是否能夠符合用戶的需求。而對軟件質量的保證不能只是靠測試人員一開金口，而要靠詳細的測試計劃以及完整的測試結果來取得用戶的信任。
誤區四：忽視缺陷的分析，報告及跟蹤。
找到缺陷本身并不能提高軟件的質量。只有缺陷被正確修復了才能真正提高軟件的質量。作為一個好的測試人員不僅僅要善于發現缺陷，同時還要善于描述缺陷的表現特征，并積極跟蹤缺陷的處理過程，確保缺陷被正確診斷及修復。不負責任的缺陷報告常常會給軟件開發人員帶來很多不必要的麻煩甚至誤導。這會嚴重影響開發人員對測試人員的信任與尊重。
誤區五：錯誤的測試目標及測試終止條件。
沒有缺陷的軟件是不存在的。同時也沒有方法可以知道一個軟件中到底有多少個缺陷。一個簡單的文本處理軟件經過三個月的測試找到了 100 個缺陷，那說明這個軟件總共有多少缺陷呢?也許是 101 個，你找到了 99% 的缺陷，也許是 10000 個你只找到 1% 的缺陷。又或連著兩個星期只找到一兩個缺陷，那么說是軟件質量已達到較高水平了呢，還是你的測試方法走進了死胡同呢?誰也說不清。
誤區六：不懂得合理調配使用測試人員的知識技能結構。
除去發現缺陷的洞察力外，好的測試人員還應該擁有很好的組織能力，準確的表達能力，嚴密的邏輯推理能力，以及對軟件開發過程，軟件使用對象，軟件開發技術等的較深入地了解。同時具備所有素質的測試人員也許比鳳毛麟角還要難找。所以在構建一個測試團隊的時候就一定要合理搭配擁有各種能力的測試人員，并在使用的時候注意發揮各自的特長。如果讓所有測試人員一心一意地找 BUG ，那不僅僅是壓制了其他方面的人才，整個測試團隊的實際績效必然會大打折扣，甚至會影響到整個軟件產品的順利開發。
? 軟件質量與軟件測試
為了定量地論述軟件測試的經濟目的，本節首先剖析一下軟件質量與軟件測試的關系。隨著人們對軟件特性、軟件測試與軟件質量的認識的深化，尤其是對質量認識的深化，任何一個軟件企業要使自已提供給用戶的產品達到并保持穩定的質量水平，不僅要關注對軟件產品在發布或交付之前進行嚴格的軟件測試，而要從軟件需求獲取開始，對整個軟件開發過程都要引入嚴格的質量管理，在每個開發階段均要引入軟件測試，并且這種質量管理不能停留在早期的質量檢驗型管理，而要轉為全面的質量管理和第三方的質量認證或評估。
顯見，在 1983 年 IEEE 的軟件測試定義 “ 使用人工或自動手段來運行或測定某個系統的過程，其目的在于檢驗它是否滿足規定的需求或是弄清預期結果與實際結果之間的差別。 ” 中只是明確指出： 1) 軟件測試是運行或測定某個系統的過程; 2) 軟件測試的目的是為了檢驗軟件系統是否滿足需求。把測試視作檢驗的一種手段和活動。
實際上，業界很早就從早期的狹義的軟件測試概念和實施范圍作了拓展。軟件測試的對象不再限于可運行的程序代碼，而拓展到質量管理中所涉及的在整個開發各階段的輸入、輸出、過程和中間工作產品，測試活動也不限于對可運行代碼的測試活動，而包括復查、走查、評審、驗證等。事實上，軟件整個開發過程，是一系列 “ 變換 ” 或 “ 處理和活動 ” 過程 P1 、 P2 、 … 、 Pn 所組成的半序序列 ( 參見圖 —1) 。
圖- 1 中 D0 是源頭(用戶需求)， D1 、 … 、 Dn-1 是諸中間 “ 變換 ” 過程的工作產品， Dn 為最終工作產品。顯見，每個 “ 變換 ” 過程都有它的輸入和輸出，都可能導入這樣或哪樣的缺陷( Bugs )，而且這種缺陷按缺陷擴大模型還會逐級擴大，尤其是在上游工作產品頻繁出現更改時。不過這些中間工作產品大多只是以靜態文檔形態給出的。對它們的測試通常也只能采用 “ 靜態測試 ” 方法，其中包括工程測試(非正式的內部評審)、正式測試(正式評審)、審核測試(驗證、審計)和檢查性測試(檢測、確認)等。
為此，為了保證最終工作產品的質量，必須關注對每一個中間 “ 變換 ” 過程以及它們輸入和輸出的質量的檢測和評估，盡可能防止缺陷向下游傳布和擴散。以下再通過一個 “ 變換 ” 過程來分析一下每個 “ 變換 ” 過程可能導入的質量隱患：
顯見，在每一個 “ 變換 ” 過程中導入缺陷途徑是多種多樣的，例如：
上游工作產品中隱含的缺陷;
規范、標準、 … 中隱含的缺陷;
資源、工具引入的缺陷，其中主要是由 “ 變換 ” 過程的操作者(組、個人)引入的缺陷，因為據大量統計資料統計，即使一個有經驗的程序員，在編碼過程中，平均每寫 7-10 行程序就會有引入 1 個缺陷。事實上，對每一過程的操作者，導入缺陷有諸多的客觀的和主觀的原因，其中包括對上游工作產品、規范、標準、 … 以及引用外部構件的理解上的差異，操作者對知識、經驗和技能方面的欠缺和習慣性、過失性錯誤，以及團隊溝通和版本管理、工具使用中差錯和過失。
由上可知，對 “ 變換 ” 過程 Pi 流向下游工作產品 Di 中所導入缺陷個數可用以下公式表示：
N i =k i N i-1 +NS i +NR i …… (1)
其中
N i - 是 “ 變換 ” 過程 P i 的工作產品 D i 中所隱含缺陷數;
k i - 是 “ 變換 ” 過程 P i 對上游工作產品 D i-1 中所隱含缺陷數的擴大系數 k i ，通常 k i 在 2 ～ 10 之間;
NS i – 是由于 “ 變換 ” 過程 P i 的規范、標準、 … 缺陷所引入的缺陷數
NR i – 是由于 “ 變換 ” 過程 P i 所用資源、工具、技術所引入的缺陷數，顯見它與參與本“變換”過程 P i 的人員特性及狀態有極大的相關性。
這樣就可從公式 (1) 導得，
N 1 =k 1 N 0 +NS 1 +NR 1
N 2 =k 2 N 1 +NS 2 +NR 2
……
N n =k n N n-1 +NS n +NR n
最終產品 Dn 中所包含的缺陷個數為
N n = k 1 k 2 …k n N 0 +k 2 k 3 …k n NS 1 +k 2 k 3 …k n NR 1 +…+NS n +NR n … (2)
顯見，當 n=5 、 k1=k2=k3=k4=k5=3 時，在需求階段引入了一個缺陷，而且未能盡早于以排除，那未最終經逐級擴大在最終產品中可產生 35 = 243 個缺陷。
可是，一旦在某個環節導入缺陷后，有些是難以被顯露的，即使通過軟件測試被外顯，被發現，有的也難以捕獲到它。只有捕獲到它，才能設法糾正它。不幸的是，有時即使找到了，而且也采取了補救措施，結果由于不良的補救措施又會引發新的缺陷。就象人從向上的自動扶梯一步一步往下走一樣，可能你往下走了一步(排除了一個缺陷)，結果自動扶梯又往上滾動好幾步(又引發了多個缺陷)，這樣一來，推倒重來的事是常有的。
現設在 Di 中每發現和修復一個缺陷的平均成本分別是 CTi 和 CRi ，如果諸缺陷都留到最終產品 Dn 才進行測試和排除，那末總的發現和修復成本為：
C n =(k 1 k 2 …k n N 0 +k 2 k 3 …k n NS 1 +k 2 k 3 …k n NR 1 +…+NS n +NR n )×(CT n +CR n ) (3)
所以，隨著軟件產品規模、復雜性增長，加上在啟動項目時，一些需求往往是模糊的。一般的軟件組織要化一半以上的精力來查找和修復錯誤。加上測試時間往往難以預計，沒完沒了的產品缺陷常常是造成超支和超期的主要原因。
可是對最終用戶來說最關心的當然還是最終軟件產品的功能、可靠性、效率、易于使用、易于移植性。而對一個實際軟件項目企業高層管理者說，他們自然更多注重總的質量和項目贏利，而不是某一特性，而要權衡質量( Q )、成本( C )、進度( T )。所以，對一個項目經理、軟件工程組以及測試組來說，同樣要重視軟件測試的質量效益。
? 軟件測試的經濟目的
事實上，作為軟件開發企業來說，投入人力，資金搞軟件測試的最終目的還是離不開經濟效益。而對與測試項目的管理也不能離開這個大前提。軟件測試的經濟效益主要來自以下兩個方面。一是滿足用戶需求，提高產品的競爭力，最終提高產品的銷售量。二是盡早發現缺陷，降低售后服務成本。而軟件測試的最終目的就是使它帶來的經濟效益最大化。
? 滿足用戶需求，提高產品的競爭力，最終提高產品的銷售量。
一個學生編寫程序可能是為了學習語言，算法，技巧等知識。一個科研人員編寫程序可能是為了驗證某個理論，計算某個結果，或實現某個算法。而一個軟件企業生產一個軟件則只有一個目的 – 盈利。同其他所有企業一樣，要盈利，首先要把用戶當作上帝。只有滿足了用戶的需求，并能使用戶用的方便、用的放心，用戶才會心甘情愿地掏錢。所以作為軟件品質的最后把關者，軟件測試要把用戶的想法放在第一位。從設計測試計劃到構造測試用例，從實際進行測試到跟蹤缺陷處理，都要從用戶的角度去考慮每一個問題。
首先，用戶花錢購買軟件實際上是購買軟件的功能。所以軟件測試首先要保證用戶所需的功能都能正確而可靠地實現。在設計測試計劃時應從用戶實際可能使用本軟件的基本流程或典型使用腳本出發，分析各個功能的重要性和相關性，再根據現有資源及時間構造和篩選測試用例。
其次，要想保住老用戶、吸引新用戶，產品的質量是關鍵。對于一個傳統工業企業來說，一個產品的質量也許可以用一連串的行業指標來界定;而對軟件企業來說，一個軟件的質量是完全由用戶來評價的。用戶對軟件質量的評價通常包含下列五個方面：
? 可靠性
? 安全性
? 性能
? 易用性
? 外觀
因而軟件測試也要針對這幾個方面構造相應的測試用例。
? 盡早發現缺陷，降低后繼質量成本
那么是不是說找缺陷就不重要了呢?當然不是。軟件測試的另一個經濟目標是盡早發現缺陷，降低修復及售后服務成本。顯然，每一個已發布產品中的缺陷除了會影響產品及企業的聲譽外，還會直接增加產品的售后服務成本。無論是派人到現場調試，或研發、發布補丁程序都要遠比在發布前的修復成本昂貴數十倍，甚至數百倍。
事實上，許多統計資料表明，開發過程每前進一步，發現和修復一個缺陷的平均成本要提高 10 倍。在代碼復查階段，平均 1-2 分種能發現和修復一個缺陷，在初始測試階段要 10-20 分鐘。在集成測試時要花費 1 個小時或更多，在系統測試時要花 10-40 個小時。所以軟件測試除了可以揭示和評估軟件產品的可靠性之外的首要任務，就是要在開發過程中盡可能早地找到可能存在的各種缺陷，并找出最佳的解決方案。一旦在某一 “ 變換 ” 過程的工作產品成了次品，那末后繼的所有 “ 變換 ” 過程的工作產品也永遠是一個次品。
現在再來分析上節所導出的成本公式 (3)
C n = (k 1 k 2 …k n N 0 +k 2 k 3 …k n NS 1 +k 2 k 3 …k n NR 1 +…+NS n +NR n )×(CT n +CR n )
再設定不再是把軟件測試和修復都留到最后，而是前移到每個 “ 變換 ” 過程 Pi 后，且設定對每個中間工作產品的缺陷捕獲率和缺陷修復率分別為 RTi 和 RRi ，那末整個軟件產品的測試和缺陷修復總成本為：
CT = CT 1 +CT 2 +CT 3 +…+CT n
= N 0 ×RT 1 (CT 1 + RR 1 ×CR 1 )
+ (N 0 (1-RT 1 ×RR 1 )+NS 1 +NR 1 ))×RT 2 (CT 2 + RR 2 ×CR 2 )
+ (N 0 (1-RT 1 ×RR 1 )+NS 1 +NR 1 ))×((1-RT 2 ×RR 2 )+NS 3 +NR 3 ))RT 3 (CT 3 + RR 3 ×CR 3 )
+……
+ (N 0 (1-RT 1 ×RR 1 )+NS 1 +NR 1 ))×((1-RT 2 RR 2 )+NS 3 +NR 3 ))×…
×( (1-RT n-1 ×RR n-1 )+NS n +NR n )…))×RT n (CT n + RR n ×CR n ) …… (4)
由 (4) 可知，當
N 0 =NS 1 =NR 1 = NS 2 =NR 2 =…=NS n =NR n =0時，有
CT=0
顯見，這就是人們期望的在每個 “ 變換 ” 過程 P i 中均實現最理想的 “ 零 ” 缺陷目標的結果。但是，這是不可能的，因為至今軟件項目涉及的諸多的 “ 變換 ” 過程 P i 還是人工介入的，尤其是由多人或眾多團隊介入后，引入缺陷是難免的，所以，控制成本的中心任務之一就是如何預防和減少對每一 “ 變換 ” 過程 P i 所引入的缺陷數?，F在再回到上節中的 “ 變換 ” 過程 P i 模型 -- 圖- 2 ，即：
首先，在上游工作產品 D i-1 流入 “ 變換 ” 過程 P i 前，由該過程的操作者共同參與對 D i-1 評估或測試，盡量避免或減少經輸入端導入和引發的缺陷數，其中導入的缺陷數是指上游工作產品 D i-1 自身中所含的缺陷數，而引發的缺陷數是指由于上游工作產品 D i-1 中所含的缺陷或因為該過程的操作者對上游工作產品 D i-1 理解上的差異而引發的。
其次，由于 S ：規范、標準、 … 的缺陷，如無完整、清晰的、可操作的文檔化的東西，有些團隊甚至只有非文擋化的約定，以至造成該 “ 變換 ” 是一種非穩定的過程，是因人而異的，這就使這種 “ 變換 ” 過程 Pi 所流向下游的工作產品 Di 必定是極不穩定的。
最后，來分析 R ：資源對過程質量的影響，其中雖然涉及到該過程所用的外部構件、工具、工作平臺等，但這里重點要分析的是該過程的操作者 - 人。根據 [ 美 ]Watts S.Humphrey 在他的《 Introduction to the Personal Softwere Process 》，即 PSP 一書中指出：學生和工程師一般在設計階段每小時引入 1~3 個缺陷，在編碼階段每小時引入 5~8 個缺陷。在代碼復查階段一般每小時發現 6~12 個缺陷，在測試階段每小時排除 2~4 個缺陷。而經過 PSP 培訓后，所引入的缺陷可減少 50% ，缺陷排除效率提高近 4 倍。又指出 Motorila 的工程師在學習了 PSP 后，第一次在測試時只發現 1 個缺陷。
實際上，排除一個缺陷的時間要比測試一個缺陷多 5 到 6 倍。當然，系統越復雜，排除缺陷的費用越高。以 Micrisoft NT 系統為例，共修復了 30000 個缺陷，測試一共花費了 250 個人 - 年，平均 16 個小時修復 1 個缺陷。
顯然測試和排除缺陷不僅要耗費人工、花錢，而且還要拖延時間，所以對缺陷的測試和排除要綜合考慮質量( Q )、時間進度( T )與成本( C )。保證工作質量的原則之一是每一次要開發出合格的產品。切忌一開始就匆忙進行設計、編碼，首先要有一個好的、合格的需求，然后按需求特性確定一個適用的軟件需求開發過程及每個 “ 變換 ” 過程 Pi 應遵循的規范、標準，在選擇合適的開發團隊、操作人員和其它資源后，還要進行上崗培訓，它包括對上游工作產品進行 “ 變換 ” 應遵循的規范、標準及所選擇的工具、構件等。隨后再啟動后繼的變換過程及質量監測和控制點，以保證每一個變換過程都能產生更好的、完整的文檔。以防止由于不清楚或不完整引入的缺陷。這些都是軟件質量保證和測試策劃過程必須與以關注的。
例如，以設計過程為例。一個有經驗的工程師在進行設計時，經常在各個設計層次之間動態地進行切換： ① 首先要理解一定抽象層次上是如何工作的，然后才能在高層設計中放心用。 ② 如一個功能過去用過就可不考慮它的細節，否則要進行詳細設計，甚至做一個原型加以驗證后，才可放心地回到高層設計。 ③ 由于難以把設計階段和實現階段嚴格區分開來，所以要關注的是設計活動，即過程，而且除了要按照支持該過程的規范、標準，把該過程的最終結果完整地、正確地在設計文檔中給予詳細地表述，即評估、測試及后繼的下游過程是可視化的，還要在給出最終設計文檔前的活動中適當引入同行評審來過濾掉不良設計思路或碰撞出好的思路，這也是十分有效的。
現在我們再來考慮評估、測試活動的實際效益問題。事實上，軟件工作產品中越復雜或所含的缺陷愈少，測試發現缺陷的效率越低，因此測試、修復缺陷的花費越大。加上軟件產品中確切的缺陷數是無法知道的，無休止的測試也是不可取的。這就涉及到兩個方面的問題 – ：第一是這些缺陷可能帶來的損失到底有多大; 第二是這種缺陷被激發的可能性有多大。如果兩個問題的答案都是 “ 極小 ” ，那么就根本不應當列入考慮之中。
? 何時應當停止測試
軟件測試還有一個很重要的問題 – 何時應當停止測試?對于許多企業來說，終止測試的時間往往是隨產品的預定發布時間或交付時間來定的。甚至有的地方產品發布或交付前一周還在寫新功能。每一個測試人員都在叫測試時間不夠，但又沒有誰能說出到底多少時間才算夠。
其實問題也很簡單，一個合理的測試終止條件只能來源于一個清晰的測試目標。如果測試的目標是找到所有的缺陷，那么無論多少時間都是不夠的。而要從測試的兩個經濟目標來看，合理的終止條件應當是由以下兩點組成：
測試是為了保證軟件的質量，而軟件的質量標準是由用戶來決定的。這個標準應當在軟件開發初期由用戶需求調查所得，如果每一需求項都列出了可測試的、被共同利益者認可的標準和寫入測試計劃之中的測試用例，這樣軟件測試結束的第一個必要條件就是所有在測試計劃中所列出的測試項和標準(常見的有：必要及重要的功能通過測試，某種公認的認證測試用例包測試通過，連續無故障運行超過一定時間等)都被通過。
通常來說，早期找到并排除的缺陷越多，總的售后服務的成本就越少，但密集的測試就會導致測試成本的增高。而對測試來說，隨著舊的缺陷不斷地被找到并修復，軟件的質量也就越來越好，后繼的服務成本就越來越低，相應地，新缺陷也就越來越難找，即測試成本越來越難高。所以售后服務的成本和測試的成本大致可以用下圖來表示：
由圖- 4 可知，當找到并解決的缺陷占總缺陷的比例達到 T E 時，可終止測試。因為再要通過測試去發現一個缺陷成本比發布后再去維護的成本要高了。其實從企業利潤的角度來看，就要使這兩部分的成本之和最小。當然在實際情況下，這兩條曲線是無法準確估計的。人們往往按拇指規則，即假設殘留的缺陷數與最后一階段排除的缺陷數相等，啟用這樣一個較為合理的中止條件 ： 當一段時間內(通常是一個星期)測試不出的新缺陷時，就可中止尋找缺陷了;或按本文提出的測試效益規則，即當找到的新缺陷的實際價值低于相同時間的測試運行費用、或測試成本與維護成本之和達最小值時、或經 3 至 5 倍企業同類軟件開發項目的平均單位缺陷測試時間內測試不出的新缺陷時就可中止找缺陷了。
結尾
隨著軟件行業的進一步發展，對軟件測試及軟件測試管理的要求也越來越高，尤其是在當前發達國家漸漸興起軟件外包浪潮的關鍵時刻，誰能提供低價可靠的軟件開發服務，誰就能搶先占領市場，而高效經濟的軟件測試則必然會成為軟件企業競爭力的最大助益。
