正文

功能測(cè)試的基本流程（軟件測(cè)試的5個(gè)基本流程）

發(fā)布時(shí)間：2023-04-22 00:08:12 稿源：創(chuàng)意嶺閱讀： 102

大家好！今天讓創(chuàng)意嶺的小編來(lái)大家介紹下關(guān)于功能測(cè)試的基本流程的問(wèn)題，以下是小編對(duì)此問(wèn)題的歸納整理，讓我們一起來(lái)看看吧。

開(kāi)始之前先推薦一個(gè)非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計(jì)劃、工作報(bào)告、論文、代碼、作文、做題和對(duì)話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細(xì)，有微信小程序端、在線網(wǎng)頁(yè)版、PC客戶端

官網(wǎng)：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內(nèi)優(yōu)秀的企業(yè)，服務(wù)客戶遍布全球各地，如需了解SEO相關(guān)業(yè)務(wù)請(qǐng)撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

1、測(cè)試流程規(guī)范
2、軟件測(cè)試的流程是什么？
3、各種功能測(cè)試點(diǎn)步驟
4、測(cè)試工作基本流程

功能測(cè)試的基本流程（軟件測(cè)試的5個(gè)基本流程）

一、測(cè)試流程規(guī)范

1.概述

1.1目的 2

1.2適用范圍 2

1.3執(zhí)行原則. 2

1.4角色和職責(zé) 2

1.4.1 測(cè)試leader 2

1.4.2 測(cè)試工程師 3

2.軟件測(cè)試流程 3

2.1軟件測(cè)試流程圖 3

2.2 流程圖解析 4

3.軟件測(cè)試周期人員活動(dòng) 7

3.1軟件測(cè)試準(zhǔn)備 7

3.2 測(cè)試執(zhí)行階段 8

3.2.1軟件執(zhí)行階段流程圖 8

3.2.2軟件測(cè)試執(zhí)行階段人員活動(dòng) 9

3.2.3測(cè)試掃尾工作 11

4.結(jié)語(yǔ) 12

1.概述

1.1目的

1、有效的保證軟件質(zhì)量；

2、有效的制定不同測(cè)試類型（軟件系統(tǒng)測(cè)試、主觀性測(cè)試、專項(xiàng)測(cè)試、（自動(dòng)化測(cè)試）、性能測(cè)試、用戶體驗(yàn)測(cè)試）的軟件測(cè)試計(jì)劃；

3、按照計(jì)劃進(jìn)行測(cè)試，發(fā)現(xiàn)軟件中存在的問(wèn)題；

4、對(duì)軟件中已經(jīng)解決的問(wèn)題進(jìn)行有效的驗(yàn)證;

5、判定測(cè)試過(guò)程和問(wèn)題驗(yàn)證的有效性。

1.2適用范圍

適用范圍是參與產(chǎn)品軟件測(cè)試的各測(cè)試工程師。

1.3執(zhí)行原則.

1、標(biāo)準(zhǔn)化作業(yè)，尊重事實(shí)；

2、測(cè)試工程師需要對(duì)產(chǎn)品各項(xiàng)功能持有疑問(wèn)的態(tài)度來(lái)思考軟件；

3、測(cè)試工程師需要主動(dòng)與項(xiàng)目組的所有成員保持有效的溝通，以便更好地完成測(cè)試任務(wù)；

4、盡早發(fā)現(xiàn)問(wèn)題，及時(shí)跟蹤問(wèn)題；

1.4角色和職責(zé)

1.4.1 測(cè)試leader

負(fù)責(zé)審核測(cè)試計(jì)劃,參與計(jì)劃的實(shí)施過(guò)程，確保計(jì)劃的實(shí)施和按計(jì)劃完成測(cè)試任務(wù)；

制定、更新和維護(hù)軟件測(cè)試流程；

對(duì)發(fā)現(xiàn)的部門需要改進(jìn)的問(wèn)題提供解決方案；

制定短期、長(zhǎng)期的改進(jìn)措施；進(jìn)行評(píng)審和監(jiān)督；

參與版本風(fēng)險(xiǎn)評(píng)估

參與軟件需求與UI評(píng)審

編制STP（軟件測(cè)試計(jì)劃），組建測(cè)試團(tuán)隊(duì)

根據(jù)軟件測(cè)試申請(qǐng)單的要求判定是否接受軟件測(cè)試版本；達(dá)到軟件測(cè)試標(biāo)準(zhǔn)安排系統(tǒng)測(cè)試；對(duì)測(cè)試需求進(jìn)行組內(nèi)培訓(xùn)。

