測試開發(fā)崗-高頻知識整理【春招】 ，內(nèi)附面試題答案！

毛屌屌

1. 本文內(nèi)容來源：本文是將自己在20年里找工作的部分筆記重新整理了下，不少內(nèi)容當(dāng)時是查閱的知乎、博客園、書籍等(部分還能找到原帖的均附上了鏈接)。我自己在這一年里也是從牛客上學(xué)習(xí)了很多面經(jīng)和經(jīng)驗帖，收獲了好幾家大廠offer。最近整理出來這些，也算是回饋?？桶桑Ｍ軐φ覝y開崗的朋友們有幫助！

2. 本文內(nèi)容順序：測試基礎(chǔ)理論、測試崗經(jīng)常被問到的場景題、智力題、測試崗高頻算法題、數(shù)據(jù)庫、 Linux知識點。

3. 本文閱讀建議：我結(jié)合了自身的面試經(jīng)歷，把高頻的、重要的知識點都用★標(biāo)注了，★越多代表自己被問得次數(shù)越多。(當(dāng)然這也只是我的面試經(jīng)歷，存在局限性。）

4. 叨逼叨：親測，測試崗的面試難度相對開發(fā)崗確實低一些，不過面試的內(nèi)容差別倒不是特別大，像計網(wǎng)、OS、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)庫、算法/刷題這些都是要準(zhǔn)備的，并且測試崗的面試還需要你額外掌握測試相關(guān)的知識，也就是本文的一、二兩部分內(nèi)容。不然你叫面試官怎么想你呢？你一點測試的理論知識都不了解，對方只會覺得你大概率是做不來開發(fā)才想著試試測試崗吧，所以得快速支棱起自己的測試技能樹，讓面試官覺得你是有志于干測試開發(fā)的。 這一點很重要。

常用自動化測試工具

1、Appium
官網(wǎng)： Mobile App Automation Made Awesome.

AppUI自動化測試
Appium 是一個移動端自動化測試開源工具，支持iOS 和Android 平臺，支持Python、Java 等語言，即同一套Java Python 腳本可以同時運行在iOS 和Android平臺，Appium 是一個C/S 架構(gòu)， 核心是一個 Web 服務(wù)器，它提供了一套 REST 的接口。當(dāng)收到客戶端的連接后，就會監(jiān)聽到命令，然后在移動設(shè)備上執(zhí)行這些命令，最后將執(zhí)行結(jié)果放在 HTTP 響應(yīng)中返還給客戶端。
License：免費

2、Selenium（★★）
官網(wǎng)： https://www.seleniumhq.org/download/

WebUI自動化測試
Selenium是一個用于Web應(yīng)用程序測試的工具，Selenium已經(jīng)成為Web自動化測試工程師的首選。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操作一樣。支持的瀏覽器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。這個工具的主要功能包括：測試與瀏覽器的兼容性——測試你的應(yīng)用程序看是否能夠很好得工作在不同瀏覽器和操作系統(tǒng)之上。測試系統(tǒng)功能——創(chuàng)建回歸測試檢驗軟件功能和用戶需求。支持自動錄制動作和自動生成 .Net、Java、Perl等不同語言的測試腳本。Selenium 是ThoughtWorks專門為Web應(yīng)用程序編寫的一個驗收測試工具。其升級版本為Webdriver。
License：免費

3、Postman（★★★）
官網(wǎng)： https://www.getpostman.com
接口測試
Postman 提供功能強(qiáng)大的 Web API 和 HTTP 請求的調(diào)試，它能夠發(fā)送任何類型的HTTP 請求 (GET, POST, PUT, DELETE…)，并且能附帶任何數(shù)量的參數(shù)和 Headers。不僅如此，它還提供測試數(shù)據(jù)和環(huán)境配置數(shù)據(jù)的導(dǎo)入導(dǎo)出，付費的 Post Cloud 用戶還能夠創(chuàng)建自己的 Team Library 用來團(tuán)隊協(xié)作式的測試，并能夠?qū)⒆约旱臏y試收藏夾和用例數(shù)據(jù)分享給團(tuán)隊。
License：免費

4、Jmeter（★★★）
官網(wǎng)： https://jmeter.apache.org
接口測試，性能測試
JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現(xiàn)；
JMeter可以用于測試靜態(tài)或者動態(tài)資源的性能（文件、Servlets、Perl腳本、java對象、數(shù)據(jù)庫和查詢、ftp服務(wù)器或者其他的資源）。JMeter用于模擬在服務(wù)器、網(wǎng)絡(luò)或者其他對象上附加高負(fù)載以測試他們提供服務(wù)的受壓能力，或者分析他們提供的服務(wù)在不同負(fù)載條件下的總性能情況。你可以用JMeter提供的圖形化界面分析性能指標(biāo)或者在高負(fù)載情況下測試服務(wù)器/腳本/對象的行為。

使用Jmeter做接口測試需要注意一點，小心使用“用戶定義變量”，Jmeter組件有優(yōu)先級的，如果多個線程同時執(zhí)行的時候，“用戶定義變量”組件定義的變量可能會亂套。
License：免費

5、Loadrunner
官網(wǎng)： https://software.microfocus.com/en-us/products/loadrunner-load-testing/overview

