一、遊戲測試

1. 你有玩過什麼遊戲

一般玩的比較多的是手遊，比如：糖果傳奇、消滅星星、密室逃脫，以及前段時間比較風靡的陰陽師。

在電腦上，QQ歡樂四川麻將，以前還會玩一些經營類遊戲，初高中的時候是：QQ寵物、QQ農場，大學的時候玩過模擬人生

2. 什麼樣的遊戲可以稱為一個好的遊戲

1. 首先，最直觀的感覺，精緻的畫風、恰到好處的背景音樂和優秀的故事情節。

對於遊戲第一眼是UI介面，整體的畫風、恰到好處的背景音樂，會讓玩家賞心悅目，眼前一亮。

其次，一個大型的一點的遊戲，相當於是一個虛擬世界，所以這個世界首先要有邏輯、故事情節不用太複雜，但是引人入勝。

2.易操作性

操作不能過於複雜和困難。

最經典的俄羅斯方塊，操作只有上下左右，但是卻一直延續至今

3. 競技性，設定的關卡難但是經過努力會過，關卡過了以後有獎勵機制

遊戲中設定關卡是一定有難度階梯的，隨著前幾關的熟悉，到後面越來越難。但是難度也不能特別不合理，不能稱為一種套路

例如，之前我有玩過一個遊戲，叫做小時代的換裝遊戲。

每一個關卡就是一個女生在打扮自己，然後評分，只有達到一定分數才能成功闖關，並且解鎖更高階的衣服。

開始我玩的挺開心的，但是後面發現，每套衣服的搭配成了一種套路，不管這一關卡的主題， 只要搭配了其中幾件很難得到的衣服就絕對可以有高分。同時，到了後面，關卡所必須的衣服實在太難，只能花錢購買。所以無奈之下只有棄玩。

4. 有抽獎或者連續登入、節假日獎勵機制，可以讓玩家保持一個新鮮度，並且刺激每天玩耍。

比如之前我玩的糖果傳奇，累計登入的時間越久獲得的獎勵越高階，一旦終止所有獎勵從頭開始，於是我為了這個獎勵每天都會登入，一登入就會忍不住玩耍。

其次，抽獎的東西是不確定的，存在是特別好的道具的可能，所以我每天最期待的就是抽獎。

2. 遊戲測試：

1. UI測試：

畫風、故事情節、背景音樂、文字的契合度

圖片的顯示、文字的排版、佈局等

2. 功能測試

遊戲分類很廣泛，例如：射擊類、經營類、競技類等等。首先根據需求說明書，確定所測部分的具體流程、功能。

1. 我認為遊戲測試最重要的是數值。

數值代表了一個角色的多種狀態、行為、裝備、技能、財富，一旦一個發生了變化，其他也會隨之變化。同時如果一旦出錯，例如我之前玩candy crush原有的金幣全部消失，則會引起玩家極大的不滿，或者棄玩。

所以儘可能的用邊界值分析法和等價類劃分法去模擬各種可能，測試角色的各種情況。

2. 活動

遊戲會根據節假日、累計登入、抽獎建立各種抽獎或者獎勵活動。所以我們需要確認活動的開始、終止時間，累計登入的次數、獎勵是否和預期相同等

對於組隊完成任務這種，更加複雜，需要將多角色融合在一起。

3. 存檔。

1. 如果暫停，是否有存檔
2. 在遊戲中途如果退出是否有存檔
3. 如果需要聯網，如果斷網，是否有存檔

3. 可用性測試

比如：

1. 需要重力感應的遊戲，是否能夠很好的識別到我們的動作。

2. 觸屏的接觸點靈敏

4. 效能測試

在遊戲中，開啟時間太長，或者遊戲過程中出現卡頓都是會讓玩家有厭倦感的。

1）手遊：主要是客戶端的效能測試

開啟遊戲、在遊戲中響應時間、是否出現卡頓情況，記憶體佔有、耗電量、流量等。

2）網遊：伺服器端的效能也十分重要

所以還需要對伺服器端的CPU、記憶體情況進行測試

5. 安全測試