9.測(cè)試任務(wù)的分配，保證測(cè)試計(jì)劃的按時(shí)完成，保障軟件測(cè)試質(zhì)量；測(cè)試過(guò)程進(jìn)行跟蹤；處理異常情況；定期發(fā)送測(cè)試報(bào)告（每一個(gè)升級(jí)版本）到開(kāi)發(fā)、PM各管理人員

10.跟進(jìn)BUG的修改情況，組織BUG評(píng)審

11.組織版本風(fēng)險(xiǎn)評(píng)估

1.4.2 測(cè)試工程師

按照測(cè)試計(jì)劃進(jìn)行測(cè)試的執(zhí)行,測(cè)試用例在編寫、評(píng)審。

測(cè)試記錄的整理，

Bug的跟蹤【包括：提交、驗(yàn)證、關(guān)閉Bug】。

參與BUG的評(píng)審

定時(shí)完成學(xué)習(xí)計(jì)劃并提交學(xué)習(xí)報(bào)告給測(cè)試leader

2. 軟件測(cè)試流程

2.1軟件測(cè)試流程圖

2.2 流程圖解析

立項(xiàng)

對(duì)于版本，立項(xiàng)的條件只需要滿足：

測(cè)試部收到版本立項(xiàng)通知，軟件產(chǎn)品功能需求/設(shè)計(jì)說(shuō)明書(shū)都已提供到位

版本進(jìn)度表

當(dāng)立項(xiàng)條件滿足時(shí)，由測(cè)試部門經(jīng)理指定測(cè)試，由測(cè)試組織立項(xiàng)與后續(xù)的測(cè)試工作。

需求初審

測(cè)試Leader組織測(cè)試進(jìn)行需求審閱，完成三個(gè)任務(wù)：一是對(duì)文檔進(jìn)行評(píng)審，如對(duì)需求有疑問(wèn)，或者對(duì)需求有建議要求要與需求輸出人進(jìn)行溝通，直到需求定稿；二是確定測(cè)試所需配置、資源、樣機(jī)、以及需求對(duì)應(yīng)的DEV等；三是確定好軟件測(cè)試策略，策略主要包括如下方面：

1.測(cè)試依據(jù)

a,軟件需求文檔

b,其他，如參考其他競(jìng)品等

測(cè)試資源

a,測(cè)試人員需求

b,測(cè)試配置需求（需要前期的配置）

c,測(cè)試樣機(jī)需求（例如特殊需求需要特殊的手機(jī)）

測(cè)試策略

a,采取測(cè)試方法

b,采取哪些測(cè)試工具以及測(cè)試管理工具

c,對(duì)測(cè)試人員進(jìn)行培訓(xùn)等

測(cè)試人員安排

測(cè)試Leader根據(jù)在需求初審過(guò)程中各功能模塊提供的測(cè)試人員名單，完成測(cè)試人員安排。

需求分析

安排完畢后，測(cè)試Leader組織組員進(jìn)行需求分析，完成兩項(xiàng)任務(wù)：一是進(jìn)行組內(nèi)需求培訓(xùn)，保證所有組員完全理解需求；二是分配測(cè)試用例編寫或維護(hù)任務(wù)，確認(rèn)測(cè)試用例完成日期。

請(qǐng)注意：測(cè)試用例完成日期必須在軟件版本發(fā)布測(cè)試之前。

測(cè)試設(shè)計(jì)

測(cè)試設(shè)計(jì)主要包括測(cè)試用例的編寫與評(píng)審。由于常規(guī)的測(cè)試點(diǎn)的用例都已經(jīng)具備，這里主要針對(duì)新的需求。

測(cè)試計(jì)劃

當(dāng)所有測(cè)試前的準(zhǔn)備工作已經(jīng)完成，測(cè)試leader就要根據(jù)開(kāi)發(fā)時(shí)間表以及測(cè)試策略制定一個(gè)完整的軟件測(cè)試計(jì)劃（STP文檔），測(cè)試計(jì)劃的依據(jù)主要是版本開(kāi)發(fā)計(jì)劃和測(cè)試需求分析結(jié)果。

測(cè)試執(zhí)行

測(cè)試執(zhí)行一般分為以下階段：

確認(rèn)測(cè)試→系統(tǒng)測(cè)試→驗(yàn)收測(cè)試→產(chǎn)品文檔check，其中每個(gè)階段還有回歸測(cè)試驗(yàn)證問(wèn)題。

從測(cè)試的角度而言，測(cè)試執(zhí)行過(guò)程是要考慮量和度的問(wèn)題，就是指測(cè)試的范圍與測(cè)試的程度的問(wèn)題。

從管理的角度而言，在有限的時(shí)間內(nèi)，在人員有限甚至短缺的情況下，要考慮如何分工，如何合理地利用資源來(lái)開(kāi)展測(cè)試。當(dāng)然如下幾個(gè)問(wèn)題也需要考慮：

