功能測(cè)試

一個(gè)完整的測(cè)試計(jì)劃應(yīng)該包含哪些內(nèi)容

• 項(xiàng)目/功能描述
• 測(cè)試范圍（功能/非功能）
• 測(cè)試開銷估計(jì)（時(shí)間/人力）
• 預(yù)計(jì)排期
• 測(cè)試用例
• 測(cè)試開始和結(jié)束的標(biāo)準(zhǔn)
• 可能存在的風(fēng)險(xiǎn)和應(yīng)對(duì)方案
• 相關(guān)人員（開發(fā)/產(chǎn)品）的審核記錄
• 歷史版本

一個(gè)完整的測(cè)試用例包含哪些內(nèi)容？

用例描述、優(yōu)先級(jí)、適用的平臺(tái)、所屬模塊、測(cè)試步驟、期望結(jié)果，與界面相關(guān)的提供截圖等。

什么時(shí)候需要發(fā)測(cè)試報(bào)告？一份測(cè)試報(bào)告應(yīng)該包含哪些內(nèi)容？

• 項(xiàng)目測(cè)試過(guò)程中，每天的測(cè)試執(zhí)行完成之后需要發(fā)送測(cè)試報(bào)告，項(xiàng)目測(cè)試完成后要發(fā)一份整體的測(cè)試報(bào)告。
• 測(cè)試報(bào)告中需要包含整體測(cè)試狀態(tài)，進(jìn)度，問(wèn)題列表，每項(xiàng)子任務(wù)的預(yù)計(jì)完成時(shí)間，已經(jīng)測(cè)試完成的用例和測(cè)試結(jié)果，是否有需要處理的風(fēng)險(xiǎn)或阻礙項(xiàng)，問(wèn)題列表中需要有問(wèn)題描述，優(yōu)先級(jí)，狀態(tài)，責(zé)任人等。

一個(gè)完整的缺陷報(bào)告應(yīng)該包含哪些內(nèi)容？

完整的缺陷報(bào)告至少應(yīng)該包含：發(fā)現(xiàn)問(wèn)題的軟件版本、使用的測(cè)試數(shù)據(jù)和賬號(hào)、測(cè)試步驟、期望結(jié)果、實(shí)際結(jié)果、嚴(yán)重程度、期望修復(fù)的時(shí)間和版本、復(fù)現(xiàn)的概率、日志、截圖、錄屏等。

簡(jiǎn)述等價(jià)類劃分法并舉例

• 等價(jià)類劃分法是把所有可能輸入的數(shù)據(jù)，有無(wú)效等價(jià)類和有效等價(jià)類（即正確輸入和非法輸入），即程序的輸入域劃分策劃國(guó)內(nèi)若干部分（子集），然后從每一個(gè)子集中選取少數(shù)具有代表性的數(shù)據(jù)作為測(cè)試用例.
• 例如測(cè)試用戶輸入框，可以把字母/數(shù)字/無(wú)效輸入/組合輸入等劃成幾類，針對(duì)不同類設(shè)計(jì)用例。

針對(duì)具體場(chǎng)景的測(cè)試用例設(shè)計(jì)（比如測(cè)試一只筆，一個(gè)用戶登錄頁(yè)面等）

使用常用的用例設(shè)計(jì)方法對(duì)可能的場(chǎng)景和功能盡可能覆蓋到，同時(shí)考慮支持的平臺(tái)，不同用戶的差別，兼容性和易用性，非功能性測(cè)試可以考慮性能，安全性等。
http://t.csdnimg.cn/NbCtH

怎樣與開發(fā)溝通一個(gè)不總是能復(fù)現(xiàn)的缺陷？