1. 使用者端：使用者是否需要登入／註冊，如果需要註冊，在註冊框應該考慮：

1. 防止JS指令碼注入、SQL語句注入
2. 防止暴力登陸——登入密碼連續錯誤幾次，需等待時間或者簡訊驗證
3. 是否允許一臺機器多使用者，或者一個使用者在多臺機器上登入

2. 伺服器端：

1. 使用者存檔資訊是否安全、完整
2. 禁止外掛
3. 合服時，資訊的儲存

6. 相容性測試

不同的瀏覽器、手機端、電腦系統。

7. 壓力測試、強度測試

長時間多使用者線上，伺服器的CPU、記憶體情況，

3. 測試俄羅斯方塊

1. UI介面

影象顯示、文字排版是否合理規範，背景音樂是否恰當

2. 功能測試：

首先分析，俄羅斯方塊主要有四個操作：左移、右移、變換方塊、向下加速。

操作過程是：一個方塊如果填補了一行的空缺之處，則消除對應行，否則一直累積，如果累積的高度達到了最大限制，則失敗。

結合等價類劃分法和邊界值分析法，我們設計測試用例主要從幾個方面：

1. 四個操作是否恰到好處，反應不會太遲鈍也不會太靈明
2. 當一個方塊掉下去填補了一行的空缺處後，是否填補行消除，但是方塊其他部分沒有消失，未消除行整體向下移。
3. 當一個方塊掉下去後，若沒有行被填補，則行數累加
4. 一些邊界值情況：只有一行就到最大行了，這個時候消除一行是否有效降低行數；不做操作，等待遊戲自己結束的情況等。
5. 如果暫停，是否有存檔
6. 在遊戲中途如果退出是否有存檔
7. 如果需要聯網，如果斷網，是否有存檔

3. 可用性測試；

1. 如果是四個上下左右鍵，則檢查靈敏度且鍵盤放置的位置是否合適
2. 如果是按照重力感應，檢測對動作的識別度

4. 效能測試：

1. 客戶端：CPU、記憶體、耗電情況、流量情況、遊戲

5. 安全性：

1. 使用者端：使用者是否需要登入／註冊，如果需要註冊，在註冊框應該考慮：

1. 防止JS指令碼注入、SQL語句注入
2. 防止暴力登陸——登入密碼連續錯誤幾次，需等待時間或者簡訊驗證
3. 是否允許一臺機器多使用者，或者一個使用者在多臺機器上登入

2. 伺服器端：

1. 使用者存檔資訊是否安全、完整
2. 禁止外掛

6. 相容性測試

不同的瀏覽器、手機端、電腦系統

7. 壓力測試、強度測試

長時間多使用者線上，伺服器的CPU、記憶體情況，

一、應用模組的測試

1.如何按排對農餐的測試？

農餐對接系統分為了兩大子系統，一個是個人訂餐系統，二是餐館、個人與農產品供應商進行農產品交易系統。我主要負責組織測試人員對該系統進行測試。

第一步，分析需求規格說明書，制定測試計劃。測試計劃包括了5W1H，也就是Why、When、What、Who、Where、How。

首先，我們確定選用了禪道Bug管理系統，用來管理需求、測試用例和Bug。

其次，根據專案的開發時間和條件，確定使用：Jenkins持續整合工具、git版本控制工具，以及Selenium自動化測試工具、Unittest框架。

第二步，瞭解技術架構，設計測試方案、測試用例。

首先，因為最開始有涉及到使用Junit進行單元測試，所以對系統的架構有一定的瞭解，定位可能存在問題的瓶頸點。

其次，將測試用例涵蓋的範圍設定在7個方面：資料庫測試、功能測試、效能測試、壓力測試、安全性測試、相容性測試、易用性測試。其中，設計測試用例的原則是：利用等價類劃分法、邊界值分析法、場景設計法等儘量多的覆蓋所有的路徑。——設計測試用例

第三步，進行測試。——搭建專案框架

在測試前先搭好測試框架，準備好各種測試要用到的工具，然後按照測試方案流程進行測試。

1. 使用PO設計模式