a, 當(dāng)測(cè)試人員測(cè)試的執(zhí)行不到位、敷衍了事時(shí)該如何解決？

b, 測(cè)試效率問(wèn)題，怎樣提高測(cè)試效率?

c, 根據(jù)版本的不同采取怎么樣的測(cè)試策略，是全面測(cè)試、自由測(cè)試還是針對(duì)模塊的測(cè)試

軟件評(píng)估

這里評(píng)估指軟件經(jīng)過(guò)一輪又一輪測(cè)試后，確認(rèn)軟件無(wú)重大問(wèn)題或者問(wèn)題很少的情況下，對(duì)準(zhǔn)備上線的版本進(jìn)行評(píng)估，以確定是否能夠上線。軟件評(píng)估會(huì)議由PM？組織，評(píng)估成員一般由DEV、PM、QA等組成。

測(cè)試總結(jié)

版本已經(jīng)上線后，測(cè)試可以通過(guò)各種方式對(duì)整個(gè)測(cè)試過(guò)程進(jìn)行總結(jié)，可以是做的好的方面的經(jīng)驗(yàn)，也可以是不足之處以便后續(xù)版本避免。

測(cè)試維護(hù)

由于測(cè)試的不完全性，當(dāng)軟件正式release后，用戶在使用過(guò)程中，難免遇到一些問(wèn)題，有的甚至是嚴(yán)重性的問(wèn)題，這就需要DEV修改有關(guān)問(wèn)題，修改后需要再次對(duì)軟件進(jìn)行測(cè)試、評(píng)估、上線。

3.軟件測(cè)試周期人員活動(dòng)

3.1軟件測(cè)試準(zhǔn)備

目的

有效的做好測(cè)試準(zhǔn)備工作，為測(cè)試的執(zhí)行做好前期所需；

按照需求制定好測(cè)試策略與測(cè)計(jì)劃；

進(jìn)入條件

版本正式啟動(dòng)

需求文檔已經(jīng)進(jìn)行歸檔

輸入

軟件開(kāi)發(fā)計(jì)劃、軟件開(kāi)發(fā)時(shí)間表、軟件產(chǎn)品功能需求/設(shè)計(jì)說(shuō)明書(shū)等相關(guān)需求文檔。

作業(yè)流程及其管理方法

No. 作業(yè)過(guò)程名作業(yè)內(nèi)容/管理方法作業(yè)人輸出

1.立項(xiàng)當(dāng)立項(xiàng)條件達(dá)到，測(cè)試leader指定測(cè)試組員，測(cè)試組員整理相關(guān)資料組織立項(xiàng)動(dòng)作測(cè)試leader、測(cè)試組員測(cè)試計(jì)劃

2需求初審測(cè)試leader組織需求的初審，邀請(qǐng)測(cè)試組員一起對(duì)需求進(jìn)行審讀，確認(rèn)該版本對(duì)應(yīng)的配置、資源，確認(rèn)對(duì)應(yīng)的測(cè)試策略測(cè)試leader、測(cè)試組員

3測(cè)試安排測(cè)試leader根據(jù)需求安排測(cè)試人員進(jìn)行需求分析與培訓(xùn)，并分配測(cè)試用例編寫與維護(hù)任務(wù)

4測(cè)試設(shè)計(jì)測(cè)試進(jìn)行TestCase的編寫，然后由測(cè)試leader制定測(cè)試用例的評(píng)審計(jì)劃并按照計(jì)劃進(jìn)行評(píng)審；（要求開(kāi)發(fā)人員、測(cè)試工程師）；測(cè)試要將每次Case的評(píng)審結(jié)果進(jìn)行記錄，測(cè)試leader在使用Case前進(jìn)行評(píng)審結(jié)果的確認(rèn)；

測(cè)試leader確認(rèn)最終的Testcase和評(píng)審記錄。

測(cè)試leader、測(cè)試組員測(cè)試用例

Case編寫的依據(jù)：

軟件需求文檔；相關(guān)規(guī)范和標(biāo)準(zhǔn)；

Case 編寫基本規(guī)則；

1. 以相關(guān)需求文檔為編寫依據(jù)；

2. 使用條件和路徑覆蓋法判定Case的覆蓋率；

3. Case的易理解和易操作性；

4. 針對(duì)不同測(cè)試目的編寫測(cè)試用例；

5. 根據(jù)不同的測(cè)試類型編寫測(cè)試用例（界面一致性、功能符合性、兼容性、性能穩(wěn)定性）

5.測(cè)試計(jì)劃編寫和評(píng)審當(dāng)測(cè)試用例完成后需要組織開(kāi)發(fā)、PM等相關(guān)人員進(jìn)行評(píng)審；