性能測試
LoadRunner，是一種預(yù)測系統(tǒng)行為和性能的負(fù)載測試工具。通過以模擬上千萬用戶實施并發(fā)負(fù)載及實時性能監(jiān)測的方式來確認(rèn)和查找問題，LoadRunner能夠?qū)φ麄€企業(yè)架構(gòu)進(jìn)行測試。企業(yè)使用LoadRunner能最大限度地縮短測試時間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。 LoadRunner可適用于各種體系架構(gòu)的自動負(fù)載測試，能預(yù)測系統(tǒng)行為并評估系統(tǒng)性能。
License：商業(yè)
6、Jenkins（★★★★★）
官網(wǎng)： https://jenkins.io
持續(xù)集成
自動化構(gòu)建 編譯，部署，任務(wù)執(zhí)行，測試報告，郵件通知等。
License：免費
手機(jī)兼容性測試(機(jī)型選擇)

登錄/注冊后可看大圖

測試基礎(chǔ)理論

登錄/注冊后可看大圖

軟件測試開發(fā)流程：

1.需求分析
在測試前拿到產(chǎn)品需求文檔，進(jìn)行需求分析及需求評審前先對需求文檔進(jìn)行詳細(xì)的閱讀，對有疑問的地方進(jìn)行標(biāo)注。
具體可從以下進(jìn)行：
a.分析產(chǎn)品功能點
b.產(chǎn)品核心競爭力
c.Kano模型、馬斯洛需求分析、多問幾個為什么、上下文分析法

2.制訂測試用例（重要）
工欲善其事，必先利其器；對測試而言，測試用例就是器，做好了才能把好關(guān)
a.使用思維導(dǎo)圖列舉測試大綱，盡量發(fā)散，想到什么就寫什么，；先放后收，對知識點進(jìn)行總結(jié)和歸納，標(biāo)記重點測試模塊，刪除冗余及重復(fù)測試點。
b.可使用邊界值法、等價類劃分法、錯誤推測法、因果圖法等設(shè)計案例
c.根據(jù)測試大綱制定測試用例，需包含模塊名、測試優(yōu)先級、操作步驟、期望結(jié)果、測試結(jié)果、備注
3.評審測試用例
a.測試作為主導(dǎo)，聯(lián)合開發(fā)、項目經(jīng)理、PM進(jìn)行測試用例評審
b.可先講解測試大綱，讓開發(fā)、項目經(jīng)理、PM心中對測試用例有個大概；后再進(jìn)行詳細(xì)測試用例講解
4.執(zhí)行測試
a.根據(jù)測試用例執(zhí)行測試
b.發(fā)現(xiàn)問題保留現(xiàn)場，記錄測試方法，通知開發(fā)解決問題
c.覆蓋測試用例之外若有時間可進(jìn)行探索性測試
5.提交Bug并推動Bug解決
a.在Bug管理工具上提交Bug，詳細(xì)記錄測試步驟
b.根據(jù)Bug嚴(yán)重程度劃分Bug等級:致命、嚴(yán)重、一般、提示
c.推動開發(fā)解決問題，記錄問題進(jìn)展，一般聊天溝通，若問題嚴(yán)重則需通過郵件推動解決
6.回歸測試
a.對已修復(fù)的Bug進(jìn)行驗證
b.對Bug所在模塊進(jìn)行基本功能測試；整體進(jìn)行冒煙測試，確保不會因為修改Bug而引起其他功能出現(xiàn)問題
7.編寫并提交測試報告
可使用金字塔原理設(shè)計測試報告，先總后分，上級統(tǒng)領(lǐng)下級，下級推導(dǎo)出上級，環(huán)環(huán)相扣
a.對Bug進(jìn)行匯總，篩選出各個等級的Bug存活情況
b.制訂Bug發(fā)現(xiàn)及解決曲線圖，一般版本正常應(yīng)是前期多，后期收斂，存活的是級別較低的Bug
c.總結(jié)歸納版本情況，評估發(fā)布與否

軟件測試方法（★★★★★）
1. 軟件測試方法 ：白盒測試、黑盒測試、灰盒測試、靜態(tài)測試、動態(tài)測試
2. 白盒測試 ：是一種測試用例設(shè)計方法，在這里盒子指的是被測試的軟件，白盒，顧名思義即盒子是可視的，你可以清楚盒子內(nèi)部的東西以及里面是如何運作的，因此白盒測試需要你對系統(tǒng)內(nèi)部的結(jié)構(gòu)和工作原理有一個清楚的了解，并且基于這個知識來設(shè)計你的用例。
白盒測試技術(shù)一般可被分為靜態(tài)分析和動態(tài)分析兩類技術(shù)。
靜態(tài)分析主要有：控制流分析技術(shù)、數(shù)據(jù)流分析技術(shù)、信息流分析技術(shù)。
動態(tài)分析主要有：邏輯覆蓋率測試(分支測試、路徑測試等)，程序插裝等。
白盒測試優(yōu)點：迫使測試人員去仔細(xì)的思考軟件的實現(xiàn)；可以檢測代碼中的每條分支和路徑；揭示隱藏在代碼中的錯誤；對代碼的測試比較徹底；最優(yōu)化。

