相關(guān)文章：

《再說說APP測試設(shè)計(jì)-1》
《再說APP測試設(shè)計(jì)-2》
《關(guān)于ad hoc test》
《干了這碗蛋炒飯 繼續(xù)APP性能提升-1》
《突破測試的墨菲定律 -- 有感于一次UAT組織》

【前言】

• 之前的測試用例規(guī)范，很多人都做過一些分享了，內(nèi)容大多集中在測試用例的分析方法（如等價(jià)類劃分）、書寫格式以及測試類型對(duì)應(yīng)的用例選取范圍（如冒煙測試對(duì)應(yīng)的用例如何選?。┍酒矊⑸婕斑@幾個(gè)方面的內(nèi)容，但不做特別深層的探討，因?yàn)檫@部分作為經(jīng)典的內(nèi)容，已經(jīng)有非常成型的內(nèi)容產(chǎn)出，且傳承良久。
• 這里將針對(duì)智能手機(jī)以及平板電腦的特性，結(jié)合在過完幾年的移動(dòng)端測試經(jīng)驗(yàn)，主要討論針對(duì)移動(dòng)設(shè)備如何進(jìn)行用例的組織，如何用于執(zhí)行，如何結(jié)合各種測試方法手段，如何把握各種測試深度以及用例的選取。

1. 測試用例分析常用方法

從理論上講，手機(jī)軟件規(guī)模越大，模塊間的關(guān)系越復(fù)雜，組合的情況越多，測試用例數(shù)目占的比例也就越大，因而總是很難設(shè)計(jì)出“足夠”的測試用例。

雖然理論上缺陷空間（測試空間上所有可能發(fā)生的缺陷構(gòu)成的集合就是缺陷空間）可以接近無限大，但實(shí)際情況中存在的缺陷只是缺陷空間的一個(gè)很小的子集。測試中最重要的是要找到已經(jīng)存在的缺陷，但在沒有進(jìn)行測試前，手機(jī)軟件中存在多少缺陷卻是不知道的。從理論上講，測試是不能窮盡的，就意味著不存在一種方法能將所有的缺陷都所以找出來，找到缺陷的問題注定是一個(gè)概率問題，將那些發(fā)生概率較大的缺陷找出來就成了測試的主要任務(wù)。測試用例是為特定的目的而設(shè)計(jì)的一組測試輸入、執(zhí)行條件和預(yù)期的結(jié)果。測試用例是執(zhí)行的最小實(shí)體。簡單地說，測試用例就是設(shè)計(jì)一個(gè)場景，使測試程序在這種場景下運(yùn)行并且達(dá)到程序所設(shè)計(jì)的執(zhí)行結(jié)果。設(shè)計(jì)測試用例首先要考慮以下幾個(gè)問題：

• 為什么要設(shè)計(jì)測試用例？
• 誰來寫測試用例？
• 這些寫測試用例的人的測試技術(shù)如何？
• 以及對(duì)被測試產(chǎn)品了解有多深入？
• 測試用例寫給誰看，多少人將使用測試用例文檔？
• 分配給編寫測試用例的時(shí)間是多長？要安排幾個(gè)人來寫？
• 怎么在測試用例的成本、質(zhì)量和效率方面達(dá)到平衡？

目前的手機(jī)市場對(duì)于新推出的功能和應(yīng)用程序有著迫切的需要，使得產(chǎn)品周期非常短；然而只有回答了這些問題，才能確定測試用例的具體寫作方法和表現(xiàn)形式。一般而言，手機(jī)軟件測試項(xiàng)目中分配寫測試用例的時(shí)間并不長，而且提供的文檔也不全面，所以寫測試用例要符合測試部門的當(dāng)前現(xiàn)狀和項(xiàng)目的測試特點(diǎn)。

對(duì)于測試設(shè)計(jì)工程師來說，設(shè)計(jì)測試用例需要考慮以下幾個(gè)方面：

• 測試用例設(shè)計(jì)必須考慮有效：容易發(fā)現(xiàn)并呈現(xiàn)錯(cuò)誤；
• 測試用例設(shè)計(jì)必須覆蓋全面又不冗余：數(shù)量上不應(yīng)有重復(fù)的、多余的用例，對(duì)軟件規(guī)格說明書和設(shè)計(jì)功能點(diǎn)有全面的覆蓋，不僅包括功能測試用例，還包括性能測試用例，外場測試、易用性等測試用例；
• 測試用例設(shè)計(jì)必須明確粒度和測試分類的程度：粒度越細(xì)，測試成本就越高，測試周期就越長；分類越多，測試成本相應(yīng)增加，測試周期就越長；
• 測試用例設(shè)計(jì)完成后必須經(jīng)過評(píng)審：以幫助進(jìn)一步補(bǔ)充用例，提高測試覆蓋率，提高用例質(zhì)量。 對(duì)于測試執(zhí)行工程師來說，測試用例的內(nèi)容應(yīng)包括以下幾個(gè)方面：
• 測試用例的測試目標(biāo)；
• 測試用例的被測功能點(diǎn)描述；
• 測試用例的測試運(yùn)行環(huán)境；
• 測試用例的執(zhí)行方法（包括測試步驟，輸入測試數(shù)據(jù)或測試腳本）；
• 測試期望的結(jié)果；
• 執(zhí)行測試的實(shí)際結(jié)果；
• 其他輔助說明。

一個(gè)好的測試用例是指可能找到迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測試，由此可見，測試用例設(shè)計(jì)工作在整個(gè)測試過程中占有十分重要的地位，所以我們不能只憑借一些主觀或直觀的想法來設(shè)計(jì)測試用例，而應(yīng)該要以一些比較成熟的測試用例設(shè)計(jì)方法為指導(dǎo)，再加上設(shè)計(jì)人員個(gè)人的經(jīng)驗(yàn)積累來設(shè)計(jì)測試用例。 下面我們將由一般到特殊，先從經(jīng)典的軟件測試分析方法開始討論。

1.1 等價(jià)類劃分

如果把所有可能的輸入數(shù)據(jù)分為有效等價(jià)類和無效等價(jià)類兩種，那么可以做出這樣的合理假定：如果等價(jià)類中的一個(gè)輸入數(shù)據(jù)能發(fā)現(xiàn)一個(gè)缺陷，那么等價(jià)類中其他輸入數(shù)據(jù)也能發(fā)現(xiàn)同一個(gè)缺陷；反之，如果一個(gè)輸入數(shù)據(jù)不能發(fā)現(xiàn)某個(gè)錯(cuò)誤，那么等價(jià)類中其他輸入數(shù)據(jù)也不能發(fā)現(xiàn)這一錯(cuò)誤。