當(dāng)計(jì)劃定稿后，測(cè)試leader需要嚴(yán)格按照制定的計(jì)劃安排測(cè)試；

測(cè)試leader

測(cè)試計(jì)劃評(píng)審注意事項(xiàng)：

1. 保證測(cè)試計(jì)劃要符合開(kāi)發(fā)計(jì)劃

2. 測(cè)試的全面性；

輸出

測(cè)試用例

3.2 測(cè)試執(zhí)行階段

3.2.1軟件執(zhí)行階段流程圖

流程圖解析

1．根據(jù)整個(gè)軟件測(cè)試執(zhí)行過(guò)程，按時(shí)間分成三等分，分別為T1：測(cè)試初期、T2：測(cè)試中期、T3：測(cè)試后期

T1：測(cè)試初期這個(gè)階段，主要執(zhí)行確認(rèn)測(cè)試、基本功能的測(cè)試。確認(rèn)測(cè)試的目標(biāo)需要確保軟件完全符合設(shè)計(jì)文檔?；竟δ艿臏y(cè)試的重點(diǎn)是執(zhí)行測(cè)試用例，盡可能多的去暴露基本功能的問(wèn)題，測(cè)試的執(zhí)行方式以執(zhí)行測(cè)試用例為主。

T2：測(cè)試中期采用自由測(cè)試為主，除了測(cè)試基本功能外，還需要重點(diǎn)測(cè)試性能、用戶體驗(yàn)性測(cè)試、兼容性測(cè)試。其中性能測(cè)試可借助于Perfdog工具進(jìn)行測(cè)試。

T3：測(cè)試后期階段，這個(gè)階段仍然需要執(zhí)行多遍測(cè)試用例以確保基本功能的實(shí)現(xiàn)完全沒(méi)有問(wèn)題。

系統(tǒng)測(cè)試分為三個(gè)階段，并不是單純的時(shí)間三等分，而是每個(gè)時(shí)間段都需要達(dá)到測(cè)試目標(biāo)。若沒(méi)有達(dá)到測(cè)試目標(biāo)，測(cè)試leader需要及時(shí)調(diào)節(jié)計(jì)劃，并組織分析問(wèn)題，避免因?yàn)闇y(cè)試不到位的原因?qū)е掳姹狙悠凇?/p>

3.2.2軟件測(cè)試執(zhí)行階段人員活動(dòng)

目的

有效的制定系統(tǒng)測(cè)試的軟件測(cè)試計(jì)劃；

按照計(jì)劃進(jìn)行測(cè)試，發(fā)現(xiàn)軟件中的存在的問(wèn)題（包括：界面、需求、功能、兼容性、性能等方面問(wèn)題）。

對(duì)軟件中已經(jīng)解決的問(wèn)題進(jìn)行有效的驗(yàn)證;

判定測(cè)試過(guò)程和問(wèn)題驗(yàn)證的有效性；

進(jìn)入條件

完成測(cè)試計(jì)劃和測(cè)試用例;

已確認(rèn)軟件測(cè)試申請(qǐng)、軟件版本

輸入

軟件測(cè)試計(jì)劃和軟件測(cè)試用例。

軟件版本；

作業(yè)流程及其管理方法

NO 作業(yè)過(guò)程名作業(yè)內(nèi)容 / 管理方法作業(yè)人輸出結(jié)果

1測(cè)試任務(wù)安排測(cè)試leader獲得軟件版本后，確認(rèn)后根據(jù)測(cè)試目的制定版本測(cè)試計(jì)劃；

測(cè)試計(jì)劃完成后，向組內(nèi)成員介紹版本基本情況、測(cè)試時(shí)間安排等

測(cè)試leader每個(gè)新版本軟件測(cè)試計(jì)劃

2系統(tǒng)測(cè)試測(cè)試接收到軟件測(cè)試申請(qǐng)并確認(rèn)版本在發(fā)布時(shí)已提供相關(guān)信息后，安排測(cè)試依據(jù)測(cè)試用例進(jìn)行系統(tǒng)測(cè)試或進(jìn)行自由測(cè)試；

在測(cè)試階段，版本的第一輪和最后一輪測(cè)試必須至少執(zhí)行一個(gè)完整的周期。包括過(guò)一遍完整的case；

測(cè)試leader

組員

測(cè)試報(bào)告

3驗(yàn)證測(cè)試每個(gè)版本對(duì)以前已修改的BUG進(jìn)行驗(yàn)證，若確認(rèn)已經(jīng)修改，可執(zhí)行關(guān)閉操作。組員

4性能測(cè)試測(cè)試leader安排組員，按照《性能測(cè)試用例》進(jìn)行測(cè)試，主要采用與對(duì)比機(jī)對(duì)比測(cè)試得出內(nèi)存峰值結(jié)果；組員內(nèi)存峰值測(cè)試報(bào)告

