軟件開發過程中的測試管理

軟件開發過程中的測試管理

測試是開發中必不可少的工作

        首先，一個軟件產品或系統的開發成功，不僅僅是編寫完為使用者提供服務功能的程序而已。軟件程序編寫的完成，其實只是完成了開發任務中的一半。與程序的開發相配合的、具有同樣重要性的另一半工作，是對開發完畢的軟件所進行必要的測試。對測試的管理和執行，其重要性不亞于對程序本身的開發。你可以花費巨大的資源和努力進行程序的開發，可是你要是沒有與此配套的完善的測試，所開發出來的軟件往往會因為質量問題無法滿足客戶的要求和幫助你贏得市場的競爭。
        近幾年來國內信息業界的軟件開發的成熟程度大大提高，很多公司都開始重視軟件測試的重要性、并建立了與此相關的組織結構來保證測試工作得以執行。但是忽視或輕視測試工作的不良習慣和企業文化仍舊普遍存在。在中國項目管理俱樂部的網站上有業界的同仁們反映了這樣的情況：他的公司居然還采用所有的軟件開發人員都只做程序編寫、只有一個人擔任軟件測試工作這樣一種組織結構，而且這個公司的領導認為只有程序的編寫才屬于實際的開發工作，因此只知道夸獎程序編寫人員的工作成果、完全忽視測試人員的貢獻。雖然這樣的近于荒唐的例子可能是極少數的極端現象，但在相當大比例的軟件企業中測試人員往往仍舊是被當作“二等公民”看待，好像他們只是開發人員的配角而已，對軟件最終是否合格和能否發行的判決，并沒有實際的影響力。

        一個成熟和高效的開發組織應該、也必須采取與此完全相反的做法：將軟件的測試和開發放到同等重要的位置上，對軟件的測試和開發給予同樣程度的重視。這種項目管理的理念就要求對軟件測試給予與軟件開發相同的資源和支持，用同等的組織結構和人才來保證軟件測試得到嚴格的執行。 
        微軟公司就是用組織結構來保證產品開發的運作流程充分體現對軟件測試的尊重、承認測試的重要性。微軟總部各個產品部門的所有開發組織都有與程序開發團隊并列的測試團隊 – 任何開發組織都是由項目管理、軟件程序開發、和軟件測試三個并列的團隊組成。這樣的“三駕馬車”的組織結構，保證了測試團隊是一個獨立于程序開發團隊之外的機構，軟件測試的結果和測試人員的觀點在這樣的組織結構中不會被程序開發人員隨意推翻或踐踏，測試人員能夠大膽申訴測試結果、堅持測試的判決、包括阻止不合格的軟件發行。我在Windows操作系統部門進行視窗嵌入式操作系統的開發工作時，就碰到過好幾起因為測試團隊堅持測試結果的審判，從而阻止了開發團隊能夠按時發行開發完畢的軟件的情況。