將一個頁面內的操作物件（按鈕框、輸入框等）和操作的步驟封裝在每個Page裡面，以Page為單位進行管理。這樣Selenium測試用例能夠通過呼叫頁面類來獲取頁面元素，從而巧妙的避開了當頁面元素的ID等屬性發生變化時，修改程式碼的情況。——>提高了程式碼的複用性、可讀性及減少工作量。

2. Selenium+Unit test搭建四層框架——實現資料、指令碼、業務邏輯分離（關鍵字驅動）

1）基礎層（BasePage）

設計一個基本的Page類，所有頁面皆繼承該類。提供了一個頁面需要實現的基本功能及公共方法。

2）業務邏輯層（Pages）：

按照PO設計模式，將每個頁面抽象為一個類，放在Pages包裡面，每個頁面繼承Basepage，可呼叫Data層資料，內容包括：

• 該頁面所有的操作物件屬性
• 實現的功能

3）資料層（Data）

該層存放相關資料，例如：使用者資料和密碼。在測試用例可通過呼叫資料層的資料來進行操作。

4）測試用例層（Testcases）

每一個測試用例testcase都對應Pages裡面的一個頁面，繼承unnitest.TestCase類。通過呼叫對應頁面類的方法，資料層的資料、增加斷言(assert)來驗證功能的正確性。

此外通過Jenkins自動執行測試、程式碼質量檢測和部署到測試伺服器、部署到生產伺服器上

3. 自動化測試執行策略——三個階段

使用Jenkins持續整合工具來執行測試指令碼和部署，主要設定了三個任務：

• tm_test：用於執行自動化測試指令碼，檢測程式碼質量
• tm_staging_deploy：用於在測試伺服器上部署程式碼
• tm_deploy：用於在生產伺服器上部署

我們將測試分為三個階段：

1. 開發新的需求時，建立分支devN。當在這個分支中，需求開發完成或者Bug修復，就配合測試人員利用JUNit框架進行單元測試以及功能測試。通過測試後，合併到master上。

2. 當master有變動，則觸發tm_test任務，執行自動化測試指令碼和程式碼質量檢測。如果通過則自動出發tm_staging_deploy，部署到測試伺服器，如果沒有通過，自動化測試指令碼會將Bug截圖傳送給測試人員。

3. 登陸生產伺服器上，對網站進行功能測試。如果通過測試，則手動觸發tm_deploy，部署到生產伺服器。如果沒有通過，在禪道管理系統上把bug指派給相應模組的開發人員。

第四步，釋出

首先考慮灰度釋出，先讓小部分群體試用，如果有什麼問題就能夠及時發現、改正。

2. 選擇農餐的一個測試模組，設計測試用例。

（1）登入模組

先分析這個模組的需求設計說明書，確認這個模組的介面、實現功能和步驟、其他技術設計。確定容易出錯的地方。

1）這個模組介面組成部分：使用者名稱輸入框、密碼輸入框、登入按鈕、“記住使用者名稱”單選項、忘記密碼連結、免費註冊連結。

2）功能實現步驟：

輸入使用者名稱——輸入密碼——輸入驗證碼——點選“登入”，則可以跳轉到對應的頁面（驗證點：跳轉頁面有：歡迎xxx登入），最後退出。

3）其他設計需求：例如使用者名稱的限制是：長度6-18位的非漢字，數字、字元、下劃線的組合

其次確認測試的方案：

• 測試分為六個方面
• 使用等價類劃分法和邊界值法，
• 用人工測試實現。
• 測試的目標：當測試用例基本都通過，沒有一、二級的BUG出現，剩餘BUG不影響功能則可以驗收本功能模組

1. 介面測試：

• 介面佈局是否合理，文字排版是否整齊
• textbox和按鈕的長度、高度是否符合要求

2. 功能測試：

我們根據等價類劃分法和邊界值分析設計測試用例：

