測試周期

測試周期一般為2~3天，根據(jù)項(xiàng)目情況以及版本質(zhì)量可適當(dāng)縮短或延長測試時間。正式測試前先向主管或產(chǎn)品經(jīng)理確認(rèn)項(xiàng)目排期。

測試資源

測試任務(wù)開始前，檢查各項(xiàng)測試資源。

1. 產(chǎn)品功能需求文檔、概要設(shè)計(jì)文檔（包含非本期開發(fā)的產(chǎn)品功能部分）
2. 產(chǎn)品原型圖（包含非本期開發(fā)的產(chǎn)品功能部分）
3. 產(chǎn)品效果圖（包含非本期開發(fā)的產(chǎn)品功能部分）
4. 測試用例（包含非本期開發(fā)的產(chǎn)品功能部分）
5. 行為統(tǒng)計(jì)分析定義文檔
6. 測試設(shè)備（ios7-ios8；Android2.3-Android4.4, 也可兼容到5.0）
7. 其他（例如有限時搶購類的項(xiàng)目，需要規(guī)劃時間表；有優(yōu)惠券使用的項(xiàng)目，需要申請?zhí)砑觾?yōu)惠券數(shù)據(jù)；支付寶/銀聯(lián)支付功能的項(xiàng)目，需要提前申請支付寶/銀聯(lián)賬戶等等）

測試要點(diǎn)

1. 接收版本
   1. 個人認(rèn)為，我們目前的團(tuán)隊(duì)可以略過，但需要在svn上創(chuàng)建分支，稱為“測試版本分支”，在發(fā)布后，代碼進(jìn)行封存。
   2. 在測試之前，需要向主管、產(chǎn)品經(jīng)理確認(rèn)當(dāng)前測試版本的版本號與版本名
   3. 要區(qū)別對待本期開發(fā)的功能與已發(fā)布的功能
2. UI測試
   1. 確保手頭的原型圖與效果圖為當(dāng)前最新版本。
   2. 確保產(chǎn)品UI符合產(chǎn)品經(jīng)理制定的原型圖與效果圖。
   3. 一切界面問題以效果圖為準(zhǔn)，若有用戶體驗(yàn)方面的建議，必須先以郵件或口頭的形式詢問產(chǎn)品經(jīng)理。
   4. 由于測試環(huán)境中的數(shù)據(jù)為模擬數(shù)據(jù)，測試時必須預(yù)先考慮到正式環(huán)境中可能出現(xiàn)的數(shù)據(jù)類型。
3. 功能測試
   1. 確保手頭的功能需求文檔為當(dāng)前最新版本。
   2. 確保所有的軟件功能都已實(shí)現(xiàn)且邏輯正常。
   3. 一切功能問題以需求文檔為準(zhǔn)，若有用戶體驗(yàn)方面的建議，必須先以郵件或口頭的形式詢問產(chǎn)品經(jīng)理。個人建議，用戶體驗(yàn)方面的建議，優(yōu)先級放在修復(fù)bug之后。
   4. 若有些功能在技術(shù)上難以實(shí)現(xiàn)或者由于排期的原因無法在短時間內(nèi)實(shí)現(xiàn)，必須得到產(chǎn)品經(jīng)理的確認(rèn)，而不是單單只聽開發(fā)人員的技術(shù)解釋。此處確認(rèn)最好以郵件形式存在。
   5. 所有的“外部原因”問題，都需要盡早地督促開發(fā)人員與客戶服務(wù)端人員聯(lián)系協(xié)調(diào)解決。并在之后的測試報(bào)告中予以體現(xiàn)。
   6. 所有的“設(shè)計(jì)如此”、“延期處理”問題，都需要和產(chǎn)品經(jīng)理確認(rèn)后再進(jìn)行驗(yàn)證。并在之后的測試報(bào)告中予以體現(xiàn)。
   7. 測試下單時，注冊的測試賬號必須符合公司規(guī)范；收貨地址必須包含“測試”關(guān)鍵字，最好每次下單的名稱中含有日期，以便查詢；在正式環(huán)境中下單后必須取消該訂單等。