敏捷模式中的測試驅動開發

        事實上，現在最新的軟件開發項目管理的模式之一甚至將軟件測試的優先權提高到高于軟件功能本身的開發之上。在敏捷模式（Agile Model）實踐范圍中的測試驅動開發模式（Test Driven Development，簡稱TDD）要求將軟件的測試機制和可測性首先開發到軟件中去，把對軟件進行測試的功能作為軟件功能開發的不可缺少的一部分來對待。它要求所有軟件功能組件都必須有自己的進行自我的單元測試的機能、并且要求程序編寫人員在開發軟件的功能程序編碼之前，先開發進行這些功能自我測試的程序。測試的程序編寫完成之后，就開始進行單元測試的運行。這時候，由于提供功能的程序源代碼都還沒有編寫，所以剛開始的時候這樣的自我單元測試當然都是通不過的。當這些單元測試都能運行之后，開發團隊然后才開始編寫每個單元里面的具體功能的程序。

        由于進行自我測試的程序已經完成了，每個功能開發完了之后，開發人員就馬上可以啟動單元的自我測試程序。要是單元的功能程序開發得完善，這時單元的自我測試就能通過，單元的開發就算完成了，測試人員再進一步進入到下一步的其它測試，比如使用案例的測試和系統整合的測試，等等；要是單元的功能程序在開發中有問題或缺陷，這時單元測試就還是無法通過，那么開發人員和測試人員就先集中精力來分析到底是什么缺陷和錯誤造成單元組件的功能程序無法通過那些自我測試，然后可以根據測試失敗的癥狀進行單元功能程序的糾錯工作。

        舉例來說，如果我們需要開發一個進行文檔選擇的功能組件。采用傳統的開發方法的話，就是開發人員先將文檔選擇的功能程序開發出來，然后進行黑箱效應測試，證實文檔能被選擇之后就完了 。采用TDD的開發方法，我們就不是先開發如何選擇文檔的功能程序，而是先考慮這個組件該如何進行單元測試。所以開發人員先編寫在文檔選擇的使用過程中進行檢測可能出現差錯的測試程序。這些測試檢驗代碼的白箱效應的測試，比如進行文檔選擇后的數據檢查、以及程序的邏輯檢查等等。等到這些單元測試程序完成并能夠運行之后，再開始編寫實際的文檔選擇的功能程序。每個局部功能程序編寫完畢就立即運行單元測試，直到單元測試全部通過為止。這時開發人員也可以根據軟件構架設計的有求，對功能代碼中的一些運算方程函數進行模塊優化性的分解（也叫Refactor），除去任何重復的代碼等等。任何源代碼改動和分解之后，必須再次運行所有的單元測試，直到全部通過后才進行證實使用方案的黑箱效應測試，比如檢測文檔選擇正確的結果、選擇錯誤的結果、文檔打不開的結果、文檔找不到的結果等等。

        這樣的開發運作流程和管理的理念是，所有的程序都應該有它的可隨時啟動和利用的測試機制（Test Harness），而且這種測試機制應該是每個軟件功能組件單元的不可分割的一個組成部分。我們首先開發這些提供測試機制的程序，建立一個可供測試的框架。然后通過先測試失敗、加上功能后然后造成測試成功這樣一種反面性的驗證，來證實開發出來的軟件是符合所設計的測試要求的。所以你可以看得出來，測試驅動開發的模式的主導思想是為滿足測試而開發。

        比喻來說，這就好像是修建一條鐵道線，得先把鐵路軌道的標準定了、軌道先鋪上，然后再在鐵路上運行與軌道寬度標準相符合、專門為它而造的火車。鐵路軌道的寬度標準決定了所用的火車必須遵循的寬度。所以可以說，軌道寬度標準是一個制約了火車合格標準的框架。先有了這個框架可以很容易地證實造出來的火車是否符合要求。當然，你也許可以不顧寬度標準先造個火車再說，但這樣造出來的火車不見得能在軌道上跑：要是輪距寬度不符合軌道標準，你就得返工重做。TDD的管理模式就是這個先造檢測標準的理念在軟件開發上的運用，就好像是你先定好軌道的寬度，然后說：按照這個標準造火車，不能在這個軌道上跑的火車就自動不合格；TDD的管理模式使開發人員建立同樣的思路：按照這個測試標準去開發程序，通不過這些測試的軟件就自動不合格。

        這樣的開發方法有很多好處，最明顯的好處是“強迫”開發人員在設計程序的同時，并列進行必須進行的單元測試設計，催促你去思考如何驗證你的程序單元的邏輯正確性和單元的完整性。更重要的是，這樣的開發模式有助于推動進行自動化測試的工具程序的開發、提高測試的效率，因為那些事先設計好的的單元測試程序，在單元的功能程序編寫過程中，可以被隨時使用，來驗證所開發的功能程序部分是否符合要求。

        這樣的開發項目管理模式和理念，很明顯地是將軟件測試的作用和重要性提高到一個開發戰略的層面。 測試不再是簡單的開發完畢后再考慮使用的質量管理的輔助手段而已，而是衡量軟件在開發過程中每個單元組件是否能夠通過，可以說是掌握了項目進度的“生殺大權”。

        這個開發管理模式相對來說是一個比較新穎的方法，它對傳統的開發流程的項目管理造成了不可避免的沖擊，因此并不是很容易被開發團隊接受，特別在絕大多數的在開發人員說了算的企業文化里，這樣的開發方法的使用和推廣很容易受到開發團隊的阻力，因為它不僅用開發流程的改革來承認測試的重要性，并且由于開發人員被要求進行單元測試的開發和執行的額外工作 ，開發人員的工作量和習慣也都需要作一定的改變。

        但是毫無疑問，這個項目管理模式所能夠帶來的巨大好處是有目共睹的。這也是為什么這幾年來在業界中像敏捷模式、TDD模式等新型管理方法在軟件開發的項目管理上被越來越廣泛地利用。就拿微軟本身來說，我們目前也正在進行一場內部的改革項目管理的“革命”：兩年前，總部產品開發部門有少數一些項目經理們自愿組成一個推廣敏捷模式的興趣社團，在少數幾個開發團隊開始推動敏捷模式和TDD等。他們有點像個“地下組織”，因為絕大多數的產品開發團隊還是在使用傳統的方法，公司也沒有人正式倡導敏捷模式等。但是近兩年來，采用TDD等模式來充分發揮測試對質量管理起到的好處，很快就得到很多團隊的共識，因為那些采用了這些模式的團隊在軟件質量的增進上有明確的數據可以證實，這種尊重測試的方法為提高軟件質量、降低Bug Count（缺陷數）、最終幫助開發項目的成功所能帶來的巨大好處。在好幾次公司的經驗交流會上，一些采用了敏捷模式和TDD等方法的團隊公布詳細的質量管理的數據比較，來證明這些新方法的優越性。微軟快速適應變化的特性使得公司很快地也學會支持對新型模式的采用，現在全公司對技術員工進行開發工程教育的部門也開辟相關的課程，幫助一起來推廣對敏捷模式和TDD等管理改革的采用，頗有“星星之火快要燎原”的氣勢。有的團隊甚至采用配對的兩人坐在一起開發的工作模式：一個人開發進行單元測試的程序，另一個人接著開發功能程序、并馬上進行測試。兩個人來回使用同一臺計算機來完成對某個組件的開發。

