為什么要測試，我們測試的目標是什么?作為測試人員和測試經理或了解測試目的軟件開發人員也許不需要了解，但現在理念完全改變了，所有人都應該了解測試，不管是項目管理還是開發人員，以及其他團隊成員�，F在強調測試驅動，業務驅動。測試的目的是什么?最重要的目的是滿足用戶的需要。講到測試重要性，很重要的是成本問題，在軟件開發有這么一些階段，有需求分析階段，設計階段，編碼階段，還有測試和最終的交付階段，到產品上線的過程，如果我們發現問題越早，我們付出代價越低，如果到了生產線以后發現問題成本幾乎是以前的95倍，因為這個問題會有很多流程，如果到了產品生產線環境里，帶來的費用是非常巨大的。作為測試人員發現BUG應該很有成就感，這對公司有很大的貢獻。
講到每個階段產生代碼的個數，這是國際知名的軟件工程研究所發現的規律，每個程序員每小時產生4.2個缺陷，這數據會根據不同的開發語言，技術層面不同會有所差異，這是一個平均值。而且大部分的缺陷產生于生產、開發階段，在編碼階段產生很多的缺陷，到后面成本投入越來越高，盡早發現缺陷，盡早解決它，以降低我們的成本。
既然測試那么重要，給客戶帶來信心，幫助我們提高質量，幫助我們改進生產力等，我們如何做呢?首先有一個概念全壽命測試的概念，為什么叫全壽命，在軟件測試各個階段都要引入測試的理念，要同各個團隊打交道，測試團隊并不只是后端，進入最終代碼一級才有的工作，在我們之前會跟很多部門有溝通、交流，有需求，還有跟市場的部門，還有溝通渠道，還有對外交流，項目管理，IT部門，比如要有測試網絡，有IT部門的介入，有系列工具的部署，架構設計方法論等等，這一系列都需要有組織級的行為，需要在不同階段有不同協作的機制�？匆幌虏煌瑴y試階段的劃分，這是最早項目的起始階段，需求分析，到了項目問題的分析到了設計階段，到系統測試、安裝和維護階段，傳統的測試階段會在設計的后期，會有一些設計文檔可能會有測試人員介入或了解，到編碼后期測試工作會進來，這理念和過去講的傳統測試不一樣的，為什么要這樣設計?有他自身的依據，因為越到后面發現問題成本越高，而且傳統的說法，在測試階段發現很多BUG，很多BUG的分類很多是在設計這一塊出現的，并不是在編碼，設計的理念或需求分析就有偏差，在這個階段要抓住這個問題。
測試生命周期和開發生命周期，在全生命階段，我們所有計劃和需求兩個同步進行。而且是一個循環，往往會有多個周期，第一個循環，第二個循環是迭代式開發，為什么要盡早引入而且要頻繁測試。下面講到IBM的測試模型，在定義階段，項目要做什么樣的東西，項目范圍多大，項目要在什么階段產出什么樣的產出物，測試的準備工作，測試的計劃就會開始啟動。測試準備開始了，隨后會在設計階段，還有生成階段，代碼生成階段，對于單元測試，之后是集成測試，還有系統測試等等都會開始引入。還有測試軟件的配置管理，測試環境的建立，需求階段，定義階段，一直到最后產品上線，全程都有。有人覺得奇怪，軟件平臺搭建和軟件工具配置跟這有什么關系，其實測試跟開發是類似的，有很多要遞交的東西，比如測試計劃，測試用意，測試數據，測試的報告，測試中間產生的狀態，這些東西都是需要有一個測試的平臺來管理，因為你不是一個人作戰，你是一個團隊，項目越大，你測試不是一個人，是一個團隊或一個中心，很多人在里面需要一系列的產出物，這是需要有人管理的，不是在你大腦里或你手里的筆記里，這是沒有辦法溝通的，一個一個信息孤島是沒有辦法交流的，而且沒有辦法互相監測。不知道大家在座有沒有感覺，很多做測試管理和測試開發，測試培訓人員，他們面對最大的挑戰，我碰多碰到客戶講現在最大挑戰，是我不知道現在進度在哪兒，也不知道挑戰什么樣子，也不知道手下什么樣，這就是缺乏平臺導致的，所以環境的準備從頭到尾。
這是測試的各個環節，項目開始階段，代碼設計階段到執行階段是一一對應的，項目從最初的定義，測試的定義，測試的目標等等，通常講的是主要的測試計劃，各個層面的測試計劃�？蛻艚邮軠y試計劃、用戶接受測試計劃、下一個階段系統測試計劃。從這個側面看像一個倒寫的V，所以我們講V字型測試模型，現在反過來更強調X，為什么叫X?就是一個V再加一個V，上下兩個V就變成X，剛開始可能需求驅動測試，有需求，有項目的立項，有各種各樣的計劃，反過來，測試又會驅動開發，可能就變成X，再往后有更多測試模型叫W，一個V接一個V下去，多次迭代，每次交付了一部分的功能、代碼、設計，所以我們測試在不斷循環。
我們測試到底為什么服務?測試不僅僅是為開發團隊服務，這是很重要的一個思考問題，通常我看到測試團隊開發團隊協作非常緊密，事實上不僅需要跟它們合作，還需要跟需求的業務分析部門，甚至跟后面的運營部門，產品上線了，或者遞交到外部，我們更多的是要以整合業務的角度來看待問題，這是我們很重要的方面�？礃I務驅動的軟件開發測試生命周期，有不同角色劃進來，有最終用戶，上層的管理層，還有測試人員、開發人員，架構設計師，這完全是循環，跨平臺，跨部門，在各個階段都有測試的理念。
講了很多方法和理念之后，下一個理念要引入的，有這樣的方法和理念要建立什么團隊來支撐我們的工作，讓我們測試中心，測試團隊更有效。第一點是人才培養，第二個流程建設非常重要，如果沒有成型的流程，整個團隊遵循的規則都很難控制的，再下面有質量量化和工程量化管理，測試項目的管理，我會一一做介紹，第一個會講到人員，對人員有分工，角色與職能的分工。首先會有質量總監，測試經理和項目經理，會有架構設計師和軟件配置人員，還有后面的測試人員，最后還有質量分析專家，到了后期很重要的環節。所以測試是一門學問，需要很多人，很多人投入，有很多專業知識在里面，我測試有什么價值，怎么提升士氣和戰斗力時也有人問到這個問題。
關于IBM開發中心測試平臺和測試方法，IBM Rational常用的RUP，對測試管理的流程定義，通常會有這樣一個角色，這是人員，這是一個行動，這是一個流程在里面，會有很多的工作，有一個固化的流程幫助團隊執行這個工作。這是RUP中的測試方法學，生成的軟件做什么事情，有測試人員，有測試的分析人員，有純粹的設計人員，他們工作的內容不太一樣，這里強調是我們通過這些方面強調測試的進度和質量，一個需求覆蓋率，測試用例實現率，要開發測試用例，寫出來是不是執行到了，最后是統計分析，我們要對缺陷分布進行分析，這是一個需求管理，通過Rational產品可以把你需求細化到每一個用例，甚至一個需求用例對應好幾個測試用例，有分支，或正反向，測試用戶不同有不同的情況出現。
往往你的需求和測試用例對不上，但最后產品質量還是不好，最后客戶發現問題是你沒發現的，這時候就要借助你的工具。這是一個循環，每一個迭代產生一部分，因為更改可能帶來新的BUG，要做回歸測試，我不斷循環測試，是不是意味著人員的投入非常巨大，因為可能新的代碼出現，舊的代碼還要維護，測試的話，這里面提倡的自動化，盡量把程序寫的自動化一些。純粹的流程，人是喜歡自由自在的，喜歡無拘無束，寫再多流程文檔，要讓執行很困難，沒有人在后面拿鞭子抽他，沒有人愿意往前走，你要通過平臺和工具來控制他，所有東西才可控，軟件工業和傳統制造業最大區別，軟件是一個思維，頂多變成代碼，但這代碼意味著什么，很難理解，甚至這代碼很輕易被刪改和刪除掉，你測試用例可能很容易被修改和監測，測試經理很難找到數據，我們需要一個測試管理平臺，提供的功能是有測試計劃，測試用例的執行，測試報告，測試結果的跟蹤。
需要特別指出的重要一點，測試是一個團隊，不是一個人單獨做，因為一個人只能測一點，每個人之間要有分工，分工要有合作，整個項目是一個交集，合集，怎么了解分配狀況，需要集中統一的平臺，所有數據在這里交流，所有人可以看到相應的數據，這樣數據可以被公開和跟蹤。第一個是管理平臺，這里面有很多的細節，要測試要分布，比如有200個測試，要分布在10個機器上，我測試分布怎么做，最笨的辦法就是一個一個系統跑，遠程做一個一個跑可能要遠程做。第三個壓力怎么辦?我跟工行、農行客戶，比如信用卡，他設計5年10年以后有1億用戶，現在可能只有1、2百個，他怎么保證系統設施滿足將來的需求，只能通過測試方法，但是沒有測試環境，而且是并發的，而且不同的測試數據在里面流入，不同的測試流程，沒有自動化的工具可能做不到，現在給我的答案，沒辦法，這確實是一個問題，如果沒有手段，現在做就是試用，比如我到江蘇省，廣東省，在一個省里面推廣，沒發現問題就用了，將來有問題將來再想辦法，經常銀行系統通知大家，系統在升級，就是它需要不斷做調整，這會影響業務和成交額，前一段時間銀行有一個案例就是這樣。
Rational的最佳實踐測試方法，要測試工作量化，測試度量標準，建立測試任務的流程，還有測試案例管理統一模板，統一管理，一定要建立相應的測試管理的平臺，缺陷和變更的管理，以及自動化的實現。
延伸閱讀
文章來源于領測軟件測試網 http://www.k11sc111.com/
