JMeter – 驗證回覆資料 (Response Assertion)

之前提到的文章都只是單方面發送 http request，卻沒有針對收回來的資料做驗證，其實在 JMeter 裡的 Assertion 是可以針對每一個 request 回應的資料做驗證，而常用的驗證內容包括：

在 Samsung 裝置使用 Android UiAutomator 的 setText(string) 會出現 string 內的字元錯位

使用在台灣販售的 Samsung 手機（搭載「三星 中文輸入法」）搭配 Android UiAutomator 都會遇到一個問題： setText(String) 時會有字串錯位問題。

原因：Samsung 手機自己的 Samsung 中文輸入法鍵盤在使用 Android UiAutomator setText(String) 時會有字串錯位問題。

如何制定 test plan

參考網址：如何制定完美的測試計劃

文中提到一個測試計劃應包括：產品基本情況調研、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結果.. 等。
測試計劃是整個測試的流程，不是一個很細項的東西，而是一個大概的流程，從測試環境的配置，測試的目的，要測哪些功能，方向等，都先記錄下來，已便以後回來再來看這些資訊。

基於模型的測試 (Mode base testing)

參考網址：关于基于模型的测试的那些事

文中提到如何來建模型，要先將大的系統拆解成小的部分，就像軟體測試之道裡面提到的，『太小，才是一個好的模型適當的大小』，從小模型開始瞭解系統的功能，在慢慢的組成整個系統的架構。文中也舉例如何進行數據模型與狀態機模型，在狀態機模型中，我們可以看出其實可以測試的路徑有很多，所以我們必須先想說我們的覆蓋目標是什麼？然後透過狀態機模型來建立我們的測試。所以我們之前畫的FSM 也要繼續維護，也許有一天我們可以利用它來建立我們測試。

效能/負載/壓力測試 差異

參考網址：Performance, Load & Stress Testing on Mobile Apps

一般這三種測試容易令人混淆，效能測試是在一般正常操作形況下，所有的數據是否符合預期的(如: 系統回應時間 )，再來負載測試是在系統負荷量最高的時候去操作系統，看是否會有問題，最後壓力測試則是在超過系統能夠負荷的情況下或是一些突然的意外下系統能不能很快的恢復正常。

How to write effective Test cases, procedures and definitions

參考網址: How to write effective Test cases, procedures and definitions

所以一開始當我們不是很瞭解待測軟體時，我們可以透過 spec 跟文件先來寫一些基本的測試案例，隨著越來越熟悉待測軟體時，我們的測試案例 level 也會越來越提高。裡面也有提到說測試案例應該是容易讀也容易理解的，不要像在寫作文一樣的去解釋，所以上次我們也討論道說我們的測試案例其實不需要把太多的細節寫在裡面，而且是容易懂就可以了。

軟體測試的關鍵要素

參考網址: 敏捷软件测试的七个关键成功要素​

這篇文章雖然是主要是在講敏捷軟體測試，但裡面提到的其實我們都可以看一下。其中有一段「敏捷測試思維」，提到了說測試人員必須不斷的磨練技能，讀書，看文章，透過這些東西增加自己的想法，並且將自己的想法與經驗跟大家一起分享交流。也有提到說當你有遇到問題時，要把問題提出來跟團隊分享，讓大家一起提出想法交流去解決問題。所以都是我們現在正在也必須繼續維持的事情。

讓 assert 不再成為自動化測試的負擔

參考網址：敏捷自动化测试（3）——让断言不再成为自动化测试的负担

裡面提到說，自動化測試中有時候 assert 的條件很繁瑣，尤其在ＵＩ中由於訊息量太大，常常很難去決定要怎麼去做 assert 的部分，所以說要針對少量，必要的關鍵點去做 assert 。但是哪些是關鍵點有時候可能得大家一起討論了。

如何讓 test case 可重複使用

參考網址：可复用测试用例研究

裡面有提到一點，如果將測試案例設計的非常細，將一些輸入數據與詳細的操作步驟都太過具體描述，這樣的測試用例只能在某些特定的版本使用。所以我們在設計測試案例時，應該避免填入一些寫死的數據，所以之前有些文章就會建議說可以結合測試技術並使用隨機數據來輸入。之後我們可能還再稍微針對之前的測試案例做一些討論來看說哪些是需要稍微更動的。

Hooray for Buggy Software

參考網址：Hooray for Buggy Software

這篇文章將軟體開發分為三個階段，每個階段有不同的測試跟著並行去做。所以在不同階段發現的 bug 數量有不同的意義。應該要針對不同階段去探討，而不是只是因為發現很多 Bug 而感到開心。