第一篇：測(cè)試流程說明

測(cè)試部聯(lián)運(yùn)評(píng)測(cè)流程

說明

1，有產(chǎn)品評(píng)測(cè)部門主管收集評(píng)測(cè)目標(biāo)，并記錄到評(píng)測(cè)日程表中

2，由市場(chǎng)或其他部門來提供評(píng)測(cè)目標(biāo)，相應(yīng)的評(píng)測(cè)目標(biāo)會(huì)記錄在評(píng)測(cè)日程表中 3，有評(píng)測(cè)組的測(cè)試員來對(duì)評(píng)測(cè)目標(biāo)進(jìn)行游戲評(píng)測(cè)并給出相應(yīng)聯(lián)運(yùn)建議

4，在測(cè)試部門內(nèi)進(jìn)行最終篩選，并給出集中建議（建議分為：推薦；不推薦；周期觀察）5，提交給評(píng)測(cè)報(bào)告產(chǎn)品運(yùn)營(yíng)部門接口人，報(bào)告包括所有給出建議的產(chǎn)品報(bào)告

6，對(duì)評(píng)價(jià)為可觀察的產(chǎn)品，進(jìn)入評(píng)測(cè)日程表中的回歸參看列表中，將根據(jù)周為單位進(jìn)行跟

蹤觀察

報(bào)告上報(bào)時(shí)間：周二，周四，周五（上報(bào)時(shí)會(huì)RTX通知相關(guān)人員）

周五為每周評(píng)測(cè)產(chǎn)品的一個(gè)數(shù)據(jù)統(tǒng)計(jì)，并包括當(dāng)天評(píng)測(cè)的游戲報(bào)告

如有非常值得推薦的產(chǎn)品游戲，會(huì)馬上提交給產(chǎn)品運(yùn)營(yíng)接口人

研發(fā)產(chǎn)品測(cè)試流程

說明

1，對(duì)公司內(nèi)研發(fā)產(chǎn)品測(cè)試，遵循研發(fā)部門測(cè)試進(jìn)行

2，產(chǎn)品更新及架設(shè)到內(nèi)網(wǎng)測(cè)試服務(wù)器后，則進(jìn)行游戲測(cè)試，在測(cè)試過程中發(fā)現(xiàn)的問題bug

上報(bào)到bug上報(bào)系統(tǒng)中（這個(gè)之后進(jìn)行架設(shè)）

3，提交后的bug由功能能劃分表進(jìn)行分配給相應(yīng)的修正人，功能模塊負(fù)責(zé)人劃分到時(shí)可以

和其他負(fù)責(zé)部門主管進(jìn)行溝通來制定或者有對(duì)應(yīng)負(fù)責(zé)的部門主管來進(jìn)行分配，這部分可以到時(shí)來討論決定

4，對(duì)修正后的bug進(jìn)行回歸測(cè)試，測(cè)試結(jié)果分為已修正和未修正兩種

5，對(duì)已修正的bug進(jìn)行關(guān)閉操作，這部分有測(cè)試部門負(fù)責(zé)人執(zhí)行

6，對(duì)未修正的bug測(cè)試人員則直接打回給修正人，讓他繼續(xù)修正

注：對(duì)于項(xiàng)目整體bug修正的推動(dòng)會(huì)按bug的嚴(yán)重程度進(jìn)行重點(diǎn)推動(dòng)，督促嚴(yán)重bug盡快的解決

Bug的嚴(yán)重等級(jí)和所歸為具體功能模塊，到時(shí)會(huì)給一個(gè)明確的定義和劃分文檔，已供測(cè)試員參考

以上是對(duì)bug的跟蹤、驗(yàn)證、回歸的流程，研發(fā)產(chǎn)品的測(cè)試會(huì)有一個(gè)相應(yīng)的日程表進(jìn)行計(jì)劃和記錄（測(cè)試計(jì)劃暫定分為：一，功能、玩法專項(xiàng)測(cè)試，既針對(duì)該功能、玩法進(jìn)行詳細(xì)測(cè)試；二，更新后常規(guī)測(cè)試，既大概走一下全部功能、玩法，保證更新后，游戲可以正常進(jìn)行；三，集中和壓力承載測(cè)試），測(cè)試計(jì)劃主要是根據(jù)項(xiàng)目的進(jìn)度和更新來做。

第二篇：采購(gòu)部審批流程測(cè)試說明文檔

采購(gòu)部審批流程測(cè)試說明文檔

一、采購(gòu)部申請(qǐng)單、采購(gòu)訂單現(xiàn)有審批流程：

系統(tǒng)內(nèi)采購(gòu)訂單生成后，采購(gòu)員進(jìn)行自審批。然后將采購(gòu)訂單進(jìn)行系統(tǒng)自動(dòng)打印，提交主管采購(gòu)經(jīng)理、采購(gòu)總監(jiān)、財(cái)務(wù)經(jīng)理等領(lǐng)導(dǎo)簽字后生效備案。

流程圖：

采購(gòu)流程1.0MRP分解2.0手工錄入輸入供應(yīng)商、價(jià)格等信息生產(chǎn)計(jì)劃部采購(gòu)部3.0采購(gòu)申請(qǐng)單4.0采購(gòu)訂單5.0打印審批單6.0領(lǐng)導(dǎo)審批Y7.0打印采購(gòu)訂單8.0通知供應(yīng)商供貨N14.0訂單修改采購(gòu)部9.0倉(cāng)庫(kù)接收儲(chǔ)運(yùn)部11.0非生產(chǎn)類檢驗(yàn)10.0生產(chǎn)類檢驗(yàn)質(zhì)檢部申請(qǐng)部門檢驗(yàn)12.0入庫(kù)儲(chǔ)運(yùn)部13.0付款財(cái)務(wù)部

二、測(cè)試目的

按照公司授權(quán)審批流程及采購(gòu)部采購(gòu)訂單審批程序，系統(tǒng)內(nèi)采購(gòu)訂單取消自審批，重新設(shè)置審批層，由主管領(lǐng)導(dǎo)在系統(tǒng)內(nèi)審批訂單。

三、測(cè)試過程

以下測(cè)試均在測(cè)試環(huán)境下，電器組織下進(jìn)行測(cè)試。測(cè)試用戶：E01061（采購(gòu)員），E04920（采購(gòu)經(jīng)理），H00021

(采購(gòu)總監(jiān))，H00083（財(cái)務(wù)經(jīng)理），E01077（采購(gòu)總經(jīng)理），E00358（財(cái)務(wù)總監(jiān)），H00076（首席財(cái)務(wù)官），H00029（首席運(yùn)營(yíng)官），H00002（董事長(zhǎng)），CHF（采購(gòu)超級(jí)用戶、人力資源管理員、HRMS管理員）。

3.1、取消采購(gòu)訂單自審批功能

以新飛電器_采購(gòu)超級(jí)用戶進(jìn)入，設(shè)置—采購(gòu)—單據(jù)類型

選擇標(biāo)準(zhǔn)采購(gòu)訂單，點(diǎn)擊<更新>，將責(zé)任人可審批前對(duì)勾去掉，即取消自審批功能。

提交報(bào)表：

同步WF局部表

（系統(tǒng)管理員下）填寫員工層次結(jié)構(gòu)表（采購(gòu)超級(jí)用戶）

3.2查看和添加職務(wù)、職位信息及相應(yīng)權(quán)限 3.2.1添加職務(wù)信息

以HRMS管理員權(quán)限進(jìn)入，工作結(jié)構(gòu)—職務(wù)—說明，查看已經(jīng)存在的職務(wù)。

添加相應(yīng)職務(wù)。添加采購(gòu)員、采購(gòu)經(jīng)理、采購(gòu)總監(jiān)、采購(gòu)總經(jīng)理、財(cái)務(wù)經(jīng)理、財(cái)務(wù)總監(jiān)、首席財(cái)務(wù)官、首席運(yùn)營(yíng)官、董事長(zhǎng)等空職務(wù)。

3.2.2添加職位信息

以HRMS管理員權(quán)限進(jìn)入，工作結(jié)構(gòu)—職位—說明，查看添加相應(yīng)職位。

例如：

3.2.3添加權(quán)限信息

以系統(tǒng)管理員權(quán)限進(jìn)入添加對(duì)應(yīng)權(quán)限職責(zé)。

例：

3.2.3添加采購(gòu)員職責(zé)

添加為采購(gòu)員，以電器采購(gòu)超級(jí)用戶權(quán)限。設(shè)置—人員—采購(gòu)員。

3.3、設(shè)立采購(gòu)審批層次

1、采購(gòu)員創(chuàng)建采購(gòu)訂單，提交相應(yīng)的采購(gòu)經(jīng)理審批。

2、采購(gòu)經(jīng)理批準(zhǔn)后提交采購(gòu)總監(jiān)審批。

3、采購(gòu)采購(gòu)總監(jiān)審批后，提交采財(cái)務(wù)經(jīng)理審批。

4、財(cái)務(wù)經(jīng)理審批后，提交采購(gòu)總經(jīng)理。

5、采購(gòu)總經(jīng)理審批后，提交財(cái)務(wù)總監(jiān)。

6、財(cái)務(wù)總監(jiān)審批后，提交首席財(cái)務(wù)官。

7、首席財(cái)務(wù)官審批后，提交首席運(yùn)營(yíng)官。

8、首席運(yùn)營(yíng)官審批后，提交董事長(zhǎng)。

9、董事長(zhǎng)審批，整個(gè)流程結(jié)束。