白盒測試缺點：昂貴；無法檢測代碼中遺漏的路徑和數(shù)據(jù)敏感性錯誤；不驗證規(guī)格的正確性
3. 黑盒測試又叫功能測試 ，這是因為在黑盒測試中主要關(guān)注被測軟件的功能實現(xiàn)，而不是內(nèi)部邏輯。在黑盒測試中，被測對象的內(nèi)部結(jié)構(gòu)，運作情況對測試人員是不可見的，測試人員對被測產(chǎn)品的驗證主要是根據(jù)其規(guī)格，驗證其與規(guī)格的一致性。
在絕大多數(shù)沒有用戶參與的黑盒測試中，最常見的測試有：功能性測試、容量測試、安全性測試、負(fù)載測試、恢復(fù)性測試、標(biāo)桿測試、穩(wěn)定性測試、可靠性測試等。
4. 灰盒測試 ：白盒測試和黑盒測試往往不是決然分開的，一般在白盒測試中交叉使用黑盒測試的方法，在黑盒測試中交叉使用白盒測試的方法?；液袦y試就是這類界于白盒測試和黑盒測試之間的測試。
最常見的灰盒測試是集成測試 。
5. 靜態(tài)測試 ：是一種不通過執(zhí)行程序而進(jìn)行測試的技術(shù)。它的關(guān)鍵功能是檢查軟件的表示和描述是否一致，沒有沖突或者沒有歧義。
6. 動態(tài)測試 ：包含了程序在受控的環(huán)境下使用特定的期望結(jié)果進(jìn)行正式的運行。它顯示了一個系統(tǒng)在檢查狀態(tài)下是正確還是不正確。
單元測試屬于白盒測試范疇；集成測試屬于灰盒測試范疇；系統(tǒng)測試屬于黑盒測試范疇 。
CI/CD理解（★★★★★）
摘自 如何理解持續(xù)集成、持續(xù)交付、持續(xù)部署？ - yumminhuang的回答 - 知乎 如何理解持續(xù)集成、持續(xù)交付、持續(xù)部署？
持續(xù)集成

登錄/注冊后可看大圖

持續(xù)集成強(qiáng)調(diào)開發(fā)人員提交了新代碼之后，立刻進(jìn)行構(gòu)建、（單元）測試。根據(jù)測試結(jié)果，我們可以確定新代碼和原有代碼能否正確地集成在一起。
持續(xù)交付

登錄/注冊后可看大圖

持續(xù)交付在持續(xù)集成的基礎(chǔ)上，將集成后的代碼部署到更貼近真實運行環(huán)境的「類生產(chǎn)環(huán)境」（production-like environments）中。比如，我們完成單元測試后，可以把代碼部署到連接數(shù)據(jù)庫的 Staging 環(huán)境中更多的測試。如果代碼沒有問題，可以繼續(xù)手動部署到生產(chǎn)環(huán)境中。
持續(xù)部署

登錄/注冊后可看大圖

持續(xù)部署則是在持續(xù)交付的基礎(chǔ)上，把部署到生產(chǎn)環(huán)境的過程自動化。
我個人覺得持續(xù)集成、持續(xù)交付、持續(xù)部署非常值得推廣。開發(fā)過程中最怕集成時遇到問題導(dǎo)致返工，而持續(xù)集成、持續(xù)交付、持續(xù)部署恰恰可以早發(fā)現(xiàn)早解決，從而可以避免這個問題。

接口文檔（★★★）
一、什么是接口文檔？
在項目開發(fā)中，web項目的前后端分離開發(fā)，APP開發(fā)，需要由前后端工程師共同定義接口，編寫接口文檔，之后大家都根據(jù)這個接口文檔進(jìn)行開發(fā)，到項目結(jié)束前都要一直維護(hù)。
二、為什么要寫接口文檔？
1、項目開發(fā)過程中前后端工程師有一個統(tǒng)一的文件進(jìn)行溝通交流開發(fā)
2、項目維護(hù)中或者項目人員更迭，方便后期人員查看、維護(hù)
三、接口規(guī)范是什么？
首先接口分為四部分：方法、uri、請求參數(shù)、返回參數(shù)
1、方法:新增(post) 修改(put) 刪除(delete) 獲取(get)
持續(xù)部署則是在持續(xù)交付的基礎(chǔ)上，把部署到生產(chǎn)環(huán)境的過程自動化。
我個人覺得持續(xù)集成、持續(xù)交付、持續(xù)部署非常值得推廣。開發(fā)過程中最怕集成時遇到問題導(dǎo)致返工，而持續(xù)集成、持續(xù)交付、持續(xù)部署恰恰可以早發(fā)現(xiàn)早解決，從而可以避免這個問題。

接口文檔（★★★）
一、什么是接口文檔？
在項目開發(fā)中，web項目的前后端分離開發(fā)，APP開發(fā)，需要由前后端工程師共同定義接口，編寫接口文檔，之后大家都根據(jù)這個接口文檔進(jìn)行開發(fā)，到項目結(jié)束前都要一直維護(hù)。
二、為什么要寫接口文檔？
1、項目開發(fā)過程中前后端工程師有一個統(tǒng)一的文件進(jìn)行溝通交流開發(fā)
2、項目維護(hù)中或者項目人員更迭，方便后期人員查看、維
三、接口規(guī)范是什么？
首先接口分為四部分：方法、uri、請求參數(shù)、返回參數(shù)
1、方法:新增(post) 修改(put) 刪除(delete) 獲取(get)
示例：
請求地址：get /a/student/list
請求參數(shù)：

登錄/注冊后可看大圖

返回參數(shù)：

登錄/注冊后可看大圖