有效等價(jià)類是指對(duì)于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。利用有效等價(jià)類可檢驗(yàn)程序是否實(shí)現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能。

與有效等價(jià)類恰巧相反，無效等價(jià)類是指對(duì)程序的規(guī)格說明是不合理的或無意義的輸入數(shù)據(jù)所構(gòu)成的集合。對(duì)于具體的問題，無效等價(jià)類至少應(yīng)有一個(gè)，也可能有多個(gè)。

等價(jià)類分析法不但可以針對(duì)輸入數(shù)據(jù)，而且可以針對(duì)輸出數(shù)據(jù)進(jìn)行劃分。總之，他們發(fā)現(xiàn)缺陷的概率是等效的。

等價(jià)類劃分方法設(shè)計(jì)用例的原則：

如果輸入條件規(guī)定了取值范圍，或者值的個(gè)數(shù)，則可以確定一個(gè)有效等價(jià)類和兩個(gè)無效等價(jià)類；

• 如果輸入條件規(guī)定了輸入值的集合，或者是規(guī)定了“必須如何”的條件，這時(shí)可以確立一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類；
• 如果輸入條件是一個(gè)布爾量，則可以確立一個(gè)有效等價(jià)類和一個(gè)無效等價(jià)類；
• 如果規(guī)定了輸入數(shù)據(jù)的一組值，則程序要對(duì)每一個(gè)輸入值分別進(jìn)行處理；這時(shí)要對(duì)每一個(gè)規(guī)定的輸入值確立一個(gè)等價(jià)類，并且對(duì)于這組值之外的所有值也都確立一個(gè)等價(jià)類；
• 如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個(gè)有效等價(jià)類（即遵守規(guī)則的數(shù)據(jù)）和若干無效等價(jià)類（從不同角度違反規(guī)則的數(shù)據(jù)）；
• 如果已劃分的等價(jià)類中的各元素在程序中的處理方式不同，則應(yīng)進(jìn)一步劃分成更小的等價(jià)類。范例，假設(shè)需求描述如下圖：

Paste_Image.png

則等價(jià)類劃分結(jié)果如下：

Paste_Image.png

1.2邊界值分析

邊界值分析法基本概念

邊界值分析法就是對(duì)輸入或輸出的邊界值進(jìn)行測試的一種黑盒測試方法。通常邊界值分析法是作為對(duì)等價(jià)類劃分法的補(bǔ)充，這種情況下，其測試用例來自等價(jià)類的邊界。

長期的測試工作經(jīng)驗(yàn)告訴我們，大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生在輸入輸出范圍的內(nèi)部。因此針對(duì)各種邊界情況設(shè)計(jì)測試用例，可以查出更多的錯(cuò)誤。說明程序在邊界值上出現(xiàn)錯(cuò)誤概率的可能性大。

邊界值分析法設(shè)計(jì)用例的原則

通常邊界值分析法是作為對(duì)等價(jià)類劃分法的補(bǔ)充，其測試用例來自等價(jià)類邊界，每個(gè)邊界都要作為測試條件。因此，邊界值分析不僅考慮輸入條件，還要考慮輸出產(chǎn)生的測試情況。邊界值分析法設(shè)計(jì)用例的原則如下：

• 如果輸入條件規(guī)定了值的范圍，則應(yīng)該取剛剛達(dá)到這個(gè)范圍的邊界值，及剛剛超越這個(gè)范圍邊界的值作為測試數(shù)據(jù)；
• 如果輸入條件規(guī)定了值的個(gè)數(shù)，則用最大個(gè)數(shù)、最小個(gè)數(shù)、比最小個(gè)數(shù)少一的數(shù)、比最大個(gè)數(shù)多的數(shù)作為測試數(shù)據(jù)；
• 根據(jù)軟件規(guī)格說明書的每個(gè)輸出條件，應(yīng)用上述的原則（1）和原則（2）；
• 如果軟件程序規(guī)格說明書所給出的輸入域或輸出域是有序集合，則應(yīng)該選取集合的第一個(gè)元素和最后一個(gè)元素作為測試數(shù)據(jù)；
• 如果程序中采用了一個(gè)內(nèi)部數(shù)據(jù)結(jié)構(gòu)，則應(yīng)當(dāng)選擇這個(gè)內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界上的值作為測試數(shù)據(jù)；
• 分析軟件規(guī)格說明書，找出其他可能的邊界條件。

按照上述方法，可以做到更好地使用邊界值對(duì)用例進(jìn)行選擇，更容易發(fā)現(xiàn)缺陷。在實(shí)際測試中可以按照這樣的分類思路進(jìn)行擴(kuò)展。常用的邊界值舉例：

Paste_Image.png

1.3 因果分析

等價(jià)類劃分和邊界值分析方法，都是著重考慮輸入條件，而未考慮輸入條件之間的聯(lián)系。如果在測試時(shí)必須考慮輸入條件的各種組合則可能又會(huì)產(chǎn)生一些新的情況。檢查輸入條件的組合不是容易的事情，即使把所有輸入條件都劃分成等價(jià)類，它們之間的組合情況也相當(dāng)多。

如果沒有系統(tǒng)性的方法來選擇輸入條件的一個(gè)子集，可能導(dǎo)致低效率的測試。因此，必須考慮使用一種適合于描述這樣一種情況的測試用例，對(duì)于多種條件的組合相應(yīng)產(chǎn)生多個(gè)動(dòng)作的形式，這就用到了因果圖——實(shí)際上是一個(gè)數(shù)字邏輯電路。因果圖是高效的方法，同時(shí)也可檢查規(guī)范中的二義性和不完整性。因果圖方法最終生成的是判定表，它適合于檢查程序輸入條件的各種組合情況。

因果圖法的步驟：

• 1、將規(guī)范分成若干個(gè)可工作的部分（對(duì)于大的規(guī)范來說因果圖難以使用）。
• 2、標(biāo)識(shí)出規(guī)范中的原因與結(jié)果：

原因是輸入條件和輸入條件的等價(jià)類；
結(jié)果是輸出條件或系統(tǒng)變換；
每個(gè)原因、結(jié)果都標(biāo)上一個(gè)編號(hào)。