• 連結測試：點選“忘記密碼”和“免費註冊”能夠正確的連結到相應的頁面
• 輸入正確的使用者名稱、密碼，點選“登入”按鈕，驗證是否跳轉到正確的介面。
• 輸入錯誤的使用者名稱、密碼，點選“登入”，驗證是否為提示“使用者名稱/密碼錯誤”
• 輸入空的使用者名稱或密碼，點選“登入”，驗證是否提示“使用者名稱/密碼不能為空”
• 輸入的使用者名稱和密碼中含有特殊的字元，和其他非英文字元，系統會提示或者過濾
• 使用者名稱和密碼前後有空格的情況
• 密碼是否以星號顯示
• 點選“記住使用者名稱”，重新整理頁面後，使用者名稱輸入框能夠自動填充

3. 效能測試：

在客戶端：

• 開啟登入頁面所需要的時間，是否滿足設計的需求
• 當輸入正確的使用者名稱和密碼後，登入成功跳轉到新頁面，不超過5秒（滿足設計需求）

在伺服器端：資源利用率（CPU使用率，記憶體佔用率），吞吐率，釋出耗時，各介面平均響應時間等等

其次，我們設定預期正常併發使用者量為1000，最高併發量為3000，我們使用Jmeter+BadBoy測試在這兩個併發量範圍內的網站響應速度和記憶體使用情況。

4. 安全測試

1. 檢查登入生成的Cookie是否為httpOnly，這是為了防止XSS（跨站指令碼攻擊），竊取cooki內容。
2. 使用者名稱和密碼的的輸入框，應該禁止輸入指令碼 （防止XSS攻擊）
3. 使用者名稱和密碼的輸入框，應該遮蔽SQL 注入攻擊
4. 錯誤登入的次數限制（防止暴力登入）
5. 使用者名稱和密碼是否通過加密的方式，傳送給伺服器
6. 使用者明和密碼的驗證，應該是伺服器端驗證，而不能單單是在客戶端用JavaScript
7. 考慮是否支援多使用者在同一機器上登入
8. 考慮同一使用者在多臺機器上執行

5. 可用性測試

1. 是否可以全用鍵盤操作——快捷鍵
2. 輸入使用者名稱、密碼後，按回車能否登入

6. 相容性測試

1. 不同的瀏覽器
2. 不同的裝置：電腦、手機、IPad
3. 不同的平臺：Mac、Windows

4. 不同的解析度

 （2）對搜尋欄進行測試——對百度首頁進行測試

首先根據需求說明書對這個功能模組進行分析，確認UI介面、實現的功能和步驟、其他技術設計。確定容易出錯的地方。

1）模組的介面：首先搜尋類別（食品還是餐館）的下拉框，其次有一個輸入框供輸入查詢的內容，在輸入框右邊有一個查詢按鈕，下邊是熱搜菜品。

2）模組的功能及實現步驟：

1. 直接點選：搜尋框下面的熱搜菜名，就可以跳轉到對應菜品所在搜尋頁面；2. 首先選擇類別：食品或者餐館，其次在輸入框中輸入查詢的內容，最後點選查詢。

3）其他技術設計：

• 搜尋框能進行模糊匹配、完全匹配；
• 搜尋框能夠識別出以空格／tab／逗號隔開的關鍵字
• 輸入框的的字元長度限制，

其次確認測試的方案：

• 測試分為六個方面
• 使用等價類劃分法和邊界值法，
• 用人工測試實現。
• 測試的目標：當測試用例基本都通過，沒有一、二級的BUG出現，剩餘BUG不影響功能則可以驗收本功能模組

1. 介面測試：

• 搜尋頁面佈局合理，無錯別字
• 檢視選擇類別框、輸入框及查詢按鈕是否在同一水平線、佈局合理
• 檢視輸入框下邊的熱搜菜品是否佈局合理、無錯別字
• 搜尋出的結果展示，佈局合理
• 已檢視過的菜品、店鋪連結顏色呈灰色處理，與沒有點選過的結果連結區分
• 結果數量龐大時，分頁佈局合理

2. 功能測試。

按照等價類劃分法和邊界值法設計測試用例