單元測試（★★★）
理解：類比電視機(jī)組裝完后不能點亮，如果檢測的話，需要一個一個電器器件去排查。如果從一開始對每個元器件進(jìn)行測試，就能夠極大程度的排除這個問題。
定義：單元測試是指，對軟件中的最小可測試單元在與程序其他部分相隔離的情況下進(jìn)行檢查和驗證的工作，這里的 最小可 測試單元通常是指 函數(shù)或者 類。

單元測試通常由開發(fā)工程師完成，一般會伴隨開發(fā)代碼一起遞交至代碼庫。單元測試屬于 最嚴(yán)格的軟件測試手段，是最接近代碼 底層實現(xiàn)的驗證手段，可以在軟件開發(fā)的早期以最小的成本保證局部代碼的質(zhì)量。另外，單元測試都是以自動化的方式執(zhí)行，所以在大量 回歸測試的場景下更能帶來高收益。

如何設(shè)計一個好的測試用例：（★★★）
“好的”測試用例一定是一個 完備 的集合，它能夠 覆蓋所有等價類 以及各種 邊界值 ，而跟能否發(fā)現(xiàn)缺陷無關(guān)。

一個“好的”測試用例，必須具備以下 三個特征 。
1. 整體完備性 ： “好的”測試用例一定是一個完備的整體，是有效測試用例組成的集合，能夠完全覆蓋測試需求。
2. 等價類劃分的準(zhǔn)確性 ： 指的是對于每個等價類都能保證只要其中一個輸入測試通過，其他輸入也一定測試通過。
3. 等價類集合的完備性 ： 需要保證所有可能的邊界值和邊界條件都已經(jīng)正確識別。

三種最常用的測試用例設(shè)計方法：
等價類劃分法、邊界值分析法、錯誤推測方法。
第一，等價類劃分法
我們只要從每個等價類中任意選取一個值進(jìn)行測試，就可以用少量具有代表性的測試輸入取得較好的測試覆蓋結(jié)果。

現(xiàn)在，我給你看一個具體的例子：學(xué)生信息系統(tǒng)中有一個“考試成績”的輸入項，成績的取值范圍是0~100之間的整數(shù)，考試成績及格的分?jǐn)?shù)線是60。為了測試這個輸入項，顯然不可能用0~100的每一個數(shù)去測試。通過需求描述可以知道，輸入0~59之間的任意整數(shù)，以及輸入60~100之間的任意整數(shù)，去驗證和揭露輸入框的潛在缺陷可以看做是等價的。

那么這就可以在0~59和60~100之間各隨機(jī)抽取一個整數(shù)來進(jìn)行驗證。這樣的設(shè)計就構(gòu)成了所謂的“有效等價類”。

你不要覺得進(jìn)行到這里，已經(jīng)完成了等價類劃分的工作，因為 等價類劃分方法的另一個關(guān)鍵點是要找出所有“無效等價類” 。顯然，如果輸入的成績是負(fù)數(shù)，或者是大于100的數(shù)等都構(gòu)成了“無效等價類”。
在考慮了無效等價類后，最終設(shè)計的測試用例為：

有效等價類1：0~59之間的任意整數(shù)；
有效等價類2：59~100之間的任意整數(shù)；
無效等價類1：小于0的負(fù)數(shù)；
無效等價類2：大于100的整數(shù)；
無效等價類3：0~100之間的任何浮點數(shù)；
無效等價類4：其他任意非數(shù)字字符。

第二，邊界值分析方法
邊界值分析是對等價類劃分的補(bǔ)充，你從工程實踐經(jīng)驗中可以發(fā)現(xiàn)，大量的錯誤發(fā)生在輸入輸出的邊界值上，所以需要對邊界值進(jìn)行重點測試，通常選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)。
我們繼續(xù)看學(xué)生信息系統(tǒng)中“考試成績”的例子，選取的邊界值數(shù)據(jù)應(yīng)該包
括：-1，0，1，59，60，61，99，100，101。

第三，錯誤推測方法
錯誤推測方法是指 基于對被測試軟件系統(tǒng)設(shè)計的理解、過往經(jīng)驗以及個人直覺，推測出軟件可能存在的缺陷，從而有針對性地設(shè)計測試用例的方法。 這個方法強(qiáng)調(diào)的是對被測試軟件的需求理解以及設(shè)計實現(xiàn)的細(xì)節(jié)把握，當(dāng)然還有個人的能力。
錯誤推測法和目前非常流行的“探索式測試方法”的基本思想和理念是不謀而合的，這類方法在目前的敏捷開發(fā)模式下的投入產(chǎn)出比很高，因此被廣泛應(yīng)用。但是，這個方法的缺點也顯而易見，那就是難以系統(tǒng)化，并且過度依賴個人能力。
總結(jié)：在我看來，深入理解被測軟件需求的最好方法是，測試工程師在需求分析和設(shè)計階段就開始介入，因為這個階段是理解和掌握軟件的原始業(yè)務(wù)需求的最好時機(jī)。
上文摘自《測試工程師全棧技術(shù)進(jìn)階與實踐》 茹炳晟

針對某一個產(chǎn)品寫測試用例：（★★★★★）
此類問題幾乎每個面試官都會問！基本思路：可以從功能測試，UI測試，穩(wěn)定性測試，壓力測試（邊界極限），安全測試，本地化測試等角度去考慮

