01

半個產品 半個開發

有人覺得這個標題有點諷刺，真正的測試？，難道我們不是真正的測試，平常做的都不是測試的工作嗎？其實不肯定也不否定，但這是一個包含關系，如果只是評審+用例編寫執行，那么確實不是一個真正的測試。

正如標題那樣，我認為真正的測試 =“半個產品+半個開發”。

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

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

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

02

職能范圍

●評審

●測試方案的確立

●用例的編寫維護

●技術點的分享

●BUG提交和總結

●輸出測試報告

●集成測試

●發布版本

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

●服務器性能測試

●APP性能測試

●網頁前端性能

●編寫自動化腳本

●（暫時想到這么多，嘿）

01

日常的工作流程

至少是我，在剛接觸測試的時候，除了完成領導的任務（主要是看需求，寫用例，執行并回歸）外，沒有什么事情可做，現在回想起來，其實能做事情還有很多，只是沒被安排（咳咳，我可不是說我第一份工作的領導不好），好其實是沒有意識去提高而已。

其實就現在而言，我目前的工作流程是這樣的（當然是以一個版本迭代為周期）：

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

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