• 3、分析規(guī)范的語義內(nèi)容，將其轉(zhuǎn)換為連接原因和結(jié)果的布爾圖，即因果圖。
• 4、由于語法和環(huán)境的限制，存在不可能的原因和結(jié)果的組合，對(duì)此用約束條件在因果圖上加以注釋。
• 5、有條理地跟蹤因果圖中的狀態(tài)條件，將因果圖轉(zhuǎn)換為有限項(xiàng)的判定表，表中每一列代表一個(gè)測試用例。
• 6、將判定表中的每一列形成一個(gè)測試用例。
  范例：有一個(gè)處理單價(jià)為5角錢的飲料的自動(dòng)售貨機(jī)軟件測試用例的設(shè)計(jì)。其規(guī)格說明如下：若投入5角 錢或1元錢的硬幣，押下〖橙汁〗或〖啤酒〗的按鈕，則相應(yīng)的飲料就送出來。若售貨機(jī)沒有零錢找，則一個(gè)顯示〖零錢找完〗的紅燈亮，這時(shí)在投入1元硬幣并押 下按鈕后，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示〖零錢找完〗的紅燈滅，在送出飲料的同時(shí)退還5角硬幣。
• 分析這一段說明，列出原因和結(jié)果

原因：

1.售貨機(jī)有零錢找
2.投入1元硬幣
3.投入5角硬幣 
4.押下橙汁按鈕
5.押下啤酒按鈕 

結(jié)果：

21.售貨機(jī)〖零錢找完〗燈亮    
22.退還1元硬幣
23.退還5角硬幣              
24.送出橙汁飲料
25.送出啤酒飲料

• 畫出因果圖，如圖所示。所有原因結(jié)點(diǎn)列在左邊，所有結(jié)果結(jié)點(diǎn)列在右邊。建立中間結(jié)點(diǎn)，表示處理的中間狀態(tài)。中間結(jié)點(diǎn)：

11. 投入1元硬幣且押下飲料按鈕
12. 押下〖橙汁〗或〖啤酒〗的按鈕
13. 應(yīng)當(dāng)找5角零錢并且售貨機(jī)有零錢找
14. 錢已付清

Paste_Image.png

• 轉(zhuǎn)換成判定表：

  
  
  Paste_Image.png

• 在判定表中，陰影部分表示因違反約束條件的不可能出現(xiàn)的情況，刪去。第16列與第32列因什么動(dòng)作也沒做，也刪去。最后可根據(jù)剩下的16列作為確定測試用例的依據(jù)。

1.4 判定表驅(qū)動(dòng)法

因果圖方法中已經(jīng)用到了判定表（Decision Table），它是分析和表達(dá)多邏輯條件下執(zhí)行不同操作的情況下的工具。在程序設(shè)計(jì)發(fā)展的初期,判定表就已被當(dāng)做編寫程序的輔助工具了。由于判定表測試嚴(yán) 格，能夠?qū)?fù)雜的邏輯關(guān)系和多種條件組合的情況表達(dá)得既具體又明確，針對(duì)不同的邏輯條件組合值，分別執(zhí)行不同的操作，因此，使用判定表能夠設(shè)計(jì)出完整的測 試用例集合。判定表是一種針對(duì)存在條件、動(dòng)作關(guān)系或者因果關(guān)系的特性測試的用例設(shè)計(jì)方法。

Paste_Image.png

• 判定表的組成
  判定表通常由4個(gè)部分組成，如圖3-6所示。
  1）條件樁（Condition Stub）：列出了問題的所有條件，列出條件的次序沒有約束。
  2）動(dòng)作樁（Action Stub）：列出問題規(guī)定可能采取的操作，這些操作的排列順序無關(guān)緊要。
  3）條件項(xiàng)（Condition Entry）：列出條件樁給出的條件并列出所有可能的取值。針對(duì)條件樁的條件和條件項(xiàng)的取值，判斷在整個(gè)程序模塊中的所有可能的情況下其結(jié)果的真假值。
  4）動(dòng)作項(xiàng)（Action Entry）：列出在條件項(xiàng)的各種取值情況下應(yīng)該采取的動(dòng)作。
• 判定表的建立步驟
  判定表的建立步驟如下：
  1）確定規(guī)則的個(gè)數(shù)，例如，有n個(gè)條件，那么決策表中就有2n個(gè)規(guī)則（每個(gè)條件取真、假值）。
  2）列出所有的條件樁和動(dòng)作樁。
  3）填入條件項(xiàng)。
  4）填入動(dòng)作項(xiàng)，得到初始判定表。
  5）簡化判定表，合并相似規(guī)則。

1.5 正交法

主要用于解決組合爆炸問題。通過使用正交分析的收隊(duì)，對(duì)多條件多因素的邏輯進(jìn)行處理，組合分析出一些典型用例，它們能夠覆蓋大多數(shù)的用例場景，提高測試效率。
以手機(jī)瀏覽器設(shè)置功能為例，如下圖：

Paste_Image.png

因子狀態(tài)表如下：

1.6 場景法

從用戶的角度來描述系統(tǒng)的運(yùn)行行為，完全站在用戶的視角來描述用戶與系統(tǒng)的交互。在場景法中，測試流程是軟件功能按照正確的事件流實(shí)現(xiàn)的一條正確流程，那么我們把這個(gè)成為該軟件的基本流；而凡是出現(xiàn)故障或缺陷的過程，就用備選流加以標(biāo)注，這樣的話，備選流就可以是從基本流來的，或是由備選流中引出的。

以手機(jī)瀏覽器登錄為例。通過場景法可以設(shè)計(jì)用例如下：

1.7 功能圖法

• 功能圖法簡介：
  功能圖方法其實(shí)是一種灰盒測試(因其兼有黑盒和白盒測試，所以稱為灰盒測度比較體貼)用例設(shè)計(jì)方法；通常情況一個(gè)程序的功能說明通常由動(dòng)態(tài)說明和靜態(tài)說明組成.動(dòng)態(tài)說明描述了輸入數(shù)據(jù)的次序或轉(zhuǎn)移的次序.靜態(tài)說明描述了輸入條件與輸出條件之間的對(duì)應(yīng)關(guān)系.用功能圖形象地表示程序的功能說明，并機(jī)械地生成功能圖的測試用例
• 程序功能說明的組成
  動(dòng)態(tài)說明：描述輸入數(shù)據(jù)的次序或轉(zhuǎn)移次序
  靜態(tài)說明：描述輸入條件和輸出條件之間的對(duì)應(yīng)關(guān)系
• 功能圖：
  由狀態(tài)遷移圖和布爾函數(shù)組成，狀態(tài)遷移圖用狀態(tài)和遷移來表示。一個(gè)狀態(tài)指出數(shù)據(jù)輸入的位置（或時(shí)間），一個(gè)遷移指明狀態(tài)的改變，同時(shí)要依靠判定表或因果圖表示的邏輯功能
• 功能圖法概述
  用功能圖形象地表示程序的功能說明，并機(jī)械地生成功能圖的測試用例,功能圖模型由狀態(tài)遷移圖和邏輯功能模型構(gòu)成