測試水杯（★）
1、基本功能測試
硬度：是否達(dá)到設(shè)計標(biāo)準(zhǔn)
裝載能力：在杯子內(nèi)分別裝入少量的、半杯的、潢杯的，看其裝載量是否達(dá)到設(shè)計標(biāo)準(zhǔn)
裝載種類：開水(是否產(chǎn)生異味）、溫水、冷水、咖啡
用水杯裝水看漏不漏；水能不能被喝到
輸入條件： 冷水，熱水，冰水。。。
輸出條件： 是否退色 是否變形 是否有毒
一杯開水（假定100攝氏度）保溫的時間（多久后變到室溫），自然還有冰塊在室溫下多長時間融化

2、界面測試(UI測試)
看其形狀、大小設(shè)計是否符合需求規(guī)格說明書的定義，適合人方便拿起喝水；
外觀是否吸引人，賞心悅目；
廣告圖案沾水后是否掉色、模糊；
廣告圖案是否使用環(huán)保材料、不影響使用者健康和回收再利用；
廣告圖案是否和當(dāng)?shù)卣?、宗教符合，沒有沖突；
廣告圖案是否做到了本地化和國際化。

3、易用性測試
看其形狀、大小設(shè)計是否適合人方便拿起；
殘疾人士用此杯去喝水的容易程度；
杯子設(shè)計是否上大下小，在運輸過程中可以套在一起有效利用空間，在使用時也容易拿開

4、穩(wěn)定性測試（24*7）
裝入液體后記錄其多久以后會漏水；

5、安全性測試
杯子所用的材料（包括紙基、涂層和廣告顏料)是否符合食品衛(wèi)生標(biāo)準(zhǔn)，在內(nèi)外溫度待環(huán)境因素下是否會與所盛各種飲料反應(yīng)，而產(chǎn)生對人體有害的物質(zhì)；

6、本地化測試
為國際化和本地化的需要，廣告圖案和文字是否在政治、宗教和文化方面具有廣泛的適用性；
安全性：杯子有沒有毒或細(xì)菌；
可靠性：杯子從不同高度落下的損壞程度；
可移植性：杯子再不同的地方、溫度等環(huán)境下是否都可以正常使用；

7、對設(shè)計的改進(jìn)建議
“如果是一次性杯子，能否標(biāo)示已使用(比如：變色)”和“杯子是否有使用者標(biāo)貼（多人使用時防止混淆)”。
壓力測試：用根針并在針上面不斷加重量，看壓強(qiáng)多大時會穿透

8、 性能測試
溫度/杯質(zhì)的抗壓力/壽命/廣告漆的耐久度/等等

測試一個輸入框(計數(shù))（★★）
相信不少朋友在筆試的時候都遇到過測試用例設(shè)計的筆試題。通常是一個登陸頁面，上面有用戶名，密碼的輸入框，再多一點的有個驗證碼。
不過要是你見到的是以下的這道測試用例設(shè)計筆試題，不用問，面試官一定是看過《Google軟件測試之道》的。（也腦補(bǔ)一下，萬一面試官是看過CC先生的簡書呢…… 嗯嗯，夢想還是要有的）

出題時間：
在一個Web測試頁面上，有一個輸入框，一個計數(shù)器（count）按鈕，用于計算一個文本字符串中字母a出現(xiàn)的個數(shù)。這里的問題是，請設(shè)計一系列測試用例用以測試這個Web頁面。

登錄/注冊后可看大圖

很多朋友可能拿到這道題的時候已經(jīng)開始寫下1.2.3.了，不過根據(jù)經(jīng)驗上來說，追求數(shù)量而非質(zhì)量的傾向，是一種低效的工作方式。（特別在有面試官在旁邊看到你答題的時候，請保持沉思者狀保持10-15秒）
能夠針對題目提出一些問題來的候選者會被認(rèn)為更有潛質(zhì)來做測試人員，比如大寫還是小寫？只是英語嗎？計算完成后文本會被清除嗎？多次按下按鈕會發(fā)生什么事情？諸如此類。

通常說來，我們考慮一個測試對象的時候至少從以下六方面來考慮。
功能性
易用性
可靠性
性能
安全
兼容性
如果你是一個測試菜鳥，從功能性出發(fā)，你可能會列出以下一個典型的列表：

“banana”：3（一個合法的英文字）。
“A” 和“a”：1（一個簡單有正常結(jié)果的合法輸入）。
“”：0（一個簡單的結(jié)果為0的合法輸入）。
Null：0（簡單的錯誤輸入）。
“AA” 和“aa”：2（個數(shù)大于1并且所有字符都為a/A的輸入）。
“b”：0（一個簡單的非空合法輸入，結(jié)果為0）。
“aba”：2（目標(biāo)字符出現(xiàn)在開頭和結(jié)尾，以尋找循環(huán)邊界錯誤）。
“bab”：1（目標(biāo)字符出現(xiàn)在中間）。
space/tabs：N（空白字符與N個a的混合）。
不包含a的長字符串：N（N大于0）。
包含a的長字符串：N（N是a的倍數(shù)，試試龍媽的名字）。
{java/C/HTML/JavaScript}：N是a出現(xiàn)的個數(shù)（可執(zhí)行字符，或錯誤，或代碼解釋）。

….