6兼容性測(cè)試測(cè)試PM安排工程師，按照《兼容性測(cè)試用例》進(jìn)行對(duì)不同型號(hào)不同系統(tǒng)版本進(jìn)行驗(yàn)證測(cè)試組員兼容性測(cè)試報(bào)告

輸出

每個(gè)新版本軟件測(cè)試計(jì)劃、測(cè)試報(bào)告、內(nèi)存峰值測(cè)試報(bào)告、兼容性測(cè)試報(bào)告

3.2.3測(cè)試掃尾工作

目的

根據(jù)測(cè)試結(jié)果，組織版本評(píng)估

做好測(cè)試總結(jié)，積累好的經(jīng)驗(yàn)，去除不好的東西

進(jìn)入條件

完成了測(cè)試執(zhí)行階段，PM申請(qǐng)上線

作業(yè)流程及其管理方法

NO 作業(yè)過(guò)程名作業(yè)內(nèi)容 / 管理方法作業(yè)人輸出結(jié)果

1版本評(píng)估上線前，測(cè)試leader書(shū)寫軟件測(cè)試報(bào)告并組織版本評(píng)估會(huì)議，邀請(qǐng)開(kāi)發(fā)leader、項(xiàng)目經(jīng)理等管理人員組織版本評(píng)估會(huì)議，最終由項(xiàng)目經(jīng)理確認(rèn)軟件是否能夠上線。項(xiàng)目經(jīng)理（PM）

測(cè)試leader

測(cè)試組員

軟件開(kāi)發(fā)leader等

評(píng)估結(jié)果

2測(cè)試總結(jié)測(cè)試leader組織測(cè)試進(jìn)行總結(jié)性會(huì)議，總結(jié)測(cè)試經(jīng)驗(yàn)測(cè)試leader

測(cè)試組員

3維護(hù)測(cè)試當(dāng)收到用戶反饋的嚴(yán)重性問(wèn)題，測(cè)試leader組織測(cè)試驗(yàn)證并提交問(wèn)題到JIRA跟蹤；

開(kāi)發(fā)人員重新集成版本修改問(wèn)題，測(cè)試leader驗(yàn)證后并組織一次全面的測(cè)試確保版本

測(cè)試leader

測(cè)試組員

測(cè)試報(bào)告

4.結(jié)語(yǔ)

軟件測(cè)試是程序的一種執(zhí)行過(guò)程，目的是盡可能發(fā)現(xiàn)并改正被測(cè)試軟件中的錯(cuò)誤，提高軟件的可靠性。它是軟件生命周期中一項(xiàng)非常重要且非常復(fù)雜的工作，對(duì)軟件可靠性保證具有極其重要的意義。測(cè)試流程制定的總目標(biāo)是充分利用有限的人力和物力資源，高效率、高質(zhì)量地完成軟件測(cè)試任務(wù)。避免不足的測(cè)試使軟件帶著一些未揭露的隱藏錯(cuò)誤投入運(yùn)行，這將意味著更大的危險(xiǎn)讓用戶承擔(dān)。然而一個(gè)規(guī)范實(shí)用的流程，往往可以改善軟件測(cè)試的效率。流程的制定為測(cè)試計(jì)劃的制定、測(cè)試過(guò)程的執(zhí)行提供了文檔性的幫助。讓每一個(gè)測(cè)試很清晰的明白，軟件測(cè)試周期中每個(gè)時(shí)段該去怎么做。

該流程的制定不是一成不變，在執(zhí)行過(guò)程中若發(fā)現(xiàn)有不足之處，我們將更新此文檔，直到完全適用于我們的項(xiàng)目流程。

二、軟件測(cè)試的流程是什么？

軟件測(cè)試的流程：

1、根據(jù)軟件設(shè)計(jì)需求制定測(cè)試計(jì)劃，測(cè)試數(shù)據(jù)和測(cè)試用例。

2、搭建測(cè)試環(huán)境、執(zhí)行測(cè)試用例。

3、提交測(cè)試報(bào)告。

4、跟蹤Bug修改情況，不斷測(cè)試完善產(chǎn)品。

5、產(chǎn)品的其他方面測(cè)試。

三、各種功能測(cè)試點(diǎn)步驟

一.支付功能怎么測(cè)試？

1、從功能方面考慮：

1）、用戶的使用場(chǎng)景：包括正常完成支付的流程；

支付中斷后繼續(xù)支付的流程；

支付中斷后結(jié)束支付的流程；

單訂單支付的流程；

多訂單合并支付的流程；

余額不足；未綁定銀行卡；密碼錯(cuò)誤；密碼錯(cuò)誤次數(shù)過(guò)多；找人代付；

