正文

功能測試的基本流程（軟件測試的5個基本流程）

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

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

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

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

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

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

本文目錄:

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

功能測試的基本流程（軟件測試的5個基本流程）

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

1.概述

1.1目的 2

1.2適用范圍 2

1.3執(zhí)行原則. 2

1.4角色和職責(zé) 2

1.4.1 測試leader 2

1.4.2 測試工程師 3

2.軟件測試流程 3

2.1軟件測試流程圖 3

2.2 流程圖解析 4

3.軟件測試周期人員活動 7

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

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

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

3.2.2軟件測試執(zhí)行階段人員活動 9

3.2.3測試掃尾工作 11

4.結(jié)語 12

1.概述

1.1目的

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

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

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

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

5、判定測試過程和問題驗證的有效性。

1.2適用范圍

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

1.3執(zhí)行原則.

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

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

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

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

1.4角色和職責(zé)

1.4.1 測試leader

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

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

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

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

參與版本風(fēng)險評估

參與軟件需求與UI評審

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

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

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

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

11.組織版本風(fēng)險評估

1.4.2 測試工程師

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

測試記錄的整理，

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

參與BUG的評審

定時完成學(xué)習(xí)計劃并提交學(xué)習(xí)報告給測試leader

2. 軟件測試流程

2.1軟件測試流程圖

2.2 流程圖解析

立項

對于版本，立項的條件只需要滿足：

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

版本進(jìn)度表

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

需求初審

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

1.測試依據(jù)

a,軟件需求文檔

b,其他，如參考其他競品等

測試資源

a,測試人員需求

b,測試配置需求（需要前期的配置）

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

測試策略

a,采取測試方法

b,采取哪些測試工具以及測試管理工具

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

測試人員安排

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

需求分析

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

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

測試設(shè)計

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

測試計劃

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

測試執(zhí)行

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

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

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

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

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

b, 測試效率問題，怎樣提高測試效率?

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

軟件評估

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

測試總結(jié)

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

測試維護(hù)

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

3.軟件測試周期人員活動

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

目的

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

按照需求制定好測試策略與測計劃；

進(jìn)入條件

版本正式啟動

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

輸入

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

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

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

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

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

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

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

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

測試leader、測試組員測試用例

Case編寫的依據(jù)：

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

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

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

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

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

4. 針對不同測試目的編寫測試用例；

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

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

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

測試leader

測試計劃評審注意事項：

1. 保證測試計劃要符合開發(fā)計劃

2. 測試的全面性；

輸出

測試用例

3.2 測試執(zhí)行階段

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

流程圖解析

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

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

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

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

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

3.2.2軟件測試執(zhí)行階段人員活動

目的

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

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

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

判定測試過程和問題驗證的有效性；

進(jìn)入條件

完成測試計劃和測試用例;

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

輸入

軟件測試計劃和軟件測試用例。

軟件版本；

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

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

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

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

測試leader每個新版本軟件測試計劃

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

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

測試leader

組員

測試報告

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

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

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

輸出

每個新版本軟件測試計劃、測試報告、內(nèi)存峰值測試報告、兼容性測試報告

3.2.3測試掃尾工作

目的

根據(jù)測試結(jié)果，組織版本評估

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

進(jìn)入條件

完成了測試執(zhí)行階段，PM申請上線

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

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

1版本評估上線前，測試leader書寫軟件測試報告并組織版本評估會議，邀請開發(fā)leader、項目經(jīng)理等管理人員組織版本評估會議，最終由項目經(jīng)理確認(rèn)軟件是否能夠上線。項目經(jīng)理（PM）

測試leader

測試組員

軟件開發(fā)leader等

評估結(jié)果

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

測試組員

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

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

測試leader

測試組員

測試報告

4.結(jié)語

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

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

二、軟件測試的流程是什么？

軟件測試的流程：

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

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

3、提交測試報告。

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

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

三、各種功能測試點步驟

一.支付功能怎么測試？

1、從功能方面考慮：

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

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

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

單訂單支付的流程；

多訂單合并支付的流程；

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

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