• 狀態(tài)遷移圖：
  用于表示輸入數(shù)據(jù)序列以及相應(yīng)的輸出數(shù)據(jù)；由輸入數(shù)據(jù)和當(dāng)前狀態(tài)決定輸出數(shù)據(jù)和后續(xù)狀態(tài)
• 邏輯功能模型：
  用于表示在狀態(tài)中輸入條件和輸出條件的對(duì)應(yīng)關(guān)系。由輸入數(shù)據(jù)決定輸出數(shù)據(jù)。此模型只適用于描述靜態(tài)說明,功能圖測試用例由測試中經(jīng)過的一系列狀態(tài)和在每個(gè)狀態(tài)中必須依靠輸入/輸出數(shù)據(jù)滿中的一對(duì)條件組成
• 功能圖法測試用例生成方法：
  從狀態(tài)遷移圖中選取測試用例，用節(jié)點(diǎn)代替狀態(tài)，用弧線代替遷移，狀態(tài)圖就可轉(zhuǎn)化成一個(gè)程序的控制流程圖形式
• 測試用例生成規(guī)則
  為了把狀態(tài)遷移（測試路徑）的測試用例與邏輯模型（局部測試用例）的測試用例組合起來，從功能圖生成實(shí)用的測試用例，在一個(gè)結(jié)構(gòu)化的狀態(tài)遷移（SST）中，定義3種形式的循環(huán)：順序，選擇和重復(fù)
• 功能圖生成測試用例步驟
  1 生成局部測試用例：在每個(gè)狀態(tài)中，從因果圖生成局部測試用例。局部測試用例由原因值（輸入數(shù)據(jù)）組合與對(duì)應(yīng)的結(jié)果值（輸出數(shù)據(jù)或狀態(tài)）構(gòu)成
  測試路徑生成：利用上面的規(guī)則生成從初始狀態(tài)到最后狀態(tài)的測試路徑
  2 測試用例合成：合成測試路徑與功能圖中每個(gè)狀態(tài)的局部測試用例。結(jié)果是初始狀態(tài)到最后狀態(tài)的一個(gè)狀態(tài)序列，以及每個(gè)狀態(tài)中輸入數(shù)據(jù)與對(duì)應(yīng)輸出數(shù)據(jù)的組合。
  3 測試用例的合成算法：采用條件構(gòu)造樹.

1.8 錯(cuò)誤推測法

錯(cuò)誤推測法是基于以往的經(jīng)驗(yàn)和直覺，參照以往的軟件系統(tǒng)出現(xiàn)的錯(cuò)誤，推測程序中所有可能存在的各種缺陷和錯(cuò)誤，從而有針對(duì)性地設(shè)計(jì)測試用例。
錯(cuò)誤推測法的基本思路是：列舉出程序中所有可能的錯(cuò)誤和容易發(fā)生錯(cuò)誤的特殊情況，根據(jù)可能出現(xiàn)的錯(cuò)誤情況選擇測試用例。
例如：

1）單元測試中列出許多在模塊中常見的錯(cuò)誤、以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯(cuò)誤等。
2）輸入數(shù)據(jù)為0或字符為空。
3）各種情況在產(chǎn)品說明中常常被忽視，也可能被程序員遺忘，但是在實(shí)際使用中卻經(jīng)常發(fā)生。測試人員要站在用戶的角度，考慮他們要輸入的信息，而不管這些信息看起來是合法的輸入還是非法的輸入。

2. 2 測試用例組織結(jié)構(gòu)

建議的用例組織方式為，以功能為拆分，通過大功能，小功能，功能點(diǎn)，樹狀向下分割，在功能點(diǎn)末端，展開相應(yīng)的測試類型。

Paste_Image.png

Paste_Image.png

示例：

Paste_Image.png

2.1 Basic – 基本功能測試

即MRD到case的轉(zhuǎn)譯

2.2 Boundary – 邊界分析測試

在基本功能的基礎(chǔ)上，開始考慮各種輸入輸出的影響。一般的，基本功能容易在邊界附近出問題。主要采用等價(jià)類劃分方法，邊界值分析方法。用例組織上，可以梳理已經(jīng)產(chǎn)出的基本功能草圖，確定哪些部分存在邊界問題。并構(gòu)造測試用例，執(zhí)行測試工作。

? 邊界類型數(shù)值大小 ，輸入的數(shù)值的范圍
? 字串長短，Null-max-max+1
? 內(nèi)容有無
? 支持與否，（保留字符，特殊字符，計(jì)劃外字符。

在此非常鄭重的提示各位新同學(xué)，寫測試用例時(shí)，很多都能考慮到邊界值分析，但是一般都只是分析輸入，而對(duì)于我們來說bug真正容易出現(xiàn)的地方是輸出。這里是輸出是廣義的，任何被我們能獲得的信息都是客戶端的輸出，比如字符超長，內(nèi)容超長，圖片超大等等。

Memory – 存儲(chǔ)測試

主要測試涉及存儲(chǔ)空間讀寫的部分。最大的問題還是memory leak。用例組織上，主要考慮哪些部分容易發(fā)生memory的問題。特別是移動(dòng)客戶端容易出現(xiàn)的問題：

? 比如旋轉(zhuǎn)屏幕—響應(yīng)G sensor，畫面需要重新載入，重新載入前的頁面可能會(huì)發(fā)生內(nèi)存無法釋放的問題。移動(dòng)客戶端相對(duì)特有的。
? 連續(xù)加載頁面
? 開多個(gè)窗口—比較典型的，如瀏覽器
? 應(yīng)用多次的互相調(diào)用—應(yīng)用之間的相互調(diào)用，調(diào)用傳遞之間，可能存在問題，另外要特別注意“重入”；所謂重入，是指一個(gè)應(yīng)用A叫起了應(yīng)用B，但是應(yīng)用B又可以再次叫起應(yīng)用A，如message編輯時(shí)插入圖片可以叫起camera，拍攝之后，camera可以不直接返回message編輯器窗口，而是通過點(diǎn)擊分享-message，重入message編輯器，由此產(chǎn)生循環(huán)的棧疊加，也容易發(fā)生內(nèi)存問題。
? 多線程下載

Performance – 響應(yīng)速度，資源占用

考慮方式參考memory的測試思路，注意在判斷是否合格或者滿足預(yù)期上，要參考競品的表現(xiàn)

? 相同移動(dòng)客戶端不同應(yīng)用；在同一個(gè)移動(dòng)客戶端上，被測試應(yīng)用和benchmark做比對(duì)，看選取的核心數(shù)據(jù)差異性
? 相同應(yīng)用不同移動(dòng)客戶端；在不同的移動(dòng)客戶端上，被測試應(yīng)用分別安裝，檢驗(yàn)被測試應(yīng)用，在不同平臺(tái)環(huán)境中的表現(xiàn)能力。