弱網(wǎng)狀態(tài)下，連續(xù)點(diǎn)擊支付功能功能，會(huì)不會(huì)支付多次；分期付款等；

2）、不同終端上支付：

包括PC端的支付、筆記本電腦的支付、平板電腦的支付、手機(jī)端的支付等；

3）、不同的支付方式：銀行卡網(wǎng)銀支付、支付寶支付、微信支付等；

4）、從產(chǎn)品容錯(cuò)性上：包括支付失敗后，能否再次支付、能否退款；

2、從性能方面考慮：

多個(gè)用戶并發(fā)支付能否成功；

支付的響應(yīng)時(shí)間；

3、從安全性方面考慮

使用Fiddler攔截訂單信息，并修改訂單金額，或者修改訂單號(hào)，

(下兩個(gè)訂單A,B，付款時(shí)攔截訂單B，并把訂單B的訂單號(hào)改為A訂單的訂單號(hào))無(wú)法完成支付；

4、從用戶體驗(yàn)方面考慮

是否支持快捷鍵功能；

點(diǎn)擊付款按鈕，是否有提示；

取消付款，是否有提示；

UI界面是否整潔；

輸入框是否對(duì)齊，大小是否適中等。

5、兼容性

BS架構(gòu)：不同瀏覽器測(cè)試。

APP：不同類型，不同分辨率，不同操作系統(tǒng)的手機(jī)上測(cè)試

二.購(gòu)物車怎么測(cè)試？

1.功能測(cè)試

a）、未登錄時(shí)：

將商品加入購(gòu)物車，頁(yè)面跳轉(zhuǎn)到登錄頁(yè)面，登錄成功后購(gòu)物車數(shù)量增加。

b）、登錄后：

所有鏈接是否跳轉(zhuǎn)正確；

商品是否可以成功加入購(gòu)物車；

購(gòu)物車商品總數(shù)是否有限制；

商品總數(shù)統(tǒng)計(jì)是否正確；

全選功能是否可用；

刪除功能是否可用；

價(jià)格總計(jì)是否正確；

商品文字太長(zhǎng)時(shí)是否顯示完整；

購(gòu)物車中下架的商品是否有標(biāo)識(shí)，是否還能支付；

新加入購(gòu)物車商品排序（添加購(gòu)物車中存在的店鋪的商品和購(gòu)物車中不存在的店鋪的商品）；

是否支持快TAB、ENTER等快捷鍵；

商品刪除后商品總數(shù)是否減少；

收藏功能是否可用；

購(gòu)物車結(jié)算功能是否可用。

2.兼容性測(cè)試：

BS架構(gòu)：不同瀏覽器測(cè)試，比如：IE，火狐，谷歌，360這些。

APP：在主流的不同類型，不同分辨率，不同操作系統(tǒng)的手機(jī)上測(cè)試，華為，vivo，oppo等

3.用戶體驗(yàn)測(cè)試：

刪除商品是否有提示；

是否支持快捷鍵功能；

是否有回到頂部的功能；

商品過(guò)多時(shí)結(jié)算按鈕是否可以浮動(dòng)顯示；

購(gòu)物車有多個(gè)商品時(shí)，能不能只對(duì)單個(gè)商品結(jié)算；

界面布局、排版是否合理；

文字是否顯示清晰；

不同賣家的商品是否區(qū)分明顯。

4.性能測(cè)試：

打開(kāi)購(gòu)物車頁(yè)面要多長(zhǎng)時(shí)間.

輸入框怎么測(cè)試？

1、長(zhǎng)度：例如輸入框支持100字符，那需要測(cè)試100字符、101字符，最大長(zhǎng)度的顯示是否正常；

2、哪些是支持的字符類型：數(shù)字、字母、漢字、字符！@！#、特殊字符；

3、是否支持換行；

4、字符串前后中帶空格，前后的空格是否過(guò)濾，中間的空格是否保留

5、全角半角的字母、數(shù)字

6、快捷鍵：能不能全選，部分選擇，復(fù)制剪切粘貼是否可用，粘貼超過(guò)最大長(zhǎng)度的字符串怎么顯示，table鍵盤是否可用；

7、不同終端的兼容性

三.登陸功能怎么測(cè)試？

功能方面的測(cè)試：

1.輸入正確的用戶名和密碼，點(diǎn)擊提交按鈕，驗(yàn)證是否能正確登錄，能否能跳轉(zhuǎn)到正確的頁(yè)面

2.輸入錯(cuò)誤的用戶名, 驗(yàn)證登錄失敗，并且提示相應(yīng)的錯(cuò)誤信息

3.輸入錯(cuò)誤的密碼, 驗(yàn)證登錄失敗，并且提示相應(yīng)的錯(cuò)誤信息