更優(yōu)秀的測試工程師，會開始考慮后面五個方面，設(shè)計以下用例。
質(zhì)疑界面的外觀、調(diào)色板和對比度（這與相關(guān)應(yīng)用風(fēng)格一致么？）
文本框太小了，建議加長以便顯示更長的輸入字符串
這個應(yīng)用能否在同一臺服務(wù)器上運行多個實例，多個用戶同時使用是否會有問題。
是否會根據(jù)用戶的輸入自動匹配內(nèi)容？
建議使用真實的數(shù)據(jù)，如從詞典或書中選擇輸入內(nèi)容。
提出疑問：“輸入的數(shù)據(jù)是否會被保存”，輸入字符串可能包含地址或其他身份信息。
輸入HTML和JavaScrip，看是否會破壞頁面渲染。
嘗試復(fù)制/粘貼字符串。
提出疑問：“計算足夠快么？在大并發(fā)下使用”。
提出疑問：“用戶怎么找到該頁面？”
提出疑問：“有快捷鍵的設(shè)置么？比如輸完字符后敲入回車鍵而不是點擊提交按鈕”
還有一些測試點，只有經(jīng)驗豐富的測試工程師才會想到。

意識到計算會通過URL-encodedHTTP GET請求傳遞到服務(wù)器，字符串可能會在網(wǎng)絡(luò)傳輸時被截斷，因此，無法保證支持多長的URL。
建議將此功能參數(shù)化，為什么只對字母a計算呢？
考慮計算其它語言中的a（α，Alpha）。
考慮到該應(yīng)用是否應(yīng)該國際化。
考慮到輸入法全角輸入和半角輸入是否相同。
考慮編寫腳本或者手工采樣來探知字符串長度的上限，然后確保在此區(qū)間內(nèi)功能正常。
考慮背后的實現(xiàn)和代碼。也許已經(jīng)有一個計數(shù)器遍歷該字符串。
提出疑問：“HTTP POST方法和參數(shù)會被黑掉碼？也許有安全漏洞？”
用腳本創(chuàng)建各種有趣的排列組合和字符串特性，如長度、a的個數(shù)等，自動生成測試輸入和驗證。
針對“用戶登錄”設(shè)計測試用例（★★★）
以用戶登錄為例，一般的小白可能只能夠想到一些功能性測試（如下）。

現(xiàn)在，針對“用戶登錄”功能，基于等價類劃分和邊界值分析方法，我們設(shè)計的測試用例包括：

1. 輸入已注冊的用戶名和正確的密碼，驗證是否登錄成功；

2. 輸入已注冊的用戶名和不正確的密碼，驗證是否登錄失敗，并且提示信息正確；

3. 輸入未注冊的用戶名和任意密碼，驗證是否登錄失敗，并且提示信息正確；

4. 用戶名和密碼兩者都為空，驗證是否登錄失敗，并且提示信息正確；

5. 用戶名和密碼兩者之一為空，驗證是否登錄失敗，并且提示信息正確；

6. 如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸入正確的驗證碼，驗證是否登錄成功；

7. 如果登錄功能啟用了驗證碼功能，在用戶名和密碼正確的前提下，輸入錯誤的驗證碼，驗證是否登
錄失敗，并且提示信息正確。
的確，上面的測試用例集已經(jīng)涵蓋了主要的功能測試場景。但是在一個優(yōu)秀的測試工程師眼中，這些用例只能達(dá)到勉強(qiáng)及格的標(biāo)準(zhǔn)。
現(xiàn)在，我跟你分享一下有經(jīng)驗的測試工程師會再增加的測試用例：
1. 用戶名和密碼是否大小寫敏感；
2. 頁面上的密碼框是否加密顯示；
3. 后臺系統(tǒng)創(chuàng)建的用戶第一次登錄成功時，是否提示修改密碼；
4. 忘記用戶名和忘記密碼的功能是否可用；
5. 前端頁面是否根據(jù)設(shè)計要求限制用戶名和密碼長度；
6. 如果登錄功能需要驗證碼，點擊驗證碼圖片是否可以更換驗證碼，更換后的驗證碼是否可用；
7. 刷新頁面是否會刷新驗證碼；
8. 如果驗證碼具有時效性，需要分別驗證時效內(nèi)和時效外驗證碼的有效性；
9. 用戶登錄成功但是會話超時后，繼續(xù)操作是否會重定向到用戶登錄界面；
10. 不同級別的用戶，比如管理員用戶和普通用戶，登錄系統(tǒng)后的權(quán)限是否正確；
11. 頁面默認(rèn)焦點是否定位在用戶名的輸入框中；
12. 快捷鍵Tab 和Enter等，是否可以正常使用。

從軟件測試的維度來看，還應(yīng)該包含非功能性需求。主要涉及 安全性、性能以及兼容性 三大方面。 在上面所有的測試用例設(shè)計中，我們完全沒有考慮對非功能性需求的測試，但這些往往是決定軟件質(zhì)量的關(guān)鍵因素。

安全性測試用例包括：
1. 用戶密碼后臺存儲是否加密；
2. 用戶密碼在網(wǎng)絡(luò)傳輸過程中是否加密；
3. 密碼是否具有有效期，密碼有效期到期后，是否提示需要修改密碼；
4. 不登錄的情況下，在瀏覽器中直接輸入登錄后的URL地址，驗證是否會重新定向到用戶登錄界面；
5. 密碼輸入框是否不支持復(fù)制和粘貼；
6. 密碼輸入框內(nèi)輸入的密碼是否都可以在頁面源碼模式下被查看；
7. 用戶名和密碼的輸入框中分別輸入典型的“SQL注入攻擊”字符串，驗證系統(tǒng)的返回頁面；
8. 用戶名和密碼的輸入框中分別輸入典型的“XSS跨站腳本攻擊”字符串，驗證系統(tǒng)行為是否被篡改；
9. 連續(xù)多次登錄失敗情況下，系統(tǒng)是否會阻止后續(xù)的嘗試以應(yīng)對暴力破解；
10. 同一用戶在同一終端的多種瀏覽器上登錄，驗證登錄功能的互斥性是否符合設(shè)計預(yù)期；
11. 同一用戶先后在多臺終端的瀏覽器上登錄，驗證登錄是否具有互斥性。