創(chuàng)建采購(gòu)審批層次：以用戶HRMS管理員進(jìn)入，工作結(jié)構(gòu)—職位—層次結(jié)構(gòu)，創(chuàng)建審批層次

3.4查看定義對(duì)應(yīng)的上下級(jí)關(guān)系（由低至高）

1、采購(gòu)員

2、采購(gòu)經(jīng)理

（李娜）

3、采購(gòu)總監(jiān)

（蘇俊文）

4、財(cái)務(wù)經(jīng)理

（王仁偉）

5、采購(gòu)總經(jīng)理（李永剛）

6、財(cái)務(wù)總監(jiān)

（鞏紅中）

7、首席財(cái)務(wù)官（尹浩恩）

9、首席運(yùn)營(yíng)官（丁俊發(fā)）

10、董事長(zhǎng)

（高嘉琳）

以新飛人力資源超級(jí)用戶進(jìn)入，人事管理—輸入維護(hù)人員—分配

3.5、查看各職位下屬人員信息

以HRMS管理員權(quán)限進(jìn)入，工作結(jié)構(gòu)—職位—層次結(jié)構(gòu)

3.6查看審批組的設(shè)定

以采購(gòu)超級(jí)用戶權(quán)限進(jìn)入，設(shè)置—審批—審批組，創(chuàng)建審批組

3.7、查看審批分配的設(shè)定

以采購(gòu)超級(jí)用戶權(quán)限進(jìn)入，設(shè)置—審批—審批分配。

3.8設(shè)置完畢，提交報(bào)表

1、以采購(gòu)超級(jí)用戶權(quán)限提交填寫員工層次結(jié)構(gòu)表報(bào)表。

2、以系統(tǒng)管理員權(quán)限提交同步WF局部表報(bào)表。

3.9采購(gòu)訂單測(cè)試

3.9.1測(cè)試采購(gòu)金額小于50萬元

流程：采購(gòu)員—采購(gòu)經(jīng)理—采購(gòu)總監(jiān)—財(cái)務(wù)經(jīng)理—批準(zhǔn)結(jié)束 測(cè)試：采購(gòu)員E01061提交采購(gòu)訂單49320審批過程。

點(diǎn)擊審批

點(diǎn)擊確定。

采購(gòu)經(jīng)理E04920進(jìn)入http://172.16.10.2:8001進(jìn)行單據(jù)審批，審批后提交采購(gòu)總監(jiān)審批。

點(diǎn)<審批> 采購(gòu)總監(jiān)H00021進(jìn)入http://172.16.10.2:8001進(jìn)行單據(jù)審批，審批后提交財(cái)務(wù)經(jīng)理審批。

點(diǎn)<審批>

財(cái)務(wù)經(jīng)理H00021進(jìn)入http://172.16.10.2:8001進(jìn)行單據(jù)審批，審批批準(zhǔn)。

點(diǎn)<審批> 采購(gòu)員E01061查看此訂單是否已經(jīng)批準(zhǔn)

3.9.2測(cè)試采購(gòu)金額大于50萬元小于300萬元

步驟如上

3.9.3測(cè)試采購(gòu)金額大于300萬元小于500萬元

步驟如上

3.9.4測(cè)試采購(gòu)金額大于500萬元

步驟如上

自審批： Step1:

創(chuàng)建一個(gè)新內(nèi)部審批組，用于電器采購(gòu)制冷、家電的成品，額度沒有限制

定義相關(guān)人員的職位

職位與審批組關(guān)聯(lián)，單據(jù)類型一定選擇標(biāo)準(zhǔn)的采購(gòu)訂單

第三篇：產(chǎn)品測(cè)試流程

需求分析

需求分析由產(chǎn)品人員制定，他們要做的不是一份簡(jiǎn)單的文檔，而是細(xì)化每一個(gè)功能的細(xì)節(jié)，每一個(gè)按鈕的位置，對(duì)于稍大或復(fù)雜一點(diǎn)的需求都進(jìn)行建模。

需求評(píng)審

需求評(píng)審（產(chǎn)品需求人員、開發(fā)人員、測(cè)試人員、設(shè)計(jì)人員）前期需求進(jìn)入會(huì)大大增加測(cè)試人員對(duì)產(chǎn)品的功能的整體把握，現(xiàn)在測(cè)試人員擔(dān)任的是測(cè)試和產(chǎn)品體驗(yàn)員的身份。測(cè)試人員提出需求，開發(fā)人員考慮功能實(shí)現(xiàn)的方案與可行性、當(dāng)然開發(fā)負(fù)責(zé)也是要參與的。測(cè)試人員主要是對(duì)需求的理解提出疑問，以便才能根據(jù)需求寫用例。QA人員是最終對(duì)軟件質(zhì)量進(jìn)行驗(yàn)證的人，所以也需求了解需求。

開發(fā)人員編寫排期

開發(fā)人員需求根據(jù)需求功能點(diǎn)進(jìn)行排期。然后將開計(jì)劃轉(zhuǎn)交給測(cè)試人員。

測(cè)試計(jì)劃排期

測(cè)試人員根據(jù)開發(fā)計(jì)劃，對(duì)測(cè)試具體測(cè)試時(shí)間，也就是開發(fā)功能完成后的時(shí)間，進(jìn)行幾輪測(cè)試等。然后，把項(xiàng)目的開發(fā)與測(cè)試計(jì)劃發(fā)送給各部門負(fù)責(zé)人及參與項(xiàng)目的所有人員。

編寫測(cè)試用例

根據(jù)詳細(xì)的需求分檔，開始進(jìn)行用例的編寫。

【開發(fā)人員寫開發(fā)計(jì)劃--》測(cè)試人員編寫測(cè)試計(jì)劃--》郵件通知所有人員及部門負(fù)責(zé)人?！?/p>

用例評(píng)審

在用例進(jìn)行評(píng)審之間，先以郵件形式將用例發(fā)送給相關(guān)人員，以便他們事先了解用例對(duì)哪些功能進(jìn)行驗(yàn)證以及驗(yàn)證的細(xì)節(jié)。

然后，測(cè)試人員組進(jìn)行用例評(píng)審，開發(fā)人員對(duì)用例與實(shí)際功能不符合有哪些，產(chǎn)品人員對(duì)會(huì)通過用例對(duì)功能的具體實(shí)現(xiàn)進(jìn)行把握等等。

【測(cè)試用例評(píng)審（產(chǎn)品需求人員、開發(fā)人員、測(cè)試人員、QA人員）】

提交基線

開發(fā)人員完成所有功能后，會(huì)對(duì)自己的功能進(jìn)行一個(gè)自測(cè)。自測(cè)完成后提交測(cè)試人員進(jìn)行基線?！鹃_發(fā)代碼及自測(cè)---》編寫測(cè)試用例】

具體測(cè)試流程

開發(fā)人員對(duì)于基到測(cè)試線的功能進(jìn)行測(cè)試，發(fā)現(xiàn)的問題通過缺陷管理工具進(jìn)行反饋，開發(fā)人員對(duì)問題進(jìn)行修復(fù)，然后，準(zhǔn)備第二輪測(cè)試。

測(cè)試人員完成第一輪測(cè)試后，需要寫測(cè)試結(jié)論，發(fā)到相關(guān)人員。然后對(duì)基線后的第二輪進(jìn)行測(cè)試，第二輪會(huì)對(duì)第一輪中發(fā)現(xiàn)的問題進(jìn)行重點(diǎn)回歸。

測(cè)試具體流程如下：

1、測(cè)試和發(fā)現(xiàn)軟件中存在的軟件缺陷

使用各種測(cè)試技術(shù)和方法來測(cè)試和發(fā)現(xiàn)軟件中存在的軟件缺陷。測(cè)試技術(shù)主要分為黑盒測(cè)試和白盒測(cè)試兩大類。

其中黑盒測(cè)試技術(shù)主要有等價(jià)類劃分法、邊界值法、因果圖法、狀態(tài)圖法、測(cè)試大綱法以及各類典型的軟件故障模型等;白盒測(cè)試的主要技術(shù)有語(yǔ)句覆蓋、分支覆蓋、判定覆蓋、基本路徑覆蓋等;

2、測(cè)試工作需要貫穿整個(gè)軟件開發(fā)生命周期

完整的軟件測(cè)試工作包括單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試工作。

單元測(cè)試工作主要在編碼階段完成，由開發(fā)人員和軟件測(cè)試工程師共同完成，其主要依據(jù)是詳細(xì)測(cè)試。集成測(cè)試的主要工作測(cè)試軟件模塊之間的接口是否正確實(shí)現(xiàn)，基本依據(jù)是軟件體系結(jié)構(gòu)設(shè)計(jì)。確認(rèn)測(cè)試和系統(tǒng)測(cè)試是在軟件開發(fā)完成后，驗(yàn)證軟件的功能與需求的一致性、驗(yàn)證軟件在相應(yīng)的硬件條件下的系統(tǒng)功能是否滿足用戶需求，其主要依據(jù)是用戶需求。

3、缺陷報(bào)告編寫及提交

測(cè)試人員將發(fā)現(xiàn)的缺陷編寫成正式的缺陷報(bào)告，提交給開發(fā)人員進(jìn)行缺陷的確認(rèn)和修復(fù)。缺陷報(bào)告編寫最主要的要求是保證缺陷的重現(xiàn)。要求測(cè)試人員具有很好的文字表達(dá)能力和語(yǔ)言組織能力。

