軟件是多個(gè)”人”長(cháng)期構思，協(xié)同作業(yè)下的成果，不可能不出錯。若沒(méi)有配置相當的人力物力資源，分階段把關(guān)測試，將隨著(zhù)系統規模漸大而逐漸失去控制的能力。
@小標：被疏忽的一環(huán)
筆者在赴制造業(yè)授課時(shí)，看到偌大的辦公大樓內，整個(gè)樓層的品保(QA)專(zhuān)業(yè)人員，使用華麗的軟硬件，針對制造流程上的瑕疵缺點(diǎn)做各種的良率分析，但該企業(yè)的 MIS 開(kāi)發(fā)卻沒(méi)有測試人員的配置。換句話(huà)說(shuō)，為支持品保所成立的軟件團隊，在開(kāi)發(fā)軟件時(shí)，本身沒(méi)有品保的支持。
投資出錢(qián)的企業(yè)老板們往往不清楚軟件開(kāi)發(fā)的困難與復雜，一般大眾也充滿(mǎn)著(zhù)對軟件工業(yè)的誤解。如筆者任職顧問(wèn)的報業(yè)集團，其建立了首屈一指的編審制度，企業(yè)內全盛時(shí)期，有八到十位軟件工程師花費近兩年的時(shí)間，開(kāi)發(fā)給上千位編輯使用的系統環(huán)境，為得就是對上千位記者所撰寫(xiě)的文字內容嚴格把關(guān)。
但沒(méi)有軟件專(zhuān)業(yè)人員為系統開(kāi)發(fā)把關(guān)，讓筆者斗膽做個(gè)對照，若程序設計師撰寫(xiě)程序代碼如同記者撰寫(xiě)文稿，則我們沒(méi)有測試工程師如同編輯來(lái)編審與校稿，也就是沒(méi)有 code review與測試。軟件開(kāi)發(fā)團隊也缺乏如編輯們對整份報紙的版面編排與改稿，也就是沒(méi)有軟件的重構(refactoring)。甚至對程序代碼的錯誤追蹤和版本控管都還不如編輯們對文稿修改所提追蹤功能之要求。
換句話(huà)說(shuō)，每個(gè)產(chǎn)業(yè)都有其專(zhuān)業(yè)，卓越企業(yè)的管理階層對該公司之品管一定都有嚴格的標準，如本書(shū)第九章所描述的全面質(zhì)量管理(TQM Total Quality Management)。但對支持品管的信息系統本身之品管卻由于無(wú)知而導致漠視。
既然全面質(zhì)量管理是大大小小的”計劃(Plan)、執行(Do)、檢查(Check)、處理(Act)”等 PDCA 循環(huán)流程，沒(méi)道理提升公司競爭力的信息系統沒(méi)有”檢查”。而純由腦力合作建構的信息系統又沒(méi)有容易施行與監督的標準步驟(SOP)，則更應該強化軟件測試，以提升質(zhì)量。
軟件測試在國內往往是被忽略的一環(huán)，光從筆者對書(shū)籍中專(zhuān)有名詞的翻譯感到陌生可作為一個(gè)指標 ，因為專(zhuān)有名詞的翻譯是約定俗成的，若大家朗朗上口，且對定義清楚明了，代表該技術(shù)在此已經(jīng)落地生根行之有年。反之，則代表大家還在啟蒙階段，雖然美國早在上個(gè)世紀 70 年代就已經(jīng)建構理論，近年更提出開(kāi)發(fā)與測試人員的比例最少 3 比 1 的要求(本書(shū)中描述微軟的開(kāi)發(fā)與測試人員視項目的不同，比例是 1比 1.5 到 1 比 3，也就是一個(gè)程序撰寫(xiě)人員配置三個(gè)測試人員)。
而我曾經(jīng)和國內一家軟件開(kāi)發(fā)商的美籍品管工程師聊天，他說(shuō)他在美國曾待過(guò)四家公司，不管規模如何，沒(méi)有一家公司沒(méi)有專(zhuān)業(yè)的品保人員。但他在臺灣沒(méi)看過(guò)具專(zhuān)業(yè)品保流程與品保工程師的軟件公司或 MIS 部門(mén)。
@小標：建構體系
軟件生命周期中，大分有分析、設計、開(kāi)發(fā)、測試、上線(xiàn)、維護，若越晚發(fā)現問(wèn)題，修正錯誤所付出的代價(jià)越大。任何階段的工作與產(chǎn)出皆有可能出錯，因此如「以測試驅動(dòng)開(kāi)發(fā)(Test-Driven Development TDD)」方法論所提倡的，在分析的初始，應該就同時(shí)撰寫(xiě)測試案例(Test Case)，亦及以測試來(lái)驗證對需求的了解程度，并規范接下去的設計與開(kāi)發(fā)不至于偏離。
也就是在分析時(shí)期，要撰寫(xiě)如何測試是否符合使用者需求的文件，在設計時(shí)期，要提出模塊與架構間整合測試的方式，以確認架構與接口定義的正確性。而在開(kāi)發(fā)時(shí)期，同時(shí)撰寫(xiě)單元測試，以驗證個(gè)別程序代碼的正確性。同時(shí)，說(shuō)明文件的正確性也要一并測試。讓 V&V(Verification and Validation)的精神貫穿整個(gè)開(kāi)發(fā)過(guò)程，時(shí)時(shí)驗證(Verification)是在做使用者需要的產(chǎn)品，并確認(Validation)把事情做對。
軟件測試理論從 1970 年代建構至今，已經(jīng)自成體系。隨著(zhù) ISO、CMMI、Agile 的盛行，不管是 CMMI 的 Support process areas，或是 Agile 的 TDD、Pair Programming，都規范了軟件質(zhì)量的基本要求，確保質(zhì)量的構成要素，以及實(shí)踐的方向?；蛟S，這是當今軟件項目管理人員不可或缺的常識。
瀏覽書(shū)中所架構的測試定位與流程讓自己一身冷汗，忝為教人做軟件的講師或顧問(wèn)，自認稍有涉獵軟工中的測試環(huán)節，但從未在心中建立出一套完整的測試架構?；蛟S是疏于找尋，滿(mǎn)足于浮面的知識，以往總以人力資源不足，項目時(shí)間短促等理由自欺欺人，而讓測試流于形式。
當我們永遠陷在資源不足的窘境中時(shí)，如何拿捏資源分配應是首要問(wèn)題。而不是把不熟的領(lǐng)域直接割舍。若心中沒(méi)有整個(gè)測試的輪廓，如何能夠取舍該做多少？
@小標：軟件測試之定位
書(shū)中提出對軟件測試定位的認知，或許值得你參考：
@小標：工欲善其事，必先利其器
由于應用程序的開(kāi)發(fā)方式繁多，如采用 C++、Visual Basic、Java、Delphi、.NET、D2K…等，存取接口也大不相同，如批次作業(yè)、Web、Windows Form。而我們的測試目的，除了上述開(kāi)發(fā)流程中的配套作業(yè)外，尚有安全、壓力等測試。廣義而言，你還需要測試使用者的專(zhuān)業(yè)能力(或許使用者的無(wú)知，是系統損毀、安全疑慮的最大來(lái)源)，系統災難復原的能力、隨著(zhù)軟硬件迭代更新的兼容性等等。因此，測試工程師需要選擇適合的軟件工具，建構獨立的測試環(huán)境，并有程序寫(xiě)作、整合軟硬件平臺，協(xié)調開(kāi)發(fā)人員的能力，同時(shí)在人格特質(zhì)上喜歡找問(wèn)題，挑毛病。這其實(shí)與軟件開(kāi)發(fā)工程師喜歡堆積木，無(wú)中生有創(chuàng )造系統的特質(zhì)不同。
當我們定出軟件測試的流程后，若沒(méi)有強悍、整合、易上手且自動(dòng)化的工具程序，則推廣的結果可能是流于空談，畢竟測試是一再重復而枯燥的流程。
本書(shū)中除了對 ISO、CMM、TQM 等規范與軟件測試之關(guān)系，各種開(kāi)發(fā)階段所應進(jìn)行的測試工作，不同類(lèi)型的測試之定位有明確解說(shuō)外，于后半冊廣泛介紹了在軟件測試領(lǐng)域著(zhù)名的廠(chǎng)家，也詳列了著(zhù)名的軟件測試工具，并分門(mén)別類(lèi)地介紹工具之使用。擷取操作的屏幕畫(huà)面，以逐步介紹的方式解說(shuō)。
＠小標：閱讀建議
這本書(shū)有點(diǎn)流于教科書(shū)的繁雜，且部份細部章節的編排上稍嫌紊亂。書(shū)中有些過(guò)于理論的說(shuō)明，需要讀者耐得住性子 。且受限于項目經(jīng)費、時(shí)程與人力，若要將書(shū)中的建議全部落實(shí)于我們日常的團隊合作，似乎仍有一段落差。
建議你先廣泛地瀏覽一下書(shū)籍內所談到的內容，如操做測試的黑箱/白箱進(jìn)行方式，配合開(kāi)發(fā)流程而對應的測試流程，如單元、整合、確認、系統、平行驗收等測試。有了概念后，在軟件開(kāi)發(fā)的過(guò)程中，再擇要精讀。
由于導入測試的效益要明顯呈現，恐怕是在兩三個(gè)案子之后，這種先期需要投資，但下兩三個(gè)案子才見(jiàn)效益的規劃，對項目經(jīng)理而言，可能更需要謹慎拿捏資源配置的比例。
@小標：相關(guān)閱讀
對于國內廣大的微軟產(chǎn)品愛(ài)用者而言，這本書(shū)有點(diǎn)可惜的是于此主題著(zhù)墨不多。若你需要從事 Microsoft .NET 開(kāi)發(fā)相關(guān)的測試，可以參考以下的書(shū)籍：
Test-Driven Development in Microsoft.NET，作者為 James W. Newkirk、Alexei A. Vorontsov。出版社 Microsoft。
此書(shū)有介紹 TDD 的概念，以及免費軟件工具 NUnit 搭配 C#/.NET Framework 開(kāi)發(fā)與測試的使用方式。
Working with Microsoft Visual Studio 2005 Team System，作者為 Richard Hundhausen。出版社 Microsoft。
此書(shū)是本入門(mén)書(shū)，介紹 VSTS 的架構，與實(shí)做軟件生命周期管理之方式。并對于 VSTS 所提供的測試管理：Test Manager、Test View、Test Project、Test Results，以及測試類(lèi)型 Unit Test、Code Coverage、Profiling、Manual Test、Web Test、Load Test 稍有介紹。
若要強化軟件質(zhì)量，重構是可考慮的過(guò)程，而重構更與測試密不可分。你可參考與重構相關(guān)的書(shū)籍：
重構—改善既有程序的設計(Refactoring : Improving The Design of Existing Code)，作者為 Martin Fowler，譯者 侯捷/熊節，碁峰出版。
除了書(shū)籍外，以下這個(gè)網(wǎng)站也蠻有趣的，值得去逛逛：周思博趣談軟件(http://chinesetrad.joelonsoftware.com/index.html)
@書(shū)名：軟件測試理論與實(shí)作
@飛思科技產(chǎn)品研發(fā)中心 編著(zhù)
@博碩文化出版
聯(lián)系客服
