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