性能壓力測試用例包括:
1. 單用戶登錄的響應(yīng)時間是否小于3秒；
2. 單用戶登錄時，后臺請求數(shù)量是否過多；
3. 高并發(fā)場景下用戶登錄的響應(yīng)時間是否小于5秒
4. 高并發(fā)場景下服務(wù)端的監(jiān)控指標(biāo)是否符合預(yù)期；
5. 高集合點并發(fā)場景下，是否存在資源死鎖和不合理的資源等待；
6. 長時間大量用戶連續(xù)登錄和登出，服務(wù)器端是否存在內(nèi)存泄漏。

兼容性測試用例包括：
1. 不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
2. 相同瀏覽器的不同版本下，驗證登錄頁面的顯示以及功能正確性；
3. 不同移動設(shè)備終端的不同瀏覽器下，驗證登錄頁面的顯示以及功能正確性；
4. 不同分辨率的界面下，驗證登錄頁面的顯示以及功能正確性。

微信紅包測試用例（★★★★★）
單個紅包：
1、紅包金額為空、0、0.01、200.00、200.01、199.99、200
2、留言輸入數(shù)字、字母、漢字、特殊字符
3、留言長度
4、留言復(fù)制粘貼
5、表情選擇收藏表情、其他表情
6、刪除表情、重新選擇表情
7、選擇支付方式 零錢、銀行卡、添加新卡支付。其中錢數(shù)<紅包錢數(shù)、其中錢數(shù)=紅包錢數(shù)、其中錢數(shù)>紅包錢數(shù)
8、使用指紋確認(rèn)付款（正確的、錯誤的指紋）
9、使用密碼確認(rèn)付款（正確的、錯誤的密碼）
10、紅包成功發(fā)送后 相應(yīng)支付方式中錢數(shù)減少（減少金額與紅包金額一致）
11、接受者能看到紅包具體信息，紅包金額、留言、表情均能正確顯示
12、紅包被拆開后顯示已領(lǐng)取，領(lǐng)取者零錢中增加正確金額，再次領(lǐng)取只能查看紅包信息
13、發(fā)紅包者自己領(lǐng)紅包
14、紅包24小時未被領(lǐng)取提示紅包被退回，相應(yīng)支付方式中錢數(shù)增加（增加金額與紅包金額一致），對方不能領(lǐng)紅包

群發(fā)紅包-普通紅包： （只寫了與單個紅包不同的地方）
1、紅包個數(shù) 為空、0、001、100、99、101
2、紅包拆開每個金額一樣 均為發(fā)紅包時設(shè)置的單個金額對應(yīng)的錢數(shù)
3、紅包被拆時，有相應(yīng)提示
4、發(fā)紅包者自己領(lǐng)紅包
5、紅包24小時內(nèi)未被拆完，剩余錢被退回，相應(yīng)支付方式中錢數(shù)增加

群發(fā)紅包-拼手氣紅包：
1、紅包總額/紅包個數(shù)<0.01
2、紅包每個人拆開金額不同，總金額與發(fā)紅包設(shè)置的總額一致
3、紅包24小時內(nèi)拆完后顯示最佳手氣
4、紅包24小時內(nèi)未被拆完不顯示最佳手氣

兼容性： 安卓、蘋果 不同型號版本手機(jī)
UI測試： 界面無錯別字，風(fēng)格統(tǒng)一
中斷測試： 不同應(yīng)用之間切換、斷網(wǎng)、來電、短信、低電量、手機(jī)沒電
網(wǎng)絡(luò)測試： 2g/3g/4g  WiFi 移動聯(lián)通電信  弱網(wǎng)  無網(wǎng)

