上傳人：d***

認(rèn)證信息

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

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

IP屬地：天津

IP屬地：天津 上傳時間：2022-03-09 格式：DOCX 頁數(shù)：8 大小：19.91KB 積分：18 舉報 版權(quán)申訴

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

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

3、ta測試）-非程序員、測試人員3測試，英文是 Betatesting 。又稱Beta測試，用戶驗收測試（UAT）。3測試是軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進(jìn)行的測試。開發(fā)者通常不在測試現(xiàn)場， Beta 測試不能由程序員或測試員完成。當(dāng)開發(fā)和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發(fā)行前找到。這種測試一般由最終用戶或其他人員完成，不能由程序員或測試員完成。?”測試（Alpha測試）-非程序員、測試人員a測試，英文是 Alphatesting 。又稱 Alpha測試.Alpha 測試是由一個用戶在開發(fā)環(huán)境下進(jìn)行的測試， 也可以是公司內(nèi)部的用戶在模擬實際操作環(huán)境下進(jìn)行的受

4、控測試， Alpha 測試不能由該系統(tǒng)的程序員或測試員完成。在系統(tǒng)開發(fā)接近完成時對應(yīng)用系統(tǒng)的測試 ; 測試后， 仍然會有少量的設(shè)計變更。這種測試一般由最終用戶或其他人員來完成，不能由程序員或測試員完成。? 兼容性測試 - 測試人員兼容性測試是指測試軟件是否可以成功移植到指定的硬件或者軟件環(huán)境中， 例如在 B/S 項目中各個不同瀏覽器之間的測試。 ? 用戶界面測試 -UI 測試 - 測試人員用戶界面測試，英文是Userinterfacetesting 。又稱 UI 測試。用戶界面，英文是Userinterface 。是指軟件中的可見外觀及其底層與用戶交互的部分(菜單、對話框、窗口和其它控件)。用

5、戶界面測試是指測試用戶界面的風(fēng)格是否滿足客戶要求， 文字是否正確， 頁面是否美觀，文字，圖片組合是否完美，操作是否友好等等。 UI 測試的目標(biāo)是確保用戶界面會通過測試對象的功能來為用戶提供相應(yīng)的訪問或瀏覽功能。確保用戶界面符合公司或行業(yè)的標(biāo)準(zhǔn)。包括用戶友好性、人性化、易操作性測試。用戶界面測試用戶分析軟件用戶界面的設(shè)計是否合乎用戶期望或要求。 它常常包括菜單， 對話框及對話框上所有按鈕， 文字，出錯提示，幫助信息(Menu 和 Helpcontent) 等方面的測試。比如，測試MicrosoftExcel 中插入符號功能所用的對話框的大小，所有按鈕是否對齊，字符串字體大小，出錯信息內(nèi)容和字體大

6、小，工具欄位置/ 圖標(biāo)等等。? 冒煙測試 - 版本編譯者冒煙測試，英文是Smoketesting 。冒煙測試的名稱可以理解為該種測試耗時短， 僅用一袋煙功夫足夠了。 也有人認(rèn)為是形象地類比新電路板功基本功能檢查。 任何新電路板焊好后， 先通電檢查， 如果存在設(shè)計缺陷， 電路板可能會短路，板子冒煙了。冒煙測試的對象是每一個新編譯的需要正式測試的軟件版本， 目的是確認(rèn)軟件基本功能正常，可以進(jìn)行后續(xù)的正式測試工作。冒煙測試的執(zhí)行者是版本編譯人員。? 隨機測試 - 測試人員隨機測試，英文是Adhoctesting 。隨機測試沒有書面測試用例、記錄期望結(jié)果、 檢查列表、 腳本或指令的測試。 主要是根據(jù)測

7、試者的經(jīng)驗對軟件進(jìn)行功能和性能抽查。 隨機測試是根據(jù)測試說明書執(zhí)行用例測試的重要補充手段，是保證測試覆蓋完整性的有效方式和過程。隨機測試主要是對被測軟件的一些重要功能進(jìn)行復(fù)測， 也包括測試那些當(dāng)前的測試樣例(TestCase) 沒有覆蓋到的部分。 另外， 對于軟件更新和新增加的功能要重點測試。 重點對一些特殊點情況點、特殊的使用環(huán)境、并發(fā)性、進(jìn)行檢查。尤其對以前測試發(fā)現(xiàn)的重大Bug，進(jìn)行再次測試，可以結(jié)合回歸測試(Regressivetesting) 一起進(jìn)行。? 黑盒測試(功能測試) - 測試人員黑盒測試，英文是BlackBoxTesting 。又稱功能測試或者數(shù)據(jù)驅(qū)動測試。黑盒測試是根據(jù)軟

