上傳人：m***

認(rèn)證信息

認(rèn)證類型：個(gè)人認(rèn)證

認(rèn)證主體：董**（實(shí)名認(rèn)證）

IP屬地：天津

IP屬地：天津 上傳時(shí)間：2022-01-05 格式：DOCX 頁數(shù)：11 大?。?5.02KB 積分：18 舉報(bào) 版權(quán)申訴

1、實(shí)用標(biāo)準(zhǔn)文案測試流程及測試?yán)碚摲椒ā?測試流程1. 軟件開發(fā)流程：需求分析 概要設(shè)計(jì) 詳細(xì)設(shè)計(jì) 編碼開發(fā) 測試 維護(hù)2. 測試流程為 ：單元測試 /集成測試 系統(tǒng)測試 / 自動(dòng)化測試 性能測試 驗(yàn)收測試3. 目標(biāo)：3.1 制定完整且具體的測試路線和流程，為快速、高效和高質(zhì)量的軟件測試提供基 礎(chǔ)流程框架。3.2 最終目標(biāo)是實(shí)現(xiàn)軟件測試規(guī)范化、標(biāo)準(zhǔn)化、自動(dòng)化。4. 測試流程說明：5. 測試需求分析 測試需求是整個(gè)測試過程的基礎(chǔ)；確定測試對象以及測試工作的范圍和作用。用 來確定整個(gè)測試工作 （如安排時(shí)間表、測試設(shè)計(jì)等）并作為測試覆蓋的基礎(chǔ)。而且被確定的 測試需求項(xiàng)必須是可核實(shí)的。即，它們必須有一個(gè)可

2、觀察、可評(píng)測的結(jié)果。 無法核實(shí)的需求 不是測試需求。 所以我現(xiàn)在的理解是測試需求是一個(gè)比較大的概念， 它是在整個(gè)測試計(jì)劃文 檔中體現(xiàn)出來的，不是類似的一個(gè)用例或者其他 .·測試需求是制訂測試計(jì)劃的基本依據(jù)，確定了測試需求能夠?yàn)闇y試計(jì)劃提供客觀依據(jù)； ·測試需求是設(shè)計(jì)測試用例的指導(dǎo)， 確定了要測什么、 測哪些方面后才能有針對性的設(shè)計(jì)測 試用例；·測試需求是計(jì)算測試覆蓋的分母，沒有測試需求就無法有效地進(jìn)行測試覆蓋。5.1 測試方法與規(guī)范5.1.1 測試方法隨著軟件技術(shù)發(fā)展， 項(xiàng)目類型越來越多樣化。 根據(jù)項(xiàng)目類型應(yīng)選用針對性強(qiáng)的 測試方法， 合適的測試方法可以讓我們事半

3、功倍。 以下是針對目前項(xiàng)目工程可以參考的測試 方法：? 測試 （ beta 測試） - 非程序員、測試人員 測試，英文是 Beta testing 。又稱 Beta 測試，用戶驗(yàn)收測試（ UAT）。 測試是軟件的多個(gè)用戶在一個(gè)或多個(gè)用戶的實(shí)際使用環(huán)境下進(jìn)行的測試。 開發(fā)者通常 不在測試現(xiàn)場， Beta 測試不能由程序員或測試員完成。當(dāng)開發(fā)和測試根本完成時(shí)所做的測試，而最終的錯(cuò)誤和問題需要在最終發(fā)行前找到。 這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。? 測試（ Alpha 測試） - 非程序員、測試人員 測試，英文是 Alpha testing 。又稱 Alpha 測試 .

4、 Alpha 測試是由一個(gè)用戶在開發(fā)環(huán)境下進(jìn)行的測試， 也可以是公司內(nèi)部的用戶在模擬實(shí) 際操作環(huán)境下進(jìn)行的受控測試， Alpha 測試不能由該系統(tǒng)的程序員或測試員完成。在系統(tǒng)開發(fā)接近完成時(shí)對應(yīng)用系統(tǒng)的測試 ;測試后， 仍然會(huì)有少量的設(shè)計(jì)變更。這種測 試一般由最終用戶或其他人員來完成，不能由程序員或測試員完成。? 兼容性測試 - 測試人員 兼容性測試是指測試軟件是否可以成功移植到指定的硬件或者軟件環(huán)境中， 例如在 B/S 項(xiàng)目中各個(gè)不同瀏覽器之間的測試。? 用戶界面測試 -UI 測試 - 測試人員 用戶界面測試，英文是 User interface testing 。又稱 UI 測試。 用戶界面

