1個月5次發版：測試人的模組測試策略分類歸納

筆者所在專案經歷了一個月開發週期，該專案有5名開發人員，1名專案經理，1名測試人員，涵蓋OA系統8個模組，在短短1個月中進行了5次釋出。

現進行模組測試策略分類歸納。

已有模組

配置項最佳化

對於已有模組的配置項最佳化，開發的主要工作是在流程後臺和系統模組配置模組中配置對應的適應各單位使用者的流程。

測試的策略在於流程測試，理論上配置不改動程式碼不會影響原功能，於是在流程測試過程中順便完成了迴歸測試。

在大家都認為沒有問題的資訊模組，測試過程中卻發現審批不透過時會報錯。

測試流程的主體思路是覆蓋正向流程和反向流程，在測試過程中尤其要注意反向流程，包括審批不透過時流程流轉到原審批節點，以及在原審批節點再次編輯並提交發起流程的場景。

總結1：後期遇到這種任務緊測試資源少的情況，對存配置的模組簡單測正反向流程即可。

功能最佳化

對於已有模組的功能最佳化，涉及到新增欄位、新增選單、新增流程，開發人員需要增加介面、增加資料表欄位，需要進行常規功能測試。

設計測試用例是必要的，雖然沒有時間寫測試計劃但是在大腦中已形成了測試計劃，知道測試重點、怎麼測試，對功能有疑點的及時找了開發確認，但是開發並沒有引起重視。

迴歸測試階段與專案經理溝通中，該介面被指出與所要求的不符，進行了又一輪修改。

在開發工期緊張的情況下，開發不一定會去把所有疑點確認，測試人員應該再找到專案經理一起確認，避免後期開發出的功能不符合需求的情況，減少後期修改帶來更多的時間和成本代價。

整體測試過程中，由於有設計的測試用例做指導，基本覆蓋住了正常和異常的業務場景，主流、分支流的流程測試，四種場景流程均進行了測試，保證了釋出功能的質量。

總結2：功能測試需要以設計的測試用例為指導。在開發工期緊張的情況下，測試人員有必要將功能歧義點和開發、專案經理一起進行確認，減少測試的功能南轅北轍的錯誤發生。

新增模組

新增管理模組

對於會議室管理、供應商管理、工作聯絡函、生產任務管理這些新模組，涉及到新增模組、新增流程，開發人員需要搭建介面、寫介面文件、設計建立資料庫，需要進行常規功能測試。

在這一測試過程中，專案團隊在建立初期，測試流程不規範，口頭提測，於是加強了測試流程宣貫和流程規範工作，這一過程中要力爭得到上級專案經理的支援。

首先讓開發人員送測時提供送測單，在測試前溝通好送測影響範圍和測試重點，避免測試工作偏頗影響進度影響上線。

具體實施過程中只有會議模組進行了測試用例編寫，迫於上線壓力測試時間壓縮，使得在上線前測試工作僅完成了92.31%，釋出後出現了遺漏問題。

會議有6個子模組，開發的送測程式碼質量不高，測試時間只有2天，要避免這種情況必須靠加班趕工，但是當時沒有與專案經理溝通是否能延遲時間。

遇到這種情況需要跟開發、專案經理溝通，線上釋出前告知專案經理可能存在的風險。即便後期出現了問題，專案經理也心裡有數，不會過多責怪。

總結3：時間緊的情況多與專案溝通，協調資源。

無測試用例

對於新模組，沒有設計測試用例，第1個模組僅一個選單，1條流程分支，兩個流程節點，第2個模組2個選單，4條流程分支，每條流程分支有2個流程節點。

開發人員講解了測試重點，有可能產生問題的地方，這些也是開發人員清楚的地方。

測試策略是以需求文件為準校驗頁面欄位和審批流程，以流程為主線校驗業務邏輯。

總結4：迫於上線壓力未準備測試點情況下，找開發溝通測試重點、可能存在的問題處，做到有的放矢。

市場千變萬化，產品需要迅速推向市場，並在使用者使用過程中去做小範圍最佳化，專案成員需要適應這種變化，最近裁員風波不斷，測試人員也需適應並擁抱變化，加強自身的戰鬥力，以使自己經手的專案質量經得起使用者和市場的考驗！