說說軟體測試

標籤：sp   資料   問題   代碼   bs   工作   時間   管理   伺服器   

        近日小組討論會中，對項目工作過程做了些總結；我自己也針對自己經曆的項目做了一點思考。
        一個項目的成敗衡量標準就是軟體品質，軟體測試關乎軟體品質，所以我就談談自己經曆過的軟體測試。
        （注，純屬個人觀點，不同的公司，不同的項目，不同的領導，軟體流程不同）
        在我早期工作過的一個軟體項目中，還是一個嚴格的CMMI流程。一個項目團隊分為2組：開發組合測試組；開發測試各司其職。測試與開發流程齊頭並進：需求分析（需求分析）->測試規格（設計規格）->測試計劃(開發計劃)->簡要測試方案（概要設計）->測試方案（詳細設計）->測試案例（編碼、單元測試）->整合測試（聯調）->迴圈(系統測試（解bug））->迴歸測試(打補丁)->驗收測試…
        在如今敏捷盛行的時代，項目流程基本上都邁入敏捷模式，在敏捷項目團隊中，開發與測試乾脆混為一個團隊，並沒有明顯的開發測試，只是不同的成員根據自己的喜好選擇不同的任務。敏捷通常以3周（2周或1月）為一個迭代周期，測試工作根據需求被劃分為一個個小的任務，通常在1個或多個迭代完成。迭代的宗旨就是快速交付，測試工作和產品品質也隨著不斷交付加強。
        隨著流程在業界不斷標準化，國內外流程基本上大同小異，只是在執行時會不同。
        說說流程的好處吧：流程必然是經驗的總結，走流程總比瞎折騰好。讓我記憶最深刻的一次走流程就是：寫測試案例；在某一項目中，專案經理嚴格要求寫用例（根據預估代碼比例），哪怕是一個參數的驗證都要寫7、8個用例（空值、邊界內、邊界值、邊界外、超長大值、亂碼…），起初我覺得非常消耗時間，是沒有意義的；待真正測試執行時，我認識到很多以前寫的用例是當前想象不到的，加上靈感激發新增的用例，覆蓋率加大，感覺踏實多了。
        有時，當面對進度與品質博弈時，常常、流程被拋棄了。在我上述的那個標準CMMI項目中，詳細設計評審未過，計劃時間又到了，專案經理一聲令下：詳細設計暫時先過了，開始寫代碼吧。在後續測試階段，一堆堆bug追溯到詳細設計中未解決的問題。後來，邊寫文檔，邊改代碼，邊測試。
        敏捷，有時也同樣會被玩的變味。每個敏捷周期都有一個目標，當周期結束，目標沒達到時，我經曆過兩種截然不同的方式：A公司，加班；搞不定，繼續加班；有時，3個星期的迭代硬是拖6個星期才完結。B公司，照常結束，總結目標達不到的原因。
        無論測試流程怎麼變，測試手段不會改變：手工，參考模型、自動化，持續整合、效能、實景測試等等。在這裡主要講一下參考模型吧，因為參考模型非常“昂貴”，一般項目不會採用。參考模型就是在開發過程中，從開發或測試人員中挑一批人馬出來用不同的方式來實現相同的系統。測試時，測試人員通過相同的介面輸入，比較2個系統的輸出，輸出結果一致是必須的；開發過程中，主Team Dev與參考模型團隊是隔離的。
        在一個項目中，自動化能力強的項目品質必然好於非自動化、半自動化的項目。如今，越來越多的公司注重自動化和持續整合測試。在我工作過的某個項目中，功能、系統、效能、持續整合等已經做到了全自動化，測試代碼與應用代碼環環相扣，每一句應用代碼的改動、每一個考慮不周全的地方都有可能牽一髮而動全身，確保基礎版本絕對的安全。
        自動化的優勢是不言而喻的，但是自動化維護難度大、要對系統有足夠的理解，測試人員必須穩定，才能有效與開發人員溝通。非自動化測試產品品質因人而定，人的隨機性太強了，資料遺失、離職都會讓測試執行推倒重來。
        在測試越來越受重視的同時，對測試人員的要求越來越高。說說軟體測試工程師，軟體測試工程師相對開發的路子更廣，因為軟體測試人員需要接觸客戶，瞭解系統業務，系統運行環境、協調與開發、營運的關係，測試人員將來走向市場、管理更容易些。一個測試人員最基本的素質是：嚴謹、注重細節但不鑽牛角尖、追求完美、不斷學習。
        在大肆節約成本的時代，測試流程常常還是會隨心而定；很多專案經理不管測試與開發人員的思維、意願不同，在項目初期，經常拿測試當開發用，後期，又拿開發當測試用，全然不管什麼流程。但是，一個成熟的Team 專案中，流程是永遠不會變的，流程只是會被最佳化、改進，面對問題時一直在總結、解決、繼續前行。
        ……
        寫這篇文章，是因為自己曾經在測試崗位上幹過一段時間，依稀還記得那年一個人在幾百台伺服器環繞的移動機房，伴隨著冰冷、雜訊、輻射做效能測試時的情境。

 

說說軟體測試