8、件的規(guī)格對軟件進(jìn)行的測試，這類測試不考慮軟件內(nèi)部的運作原理，因此軟件對用戶來說就像一個黑盒子。在完全不考慮程序內(nèi)部結(jié)構(gòu)和特性的情況下， 測試軟件的外部特性。 根據(jù)軟件的需求規(guī)格說明書設(shè)計測試用例， 從程序輸入和輸出特性上檢查程序是否滿足設(shè)定的功能。 黑盒測試常采用的方法是設(shè)計適量有效和無效的輸入數(shù)據(jù)進(jìn)行測試， 以期用最小的代價發(fā)現(xiàn)最多的錯 誤。軟件測試人員以用戶的角度， 通過各種輸入和觀察軟件的各種輸出結(jié)果來發(fā)現(xiàn)軟件存在 的缺陷，而不關(guān)心程序具體如何實現(xiàn)的一種軟件測試方法。個人復(fù)查個人復(fù)查是指程序員自行設(shè)計 測試用例，對源代碼、詳細(xì)設(shè)計進(jìn)行仔細(xì)檢查， 并記錄錯 誤、不足之處等。個人復(fù)查主要包括

9、檢查變量的正確性、檢查標(biāo)號的正確性、檢查子程序、 宏、函數(shù)、常量檢查、標(biāo)準(zhǔn)檢查、風(fēng)格檢查、比較控制流、選擇、激活路徑、對照詳細(xì)說明 書，閱讀源代碼和補充文檔等方面的測試內(nèi)容。走查走查是指測試人員先閱讀相應(yīng)的文檔和源代碼，然后人工將測試數(shù)據(jù)輸入被測試程序， 并在紙上跟蹤監(jiān)視程序的執(zhí)行情況，人工沿著程序的邏輯走查運行一遍，跟蹤走查運行的進(jìn)程來發(fā)現(xiàn)程序的錯誤。 走查的具體測試內(nèi)容包括模塊特性、模塊接口、模塊的對外輸入或輸出、局部數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)計算錯誤、控制流錯誤、處理出錯和邊界測試等方面。會審會審是指測試人員在會審前仔細(xì)閱讀軟件的有關(guān)資料，根據(jù)錯誤類型清單（根據(jù)以往的經(jīng)驗、對源程序的估計等，并在以后

10、測試中給以豐富補充）填寫檢測表，提出根據(jù)錯誤類型 要提出的問題。會審時，由程序設(shè)計人員講解程序的設(shè)計方法，由程序編寫人員逐個講解程序代碼的編寫，測試人員需要逐個審查，提問，討論可能出現(xiàn)的問題。會審對程序的功能、 結(jié)構(gòu)、邏輯和風(fēng)格都要進(jìn)行審定。會審的測試內(nèi)容與上查”的內(nèi)容相同。白盒測試白盒也稱結(jié)構(gòu)測試， 這是將軟件看成一個透明的白盒子，按照程序的內(nèi)部結(jié)構(gòu)和處理邏輯來選定測試用例，對軟件的邏輯路徑及過程進(jìn)行測試，檢查它與設(shè)計是否相符。性能測試性能測試，英文是 PerformanceTesting 。性能測試是在交替進(jìn)行負(fù)荷和強迫測試時常用的術(shù)語。理想的“性能測試”（和其他類型的測試）應(yīng)在需求文檔或

11、質(zhì)量保證、測試計劃中定義。性能測試一般包括負(fù)載測試和壓力 測試。通常驗證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復(fù)使用是否還能滿足性能指標(biāo)?；蛘邎?zhí)行同樣任務(wù)時新版本不比舊版本慢。一般還檢查系統(tǒng)記憶容量在運行程序時會不會流失（memoryleak）。比如，驗證程序保存一個巨大的文件新版本不比舊版本慢。5.1.2 測試規(guī)范測試規(guī)范是根據(jù)開發(fā)規(guī)范而制定的測試標(biāo)準(zhǔn)， 測試規(guī)范也是后期測試用例編寫的重 要依據(jù)。因為開發(fā)規(guī)范因公司而異， 因產(chǎn)品而異，所以測試規(guī)范的標(biāo)準(zhǔn)程度每個公司都不一 樣。從理論到方法到各類流程到各類報告模版，都屬于測試規(guī)范的范疇，當(dāng)一整套規(guī)范形成之后，可使得測試工作進(jìn)行更加穩(wěn)健，所有問題有據(jù)