• 通過(guò)不同測(cè)試條件（設(shè)置，數(shù)據(jù)，賬號(hào)等）的組合嘗試找出可能觸發(fā)問(wèn)題的場(chǎng)景；
• 保留問(wèn)題發(fā)生時(shí)的完整日志，嘗試從日志中發(fā)現(xiàn)可能的錯(cuò)誤；
• 在缺陷報(bào)告中提供完整的場(chǎng)景描述、截圖錄屏、日志以及發(fā)生概率，配合開發(fā)人員做后續(xù)測(cè)試和分析。

怎樣與開發(fā)溝通一個(gè)開發(fā)不認(rèn)為是缺陷的問(wèn)題？

• 從用戶體驗(yàn)的角度看目前的行為是否合理；
• 競(jìng)品比較，行業(yè)內(nèi)其他類似的產(chǎn)品是如何處理的；
• 邀請(qǐng)產(chǎn)品經(jīng)理介入，詢問(wèn)他的意見。

如何劃分缺陷的嚴(yán)重級(jí)別？

缺陷一般分成四個(gè)等級(jí)：

1. 嚴(yán)重 - 導(dǎo)致嚴(yán)重用戶體驗(yàn)問(wèn)題和關(guān)鍵功能失效的必須修復(fù)的缺陷;
2. 重大 - 必須修復(fù)的用戶體驗(yàn)問(wèn)題，與需求文檔不符合的關(guān)鍵功能缺陷；
3. 一般 - 不好的用戶體驗(yàn)，需要修復(fù)但是不緊急；
4. 小 - 最好能修復(fù)的可以提升用戶體驗(yàn)的問(wèn)題。

如何和開發(fā)就缺陷的嚴(yán)重程度達(dá)成一致？

通過(guò)文檔和流程來(lái)確保和團(tuán)隊(duì)其他成員就缺陷的等級(jí)劃分達(dá)成一致意見。比如制定流程規(guī)范，邀請(qǐng)所有相關(guān)人員審核，達(dá)成一致后作為標(biāo)準(zhǔn)指導(dǎo)后面的缺陷提交和修復(fù)。

整個(gè)項(xiàng)目開發(fā)過(guò)程中有哪些需要測(cè)試參與的環(huán)節(jié)

• 需求評(píng)審
• 代碼設(shè)計(jì)評(píng)審
• 代碼評(píng)審
• 測(cè)試評(píng)審
• 測(cè)試執(zhí)行
• 缺陷跟進(jìn)
• 上線評(píng)估
• 上線后的測(cè)評(píng)
• 線上數(shù)據(jù)分析
• 線上問(wèn)題跟蹤
• 回歸測(cè)試自動(dòng)化
• 定期的缺陷分析和用例/流程改進(jìn)

測(cè)試人員是否需要參加代碼審核？重點(diǎn)需要關(guān)注什么？

測(cè)試人員需要參加代碼評(píng)審，通過(guò)靜態(tài)代碼走查和代碼審核報(bào)告確保：

1. 代碼變動(dòng)有足夠的單元測(cè)試覆蓋率；
2. 發(fā)現(xiàn)可能的邊界條件處理問(wèn)題；
3. 通過(guò)測(cè)試用例補(bǔ)充單元測(cè)試中可能無(wú)法覆蓋的分支；
4. 檢查代碼中可能存在的問(wèn)題提早糾正；
5. 檢查代碼是否能夠?qū)崿F(xiàn)預(yù)期的功能。

如何預(yù)估測(cè)試工作量

• 根據(jù)測(cè)試計(jì)劃，預(yù)估測(cè)試用例設(shè)計(jì)及評(píng)審、測(cè)試計(jì)劃制定及評(píng)審、測(cè)試執(zhí)行及缺陷跟進(jìn)、上線準(zhǔn)備、上線后的跟蹤和數(shù)據(jù)分析、回歸測(cè)試自動(dòng)化分別所需要的時(shí)間
• 同時(shí)考慮測(cè)試過(guò)程中可能存在的風(fēng)險(xiǎn)（比如首次提測(cè)無(wú)法達(dá)到測(cè)試開始標(biāo)準(zhǔn)、對(duì)其他團(tuán)隊(duì)的依賴導(dǎo)致的延遲、可能的需求變更導(dǎo)致的測(cè)試范圍變化等）給出對(duì)應(yīng)的可能結(jié)果和應(yīng)對(duì)方案。