Stress – 壓力測試

可以簡單理解為，在基本功能上的提升負(fù)載，速度，吞吐量等性能指標(biāo)。一般的，移動(dòng)客戶端通過monkey之類的測試工具加以覆蓋，以及錄制回放工具之類的測試來實(shí)現(xiàn)壓力檢驗(yàn)。

Capability – 兼容性測試

移動(dòng)客戶端常見的兼容性測試測項(xiàng)

? 網(wǎng)絡(luò)兼容性測試（各種運(yùn)行商，各種接入點(diǎn)）
? 平臺(tái)兼容性測試 （如android，從cupcake到donut到éclair到froyo到gingerbread到honeycomb）
? 分辨率兼容性測試 （各種不同的分辨率）

其他可能會(huì)涉及移動(dòng)客戶端兼容性測試測項(xiàng)

? 操作系統(tǒng)兼容性測試 （如實(shí)現(xiàn)一個(gè)手機(jī)到pc的通信工具，則各種pc操作系統(tǒng)需要被檢驗(yàn)其兼容性）
? 藍(lán)牙設(shè)備兼容性測試 （如果是一款使用藍(lán)牙的應(yīng)用）
? 存儲(chǔ)卡兼容性測試（比如文件管理器）

Interrupt – 中斷功能測試

別的應(yīng)用對(duì)當(dāng)前應(yīng)用的中斷，體現(xiàn)應(yīng)用的被動(dòng)型

Interaction – 交互功能測試

應(yīng)用主動(dòng)叫起其他的應(yīng)用，體現(xiàn)應(yīng)用的主動(dòng)性，比如share via message，比如叫起camera，該部分詳細(xì)的內(nèi)容，如何開展交互和中斷測試，將另行分享。

3. 測試用例書寫方法

測試用例的代表性：能夠代表并覆蓋各種合理的和不合理的、合法的和非法的、邊界的和越界的以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等。
測試用例的可執(zhí)行特點(diǎn)：在測試前提符合的情況下，依照測試步驟，每一個(gè)測試用例都能夠順利地使程序運(yùn)行，同時(shí)呈現(xiàn)相應(yīng)的期望結(jié)果。
測試結(jié)果的可判定性：即測試執(zhí)行結(jié)果的正確性是可判定的，每一個(gè)測試用例都應(yīng)有相應(yīng)的期望結(jié)果。
測試結(jié)果的可再現(xiàn)性：即對(duì)同樣的測試用例，系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是相同的。

3.1 用例書寫技巧

正如上面提到的用例的四個(gè)特點(diǎn)，書寫測試用例目的執(zhí)行測試，一方面我們要提高測試用例的全面性，另外一方面，我們要考慮測試用例的可讀性，即，用例很容易的被其他執(zhí)行人員所掌握，執(zhí)行結(jié)果和書寫人執(zhí)行基本一致。舉個(gè)例子，

一個(gè)人A去找C同學(xué)，發(fā)現(xiàn)C同學(xué)不在，問B同學(xué)說：B同學(xué)，怎么不見C同學(xué)，
B同學(xué)頭也不抬：C已經(jīng)不在人shi了
A同學(xué)大呼：我是聽說過他要離開人shi，沒想到走的這么快
B：雖然他不方便上來找你，但是你可以下去找他呀

你看完這段對(duì)話的第一反應(yīng)是什么，可能很多人的第一反應(yīng)是，C同學(xué)已經(jīng)撒手人寰了。事實(shí)不然，C同學(xué)之前和B同學(xué)都在樓上人事部工作，后來人事調(diào)動(dòng)，C同學(xué)去了樓下行政部。A來找C的時(shí)候發(fā)現(xiàn)他已經(jīng)走了，而C工作比較忙，沒有時(shí)間上樓來見A。

作為測試用例的撰寫，我們也要注意這些內(nèi)容，避免想當(dāng)然，避免條件的遺漏。特別是初始的條件。

用例撰寫一個(gè)容易苦惱的地方就是路徑可能過長，基于經(jīng)驗(yàn)，我們一般建議單條case的步長不超過五步，功能點(diǎn)僅涵蓋一個(gè)。

比如一個(gè)音樂播放器，進(jìn)入文件管理器相關(guān)的功能，使文件為空，添加一個(gè)曲目，然后查看后續(xù)的功能。這三個(gè)步驟，但是這三個(gè)步驟，可以做拓展，怎么使文件為空，我們可以拔掉SD換一張空卡回來，我們可以格式化SD，我們可以通過文件管理器刪除全部，我們可以通過播放器刪除全部……，第二步如何添加一個(gè)曲目，我們可以通過播放器下載一個(gè)，可以通過瀏覽器下載一個(gè)，可以通過藍(lán)牙傳輸一個(gè)，可以通過錄音機(jī)這個(gè)應(yīng)用錄制一個(gè)……，第三步對(duì)存在但個(gè)曲目的操作，是播放，刪除，修改，查看詳情……，如果按照路徑遍歷，單純這幾個(gè)點(diǎn)，就可以拓展為4X4X4，64條用例。但是事實(shí)上，我們并不需要這么做，首先我們會(huì)分析依賴關(guān)系，對(duì)于前一步驟各類操作產(chǎn)生的結(jié)果對(duì)下一步驟的影響一致，則用例可以被切割，統(tǒng)一成前一類步驟的一個(gè)結(jié)果為后一步驟的初始條件。所以這個(gè)功能會(huì)被拆分為三組測試用例，大約十二個(gè)。讓文件管理器變空的若干條測試用例，然后以文件管理器為空做前提，看接收文件的刷新顯示，第三條查看僅有一個(gè)曲目時(shí)的基本功能。

3.2 如何實(shí)現(xiàn)從MRD到測試用例

下圖給出的是按照MRD，我們分析需求—轉(zhuǎn)換用例---評(píng)審用例—最終生成完整用例的一個(gè)過程，下圖體現(xiàn)的主要是初稿的撰寫流程，突出的是，QA-PM-RD之間在基于測試用例為主線的協(xié)作關(guān)系。下面我們將從MRD出發(fā)，以點(diǎn)連線，說明下測試用例的撰寫過程。

