一、 測試周期
測試周期一般為兩周搭独，根據(jù)項目情況以及版本質(zhì)量可適當(dāng)縮短或延長測試時間婴削。正式測試前先向主管或產(chǎn)品經(jīng)理確認(rèn)項目排期。
二牙肝、測試資源
測試任務(wù)開始前唉俗，檢查各項測試資源。
產(chǎn)品功能需求文檔
產(chǎn)品原型圖
產(chǎn)品效果圖
行為統(tǒng)計分析定義文檔
測試設(shè)備（ios3.1.3-ios5.0.1配椭；Android1.6-Android4.0虫溜；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）
其他（例如有秒殺專題的項目股缸，需要規(guī)劃秒殺時間表吼渡；有優(yōu)惠券使用的項目，需要申請?zhí)砑觾?yōu)惠券數(shù)據(jù)乓序；支付寶/銀聯(lián)支付功能的項目寺酪，需要提前申請支付寶/銀聯(lián)賬戶等等）
二坎背、測試要點
接收版本
本人覺得，這個過程可以直接略過寄雀。非專業(yè)測試著得滤，不喜勿拍。
UI測試
A）? 確保手頭的原型圖與效果圖為當(dāng)前最新版本盒犹。
B）? 確保產(chǎn)品UI符合產(chǎn)品經(jīng)理制定的原型圖與效果圖懂更。
C）? 一切界面問題以效果圖為準(zhǔn)，若有用戶體驗方面的建議急膀，必須先以郵件或口頭的形式詢問產(chǎn)品經(jīng)理沮协。
D）由于測試環(huán)境中的數(shù)據(jù)為模擬數(shù)據(jù)，測試時必須預(yù)先考慮到正式環(huán)境中可能出現(xiàn)的數(shù)據(jù)類型卓嫂。
功能測試
A）? 確保手頭的功能需求文檔為當(dāng)前最新版本慷暂。
B）? 確保所有的軟件功能都已實現(xiàn)且邏輯正常。
C）? 一切功能問題以需求文檔為準(zhǔn)晨雳，若有用戶體驗方面的建議行瑞，必須先以郵件或口頭的形式詢問產(chǎn)品經(jīng)理。個人建議餐禁，用戶體驗方面的建議血久，優(yōu)先級放在修復(fù)bug之后。
D）若有些功能在技術(shù)上難以實現(xiàn)或者由于排期的原因無法在短時間內(nèi)實現(xiàn)帮非，必須得到產(chǎn)品經(jīng)理的確認(rèn)氧吐，而不是單單只聽開發(fā)人員的技術(shù)解釋。此處確認(rèn)最好以郵件形式存在末盔。
E）所有的“外部原因”問題筑舅，都需要盡早地督促開發(fā)人員與客戶服務(wù)端人員聯(lián)系協(xié)調(diào)解決。并在之后的測試報告中予以體現(xiàn)庄岖。
F）所有的“設(shè)計如此”豁翎、“延期處理”問題，都需要和產(chǎn)品經(jīng)理確認(rèn)后再進(jìn)行驗證隅忿。并在之后的測試報告中予以體現(xiàn)心剥。
G）測試下單時，注冊的測試賬號必須符合公司規(guī)范背桐；收貨地址必須包含“測試”關(guān)鍵字优烧，最好每次下單的名稱中含有日期，以便查詢链峭；在正式環(huán)境中下單后必須取消該訂單等畦娄。
兼容測試/性能測試
A）? 確保軟件在所有兼容機型上都能正常使用（ios一般需要兼容7或者6, ?ios5可以不用考慮，用戶使用率已經(jīng)低于5%以下）
B）? 對于低端性能兼容機上獨有的問題（例如ios5以下、Android1.6以下）熙卡，若在技術(shù)上難以修改或者由于排期的原因無法在短時間內(nèi)改進(jìn)杖刷，必須在測試日報中注明，并得到技術(shù)平臺主管驳癌、產(chǎn)品經(jīng)理以及運營人員的確認(rèn)滑燃，最好以郵件的形式得到確認(rèn)）
C）? 性能測試方面必須滿足硬件壓力條件下的測試需要（例如多線程，用戶常用的app都要后臺運行的環(huán)境中測試颓鲜。）
D）網(wǎng)絡(luò)響應(yīng)用戶體驗方面的性能測試表窘，需要保證在wifi、3g甜滨、2g網(wǎng)絡(luò)下的切換效果乐严。比如wifi切換到2g，網(wǎng)絡(luò)響應(yīng)的速度以及切換界面衣摩。
后臺訂單統(tǒng)計測試
A）? 核對“客戶端相關(guān)啟動查詢”項昂验，此項數(shù)據(jù)就是經(jīng)常說的“激活量”，非常重要昭娩。測試時必須保證該項中的各數(shù)據(jù)均正確凛篙，且每次啟動軟件都會有相應(yīng)的統(tǒng)計記錄黍匾。
B）? 核對“訂單查詢”項栏渺，測試時必須保證各數(shù)據(jù)均正確，且每次成功下單后都會有相應(yīng)的統(tǒng)計記錄锐涯。
C）? 需要注意的是磕诊，在成功下單之后，后臺會做判斷將該訂單劃到測試訂單范圍纹腌，測試人員必須到“訂單查詢（測試）”模塊中核對訂單統(tǒng)計記錄信息霎终。
用戶行為統(tǒng)計測試
A）確保手頭的行為統(tǒng)計分析定義文檔為最新版本，且與開發(fā)人員手中的文檔一致升薯。
B）確保產(chǎn)品經(jīng)理在文檔中所定義的頁面在該產(chǎn)品中都是存在的莱褒。
C）盡可能真實地模擬用戶行為。
D）核對統(tǒng)計日志涎劈，確保各項操作所對應(yīng)的頁面ID以及操作ID都是正確的广凸。
回歸測試
A）軟件最終上線前，需對產(chǎn)品進(jìn)行回歸測試蛛枚，測試內(nèi)容包含之前所有的測試項目
B）回歸測試不再對細(xì)節(jié)進(jìn)行測試谅海，而是類似于對產(chǎn)品進(jìn)行驗收，從客戶正常使用的角度對產(chǎn)品進(jìn)行再一輪的整體測試蹦浦。
C）只有在回歸測試通過之后扭吁，才對產(chǎn)品進(jìn)行提交。
三、測試日報及產(chǎn)品上線報告
測試人員每天需對所測項目發(fā)送測試日報侥袜。
測試日報所包含的內(nèi)容為：
A）對當(dāng)前測試版本質(zhì)量進(jìn)行分級蝌诡。
B）對較嚴(yán)重的問題進(jìn)行例舉，提示開發(fā)人員優(yōu)先修改枫吧。
C）對版本的整體情況進(jìn)行評估送漠。
產(chǎn)品上線前，測試人員發(fā)送產(chǎn)品上線報告