4、軟件質(zhì)量分析

測(cè)試人員需要分析軟件質(zhì)量。

在測(cè)試完成后，測(cè)試人員需要根據(jù)測(cè)試結(jié)果來分析軟件質(zhì)量，包括缺陷率、缺陷分布、缺陷修復(fù)趨勢(shì)等。給出軟件各種質(zhì)量特性包括有功能性、可靠性、易用性、安全性、時(shí)間與資源特性等的具體度量。最后給出一個(gè)軟件是否可以發(fā)布或提交用戶使用的結(jié)論。

5、測(cè)試計(jì)劃制定

測(cè)試過程中，為了更好地組織與實(shí)施測(cè)試工作，測(cè)試負(fù)責(zé)人需要制定測(cè)試計(jì)劃，包括有測(cè)試資源、測(cè)試進(jìn)度、測(cè)試策略、測(cè)試方法、測(cè)試工具、測(cè)試風(fēng)險(xiǎn)等。

6、測(cè)試用例報(bào)告形成測(cè)試人員為了更好更有效地進(jìn)行測(cè)試，保證測(cè)試工作質(zhì)量，需要在執(zhí)行測(cè)試工作之前首先需要設(shè)計(jì)測(cè)試用例，形成測(cè)試用例報(bào)告。設(shè)計(jì)測(cè)試用例是保證測(cè)試質(zhì)量的核心工作，很多測(cè)試技術(shù)都可以用來指導(dǎo)設(shè)計(jì)用例。

7、自動(dòng)化測(cè)試工具引進(jìn)

為了提高工作效率或提高測(cè)試水平，測(cè)試工作需要引進(jìn)自動(dòng)化測(cè)試工具，測(cè)試人員需要學(xué)會(huì)使用自動(dòng)化測(cè)試工具，編寫測(cè)試腳本，進(jìn)行性能測(cè)試等。

8、測(cè)試水平提高

測(cè)試負(fù)責(zé)人在測(cè)試工作中，還需要根據(jù)實(shí)際情況不斷改進(jìn)測(cè)試過程，提高測(cè)試水平，進(jìn)行測(cè)試隊(duì)伍的建設(shè)等。

缺陷管理

使用bug缺陷管理工具，redmine項(xiàng)目管理，通過測(cè)試對(duì)發(fā)現(xiàn)的問題提交到redmine上并進(jìn)行跟蹤。視情況可以將比較簡(jiǎn)單的bug直接對(duì)接開發(fā)人員，通過當(dāng)面交流的方式闡明簡(jiǎn)單bug的問題所在，提高開發(fā)人員修復(fù)bug的效率，同時(shí)要在redmine上做好bug記錄，發(fā)布測(cè)試新的版本的時(shí)候復(fù)測(cè)問題。

測(cè)試管理

經(jīng)過兩到三輪或四輪的測(cè)試后，直到?jīng)]發(fā)現(xiàn)新的問題，或暫時(shí)無法解決，或不緊急的問題。通過上級(jí)確認(rèn)，可以通過。編寫測(cè)試報(bào)告與驗(yàn)收方案。

驗(yàn)收方案是交由QA進(jìn)行驗(yàn)證的。在現(xiàn)公司的流程中是將測(cè)試與QA分開的，測(cè)試人員重點(diǎn)關(guān)注的是功能是否可以正常運(yùn)行。QA關(guān)注的是整個(gè)流程的質(zhì)量以及最終用戶的質(zhì)量。有些公司QA與測(cè)試是不區(qū)分的，但這對(duì)測(cè)試的要求會(huì)更高，除了關(guān)心功能，還需要關(guān)心整體流程與質(zhì)量。

上線后測(cè)試

產(chǎn)品上線后需要再次測(cè)試產(chǎn)品的功能性，確保發(fā)布線上的環(huán)境配置正確，產(chǎn)品功能流暢。這是我們一個(gè)面向大眾用戶的網(wǎng)站，給于測(cè)試人員的定位是測(cè)試員兼用戶體驗(yàn)員，測(cè)試員將發(fā)現(xiàn)的bug和體驗(yàn)問題提交到缺陷管理系統(tǒng)，由經(jīng)理對(duì)問題進(jìn)行分析，指派開發(fā)人員解決。定期對(duì)系統(tǒng)進(jìn)行更新。（測(cè)試人員以用戶的角度出發(fā)體驗(yàn)功能完整性和功能流暢度以及功能的體驗(yàn)，為產(chǎn)品的長(zhǎng)期發(fā)展起到一個(gè)促進(jìn)的作用！）

第四篇：測(cè)試流程參考資料

工作兩年了，我一直希望讓自己每年對(duì)測(cè)試的理解更深入一層。工作一年的時(shí)候我寫了《談軟件測(cè)試---一年工作總結(jié)》，談?shì)喠俗约簩?duì)各種測(cè)試的理解，這一年來，雖然對(duì)那些理概念的有所加強(qiáng)，自我感覺沒有什么質(zhì)的變化。前些天聽我們公司的一位測(cè)試經(jīng)理講《敏捷測(cè)試》豁然開朗。他在學(xué)造飛機(jī)，而我一直在學(xué)造飛機(jī)里的一個(gè)發(fā)動(dòng)機(jī)。我從來沒想過，一個(gè)完整飛機(jī)的架構(gòu)應(yīng)該是怎樣的。

如果想讓測(cè)試在公司的項(xiàng)目中發(fā)揮出它最大的價(jià)值，并不是招兩個(gè)測(cè)試技術(shù)高手，或引入幾個(gè)測(cè)試技術(shù)，而是測(cè)試技術(shù)對(duì)項(xiàng)目流程的滲透，以及測(cè)試流程的改進(jìn)與完善。雖然，當(dāng)然測(cè)試行業(yè)前景樂觀，許多中小企業(yè)也都在引入測(cè)試，但一百個(gè)公司就有一百種測(cè)試，每個(gè)公司對(duì)測(cè)試的看法不同，公司對(duì)測(cè)試的定位也不完全一樣。本人前后經(jīng)歷兩個(gè)公司，以自己的拙見淺談一下對(duì)測(cè)試流程的看法。

這幾天整理思路，回顧了前兩份測(cè)試工作的流程與架構(gòu)。

簡(jiǎn)陋的測(cè)試流程

先說筆者入職的第一個(gè)家公司，筆者是第一個(gè)入職的專職測(cè)試人員，相信一兩個(gè)測(cè)試的公司還是不少的，入職后各種項(xiàng)目都在進(jìn)行當(dāng)中，上面給我的定位是并沒完全融入到項(xiàng)目中去。而通過指派任務(wù)的方式。下面是簡(jiǎn)陋的流程圖：

需求分析與架構(gòu)設(shè)計(jì)：

我們做的是某一移動(dòng)公司內(nèi)部使用的項(xiàng)目，需求分析與架構(gòu)全部由項(xiàng)目經(jīng)理完成，之后由項(xiàng)目經(jīng)理給具體某個(gè)開發(fā)人員分配任務(wù)，具體對(duì)某個(gè)功能模塊的實(shí)現(xiàn)。這個(gè)對(duì)項(xiàng)目經(jīng)理的經(jīng)驗(yàn)與技術(shù)要求很高，他既然擔(dān)任了需求分析師，又擔(dān)任架構(gòu)師的角色。程序員編碼：

因?yàn)槲覀冮_發(fā)語(yǔ)言用的是JAVA 語(yǔ)言，IDE用myeclipse 中自帶的CVS版本管理工具，開發(fā)人員完成代碼后，提交到版本庫(kù)中。測(cè)試：

筆者入職后的第一個(gè)任務(wù)是搭建缺陷管理工具，禪道項(xiàng)目管理，通過推廣對(duì)發(fā)現(xiàn)的問題進(jìn)行跟蹤。后來正明效果并不好，因?yàn)閷?duì)于一個(gè)六七人的開發(fā)團(tuán)隊(duì)項(xiàng)目，開發(fā)人員更喜歡測(cè)試人員能當(dāng)面反饋，這樣更能提高效率。對(duì)一個(gè)小bug 通過當(dāng)面交流的方式就可以將問題修復(fù)。

對(duì)于當(dāng)時(shí)的環(huán)境，并沒有測(cè)試線。開發(fā)人員在本機(jī)上將項(xiàng)目進(jìn)行部署運(yùn)行。測(cè)試人員通過局域網(wǎng)訪問開發(fā)人員的機(jī)子進(jìn)行訪問?；蛟跍y(cè)試人員本機(jī)上進(jìn)行部署測(cè)試。這也是一個(gè)致命的缺點(diǎn)。因?yàn)殚_發(fā)人員測(cè)試人員使用的電腦存在太多不穩(wěn)定性，這些都會(huì)造成問題的出現(xiàn)，有時(shí)候難以判定是系統(tǒng)問題還是環(huán)境問題。上線：

經(jīng)過測(cè)試人員測(cè)試通過后，開發(fā)人員部署上線。A程序員流程

你會(huì)發(fā)現(xiàn)在流程圖中，A程序員是先發(fā)上線之后，再進(jìn)行測(cè)試。這是我們一個(gè)面向大眾用戶的網(wǎng)站，上面給于測(cè)試人員的定位是測(cè)試員兼用戶體驗(yàn)員，測(cè)試員將發(fā)現(xiàn)的bug和體驗(yàn)問題提交到缺陷管理系統(tǒng)，由經(jīng)理對(duì)問題進(jìn)行分析，指派開發(fā)人員解決。定期對(duì)系統(tǒng)進(jìn)行更新。

