論一個真正的軟體測試工程師

01

半個產品 半個開發

      有人覺得這個標題有點諷刺，真正的測試。，難道我們不是真正的測試，平常做的都不是測試的工作嗎。其實不肯定也不否定，但這是一個內含項目關聯性，如果只是評審+用例編寫執行，那麼確實不是一個真正的測試。 
　　正如標題那樣，我認為真正的測試 =“半個產品+半個開發”。 

　　半個產品，主要體現在理解這個需求為什麼要做。其核心價值在哪裡。吸引使用者的特點是什麼。意味著在評審階段，你除了協助完善功能需求外，更重要的是理解這個需求對於使用者有什麼價值，你是使用者你會怎麼想有什麼感受,不能簡單的走完流程就可以了，比如一個播放視頻類應用， 多樣性 流暢度 簡易性 快速性等 這是在評審之後可以總結出來的，那麼抱著這個價值點，圍繞這我們的整個測試流程，往往能夠發現不一樣的地方。比如還是播放類應用，在我瞭解個特性後，在測試過程中我會更加留意播放方面的效能，以及相容性，在我設計測試方案的時候就會標明這幾個測試重點，以便我自己或者組員能夠在測試過程中多加留意這部分的測試點，然後在設計測試案例的時候會提高優先順序和覆蓋率。可以發現，測試有了測重點。 

　　半個開發，其實個人認為這是偏向於灰盒測試了，體現在一個需求，你除了要明確這個需求的商務邏輯，其代碼邏輯(資料流邏輯)也是需要知道的，從後台擷取的json資料結構到用戶端展示再到儲存至本機資料，這一個流向，都是需要去瞭解並測試的(這部分參照之前寫的測試分析文章)，所以測實驗證的不僅僅是功能層面的東西，還是內部的具體實現(當然，具體到類方法的測試那是測試開發的職能，不關咱測試的事)，我們要保證的，就是這一階段資料的正確性和容錯性。這樣做的好處是，能從內部發現缺陷，在出現問題的時候可以大概定位到問題出在哪，在出問題面對boss的質疑能夠把責任丟給開發，哦不，是更好的解決問題。 

　　那麼半個開發還體現在對工具效率的提升上，能夠通過小指令碼，小架構去提升測試效率，這要求對於基本的語言要求是必須的，大公司面試的某一輪考研的就是你的代碼能力，所以測試還是半個開發這一點是毋庸置疑滴。

02

職能範圍

●評審

●測試方案的確立

●用例的編寫維護

●技術點的分享

●BUG提交和總結

●輸出測試報告

●整合測試

●發布版本

●論壇/其他渠道收集反饋

●伺服器效能測試

●APP效能測試

●網頁前端效能

●編寫自動化指令碼

●(暫時想到這麼多，嘿)

01

日常的工作流程

       至少是我，在剛接觸測試的時候，除了完成領導的任務(主要是看需求，寫用例，執行並迴歸)外，沒有什麼事情可做，現在回想起來，其實能做事情還有很多，只是沒被安排(咳咳，我可不是說我第一份工作的領導不好)，好其實是沒有意識去提高而已。 
　　其實就現在而言，我目前的工作流程是這樣的(當然是以一個版本迭代為周期):

評審新需求，記錄關鍵點–>編寫測試點(用例)–>測試之前向開發瞭解部分實現–>執行測試(翻閱代碼，查看主邏輯走向<可選>)–>提交BUG–>迴歸BUG(查看BUG代碼改動)–>新需求的效能評估(可選)–>發布前的系統測試(結合自動化)–>發布–>自動化用例的補充(可選)–>商務邏輯總結歸總–>休息

　那麼基本流程就是這樣了，那麼可以看到一隔項目組的正真的測試人員，是要完成這麼多工作的，所以這也是用來區分手工的外包人員和正式員工的區別，外包怎麼樣，大家都知道。

補充： 
竊取某個大神的關於時間安排 
時間 工作內容 
30% 評審用例維護等準備以及後期工作 
20% 執行測試案例，BUG迴歸 
50% 自動化 && 新技術學習，引入 !