4.用戶名為空, 驗(yàn)證登錄失敗，并且提示相應(yīng)的錯(cuò)誤信息

5.密碼為空, 驗(yàn)證登錄失敗，并且提示相應(yīng)的錯(cuò)誤信息

6.用戶名和密碼都為空，點(diǎn)擊登陸

7.用戶名和密碼前后有空格的處理

性能方面的測(cè)試

1.打開(kāi)登錄頁(yè)面，需要多長(zhǎng)時(shí)間

2.輸入正確的用戶名和密碼后，登錄成功跳轉(zhuǎn)到新頁(yè)面，需要多長(zhǎng)時(shí)間.

安全性方面的測(cè)試

1.密碼是否在前端加密，在網(wǎng)絡(luò)傳輸?shù)倪^(guò)程中是否加密

2.用戶名和密碼的輸入框，能否防止SQL注入攻擊

3.用戶名和密碼的輸入框，能否防止XSS攻擊

4.錯(cuò)誤登陸的次數(shù)限制（防止暴力綠色）

5.是否支持多用戶在同一機(jī)器上登錄

6.一個(gè)用戶在不同終端上登陸

7.用戶異地登陸

用戶體驗(yàn)測(cè)試：

1.頁(yè)面布局是否合理，輸入框和按鈕是否對(duì)齊

2.輸入框的大小和按鈕的長(zhǎng)度，高度是否合理

3.是否可以全用鍵盤操作，是否有快捷鍵

4.輸入用戶名，密碼后按回車，是否可以登陸

5. 牽扯到驗(yàn)證碼的，還要考慮文字是否扭曲過(guò)度導(dǎo)致辨認(rèn)難度大，考慮顏色（色盲使用者），刷新或換一個(gè)按鈕是否好用

兼容性測(cè)試

BS架構(gòu)：不同瀏覽器測(cè)試，比如：IE，火狐，谷歌，360這些。

APP：在主流的不同類型，不同分辨率，不同操作系統(tǒng)的手機(jī)上測(cè)試，華為，vivo，oppo等

四.支付功能怎么測(cè)試？

1、從功能方面考慮：

1）、用戶的使用場(chǎng)景：包括正常完成支付的流程；

支付中斷后繼續(xù)支付的流程；

支付中斷后結(jié)束支付的流程；

單訂單支付的流程；

多訂單合并支付的流程；

余額不足；未綁定銀行卡；密碼錯(cuò)誤；密碼錯(cuò)誤次數(shù)過(guò)多；找人代付；

弱網(wǎng)狀態(tài)下，連續(xù)點(diǎn)擊支付功能功能，會(huì)不會(huì)支付多次；分期付款等；

2）、不同終端上支付：

包括PC端的支付、筆記本電腦的支付、平板電腦的支付、手機(jī)端的支付等；

3）、不同的支付方式：銀行卡網(wǎng)銀支付、支付寶支付、微信支付等；

4）、從產(chǎn)品容錯(cuò)性上：包括支付失敗后，能否再次支付、能否退款；

2、從性能方面考慮：

多個(gè)用戶并發(fā)支付能否成功；

支付的響應(yīng)時(shí)間；

3、從安全性方面考慮

使用Fiddler攔截訂單信息，并修改訂單金額，或者修改訂單號(hào)，

是否防止SQL注入，XSS攻擊(跨站腳本攻擊)。

4、從用戶體驗(yàn)方面考慮

是否支持快捷鍵功能；

點(diǎn)擊付款按鈕，是否有提示；

取消付款，是否有提示；

UI界面是否整潔；

輸入框是否對(duì)齊，大小是否適中等。

5、兼容性

BS架構(gòu)：不同瀏覽器測(cè)試。

APP：不同類型，不同分辨率，不同操作系統(tǒng)的手機(jī)上測(cè)試 .

五.還款怎么測(cè)試？

功能上：

1.不同的還款方式：等額本息，等額本金還款，一次性還本付息。

2.逾期，提前還款和第三方還款。

3.不同賬戶的還款。

4.余額不足的還款，.

5.金額輸入錯(cuò)誤，不輸入。

6.弱網(wǎng)狀態(tài)下連續(xù)點(diǎn)擊還款按鈕或者系統(tǒng)不問(wèn)題情況下，支付方未把支付結(jié)果返回給下單發(fā)起方。

從性能方面考慮：

還款的響應(yīng)時(shí)間；

從安全性方面考慮：

是否防止SQL注入，XSS攻擊(跨站腳本攻擊)。

還款金額是否被攔截，還款密碼等敏感信息是否加密。

從用戶體驗(yàn)方面考慮

系統(tǒng)界面是否容易理解。

UI界面是否整潔；