12、可查。5.2 軟件需求規(guī)格說明書軟件需求規(guī)格說明書是軟件達(dá)到的各項功能的目標(biāo)。是測試人員各項工作的依據(jù)，沒有需求就無法判斷測試結(jié)果是正確的。5.3 軟件設(shè)計說明（概要與詳細(xì)設(shè)計）設(shè)計說明書包含軟件的一些框架、 字段、 數(shù)據(jù)庫設(shè)計等。 軟件設(shè)計說明對測試工作開展有很大影響， 沒有軟件設(shè)計說明很多問題將無法溯源， 測試準(zhǔn)備的前期工作也是根據(jù)軟件設(shè)計說明來制定的。5.4 頁面原型（ demo）頁面原型是項目人員快速熟悉項目的最佳路徑。 在需求不夠明確， 設(shè)計說明書不夠全面的情況下，頁面原型也是后期測試用例編寫思想的重要根據(jù)。6.測試過程設(shè)計明確測試目的，最終達(dá)成目的并驗證結(jié)果是測試要做的事情。包括：

13、1. 測試范圍：描述本次測試中的測試范圍，如：測試軟件功能范圍、測試種類等。2. 簡單的描述如何搭建測試平臺以及測試的潛在的風(fēng)險。3. 項目信息：說明要測試的項目的相關(guān)資料，如：輸入輸出文檔，產(chǎn)品描述，軟件主要功能。4. 人力資源的分配。5. 測試需求：籠統(tǒng)說，就是測試中的所有設(shè)計和需求文檔。作為本次測試的依據(jù)6.1 測試策略制定這一階段在于需求、詳細(xì)設(shè)計、測試計劃完成之后，主要是本次測試的策略階段。很多公司缺少這個階段， 需要有計劃性的分出產(chǎn)品的功能扣出測試的功能點， 現(xiàn)階段大多公司都是直接拿著文檔就開始做用例設(shè)計。對需求進(jìn)行分析，列出具體的功能列表。 （一般根據(jù)功能交互文檔就能明確出此功能

14、的大體功能， 一層層的分下去， 一直到每個功能表單。 然后考慮到使用哪些測試方法？工作一旦做到執(zhí)行階段，我們可以更好的根據(jù)這些功能表一點一點的覆蓋。也能讓我們在用例評審時， 充分的證實我們的工作是有效的能夠保證產(chǎn)品的質(zhì)量。 ）一般在此之前， 一些業(yè)務(wù)培訓(xùn)和需求評審是有必要是聽一下的。 這樣能夠更早更熟練的理解需求，也能保證產(chǎn)品設(shè)計中出現(xiàn)的一些誤區(qū)。對于一個個測試該如何進(jìn)行測試？如下：a） 功能測試?功能范圍（劃分出各自負(fù)責(zé)的功能模塊）?使用測試方法（等價類、邊界值等測試方法）?測試標(biāo)準(zhǔn)（符合設(shè)計、需求和規(guī)范文檔對該功能的描述）b） 界面測試c） 兼容性測試d） 性能測試6.2 測試計劃1） 要

15、充分考慮測試計劃的實用性， 即測試計劃與實際之間的接近程度和可操作性。 編寫測試計劃的目的在于充分考慮執(zhí)行測試時的各種資源， 包括測試內(nèi)容、 測試標(biāo)準(zhǔn)、時間資源、 人力資源等等， 準(zhǔn)確地說是要分析執(zhí)行時所能夠調(diào)用的一切資源以及受各種條件限制，可能受到的各種影響。a） 測試內(nèi)容：對一個軟件來說測試計劃中會明確本次測試做哪些測試？如：系統(tǒng)測試：在整個系統(tǒng)測試中會有（界面測試、功能測試、性能測試、兼容性測試、安裝卸載測試、可靠性測試等測試）。b）測試目的：一般多為保證產(chǎn)品質(zhì)量是否達(dá)到預(yù)期的指標(biāo)。這個指標(biāo)也就是在測試中定義的結(jié)束標(biāo)準(zhǔn)。c）測試標(biāo)準(zhǔn)：需要考慮本次測試需要輸入那些文檔，該項目結(jié)束標(biāo)準(zhǔn)定義、