流程分析：

這個(gè)流程唯一的優(yōu)點(diǎn)，就是能快速的發(fā)現(xiàn)并修復(fù)問題。

缺點(diǎn)就非常多了，相信許多小軟件公司也有類似的流程。

這個(gè)流程中，項(xiàng)目經(jīng)理是核心，項(xiàng)目經(jīng)理也確實(shí)是有多年開發(fā)與項(xiàng)目經(jīng)驗(yàn)的牛人，他喜歡不定期分享上些前沿的技術(shù)。我很崇拜他。

對(duì)于測(cè)試來說，需求很不明確，測(cè)試文檔與用例也是可有可無的產(chǎn)物，沒有需求文檔，或非常簡(jiǎn)陋，根據(jù)需求文檔根本無法編寫用例。筆者只能收集一些通用的測(cè)試用例，如登錄、文件上傳下載、列表翻頁(yè)、日期選擇、輸入框驗(yàn)證、搜索等有一些“通用型”用例，以便在測(cè)試過程中做參考。功能測(cè)試的多了，拿到一個(gè)功能，測(cè)試思路也就出來了。

規(guī)范的測(cè)試流程

放棄上份悠閑的工作，感謝那個(gè)帶我入行公司，我想了解真正的測(cè)試在公作中如何進(jìn)行的。所以，來到了現(xiàn)在這家公司。我很欣喜的是這測(cè)試有自己的團(tuán)隊(duì)，專業(yè)（對(duì)當(dāng)時(shí)的我來說）的流程，以及與開發(fā)等同的地位。現(xiàn)在的測(cè)試流程：

需求分析：

需求分析由產(chǎn)品人員制定，他們要做的不是一份簡(jiǎn)單的文檔，而是細(xì)化每一個(gè)功能的細(xì)節(jié)，每一個(gè)按鈕的位置，對(duì)于稍大或復(fù)雜一點(diǎn)的需求都進(jìn)行建模。需求評(píng)審：

這里會(huì)叫上所有參與項(xiàng)目人員進(jìn)行，開發(fā)人員、測(cè)試人員、QA人員。測(cè)試人員提出需求，開發(fā)人員考慮功能實(shí)現(xiàn)的方案與可行性、當(dāng)然開發(fā)負(fù)責(zé)也是要參與的。測(cè)試人員主要是對(duì)需求的理解提出疑問，以便才能根據(jù)需求寫用例。QA人員是最終對(duì)軟件質(zhì)量進(jìn)行驗(yàn)證的人，所以也需求了解需求 開發(fā)人員編寫排期：

開發(fā)人員需求根據(jù)需求功能點(diǎn)進(jìn)行排期。然后將開計(jì)劃轉(zhuǎn)交給測(cè)試人員。測(cè)試計(jì)劃排期：

測(cè)試人員根據(jù)開發(fā)計(jì)劃，對(duì)測(cè)試具體測(cè)試時(shí)間，也就是開發(fā)功能完成后的時(shí)間，進(jìn)行幾輪測(cè)試等。然后，把項(xiàng)目的開發(fā)與測(cè)試計(jì)劃發(fā)送給各部門負(fù)責(zé)人及參與項(xiàng)目的所有人員。編寫測(cè)試用例：

根據(jù)詳細(xì)的需求分檔，開始進(jìn)行用例的編寫。用例評(píng)審：

在用例進(jìn)行評(píng)審之間，先以郵件形式將用例發(fā)送給相關(guān)人員，以便他們事先了解用例對(duì)哪些功能進(jìn)行驗(yàn)證以及驗(yàn)證的細(xì)節(jié)。

然后，測(cè)試人員組進(jìn)行用例評(píng)審，開發(fā)人員對(duì)用例與實(shí)際功能不符合有哪些，產(chǎn)品人員對(duì)會(huì)通過用例對(duì)功能的具體實(shí)現(xiàn)進(jìn)行把握等等。提交基線：

開發(fā)人員完成所有功能后，會(huì)對(duì)自己的功能進(jìn)行一個(gè)自測(cè)。自測(cè)完成后提交測(cè)試人員進(jìn)行基線。

具體測(cè)試流程：

開發(fā)人員對(duì)于基到測(cè)試線的功能進(jìn)行測(cè)式，發(fā)現(xiàn)的問題通過缺陷管理工具進(jìn)行反饋，開發(fā)人員對(duì)問題進(jìn)行修復(fù)，然后，準(zhǔn)備第二輪基。

測(cè)試人員完成第一輪測(cè)試后，需要寫測(cè)試結(jié)論，發(fā)到相關(guān)人員。然后對(duì)基線后的第二輪進(jìn)行測(cè)試，第二輪會(huì)對(duì)第一輪中發(fā)現(xiàn)的問題進(jìn)行重點(diǎn)回歸。測(cè)試通過：

經(jīng)過兩到三輪或四輪的測(cè)試后，直到?jīng)]發(fā)現(xiàn)新的問題，或暫時(shí)無法解決，或不緊急的問題。通過上級(jí)確認(rèn)，可以通過。編寫測(cè)試報(bào)告與驗(yàn)收方案。

驗(yàn)收方案是交由QA進(jìn)行驗(yàn)證的。在現(xiàn)公司的流程中是將測(cè)試與QA分開的，測(cè)試人員重點(diǎn)關(guān)注的是功能是否可以正常運(yùn)行。QA關(guān)注的是整個(gè)流程的質(zhì)量以及最終用戶的質(zhì)量。有些公司QA與測(cè)試是不區(qū)分的，但這對(duì)測(cè)試的要求會(huì)更高，除了關(guān)心功能，還需要關(guān)心整體流程與質(zhì)量。

流程分析：

對(duì)于剛接觸這個(gè)流程的我來說，這個(gè)流程是規(guī)范的，測(cè)試真正融入了整個(gè)流程，而且還擔(dān)任了很重的角色，從而也有效的保證了軟件產(chǎn)品的整體質(zhì)量。

那么這個(gè)流程是不是完美的呢？不，這個(gè)項(xiàng)目流程太強(qiáng)化各種文檔。我們來看測(cè)試的工作內(nèi)容，測(cè)試計(jì)劃、測(cè)試用例、測(cè)試結(jié)論、測(cè)試報(bào)告、驗(yàn)收方案、問題的提交跟蹤。其實(shí)，我們真用于測(cè)試的時(shí)間是非常少的，在一周的時(shí)間，也許只有一天或不到一天的時(shí)間是在進(jìn)行測(cè)試的。測(cè)試人員只有在測(cè)試的時(shí)候才會(huì)體現(xiàn)出他的價(jià)值。而大部分工作卻不能體現(xiàn)他的價(jià)值。

當(dāng)然，我這里會(huì)省略與測(cè)試主流程無關(guān)的東西，真正的測(cè)試工作中瑣事很多。

敏捷測(cè)試流程

下面來看敏捷測(cè)試，本人并沒有接觸過敏捷，對(duì)敏捷也沒花時(shí)間學(xué)習(xí)與研究。唯一接觸就是聽我們測(cè)試經(jīng)理對(duì)測(cè)度流程講了兩個(gè)半小時(shí)，聽講的人很多，我站著聽的。受益匪淺，憑著記憶也簡(jiǎn)單談?wù)劇?/p>

前面講的第一種流程，還是第二種流程都是瀑布式的，嚴(yán)格來說第一種簡(jiǎn)陋的都不能稱為瀑布式，對(duì)于一個(gè)三個(gè)月的項(xiàng)目說，產(chǎn)品把需求分析完了給開發(fā)，然后產(chǎn)品就沒事兒了；開發(fā)開發(fā)完成之后給測(cè)試，然后開發(fā)人員也不忙了。測(cè)試完成之后上線。那么在產(chǎn)品分析的階段，開發(fā)和測(cè)試都是沒事干的（這里只對(duì)單一項(xiàng)目）。開發(fā)階段，產(chǎn)品和測(cè)試也基本沒事兒。同樣在測(cè)試階段，產(chǎn)品與開發(fā)也是沒什么事兒的。

敏捷測(cè)試的一個(gè)核心是迭代，在每個(gè)時(shí)間點(diǎn)上，所有項(xiàng)目人員都是有事可做的。

1、下面是我理解中的敏捷測(cè)試流程圖：

第一階段：

通過上面的流程圖，對(duì)于一個(gè)月的需求分析，在敏捷中，可能三五天就確定下來。這個(gè)需求定得會(huì)很模糊，但整體框架確定。產(chǎn)品對(duì)其中某一模塊功能確認(rèn)，開發(fā)人員開始對(duì)確認(rèn)的功能編碼，開發(fā)人員編碼的過程中，測(cè)試進(jìn)行功能分解，因?yàn)楦鶕?jù)模糊的需求很難寫出具體的用例，所以，只能盡量對(duì)功能進(jìn)行分析得細(xì)些，標(biāo)注需要驗(yàn)證的內(nèi)容。第二階段：

開發(fā)完成后交給測(cè)試人員進(jìn)行測(cè)試，開發(fā)人員繼續(xù)開發(fā)新的功能。那么測(cè)試人員發(fā)現(xiàn)的問題怎么辦呢？會(huì)從開發(fā)團(tuán)隊(duì)中抽出一個(gè)人員來用于解決測(cè)試發(fā)現(xiàn)的問題。但開發(fā)進(jìn)度并沒有因?yàn)闇y(cè)試而停止。

