往往在測試中，大家覺得來了測試任務就測試，時間久了，反而忘記了還有什麼規範？也就慢慢忽略了規範！
規範的軟體測試流程有助於需求條理化，將測試工作模組化，一切跟著計畫走比通過腦袋記憶要更加的有條理。有的時候，工作任務比較繁瑣，腦袋記憶力容易出現亂成一鍋粥的情況，特別這個時候，軟體測試計畫就更加重要。下面結合實際情況對自己工作中測試流程進行簡單的闡述。
測試策略就是如何進行測試，運用何種手段進行測試。當使用者提出新的需求時，測試人員應該和開發人員一起做測試需求分析，一般我們都會通過會議的形式去進行討論分析，這樣測試人員會對測試需求要有個大概的了解，需要是幹什麼的，包括哪些功能等等，而不至於什麼都不清楚不了解。
了解需求內容之後，就可以對整個測試進行預期估算，包括計畫要測試哪些方面的功能，測試的策略，要計畫分配哪些人員參與到測試中，哪些人負責哪個模組，以及按照交叉測試的方法，同時還要提前計畫好測試的開始時間和結束時間，以及測試計入條件和測試退出條件，便於掌控整個測試進度。
測試計畫規範之後，則是進行測試用例的編寫。測試用例的編寫，主要圍繞介面模組而展開，如介面包括哪些按鈕，按鈕操作是否可以正常進行，其次圍繞功能來設計，然後根據不同的場景來設計。對於測試過程中，出現的缺陷問題，要在將缺陷問題記錄到測試用例「測試結果」一列，便於檢視測試項測試任務情況。測試用例需要組織開發人員、測試人員、需求人員一起進行評審，評審通過後作為正式測試用例供測試人員執行。
測試用例執行之後，對測試過程中發現的缺陷，要匯報自己的測試情況，並且將測試中的缺陷反饋到測試工具中，便於開發人員解決。對於安排的不同模組的負責人在測試自己對應模組的任務時，也要及時的匯報自己的測試工作進度，便於測試小組掌握測試的整個進度。
按照測試用例執行完所有的測試任務，且開發人員修復完了所有的bug問題(不包含一些難以修復但不緊急的問題，)，測試人員需要編寫針對本次專案的測試總結，要在總結中說明，測試計畫是否按照如期進行。總測試缺陷資料多少，測試覆蓋度等。
系統測試完成後，文件編寫人員需要針對本次專案開發新增加的功能進行專案「公升級日誌」和「使用者手冊」文件的編寫。方便使用者了解並能夠快速上手使用新增加的功能。
最後，測試通過的軟體及文件需要cm發布檔案包，以便對外正式使用。市場人員可以編寫***等文件對外進行宣傳。
例解 如何將規範的過程敏捷化？
很多企業基於cmmi 建立過程體系後，大家普遍反應太複雜，編寫的文件太多，複雜的體系可能就無法貫徹執行下去，無法成為企業的文化。因此需要敏捷化，當我們對過程進行敏捷化時，是基於實效的目的而不是基於評估的目的。如何將乙個規範的過程體系敏捷化呢，下文將針對軟體企業反應突出 cmmi 中的dar 過程域為...
例解 如何將規範的過程敏捷化？
很多企業基於cmmi建立過程體系後，大家普遍反應太複雜，編寫的文件太多，複雜的體系可能就無法貫徹執行下去，無法成為企業的文化。因此需要敏捷化，當我們對過程進行敏捷化時，是基於實效的目的而不是基於評估的目的。如何將乙個規範的過程體系敏捷化呢，下文將針對軟體企業反應突出cmmi中的dar過程域為例，說明...
如何將oracle中的資料匯入到excle中
工作過程中需要將oracle中的資料匯入到excle中，自己做了一下，先將方法介紹如下，你可以根據自己的實際情況，做出更改。1,建立乙個emp.sql檔案我的是在f sql emp.sql set line 120 set pagesize 100 set feedback off 關閉類似於 已選...