16、測試結(jié)束標(biāo)準(zhǔn)的定義？ bug級別定義、優(yōu)先級定義、bug管理流程定義。這個都需要在執(zhí)行測試時明確。計劃中應(yīng)該包含這些內(nèi)容。d）資源分配：這里分為人力資源、軟硬件資源等劃分。一般會把人力資源的利用 寫入一個測試人員任務(wù)分配表里，按照不同的階段，每個階段提交相應(yīng)的成果（難度很大）。軟硬件資源中主要是在做計劃時考慮到需要多少電腦或別的工 具，列出清單。e）測試風(fēng)險：大多考慮到的就是項目開發(fā)延期、測試人員不足用例無法全面覆蓋測試點、時間不足用例無法全部執(zhí)行、bug無法及時修改導(dǎo)致無法驗證、測試人員技能不足導(dǎo)致測試進(jìn)度拉長。f） 軟件測試策略一般都是分開來做相關(guān)測試方案。6.3測試附件用例模板、缺陷報告

17、模板測試環(huán)境的搭建缺陷管理流程和缺陷級別定義缺陷狀態(tài)一般分為：新建、打開、已分配、已修復(fù)、關(guān)閉、重新打開中間會有：延期、重復(fù)、拒絕等狀態(tài)缺陷管理流程：1 .測試人員或開發(fā)人員發(fā)現(xiàn)bug后，判斷輸入哪個模塊的問題，填寫bug報告后，系統(tǒng)會自動通過 Email通知開發(fā)組長和該模塊開發(fā)者。2 .開發(fā)組長根據(jù)具體情況，重新reassigned分配給bug所屬的開發(fā)者。3 .開發(fā)者收到email信息后，判斷是否為自己的修改范圍。若不是，重新reassigned分配給開發(fā)組長或應(yīng)該分配的開發(fā)者。若是，進(jìn)行處理，resoked并給出解決方法。（可創(chuàng)建補丁附件及補充說明）4 .測試人員查詢開發(fā)者已修改的bug

18、,進(jìn)行回歸測試。經(jīng)驗證無誤后，修改狀態(tài)為verified o待整個產(chǎn)品發(fā)布后，修改為 closed。還有問題，reopened ,狀態(tài)重新變?yōu)?quot;new”,并發(fā)送郵件通知。5 .如果這個bug一周內(nèi)一直沒被處理過。Bugzilla就會一直用email騷擾它的屬主，直接采取行動。管理員可以設(shè)定最遲采取行動的期限，比如3天，系統(tǒng)默認(rèn)7天。缺陷等級劃分：分級Bug等級Bug等級說明分類說明致命問題Blocker導(dǎo)致整個產(chǎn)品無法進(jìn)行 測試。修改優(yōu)先級為最 高，該級別需要程序員 立即修改O塊無法啟動或異常退出C其它導(dǎo)致無法測試的錯誤Critical死機，數(shù)據(jù)丟失，主要 功能完全喪失，系統(tǒng)懸 掛等

19、錯誤。修改優(yōu)先級Qi行過程中系統(tǒng)崩潰/死機/重啟O能設(shè)計與需求嚴(yán)重不符（:嚴(yán)重花屏為最高，該級別需要程 序員立即修改E存泄漏C影響手機語音或數(shù)據(jù)通訊等C嚴(yán)重的數(shù)值計算錯誤嚴(yán)重問題Major主要功能喪失，導(dǎo)致嚴(yán) 重的問題，或致命的錯 誤聲明。修改優(yōu)先級為 高，該級別需要程序員 盡快修改O能未實現(xiàn)或者存在錯誤C輕微的數(shù)值計算錯誤C系統(tǒng)所提供的功能或服務(wù)受明顯的影響C用戶數(shù)據(jù)丟失或破壞一般問題Normal次要功能喪失，不太嚴(yán) 重，如提示信息不太準(zhǔn) 確。修改優(yōu)先級為中， 該級別需要程序員修改C操作界面錯誤（包括數(shù)據(jù)窗口內(nèi)列名定義、 含義是否一致）O界條件下錯誤O能存在錯誤，但出現(xiàn)概率很低C提示信息錯誤

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