流程分析：

在這個(gè)流程中弱化了文檔，強(qiáng)調(diào)了各個(gè)人員的溝通，通過這種迭代的方式，三個(gè)月的項(xiàng)目，可以能兩個(gè)月和兩個(gè)半月就會(huì)完成。

但這種流程并非完美，加入一個(gè)功能在需求分析階段就是錯(cuò)誤的，因?yàn)樗且粋€(gè)迭代漸進(jìn)的過程。也只能一路錯(cuò)下去。

2、對(duì)測(cè)試問題的處理

上面的圖更能清晰看出對(duì)問題的處理過程。

第一塊面板中是開發(fā)人員未實(shí)現(xiàn)的功能，第二塊面板中是開發(fā)完成功能，測(cè)試人員對(duì)其進(jìn)行測(cè)試，發(fā)現(xiàn)不通過的就放回未開發(fā)的面板中，測(cè)試通過的將放到第三塊面板中。

需要說明的是，敏捷測(cè)試在國(guó)外很流行，在內(nèi)容，雷聲大雨點(diǎn)小，推行的人很多，真正有公司引入的不多。我們所在公司千差萬別，測(cè)試流程也可能有很大的不同。對(duì)于已經(jīng)工作兩年一個(gè)測(cè)試員來說，從來沒關(guān)注過測(cè)試流程與結(jié)構(gòu)應(yīng)該是個(gè)悲劇。我希望不被思想局限，所以，努力沖破一個(gè)又一個(gè)的局限。

第五篇：APP測(cè)試流程

APP測(cè)試基本流程 1.流程圖

盡快申請(qǐng)到正式環(huán)境下測(cè)試 接收版本 不符

App測(cè)試版本送測(cè)規(guī)范 用戶行為統(tǒng)計(jì)測(cè)試 后臺(tái)訂單統(tǒng)計(jì)測(cè)試 盡快申請(qǐng)到正式環(huán)境下測(cè)試 兼容性測(cè)試、性能壓力測(cè)試 功能測(cè)試：核對(duì)需求文檔 UI測(cè)試：核對(duì)rp/效果圖 符合 回歸測(cè)試 仍然為測(cè)試環(huán)境 進(jìn)入正式環(huán)境 發(fā)送上線報(bào)告 Fail Pass

2.測(cè)試周期 測(cè)試周期可按項(xiàng)目的開發(fā)周期來確定測(cè)試時(shí)間，一般測(cè)試時(shí)間為兩三周（即15個(gè)工作日），根據(jù)項(xiàng)目情況以及版本質(zhì)量可適當(dāng)縮短或延長(zhǎng)測(cè)試時(shí)間。正式測(cè)試前先向主管確認(rèn)項(xiàng)目排期。3.測(cè)試資源

測(cè)試任務(wù)開始前，檢查各項(xiàng)測(cè)試資源。--產(chǎn)品功能需求文檔；--產(chǎn)品原型圖；--產(chǎn)品效果圖；

--行為統(tǒng)計(jì)分析定義文檔；

--測(cè)試設(shè)備（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）；--其他。

4.日?qǐng)?bào)及產(chǎn)品上線報(bào)告

1）測(cè)試人員每天需對(duì)所測(cè)項(xiàng)目發(fā)送測(cè)試日?qǐng)?bào)。2）測(cè)試日?qǐng)?bào)所包含的內(nèi)容為：--對(duì)當(dāng)前測(cè)試版本質(zhì)量進(jìn)行分級(jí)；

--對(duì)較嚴(yán)重的問題進(jìn)行例舉，提示開發(fā)人員優(yōu)先修改；--對(duì)版本的整體情況進(jìn)行評(píng)估。

3）產(chǎn)品上線前，測(cè)試人員發(fā)送產(chǎn)品上線報(bào)告。4）上線報(bào)告所包含的內(nèi)容為：---對(duì)當(dāng)前版本質(zhì)量進(jìn)行分級(jí)；---附上測(cè)試報(bào)告（功能測(cè)試報(bào)告、兼容性測(cè)試報(bào)告、性能測(cè)試報(bào)告以及app可用性能標(biāo)準(zhǔn)結(jié)果）；

--總結(jié)上線版本的基本情況。若有遺留問題必須列出并記錄解決方案。

App測(cè)試

1.安全測(cè)試

a.軟件權(quán)限

1）扣費(fèi)風(fēng)險(xiǎn)：包括發(fā)送短信、撥打電話、連接網(wǎng)絡(luò)等 2）隱私泄露風(fēng)險(xiǎn)：包括訪問手機(jī)信息、訪問聯(lián)系人信息等

3）對(duì)App的輸入有效性校驗(yàn)、認(rèn)證、授權(quán)、敏感數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)加密等方面進(jìn)行檢測(cè)

4）限制/允許使用手機(jī)功能接人互聯(lián)網(wǎng) 5）限制/允許使用手機(jī)發(fā)送接受信息功能 6）限制/允許應(yīng)用程序來注冊(cè)自動(dòng)啟動(dòng)應(yīng)用程序 7）限制或使用本地連接

8）限制/允許使用手機(jī)拍照或錄音 9）限制/允許使用手機(jī)讀取用戶數(shù)據(jù) 10)限制/允許使用手機(jī)寫人用戶數(shù)據(jù)

11)檢測(cè)App的用戶授權(quán)級(jí)別、數(shù)據(jù)泄漏、非法授權(quán)訪問等 b.安裝與卸載安全性

1）應(yīng)用程序應(yīng)能正確安裝到設(shè)備驅(qū)動(dòng)程序上 2）能夠在安裝設(shè)備驅(qū)動(dòng)程序上找到應(yīng)用程序的相應(yīng)圖標(biāo) 3）是否包含數(shù)字簽名信息

4）JAD文件和JAR包中包含的所有托管屬性及其值必需是正確的 5）JAD文件顯示的資料內(nèi)容與應(yīng)用程序顯示的資料內(nèi)容應(yīng)一致 6）安裝路徑應(yīng)能指定

7）沒有用戶的允許, 應(yīng)用程序不能預(yù)先設(shè)定自動(dòng)啟動(dòng) 8）卸載是否安全, 其安裝進(jìn)去的文件是否全部卸載 9）卸載用戶使用過程中產(chǎn)生的文件是否有提示 10）其修改的配置信息是否復(fù)原 11）卸載是否影響其他軟件的功能 12）卸載應(yīng)該移除所有的文件 c.數(shù)據(jù)安全性

1）當(dāng)將密碼或其他的敏感數(shù)據(jù)輸人到應(yīng)用程序時(shí), 其不會(huì)被儲(chǔ)存在設(shè)備中, 同時(shí)密碼也不會(huì)被解碼

2）輸人的密碼將不以明文形式進(jìn)行顯示

3）密碼, 信用卡明細(xì), 或其他的敏感數(shù)據(jù)將不被儲(chǔ)存在它們預(yù)輸人的位置上 4）不同的應(yīng)用程序的個(gè)人身份證或密碼長(zhǎng)度必需至少在4一8 個(gè)數(shù)字長(zhǎng)度之間

5）當(dāng)應(yīng)用程序處理信用卡明細(xì), 或其他的敏感數(shù)據(jù)時(shí), 不以明文形式將數(shù)據(jù)寫到其它單獨(dú)的文件或者臨時(shí)文件中。以6）防止應(yīng)用程序異常終止而又沒有側(cè)除它的臨時(shí)文件, 文件可能遭受人侵者的襲擊, 然后讀取這些數(shù)據(jù)信息。7）當(dāng)將敏感數(shù)據(jù)輸人到應(yīng)用程序時(shí), 其不會(huì)被儲(chǔ)存在設(shè)備中 8）備份應(yīng)該加密, 恢復(fù)數(shù)據(jù)應(yīng)考慮恢復(fù)過程的異常訊中斷等, 數(shù)據(jù)恢復(fù)后再使用前應(yīng)該經(jīng)過校驗(yàn)

9）應(yīng)用程序應(yīng)考慮系統(tǒng)或者虛擬機(jī)器產(chǎn)生的用戶提示信息或安全替告 10）應(yīng)用程序不能忽略系統(tǒng)或者虛擬機(jī)器產(chǎn)生的用戶提示信息或安全警告, 更不能在安全警告顯示前,，利用顯示誤導(dǎo)信息欺騙用戶，應(yīng)用程序不應(yīng)該模擬進(jìn)行安全警告誤導(dǎo)用戶

11）在數(shù)據(jù)刪除之前，應(yīng)用程序應(yīng)當(dāng)通知用戶或者應(yīng)用程序提供一個(gè)“取消”命令的操作

12）“ 取消” 命令操作能夠按照設(shè)計(jì)要求實(shí)現(xiàn)其功能

13）應(yīng)用程序應(yīng)當(dāng)能夠處理當(dāng)不允許應(yīng)用軟件連接到個(gè)人信息管理的情況 14）當(dāng)進(jìn)行讀或?qū)懹脩粜畔⒉僮鲿r(shí), 應(yīng)用程序?qū)?huì)向用戶發(fā)送一個(gè)操作錯(cuò)誤的提示信息

15）在沒有用戶明確許可的前提下不損壞側(cè)除個(gè)人信息管理應(yīng)用程序中的任何內(nèi)容Μ

16）應(yīng)用程序讀和寫數(shù)據(jù)正確。17）應(yīng)用程序應(yīng)當(dāng)有異常保護(hù)。

