01

半個產(chǎn)品 半個開發(fā)

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

正如標(biāo)題那樣，我認(rèn)為真正的測試 =“半個產(chǎn)品+半個開發(fā)”。

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

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

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

02

職能范圍

●評審

●測試方案的確立

●用例的編寫維護(hù)

●技術(shù)點的分享

●BUG提交和總結(jié)

●輸出測試報告

●集成測試

●發(fā)布版本

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

●服務(wù)器性能測試

●APP性能測試

●網(wǎng)頁前端性能

●編寫自動化腳本

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

01

日常的工作流程

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

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

評審新需求，記錄關(guān)鍵點–》編寫測試點（用例）–》測試之前向開發(fā)了解部分實現(xiàn)–》執(zhí)行測試（翻閱代碼，查看主邏輯走向《可選》）–》提交BUG–》回歸BUG（查看BUG代碼改動）–》新需求的性能評估（可選）–》發(fā)布前的系統(tǒng)測試（結(jié)合自動化）–》發(fā)布–》自動化用例的補(bǔ)充（可選）–》業(yè)務(wù)邏輯總結(jié)歸總–》休息

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