 | 軟體測試理論與實作 飛思科技產品研發中心 編著 博碩文化出版 售價：520元 |
軟體是多「人」長期構思、協同作業下的成果，不可能不出錯。若沒有配置相當的人力物力資源，分階段把關測試，將隨著系統規模漸大而逐漸失去控制的能力。
被疏忽的一環︰軟體品質管制
有一次偶然赴製造業授課時，看到偌大的辦公大樓內，整個樓層的品保（QA）專業人員使用華麗的軟硬體，針對製造流程上的瑕疵缺點正在進行各種的產品良率分析，但該企業的MIS開發卻沒有配置測試人員。換句話說，支援品保所成立的軟體團隊，在開發軟體時，本身並沒有建立品保的支援。
投資出錢的企業老闆們往往不清楚軟體開發的困難與複雜，一般大眾也充滿著對軟體工業的誤解。以筆者任職顧問的報業集團為例，建立了首屈一指的編審制度，全盛時期有八到十位軟體工程師，花費近兩年的時間，開發給編輯使用的系統環境，為的就是對上千位記者所撰寫的文字內容嚴格把關。
沒有軟體專業人員為系統開發把關是相當危險的。假設程式設計師撰寫程式碼等同於記者撰寫文稿，沒有測試工程師，即如同沒有編輯來編審與校稿，亦即沒有 code review與測試；就像編輯們編排整份報紙的版面、進行改稿，軟體開發團隊如果不採取類似的做法，也就是沒有做到軟體的重構（refactoring）。對程式碼的錯誤追蹤和版本控管，軟體開發團隊甚至比不上編輯們對文稿修改所提出的追蹤功能要求。
每個產業都有其專業，卓越企業的管理階層對該公司之品管一定都有嚴格的標準，如本書第九章所描述的全面品質管制（Total Quality Management，TQM），然而我們對支援品管的資訊系統本身的品管，卻往往由於無知而導致漠視。
既然全面品質管制是大小不一的計畫（Plan）、執行（Do）、檢查（Check）、處理（Act）等 PDCA 循環流程所組成，提升公司競爭力的資訊系統沒道理不經過「檢查」。
純由腦力合作建構的資訊系統，既然實際上沒有容易施行與監督的標準步驟（SOP），更應該強化軟體測試，以提升品質。
軟體測試在國內往往是被忽略的一環，筆者自己對書籍中專有名詞的翻譯感到陌生的經驗，即可作為一個指標（註1）。
專有名詞的翻譯是約定俗成的，若大家琅琅上口，清楚明瞭這些專用名詞的定義，代表該技術在此已經落地生根、行之有年。反之則代表大家還在啟蒙階段。
雖然美國早在上個世紀 70 年代就已經建構理論，近年更提出開發與測試人員的比例最少3比1的要求。本書中描述微軟的開發與測試人員視專案不同，比例會隨之調整，從1比1.5 到1比3，也就是一個程式撰寫人員配置三個測試人員。
曾經和國內一家軟體開發商的美籍品管工程師聊天，他在美國曾待過四家公司，他提到不論規模如何，每家公司都有專業的品保人員，但在臺灣他沒看過具專業品保流程與品保工程師的軟體公司或 MIS 部門。
建構體系
軟體生命周期中，可分成分析、設計、開發、測試、上線、維護等階段，若越晚發現問題，修正錯誤所付出的代價越大。任何階段的工作與產出皆有可能出錯，如以「測試驅動開發（Test-Driven Development，TDD）」方法論所提倡的，在分析的初始，應該同時撰寫測試案例（Test Case），亦即用測試來驗證對需求的了解程度，並規範接下去的設計與開發，使方向不至於偏離。
這意味著在分析時期，要撰寫如何測試是否符合使用者需求的文件；而在設計時期，則要提出模組與架構間整合測試的方式，以確認架構與介面定義的正確性；到了開發時期，須同時撰寫單元測試，以驗證個別程式碼的正確性。同時，系統說明文件的正確性也要一併測試。讓V&V（Verification and Validation）的精神貫穿整個開發過程，時時驗證（Verification）是否正在開發使用者需要的產品，並確認（Validation）把事情做對。
軟體測試理論從 1970 年代建構至今，已經自成體系。隨著 ISO、CMMI、Agile 的盛行，不管是 CMMI 的 支援流程領域（Support process areas），或是 Agile的測試驅動開發、搭檔開發（Pair Programming），都規範了軟體品質的基本要求，確保品質的構成要素，以及實踐的方向。或許，這是當今軟體專案管理人員不可或缺的常識。
當自己瀏覽書中所架構的測試定位與流程時，不禁冒了一身冷汗。忝為教導開發軟體的講師或顧問，平時自認稍有涉獵軟工中的測試環節，但從未在心中建立出一套完整的測試架構。或許是疏於找尋或滿足於浮面的知識，以往總以人力資源不足，專案時間短促等理由自欺欺人，讓測試流於形式。
當我們經常陷在資源不足的窘境中，如何拿捏好資源分配應是首要問題，而不是把不熟的領域直接割捨。若心中沒有整個測試的輪廓，又如何能夠取捨該做多少？
軟體測試之定位
書中提出對軟體測試定位的認知，或許值得你參考：
● 提高軟體測試的效率和產出靠功力。好的測試人員不僅要掌握各種測試技術，還要具備豐富的程式編寫和對bug的敏感度。
● 經驗對軟體測試至關重要，測試人員有無經驗實有天壤之別。軟體測試有複雜專業的技術，且需要測試專案本身的專案管理。
● 軟體測試有規範與理論，需要分配時間、人力、財力，並非隨心所欲，愛做多少，就做多少。
● 開發與測試是相輔相成的過程，開發與測試兩個團隊間的彼此交流、協助，是提高整體效率的重要因素。
● 軟體生命周期中的「測試階段」表明該階段的主要工作是測試，但測試工作不只發生在該階段。通常「測試階段」的主要任務是執行測試與撰寫報告，準備工作例如編寫測試計畫、案例及測試程式，需在更早階段完成。
開發過程中交互執行著單元測試（unit test），若干單元或全部集結後的測試，在日漸高漲的軟工理論TDD中，需要求周期性、甚至到每天編譯（build）後執行測試計畫，第二天看分析報表。
● 軟體測試是一種有效提高軟體品質的手段，但不能百分之百發現所有品質的隱憂。
工欲善其事，必先利其器
由於應用程式的開發方式繁多，如採用 C++、Visual Basic、Java、Delphi、.NET、D2K等，存取介面也大不相同，如批次作業、Web、Windows Form。而測試目的，除了上述開發流程中的配套作業外，尚有安全、壓力等測試。廣義而言，你還需要測試使用者的專業能力（例如使用者的無知，即可能是系統損毀與安全疑慮的最大來源）、系統災難復原的能力、隨軟硬體迭代更新的相容性等。
因此，測試工程師需要選擇適合的軟體工具，建構獨立的測試環境，並有程式寫作、整合軟硬體平臺，協調開發人員的能力，同時在人格上具備喜歡找問題、挑毛病的特質。這其實不同於軟體開發工程師喜歡堆積木、無中生有以便創造系統的特質。
當我們定出軟體測試的流程後，若沒有強悍、整合、易上手且自動化的工具程式，推廣的結果很可能流於空談，畢竟測試是一再重複而枯燥的流程。
本書中除了明確解說 ISO、CMM、TQM 等規範與軟體測試之關係，各種開發階段所應進行的測試工作，不同類型測試的定位外，後半冊廣泛介紹了在軟體測試領域著名的廠家，同時詳列了著名的軟體測試工具，並分門別類介紹工具之使用，透過擷取工具軟體操作的螢幕畫面，以逐步介紹的方式解說。
閱讀建議
這本書有點流於教科書的繁雜，且部分細部章節的編排上稍嫌紊亂。書中有些過於理論的說明，需要讀者耐得住性子（註2）。且受限於專案經費、時程與人力，若要將書中的建議全部落實於我們日常的團隊合作，似乎仍有一段落差。
建議你先廣泛地瀏覽一下書籍內所談到的內容，如操做測試的黑箱/白箱進行方式，配合開發流程所對應的測試流程，如單元、整合、確認、系統、平行驗收等測試項目。有了這些基本概念後，在進行軟體開發的過程中，再擇要精讀。
想要明顯呈現導入測試的效益，恐怕是在兩三個案子之後，這種變革需要先期投資，但下兩三個案子才見效益的規畫，對專案經理而言，可能更需要謹慎拿捏資源配置的比例。
註1︰另一個原因或許是：這本書也許是從簡體翻譯的，所以有些地方的用語不同。但正體中文版的編輯對於專業用語翻譯不一致，仍代表大家對這個領域的不熟悉。
偶而看到一本討論測試的中文書，卻是從簡體版翻譯過來，深覺資訊的基礎功夫對岸比較紮實。要枝繁葉茂需要先根深蒂固，而從圖書的廣度與深度可以略窺一二。
註2︰就筆者的感覺，習於實作的人需要的step by step的說明即可，而管理人員只看定位與效益，這本書兩者都涵蓋在內，會讓人很難看完。
|
延伸閱讀 |
| 對於國內廣大的微軟產品愛用者而言，這本書有點可惜的是於此主題著墨不多。若你需要從事與Microsoft .NET 開發相關的測試，可以參考以下的書籍： Test-Driven Development in Microsoft.NET James W. Newkirk、Alexei A. Vorontsov/著 Microsoft Press出版 此書介紹 TDD 的概念，以及免費軟體工具 NUnit 搭配 C#/.NET Framework 開發與測試的使用方式。 Working with Microsoft Visual Studio 2005 Team System 若要強化軟體品質，重構是可考慮的過程，而重構更與測試密不可分。你可參考與重構相關的書籍： 除了書籍外，以下這個網站也是滿有趣的，值得去逛一逛： |
《作者簡介》胡百敬
現任職恆逸資訊教育訓練處資深講師，聯合報系、睿智資訊與臺灣微軟技術顧問。著有《SQL Server 商業智慧聖經》等書，並為專欄作家。
熱門新聞
2025-12-12
2025-12-12
2025-12-12
2025-12-15
2025-12-12
2025-12-12
Advertisement