如果出現(xiàn)排期緊張，上線之前大量測(cè)試可能無(wú)法按時(shí)測(cè)試怎么辦？

1. 根據(jù)現(xiàn)有數(shù)據(jù)提前預(yù)警和告知所有相關(guān)人員，提示可能的風(fēng)險(xiǎn)；
2. 提出可能的應(yīng)對(duì)方案，包括合并和精簡(jiǎn)測(cè)試，擴(kuò)充人員，倒休；
3. 對(duì)每種方案帶來(lái)的優(yōu)劣點(diǎn)做充分溝通保證團(tuán)隊(duì)達(dá)成一致；4. 確定方案后給出新的估計(jì)和可能存在的風(fēng)險(xiǎn)。

產(chǎn)品上線之后發(fā)現(xiàn)問(wèn)題，測(cè)試人員需要如何做出響應(yīng)？

1. 配合開發(fā)人員復(fù)現(xiàn)和調(diào)研問(wèn)題；
2. 如果是環(huán)境差異（配置或者資源本身）導(dǎo)致的問(wèn)題，需要優(yōu)化上線前測(cè)試流程，添加在無(wú)此差異的環(huán)境上測(cè)試用例；
3. 如果是軟件問(wèn)題，需要查看是否有用例覆蓋此場(chǎng)景，如果沒(méi)有需要添加，如果有，需要調(diào)查為什么沒(méi)被執(zhí)行或者執(zhí)行了未被發(fā)現(xiàn)；
4. 寫總結(jié)報(bào)告，總結(jié)問(wèn)題和需要采取的行動(dòng)，避免下次出現(xiàn)同樣的問(wèn)題。

測(cè)試過(guò)程中如何保證測(cè)試用例能夠及時(shí)更新？

• 借助測(cè)試用例管理工具比如禪道，testrail對(duì)測(cè)試用例進(jìn)行版本管理；
• 需求、設(shè)計(jì)或者實(shí)現(xiàn)發(fā)生變更時(shí)及時(shí)更新用例；
• 定期的測(cè)試用例評(píng)審保證測(cè)試用例有效性。

如何衡量和保證測(cè)試覆蓋率？

• 根據(jù)業(yè)務(wù)流程圖、數(shù)據(jù)處理時(shí)序圖、類圖等設(shè)計(jì)文檔檢查用例對(duì)主要分支的覆蓋程度；
• 邀請(qǐng)產(chǎn)品經(jīng)理、項(xiàng)目經(jīng)理、開發(fā)團(tuán)隊(duì)、測(cè)試團(tuán)隊(duì)審核測(cè)試用例；
• 根據(jù)測(cè)試過(guò)程中發(fā)現(xiàn)的問(wèn)題對(duì)出現(xiàn)問(wèn)題較多的功能加強(qiáng)用例覆蓋

產(chǎn)品需求發(fā)生變更時(shí)，測(cè)試人員需要做出什么響應(yīng)？

1. 與產(chǎn)品經(jīng)理及開發(fā)人員溝通該變更是否必要，如需變更，是否有其他更好方案；
2. 評(píng)估變更對(duì)測(cè)試范圍和測(cè)試工作量的影響；
3. 更新測(cè)試用例和測(cè)試排期并邀請(qǐng)所有相關(guān)人員審查；
4. 明確告知變更帶來(lái)的影響和可能的解決方案（更多測(cè)試資源，交叉簡(jiǎn)化部分測(cè)試，分批上線等）。

測(cè)試計(jì)劃中的測(cè)試開始條件一般包含哪些內(nèi)容？