輸入框是否對(duì)齊，大小是否適中等。

兼容性：

BS架構(gòu)：不同瀏覽器測(cè)試。

APP：不同類型，不同分辨率，不同操作系統(tǒng)的手機(jī)上測(cè)試 .

《附》

支付流程：

用戶發(fā)送下單請(qǐng)求-平臺(tái)后臺(tái)查看訂單并制作支付請(qǐng)求后將請(qǐng)求傳給第三方（銀行）-銀行將支付的信息反饋給客戶，客戶核對(duì)后輸入支付密碼--銀行成功劃賬后將支付成功信息告知給平臺(tái)后臺(tái)和用戶--平臺(tái)確認(rèn)支付信息反饋給第三方并發(fā)貨.

退款流程：

用戶提交退款申請(qǐng)給平臺(tái)，平臺(tái)后臺(tái)通過(guò)審核后將退款信息告知給第三方（銀行），第三方將錢退到用戶綁定的銀行賬戶中并告知平臺(tái)處理結(jié)果。平臺(tái)確認(rèn)結(jié)果后并結(jié)束用戶退款申請(qǐng)。

六.電梯如何測(cè)試？

需求測(cè)試：

查看電梯使用說(shuō)明書(shū)、安全說(shuō)明書(shū)等

界面測(cè)試：

查看電梯外觀

功能測(cè)試：

1.測(cè)試電梯能否實(shí)現(xiàn)正常的上升和下降功能。

2.電梯的按鈕是否都可以使用。

3.電梯門的打開(kāi)，關(guān)閉是否正常。

4.報(bào)警裝置是否可用。

5.與其他電梯之間是否協(xié)作良好。

6.通風(fēng)狀況如何。

7.突然停電時(shí)的情況。

8.上升途中的響應(yīng)。

1）電梯本來(lái)在1樓，如果有人按18樓，那么電梯在上升到5樓的時(shí)候，有人按了10樓，這時(shí)候是否會(huì)在10樓先停下來(lái)；

2）電梯下降到10層時(shí)顯示滿員，此時(shí)若8層有人等待電梯，是否在8層停。

可靠性：

1.門關(guān)上的一剎那出現(xiàn)障礙物。

2.同時(shí)按關(guān)門和開(kāi)門按鈕。

3.點(diǎn)擊當(dāng)前樓層號(hào)碼。

4.多次點(diǎn)擊同一樓層的號(hào)碼等等。

5.同時(shí)按上鍵和下鍵會(huì)怎樣。

易用性：

1.電梯的按鈕的設(shè)計(jì)符合一般人使用的習(xí)慣嗎．

負(fù)載/壓力測(cè)試：

1.看電梯的最大限度的承受重量．在負(fù)載過(guò)重時(shí)是否有提醒。

2.在一時(shí)間內(nèi)不斷的讓電梯上升，下降。

穩(wěn)定性測(cè)試：

1.最大負(fù)載下平穩(wěn)運(yùn)行的最長(zhǎng)時(shí)間。

文檔測(cè)試：

1.使用手冊(cè)是否對(duì)電梯的用法、限制、使用條件等有詳細(xì)描述.

四、測(cè)試工作基本流程

測(cè)試工作基本流程包括四個(gè)基本活動(dòng)、即測(cè)試需求分析、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行、測(cè)試分析與總結(jié)，關(guān)鍵成果包括《測(cè)試需求分析》、《測(cè)試方案》、《測(cè)試記錄》、《測(cè)試報(bào)告》。在實(shí)際測(cè)試工作中，會(huì)出現(xiàn)若干環(huán)節(jié)的迭代循環(huán)，也會(huì)出現(xiàn)要求弱化，或者要求強(qiáng)化。只要是實(shí)現(xiàn)測(cè)試目標(biāo)的必要調(diào)整，都可以按需進(jìn)行。

輸入： 原始需求，包括但不限于《產(chǎn)品設(shè)計(jì)文檔（PRD）》、《系統(tǒng)需求說(shuō)明書(shū)》、《立項(xiàng)書(shū)》、《項(xiàng)目合同》

輸出： 《測(cè)試需求分析》、《測(cè)試規(guī)劃》

注意事項(xiàng)：

輸入： 《測(cè)試需求分析》、《測(cè)試規(guī)劃》

輸出： 《測(cè)試方案》、《測(cè)試計(jì)劃》、《測(cè)試用例》

注意事項(xiàng)：

輸入： 《測(cè)試方案》、《測(cè)試計(jì)劃》、《測(cè)試用例》

輸出： 《測(cè)試記錄》

注意事項(xiàng)：

輸入： 《測(cè)試記錄》

輸出： 《測(cè)試報(bào)告》

注意事項(xiàng)：