5、，英文是 User interface 。是指軟件中的可見外觀及其底層與用戶交互的部 分（菜單、對話框、窗口和其它控件）。用戶界面測試是指測試用戶界面的風(fēng)格是否滿足客戶要求， 文字是否正確， 頁面是否美 觀，文字， 圖 片組合是否完美， 操作是否友好等等。 UI 測試的目標(biāo)是確保用戶界面會(huì)通過 測試對象的功能來為用戶提供相應(yīng)的訪問或?yàn)g覽功能。 確保用戶界面符合公司或行業(yè)的標(biāo)準(zhǔn)。 包括用戶友好性、人性化、易操作性 測試。用戶界面測試用戶分析軟件用戶界面的設(shè)計(jì)是否合乎用戶期望或要求。 它常常包括 菜單，對話框及對 話框上所有按鈕，文字，出錯(cuò)提示，幫助信息 （Menu 和 Help content）

6、 等方面的測試。比如，測試 Microsoft Excel 中插入符號(hào)功能所用的對話框的大小，所有按 鈕是否對齊，字符串字體大小，出錯(cuò)信息內(nèi)容和字體大小，工具欄位置 / 圖標(biāo)等等。? 冒煙測試 - 版本編譯者 冒煙測試，英文是 Smoke testing 。 冒煙測試的名稱可以理解為該種測試耗時(shí)短， 僅用一袋煙功夫足夠了。 也有人認(rèn)為是形 象地類比新電路板功基本功能檢查。 任何新電路板焊好后， 先通電檢查， 如果存在設(shè)計(jì)缺陷， 電路板可能會(huì)短路，板子冒煙了。冒煙測試的對象是每一個(gè)新編譯的需要正式測試的軟件版本， 目的是確認(rèn)軟件基本功能 正常，可以進(jìn)行后續(xù)的正式測試工作。冒煙測試的執(zhí)行者是版本編

7、譯人員。? 隨機(jī)測試 - 測試人員 隨機(jī)測試，英文是 Ad hoc testing 。隨機(jī)測試沒有書面測試用例、記錄期望結(jié)果、 檢查列表、 腳本或指令的測試。 主要是根 據(jù)測試者的經(jīng)驗(yàn)對軟件進(jìn)行功能和性能抽查。 隨機(jī)測試是根據(jù)測試說明書執(zhí)行用例測試的重 要補(bǔ)充手段，是保證測試覆蓋完整性的有效方式和過程。隨機(jī)測試主要是對被測軟件的一些重要功能進(jìn)行復(fù)測， 也包括測試那些當(dāng)前的測試樣例 (TestCase) 沒有覆蓋到的部分。 另外， 對于軟件更新和新增加的功能要重點(diǎn)測試。重點(diǎn)對一些特殊點(diǎn)情況點(diǎn)、 特殊的使用環(huán)境、 并發(fā)性、 進(jìn)行檢查。 尤其 對以前測試發(fā)現(xiàn)的重大 Bug， 進(jìn)行再次測試，可以結(jié)合回

8、歸測試 (Regressive testing)一起進(jìn)行。? 黑盒測試(功能測試) - 測試人員黑盒測試，英文是 Black Box Testing 。又稱功能測試或者數(shù)據(jù)驅(qū)動(dòng)測試。黑盒測試是根據(jù)軟件的規(guī)格對軟件進(jìn)行的測試，這類測試不考慮軟件內(nèi)部的運(yùn)作原理， 因此軟件對用戶來說就像一個(gè)黑盒子。在完全不考慮程序內(nèi)部結(jié)構(gòu)和特性的情況下， 測試軟件的外部特性。 根據(jù)軟件的需求規(guī) 格說明書設(shè)計(jì)測試用例， 從程序輸入和輸出特性上檢查程序是否滿足設(shè)定的功能。 黑盒測試 常采用的方法是設(shè)計(jì)適量有效和無效的輸入數(shù)據(jù)進(jìn)行測試， 以期用最小的代價(jià)發(fā)現(xiàn)最多的錯(cuò) 誤。軟件測試人員以用戶的角度， 通過各種輸入和觀察軟件