軟件關(guān)鍵功能工作正常，無(wú)阻礙測(cè)試的缺陷，無(wú)影響用戶使用的重大缺陷。具體執(zhí)行中，需要測(cè)試人員在測(cè)試計(jì)劃中列出測(cè)試開始條件，與開發(fā)團(tuán)隊(duì)共同審核達(dá)成一致后執(zhí)行。

測(cè)試計(jì)劃中的測(cè)試結(jié)束條件一般包含哪些內(nèi)容？

無(wú)嚴(yán)重、無(wú)重大、無(wú)一般級(jí)別缺陷，達(dá)到需求驗(yàn)收標(biāo)準(zhǔn)，所有未修復(fù)缺陷缺陷團(tuán)隊(duì)整體已經(jīng)知曉并達(dá)成一致可以發(fā)布后修復(fù)。

什么是白盒測(cè)試？可以完全替代黑盒測(cè)試嗎？

• 白盒測(cè)試也稱為結(jié)構(gòu)測(cè)試或邏輯驅(qū)動(dòng)測(cè)試，是針對(duì)被測(cè)單元內(nèi)部是如何進(jìn)行工作的測(cè)試。 它根據(jù)程序的控制結(jié)構(gòu)設(shè)計(jì)測(cè)試用例，主要用于軟件或程序驗(yàn)證。 白盒測(cè)試法檢查程序內(nèi)部邏輯結(jié)構(gòu)，對(duì)所有的邏輯路徑進(jìn)行測(cè)試，是一種窮舉路徑的測(cè)試方法，但即使每條路徑都測(cè)試過(guò)了，但仍然有可能存在錯(cuò)誤。
• 由于不能模擬端到端，因此不能替代黑盒測(cè)試。

白盒測(cè)試的覆蓋標(biāo)準(zhǔn)有哪些？分別指的是什么？

白盒測(cè)試法的覆蓋標(biāo)準(zhǔn)有邏輯覆蓋、循環(huán)覆蓋和基本路徑測(cè)試。

• 邏輯覆蓋包括語(yǔ)句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和修改條件判斷覆蓋，六種覆蓋標(biāo)準(zhǔn)發(fā)現(xiàn)錯(cuò)誤的能力呈由弱到強(qiáng)的變化，分別是：
  • 1.語(yǔ)句覆蓋每條語(yǔ)句至少執(zhí)行一次；
  • 2.判定覆蓋每個(gè)判定的每個(gè)分支至少執(zhí)行一次；
  • 3.條件覆蓋每個(gè)判定的每個(gè)條件應(yīng)取到各種可能的值；
  • 4.判定/條件覆蓋同時(shí)滿足判定覆蓋條件覆蓋。
  • 5.條件組合覆蓋每個(gè)判定中各條件的每一種組合至少出現(xiàn)一次；
  • 6.修改條件判斷覆蓋每一個(gè)判斷的所有可能結(jié)果都出現(xiàn)過(guò)、每一個(gè)判斷中所有條件的所有可能結(jié)果都出現(xiàn)過(guò)、每一個(gè)進(jìn)入點(diǎn)及結(jié)束點(diǎn)都執(zhí)行過(guò)、判斷中每一個(gè)條件都可以獨(dú)立的影響判斷的結(jié)果。

產(chǎn)品上線后，還需要做哪些工作保證線上質(zhì)量？

產(chǎn)品上線之后，還需要做線上回歸測(cè)試，保證產(chǎn)品的各項(xiàng)功能和性能均正常。同時(shí)需要監(jiān)測(cè)線上數(shù)據(jù)和異常日志，跟蹤用戶反饋并及時(shí)處理。

你了解灰度發(fā)布嗎？它的作用是什么？