18）如果數(shù)據(jù)庫(kù)中重要的數(shù)據(jù)正要被重寫, 應(yīng)及時(shí)告知用戶 19）能合理地處理出現(xiàn)的錯(cuò)誤 20）意外情況下應(yīng)提示用戶 d.通訊安全性 1）在運(yùn)行其軟件過程中, 如果有來電、SMS、EMS、MMS、藍(lán)牙、紅外等通訊或充電時(shí), 是否能暫停程序，優(yōu)先處理通信, 并在處理完畢后能正?；謴?fù)軟件, 繼續(xù)其原來的功能

2）當(dāng)創(chuàng)立連接時(shí), 應(yīng)用程序能夠處理因?yàn)榫W(wǎng)絡(luò)連接中斷, 進(jìn)而告訴用戶連接中斷的情況

3）應(yīng)能處理通訊延時(shí)或中斷

4）應(yīng)用程序?qū)⒈３止ぷ鞯酵ㄓ嵆瑫r(shí), 進(jìn)而發(fā)送給用戶一個(gè)錯(cuò)誤信息指示有連接錯(cuò)誤

5）應(yīng)能處理網(wǎng)絡(luò)異常和及時(shí)將異常情況通報(bào)用戶 6）應(yīng)用程序關(guān)閉或網(wǎng)絡(luò)連接不再使用時(shí)應(yīng)及時(shí)關(guān)閉)斷開 7)HTTP、HTTPS覆蓋測(cè)試

--App和后臺(tái)服務(wù)一般都是通過HTTP來交互的，驗(yàn)證HTTP環(huán)境下是否正常；--公共免費(fèi)網(wǎng)絡(luò)環(huán)境中（如：麥當(dāng)勞、星巴克等）都要輸入用戶名和密碼，通過SSL認(rèn)證來訪問網(wǎng)絡(luò)，需要對(duì)使用HTTP Client的library異常作捕獲處理。e.人機(jī)接口安全性

1）返回菜單總保持可用 2）命令有優(yōu)先權(quán)順序

3）聲音的設(shè)置不影響應(yīng)用程序的功能

4）應(yīng)用程序必需利用目標(biāo)設(shè)備適用的全屏尺寸來顯示上述內(nèi)容

5）應(yīng)用程序必需能夠處理不可預(yù)知的用戶操作, 例如錯(cuò)誤的操作和同時(shí)按下多個(gè)鍵

2.安裝、卸載測(cè)試 驗(yàn)證App是否能正確安裝、運(yùn)行、卸載以及操作過程和操作前后對(duì)系統(tǒng)資源的使用情況 a.安裝

1）軟件在不同操作系統(tǒng)（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、Windows Phone 7）下安裝是否正常。

2）軟件安裝后的是否能夠正常運(yùn)行，安裝后的文件夾及文件是否寫到了指定的目錄里。

3）軟件安裝各個(gè)選項(xiàng)的組合是否符合概要設(shè)計(jì)說明 4)）軟件安裝向?qū)У腢I測(cè)試

5）軟件安裝過程是否可以取消，點(diǎn)擊取消后，寫入的文件是否如概要設(shè)計(jì)說明處理

6）軟件安裝過程中意外情況的處理是否符合需求（如死機(jī)，重啟，斷電）7）安裝空間不足時(shí)是否有相應(yīng)提示 8）安裝后沒有生成多余的目錄結(jié)構(gòu)和文件

9）對(duì)于需要通過網(wǎng)絡(luò)驗(yàn)證之類的安裝，在斷網(wǎng)情況下嘗試一下 10）還需要對(duì)安裝手冊(cè)進(jìn)行測(cè)試，依照安裝手冊(cè)是否能順利安裝 b.卸載

1）直接刪除安裝文件夾卸載是否有提示信息。2）測(cè)試系統(tǒng)直接卸載程序是否有提示信息。3）測(cè)試卸載后文件是否全部刪除所有的安裝文件夾。

4）卸載過程中出現(xiàn)的意外情況的測(cè)試（如死機(jī)、斷電、重啟）。5）卸載是否支持取消功能，單擊取消后軟件卸載的情況。6）系統(tǒng)直接卸載UI測(cè)試，是否有卸載狀態(tài)進(jìn)度條提示。

3.UI測(cè)試

測(cè)試用戶界面(如菜單、對(duì)話框、窗口和其它可規(guī)控件)布局、風(fēng)格是否滿足客戶要求、文字是否正確、頁(yè)面是否美觀、文字、圖片組合是否完美、操作是否友好等。UI測(cè)試的目標(biāo)是確保用戶界面會(huì)通過測(cè)試對(duì)象的功能來為用戶提供相應(yīng)的訪問或?yàn)g覓功能。確保用戶界面符合公司或行業(yè)的標(biāo)準(zhǔn)。包括用戶友好性、人性化、易操作性測(cè)試。a.導(dǎo)航測(cè)試

1）按鈕、對(duì)話框、列表和窗口等；或在不同的連接頁(yè)面之間需要導(dǎo)航 2）是否易于導(dǎo)航，導(dǎo)航是否直觀 3）是否需要搜索引擎 4）導(dǎo)航幫助是否準(zhǔn)確直觀

5）導(dǎo)航與頁(yè)面結(jié)構(gòu)、菜單、連接頁(yè)面的風(fēng)格是否一致 b.圖形測(cè)試

1）橫向比較。各控件操作方式統(tǒng)一

2）自適應(yīng)界面設(shè)計(jì)，內(nèi)容根據(jù)窗口大小自適應(yīng) 3）頁(yè)面標(biāo)簽風(fēng)格是否統(tǒng)一 4）頁(yè)面是否美觀

5）頁(yè)面的圖片應(yīng)有其實(shí)際意義而要求整體有序美觀

6）圖片質(zhì)量要高且圖片尺寸在設(shè)計(jì)符合要求的情況下應(yīng)盡量小 7）界面整體使用的顏色不宜過多 c.內(nèi)容測(cè)試 1）輸入框說明文字的內(nèi)容與系統(tǒng)功能是否一致 2）文字長(zhǎng)度是否加以限制 3）文字內(nèi)容是否表意不明 4）是否有錯(cuò)別字 5）信息是否為中文顯示 6）是否有敏感性詞匯、關(guān)鍵詞

7）是否有敏感性圖片，如：涉及版權(quán)、專利、隱私等圖片

4.功能測(cè)試

根據(jù)軟件說明或用戶需求驗(yàn)證App的各個(gè)功能實(shí)現(xiàn)，采用如下方法實(shí)現(xiàn)并評(píng)估功能測(cè)試過程：

1)采用時(shí)間、地點(diǎn)、對(duì)象、行為和背景五元素或業(yè)務(wù)分析等方法分析、提煉App的用戶使用場(chǎng)景，對(duì)比說明或需求，整理出內(nèi)在、外在及非功能直接相關(guān)的需求，構(gòu)建測(cè)試點(diǎn)，并明確測(cè)試標(biāo)準(zhǔn)，若用戶需求中無明確標(biāo)準(zhǔn)遵循，則需要參考行業(yè)或相關(guān)國(guó)際標(biāo)準(zhǔn)或準(zhǔn)則。

2)根據(jù)被測(cè)功能點(diǎn)的特性列丼出相應(yīng)類型的測(cè)試用例對(duì)其進(jìn)行覆蓋，如；涉及輸入的地方需要考慮等價(jià)、邊界、負(fù)面、異?；蚍欠?、場(chǎng)景回滾、關(guān)聯(lián)測(cè)試等測(cè)試類型對(duì)其進(jìn)行覆蓋。

3)在測(cè)試實(shí)現(xiàn)的各個(gè)階段跟蹤測(cè)試實(shí)現(xiàn)與需求輸入的覆蓋情況，及時(shí)修正業(yè)務(wù)或需求理解錯(cuò)誤。a.運(yùn)行

1）App安裝完成后的試運(yùn)行，可正常打開軟件。2）App打開測(cè)試，是否有加載狀態(tài)進(jìn)度提示。3）App打開速度測(cè)試，速度是否可觀。4）App頁(yè)面間的切換是否流暢，邏輯是否正確 5）注冊(cè)

--同表單編輯頁(yè)面--用戶名密碼長(zhǎng)度--注冊(cè)后的提示頁(yè)面

--前臺(tái)注冊(cè)頁(yè)面和后臺(tái)的管理頁(yè)面數(shù)據(jù)是否一致--注冊(cè)后，在后臺(tái)管理中頁(yè)面提示 6）登錄

--使用合法的用戶登錄系統(tǒng)。

--系統(tǒng)是否允許多次非法的登陸，是否有次數(shù)限制。--使用已經(jīng)登陸的賬號(hào)登陸系統(tǒng)是否正確處理。--使用禁用的賬號(hào)登陸系統(tǒng)是否正確處理。--用戶名、口令（密碼）錯(cuò)誤或漏填時(shí)能否登陸。--刪除或修改后的用戶，原用戶登陸。

--不輸入用戶口令和用戶、重復(fù)點(diǎn)（確定或取消按鈕）是否允許登陸。--登陸后，頁(yè)面中登陸信息。--頁(yè)面中有注銷按鈕。--登陸超時(shí)的處理。7）注銷

--注銷原模塊，新的模塊系統(tǒng)能否正確處理。--終止注銷能否返回原模塊，原用戶。--注銷原用戶，新用戶系統(tǒng)能否正確處理。

--使用錯(cuò)誤的賬號(hào)、口令、無權(quán)限的被禁用的賬號(hào)進(jìn)行注銷 b.應(yīng)用的前后臺(tái)切換

