本文以乙個工作流測試專案為例， 總結了在測試過程中積累的經驗，**了目前國內軟體開發企業在軟體測試過程中遇到的問題以及解決的方法。測試專案背景和實施情況工作流在某公司軟體產品線中占有重要地位，***5.2
workflow專案是5系列中的乙個小版本，主要增加了任務代辦、任務**、以及任務交接等功能，同時還修復了一些易用性和功能性的bug。下面，我們大概介紹一下這個專案的實施情況：
● 專案規模與測試人員配置：
○ 專案**行數：5萬行
○ 開發人員配置：開發人員5名、實習生1名
○ 測試人員配置：測試設計人員1名、測試執行人員2名、實習生1名
● 專案測試時的系統部署情況:
● 測試預期與測試執**況整個測試專案是比較成功的，專案的時間執**況和預期的測試指標度量都比較接近。發現bug總數和缺陷密度都達到了要求的標準。當然，測試週期的實際值比計畫值晚了兩周，原?因是在系統測試後期，為了滿足pso部門提出的定時器需求造成了一定的延期。回顧整個專案的測試過程，我有幾點小小的感悟，願在此和大家一起分享。
測試如何盡早介入
基於以前的測試經驗，我們也越來越認識到測試人員應該盡早介入專案的重要性。簡單地沿用測試v模型往往出現很多問題，特別是在專案進度拖延的情況下更是如此。如果測試人員一味固執地被要求嚴格按照v模型定義的標準來開展測試工作的話，則結果往往是在專案初期測試人員工作量極度不飽和（很多測試人員無所事事），而到了專案後期，一旦專案經理決定壓縮測試時間，測試人員就不得不加班加點地工作。但是，不少朋友實踐「測試人員盡早介入」的效果並不理想，例如：
● 測試人員參加專案前期的各種會議，會被當作「專職的」會議記錄員。
● 測試人員參加**評審，又不甚了解程式開發語言，浪費了時間其丟失了自信。那麼，在這個***5.2 workflow專案中我們是怎麼做的呢？實際上，在專案開發初期，測試人員可以開展很多有價值的工作，例如：
● 評審需求文件的正確性和可測試性；根據需求文件整理和分析測試需求，清晰明確的測試需求是測試設計的基礎。
● 在開發設計過程中，根據需求文件和設計文件進行測試設計，測試設計方案是測試用例的保證。
● 和專案團隊中的整合組和開發組協?商軟體版本的編譯方式和編譯進度以及測試人員提取版本的方式和進度。
● 開發人員每天下午4：30之前提交所有可編譯的**，每天晚上進行日編譯；
● 開發經理根據版本穩定情況，每週提交測試申請單。
● 測試人員根據測試進度需要，提取測試版本。
● 提前準備測試環境，包括資料庫環境，作業系統和web應用伺服器，以及複雜集群環境。
● 如果專案需要，還可以在此階段研究一下自動測試工具，包括一些準備外包測試的工作。根據產品的成熟度調整測試策略開發測試一盤棋。測試經理應該有大局觀，保持測試策略總與開發的進展相一致，保證最終的軟體成果最佳（而不是測試部發現bug數最多）。在這個***5.2 workflow專案過程中，我們合理制定了不同階段的測試策略，收到了很好的效果。
產品開發期同情的測試
要忍！要在這個能夠發現大批bug的**時段學會做減法。就現實而言，這個階段的產品，大多難以滿足系統測試的條件。如果進行窮兵黷武式的測試，無疑會加重開發人員的焦慮心情，甚至對測試產生逆反心理。另一方面，測試工作不應停滯，特別是不少測試人員對產品的了解還流於皮毛，抓緊時間進行「測試練兵」非常有必要。因此，「產品開發期」的測試切忌生硬。其實，此時程式人員也知道產品還不成熟，所以要告訴測試執行人員：
● 這個階段不要提交介面簡單錯誤和易用性方面的bug（可以先記錄下來到專案末期提交），否則會使開發人員質疑測試人員只會發現簡單的bug。
● 換位思考，了解此時開發人員最關心的是功能是否能正確執行，多對基本功能進行測試。
產品成熟期積極的測試
隨著產品的不斷成熟，主要功能的實現已經趨於完善，關鍵路徑的測試已經不成問題。此時的程式設計師們，壓力已經大大減輕，他們的工作重點也從「構建」轉移到了「修復bug」，這個階段程式人員對於bug的接受程度是最高的，對bug的修復和反饋也非常積極。於是，此時的測試工作應對整個產品的細節和所有路徑進行覆蓋測試，保證測試的全面性，層層深入地測試產品值得測試的各個部分，盡可能多的發現並報告bug。
產品穩定期多樣的測試
在這個階段，可以盡情的向開發人員報告產品易用性和介面的bug；可以充分發揮每個測試人員的想象力，根據以往的測試經驗來搭建測試場景，構造測試資料；可以通過不同業務場景的不同操作，通過特殊的測試資料，以及相對複雜的集群測試環境來進行多樣化測試。為什麼？因為此時必須測試得更加深入，才能發現更深層次的bug，於是多樣性的測試、探索式的測試必不可少。產品發布期謹慎的測試在臨近產品發布的日子，包括測試在那的很多任務作都變得謹慎起來：**的提交許可權受到了控制，只保留開發經理乙個入口；測試的重點更加具有防禦性，要仔細測試每個變更，還可以組織「結對測試」來增加測試的保障。測試經理應知人善任為了保證測試工作的質量，首當其衝地就是應該有專業的測試團隊。在很多小的軟體專案中，往往沒有專門的測試團隊。這樣一來，到了**基本完成之時，就只能從客戶支援部門或研發部門抽調一些人手臨時拼湊出「測試團隊」進行幾周的測試工作，測試質量難以保證。我們則會盡早規劃測試團隊的人員結構，完善測試團隊的配置。每個測試人員的特點和強項常常不盡相同，例如，擅長測試資料質量的測試員，未必能勝任系統環境配置複雜的測試任務。總之，對測試經經理而言，做到知人善任非常重要。同時，在專案測試過程中及時進行調整有時也很必要。此次測試的工作流系統，要求測試人員不僅應掌握一定的工作流業務知識，還需要有較強的邏輯思維能力。而在此專案測試過程中，筆者發現一位測試人員對功能的細節過分關注，而對整個工作流程總是理解不到位。顯然，其設計出的測試用例不能適應工作流測試的要求。於是，立即進行人員分工和測試任務的調整，保證了測試工作順利進行。堅持立場，規範流程我們公司有嚴格的測試流程，所有提交測試的軟體版本，在提交之前，都要完成必需的冒煙測試（smoking test）。冒煙測試是一種測試包，其目標是檢查版本的基本功能。這個測試包是由測試人員根據測試用例中級別為「基本」的測試用例抽取出來的，如果該版本沒有通過冒煙測試，則就可以說明該版本不太穩定，不值得提交測試人員進行系統測試。有的公司冒煙測試是由測試人員手工或者自動測試。在我們這個專案中，為了保證每個可測試版本的冒煙測試質量，是由開發人員負責完成的。他們知道，如果程式不能通過冒煙測試，測試小組就會拒絕該版本。因此，他們會填寫乙份提交測試申請表來申請進行系統測試。在這份**中，不僅會明確版本號，修改或新增的功能詳細說明，還會給測試人員提供此版本的測試重點，以及可能會影響到的功能。這些內容對測試人員都是至關重要和大有裨益的。
在專案測試過程中，我們也出現過打回某個版本的情況，拒絕測試。總結起來，基本上有以下幾種情況：
● 由於任務查詢的技術難度比較大，開發進度已經延期了5天，測試人員正在焦急的等待這部分的功能測試。可是，新提交的可測試版本中，這個功能根本就不能使用，如果進一步測試就是浪費時間，我們立即打回了這個測試版本。
● 新增了代辦的功能，可是以往的**功能中的增加**人功能卻不能正常使用，而增加**人功能又是代辦功能的基礎，也就是說，在這個版本中，及時代辦功能完全能夠測試，可離開了增加**人功能，代辦測試是沒有意義的。
● 在回歸測試階段，可測試版本的提交是比較頻繁的。開發人員一旦解決了一部分bug就會提交乙個可測試版本，如果此時測試人員並不急需更換版本，並且得知另乙個版本會在幾個小時之後就會完成，我們可以不測試這個版本。為了能更好的完成冒煙測試這個關鍵階段，測試人員積極與開發人員配合：
● 負責提供冒煙測試案例。
● 如果測試人員處於版本等待階段，主動和開發人員一起做冒煙測試。開展有效測試，提高測試效率有效的測試用例是軟體測試成功的關鍵，有助於提高測試效率和測試覆蓋率。在這個工作流軟體測試專案中，我們從測試模型（test model）入手，結合豐富的測試經驗和專業知識，從繁多的測試用例中挑選出有效的用例，用盡可能少的測試輸入，覆蓋盡可能多的軟體需求。主要採用了狀態機模型和組合模型，並結合了正交設計技術和組合覆蓋技術，完成了對整個系統的測試設計。詳細內容可以參考筆者在《程式設計師》雜誌2023年第4期上的文章《基於模型的有效測試用例設計——工作流系統測試實戰》一文。知己知彼，合力制勝提供服務使測試人員有機會贏得程式設計師的信任，同時也有機會展示自己的才能。同時，帶來的回報是得到了開發人員對我們的幫助。在整個專案過程中，我們獲得了很好的回報，比如：開發人員講解設計思路、演算法流程；和測試人員一起構造測試資料；積極參加每日測試例會，主動解決問題等。這樣良好的合作狀態與測試人員的主動努力是分不開的，主要體現在：
● 獲取程式設計師信任，及時溝通不要與被測程式的開發人員形成不必要的敵對關係。如果能與打交道的程式設計師共享資訊，比如他們的計畫、設計文件的早期草案和早期原型等，測試工作會更加有效。越早與程式設計師接觸，情況就越好。盡早提出你的意見和反饋，了解程式設計師提交前完成的工作。
● 主動出擊，提供服務 ○ 在測試前期，直接向開發人員提供服務；這不僅可以建立信任，而且還可以證明測試人員是能夠與之合作的人。我們在專案過程中提供給開發人員的服務：○ 對工作流的運算邏輯?構件進行了測試，方便了後期開發工作流客戶端應用的使用。○ 對內部版本和原?型進行測試。○ 對需求文件的可測試性進行評審。開發人員和測試人員一樣，對模稜兩可的要求很頭疼，他們非常希望測試人員的介入。○ 幫助程式設計師建立測試環境，方便程式設計師進行測試。
● 耳目作用
○ 在專案過程中，測試人員有機會能夠發現很多存在的問題，比如：需求和設計以及開發的不一致性，專案計畫中工作任務的缺失等等。測試人員不要僅侷限於測試命令鏈本身，及時驗證和發現專案環節中的問題。總之，測試專案能否成功，與整個專案組的精誠合作是密不可分的。測試人員是一種服務角色，要樂於接受這種角色，只有這樣，才能得到被服務的人的幫助和支援，以及認可
(文 / 徐異婕) 徐異婕，10年軟體開發與測試從業經驗，對需求分析、測試設計、測試管理、測試分析有深入研究。目前在普元軟體從事測試工作，曾在中國工商銀行總行軟體開發中心從事測試工作。
乙個典型軟體專案的故事
acme公司的widgets系統出了點問題。這個系統被他們用來管理器材的庫存，當初設計時沒考慮到如今這樣大量的資料的增長。他們的員工因為這個問題備受折磨。很顯然，需要想辦法解決這個問題，讓系統恢復正常。經過對本地軟體公司的一番篩選，acme聯絡到了hamster軟體公司，看看他們能否解決這個庫存系統...
什麼是軟體專案的成功
傳統觀念上的成功是指基於給定的財政預算，按照需求規格按時交付產品。standish 中給出了一些經典的定義 成功的 successful 按時完成，費用不超出預算，而且所有特性和功能都符合原先的設計規格。不太成功的 challenged 已完成而且可以執行，但費用超出了預算，沒有如期完成，擁有 的特...
乙個專案的感想
去年真正做了乙個專案，有些感言，寫下來，為以後作專案積累經驗。這個專案很簡單，但是從這個較簡單的專案中，我體會了很多，其中包括對使用者需求的理解 自己的做事風格的反省 專案實施的情況。首先，我談談專案的情況 這個專案是乙個資訊發布系統，很簡單吧，但是，其中有一方面是規章搜尋，並且要生成規章成冊。而且...