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

• 產(chǎn)品功能需求文檔

• 產(chǎn)品原型圖

• 產(chǎn)品效果圖

• 行為統(tǒng)計分析定義文檔

• 測試設備（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è)測試著,，不喜勿拍,。

D）由于測試環(huán)境中的數(shù)據(jù)為模擬數(shù)據(jù),，測試時必須預先考慮到正式環(huán)境中可能出現(xiàn)的數(shù)據(jù)類型。

C）一切功能問題以需求文檔為準，若有用戶體驗方面的建議,，必須先以郵件或口頭的形式詢問產(chǎn)品經(jīng)理,。個人建議，用戶體驗方面的建議,，優(yōu)先級放在修復bug之后,。

D）若有些功能在技術上難以實現(xiàn)或者由于排期的原因無法在短時間內(nèi)實現(xiàn)，必須得到產(chǎn)品經(jīng)理的確認,，而不是單單只聽開發(fā)人員的技術解釋,。此處確認最好以郵件形式存在。

E）所有的“外部原因”問題,，都需要盡早地督促開發(fā)人員與客戶服務端人員聯(lián)系協(xié)調(diào)解決,。并在之后的測試報告中予以體現(xiàn)。

F）所有的“設計如此”,、“延期處理”問題,，都需要和產(chǎn)品經(jīng)理確認后再進行驗證。并在之后的測試報告中予以體現(xiàn)。

G）測試下單時,，注冊的測試賬號必須符合公司規(guī)范,；收貨地址必須包含“測試”關鍵字，最好每次下單的名稱中含有日期,，以便查詢,；在正式環(huán)境中下單后必須取消該訂單等。

A）確保軟件在所有兼容機型上都能正常使用（ios一般需要兼容7或者6,ios5可以不用考慮,，用戶使用率已經(jīng)低于5%以下）

B）對于低端性能兼容機上獨有的問題（例如ios5以下,、Android1.6以下），若在技術上難以修改或者由于排期的原因無法在短時間內(nèi)改進,，必須在測試日報中注明,，并得到技術平臺主管、產(chǎn)品經(jīng)理以及運營人員的確認,，最好以郵件的形式得到確認）

C）性能測試方面必須滿足硬件壓力條件下的測試需要（例如多線程,，用戶常用的app都要后臺運行的環(huán)境中測試。）

后臺訂單統(tǒng)計測試

A）核對“客戶端相關啟動查詢”項,，此項數(shù)據(jù)就是經(jīng)常說的“激活量”,，非常重要。測試時必須保證該項中的各數(shù)據(jù)均正確,，且每次啟動軟件都會有相應的統(tǒng)計記錄,。

B）核對“訂單查詢”項,，測試時必須保證各數(shù)據(jù)均正確,，且每次成功下單后都會有相應的統(tǒng)計記錄。

C）需要注意的是,，在成功下單之后,，后臺會做判斷將該訂單劃到測試訂單范圍，測試人員必須到“訂單查詢（測試）”模塊中核對訂單統(tǒng)計記錄信息,。

D）核對統(tǒng)計日志，確保各項操作所對應的頁面ID以及操作ID都是正確的。

C）只有在回歸測試通過之后，才對產(chǎn)品進行提交,。

產(chǎn)品上線前,，測試人員發(fā)送產(chǎn)品上線報告