其實有時候自己會思考，假如有一天需要自己負責一個新的apk，整個測試組只有我一個人，那麼我會怎麼辦。

這個問題也是挺有意思的，之所以會思考寫出來，是因為我知道如果面對這個問題，我一定會手足無措的，所以先來玩玩 :)

整個立項到釋出的整體流程以後再寫吧，這裡從開發的預研開始。

其實我還是建議測試瞭解開發邏輯是從有一個成品的apk開始，因為如果從預研就去深入的話，中間變動太大，前期app還沒開發出來測試應該思考針對這一類的app(某類的應用其實介面元素都是蠻像的)怎麼做效能和自動化測試，比如需要什麼效能指標，自動化框架哪個適合並深入研究，針對開發預研的大體方向學習一下應用的技術，例如我們大家都在用的微信，前期可以思考到的效能指標為，耗電，CPU，記憶體，如果保證訊息的時效性，避免後臺被殺的方案，自動化是以介面為主，所以主流的框架都可以用，當然騰訊自己肯定有自己的框架的。

前期就這麼友好地度過了，接下來就是常規測試，測試方法前面文章已經說過了，看個人吧，我的方法並不一定適合所有人了。第一個版本釋出藥做好相容性和跟蹤外網問題，基本就差不多了。
其實重點還是專案的持續性迭代，包括我以及大多數產品都是在這個階段的吧，我認為這個階段就是這幾個部分組成的：
1.新功能模組的功能測試
2.測試用例的編寫
3.自動化用例編寫和完善
4.重要模組的效能(我認為這不應該單獨列出來了，因為平時測試功能模組的時候也要關注一下自己模組的記憶體時延，單獨拿出來讓一個人測試那個人也沒有比測的人瞭解邏輯)
5.週期釋出前的全面功能測試和安裝覆蓋安裝
6.迴歸BUG
7.想到再新增上去吧 @

[email protected]
要做的其實也就這麼多吧，等等，時間好像沒加上，於是列個excel表格出來看下(僅供參考，如有雷同，你抄我的吧 ->.->)

階段	時間	優先順序	說明
新功能	馬上	最高
測試用例完善	新功能測試完成，開發在修改BUG的過程中	中	也可以邊測試邊完善，看時間和人員充裕情況，但是測試前必須擬定測試點
迴歸BUG	間歇性，一般改好有時間就驗證，這個不怎麼費時	中	這個只要描述清楚，也可以給非負責這個模組的人迴歸，因為不涉及太多邏輯，不過可能會迴歸發現新的邏輯性BUG
自動化用例	有時間再弄	低	前期只需要大體的框架自動化，專案穩定再實現小細節，省時
效能	有時間再弄	低	非新手還是把效能柔和在普通測試中吧，因為更具有針對性
全面功能測試	釋出前N天	高	N自己定，但是最少也要預留3天吧，畢竟開發也要改BUG了，理論當然越多天越好
新安裝/覆蓋安裝	釋出前	中高	基本沒問題
測試的學習提高	any time	高	嘿嘿，個人技術的提高是必要的，因為自動化和效能沒必要每個版本都測試對吧，專案穩定後空閒時間還不少的，一個公司的好壞在於流程的規範，意味這任務完成有更多的時間給你提高，給你學習，bat都看中個人技術啦

最後，專案的持續性迭代過程中，可以考慮持續繼承，比如在jenkins中每日執行monkey穩定性指令碼，git程式碼發生變化的時候自動構建apk並執行靜態程式碼掃描，針對常用模組完成UI自動化編寫，定時跑跑，最後，介面測試沒幾個小時跑一遍

好了，寫了這麼多，最後總結一下

如果一個人開始負責一個新專案：
1.前期確定產品特性，規劃大概一個測試方案
2.持續迭代過程中，根據時間規劃新功能測試和用例編寫，剩餘時間技術性的自動話，效能和學習提高

如果又來了一個測試，那就合理分配測試任務，不過要考慮關聯模組分配(再來多幾個人是不是就變成小組了呢，呵呵)

3.持續性方案的繼承，首選當然kenkins啦

還有一個矛盾的地方，有時候測一個功能，明明測試完了，不自信，或者別人突然幫你找出了一個bug，你就一直在那裡持續性地測試，沒完沒了，加班加點，領導表揚...然後自己的提高時間也沒有，但是在領導面前確實很忙很忙，囧...所以還是應該有規劃，有目的測試，累了就玩玩找bug，這樣才像話嘛。