• 連結測試：點選輸入框下面的熱搜菜名，會正確跳轉到該菜名指向的頁面
• 選擇搜尋“菜品”，輸入部分菜品名，點選查詢，檢視顯示結果是否正確
• 選擇搜尋“菜品”，輸入完全的菜品名，點選查詢，檢視顯示結果是否正確
• 選擇搜尋“餐館”，輸入部分餐館名，點選查詢，檢視顯示結果是否正確
• 選擇搜尋“餐館”，輸入完全的菜品名，點選查詢，檢視顯示結果是否正確
• 多個關鍵字中間加入空格／tab／逗號後系統的結果是否正確

• 輸入內容為空，點選“查詢”，驗證系統如何處理
• 輸入內容為空格，點選“檢視”，驗證系統如何處理
• 輸入合法長度的字串後，加空格，驗證搜尋結果
• 輸入空格+合法長度的字串，驗證搜尋結果
• 輸入字串長度等於及超過允許的字串範圍，驗證系統如何處理
• 輸入特殊字元，驗證系統如何處理
• 多次輸入相同內容，結果是否相同

3. 可用性測試：

• 在輸入框是否可以用快捷鍵
• 輸入框是否支援回車

4. 安全測試

• 輸入框禁止指令碼
• 輸入框禁止SQL注入，檢索sql select語句等
• 特殊字元的檢索
• 被刪除、加密、授權的資料是不允許被查出來的（淘寶！）

5. 效能測試

在客戶端：

• 搜尋頁面開啟的速度是否滿足設計需求
• 搜尋出結果消耗的時間是否滿足設計需求

在伺服器端：資源利用率（CPU使用率，記憶體佔用率），吞吐率，釋出耗時，各介面平均響應時間等等

6. 相容性測試

• 多平臺：windows、MAC
• 移動裝置：android、iphone、ipad、surface
• 多瀏覽器：Safari、Ie、Firefox等
• 不同解析度

7. 本地測試

登入時，自動切換到響應國家的搜尋頁面（淘寶）

3. 如何測試微信紅包——騰訊

將測試階段分為四個步驟：

一、首先根據需求說明書確認這個模組的UI介面、實現的功能和步驟、及其他技術設計架構，定位可能出錯的地方。

二、其次確認測試的方案（5W1H）：

• Why：測試的原因，即當前產品的現狀，和測試的目標、上線的質量指標
• What：測試的內容（微信紅包模組）
• When：測試的時間範圍和週期
• Who：測試的人員安排
• Where：測試相關文件存放的位置
• How：確定測試的策略：測試用例編寫方法（例如：邊界值分析、等價化分類等）、測試的工具等

三、進行測試。

在第一步中，我們已經確認了微信紅包的功能及步驟：

一）作為發紅包者：

1. 選擇個人／群當作發紅包物件

2. 進入聊天介面，點選右下角“+”——點選第二排第一個“紅包”，進入“填寫紅包資訊”頁面

3. 在第一個輸入框中：輸入金額

4. 在第二個輸入框中：輸入紅包祝福語如果是群發紅包，還會輸入紅包的個數）

5. 點選“塞錢進紅包”

6. 彈出支付提升框，選擇“支付的方式”，點選“確認支付”，輸入密碼／輸入指紋

7. 回到聊天介面，有一個紅包顯示，不會顯示金額，但是會顯示輸入的紅包祝福語

8. 如果該紅包被領取了，會在聊天記錄中，顯示“XXX領取了你的紅包”

9. 再點選紅包，會顯示你發的金額，及領取的人。（如果是在群發紅包，會顯示已領取紅包的個數、金額，領取的人和對應的金額。全部紅包領取完以後，會特別標記領取金額最多人為“手氣最佳者”）

二）作為首紅包者

1. 微信提示，收到紅包（在電腦上不可顯示）

2. 點選紅包——點選“開”

3. 出現領取紅包的資訊，包括：紅包祝福語、金額、“已存入紅包、直接提現”——連結到“微信零錢”、“留言”、“檢視我的紅包記錄”（如果是群發紅包，還可以看到其他人領取的情況和最佳手氣者）

4. 點選左上角“關閉”，聊天記錄出現一條“你已領取XXX紅包”

從測試的內容，我們確認測試從八個方面展開：

