國內為數(shù)不少軟件企業(yè)雖然經(jīng)過多年的發(fā)展，但仍處于疲于奔命、停滯不前的局面；另一方面，規(guī)模像“作坊”一樣的小公司，幾乎每天都在誕生、消亡。導致公司興衰成敗的原因是多方面的，筆者以為其中一個最重要的原因是軟件產(chǎn)品質量的好壞。（當然，市場策略也是其中一個極為重要的因素。）幾乎所有的企業(yè)都想對自己已有的技術成果或項目成果進行產(chǎn)品化，然后再把產(chǎn)品市場化、國際化。可是，絕大多數(shù)企業(yè)的軟件產(chǎn)品一旦走向市場就會遭遇重重困難，例如，軟件質量不過關，軟件可維護性差，軟件使用學習周期過長等等問題。本文不打算深入剖析決定軟件企業(yè)及其產(chǎn)品成敗的各個因素，而是側重于測試角度，以案例的形式，對軟件企業(yè)中影響產(chǎn)品質量提升的常見錯誤認識作一些分析并給出解決方案。
軟件公司在產(chǎn)品開發(fā)中，通常存在三大不合理現(xiàn)象，它們嚴重影響了產(chǎn)品質量的提升：
1）為了保證產(chǎn)品的工期和進度，文檔、質量管理、測試、評審等一系列工作統(tǒng)統(tǒng)可以忽略；
2）為了早日推出產(chǎn)品，不進行正規(guī)的缺陷管理，導致缺陷反復出現(xiàn)，缺陷較多的問題不能從“源頭”進行控制；
3）發(fā)生質量問題不好好反思自己產(chǎn)品開發(fā)管理方面的不足，進而從最根本處入手解決問題；而是掩蓋真實原因，追查個人責任。
本文將針對這三大現(xiàn)象，以真實的案例為藍本，逐個進行剖析。
1、進度 VS 質量
本案例是非常典型的產(chǎn)品開發(fā)案例，幾乎是很多中小公司的典型做法——以按時發(fā)布產(chǎn)品和進度為理由，不實施任何測試工作，就更不用說質量保證工作了。
下面是案例的一些基本信息：
產(chǎn)品信息
內容
產(chǎn)品名稱
系統(tǒng)為J2EE結構的某行業(yè)的ERP系統(tǒng)。本產(chǎn)品是一個來源于項目的產(chǎn)品，原有客戶和新的客戶已經(jīng)投入使用部分功能。
開發(fā)人員
產(chǎn)品開發(fā)人員10人。
功能模塊
含有工作流流程的模塊有30個，不含工作流流程的普通功能模塊20個左右。
進度要求
當時計劃一年內開發(fā)完成，實際目前已經(jīng)耽誤進度0.5年。
產(chǎn)品現(xiàn)狀
主要功能基本完成，而且在一些新的客戶中投入使用，反饋問題較多。
下面是產(chǎn)品開發(fā)的過程：
階段
過程
大事記
項目立項階段
三家大客戶準備采用該產(chǎn)品，公司把三個項目在內部作為一個項目來開發(fā)，同時制定要把該項目成果產(chǎn)品化的目標。
為了趕進度，采取封閉開發(fā)的方法，同時決定第一版不進行測試。
第1個月
項目在沒有文檔的情況下進入開發(fā)狀態(tài)，主要參考依據(jù)是公司內部基于另外一個平臺的同類產(chǎn)品，該平臺有些過時是開發(fā)這個產(chǎn)品的主要原因。
產(chǎn)品整個開發(fā)過程基本沒有進行關鍵方案、文檔的評審工作；沒有進行任何測試；沒有任何質量保證人員。
第2～5個月
產(chǎn)品正常開發(fā)，大多數(shù)功能由程序員做主進行開發(fā)。同時，開發(fā)完成的部分準備安裝試用。
第6～12個月
開發(fā)團隊進一步開發(fā)產(chǎn)品；
實施人員在現(xiàn)場安裝已經(jīng)完成的部分，同時做缺陷修改工作；
第六個月時，客戶開始對公司施壓，要求盡快安裝全部產(chǎn)品，同時拒絕使用已經(jīng)安裝好的部分產(chǎn)品；
幾個實施工程師以超人的“救火”能力，解決了現(xiàn)有缺陷，在幾乎沒有提供新產(chǎn)品的條件下?lián)芜^了半年。
第13個月
把主要功能提供給客戶進行安裝；
前面的幾位實施工程師在季度會議上，被公司評為了“英雄”，給予了一定的獎勵，鼓勵他們繼續(xù)堅守陣地。
第14～18個月
公司決定把產(chǎn)品交給現(xiàn)場的實施人員進行維護，專注產(chǎn)品化工作；
確定在接下來的6個月推出新版本的目標；
由于缺陷較多，現(xiàn)場用戶抱怨不斷；
實施人員忙于現(xiàn)場“救火”。
第19個月
所有的開發(fā)人員不再兼顧項目，加班加點準備按時發(fā)布產(chǎn)品。
……
……
……
現(xiàn)實中很多公司目前都是這樣進行軟件開發(fā)的，幾乎很少進行測試工作，最多也就是在產(chǎn)品發(fā)布后進行最后的“用戶測試”和一些功能性測試。當軟件系統(tǒng)在用戶那里出故障了，現(xiàn)場補救成功的人成了公司的英雄，好心的用戶甚至還會因此寄來感謝信。然而這并不是真正合理的做法。如同案例中描述的那樣，這會導致現(xiàn)場用戶抱怨不斷，分配用于“救火”的工程師越來越多，最后導致企業(yè)不堪重負，不得不放棄部分現(xiàn)有客戶的系統(tǒng)維護工作。要想改變這種現(xiàn)狀，應該從以下幾個方面入手：
不但要主觀認識到測試對軟件質量的重要性，同時還要落實到行動中。
測試的重要性已經(jīng)逐漸被軟件開發(fā)團隊認可。但是落實到實際工作中，通過測試真正提高軟件質量，還有一段很長時間的路要走。因為幾乎所有的軟件公司都灌輸著“進度高于一切”的思想，只要是為了趕進度和發(fā)布產(chǎn)品，所有影響進度的工作都可以忽略。
從表面上看，測試、質量檢查、評審是在耽誤進度，實際上則不然。如果軟件缺陷被遺落并流落到客戶那里，其結果就是代價高昂的電話費或者現(xiàn)場支持費 用，還可能需要修復、重新測試和發(fā)布新的產(chǎn)品，更糟糕的情況是產(chǎn)品要被召回甚至被客戶起訴。這種成本付出非常高，幾乎是在內部修改缺陷時的幾何級數(shù)倍，一 般高達100～1000倍（可以參考PhilipCrosb的相關著作）。
案例中的情況，實際上就是為了趕進度而不進行測試，如果第一版進行規(guī)范的測試，后面那些“救火”英雄肯定會少些，同時也會得到客戶對公司更大的認可。很多公司盡管對這個道理已經(jīng)耳熟能詳，但接下來如何進一步落實到行動中卻是不容樂觀的問題。
樹立提高質量就是尊重客戶的思想。
作者注意到目前不少公司存在著“愚弄客戶”的嫌疑。不管是有心的還是無意的，很多公司認為只要能拿到“錢”就已經(jīng)達到目的了，因此也不在乎是否 掩蓋缺陷和敷衍客戶。案例中的做法肯定是不尊重客戶的，因為沒有產(chǎn)品可以安裝時，不說明實情，反而提供一個“滿目瘡痍”的產(chǎn)品來臨時應付客戶，甚至最后安 排實施人員“硬撐”半年。
生活中大家都討厭假冒偽劣產(chǎn)品，但是軟件行業(yè)從業(yè)者的卻很少意識到質量不好的軟件也是假冒偽劣產(chǎn)品。對客戶負責，就是對公司負責。“樹立客戶是 上帝”的思想，一定要把重視質量落實到行動中，這樣我們就不至于拼命的去生產(chǎn)那些“假冒偽劣”軟件，最后被市場淘汰。在軟件產(chǎn)業(yè)發(fā)達的今天，已經(jīng)是客戶的 買方市場，客戶永遠會選擇質量好的、服務好的產(chǎn)品來滿足自己的需求，只有質量好的產(chǎn)品，才可以不斷的向前發(fā)展。
建立規(guī)范的測試體系和質量保證體系，逐步使軟件開發(fā)進入良性循環(huán)狀態(tài)。
在沒有開發(fā)規(guī)范的前提下，軟件團隊是很少能開發(fā)出高質量的軟件。因此軟件團隊一定要建立規(guī)范的測試體系和質量保證體系，同時把規(guī)范體系逐步落實 到工作中。案例中的公司就是沒有“開發(fā)法律”的小軟件作坊，所以才倒行逆施。不但做了很多浪費人力、物力的無謂工作，還給客戶留下了不好的印象，造成了不 良后果。類似案例中這樣的開發(fā)團隊在現(xiàn)實中很多，都是處于混亂的開發(fā)狀態(tài)。解決的根本辦法就是逐步規(guī)范測試體系，進而建立全面管理的質量管理系統(tǒng)，最終形 成一個良好的開發(fā)體系。在好的開發(fā)體系下，片面重視進度的情況是不容易發(fā)生的。
2、缺陷反復出現(xiàn)，誰的責任？
下面的案例取材自某公司產(chǎn)品開發(fā)部開發(fā)某網(wǎng)絡教育平臺軟件的工程過程。本產(chǎn)品在歷時一年半的研發(fā)后開始投入測試。測試工作允許的時間為7個工作日。
測試工作過程記錄如下
| 進度 | 測試人員 | 開發(fā)人員 | 其他問題 |
| 第一天 | （1）熟悉軟件 （2）閱讀項目文檔 （3）制定測試策略（2人） （4）制作測試跟蹤表格（1人） | 其它工作 | 無 |
| 第二天 | （1）確定測試策略 （2）劃分測試任務 （3）閱讀各自測試模塊的文檔 | 下午做整個系統(tǒng)的業(yè)務功能串講（部分開發(fā)人員）。 |
| 第三天 | 開始執(zhí)行測試 | 其它工作 | 缺陷總數(shù)70多 |
| 第四天 | 執(zhí)行測試 | 其它工作 | 缺陷總數(shù)200多 |
| 第五天 | 執(zhí)行測試 | 其它工作 | 缺陷總數(shù)500多 |
| 第六天 | （1）執(zhí)行測試 （2）總結測試 （3）撰寫測試缺陷報告 | 其它工作 | 缺陷總數(shù)600多 |
| 第七天 | 撰寫測試分析報告 | 其它工作 | 無 |
經(jīng)過7個工作日的測試，得出結果，此系統(tǒng)不可用，需做重大修改。系統(tǒng)經(jīng)過重新設計，保留了部分原有業(yè)務功能和業(yè)務邏輯之后重新開發(fā)，并進行了測試。測試工作允許的時間為三個月。
測試工作過程記錄如下
| 階段 | 測試人員 | 開發(fā)人員 | 其他問題 |
| 單元測試 | 無 | build通過，操作均實現(xiàn) | 無 |
| 集成測試 | 無 | 數(shù)據(jù)流轉執(zhí)行正常 |
| 系統(tǒng)測試 | 隨著開發(fā)過程測試 | 無 | 缺陷總數(shù)500多 |
| | 全部開發(fā)完成集中測試 | 無 | 缺陷總數(shù)4000多 |
在最后的系統(tǒng)測試結束后，對測試結果進行了分析，發(fā)現(xiàn)如下現(xiàn)象：
第二版中的4000個多缺陷基本包含了第一版發(fā)現(xiàn)的600多個缺陷；
相似缺陷較多，例如：如果一個程序員寫的模塊中發(fā)現(xiàn)某個頁面郵件輸入格式?jīng)]有校驗，那么他寫的所有頁面中包含郵件數(shù)據(jù)項的內容都不會校驗；
數(shù)據(jù)校驗遺漏較多：如果在一個系統(tǒng)輸入了不合法的數(shù)據(jù)項，那么，整個系統(tǒng)中就會出現(xiàn)幾十個數(shù)據(jù)項合法校驗遺漏；
細節(jié)錯誤較多，例如：頁面Title不對應的錯誤在系統(tǒng)中有600多個；
程序設計風格不統(tǒng)一。相同的功能點，如分頁、翻頁處理，做得五花八門，并且以測試人員的理解來判斷是否為缺陷，導致某些功能點在不同頁面就能發(fā)現(xiàn)個3到5個缺陷。
通過上面的案例信息，可以看出這個產(chǎn)品的開發(fā)過程本身就是不規(guī)范的，而且測試工作介入的太晚，同時在軟件產(chǎn)品設計、過程管理、文檔評審等諸多方 面均存在問題。產(chǎn)品開發(fā)工作和項目開發(fā)工作相比，一般進度壓力較小。但是產(chǎn)品要進行商業(yè)化最終轉化為通用的商品軟件，質量方面的要求要比項目成果高很多。 缺陷反復出現(xiàn)幾乎是軟件產(chǎn)品開發(fā)的一個常見現(xiàn)象，要想解決這個問題，作者建議整個團隊要從下面幾個方面入手：
規(guī)范化產(chǎn)品開發(fā)流程：產(chǎn)品開發(fā)是應該遵循軟件工程規(guī)范的，開發(fā)過程不應該跳過必要的環(huán)節(jié)。例如這個案例中的產(chǎn)品，無疑就是開始系統(tǒng)設計和評審工作沒有做好，才導致二次開發(fā)，并且還有一個嚴重的遺漏就是首次開發(fā)忽略了測試工作。測試、質量保證等相關工作應該從立項開始就同步啟動。
需求分析要明確：如果開發(fā)人員都不知道完成的內容是否正確，而是由測試人員來判斷是否符合要求，那簡直是需求分析的的巨大“失誤”。用戶或者設計者想要達到什么目標一定要清晰的描述出來，模棱兩可的需求是沒有辦法設計測試用例的，更不用說進行測試了。
開發(fā)人員的調試一定要到位：開發(fā)人員一定要認真調試代碼，至少要把自己負責的部分和其它模塊的接口部分進行 詳細的測試。這項由開發(fā)人員進行的基礎測試是不可缺少的。目標就是把盡可能多的缺陷消滅在開發(fā)階段，這也無疑是最節(jié)約成本的。現(xiàn)代軟件系統(tǒng)十分復雜，程序 員寫了程序不仔細檢查代碼，大多會有很多缺陷存在。如果憑著僥幸心里把所有的測試工作都交給測試工程師來完成，那只能適得其反。這些本來在開發(fā)階段解決的 缺陷由測試人員來發(fā)現(xiàn)會有如下的后果：
耽誤進度——首先，缺陷要經(jīng)過一定的測試流程。例如上面的案例中，網(wǎng)頁的Title寫錯這樣的缺陷折騰了兩個部門，簡直是“勞民傷財”。
轉移測試人員注意力——大量的低級缺陷使測試工程師無法進行更加深入的測試。測試工程師的注意力分散在對于開發(fā)工程師來說“無關痛癢”的缺陷上，使得更深層次的缺陷隱藏起來。
降低開發(fā)人員斗志——盡管這些缺陷是開發(fā)人員自己“制造”的，但是一看到上百、上千個缺陷，無疑會影響心情，降低效率。
當然，增大開發(fā)人員測試力度會帶來一定的投入，因此需要在項目初期進行合理的規(guī)劃，否則開發(fā)工程師就會拼命趕進度，自然把測試工作“寄厚望”于測試工程師。
加強缺陷管理：缺陷管理在這個案例的前期做的不好。在缺陷管理中，我們不但應該把缺陷修改工作能否一次通過 作為考核開發(fā)師的標準之一，更應該把一些常見的缺陷是否存在作為考核開發(fā)工程師的標準。在經(jīng)過一定的積累后，開發(fā)團隊應該形成一些常見的程序缺陷列表，以 引起開發(fā)組成員注意。在此基礎上，還需要做到下面幾個要求來提高質量：
修改缺陷要徹底——徹底不單單是要修改好測試人員提交的缺陷，還要爭取不帶來新的缺陷、這就要求開發(fā)工程師修改缺陷時要對相關聯(lián)的部分進行檢查。
低級缺陷不存在——常見缺陷列表中的錯誤盡量不應該由測試工程師發(fā)現(xiàn)并提出。
3、產(chǎn)品發(fā)布后，缺陷誰來負責？
本案例發(fā)生在一個正在建設測試團隊的組織中，這個研發(fā)團隊有獨立的測試小組，但不是獨立的測試部門，產(chǎn)品部經(jīng)理兼任測試經(jīng)理。在產(chǎn)品提交給代理商后，代理商發(fā)現(xiàn)了一個嚴重的缺陷，并對其進行了投訴，最終的結果是公司領導層對開發(fā)隊伍的相關人員進行了一系列懲罰。
測試過程簡要記錄：
| 測試階段 | 測試人員 | 備注 |
| 單元測試 | 主要由開發(fā)人員負責。 | 開發(fā)人員一邊開發(fā)一邊測試。 |
| 集成測試 | 開發(fā)人員負責，測試人員沒有參與。 | 沒有作為一個獨立的測試階段進行，在開發(fā)過程中進行。 |
| 系統(tǒng)測試 | 由測試小組進行，共5名工程師，測試了進15個工作日。 | 測試過程采用了缺陷管理工具。 |
| 回歸測試 | 測試工程師和開發(fā)工程師進行交互的測試、修改。 | 開發(fā)工程師修改完最后的缺陷后，把所有的模塊打包，發(fā)送給客戶。 |
| 驗收測試 | 由軟件代理商的測試隊伍自己進行驗收測試。 | 根據(jù)用戶手冊進行測試。 |
在代理商驗收測試進行的第三天，測試人員發(fā)現(xiàn)了一個嚴重缺陷——“流轉后的文檔無法正常歸檔”。代理商立刻向公司的客戶服務部進行了投訴。在此之后的10多天里，代理商的測試人員又陸續(xù)發(fā)現(xiàn)了近30個缺陷。
公司對產(chǎn)品的質量十分“震怒”，詳細調查后，發(fā)現(xiàn)了這個問題產(chǎn)生的過程如下：
這個缺陷實際發(fā)現(xiàn)過一次，開發(fā)人員進行修改時，發(fā)現(xiàn)難度較大，決定暫停修改，得到了測試人員的認可；
接著大家忙于新的測試和修改工作；
產(chǎn)品發(fā)布前，開發(fā)工程師進行了修改，然后直接發(fā)布，在開發(fā)環(huán)境下問題確實得到了解決；
最后公司對相關人員進行了連帶懲罰：
產(chǎn)品部經(jīng)理、項目經(jīng)理、開發(fā)工程師本季度績效考核降為最低，即下個季度每個月份都要扣除一定比例的工資；
測試工程師績效考核降為最低，同樣扣除了工資。
上面案例的執(zhí)行過程中，有幾處顯而易見的不合理的地方：
缺少文檔，尤其是需求文檔。文檔是測試的主要依據(jù)。如果交給測試組僅僅是一個軟件系統(tǒng)，然后告訴他“你們來測試吧，發(fā)現(xiàn)缺陷就提交”，我相信提交缺陷后開發(fā)與測試雙方幾乎會陷入喋喋不休的爭吵狀態(tài)。
測試介入太晚。只在系統(tǒng)測試階段才安排測試人員進行測試，實際上質量已經(jīng)失控了。尤其是沒有文檔，測試人員 無疑會把一些“缺陷”認為是合理的，而開發(fā)人員通常會自信地人為自己的開發(fā)工作是正確的。這樣，一些問題是否是缺陷就會最終交給客戶來完成。質量控制和測 試的相關工作沒有按照合理的流程進行必然會產(chǎn)生這種結果。要改變這種現(xiàn)狀測試工作就應該盡早地介入整個產(chǎn)品的開發(fā)流程。
回歸測試做的不合理。案例中在回歸測試時，“開發(fā)工程師修改完最后的缺陷后，把所有的模塊打包，發(fā)送給客戶”，這里明顯還缺少一次測試。所有的缺陷應該經(jīng)過修改驗證后才可以發(fā)布產(chǎn)品，最后階段發(fā)現(xiàn)的缺陷也不應例外。必須經(jīng)過這道工序才可以發(fā)布產(chǎn)品，因為修改可能會帶來新的缺陷。
產(chǎn)品發(fā)布的出口不對。案例中的產(chǎn)品最后是由開發(fā)人員發(fā)布的，這是十分不合理的。這些產(chǎn)品來自于開發(fā)環(huán)境，眾 所周知，很多缺陷在開發(fā)環(huán)境下運行時是不出現(xiàn)的。產(chǎn)品在經(jīng)過最后的回歸測試并且確定可以發(fā)布后，應該把經(jīng)過測試的產(chǎn)品而不是來自于開發(fā)環(huán)境的產(chǎn)品納入配置 管理基線庫，最后發(fā)布的產(chǎn)品應該從配置管理庫中提取的。
缺陷流程不合理。這個帶來嚴重后果的缺陷其實就是從不規(guī)范的流程“空隙”中逃脫的，原因主要如下：
缺陷的用戶權限控制不嚴。開發(fā)工程師無權決定是否延期或者暫時停止修改某一缺陷。案例中開發(fā)工程師自己決定延期修改，測試工程師也進行了認可，這是不合理的做法。
沒有對每個缺陷進行全程跟蹤。測試工程師應該跟蹤每一條缺陷，并確定修改后才可以進行關閉操作，而不是發(fā)現(xiàn)缺陷就完成了任務。
缺少了缺陷審核步驟。產(chǎn)品發(fā)布前，項目經(jīng)理應該對產(chǎn)品發(fā)現(xiàn)的缺陷進行審核，根據(jù)修改狀況來決定是否可以發(fā) 布。產(chǎn)品帶著缺陷發(fā)布也是正常的行為，例如微軟的大多數(shù)產(chǎn)品都是帶著缺陷發(fā)布的。重要的是對最后未關閉的缺陷進行合理的處理。這些缺陷要由項目經(jīng)理甚至是 技術總監(jiān)進行審核簽字后確定不進行修改后，才可以轉入產(chǎn)品發(fā)布。本案例中如果事先對缺陷做過審核并確認，就可以規(guī)避風險。
上面的諸多原因，必然導致了產(chǎn)品會遺漏很多缺陷。實際也是如此。開始發(fā)現(xiàn)的這個“嚴重缺陷”只是個開端，后面陸續(xù)發(fā)現(xiàn)的30多個缺陷才是上面這 些原因的“所以”。如果這30多個缺陷都要進行懲罰，公司可以收入一大筆。雖然公司根本目的是想把產(chǎn)品質量做好，并不希望處罰大家，可是找不出提高質量的 根本方法，只能出此下策以儆效尤。
產(chǎn)品發(fā)布后的責任究竟應該由誰來承擔？作者認為，應該根據(jù)具體的問題來決定。首先要意識到產(chǎn)品帶著一些缺陷是正常現(xiàn)象。如果純屬個人原因造成， 個人是應當承擔責任的，懲罰永遠不是最有效的辦法。實際上，本案例中的開發(fā)工程師在不到20天就提出了辭職并離開公司，給公司的產(chǎn)品開發(fā)帶來更大的損失。 提高質量必須從提高項目管理水平處入手，同時加強質量控制來避免類似問題發(fā)生。
4、小結
通過對上面三個案例進行分析，我們應該已經(jīng)意識到質量、進度、成本是相輔相成、同等重要的，決不可以忽略任何一個方面。尤其是軟件質量，決不要 因為它是非硬性指標就敷衍了事。此外，軟件測試作為質量控制的最重要手段，必須引起足夠的重視。本文所討論的案例，都是直接從實踐中來的，且具有相當?shù)拇?表性。那么，為什么為數(shù)不少的軟件企業(yè)會陷入上述“怪圈”呢？歸根結底就是短期利益心理在作怪。希望企業(yè)能夠通過本文的案例剖析，意識到問題產(chǎn)生的原因的 所在，進而提高軟件質量管理水平，建立合理的質量管理體系。