首先一個(gè)問題，什么是MRD？市場需求文檔，（英文全稱 Market Requirement Document，MRD）。該文檔在產(chǎn)品項(xiàng)目過程中屬于“過程性”文檔。MRD文檔是產(chǎn)品項(xiàng)目由“準(zhǔn)備”階段進(jìn)入到“實(shí)施”階段的第一文檔，其作用就是“對(duì)年度產(chǎn)品中規(guī)劃的某個(gè)產(chǎn)品進(jìn)行市場層面的說明”，這個(gè)文檔的質(zhì)量好壞直接影響到產(chǎn)品項(xiàng)目的開展，并直接影響到公司產(chǎn)品戰(zhàn)略意圖的實(shí)現(xiàn)。對(duì)MRD的認(rèn)識(shí)，你覺得準(zhǔn)確么？把MRD和PRD混為一談，MRD是PRD的基礎(chǔ)，PRD是MRD在產(chǎn)品功能上的具體化。產(chǎn)品需求文檔(Product Requirement Document，PRD)的英文簡稱。是將商業(yè)需求文檔（BRD）和市場需求文檔（MRD）用更加專業(yè)的語言進(jìn)行描述。

通過前面一段的簡單分析，我們在項(xiàng)目立項(xiàng)的時(shí)候，其實(shí)就應(yīng)該明晰MRD對(duì)我們的作用，以及我們要做的功課有哪些，下面我們就這幾個(gè)部分做一下闡述：

基本需求這里是指，明確的以viso，腦圖，文字明確下來的需求。這個(gè)概念比較好理解，因?yàn)檫@些內(nèi)容會(huì)相對(duì)直白的表達(dá)出來，對(duì)于這部分，我們需要做的是，以評(píng)審討論的方式了解相關(guān)的需求是否正如你對(duì)字面的理解那樣。因?yàn)槲淖值谋磉_(dá)難免會(huì)有一定的局限性，每個(gè)人的理解都不一樣。正如上圖中需求分析的部分.

通過適當(dāng)?shù)脑u(píng)審，將需求明確，避免理解偏差，具體的操作方式可以參考流程。
舉例，下面是wenku android關(guān)于搜索功能的MRD需求
功能需求：

1.【在線】搜索范圍是文庫
2.【本地】搜索范圍是已導(dǎo)入的本地書籍索引。
3.【本地搜索】默認(rèn)界面，給出已有本地書籍索引
4. 本地搜索無結(jié)果時(shí)，提示在線搜索，點(diǎn)觸立即切換至在線結(jié)果。

按照MRD，可以依照UI界面切分為大的功能塊，然后在大功能塊下再切分小功能塊，最后到功能點(diǎn)，在功能點(diǎn)basic的部分，將圖像化的，表格化的或者文字化的MRD需求分類逐條填充到basic內(nèi)容。具體的方法，可以先構(gòu)造腦圖，然后腦圖轉(zhuǎn)化為組織構(gòu)架圖的模式，然后按照點(diǎn)逐條轉(zhuǎn)換測試用例。

除了基本需求，我們還有讀出MRD之外的隱含需求和擴(kuò)展需求。

隱含需求指的是不明確寫在MRD文檔當(dāng)中，但是作為某一款產(chǎn)品自身的需求，或者某些基本需求的視線，這部分內(nèi)容必須實(shí)現(xiàn)。

對(duì)于隱含需求有兩種可能，一種稱之為約定俗成的需求，一種稱之為支撐性的需求。

關(guān)于約定俗成的需求，對(duì)于某一款產(chǎn)品，必須存在的內(nèi)容，比如描述做一款音樂播放器，對(duì)mp3 wma這樣的解碼支持雖然沒有寫在MRD需求文檔中，但是你如果不支持這部分隱含未表述的需求，則你做出來的東西可能稱不上是音樂播放器。

關(guān)于支撐性的需求，多是若實(shí)現(xiàn)a，則必須實(shí)現(xiàn)b，若b實(shí)現(xiàn)上存在問題，則a的功能不完整。有些時(shí)候a作為明確的需求寫出，但是b不會(huì)。舉個(gè)例子，比如播放器要支持藍(lán)牙線控技術(shù)了，那么線控作為MMI的交互功能，在實(shí)現(xiàn)上需要更多的支撐，比如支持不同的藍(lán)牙音視頻控制協(xié)議，比如兼容不同的藍(lán)牙線控設(shè)備。因?yàn)镸RD更多的是面向市場的，所以另外還有一部分的擴(kuò)展需求是在產(chǎn)品一級(jí)的，比如，在文件管理器為空的時(shí)候做操作，一般MRD都不會(huì)明確定義如何實(shí)現(xiàn)，但是需要我們將這部分作為需求轉(zhuǎn)化為測試用例。

擴(kuò)展需求體現(xiàn)的主要是一部分優(yōu)化，更多的可能體現(xiàn)一個(gè)策略性的東西。比如輸入法，針對(duì)錯(cuò)誤的輸入有一個(gè)識(shí)別過程，比如輸入zhognguo可以自動(dòng)識(shí)別成zhongguo，并顯示為中國。對(duì)于這些模糊輸入的邏輯實(shí)現(xiàn)，依賴于某個(gè)算法，而具體的算法可能是需要擴(kuò)展的。

一般的需求拆分主要考慮兩個(gè)方向，一個(gè)是宏觀的，一個(gè)是微觀的。

宏觀的方式是基于功能塊的拆分，按照一定的功能，將需求拆分成若干個(gè)大功能塊，然后大功能塊拆分成小功能塊，再逐步柴扉為功能點(diǎn)。

微觀的方式主要至考慮功能點(diǎn)的具體實(shí)現(xiàn)流程。

如baidu文庫在線搜索：我們可以明確，在線搜索，搜索的文庫web端的資源，從而我們可以分析出這部分的依賴內(nèi)容，web端api接口，內(nèi)容返回，網(wǎng)絡(luò)連接本身，內(nèi)容展示……逐點(diǎn)的分析才能確保我們測試用例的準(zhǔn)確描述。

另外要借助MRD的評(píng)審會(huì)，了解具體的需求，從需求中理清楚功能。從源頭上減少理解的偏差，才能后續(xù)的測試用例撰寫減少遺漏。

3.3 如何確認(rèn)覆蓋度

確認(rèn)覆蓋度，首先是確認(rèn)對(duì)需求檢驗(yàn)的覆蓋度，必要的流程是MRD評(píng)審和測試用例評(píng)審。通過MRD評(píng)審，QA可以充分了解PM對(duì)產(chǎn)品的需求以及主觀上想要產(chǎn)品的功能，在評(píng)審過程中，QA應(yīng)該提前閱讀MRD文檔，并在會(huì)上拋出自己的問題，以及人為描述遺漏的地方。之后QA進(jìn)入測試用例撰寫階段，結(jié)合前面所述的，先將測試用例撰寫為check list，checklist可以理解為測試用例的大綱，并發(fā)起測試用例評(píng)審，通過集體智慧確保在基本功能測試上，用例能確保全面性。