• 灰度發(fā)布 （又名金絲雀發(fā)布）是指在黑與白之間，能夠平滑過(guò)渡的一種發(fā)布方式。
• 在其上可以進(jìn)行A/B testing，即讓一部分用戶繼續(xù)用產(chǎn)品特性A，一部分用戶開始用產(chǎn)品特性B，如果用戶對(duì)B沒(méi)有什么反對(duì)意見，那么逐步擴(kuò)大范圍，把所有用戶都遷移到B上面來(lái)。
• 灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問(wèn)題，以保證其影響度。 灰度期 ：灰度發(fā)布開始到結(jié)束期間的這一段時(shí)間，稱為灰度期。
• 為什么要灰度發(fā)布
  • 靈活選擇用戶參與產(chǎn)品測(cè)試。
  • 規(guī)避一定的發(fā)布風(fēng)險(xiǎn)，降低產(chǎn)品迭代升級(jí)所影響的范圍。

什么是a/b測(cè)試？a/b測(cè)試中如何保證覆蓋率？

• a/b測(cè)試是一種用戶體驗(yàn)研究方法，通常針對(duì)兩到三個(gè)不同的用戶體驗(yàn)方案給出不同的代碼實(shí)現(xiàn)，按比例隨機(jī)分配用戶到其中的某個(gè)方案，根據(jù)上線后的用戶數(shù)據(jù)（點(diǎn)擊率，購(gòu)買率，存活率，注冊(cè)率等）來(lái)決定哪個(gè)方案更受用戶青睞。
• 針對(duì)a/b測(cè)試，測(cè)試計(jì)劃應(yīng)該覆蓋不同入口條件下的不同方案的組合測(cè)試，從而保證任何路徑下用戶的體驗(yàn)是完整合乎期望的。

你是否組織或者參加過(guò)上線之前的beta測(cè)試？它的作用是什么？

• beta測(cè)試通常指的是測(cè)試和缺陷修復(fù)完成之后，組織人力資源對(duì)項(xiàng)目進(jìn)行集中測(cè)試。
• 它的組織形式可以是會(huì)議，也可以是發(fā)送請(qǐng)求測(cè)試郵件和在系統(tǒng)中搜集反饋，參與人員可以包括所有項(xiàng)目相關(guān)人員，也通常邀請(qǐng)其他團(tuán)隊(duì)人員來(lái)交叉測(cè)試和驗(yàn)收
• 主要目的是盡可能的在上線之前發(fā)現(xiàn)可能遺漏的問(wèn)題或者提升用戶體驗(yàn)的建議。

什么是冒煙測(cè)試？

冒煙測(cè)試通常用于驗(yàn)證軟件的關(guān)鍵功能工作正常，它通常是執(zhí)行詳細(xì)的功能測(cè)試或者回歸測(cè)試的前提條件

冒煙測(cè)試之后發(fā)現(xiàn)交付的軟件達(dá)不到開始測(cè)試的標(biāo)準(zhǔn)應(yīng)該怎么辦？

1. 測(cè)試計(jì)劃中應(yīng)該明確標(biāo)注測(cè)試開始的標(biāo)準(zhǔn)（如冒煙測(cè)試中無(wú)重大問(wèn)題，沒(méi)有阻礙測(cè)試的重大缺陷）；
2. 冒煙測(cè)試后發(fā)現(xiàn)無(wú)法達(dá)到測(cè)試開始的標(biāo)準(zhǔn)，應(yīng)該果斷拒絕繼續(xù)測(cè)試并且將問(wèn)題反饋給所有相關(guān)人員；
3. 要求開發(fā)團(tuán)隊(duì)給出明確的下個(gè)版本交付的時(shí)間并說(shuō)明對(duì)測(cè)試工作和整體項(xiàng)目排期可能造成的影響；
4. 對(duì)測(cè)試資源和進(jìn)度進(jìn)行重新安排和溝通已確保整體項(xiàng)目進(jìn)度。

單元測(cè)試的作用是什么？是否使用過(guò)junit之類的單元測(cè)試工具？