1)APP切換到后臺(tái)，再回到app，檢查是否停留在上一次操作界面。2)APP切換到后臺(tái)，再回到app，檢查功能及應(yīng)用狀態(tài)是否正常，IOS4和IOS5的版本的處理機(jī)制有的不一樣。

3)app切換到后臺(tái)，再回到前臺(tái)時(shí)，注意程序是否崩潰，功能狀態(tài)是否正常，尤其是對(duì)于從后臺(tái)切換回前臺(tái)數(shù)據(jù)有自動(dòng)更新的時(shí)候。

4)手機(jī)鎖屏解屏后進(jìn)入app注意是否會(huì)崩潰，功能狀態(tài)是否正常，尤其是對(duì)于從后臺(tái)切換回前臺(tái)數(shù)據(jù)有自動(dòng)更新的時(shí)候。

5)當(dāng)App使用過程中有電話進(jìn)來中斷后再切換到app，功能狀態(tài)是否正常 6)當(dāng)殺掉app進(jìn)程后，再開啟app，app能否正常啟動(dòng)。

7)出現(xiàn)必須處理的提示框后，切換到后臺(tái)，再切換回來，檢查提示框是否還存在，有時(shí)候會(huì)出現(xiàn)應(yīng)用自動(dòng)跳過提示框的缺陷。

8)對(duì)于有數(shù)據(jù)交換的頁(yè)面，每個(gè)頁(yè)面都必需要進(jìn)行前后臺(tái)切換、鎖屏的測(cè)試，這種頁(yè)面最容易出現(xiàn)崩潰。c.免登錄

很多應(yīng)用提供免登錄功能，當(dāng)應(yīng)用開啟時(shí)自動(dòng)以上一次登錄的用戶身份來使用app.1)app有免登錄功能時(shí)，需要考慮IOS版本差異。2)考慮無網(wǎng)絡(luò)情況時(shí)能否正常進(jìn)入免登錄狀態(tài)。3)切換用戶登錄后，要校驗(yàn)用戶登錄信息及數(shù)據(jù)內(nèi)容是否相應(yīng)更新，確保原用戶退出。

4)根據(jù)MTOP的現(xiàn)有規(guī)則，一個(gè)帳戶只允許登錄一臺(tái)機(jī)器。所以，需要檢查一個(gè)帳戶登錄多臺(tái)手機(jī)的情況。原手機(jī)里的用戶需要被踢出，給出友好提示。5)app切換到后臺(tái)，再切回前臺(tái)的校驗(yàn) 6)切換到后臺(tái)，再切換回前臺(tái)的測(cè)試

7)密碼更換后，檢查有數(shù)據(jù)交換時(shí)是否進(jìn)行了有效身份的校驗(yàn)

8)支持自動(dòng)登錄的應(yīng)用在進(jìn)行數(shù)據(jù)交換時(shí)，檢查系統(tǒng)是否能自動(dòng)登錄成功并且數(shù)據(jù)操作無誤。

9)檢查用戶主動(dòng)退出登錄后，下次啟動(dòng)app，應(yīng)停留在登錄界面 d.數(shù)據(jù)更新

根據(jù)應(yīng)用的業(yè)務(wù)規(guī)則，以及數(shù)據(jù)更新量的情況，來確定最優(yōu)的數(shù)據(jù)更新方案。1)需要確定哪些地方需要提供手動(dòng)刷新，哪些地方需要自動(dòng)刷新，哪些地方需要手動(dòng)+自動(dòng)刷新。

2)確定哪些地方從后臺(tái)切換回前臺(tái)時(shí)需要進(jìn)行數(shù)據(jù)更新。

3)根據(jù)業(yè)務(wù)、速度及流量的合理分配，確定哪些內(nèi)容需要實(shí)時(shí)更新，哪些需要定時(shí)更新。

4)確定數(shù)據(jù)展示部分的處理邏輯，是每次從服務(wù)端請(qǐng)求，還是有緩存到本地，這樣才能有針對(duì)性的進(jìn)行相應(yīng)測(cè)試。

5)檢查有數(shù)據(jù)交換的地方，均有相應(yīng)的異常處理。e.離線瀏覽

很多應(yīng)用會(huì)支持離線瀏覽，即在本地客戶端會(huì)緩存一部分?jǐn)?shù)據(jù)供用戶查看。1)在無網(wǎng)絡(luò)情況可以瀏覽本地?cái)?shù)據(jù) 2)退出app再開啟app時(shí)能正常瀏覽 3)切換到后臺(tái)再切回前臺(tái)可以正常瀏覽 4)鎖屏后再解屏回到應(yīng)用前臺(tái)可以正常瀏覽 5)在對(duì)服務(wù)端的數(shù)據(jù)有更新時(shí)會(huì)給予離線的相應(yīng)提示 f.App更新

1)當(dāng)客戶端有新版本時(shí)，有更新提示。

2)當(dāng)版本為非強(qiáng)制升級(jí)版時(shí)，用戶可以取消更新，老版本能正常使用。用戶在下次啟動(dòng)app時(shí)，仍能出現(xiàn)更新提示。

3)當(dāng)版本為強(qiáng)制升級(jí)版時(shí)，當(dāng)給出強(qiáng)制更新后用戶沒有做更新時(shí)，退出客戶端。下次啟動(dòng)app時(shí)，仍出現(xiàn)強(qiáng)制升級(jí)提示。

4)當(dāng)客戶端有新版本時(shí)，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新。

5)當(dāng)客戶端有新版本時(shí)，在本地不刪除客戶端的情況下，檢查更新后的客戶端功能是否是新版本。

6)當(dāng)客戶端有新版本時(shí)，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本。如果以上無法更新成功的，也都屬于缺陷。g.定位、照相機(jī)服務(wù)

1)App有用到相機(jī)，定位服務(wù)時(shí)，需要注意系統(tǒng)版本差異

2)有用到定位服務(wù)、照相機(jī)服務(wù)的地方，需要進(jìn)行前后臺(tái)的切換測(cè)試，檢查應(yīng)用是否正常。3)當(dāng)定位服務(wù)沒有開啟時(shí)，使用定位服務(wù)，會(huì)友好性彈出是否允許設(shè)置定位提示。當(dāng)確定允許開啟定位時(shí)，能自動(dòng)跳轉(zhuǎn)到定位設(shè)置中開啟定位服務(wù)。4)測(cè)試定位、照相機(jī)服務(wù)時(shí)，需要采用真機(jī)進(jìn)行測(cè)試。h.時(shí)間測(cè)試

客戶端可以自行設(shè)置手機(jī)的時(shí)區(qū)、時(shí)間，因此需要校驗(yàn)該設(shè)置對(duì)app的影響。--中國(guó)為東8區(qū)，所以當(dāng)手機(jī)設(shè)置的時(shí)間非東8區(qū)時(shí)，查看需要顯示時(shí)間的地方，時(shí)間是否展示正確，應(yīng)用功能是否正常。時(shí)間一般需要根據(jù)服務(wù)器時(shí)間再轉(zhuǎn)換成客戶端對(duì)應(yīng)的時(shí)區(qū)來展示，這樣的用戶體驗(yàn)比較好。比如發(fā)表一篇微博在服務(wù)端記錄的是10：00，此時(shí)，華盛頓時(shí)間為22：00，客戶端去瀏覽時(shí)，如果設(shè)置的是華盛頓時(shí)間,則顯示的發(fā)表時(shí)間即為22:00,當(dāng)時(shí)間設(shè)回東8區(qū)時(shí)間時(shí)，再查看則顯示為10：00。i.PUSH測(cè)試

1)檢查push消息是否按照指定的業(yè)務(wù)規(guī)則發(fā)送 2)檢查不接受推送消息時(shí)，檢查用戶不會(huì)再接收到push.3)如果用戶設(shè)置了免打擾的時(shí)間段，檢查在免打擾時(shí)間段內(nèi)，用戶接收不到PUSH。

在非免打擾時(shí)間段，用戶能正常收到push。

4)當(dāng)push消息是針對(duì)登錄用戶的時(shí)候，需要檢查收到的push與用戶身份是否相符，沒有錯(cuò)誤地將其它人的消息推送過來。一般情況下，只對(duì)手機(jī)上最后一個(gè)登錄用戶進(jìn)行消息推送。

5)測(cè)試push時(shí)，需要采用真機(jī)進(jìn)行測(cè)試。

5.性能測(cè)試 評(píng)估App的時(shí)間和空間特性 ：

1)極限測(cè)試：在各種邊界壓力情況下，如電池、存儲(chǔ)、網(wǎng)速等，驗(yàn)證App是否能正確響應(yīng)。

--內(nèi)存滿時(shí)安裝App--運(yùn)行App時(shí)手機(jī)斷電--運(yùn)行App時(shí)斷掉網(wǎng)絡(luò)

2)響應(yīng)能力測(cè)試：測(cè)試App中的各類操作是否滿足用戶響應(yīng)時(shí)間要求。--App安裝、卸載的響應(yīng)時(shí)間--App各類功能性操作的影響時(shí)間

3)壓力測(cè)試：反復(fù)/長(zhǎng)期操作下、系統(tǒng)資源是否占用異常。--App反復(fù)進(jìn)行安裝卸載，查看系統(tǒng)資源是否正常--其他功能反復(fù)進(jìn)行操作，查看系統(tǒng)資源是否正常