2）、不同終端上支付：

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

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

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

2、從性能方面考慮：

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

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

3、從安全性方面考慮

使用Fiddler攔截訂單信息，并修改訂單金額，或者修改訂單號，

(下兩個訂單A,B，付款時攔截訂單B，并把訂單B的訂單號改為A訂單的訂單號)無法完成支付；

4、從用戶體驗方面考慮

是否支持快捷鍵功能；

點擊付款按鈕，是否有提示；

取消付款，是否有提示；

UI界面是否整潔；

輸入框是否對齊，大小是否適中等。

5、兼容性

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

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

二.購物車怎么測試？

1.功能測試

a）、未登錄時：

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

b）、登錄后：

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

商品是否可以成功加入購物車；

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

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

全選功能是否可用；

刪除功能是否可用；

價格總計是否正確；

商品文字太長時是否顯示完整；

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

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

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

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

收藏功能是否可用；

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

2.兼容性測試：

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

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

3.用戶體驗測試：

刪除商品是否有提示；

是否支持快捷鍵功能；

是否有回到頂部的功能；

商品過多時結(jié)算按鈕是否可以浮動顯示；

購物車有多個商品時，能不能只對單個商品結(jié)算；

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

文字是否顯示清晰；

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

4.性能測試：

打開購物車頁面要多長時間.

輸入框怎么測試？

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

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

3、是否支持換行；

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

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

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

7、不同終端的兼容性

三.登陸功能怎么測試？

功能方面的測試：

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

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

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

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

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

6.用戶名和密碼都為空，點擊登陸

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

性能方面的測試

1.打開登錄頁面，需要多長時間

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

安全性方面的測試

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

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

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

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

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

6.一個用戶在不同終端上登陸

7.用戶異地登陸

用戶體驗測試：

1.頁面布局是否合理，輸入框和按鈕是否對齊

2.輸入框的大小和按鈕的長度，高度是否合理

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

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

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

兼容性測試

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

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

四.支付功能怎么測試？

1、從功能方面考慮：

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

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

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

單訂單支付的流程；

多訂單合并支付的流程；

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

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

2）、不同終端上支付：

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

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

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

2、從性能方面考慮：

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

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

3、從安全性方面考慮

使用Fiddler攔截訂單信息，并修改訂單金額，或者修改訂單號，

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

4、從用戶體驗方面考慮

是否支持快捷鍵功能；

點擊付款按鈕，是否有提示；

取消付款，是否有提示；

UI界面是否整潔；

輸入框是否對齊，大小是否適中等。

5、兼容性

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

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

五.還款怎么測試？

功能上：

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

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

3.不同賬戶的還款。

4.余額不足的還款，.

5.金額輸入錯誤，不輸入。

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

從性能方面考慮：

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

從安全性方面考慮：

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

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

從用戶體驗方面考慮

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

UI界面是否整潔；

輸入框是否對齊，大小是否適中等。

兼容性：

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

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

《附》

支付流程：

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

退款流程：

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

六.電梯如何測試？

需求測試：

查看電梯使用說明書、安全說明書等

界面測試：

查看電梯外觀

功能測試：

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

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

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

4.報警裝置是否可用。

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

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

7.突然停電時的情況。

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

1）電梯本來在1樓，如果有人按18樓，那么電梯在上升到5樓的時候，有人按了10樓，這時候是否會在10樓先停下來；

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

可靠性：

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

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

3.點擊當(dāng)前樓層號碼。

4.多次點擊同一樓層的號碼等等。

5.同時按上鍵和下鍵會怎樣。

易用性：

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

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

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

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

穩(wěn)定性測試：

1.最大負(fù)載下平穩(wěn)運行的最長時間。

文檔測試：

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

四、測試工作基本流程

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

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

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

注意事項：

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

輸出： 《測試方案》、《測試計劃》、《測試用例》

注意事項：

輸入： 《測試方案》、《測試計劃》、《測試用例》

輸出： 《測試記錄》

注意事項：

輸入： 《測試記錄》

輸出： 《測試報告》

注意事項：