測試用例設計的方法下

知乎的圖片編輯實在太麻煩，要看圖片的同學可以關注微信公眾號.：it65535，然後回復軟體測試資料。

大家晚上好，上章介紹了測試用例設計的重要性和用例設計的方法，並且石頭哥分享了自己的一套用例設計的方法，即：質量屬性＋用戶場景＋業務邏輯的用例設計方法。今天石頭哥用一個每個人都會用到的功能來舉例子說明下吧！

對於微信個人用戶來說，兩大重要特色就是聊天和發朋友圈了吧。今天我們就一起討論下如何對發朋友圈這個功能來設計用例。

首先，我們從質量屬性上來分析該功能。這裡一個比較好用的方法就是用思維導圖的方式先將各個質量屬性維度列出來，如下圖：

然後根據各個維度進行分析和補充測試點（這裡需要自己具備一定的經驗和對業務的熟悉程度了），石頭哥根據自己的分析後補充測試點如下（當然， 可能本身也不完善，大家可以一起討論下），補充結果見下圖：

這裡簡單梳理下上面的分析結果，歡迎拍磚。

1、安全性：因為對於微信發朋友圈來說，其實在安全性方面不是重點，就是去獲取相冊和視頻的許可權時要確認下有沒有問題（但是微信支付這個功能這塊就是最重要的了）。

2、兼容性：這塊應該是app一個通用的測試難點了，涉及到不同型號和廠商的手機，相信很多公司都有了對應的測試方法，比如：眾測。

3、體驗性：這個其實是app的一個測試重點，按照目前發朋友圈的方式體驗還是比較好的，而且人人都習慣了，所以也沒有什麼問題（不過目前發朋友圈有2種方式，大家可以比較下哪種更符合用戶習慣呢）？ 這裡也同時發現了幾個問題：只能夠現場錄製視頻後發朋友圈，不能發已有視頻；不能發多個視頻；不能夠直接發文字；對於後面的2個問題，微信有自己的體驗原則還可以理解。但是不能夠發相冊裡面的視頻其實是值得吐槽的（如果是石頭哥的版本肯定是提bug的節奏），畢竟視頻具有實時性，本來別人看到一個好玩的東西想錄製視頻（比如：小朋友的表情），還需要先打開微信，找到發朋友圈的地方再去錄製，這個時候可能黃花菜都涼了。

4、可擴展性：我們除了現在能夠發照片和視頻外，後面如果支持更多內容的話，是不是有很快的解決方案，還是需要改動很大（這個其實我們測試人員是可以幫助開發去考慮的）。

5、可靠性：這裡主要分為對發的內容和發送的過程來進行分析，結果大家可以看上面。

6、性能：對於app來說，主要的性能就是對資源的佔用，當然， 這裡也需要考慮到對伺服器的性能壓力。

7、可維護性：這裡主要說只出問題後如何去分析和排查。要知道，對於app來說用戶才是最大的測試群體。所以，一般的app都會有自動上報的功能（好吧，這其實已經涉及到安全問題了）。

ok，對質量屬性分析完成後，下面我們從用戶場景進行分析。用戶場景的測試就是從用戶整個發朋友圈的過程進行分析，然後通過模擬真實的用戶行為進行測試。比如：用戶拍照後想將當前照片發朋友圈。

這裡有2個方法：

1、打開微信－>選擇 「我」的標籤－>點「相冊」－>點「今天」旁邊的照相機圖標－>選擇照片－>從相冊里選好相片－>輸入文字（可選）－>完成。

2、打開微信－>選擇 「發現」的標籤－>選擇「朋友圈」－>選擇右上角的照相機圖標－>選擇照片－>從相冊里選好相片－>輸入文字（可選）－>完成。

大家發現操作步驟是不是一樣的？這個也是石頭哥認可微信體驗到一方面，用最少的步驟去滿足大家最常用的需求（大家有更少的方法嗎？可以分析下，對自己對產品理解能力會很有幫助）。

分析完成後，我們就可以根據這些操作步驟進行分析測試點了（這裡就不僅僅是一個功能了）。

下面是石頭哥對第二種方法分析的結果（石頭哥習慣的一種方式），大家可以先看看。

對於用戶場景的測試點分析，一個比較好的方法就是分析用戶在這個過程中可能的行為（目前app的用戶行為分析和上報就是很好的輸入來源），然後進行針對性的設置測試點（這個方法在探索性方面也可以用到）。

完成用戶場景的分析後，就要開始對業務邏輯進行分析了，可惜的是石頭哥沒有相關功能的代碼和業務流程圖。這裡根據功能來分析下大概的邏輯（真實的業務邏輯處理肯定是遠複雜於石頭哥列的，這裡為了舉例子方便，所以簡化了）。

對於業務邏輯該如何測試呢？大概過程如下：

1、拿著開發的設計文檔梳理出整個業務邏輯圖（能夠跟開發一起做的話效果更好，方便更加了解開發的整個思考過程）。

2、業務邏輯圖（有可能是開發自己畫的）完成後，肯定會有很多有疑問的地方，然後拿著業務邏輯圖跟開發一步一步的梳理和確認（需要自己先花時間學習，否則可能會被開發鄙視，臉皮厚的話也可以），過程中如果能夠發現開發一些設計不合理的地方並且給開發提出更好的解決思路的話，會更好的得到開發的認可。

3、對照著業務邏輯圖去設計針對業務邏輯的測試點（對每個業務邏輯的正常情況和異常情況進行分析）。

4、根據開發的設計介面，將介面提取出來，並且專門針對介面去實現自動化測試（介面測試對於代碼的質量是很有幫助的），這塊後面在測試開發一章中會詳細介紹。

5、提前將我們的一些分析結果，比如：測試點發給開發去看看，告訴他們我們會對哪些地方進行測試。這樣他們就會提前做好處理了，節省後面發現bug的成本。

6、對於邏輯的測試最好是全部實現自動化，方便後面持續去測試。

到這裡，我們就完成了用例設計的方法分享。大家有什麼問題可以直接跟石頭哥進行交流。另外，對於具體領域的用例設計網上其實還是有很多相關資料的，比如：app的測試和web的測試，其實都是有一套完善的方法的，大家可以整理出來，形成自己的一套經驗庫。

後面，我們將會分享探索性測試相關的內容，歡迎大家關注大話it公司，來更好的跟石頭哥進行親密接觸。