1. UI介面測試：包括

• 編寫紅包資訊時，UI介面是否規範合理、無錯別字
• 傳送紅包後，在聊天介面中，紅包顯示是否規範、紅包祝福語是否顯示合理。
• 再他人領取紅包後，點選進紅包，紅包領取資訊是否排版規範（特別是多人領取的情況）
• 其他人領取紅包後／自己領取他人紅包後，在聊天介面顯示領取紅包資訊是否規範、合理

2. 功能測試：

首先進行連結測試：連結頁面的正確

一）發紅包時

• 剛點開一個人／群聊天框，點選右下角“+”，正確顯示各項功能
• 點選“紅包”，正確連結到“填寫紅包資訊”頁面
• 在“填寫紅包資訊”頁面，點選右上角問號，正確連結到“微信紅包疑問解答”頁面
• 在“填寫紅包資訊”頁面點選“關閉”，則離開這個頁面，回到聊天介面

二）在領取紅包時

• 點選紅包，能夠正確彈出“開紅包”
• 點選“開”後，正確連結到領取紅包的資訊
• 在領取紅包資訊頁面，點選“已存入零錢，可用於發紅包”——連結到“零錢”
• 點選“留言”，正確連結到填寫留言頁面
• 點選“檢視我的紅包記錄”，正確連結到“收到的紅包”頁面
• 點選“返回”，返回聊天介面

其次，根據邊界值分析法和等價類劃分法設計測試用例，主要測試功能：

• 輸入金額（在0-200元之間，0元，-1元、200元，201元，0.00元，在特殊日子，測試520等；以及輸入的金額與零錢不足——跳轉到其他支付方式，如果輸入金額其他支付方式也不滿足）
• 輸入紅包個數（0、100、101，超過群成員個數、小數、負數）
• 輸入紅包祝福語：特殊字元、空格、空、超過字串長度
• 在支付時，選擇各種支付方式，輸入密碼／指紋（正確、錯誤）
• 點選紅包（個人紅包／群紅包-可能已經搶完了，不能再搶；已過期紅包-不能再搶）

3. 可用性測試：

• 在輸入框是否可以用快捷鍵
• 輸入框是否支援回車

4. 安全測試

• 在輸入紅包資訊的輸入框中能識別特殊字元、禁止JS指令碼、禁止SQL語句注入
• 過期紅包（>24小時），不能領取，並且退回到零錢裡面
• 呼叫“支付”介面的安全性（支付密碼的安全傳輸、驗證）

5. 效能測試：

即測試在客戶端，發紅包、開啟紅包等響應時間是否符合需求設計；

在伺服器端，資源利用率（CPU使用率，記憶體佔用率），吞吐率，釋出耗時，各介面平均響應時間等等

6. 負載測試

其次，通過增加併發量來測試系統性能情況。

7. 壓力測試

最後，還要進行壓力測試，即評估系統處於、超過預期負載時的處理能力。

還可以進行強度測試：檢查程式對異常情況的抵抗能力，及在極限情況效能下降是否在允許的範圍內。

疲勞強度測試：測試系統在長時間執行後的效能測試表現

8. 相容性測試

• 不同的系統：安卓、蘋果
• 不同的移動裝置：ipad、手機
• 不同的解析度

四、最後釋出

釋出的時候必須要考慮灰度釋出，先讓小部分群體先試用，如果有什麼問題能夠更好更早的發現，然後進行相應的應對措施。

粲粲姐的答案：

第一步，根據需求進行分析，瞭解需求需要實現的是什麼功能，假設我對這個需求比較瞭解，我還會對該需求的風險進行一個初步的判斷。

第二步，我會先去大致瞭解微信紅包的技術架構（定位可能存在問題的瓶頸點）然後根據需求擬定測試方案以及測試用例。測試方案所要考慮的內容比較多且也比較全面，主要包括：測試的範圍（功能測試，效能測試，壓力測試，安全測試，這些測試的測試點，測試的必要性，工具），測試目標，上線質量指標，測試策略，測試輪數，進度安排）測試方案涵蓋所有測試過程，質量保障計劃的提綱和方向。測試用例主要涵蓋需求上的一些功能點以及異常點，邊界值。