完善的測試依賴全面的測試計劃

        前面講述了測試對軟件開發的重要性。那么在開發項目管理的運作中，究竟如何執行具體的測試呢？答案是：每個軟件都有它的功能設計，通過它們為用戶解決某些問題或提供某些服務。測試的目的有兩個：第一是要確證這些為用戶解決某些問題的功能設計被正確無誤地開發出來了，也就是說，如果用戶按照所設計的使用方法和過程（我們稱為User Scenario，即使用方案），的確能夠利用這些功能所提供的服務和解決問題；第二是保證軟件在被使用的情況下，如果使用者并不按照所設計的使用方案在使用軟件，它不應該由于任意的使用、或其它外部影響造成任何問題，包括出現差錯，比如數據遺失、數據錯誤、 甚至造成系統崩潰等等。

        為了達到這兩個不同的測試目的，在執行具體的測試時就要采用不同的測試方法。為達到第一個目的、也是最主要的目的，最佳的方法是根據所設計的每個功能和使用方案，設計一個相對應的測試執行過程，去驗證這個功能或使用方案是能夠從頭到尾完成的。這個測試執行過程的定義和描述我們稱它為測試方案或測試案例（Test Case）。要能夠確證所有功能的確是準確地被開發出來了，唯一的辦法就是為每一個使用方案都設計出大量的、一套完整的測試案例（在微軟的產品開發中往往都是幾百甚至上千的測試案例在測試中被使用），然后通過對這些測試案例的按部就班的執行來證明軟件的確可以完成所設計的功能。測試案例的全面性和完整性最終決定了為達到第一個目的測試的質量。

        要能夠做到制定完整的測試案例，就需要有一個可以作為依據的綱領性指南，幫助測試人員設計這些案例。這樣的綱領性指南是由一份叫做測試計劃的文件來總結的。測試計劃在軟件的設計規范書的基礎上進行總結和撰寫，根據具體的軟件和使用要求，制定出整個軟件產品的總體測試構思和設想、測試總體范圍、對測試方法和測試自動化工具的要求和定義等等。在測試計劃的基礎之上，測試工程師們根據它再進一步制定詳細的具體測試方案。至于測試計劃該怎樣寫，該包括什么內容，我在《軟件開發項目管理》一書的第十一章里有詳細的測試計劃文件的模版你可以參照使用，這里我就不再重復了。