摘自http://blog.csdn.net/xia_xia0919/article/details/50600374
我在這里討論的方法主要是針對互聯(lián)網企業(yè)的測試猜扮，可能對傳統(tǒng)企業(yè)的測試來說會有點不同猎贴，但是大體上是適用所有公司的測試情況的奢赂。
版本發(fā)布后大部分測試人員的意識里面都會認為該要好好休息一下了，放幾天羊话浇，做做其它和已發(fā)布版本沒有相關的事情赖草。其實版本發(fā)布后測試人員還有很多事情
需要去處理午乓，需要去總結、歸類滋迈、反思霎奢、分享。我這里主要探討幾個問題：版本發(fā)布后用戶反饋如何饼灿；版本測試過程中碰到了那些問題幕侠；版本測試發(fā)現的缺陷情況如
何；測試過程中有沒有漏測碍彭；
第一：版本發(fā)布后用戶反饋如何橙依。
一般的系統(tǒng)需要都需
要提供一個用戶反饋入口給到用戶，這個功能在互聯(lián)網企業(yè)基本上都會有硕旗，當用戶在使用過程中發(fā)現問題時用戶會提交問題到公司的support系統(tǒng)，客服人員
會跟蹤用戶反饋的問題女责。而且客服人員會定期推送系統(tǒng)的質量報告給到相關人員漆枚。那么除了客服人員跟蹤用戶反饋之外，測試人員要怎么對待用戶反饋呢抵知？
1墙基、用戶反饋的問題是不是一個bug？如果是的話就要分析為什么在測試環(huán)境下沒有發(fā)現刷喜，而到了用戶那邊就出現了：是我們的測試場景覆蓋不夠嗎残制；是用戶的環(huán)境太復雜了，和測試環(huán)境有多大的區(qū)別掖疮；還是測試人員偷懶初茶、過于自信輕松放過了bug；
2浊闪、用戶反饋的是以前系統(tǒng)有的功能現在沒有了恼布，操作習慣改變很大螺戳。那測試人員就要反思，為什么我測試的時候覺得系統(tǒng)操作起來很方便折汞，而且操作習慣改變也
不大倔幼。是不是測試人員的思維習慣和用戶差距很大，文化差異也大爽待；那測試人員要總結如何站在用戶的角度上去思考問題损同，更多的學會換位思考；體驗測試如何要做
得更好鸟款。
3膏燃、軟件在用戶那出現crash了。為什么在測試環(huán)境下沒有出現相同的crash呢欠雌？是用戶環(huán)境復雜蹄梢，還是開發(fā)人員在測試環(huán)境下系統(tǒng)根本就沒有接入crash上報模塊，即使軟件出現了crash也無法得知富俄。
4禁炒、用戶反饋改版后的系統(tǒng)和競爭對手的比差太大了，很垃圾霍比。測試人員要反思的問題是：在測試的時候有沒有關注競爭對手的軟件幕袱，有沒有做競品分析，產品人員做的競品分析是否靠譜悠瞬；有沒有關注競爭對手軟件的相關非功能性表現如何（性能们豌，體驗，內容豐富度）浅妆。深入測試
第二：版本測試過程中碰到了哪些問題望迎。
由于在測試時任務比較多，時間少凌外，測試過程中發(fā)現的問題只是記錄了bug辩尊，測試的知識點也是粗略的記錄，沒有形成系統(tǒng)的文檔康辑。測試人員應該利用版本發(fā)布后空出的相對充裕的時間來總結自己記錄的信息摄欲，形成文檔，并且分享出去疮薇。
1胸墙、測試過程中碰到系統(tǒng)中所使用的新技術點自己不清楚的，需要在這時候進行學習總結按咒。
2迟隅、測試環(huán)境是否準備充分？
3、測試時間估算是否準確玻淑，偏差有多大嗽冒，為什么會出現這種原因。
4补履、測試用例的粒度是否過粗還是過細添坊？
5、測試人員的配備是否合理箫锤？新老員工比例如何贬蛙？
6、測試輔助工具的使用有碰到什么問題谚攒？
7阳准、在測試過程中是否感覺到重復的操作很多，是否考慮可以自動化馏臭，自動化的成本如何衡量野蝇？
第三：版本測試發(fā)現的缺陷情況如何。
缺陷記錄是測試人員的寶庫括儒，但是很多測試人員甚至包括測試leader對缺陷記錄的利用一直停留在很初級的水平上绕沈，沒有進入深入的挖掘，沒有能
夠總結出一套屬于自己組內的缺陷模式帮寻，導致每個版本發(fā)布時總是出現相同的缺陷乍狐，而且不同人接手不同項目的測試總是會犯一些以前犯過的錯誤。針對這種情況固逗，
測試人員是否要思考下有沒有什么方法來改善浅蚪，來充分的利用缺陷？
1烫罩、缺陷產生的原因分析惜傲。缺陷找到后，需要弄清楚為什么這里會出現問題贝攒，其它地方沒有問題操漠。缺陷產生的根本原因是開發(fā)人員的經驗欠缺呢？還是系
統(tǒng)比較復雜饿这，涉及到的交互和協(xié)議很多，單個開發(fā)人員不可能完全掌握撞秋？還是產品的需求定義不明確长捧？甚者是開發(fā)人員的懶惰找出代碼對異常情況的考慮不周？
2吻贿、缺陷是否能夠歸為一類串结，是否可以抽象出共性的問題，比如缺陷生成的功能點、場景肌割、業(yè)務卧蜓，測試業(yè)界是否有類似的缺陷模式來定義，如果沒有的
話把敞，我們自己是否可以明確定義這類問題弥奸，并且分享給業(yè)界。這類缺陷是否在不同項目下出現過奋早，且出現的頻率很高盛霎。測試人員對這類缺陷應該進行抽象和總結并且
分享給開發(fā)人員和管理層，減少他們再次產生同類缺陷的成本耽装。
3愤炸、對于比較難重現的缺陷測試人員是否可以通過編寫自動化工具來復現，創(chuàng)造特定的環(huán)境來使bug現身掉奄。
4规个、bug嚴重等級分布。致命姓建、嚴重诞仓、一般、建議類的bug分別如何引瀑，是否符合正態(tài)分布狂芋。
5、缺陷密度如何憨栽。那些模塊比較容易產生bug帜矾；那些開發(fā)人員的bug數比較多，且bug嚴重等級高屑柔；那位產品提的需求不夠嚴謹屡萤，經常出現需求
變動導致bug，需求定義不準確導致bug掸宛；那類環(huán)境下出現的bug多（比如web的兼容性測試死陆，是ie6環(huán)境下bug多呢？還是firefox下等）唧瘾。
第四：版本漏測原因分析措译。
隨著計算機軟件的復雜度增加，系統(tǒng)內部各模塊之間的交互通信饰序、系統(tǒng)與系統(tǒng)之間的交互越來越復雜领虹，但是開發(fā)人員的能力提升水平卻是比較緩慢的，而
且優(yōu)秀的開發(fā)人員更加少求豫，合格的開發(fā)人員也不多塌衰，導致編寫的代碼存在很多缺陷诉稍。我們測試過的一個web系統(tǒng)，開發(fā)周期大概1多月最疆，但是測試時間才2周杯巨，發(fā)
現了300多個bug。即使這樣發(fā)出去后還是會出現一些漏測的情況努酸。針對這種情況服爷，我們有什么辦法來分析并且減少漏測呢？
1蚊逢、測試用例覆蓋度如何层扶？有沒有覆蓋到用戶常用的場景、操作習慣烙荷、用戶數據真實度模擬镜会。
2、代碼覆蓋率有沒有至少做到行覆蓋终抽，對于未覆蓋到的代碼有沒有進行風險評估添祸。千萬不能認為用戶的環(huán)境不會這么特殊而放棄測試著隆。我們有一個版本
特性是測試軟件給用戶開辟一塊硬盤緩存的特性具壮，開發(fā)想當然的直接劃分了1G的空間給到程序溯壶，沒有考慮到如果用戶的虛擬內存是分配在系統(tǒng)盤，且如果系統(tǒng)盤的
剩余空間小于1G時程序會不會出現crash圃郊。測試人員在做代碼差異覆蓋時已經發(fā)現這個問題价涝，但是在和開發(fā)確認后就輕易的放過去了。
3持舆、測試人員的測試思維是否狹窄色瘩，對被測系統(tǒng)的各個底層理解不夠深入，所檢查的測試點都是比較簡單逸寓，導致系統(tǒng)會出現漏洞居兆。比如在測試文件上傳功
能時，程序不允許上傳exe等可執(zhí)行文件竹伸。如果只是簡單的檢查是否文件名后綴泥栖，并且只是前端javascript來做檢查，后臺不做二次檢查的話勋篓，就很容
易被用戶使用fiddler等抓包調試工具輕松構造條件繞過吧享。
4、測試人員的經驗是否不足譬嚣，測試leader在人員安排方面是否有疏忽耙蔑，沒有進行新老同事搭配，沒有對重要且風險高的功能安排資深的測試工程師輔助進行把關孤荣。
5甸陌、測試時間不夠，導致計劃測試的內容結果沒有測試到盐股。針對這種情況測試人員在版本發(fā)布前是否有進行風險分析并且知會到相關的owner钱豁。