9、的各種輸出結(jié)果來發(fā)現(xiàn)軟件存在 的缺陷，而不關(guān)心程序具體如何實(shí)現(xiàn)的一種軟件測試方法。個(gè)人復(fù)查 個(gè)人復(fù)查是指程序員自行設(shè)計(jì) 測試用例 ，對源代碼、 詳細(xì)設(shè)計(jì)進(jìn)行仔細(xì)檢查， 并記錄錯(cuò) 誤、不足之處等。個(gè)人復(fù)查主要包括檢查變量的正確性、檢查標(biāo)號(hào)的正確性、檢查子程序、 宏、函數(shù)、常量檢查、標(biāo)準(zhǔn)檢查、風(fēng)格檢查、比較控制流、選擇、激活路徑、對照詳細(xì)說明 書，閱讀源代碼和補(bǔ)充文檔等方面的測試內(nèi)容。走查 走查是指測試人員先閱讀相應(yīng)的文檔和源代碼，然后人工將測試數(shù)據(jù)輸入被測試程序， 并在紙上跟蹤監(jiān)視程序的執(zhí)行情況， 人工沿著程序的邏輯走查運(yùn)行一遍， 跟蹤走查運(yùn)行的進(jìn) 程來發(fā)現(xiàn)程序的錯(cuò)誤。 走查的具體測試內(nèi)容包括模

10、塊特性、 模塊接口、 模塊的對外輸入或輸 出、局部數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)計(jì)算錯(cuò)誤、控制流錯(cuò)誤、處理出錯(cuò)和邊界測試等方面。會(huì)審 會(huì)審是指測試人員在會(huì)審前仔細(xì)閱讀軟件的有關(guān)資料， 根據(jù)錯(cuò)誤類型清單 (根據(jù)以往的 經(jīng)驗(yàn)、 對源程序的估計(jì)等，并在以后測試中給以豐富補(bǔ)充)填寫檢測表，提出根據(jù)錯(cuò)誤類型 要提出的問題。 會(huì)審時(shí)， 由程序設(shè)計(jì)人員講解程序的設(shè)計(jì)方法， 由程序編寫人員逐個(gè)講解程 序代碼的編寫，測試人員需要逐個(gè)審查，提問，討論可能出現(xiàn)的問題。會(huì)審對程序的功能、 結(jié)構(gòu)、邏輯和風(fēng)格都要進(jìn)行審定。會(huì)審的測試內(nèi)容與“走查”的內(nèi)容相同。白盒測試白盒也稱結(jié)構(gòu)測試， 這是將軟件看成一個(gè)透明的白盒子， 按照程序的內(nèi)部結(jié)構(gòu)

11、和處理邏 輯來選定測試用例，對軟件的邏輯路徑及過程進(jìn)行測試，檢查它與設(shè)計(jì)是否相符。性能測試性能測試，英文是 Performance Testing 。 性能測試是在交替進(jìn)行負(fù)荷和強(qiáng)迫測試時(shí)常用的術(shù)語。理想的“性能測試” （ 和其他類 型的測試 ） 應(yīng)在需求文檔或質(zhì)量保證、測試計(jì)劃中定義。性能測試一般包括負(fù)載測試和壓力 測試。通常驗(yàn)證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復(fù)使用是否還能滿足性能指標(biāo)。 或 者執(zhí)行同樣任務(wù)時(shí)新版本不比舊版本慢。 一般還檢查系統(tǒng)記憶容量在運(yùn)行程序時(shí)會(huì)不會(huì)流失 （memory leak） 。比如，驗(yàn)證程序保存一個(gè)巨大的文件新版本不比舊版本慢。5.1.2 測試規(guī)范測試規(guī)范是根

