版本發佈後大部分測試人員的意識裏面都會認爲該要好好休息一下了，放幾天羊，作作其它和已發佈版本沒有相關的事情。其實版本發佈後測試人員還有不少事情須要去處理，須要去總結、歸類、反思、分享。我這裏主要探討幾個問題：版本發佈後用戶反饋如何；版本測試過程當中碰到了那些問題；版本測試發現的缺陷狀況如 何；測試過程當中有沒有漏測；javascript
第一：版本發佈後用戶反饋如何。前端
通常的系統須要都須要提供一個用戶反饋入口給到用戶，這個功能在互聯網企業基本上都會有，當用戶在使用過程當中發現問題時用戶會提交問題到公司的support系統，客服人員 會跟蹤用戶反饋的問題。並且客服人員會按期推送系統的質量報告給到相關人員。那麼除了客服人員跟蹤用戶反饋以外，測試人員要怎麼對待用戶反饋呢？java
一、用戶反饋的問題是否是一個bug？若是是的話就要分析爲何在測試環境下沒有發現，而到了用戶那邊就出現了：是咱們的測試場景覆蓋不夠嗎；是用戶的環境太複雜了，和測試環境有多大的區別；仍是測試人員偷懶、過於自信輕鬆放過了bug；web
二、用戶反饋的是之前系統有的功能如今沒有了，操做習慣改變很大。那測試人員就要反思，爲何我測試的時候以爲系統操做起來很方便，並且操做習慣改變也 不大。是否是測試人員的思惟習慣和用戶差距很大，文化差別也大；那測試人員要總結如何站在用戶的角度上去思考問題，更多的學會換位思考；體驗測試如何要作 得更好。緩存
三、軟件在用戶那出現crash了。爲何在測試環境下沒有出現相同的crash呢？是用戶環境複雜，仍是開發人員在測試環境下系統根本就沒有接入crash上報模塊，即便軟件出現了crash也沒法得知。工具
四、用戶反饋改版後的系統和競爭對手的比差太大了，很垃圾。測試人員要反思的問題是：在測試的時候有沒有關注競爭對手的軟件，有沒有作競品分析，產品人員作的競品分析是否靠譜；有沒有關注競爭對手軟件的相關非功能性表現如何（性能，體驗，內容豐富度）深刻測試性能
第二：版本測試過程當中碰到了哪些問題。學習
因爲在測試時任務比較多，時間少，測試過程當中發現的問題只是記錄了bug，測試的知識點也是粗略的記錄，沒有造成系統的文檔。測試人員應該利用版本發佈後空出的相對充裕的時間來總結本身記錄的信息，造成文檔，而且分享出去。測試
一、測試過程當中碰到系統中所使用的新技術點本身不清楚的，須要在這時候進行學習總結。spa
二、測試環境是否準備充分？
三、測試時間估算是否準確，誤差有多大，爲何會出現這種緣由。
四、測試用例的粒度是否過粗仍是過細？
五、測試人員的配備是否合理？新老員工比例如何？
六、測試輔助工具的使用有碰到什麼問題？
七、在測試過程當中是否感受到重複的操做不少，是否考慮能夠自動化，自動化的成本如何衡量？
第三：版本測試發現的缺陷狀況如何。
缺陷記錄是測試人員的寶庫，可是不少測試人員甚至包括測試leader對缺陷記錄的利用一直停留在很初級的水平上，沒有進入深刻的挖掘，沒有能 夠總結出一套屬於本身組內的缺陷模式，致使每一個版本發佈時老是出現相同的缺陷，並且不一樣人接手不一樣項目的測試老是會犯一些之前犯過的錯誤。針對這種狀況， 測試人員是否要思考下有沒有什麼方法來改善，來充分的利用缺陷？
一、缺陷產生的緣由分析。缺陷找到後，須要弄清楚爲何這裏會出現問題，其它地方沒有問題。缺陷產生的根本緣由是開發人員的經驗欠缺呢？仍是系 統比較複雜，涉及到的交互和協議不少，單個開發人員不可能徹底掌握？仍是產品的需求定義不明確？甚者是開發人員的懶惰找出代碼對異常狀況的考慮不周？
二、缺陷是否可以歸爲一類，是否能夠抽象出共性的問題，好比缺陷生成的功能點、場景、業務，測試業界是否有相似的缺陷模式來定義，若是沒有的 話，咱們本身是否能夠明肯定義這類問題，而且分享給業界。這類缺陷是否在不一樣項目下出現過，且出現的頻率很高。測試人員對這類缺陷應該進行抽象和總結而且 分享給開發人員和管理層，減小他們再次產生同類缺陷的成本。
三、對於比較難重現的缺陷測試人員是否能夠經過編寫自動化工具來複現，創造特定的環境來使bug現身。
四、bug嚴重等級分佈。致命、嚴重、通常、建議類的bug分別如何，是否符合正態分佈。
五、缺陷密度如何。那些模塊比較容易產生bug；那些開發人員的bug數比較多，且bug嚴重等級高；那位產品提的需求不夠嚴謹，常常出現需求 變更致使bug，需求定義不許確致使bug；那類環境下出現的bug多（好比web的兼容性測試，是ie6環境下bug多呢？仍是firefox下等）。
第四：版本漏測緣由分析。
隨着計算機軟件的複雜度增長，系統內部各模塊之間的交互通訊、系統與系統之間的交互愈來愈複雜，可是開發人員的能力提高水平倒是比較緩慢的，而 且優秀的開發人員更加少，合格的開發人員也很少，致使編寫的代碼存在不少缺陷。咱們測試過的一個web系統，開發週期大概1多月，可是測試時間才2周，發 現了300多個bug。即便這樣發出去後仍是會出現一些漏測的狀況。針對這種狀況，咱們有什麼辦法來分析而且減小漏測呢？
一、測試用例覆蓋度如何？有沒有覆蓋到用戶經常使用的場景、操做習慣、用戶數據真實度模擬。
二、代碼覆蓋率有沒有至少作到行覆蓋，對於未覆蓋到的代碼有沒有進行風險評估。千萬不能認爲用戶的環境不會這麼特殊而放棄測試。咱們有一個版本 特性是測試軟件給用戶開闢一塊硬盤緩存的特性，開發想固然的直接劃分了1G的空間給到程序，沒有考慮到若是用戶的虛擬內存是分配在系統盤，且若是系統盤的 剩餘空間小於1G時程序會不會出現crash。測試人員在作代碼差別覆蓋時已經發現這個問題，可是在和開發確認後就輕易的放過去了。
三、測試人員的測試思惟是否狹窄，對被測系統的各個底層理解不夠深刻，所檢查的測試點都是比較簡單，致使系統會出現漏洞。好比在測試文件上傳功 能時，程序不容許上傳exe等可執行文件。若是隻是簡單的檢查是否文件名後綴，而且只是前端javascript來作檢查，後臺不作二次檢查的話，就很容 易被用戶使用fiddler等抓包調試工具輕鬆構造條件繞過。
四、測試人員的經驗是否不足，測試leader在人員安排方面是否有疏忽，沒有進行新老同事搭配，沒有對重要且風險高的功能安排資深的測試工程師輔助進行把關。
五、測試時間不夠，致使計劃測試的內容結果沒有測試到。針對這種狀況測試人員在版本發佈前是否有進行風險分析而且知會到相關的owner。