我們做軟件測試的，往往都是以Bug量多為衡量標準。測試的目的是為了發現更多的Bug，這點永遠都不會錯，但我們經常會為追求更多的Bug而忽略了軟件測試的更本質的東西，個人認為軟件測試的終極目標是提供給一個讓客戶滿意的產品和服務。所以說，我認為只有真正去理解客戶所關注的業務，才能從本質上更好的改善我們的工作。

·         目前的問題

或許有過這樣的經歷，一個軟件（項目），在測試過程中往往會發現幾百個甚至幾千個Bug，可是客戶依然對我們所提供的質量保障喋喋不休。從我經歷的一些項目和產品來說，感覺不外乎三個原因：

1、測試的力度和深度依然不夠

我感覺主要是人力資源和時間上的緊缺造成的。人力資源，通常一個產品測試，往往都是一個人負責好幾個模塊，項目上更是一個人既負責環境搭建，又要負責測試用例的編寫，還有負責功能測試以及最后的報告編制，很難做到面面俱到。加之一些項目客戶要求的時間緊張，所以最后測試即便能夠達到通過標準，在客戶那里依然會有很多問題，當然，這其中的原因也包括需求設計的不確定以及后期的變更。

2、環境的不同，包括硬件環境和軟件環境

在我們內部測試，不僅需要一個干凈高效的系統環境，我們的個人電腦，也就是通常意義上的客戶端，往往都是比較高的配置。而在客戶現場，這些幾乎都很難一致。加之客戶現場的一些突發事件，都會造成一些低級但很嚴重的Bug。

還有一個比較重要的問題，就是數據環境。因為我們測試往往都是在一個干凈的系統里新建一套帳，再手動或自動化初始一些簡單的數據，然后再分配職責進行測試。而客戶現場的情況則要復雜的多，很多都是在原有數據的基礎上進行安裝、升級或者移植，這些案例我們實際考慮的并不是很多或很全面。

3、測試過程沒有真正以客戶關注為焦點

測試有時遇到這樣的情況，拿來一個模塊可能知道一些業務流程知識，或者是一點不知。測試主要就是通過自己的操作和理解，加上一些與開發人員的交流來進行。測試過程大都通過菜單一級一級的往下進行，數據都是通過自己的經驗來組織出來的，感覺主觀性比較大。所進行的測試，大多應該稱為功能測試，而不是業務測試。最后能夠確保所測的功能點不出錯誤，但是卻沒有真正的站在客戶的角度去理解這個軟件、這個功能。

·         建議

個人認為最重要就是測試盡量全面的模擬客戶現場。感覺可以通過一下幾點來進行改善。

1、制定比較完善的測試周期。

大體可以分為三個階段：

1）單元測試。這個測試可由開發人員或設計人員自行完成。主要是驗證所寫的功能和設計的一致性，當然前提是設計最好是能確定以及肯定。

2）集成測試。這個測試階段主要的目的是能夠確保整個功能流程能夠走通，無嚴重錯誤。

3）真實業務測試。嚴格按照客戶的業務流程、數據和職責進行測試。這個感覺目前實現起來還是比較困難，主要是對真實業務的理解需要深入。但如果能有一套完善的測試用例，相信這個階段還是可以實現的。

2、測試環境搭建盡量模擬客戶現場。

可搭建多種測試環境，或者分Build搭建不同的測試環境?？捎行陆◣ぬ?，也有舊帳套基礎上進行升級測試。感覺這個我們目前開展的還是比較多的，也是蠻有效果的，以后可重點再關注一下升級后原有數據的驗證和操作。

3、測試過程要真正以客戶關注為焦點。

我們可以通過與各方面人員交流和自己的學習，首先要弄明白一點，客戶想用我們的軟件實現什么，也就是客戶使用我們軟件的目的，包括各個職責的，例如系統管理員想通過我們軟件實現什么，經理想實現什么，出納、會計、審計他們分別想實現什么。因為很可能會有這種情況：我們測出了成百上千的個Bug，但是客戶最為關注的東西我們所涉及的卻不多，而把太多的測試工作都投入到客戶并不是特別關注的功能上來了。

等這些明確后，再去進一步分別了解這些目的是怎么實現的，實現過程中需要分步驟分別操作那些功能（業務）。如果這些都明確后，我們就可以組織一些具體詳細的數據，嚴格按照客戶的實現方法進行走查，這個過程最好能與客戶或者熟知客戶業務的人員一同進行。當然，這只是測試的一個階段，之前的全方面集成測試還是必不可少的（主要用來發現影響流程的嚴重Bug）。

再就是一點，測試過程中，一定要充分利用需求設計和數據結構，應該會對功能點業務測試以及數據驗證起到很大的作用。

以上文字都是根據個人的工作經歷所總結，肯定會有很多不足或欠妥之處，希望大家多多批評指正。