微信朋友圈測試用例（★★★★★）
功能測試
1、朋友圈發(fā)送功能
1）只發(fā)送文本
a、考慮文本長度：1-1500字符（該數(shù)據(jù)為百度數(shù)據(jù)）、超出最大字符長度
b、文本是否支持復(fù)制粘貼
c、為空驗證
2）只發(fā)送圖片
a、本地相冊選擇/拍攝
b、圖片數(shù)量驗證：1-9張圖片、超出9張
c、為空驗證
3）只發(fā)送視頻
a、本地相冊選擇/拍攝
b、視頻秒數(shù)驗證：1-10s，超出10s
c、視頻個數(shù)驗證：1個，超出1個
d、視頻格式驗證：支持的視頻格式，例mp4、不支持的視頻格式
e、視頻大小驗證：蘋果400kb以內(nèi)、Android200-300kb（此為百度數(shù)據(jù)）、超出規(guī)定大小
f、視頻預(yù)覽增刪改操作
g、為空驗證
4）發(fā)送文本+圖片：輸入滿足要求的文本、圖片進(jìn)行一次驗證
5）發(fā)送文本+視頻：輸入滿足要求的文本、視頻進(jìn)行一次驗證
6）發(fā)送圖片+視頻：不支持發(fā)送
7）朋友圈發(fā)送內(nèi)容是否有限制，例如涉及黃賭毒等敏感字
8）所在位置
a、不顯示位置：發(fā)送到朋友圈動態(tài)不顯示位置
b、選擇對應(yīng)位置：搜索支持、自動定位、手動編輯
C、點擊取消，返回上一級頁面
9）誰可以看
a、設(shè)置公開：所有朋友可見
b、設(shè)置私密（僅自己可見）：自己查看朋友圈-可見、好友查看朋友圈-不可見
c、設(shè)置部分可見（部分朋友可見）：選擇的部分好友-可見、不被選擇的好友-不可見、是否有人數(shù)上限
d、設(shè)置不給誰看（選中的朋友不可見）：不被選中的朋友-可見、被選中的朋友-不可見、是否有人數(shù)上限
e、點擊取消，返回發(fā)送頁面
10）提醒誰看
a、提醒單人/提醒多人：被提醒的朋友-收到消息提醒、未被提醒-未有消息提醒
b、是否有人數(shù)上限
c、點擊取消，返回發(fā)送頁面
11）同步QQ空間：默認(rèn)不同步、同步到QQ空間
12）取消發(fā)送朋友圈操作
a、選擇相機(jī)，點擊取消，返回朋友圈頁面
b、進(jìn)入朋友圈發(fā)送頁面，選擇文本圖片，點擊取消
13）朋友圈當(dāng)天發(fā)送次數(shù)是否有上限限制

2、朋友圈瀏覽功能
1）文本查看：
a、過長文本內(nèi)容是否隱藏，并支持查看全文
b、右鍵選擇復(fù)制、收藏、翻譯
c、url鏈接是否支持點擊跳轉(zhuǎn)網(wǎng)頁
2）圖片查看
a、小圖右鍵支持收藏/編輯
b、點擊支持大圖瀏覽
c、選擇發(fā)送給朋友、收藏、保存圖片、編輯
d、多張圖片支持左右滑動瀏覽
3）視頻查看
a、右鍵視頻支持靜音播放/搜藏
b、點擊視頻播放按鍵支持播放視頻
c、選擇發(fā)送給朋友、收藏、保存視頻、編輯
4）分享動態(tài)瀏覽：QQ空間/公眾號文章/非騰訊產(chǎn)品分享后朋友圈是否正常顯示
5）贊：點贊、取消點贊
6）評論
a、評論長度：評論字?jǐn)?shù)合理長度、評論超過字?jǐn)?shù)上限
b、評論類型：純中文、純數(shù)字、純字母、純字符、純表情（微信表情/手機(jī)自帶表情）、混合類型、包含url鏈接；
c、評論是否支持復(fù)制粘貼
d、為空驗證
e、發(fā)表評論后刪除
f、評論回復(fù)操作
7）刪除朋友圈動態(tài)
8）更換相冊封面
9）刷新是否正常獲取新動態(tài)
10）上滑是否加載更多

界面/易用性測試
1、技術(shù)人員角度：頁面布局設(shè)計是否跟產(chǎn)品原型圖/ui效果圖一致
2、但除了考慮1之外，我們同樣要考慮到用戶使用：功能操作是否簡便，頁面布局排版風(fēng)格是否美觀合理，提示語相關(guān)信息是否易于理解

中斷測試
1、主要考慮：a)核心功能  b)當(dāng)前功能存在實時數(shù)據(jù)交換，例發(fā)朋友圈、瀏覽朋友圈進(jìn)行中斷，是否容易出現(xiàn)崩潰
2、中斷包括：前后臺切換、鎖屏解鎖、斷網(wǎng)重連、app切換、來電話/來短信中斷、插拔耳機(jī)線/數(shù)據(jù)線

網(wǎng)絡(luò)測試
1、三大運營商不同網(wǎng)絡(luò)制式測試
2、網(wǎng)絡(luò)切換測試：WIFI/4G/3G/2G
3、無網(wǎng)測試：對于緩存在本地的數(shù)據(jù)，部分朋友圈信息是否支持瀏覽
4、弱網(wǎng)測試：
a、延時：頁面響應(yīng)時間是否可接受、不同網(wǎng)絡(luò)制式是否區(qū)分超時時長、出現(xiàn)請求超時，是否給予相應(yīng)的提示
b、丟包：有無超時重連機(jī)制、如果未響應(yīng)，是否給予相應(yīng)提示
c、頁面呈現(xiàn)的完整性驗證

兼容性測試
1、Android手機(jī)端、蘋果手機(jī)端、pad版（主流）功能界面顯示是否正常
2、各平臺朋友圈展示數(shù)據(jù)是否一致

安全測試
發(fā)送朋友圈時，文本輸入腳本代碼，是否出現(xiàn)異常

性能測試
1、服務(wù)器性能測試
可通過loadrunner/jmeter工具實現(xiàn)，主要關(guān)注TPS、響應(yīng)時間、吞吐量、CPU、內(nèi)存等

2、app客戶端性能測試
可通過GT工具實現(xiàn)，運行時關(guān)注cpu、內(nèi)存、流量、電量等占用率

3、app壓力穩(wěn)定性測試
通過monkey工具實現(xiàn)，頻繁發(fā)送朋友圈，瀏覽朋友圈請求，是否容易發(fā)生崩潰

-----------------------------

麗麗LILY

[愛]
干杯