4)性能評(píng)估：評(píng)估典型用戶應(yīng)用場(chǎng)景下，系統(tǒng)資源的使用情況。

5)Benchmark測(cè)試（基線測(cè)試）：與競(jìng)爭(zhēng)產(chǎn)品的Benchmarking, 產(chǎn)品演變對(duì)比測(cè)試等。6.交叉事件測(cè)試

針對(duì)智能終端應(yīng)用的服務(wù)等級(jí)劃分方式及實(shí)時(shí)特性所提出的測(cè)試方法。交叉測(cè)試又叫事件或沖突測(cè)試，是指一個(gè)功能正在執(zhí)行過程中，同時(shí)另外一個(gè)事件或操作對(duì)該過程進(jìn)行干擾的測(cè)試。如；App在前/后臺(tái)運(yùn)行狀態(tài)時(shí)與來電、文件下載、音樂收聽等關(guān)鍵運(yùn)用的交互情況測(cè)試等。交叉事件測(cè)試非常重要，能發(fā)現(xiàn)很多應(yīng)用中潛在的性能問題。

1）多個(gè)App同時(shí)運(yùn)行是否影響正常功能 2）App運(yùn)行時(shí)前/后臺(tái)切換是否影響正常功能 3）App運(yùn)行時(shí)撥打/接聽電話 4）App運(yùn)行時(shí)發(fā)送/接收信息 5）App運(yùn)行時(shí)發(fā)送/收取郵件

6）App運(yùn)行時(shí)切換網(wǎng)絡(luò)（2G、3G、wifi）7）App運(yùn)行時(shí)瀏覽網(wǎng)絡(luò)

8）App運(yùn)行時(shí)使用藍(lán)牙傳送/接收數(shù)據(jù)

9）App運(yùn)行時(shí)使用相機(jī)、計(jì)算器等手機(jī)自帶設(shè)備 7.兼容測(cè)試

主要測(cè)試內(nèi)部和外部兼容性 1）與本地及主流App是否兼容

2）基于開發(fā)環(huán)境和生產(chǎn)環(huán)境的不同，檢驗(yàn)在各種網(wǎng)絡(luò)連接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數(shù)據(jù)和運(yùn)用是否正確

3）與各種設(shè)備是否兼容，若有跨系統(tǒng)支持則需要檢驗(yàn)是否在各系統(tǒng)下，各種行為是否一致

--不同操作系統(tǒng)的兼容性，是否適配--不同手機(jī)屏幕分辨率的兼容性--不同手機(jī)品牌的兼容性 8.回歸測(cè)試

1）Bug修復(fù)后且在新版本發(fā)布后需要進(jìn)行回歸測(cè)試。

2）Bug修復(fù)后的回歸測(cè)試在交付前、要進(jìn)行全量用例的回歸測(cè)試。9.升級(jí)、更新測(cè)試

新版版發(fā)布后，配合不同網(wǎng)絡(luò)環(huán)境的自勱更新提示及下載、安裝、更新、啟勱、運(yùn)行的驗(yàn)證測(cè)試。

1）測(cè)試升級(jí)后的功能是否與需求說明一樣

2）測(cè)試與升級(jí)模塊相關(guān)的模塊的功能是否與需求一致 3）升級(jí)安裝意外情況的測(cè)試（如死機(jī)、斷電、重啟）4）升級(jí)界面的UI測(cè)試 5）不同操作系統(tǒng)間的升級(jí)測(cè)試 10.用戶體驗(yàn)測(cè)試

以主觀的普通消費(fèi)者的角度去感知產(chǎn)品或服務(wù)的舒適、有用、易用、友好親切程度。通過不同個(gè)體、獨(dú)立空間和非經(jīng)驗(yàn)的統(tǒng)計(jì)復(fù)用方式去有效評(píng)價(jià)產(chǎn)品的體驗(yàn)特性提出修改意見提升產(chǎn)品的潛在客戶滿意度。

1）是否有空數(shù)據(jù)界面設(shè)計(jì)，引導(dǎo)用戶去執(zhí)行操作。2）是否濫用用戶引導(dǎo)。

3）是否有不可點(diǎn)擊的效果，如：你的按鈕此時(shí)處于不可用狀態(tài)，那么一定要灰掉，或者拿掉按鈕，否則會(huì)給用戶誤導(dǎo) 4）菜單層次是否太深 5）交互流程分支是否太多 6）相關(guān)的選項(xiàng)是否離得很遠(yuǎn) 7）一次是否載入太多的數(shù)據(jù) 8）界面中按鈕可點(diǎn)擊范圍是否適中

9）標(biāo)簽頁(yè)是否跟內(nèi)容沒有從屬關(guān)系，當(dāng)切換標(biāo)簽的時(shí)候，內(nèi)容跟著切換 10）操作應(yīng)該有主次從屬關(guān)系

11）是否定義Back的邏輯。涉及軟硬件交互時(shí)，Back鍵應(yīng)具體定義 12）是否有橫屏模式的設(shè)計(jì)，應(yīng)用一般需要支持橫屏模式，即自適應(yīng)設(shè)計(jì) 11.硬件環(huán)境測(cè)試

a.手勢(shì)操作測(cè)試

1）手機(jī)開鎖屏對(duì)運(yùn)行中的App的影響 2）切換網(wǎng)絡(luò)對(duì)運(yùn)行中的App的影響 3）運(yùn)行中的App前后臺(tái)切換的影響 4）多個(gè)運(yùn)行中的App的切換 5）App運(yùn)行時(shí)關(guān)機(jī) 6）App運(yùn)行時(shí)重啟系統(tǒng) 7）App運(yùn)行時(shí)充電

8）App運(yùn)行時(shí)kill掉進(jìn)程再打開 b.網(wǎng)絡(luò)環(huán)境

手機(jī)的網(wǎng)絡(luò)目前主要分為2G、3G、wifi。目前2G的網(wǎng)絡(luò)相對(duì)于比較慢，測(cè)試時(shí)尤其要注意此塊的測(cè)試。

1)無網(wǎng)絡(luò)時(shí)，執(zhí)行需要網(wǎng)絡(luò)的操作，給予友好提示，確保程序不出現(xiàn)crash。2)內(nèi)網(wǎng)測(cè)試時(shí)，要注意選擇到外網(wǎng)操作時(shí)的異常情況處理。

3)在網(wǎng)絡(luò)信號(hào)不好時(shí)，檢查功能狀態(tài)是否正常，確保不因提交數(shù)據(jù)失敗而造成crash。

4)在網(wǎng)絡(luò)信號(hào)不好時(shí)，檢查數(shù)據(jù)是否會(huì)一直處于提交中的狀態(tài)，有無超時(shí)限制。如遇數(shù)據(jù)交換失敗時(shí)要給予提示。5)在網(wǎng)絡(luò)信號(hào)不好時(shí)，執(zhí)行操作后，在回調(diào)沒有完成的情況下，退出本頁(yè)面或者執(zhí)行其他操作的情況，有無異常情況。此問題也會(huì)經(jīng)常出現(xiàn)程序crash。c.服務(wù)器宕機(jī)或出現(xiàn)404、502等情況下的測(cè)試

后臺(tái)服務(wù)牽涉到DNS、空間服務(wù)商的情況下會(huì)影響其穩(wěn)定性，如：當(dāng)出現(xiàn)域名解析故障時(shí)，你對(duì)后臺(tái)API的請(qǐng)求很可能就會(huì)出現(xiàn)404錯(cuò)誤，拋出異常。這時(shí)需要對(duì)異常進(jìn)行正確的處理，否則可能會(huì)導(dǎo)致程序不能正常工作。

12.接口測(cè)試

服務(wù)端一般會(huì)提供JSON格式的數(shù)據(jù)給客戶端，所以我們?cè)诜?wù)端需要進(jìn)行接口測(cè)試，確保服務(wù)端提供的接口并轉(zhuǎn)換的JSON內(nèi)容正確，對(duì)分支、異常流有相應(yīng)的返回值。此塊測(cè)試可以采用itest框架進(jìn)行測(cè)試。最方便的是采用httpclient進(jìn)行接口測(cè)試。進(jìn)行服務(wù)端測(cè)試時(shí)，需要開發(fā)提供一份接口文檔。13.客戶端數(shù)據(jù)庫(kù)測(cè)試

1）一般的增、刪、改、查測(cè)試。

2）當(dāng)表不存在時(shí)是否能自動(dòng)創(chuàng)建，當(dāng)數(shù)據(jù)庫(kù)表被刪除后能否再自建，數(shù)據(jù)是否還能自動(dòng)從服務(wù)端中獲取回來并保存。

3）在業(yè)務(wù)需要從服務(wù)端取回?cái)?shù)據(jù)保存到客戶端的時(shí)候，客戶端能否將數(shù)據(jù)保存到本地。

4）當(dāng)業(yè)務(wù)需要從客戶端取數(shù)據(jù)時(shí)，檢查客戶端數(shù)據(jù)存在時(shí)，app數(shù)據(jù)是否能自動(dòng)從客戶端數(shù)據(jù)中取出，還是仍然會(huì)從服務(wù)器端獲??？檢查客戶端數(shù)據(jù)不存在時(shí)，app數(shù)據(jù)能否自動(dòng)從服務(wù)器端獲取到并保存到客戶端

5）當(dāng)業(yè)務(wù)對(duì)數(shù)據(jù)進(jìn)行了修改、刪除后，客戶端和服務(wù)端是否會(huì)有相應(yīng)的更新。