4. 兼容測試/性能測試
   1. 確保軟件在所有兼容機(jī)型上都能正常使用（ios一般需要兼容到6, ios5可以不用考慮，用戶使用率已經(jīng)低于5%以下）
   2. 性能測試方面必須滿足硬件壓力條件下的測試需要（例如多線程，用戶常用的app都要后臺運(yùn)行的環(huán)境中測試。）
   3. 網(wǎng)絡(luò)響應(yīng)用戶體驗(yàn)方面的性能測試，需要保證在wifi、3g、2g網(wǎng)絡(luò)下的切換效果。比如wifi切換到2g，網(wǎng)絡(luò)響應(yīng)的速度以及切換界面。
5. 后臺訂單統(tǒng)計(jì)測試
   1. 核對“客戶端相關(guān)啟動查詢”項(xiàng)，此項(xiàng)數(shù)據(jù)就是經(jīng)常說的“激活量”，非常重要。測試時必須保證該項(xiàng)中的各數(shù)據(jù)均正確，且每次啟動軟件都會有相應(yīng)的統(tǒng)計(jì)記錄。
   2. 核對“訂單查詢”項(xiàng)，測試時必須保證各數(shù)據(jù)均正確，且每次成功下單后都會有相應(yīng)的統(tǒng)計(jì)記錄。
   3. 需要注意的是，在成功下單之后，后臺會做判斷將該訂單劃到測試訂單范圍，測試人員必須到“訂單查詢（測試）”模塊中核對訂單統(tǒng)計(jì)記錄信息。
6. 用戶行為統(tǒng)計(jì)測試（這個暫時略過不提）
   1. 確保手頭的行為統(tǒng)計(jì)分析定義文檔為最新版本，且與開發(fā)人員手中的文檔一致。
   2. 確保產(chǎn)品經(jīng)理在文檔中所定義的頁面在該產(chǎn)品中都是存在的。
   3. 盡可能真實(shí)地模擬用戶行為。
   4. 核對統(tǒng)計(jì)日志，確保各項(xiàng)操作所對應(yīng)的頁面ID以及操作ID都是正確的。
7. 回歸測試
   1. 軟件最終上線前，需對產(chǎn)品進(jìn)行回歸測試，測試內(nèi)容包含之前所有的測試項(xiàng)目
   2. 回歸測試不再對細(xì)節(jié)進(jìn)行測試，而是類似于對產(chǎn)品進(jìn)行驗(yàn)收，從客戶正常使用的角度對產(chǎn)品進(jìn)行再一輪的整體測試。
   3. 只有在回歸測試通過之后，才對產(chǎn)品進(jìn)行提交。

bug修復(fù)

1. 測試人員提交測試日報(bào)，到主管、產(chǎn)品經(jīng)理
2. 主管與開發(fā)人員確認(rèn)bug
3. 主管與產(chǎn)品經(jīng)理協(xié)調(diào)修復(fù)方案（有文檔記錄）
4. 主管安排開發(fā)人員在測試版本分支上修復(fù) bug （有文檔記錄）
5. 開發(fā)人員修復(fù)完成后，通知測試人員已修復(fù)相關(guān)問題

測試日報(bào)及產(chǎn)品上線報(bào)告

1. 測試人員每天需對所測項(xiàng)目發(fā)送測試日報(bào)。
2. 測試日報(bào)所包含的內(nèi)容為：
   1. 對當(dāng)前測試版本質(zhì)量進(jìn)行分級。
   2. 對較嚴(yán)重的問題進(jìn)行例舉，提示開發(fā)人員優(yōu)先修改。
   3. 對版本的整體情況進(jìn)行評估。
   4. 對版本測試過程中修改的內(nèi)容進(jìn)行記錄。
3. 產(chǎn)品上線前，測試人員發(fā)送產(chǎn)品上線報(bào)告（記錄產(chǎn)品測試記錄、修復(fù)情況、最終部分）

測試版本分支與主線版本的合并

由于測試版本分支的上修改的某些代碼只是為了暫時性的修復(fù)某些問題，隨著我們代碼量的增大，也許有時候不太會適合提交到主線版本。

1. 開發(fā)人員、主管、產(chǎn)品經(jīng)理集體確認(rèn)需要把什么代碼合并到開發(fā)主線

作者：人呆木水

來源：簡書

原文地址：http://www.jianshu.com/p/c58e10d5f35f