• 單元測(cè)試是用來(lái)測(cè)試軟件中某些獨(dú)立單元的技術(shù)，用于在開發(fā)階段驗(yàn)證代碼的正確性
• junit是常用的單元測(cè)試工具之一。一般開發(fā)人員需要自己寫單元測(cè)試，測(cè)試人員可以通過(guò)審查單元測(cè)試查看覆蓋率和發(fā)現(xiàn)需要在端到端測(cè)試中加強(qiáng)的點(diǎn)。

系統(tǒng)測(cè)試和集成測(cè)試分別指什么？

• 集成測(cè)試在系統(tǒng)測(cè)試之前，單元測(cè)試完成之后系統(tǒng)集成的時(shí)候進(jìn)行測(cè)試。
• 集成測(cè)試主要是針對(duì)程序內(nèi)部結(jié)構(gòu)進(jìn)行測(cè)試，特別是對(duì)程序之間的接口進(jìn)行測(cè)試。
• 集成測(cè)試對(duì)測(cè)試人員的編寫腳本能力要求比較高。 測(cè)試方法一般選用黑盒測(cè)試和白盒測(cè)試相結(jié)合。
• 系統(tǒng)測(cè)試是基于軟件需求的黑盒測(cè)試，是對(duì)已經(jīng)集成好的軟件系統(tǒng)進(jìn)行徹底的測(cè)試，以驗(yàn)證軟件系統(tǒng)的正確性和性能等滿足其規(guī)約所指定的要求，檢查軟件的行為和輸出是否正確。

測(cè)試中需要收集哪些日志？這些日志的作用是什么？

• 對(duì)于服務(wù)器端測(cè)試，需要收集服務(wù)器日志，以便出現(xiàn)問(wèn)題時(shí)，開發(fā)人員可以從日志中獲取堆棧信息定位問(wèn)題；
• 自動(dòng)化測(cè)試需要采集測(cè)試執(zhí)行的日志，追蹤執(zhí)行的步驟和可能拋出的異常；
• 對(duì)于性能測(cè)試，需要采集系統(tǒng)資源使用數(shù)據(jù)和時(shí)間戳；
• 客戶端測(cè)試在發(fā)現(xiàn)問(wèn)題時(shí)需要采集發(fā)送的完整請(qǐng)求和響應(yīng)消息內(nèi)容。

移動(dòng)端測(cè)試相比傳統(tǒng)web端，需要注意哪些方面？

相較于傳統(tǒng)的web端、PC客戶端產(chǎn)品的測(cè)試，移動(dòng)端的測(cè)試受手機(jī)屏幕大小、內(nèi)存、CPU、網(wǎng)絡(luò)特性，操作系統(tǒng)、用戶使用習(xí)慣的差異，有其自身的特點(diǎn)，所以對(duì)移動(dòng)端產(chǎn)品測(cè)試就需要充分考慮測(cè)試差異而單獨(dú)分列出來(lái)。

安卓和ios客戶端測(cè)試有何不同？