第三步，主要開始進行測試，在測試前先搭好測試框架，準備好各種測試要用到的工具，然後按照測試方案流程進行測試。對於微信紅包，最基礎的是要能夠使得需求上的功能點都能正確實現。（這一點可以按照測試用例來進行，比如紅包個數為零時，金額上限），因為考慮到微信紅包的使用者量大，高併發性，所以還需要考慮對各種效能的測試，比如資源利用率（CPU使用率，記憶體佔用率），吞吐率，釋出耗時，各介面平均響應時間等等，然後進行壓力測試。因為使用的使用者範圍廣，自然還要考慮到相容性問題，是否不同的手機都能正常使用這一功能，並且還需要考慮安全測試。如果測試結束後能夠達到上線指標，則可以考慮釋出。

第四步，釋出的時候必須要考慮灰度釋出，先讓小部分群體先試用，如果有什麼問題能夠更好更早的發現，然後進行相應的應對措施。

4. 微信公眾號測試：

1）介面配置測試

由於微信公眾號需要呼叫微信的介面，所以我們首先需要進行呼叫介面配置測試。檢視呼叫介面後，基本原聲功能是否正常執行。例如：自定義選單展示和跳轉、自動回覆等功能

2）功能測試

其次，我們再測試自己設計的各項功能，主要從以下幾個方面：

• 介面測試：檢查佈局是否規範、字型和圖片顯示是否正常
• 連結測試：能夠正確的跳轉公眾號裡面的頁面
• 邏輯功能測試：實現需求中所期望的功能

3）資料庫測試

• 檢查資料庫的一致性：例如使用者提交的表單資訊能否正確存入資料庫並且讀取
• 對特殊字元的處理，例如：如果使用者輸入or，不處理讀進資料庫的話，可能導致嚴重的後果
• 資料庫的加密性：使用者資訊不會被洩漏
• 當訪問量過大時，資料庫查詢效能

4）效能測試

首先，我們設定一個預期的正常使用者訪問量和最高使用者訪問量，然後分別在這兩個數值範圍內設定併發使用者數目，來測試在這些情況下系統的效能，例如：頁面響應時間、記憶體使用情況。

其次，再逐步增加併發使用者量，觀察在各種負載情況下系統的效能，直到達到系統的瓶頸。也就是負載測試

最後，評估系統在處於超過預期併發數（或者記憶體耗盡）的情況下的處理能力。也就是壓力測試。

5）安全性測試

主要考慮三個方面：

1. cookie為HttpOnly，防止XSS攻擊

2. 在自己HTML5頁面中傳輸資料時，資料會加密，不會被攔截

3. 如果與使用者有互動，在使用者輸入框中，對特殊字元有處理、不能輸入指令碼、SQL語句。

6）相容性測試

1. 主流瀏覽器
2. 不同電腦平臺：Windows、Mac
3. 不同移動裝置：iPad、手機（Android、iPhone）
4. 不同解析度

二、實物的測試

1. 杯子的測試

首先分析杯子的設計需求說明書，確定它的介面設計、功能可和另一些製作技術（例如：材質，耐熱程度等），其次從以下幾個方面進行測試：

1. 介面測試

• 杯子圖案是否符合設計需求，印刷合理、規範
• 杯子顏色是否符合設計需求
• 杯子形狀是否符合設計需求
• 杯子上的印刷字型是否符合設計需求、排版合理、沒有錯別字
• 杯子的重量是否符合設計需求
• 杯子是否有異味

2. 功能測試

根據杯子的用途、規格、承受的冷熱程度等（假設杯子的規格為：100ml，杯子承受的最高溫度：100度），依據邊界值分析法和等價類劃分法，確認測試用例如下：

• 杯子能否裝100ml的水
• 杯子盛入50攝氏度的水
• 杯子盛入100攝氏度的水
• 杯子盛入0攝氏度的水
• 快速的裝滿水，看是否漏水
• 裝滿水後，放置幾天，檢視是否漏水
• 用過幾天以後，杯子的內壁顏色是否脫落

