Time will tell.
之前一直在外包企業做電商的測驗，從接觸專案到結束專案，真心累，卻覺得自己成長了很多，初入測驗，都是在等著測驗組長或者經理安排需求點，然后自己在那吭哧吭哧的點點點，或者壓根沒有人安排活，只能自己硬著頭皮上，沒有前輩的腳印，自己就是先鋒，
作業
一直做黑盒測驗，從開始的手忙腳亂，到慢慢形成了自己的一套作業程式：專案接觸，需求搜集、分析，測驗計劃，方案撰寫制定，測驗用例框架搭建、用例撰寫、用例評審，用例執行以及完善訂正，bug追蹤、回歸，測驗報告提交，
一整套流程下來后，之后再接專案就不會那么慌亂了，心里有底了，以上是軟體測驗流程，專案接洽，報價、競標，做需求，設計資料庫，分配模塊進行分期開發，測驗介入測驗，代碼凍結，客戶驗收，專案上線，ab、性能、安全測驗，
這是整個專案的大流程，可能由于專案的類別，流程順序上可能有點不同，
在我的經歷中，最讓我糾結的是讓開發改bug、讓客戶砍需求、讓甲方驗貨、收錢；我亢奮的走入測驗行業，力求精益求精，但是經常聽到：差不多就行了，沒必要這么干 . . .
讓我一再地迷茫，我要不要堅持己見；或者我就不管了，反正你們覺得可以就行，然后把一個怪胎不負責的扔給他們，這就是你們要的，不能怪我嘍，哎，當時可是把我糾結死了，終究是too young啊！
來點分享
和客戶聊天永遠報喜不報憂，和開發溝通永遠不要針鋒相對，和老總喝茶一定廢話少說，以上廢話完了，來點水貨：
1、測驗作業切忌上手就開測，一定要好好的了解一下專案的背景，這樣你可以很好的掌控測驗的力度和大方向；
2、測驗計劃方案制定之前，最重要的是確定測驗范圍和標準以及問題確認的對接人，范圍邊界一定要非常非常的清楚，切忌模糊，否則后面等著吐血吧；
3、測驗計劃和方案制定的時候有必要和開發負責人、專案經理了解一下目前專案的專案計劃和真實進度，以此為依據制定一下測驗計劃；
4、盡力去了解整個系統，可能此時連UI頁面都沒有，你可以參考一下類似的系統或者網站，腦補一下系統整體流程以及相關系統之間的聯系互動；
5、第4點差不多了，就開始寫測驗用例框架，用例不用寫的很細，從整體梳理一下測驗思路，資料、業務規則、UI或者拆分模塊、或者先介面后功能再集成最后場景，隨機應變吧，骨架搭好了，就可以和需求一個字一個字的扣了，
6、此時應該是屬于需求再次確認的階段了，在寫用例的時候發現的需求疑問應該是最多的，要是維護一個需求確認清單，絕對會讓你事半功倍的；
7、測驗的一切作業的基礎不是需求檔案，而是你的測驗用例，所以一定要將需求和專案的一切變動都實時的更新轉化到你的測驗用例里面，后續可能會出現很多扯皮的事情，所以此時的測驗用例是你作業的底氣，你懂的；
8、測驗軟體程序中，忌諱一遇到問題就馬上找開發，測驗的作業時間是碎片化的，但是開發的作業時間一定不能是碎片的，否則開發會瘋的；對于何時去找開發處理問題，那要看你發現的問題屬于什么，如果是頁面樣式錯位了，手機號長度沒有限制這些，那就先緩緩吧，不急于一時的；如果是阻斷測驗流程了，給開發先發個資訊，說明問題修復的優先級，等5分鐘，喝口水，如果開發沒有及時回復，口頭溝通一下（讓盡快暫停手頭活，優先修復一下問題），這樣會好一些；
9、測驗初期是bug急劇增加的時期，測驗作業也是阻礙重重，不要抱怨，把問題好好整理一下，好多問題都是其中某一個引起的連鎖問題，一個解決，其他的都不存在了，所以嘗試去找到那個關鍵問題，讓開發干掉它；中期bug的增量和修復量就平穩了，也是最累的時候，一定要堅持住；后期的bug如果出現平穩下滑，那么恭喜你，測驗的質量不錯；如果急速下滑，要謹慎遺漏和修復引起的新問題；如果還在急劇增加，趕緊看看是需求變更了還是資料庫或者版本管理出現問題了，這種情況基本不用考慮準時上線了；
10、測驗結束，上線了，根據2/8原則，客觀分析系統質量，以及風險，待優化和注意的點，這樣在團隊下期專案開始后，會輕松很多的，其實此時是體現測驗最大價值的地方，但是絕大時候都沒人關注此時的軟體測驗報告（悲傷），
絮叨
以上就是今天跟大家的一點分享，希望看過本篇文章之后，讓正在做測驗和準備做測驗的小伙伴們對自己今后的作業方向有點了解，如果你喜歡軟體測驗這個行業的話，可以加入我們175317069一起學習，群有行業深潛多年的測驗人技術分析講解，最后祝愿你能成為一名優秀的軟體測驗工程師，
喜歡的話，歡迎【評論】、【點贊】、【關注】禮貌三連
Time will tell.（時間會證明一切）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/162326.html
標籤：其他