1. 按鍵習(xí)慣差異：Home鍵，左右滑動(dòng)，返回的處理等;
2. 操作系統(tǒng)和品牌差異：在Android平臺(tái)則包括各種主流品牌，操作系統(tǒng)和版本的測(cè)試，選型涉及較多，而iOS較少;
3. 分辨率差異：Android端有多種，iOS較少;
4. 升降級(jí)：iOS不能降級(jí)，只能單向升級(jí);新的iOS系統(tǒng)中的資源庫(kù)不能完全兼容低版本中的iOS系統(tǒng)中的應(yīng)用，低版本iOS系統(tǒng)中的應(yīng)用調(diào)用了新的資源庫(kù)，會(huì)直接導(dǎo)致閃退(Crash);Android可以被升級(jí)的必要條件：新舊版本具有相同的簽名;新舊版本具有相同的包名;有一個(gè)標(biāo)示符區(qū)分新舊版本，比如版本號(hào)，對(duì)于Android若有內(nèi)置的應(yīng)用需檢查升級(jí)之后內(nèi)置文件是否匹配(如內(nèi)置的輸入法);
5. 推送差異：Android：點(diǎn)擊home鍵，程序后臺(tái)運(yùn)行時(shí)，此時(shí)接收到push，點(diǎn)擊后喚醒應(yīng)用，此時(shí)可以正確跳轉(zhuǎn);iOS，點(diǎn)擊home鍵關(guān)閉程序和屏幕鎖屏的情況下顯示紅點(diǎn);
6. 安裝卸載差異：Android的下載和安裝的平臺(tái)和工具和渠道比較多，iOS主要有app store，iTunes和testflight下載;
7. 編程語(yǔ)言：Android下app使用的是java語(yǔ)言，而iOS是objective c++;
8. 導(dǎo)航方式：iOS的Tab放在頁(yè)面底部，不能通過(guò)滑動(dòng)來(lái)切換，只能點(diǎn)擊。也有放在上面的，也不能滑動(dòng)，但有些Tab本身可以滑動(dòng)，比如新聞?lì)悜?yīng)用。Android：一般放在頁(yè)面頂端，可以通過(guò)滑動(dòng)頁(yè)面來(lái)切換Tab，當(dāng)然Tab可以點(diǎn)擊切換，Tab多的話，Tab本身也可以滑動(dòng)。

web端和移動(dòng)端可以分別使用什么抓包工具？通?？梢詮陌蝎@得哪些信息？

• web端可以直接使用瀏覽器抓包，
• 移動(dòng)端常用的的抓包工具有Charles、fiddler等，可以通過(guò)連接代理等方式抓取請(qǐng)求。
• 包可以提供：消息的時(shí)間戳、路由信息，請(qǐng)求的發(fā)送方、接收方、請(qǐng)求消息頭、請(qǐng)求消息體、響應(yīng)消息頭和響應(yīng)消息體等信息。

移動(dòng)app測(cè)試需要覆蓋哪些測(cè)試類型？

可用性/兼容性/接口測(cè)試/服務(wù)測(cè)試/底層資源測(cè)試/性能測(cè)試/安裝測(cè)試/升級(jí)測(cè)試/安全性測(cè)試。

什么是性能測(cè)試？

• 狹義的性能測(cè)試指的是通過(guò)增加并發(fā)請(qǐng)求的數(shù)量，觀察系統(tǒng)的吞吐量，一直到系統(tǒng)處理能力達(dá)到飽和的時(shí)候，系統(tǒng)吞吐量保持在一個(gè)數(shù)字保持不變，得到系統(tǒng)吞吐量和請(qǐng)求之間關(guān)系的測(cè)試，
• 實(shí)際中還會(huì)同時(shí)考慮如響應(yīng)時(shí)間（SLA），穩(wěn)定性，硬件資源，網(wǎng)絡(luò)等因素。
• 廣義的性能測(cè)試包括狹義性能測(cè)試，容量測(cè)試，負(fù)載測(cè)試、壓力測(cè)試和穩(wěn)定性測(cè)試等。

web端和移動(dòng)端的性能測(cè)試關(guān)注點(diǎn)有何不同？

• web端和移動(dòng)端的性能測(cè)試都關(guān)注頁(yè)面加載速度
• 移動(dòng)端由于自身特性，性能測(cè)試中同時(shí)關(guān)注手機(jī)CPU使用率、內(nèi)存使用率、流量、電量、流暢度等性能指標(biāo)。

性能測(cè)試中需要考慮哪些參數(shù)？

cpu使用率/內(nèi)存使用率/帶寬/網(wǎng)絡(luò)請(qǐng)求隊(duì)列長(zhǎng)度/響應(yīng)時(shí)間/線程數(shù)量/top等待等。

UI自動(dòng)化測(cè)試

什么是頁(yè)面對(duì)象模型？