3. 安全性測試

• 杯子的材料是否有害人身體健康
• 放入微波爐中，是否會爆炸、融化
• 從桌子掉到水泥地會否破碎
• 杯子邊緣是否有缺口，容易劃傷嘴巴
• 杯子內壁的燃料會否溶解到水中

4. 可用性測試

• 是否容易導熱-燙手
• 是否有杯柄，方便端
• 杯子是否有防滑墊

2. 對一個自動販賣機進行功能測試

3. 對A4紙測試

2. 測試一個三角形

例子：有一個app，輸入三角形的三條邊長，判斷是否能構成一個三角形（不考慮退化三角形，即面積為零的三角形），是什麼樣的三角形（直角、銳角、鈍角、等邊、等腰）。——考慮app相容性！！

函式宣告為：byte GetTriangleType(int ,int, int)。

（1） 如何用一個byte來表示各種輸出情況？

（2） 如果你是一名測試工程師，應該如何寫測試用例來完成功能測試呢？

答：

步驟一：分析這個函式的功能。

首先這個函式需要根據輸入的a、b、c

• 判斷是否為三角形：
• 識別等腰三角形
• 識別等邊三角形
• 識別直角三角形
• 識別銳角三角形
• 識別鈍角三角形

其次，用一個byte表示所有的輸出情況。

步驟二：

首先根據等價化分類劃分輸入的等價類，用邊界法來補充。

其次用一個byte表示所有的情況，1個byte有8位，考慮用0、1標誌位編碼表示輸出的情況。例如：byte從右到左，第0位表示等腰三角形、第1位是等邊三角形。。。第七位是三角形標誌，剩餘的第6位和第5位可以留作錯誤編碼，比如用於表示兩邊之和小於第三邊等。

分析條件有：

1. 是否是三角形：

(1) a>0

(2) b>0

(3) c>0

(4) a+b>c

(5) a+c>b

(6) b+c>a

(7)a<=0

(8)b<=0

(9)c<=0

(10)a+b<=c

(11)b+c<=a

(12)c+a<=b

2. 是否是等腰三角形

(13) a=b

(14) b=c

(15) a=c

(16) a^2 + b^2 >c^2

(17) b^2 + c^2 >a^2

(18) a^2 + c^2 >b^2 

(19) (a!=b)and(a!c)and(b!c)

3.是否是等腰直角三角形

(20) (A=B)and(A^2+B^2=C^2)  
(21) (B=C)and(B^2+C^2=A^2)  
(22) (C=A)and(C^2+A^2=B^2) 

4. 是否是等邊三角形
(23) (A=B)and(B=C)and(C=A)    
(24) (A!=B)     (21)
(25) (B!=C)    (22)
(26) (C!=A)    (23)

再根據邊界值法補充測試用例：

(27) 三個零

(28) 有特殊字元

(29) 超過邊界值

測試用例id	條件	輸入	預期輸出	描述
1	(1)-(6)	(3, 4, 5)	10001000	銳角三角形
2	(7)	(1, 1, 3)	00000000	非三角形
3	(8)	(0, 2, 3)	00000000	非三角形
4	(9)	(1,0,2)	00000000	非三角形
5	(10)	(1, 2, 3)	00000000	非三角形
6	(11)	(1, 3, 2)	00000000	非三角形
7	(12)	(3, 1, 2)	00000000	非三角形
8	(1)-(6)、(13)(16)	(3, 3, 4)	1	等腰三角形
9	(1)-(6)、(14)(17)	(3, 4, 4)	等腰三角形
10	(1)-(6)、(15)(18)	(3 ,4, 3)	等腰三角形
11	(1)-(6)、(20)	(2, 2, ^2)
12	(1)
13
14
15
16
17	(a, 1, 2)
18	(@, 2, 3)
19

三、函式的測試

1. 對函式str()的測試

 主要考察：邊界、基本情況、魯棒性、效能及演算法優化

2. 個函式實現對字串中第三個字元的替換，設計測試用例

四、Linux下命令的測試

1. cp命令設計測試用例