在時(shí)間允許的條件下，請(qǐng)組內(nèi)其他同仁review，特別是老鳥，避免絆倒他們的石頭再把你絆倒。

3.4 如何創(chuàng)建測試用例

每個(gè)公司和團(tuán)隊(duì)都有自己測試用例設(shè)計(jì)的規(guī)范，這個(gè)就不說啥了。主要幾個(gè)要求無外乎以下幾點(diǎn)：

用例描述（case名稱）：簡要的對(duì)用例的功能進(jìn)行說明，也就是用例的標(biāo)題
測試說明：簡要說明運(yùn)行該測試用例后能夠達(dá)到的目的，這部分內(nèi)容應(yīng)來自MRD或者詳細(xì)設(shè)計(jì)文檔。
初始條件
測試步驟：詳細(xì)描述該測試用例的執(zhí)行步驟。
預(yù)期結(jié)果：按照測試步驟執(zhí)行完畢后預(yù)期獲得的結(jié)果，是判斷測試用例運(yùn)行成功或失敗的準(zhǔn)則

3.5 如何修改測試用例

測試用例的修改是必然的，一方面需求總會(huì)調(diào)整，這個(gè)尤其在維護(hù)過自動(dòng)化測試用例的同學(xué)會(huì)深有體會(huì)。另外一方面，用例很難一次就撰寫的很完美，需要我們持續(xù)的打磨。包括用例評(píng)審，需求的再次走查，ET發(fā)現(xiàn)的bug，用戶反饋的特殊場景等等。這里需要提醒一句：一定要記得，被人給你提的一個(gè)意見，用戶發(fā)現(xiàn)的一個(gè)bug都代表你一類型測試覆蓋的不足，所以在補(bǔ)充測試用例時(shí)，要注意自己是那個(gè)方面有缺失和不足。

3.6 如何確保描述準(zhǔn)確性并提高可移植性

測試用例的撰寫過程，類似寫代碼一樣，我們?nèi)绻恳粋€(gè)項(xiàng)目都從頭寫一遍，那花在測試用的時(shí)間上將非常長，也不利于我們較好的傳承其他項(xiàng)目或者之前項(xiàng)目上總結(jié)提煉的內(nèi)容。

描述的準(zhǔn)確性和用例的可移植性，這看上去其實(shí)是一對(duì)矛盾的話題。如果再加上測試用例的可執(zhí)行性問題，那兩個(gè)case的提升點(diǎn)將更缺乏支撐力。所以這個(gè)小結(jié)，僅作一個(gè)探討。

關(guān)于提高描述的準(zhǔn)確性，這個(gè)毋庸置疑，需要大家做到的是通過盡量少的描述，盡量快速的讓閱讀測試用例的人，把握該用例的為什么做，怎么做，做成什么樣。但是描述的準(zhǔn)確性，往往意味著在交互上，我們更加明確的點(diǎn)出來，如何執(zhí)行一步一步的操作，但是在后續(xù)的應(yīng)用上，實(shí)現(xiàn)類似的功能，也許有完全不同的交互方式。所以單一測試用例的描述準(zhǔn)確性，必然降低可移植性。

所以，我們可以嘗試，UI一級(jí)的測試用例和功能一級(jí)的測試用例分離。這會(huì)導(dǎo)致測試用例的增加，但是UI一級(jí)的測試用例，在多次往復(fù)的系統(tǒng)測試中，可以遍歷一次后被擱置，在其他系統(tǒng)一級(jí)的測試用例保留?？偟膱?zhí)行上，應(yīng)該可以減少執(zhí)行成本。而功能一級(jí)的測試用例，可以被我們做抽象，抽象后的用例，可以在項(xiàng)目的項(xiàng)目升級(jí)，或者不同項(xiàng)目的相似功能模塊之間復(fù)用。

這里需要定義這兩個(gè)概念，什么是功能級(jí)測試用例，什么時(shí)候UI一級(jí)測試用例。UI一級(jí)的測試用例，測試步驟上突出執(zhí)行的步驟，如點(diǎn)某某按鍵到實(shí)現(xiàn)什么，檢查點(diǎn)突出檢查的是畫面的展現(xiàn)以及頁面之間的跳轉(zhuǎn)。功能一級(jí)的測試用例，不突出形態(tài)，而是就某一項(xiàng)功能是否實(shí)現(xiàn)。

也許這里，我們可以借鑒兩個(gè)概念類和多態(tài)。類這個(gè)概念，可以被理解成被我們抽象出來的功能模塊，這些功能模塊對(duì)于某一類產(chǎn)品，就特點(diǎn)上是固定的，多態(tài)可以被理解成是該功能的展現(xiàn)方式。

打個(gè)比方，播放模塊可以被封裝的功能有：播放-暫停-前一個(gè)-后一個(gè)-快進(jìn)-快退-播放進(jìn)度，這個(gè)“類”在被不同的音樂播放器上有不同的展銷效果，比如有的播放器可以通過拖拽進(jìn)度條實(shí)現(xiàn)快進(jìn)快退，有的通過按鍵點(diǎn)擊實(shí)現(xiàn)快進(jìn)快退。

4. 測試用例和補(bǔ)充測試手段

如前文已經(jīng)提到的，測試用例一定是無法一次性就寫得很完整，即便是一只QA老鳥，即便經(jīng)過了評(píng)審和認(rèn)證，還是會(huì)有我們遺漏的問題。就如同積累了豐富的經(jīng)驗(yàn)，我們?nèi)耘f無法預(yù)測地震一樣。

因?yàn)樵诋a(chǎn)品實(shí)際做出來之前，我們的case撰寫本身就是一個(gè)閉門造車的過程，即便已經(jīng)很嚴(yán)密了，仍舊有很多實(shí)際問題我們是開始階段無法想到的。

另外有一些問題，本身我們不可能完全轉(zhuǎn)換為測試用例，因?yàn)橐恍┚唧w的bug一旦描述被抽象后，很難表達(dá)給執(zhí)行人。所以在測試過程中，需要使用一定的補(bǔ)充測試手段，用以補(bǔ)足測試覆蓋。

4.1 ad hoc test

Ad hoc test主要在各輪bug驗(yàn)證以及系統(tǒng)測試的補(bǔ)充，在執(zhí)行ad時(shí)主要要考慮三點(diǎn)：