12、據(jù)開發(fā)規(guī)范而制定的測試標(biāo)準(zhǔn)， 測試規(guī)范也是后期測試用例編寫的重 要依據(jù)。 因?yàn)殚_發(fā)規(guī)范因公司而異， 因產(chǎn)品而異， 所以測試規(guī)范的標(biāo)準(zhǔn)程度每個(gè)公司都不一 樣。從理論到方法到各類流程到各類報(bào)告模版， 都屬于測試規(guī)范的范疇， 當(dāng)一整套規(guī)范形成 之后，可使得測試工作進(jìn)行更加穩(wěn)健，所有問題有據(jù)可查。5.2 軟件需求規(guī)格說明書 軟件需求規(guī)格說明書是軟件達(dá)到的各項(xiàng)功能的目標(biāo)。是測試人員各項(xiàng)工作的依據(jù)， 沒有需求就無法判斷測試結(jié)果是正確的。5.3 軟件設(shè)計(jì)說明（概要與詳細(xì)設(shè)計(jì)）設(shè)計(jì)說明書包含軟件的一些框架、 字段、 數(shù)據(jù)庫設(shè)計(jì)等。 軟件設(shè)計(jì)說明對測試工作 開展有很大影響， 沒有軟件設(shè)計(jì)說明很多問題將無法溯源，

13、 測試準(zhǔn)備的前期工作也是根據(jù)軟 件設(shè)計(jì)說明來制定的。5.4 頁面原型（ demo）頁面原型是項(xiàng)目人員快速熟悉項(xiàng)目的最佳路徑。 在需求不夠明確， 設(shè)計(jì)說明書不夠全面的情況下，頁面原型也是后期測試用例編寫思想的重要根據(jù)6. 測試過程設(shè)計(jì)明確測試目的，最終達(dá)成目的并驗(yàn)證結(jié)果是測試要做的事情。包括：1. 測試范圍：描述本次測試中的測試范圍，如：測試軟件功能范圍、測試種類等。2. 簡單的描述如何搭建測試平臺(tái)以及測試的潛在的風(fēng)險(xiǎn)。3. 項(xiàng)目信息：說明要測試的項(xiàng)目的相關(guān)資料，如：輸入輸出文檔，產(chǎn)品描述，軟件主 要功能。4. 人力資源的分配。5. 測試需求：籠統(tǒng)說，就是測試中的所有設(shè)計(jì)和需求文檔。作為本次測試

14、的依據(jù)6.1 測試策略制定 這一階段在于需求、詳細(xì)設(shè)計(jì)、測試計(jì)劃完成之后，主要是本次測試的策略階段。 很多公司缺少這個(gè)階段， 需要有計(jì)劃性的分出產(chǎn)品的功能扣出測試的功能點(diǎn)， 現(xiàn)階 段大多公司都是直接拿著文檔就開始做用例設(shè)計(jì)。對需求進(jìn)行分析，列出具體的功能列表。 （一般根據(jù)功能交互文檔就能明確出此功 能的大體功能， 一層層的分下去， 一直到每個(gè)功能表單。 然后考慮到使用哪些測試 方法？工作一旦做到執(zhí)行階段，我們可以更好的根據(jù)這些功能表一點(diǎn)一點(diǎn)的覆蓋。 也能讓我們在用例評(píng)審時(shí)， 充分的證實(shí)我們的工作是有效的能夠保證產(chǎn)品的質(zhì)量。 ） 一般在此之前， 一些業(yè)務(wù)培訓(xùn)和需求評(píng)審是有必要是聽一下的。 這樣能