頁(yè)面對(duì)象模型是一種前端自動(dòng)化的設(shè)計(jì)模式，把一個(gè)頁(yè)面中的所有的元素封裝到一個(gè)對(duì)象中，
測(cè)試流程調(diào)用頁(yè)面對(duì)象成員來(lái)實(shí)現(xiàn)完整的業(yè)務(wù)場(chǎng)景，按頁(yè)面封裝的方式，提高了測(cè)試的可維護(hù)性，減少了代碼冗余。

自動(dòng)化測(cè)試一般在哪個(gè)階段開始編寫？通常用于哪些階段的測(cè)試？

• 在功能的主體已經(jīng)完成，需求穩(wěn)定之后就可以開始準(zhǔn)備自動(dòng)化測(cè)試的腳本
• 自動(dòng)化測(cè)試可以用于日常版本迭代中做主要場(chǎng)景的回歸測(cè)試，產(chǎn)品上線之后做線上回歸測(cè)試，后續(xù)功能開發(fā)中對(duì)已有功能的回歸測(cè)試等

客戶端自動(dòng)化測(cè)試中有哪些常見的問(wèn)題導(dǎo)致元素?zé)o法定位？如何解決？

1. 頁(yè)面加載元素過(guò)慢，加等待時(shí)間；
2. 頁(yè)面有frame框架頁(yè)，需要先跳轉(zhuǎn)入frame框架再定位；
3. 可能該元素是動(dòng)態(tài)元素，定位方式要優(yōu)化，可以使用部分元素定位或通過(guò)父節(jié)點(diǎn)或兄弟節(jié)點(diǎn)定位；
4. 可能識(shí)別了元素，但是不能操作，比如元素不可用，不可寫等。需要使用js先把前置的操作完成。

客戶端自動(dòng)化測(cè)試中如何處理多個(gè)窗口切換？

1. 頁(yè)面跳轉(zhuǎn)之前使用driver.current_window_handle獲得當(dāng)前窗口句柄；
2. 跳轉(zhuǎn)之后通過(guò)driver.window_handles獲得所有窗口的句柄；
3. 循環(huán)找到新窗口的句柄，再通過(guò)driver.switch_to.window()方法跳轉(zhuǎn)到新的窗口。

所有的測(cè)試都可以自動(dòng)化嗎？哪些測(cè)試不適合做自動(dòng)化？

不是所有的項(xiàng)目都適合做自動(dòng)化，下面幾種情形不適合做自動(dòng)化：

1. 項(xiàng)目周期很短的項(xiàng)目；
2. 業(yè)務(wù)規(guī)則復(fù)雜的對(duì)象；
3. 美觀、聲音、易用性測(cè)試
4. 測(cè)試很少運(yùn)行；
5. 軟件不穩(wěn)定；
6. 涉及物理交互

什么是testng？它有哪些優(yōu)點(diǎn)？

testng是一套用來(lái)在自動(dòng)化測(cè)試代碼中管理用例組織、運(yùn)行和配置的工具，它的優(yōu)點(diǎn)是：

1. 允許并行執(zhí)行；
2. 可以定義用例之間的依賴關(guān)系；
3. 可以給用例分配優(yōu)先級(jí)；
4. 允許測(cè)試用例的分組；
5. 提供用例的參數(shù)化配置；
6. 支持多種斷言；
7. 提供詳盡的html測(cè)試報(bào)告。

testng中如何設(shè)置測(cè)試用例的優(yōu)先級(jí)？

testng通過(guò)priority屬性支持用例的優(yōu)先級(jí)設(shè)置。具體的實(shí)現(xiàn)方式是在@Test標(biāo)注之后加上priority屬性，設(shè)置用例的優(yōu)先級(jí)，比如@Test(priority=0)，如果沒(méi)有設(shè)置優(yōu)先級(jí)，則默認(rèn)用例按照字母順序執(zhí)行。