• 第一：更改了什么內(nèi)容，可能引發(fā)什么side effect
• 第二：新增了什么內(nèi)容，那些交互上容易出現(xiàn)水土不服
• 第三：執(zhí)行測試時(shí)的新發(fā)現(xiàn)，比如測試執(zhí)行中，你發(fā)現(xiàn)某些可能實(shí)現(xiàn)上有可能出現(xiàn)瓶頸的東東，為了防止的思維發(fā)飄，可以先記錄下來，然后到系統(tǒng)測試結(jié)束后，執(zhí)行ad hoc test。

ad hoc test更詳細(xì)的介紹可以參考文檔：http://www.itdecent.cn/p/a93793d5296a

4.2 User trail

用戶體驗(yàn)，在功能大架子完成，基本上沒有S0-S1的bug，S2的bug也趨向低水品后，可以發(fā)動(dòng)內(nèi)測，通過內(nèi)測去發(fā)現(xiàn)更多的問題。內(nèi)測的排期，通常在項(xiàng)目立項(xiàng)之時(shí)就會(huì)做好估計(jì)，此時(shí)QA需要約定好內(nèi)測觸發(fā)的版本條件。千萬避免版本質(zhì)量不夠好，為了內(nèi)測而內(nèi)測，未解決的問題過多，那內(nèi)測問題重復(fù)率將加倍放大，QA PM會(huì)在篩選bug上浪費(fèi)時(shí)間，所以必須確保內(nèi)測版本質(zhì)量。與此同時(shí)也不必過于強(qiáng)求版本質(zhì)量，而花費(fèi)太多時(shí)間在版本穩(wěn)定上，造成項(xiàng)目整體時(shí)間的不可控。

一般建議S0-S1的bug應(yīng)該是0，S2的bug修復(fù)率應(yīng)該在95%以上，一般的vsm項(xiàng)目，到內(nèi)測時(shí)的bug大約為150個(gè)，所以一般最后尚未解決的bug大致在5個(gè)左右。注意，此數(shù)據(jù)僅供參考。在實(shí)際執(zhí)行中，需要靈活處理，合適的調(diào)整約束條件，比如有些S1crash的問題，被用戶發(fā)現(xiàn)的概率非常低，可以降低其修復(fù)的優(yōu)先級(jí)，可以暫時(shí)接受不修改。

內(nèi)測階段，可以通過創(chuàng)建內(nèi)測群，內(nèi)測郵件組等方式，第一時(shí)間關(guān)注內(nèi)測問題，另外一方面積極關(guān)注PM手機(jī)的問題反饋，確認(rèn)屬于bug還是建議，bug的部分，那些是未發(fā)現(xiàn)的，那些是已經(jīng)發(fā)現(xiàn)的；建議的部分，那些是合理的，合理的建議哪些是需要被采納的。

在內(nèi)測階段，需要注意良好的溝通方式，內(nèi)測的同學(xué)一般都不是專門的QA，書寫描述可能不夠仔細(xì)、翔實(shí)。需要溝通問題發(fā)生的硬件版本，軟件版本，所處的各種相關(guān)環(huán)境，在一些特有條件下發(fā)生的問題，需要特別注意這些。

可以有目的的引導(dǎo)執(zhí)行內(nèi)測，覆蓋一些我們不容易發(fā)現(xiàn)的問題。這可能算是一個(gè)比較高階的問題，困難來自于兩方面，如何驅(qū)動(dòng)用戶接受你的引導(dǎo)完成你需要的測試；第二個(gè)問題是，如何使用整理你需要協(xié)助完成的測試內(nèi)容，無論是測試項(xiàng)還是反饋形式。

很多公司和團(tuán)隊(duì)內(nèi)測完全是放任自由主義，任由自由之花盡情綻放，不過和自然界一樣，果樹想多長果實(shí)，打定摘心的誘導(dǎo)還是必須的。QA就是內(nèi)測這棵自由之樹將來打頂摘心的人。對(duì)，我說的是將來。因?yàn)檎归_內(nèi)測首先以上的兩個(gè)問題如何解決。第二個(gè)和交由新人第一次寫測試用例一樣，這個(gè)可以準(zhǔn)備，但是不能苛求全面，在實(shí)踐活動(dòng)中，我們才可能充實(shí)起來。關(guān)鍵是第一個(gè)問題，如果引導(dǎo)內(nèi)測用戶和獲得較大的反饋收益，這個(gè)具體可以參考后續(xù)topic--內(nèi)測執(zhí)行建議規(guī)范。

大致的流程為：PM收集用戶的反饋，并由PM篩選將bug的部分轉(zhuǎn)交給QA，建議和功能改善的部分由PM-UE發(fā)起討論。QA拿到內(nèi)測反饋的問題，先分析是否為bug，是bug的話是否已經(jīng)提交，針對(duì)未提交的部分，我們需要積極和發(fā)現(xiàn)問題的用戶做溝通，特別是就在我們周邊的同時(shí)。分析用戶發(fā)現(xiàn)這一問題的場景和復(fù)現(xiàn)步驟。對(duì)可疑拆分為系統(tǒng)測試的內(nèi)容點(diǎn)，需要轉(zhuǎn)為測試用例，并強(qiáng)化到測試用例集中。在此基礎(chǔ)之上，轉(zhuǎn)化步驟，可以參考ad hoc test的后轉(zhuǎn)化動(dòng)作。

4.3 Project Handover

項(xiàng)目交換，這里講的不是將項(xiàng)目執(zhí)行一段時(shí)間后，交換負(fù)責(zé)人，而是在項(xiàng)目的系統(tǒng)測試結(jié)束之后。通過半天的時(shí)間，由組內(nèi)甚至組外其他同仁介入做一次ad hoc test。此方法的目的旨在減少個(gè)人思維的瓶頸，并利用交流機(jī)會(huì)，一方面減少測試點(diǎn)遺漏，另外一方面開拓思路。

很多團(tuán)隊(duì)對(duì)測試項(xiàng)目的輪轉(zhuǎn) -- 這個(gè)還沒有形成規(guī)范，建議在系統(tǒng)測試結(jié)束，整體提測試前。

Project handover會(huì)由同仁幫忙發(fā)現(xiàn)一些疏漏的問題，首先可以以點(diǎn)代面，了解別人的思路，并由此整理測試用例。在此基礎(chǔ)之上，轉(zhuǎn)化步驟，可以參考ad hoc test的后轉(zhuǎn)化動(dòng)作。

相關(guān)文章：

《再說說APP測試設(shè)計(jì)-1》
《再說APP測試設(shè)計(jì)-2》
《關(guān)于ad hoc test》
《干了這碗蛋炒飯 繼續(xù)APP性能提升-1》
《突破測試的墨菲定律 -- 有感于一次UAT組織》