15、夠更早更熟 練的理解需求，也能保證產(chǎn)品設(shè)計(jì)中出現(xiàn)的一些誤區(qū)。對于一個(gè)個(gè)測試該如何進(jìn)行測試？如下：a）功能測試? 功能范圍（劃分出各自負(fù)責(zé)的功能模塊）? 使用測試方法（等價(jià)類、邊界值等測試方法）? 測試標(biāo)準(zhǔn)（符合設(shè)計(jì)、需求和規(guī)范文檔對該功能的描述）b）界面測試c）兼容性測試d）性能測試6.2 測試計(jì)劃精彩文檔1) 要充分考慮測試計(jì)劃的實(shí)用性， 即測試計(jì)劃與實(shí)際之間的接近程度和可操作性。 編 寫測試計(jì)劃的目的在于充分考慮執(zhí)行測試時(shí) 的各種資源，包括測試內(nèi)容、測試標(biāo) 準(zhǔn)、時(shí)間資源、 人力資源等等， 準(zhǔn)確地說是要分析執(zhí)行時(shí)所能夠調(diào)用的一切資源以 及受各種條件限制，可能受到的各種影響。a) 測試內(nèi)容：對

16、一個(gè)軟件來說測試計(jì)劃中會(huì)明確本次測試做哪些測試？ 如：系統(tǒng)測試：在整個(gè)系統(tǒng)測試中會(huì)有(界面測試、功能測試、性能測試、兼 容性測試、安裝卸載測試、可靠性測試等測試) 。b) 測試目的： 一般多為保證產(chǎn)品質(zhì)量是否達(dá)到預(yù)期的指標(biāo)。 這個(gè)指標(biāo)也就是在測 試中定義的結(jié)束標(biāo)準(zhǔn)。c) 測試標(biāo)準(zhǔn)： 需要考慮本次測試需要輸入那些文檔， 該項(xiàng)目結(jié)束標(biāo)準(zhǔn)定義、 測試 結(jié)束標(biāo)準(zhǔn)的定義？ bug 級(jí)別定義、優(yōu)先級(jí)定義、 bug 管理流程定義。這個(gè)都需 要在執(zhí)行測試時(shí)明確。計(jì)劃中應(yīng)該包含這些內(nèi)容。d) 資源分配： 這里分為人力資源、 軟硬件資源等劃分。 一般會(huì)把人力資源的利用 寫入一個(gè)測試人員任務(wù)分配表里， 按照不同的階

17、段， 每個(gè)階段提交相應(yīng)的成果 (難度很大) 。軟硬件資源中主要是在做計(jì)劃時(shí)考慮到需要多少電腦或別的工 具，列出清單。e) 測試風(fēng)險(xiǎn)： 大多考慮到的就是項(xiàng)目開發(fā)延期、 測試人員不足用例無法全面覆蓋 測試點(diǎn)、時(shí)間不足用例無法全部執(zhí)行、 bug 無法及時(shí)修改導(dǎo)致無法驗(yàn)證、測試 人員技能不足導(dǎo)致測試進(jìn)度拉長。f) 軟件測試策略一般都是分開來做相關(guān)測試方案。6.3 測試附件用例模板、缺陷報(bào)告模板 測試環(huán)境的搭建 缺陷管理流程和缺陷級(jí)別定義缺陷狀態(tài)一般分為：新建、打開、已分配、已修復(fù)、關(guān)閉、重新打開中間會(huì)有：延期、重復(fù)、拒絕等狀態(tài)缺陷管理流程：1. 測試人員或開發(fā)人員發(fā)現(xiàn) bug 后，判斷輸入哪個(gè)模塊的問

18、題，填寫 bug 報(bào)告后，系 統(tǒng)會(huì)自動(dòng)通過 Email 通知開發(fā)組長和該模塊開發(fā)者。2. 開發(fā)組長根據(jù)具體情況，重新 reassigned 分配給 bug 所屬的開發(fā)者。3. 開發(fā)者收到 email 信息后，判斷是否為自己的修改范圍。 若不是，重新 reassigned 分配給開發(fā)組長或應(yīng)該分配的開發(fā)者。 若是，進(jìn)行處理， resolved 并給出解決方法。 （可創(chuàng)建補(bǔ)丁附件及補(bǔ)充說明）4. 測試人員查詢開發(fā)者已修改的 bug ，進(jìn)行回歸測試。 經(jīng)驗(yàn)證無誤后，修改狀態(tài)為 verified 。待整個(gè)產(chǎn)品發(fā)布后，修改為 closed 。 還有問題， reopened ，狀態(tài)重新變?yōu)椤?new”，并

