測試角度看公司流程規範對比後篇

　　想想現在，已經輾轉流離了兩座城市的風景了。
　　對於城市來說，風景一直都在，只是熟悉的地方我們心底比較難以當做風景。
　　很多時候，愈加熟悉的東西我們就越容易不去珍惜，也越容易不去感悟對比。人如是，生活如是，工作亦如是。
　　僅以此文，記錄近期所感。
　　最近，公司的專案是越來越多了，多的讓人有些惶恐，然而即使多，也要儘自己所能做完才行。
　　之前的一個專案，由於在設計上的失誤，導致上線時和線上的資料庫中的資料對不上，而重新加做了一個版本：資料同步。然而，因為專案比較多，測試的人力 很少，很多流程要求的又比較嚴；同時，策劃的要求又非常低，低的只要能保證功能實現，至於健壯性、異常處理等都不做要求（因為這個專案的使用者就是策劃自 己）。
　　於是，中間關於需求和流程方面出現了很多矛盾，簡單整理如下：
　　1.  由於公司在測試流程方面劃分比較嚴，所以要求策劃提供的需求要能涵蓋正常、非正常的功能點，並且對於程式的限制能夠儘可能詳盡的提供；然後策劃僅僅需要一 個正常的資料匯入功能，在滿足這個基礎的前提下，其他所有的限制不管有無都可以接受。加上策劃本身對於程式不是很瞭解，所以很多地方都是以開發提供的為 主，而開發在提交測試程式前並沒有對自己的程式進行詳盡測試，一些地方也語意模糊，不能定論；
　　2.  因為這個專案只是在原有專案的基礎上做了一個附加的功能，所以主要的測試就是和迴歸測試，可以說算是一個快速響應型的二期專案；但是由於資源等限制，需要重新制定測試計劃、TestCase修改、重新走一遍測試流程。
　　3.  因為開發提供的一次可接受匯入的最大限度的資料條目數量不確定，所以連帶的效能測試的指標也不好評估。當然，目前的所謂效能，其實是個坑，只要伺服器不掛就沒有任何話語權。。。
　　分析下上面的3個問題，其實最關鍵的也就兩個方面：測試範圍和測試時間。
　　這個也是大多數專案最糾結的地方。
　　如何更有效的劃分測試範圍和測試時間呢？之前老大曾經告訴我一些東西，結合自己的一點感觸整理如下：測試範圍=修改範圍+影響功能範圍+其他；測試時 間=測試準備時間+測試執行時間+測試報告時間+開發fix時間+bug追蹤管理時間+idle時間。所以我們可以大致的得出測試範圍和測試時間。
　　但是這個測試時間在很多情況下都只是一種理想情況。如果我們都按照這個公式來安排，在專案緊的情況下，專案經理和需求策劃肯定會拍桌子跟你叫板的。於 是，測試人員很多時候都會悲催一些，除非你是老大，還有可能會好一些。既然我們不可能都是老大，那麼我們常用的測試時間的估算方式應該是：測試時間=測試 準備時間+測試執行時間+測試報告時間，至於其他的時間就需要我們自己做一些調整和工作上的最佳化來保證我們的工作能正常進行下去，通常會在實際執行時間上 乘以1.2或1.5來保證其他測試工作正常執行下去。
　　當然，我們的那個專案最後也只能以百分之百的考慮來完善其百分之十的顯式需求和若干隱式需求。
　　無論如何，既然我們是一個測試人員，那麼我們就得好好做好手中的事情。雖不能保證其完美無瑕，但也要保證其抗摔抗砸。
本文轉自：