對測試的理解

• 基本思想
• • 一、 測試在項目中的定位和測試的理念
  • 二、 保證測試的常用方法
  • 三、 測試經理需要的配合

基本思想

這里只是個人認為測試經常保持的基本思想否則測試就是單純為了測試而測試，下面的這幾點如果做到，測試才真正的發揮作用，并且這個過程需要管理層和項目經理的認可和配合。

一、 測試在項目中的定位和測試的理念

1、 測試是要貫穿整個項目周期的，是項目經理的有利助手，項目經理和測試經理應該是類似于部隊軍團長和政委之間的關系，相輔相成的。；
2、 測試經理不應是單純的發現系統存在的缺陷，而是應該對項目風險（比如有風險的程序模塊、項目進度風險等）有提醒預警的義務和責任。
3、 測試和項目經理的最終目標是一致的，但是測試在原則上是不能允許測試未完成或者遺漏缺陷上線的，如出現此情況應該由項目經理申請經高層領導決策是否上線。

二、 保證測試的常用方法

1、評審非常重要，未雨綢繆、防范未然、謀定后動都在這個環節上，如果沒有好的郵件評審反饋意見的習慣，就一定要會議評審，前期浪費些時間可以減少很多風險，項目成本的概念就不多說了。
（1）需求說明書形成后，測試需要評審需求的可測試性及是否有風險，提醒項目經理規避風險。
（2）設計說明書形成后，需要測試評審可測試性、交易及數據的可跟蹤性，如有問題提醒項目經理規避風險。
（3）測試需求和測試案例評審時，項目經理、需求人員、開發人員應該參與評審，需求人員檢查是否有遺漏的功能，開發人員根據自己修改的內容，檢查測試需求和案例是否有遺漏對修改內容的測試。并提醒測試人員重點測試哪些模塊。
（4）評審的講訴者一定要講出自己對需求的理解和工作思路。
2、項目保障預警提醒
（1）進度預警，如果開發不能按時送測，測試經理應給項目經理預警在指定日期（可以是計劃日期，也可以是計劃日期后寬限的日期）不能送測對測試進度或者整個項目進度的影響。
（2）功能模塊風險預警，當測試發現某個模塊缺陷集中時，應給項目經理預警，項目經理應安排對該模塊進行整體治理，不應在繼續大量投入測試，否則對測試進度、項目整體質量和項目成本控制都是不利的。
（3）缺陷預警，當缺陷出現爭議（包括開發和測試有爭議或者關聯系統間有爭議）、缺陷反復出現三次或以上、缺陷駐留時間過長等，應給項目經理預警，召開缺陷討論會議，盡快明確缺陷責任、缺陷修改方案和計劃等。如多個關聯系統測試時建議缺陷催促應采用首發負債制度（既首個接到缺陷的系統開發人員負責跟蹤到缺陷關閉），但項目經理應起到監督作用，測試應繼續關注及及時預警。
（4）項目保障，當項目經理不能及時處理項目風險，導致不能按時送測或者缺陷處理不及時等，測試有義務向上級上報風險，已保障項目風險上級及時了解，采取應對措施。
3、環境部署方面
（1）環境方面，測試環境由對應的測試經理管理，主要負責申請資源、申請配置修改、及測試查詢日志等，但是可修改或部署權限的用戶由專人管理。測試應只有可讀權限，對數據庫數據可以有適當的修改權限
（2）部署方面，測試環境部署和生產環境部署，最好是同一批人員。開發送測后，部署人員按部署手冊部署，這部分人員最好具備系統工程相關知識，對操作命令應比較熟悉。并且可以處理測試提出的參數配置修改等日常出來和維護。
4、測試人員管理和分工
（1）一般情況寫測試案例的人和執行人都是同一個人，可通過測試案例由其他人執行的形式進行交叉測試。可以通過這種方式更多的發現問題，避免因視覺疲勞引起部分缺陷不能發現；也可以通過此方式檢查測試執行情況，如果遺漏的大量需求則測試人員需要進行說明和整改；同時也可以未人員備份做準備。
（2）測試的工作是比較雜比較細的，如果有不細致認真的員工，可以通過細化測試案例，通過測試案例跟蹤，比如檢查測試數據等，對測試工作進行監督。讓員工被動的工作。
（3）經常測試的系統，測試案例執行時間是可評估的，分工時應充分考慮時間可控，其他因素也要考慮，比如：如果測試數據是否有不同狀態，測試案例的執行是否需要前期準備的，如果有多個系統參與批量，批量計劃應謹慎編排并嚴格執行，不可隨意更改批量計劃。
5、應及時定期發測試報告
進入測試階段后，測試報告應定期發給項目相關人員。報告內容應明確說明當前進度，缺陷狀態，是否有風險，風險描述，影響范圍等。每個需求應單獨發測試報告。

三、 測試經理需要的配合

1、 需要項目經理緊密配合，測試提出缺陷預警風險，項目 經理應充分重視，并擺正態度，測試在幫助項目經理，一切為了項目不要認為是告狀。測試需要項目經理建立起開發和測試的合作紐帶。
2、 測試需要把握測試的基本原則，不能因其他考核等影響原則。如不及時提交缺陷或預警風險，是對整個項目不負責。

總結

以上是生活随笔為你收集整理的对测试的理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。