19、發(fā)送郵件通知。5. 如果這個(gè) bug 一周內(nèi)一直沒被處理過。 Bugzilla 就會(huì)一直用 email 騷擾它的屬主， 直接采取行動(dòng)。管理員可以設(shè)定最遲采取行動(dòng)的期限，比如 3 天，系統(tǒng)默認(rèn) 7 天。缺陷等級(jí)劃分：分級(jí)Bug等級(jí)Bug等級(jí)說明分類說明致命問題Blocker導(dǎo)致整個(gè)產(chǎn)品無法進(jìn)行 模塊無法啟動(dòng)或異常退出Critical測試。修改優(yōu)先級(jí)為最 高，該級(jí)別需要程序員 立即修改死機(jī)，數(shù)據(jù)丟失，主要 功能完全喪失，系統(tǒng)懸 掛等錯(cuò)誤。修改優(yōu)先級(jí) 為最高，該級(jí)別需要程 序員立即修改 其它導(dǎo)致無法測試的錯(cuò)誤 運(yùn)行過程中系統(tǒng)崩潰 / 死機(jī) / 重啟 功能設(shè)計(jì)與需求嚴(yán)重不符 嚴(yán)重花屏 內(nèi)存泄漏 影響手

20、機(jī)語音或數(shù)據(jù)通訊等 嚴(yán)重的數(shù)值計(jì)算錯(cuò)誤嚴(yán)重問題Major主要功能喪失，導(dǎo)致嚴(yán) 重的問題，或致命的錯(cuò) 誤聲明。修改優(yōu)先級(jí)為 高，該級(jí)別需要程序員 盡快修改Normal次要功能喪失， 不太嚴(yán) 重，如提示信息不太準(zhǔn) 確。修改優(yōu)先級(jí)為中， 該級(jí)別需要程序員修改一般問題Minor微小的問題，對功能幾 乎沒有影響，產(chǎn)品及屬 性仍可使用。修改優(yōu)先 級(jí)為低，該級(jí)別需要程 序員修改或不修改 功能未實(shí)現(xiàn)或者存在錯(cuò)誤 輕微的數(shù)值計(jì)算錯(cuò)誤 系統(tǒng)所提供的功能或服務(wù)受明顯的影響 用戶數(shù)據(jù)丟失或破壞 操作界面錯(cuò)誤（包括數(shù)據(jù)窗口內(nèi)列名定義、 含義是否一致） 邊界條件下錯(cuò)誤 功能存在錯(cuò)誤，但出現(xiàn)概率很低 提示信息錯(cuò)誤（包括未給

21、出信息、信息提示錯(cuò)誤等） 長時(shí)間操作無進(jìn)度提示 系統(tǒng)未優(yōu)化（性能問題） 界面格式等不規(guī)范 操作時(shí)未給用戶提示 文字排列不整齊等一些小問題 光標(biāo)跳轉(zhuǎn)設(shè)置不好，鼠標(biāo)（光標(biāo)）定位錯(cuò)誤Trivial輕微問題Enhancement提示信息格式不符合要 求 , 違背正常習(xí)俗習(xí)慣 的，界面不美觀，控件 排列、格式不統(tǒng)一 功能性建議，功能使用 性、方便性、易用性不 輔助說明描述不清楚 個(gè)別不影響產(chǎn)品理解的錯(cuò)別字 可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標(biāo)志 建議7. 測試實(shí)施7.1 執(zhí)行開發(fā)就會(huì)轉(zhuǎn)版本給我們測試部門進(jìn)行系統(tǒng)測試了。 拿到版本我們首先搭建測試環(huán)境 做一個(gè)預(yù)測試， 目的是來評(píng)斷這個(gè)版本是不是可測試的。 如果預(yù)測試不通過， 打回 開發(fā)部返工，如果通過了，就開始我們第一輪的系統(tǒng)測試。第一輪系統(tǒng)測試我們會(huì)執(zhí)行我們所編寫的所有測試用例， 做好測試結(jié)果的記錄， 發(fā) 現(xiàn)缺陷了提交缺陷報(bào)告。 當(dāng)?shù)谝惠啘y試結(jié)束后， 我們把所有的 b