測試流程怎麼寫

測試是什麼？測試流程是怎樣的？1、按是否檢視程式內部結構分為：（1）黑盒測試（black-box testing）：只關心輸入和輸出的結果 （2）白盒測試（white-box testing）：去研究裡面的原始碼和程式結構 此外，還有灰盒測試：介於黑、白盒測試之間的，關注輸出對於輸入的正確性，同時也關注內部表現2、按是否執行程式分為：（1）靜態測試（static testing）：是指不實際執行被測軟體，而只是靜態地檢查程式程式碼、介面或文件可能存在的錯誤的過程。

靜態測試包括：對於程式碼測試，主要是測試程式碼是否符合相應的標準和規範。對於介面測試，主要測試軟體的實際介面與需求中的說明是否相符。

對於文件測試，主要測試使用者手冊和需求說明是否真正符合使用者的實際需求。（5）動態測試（dynamic testing），是指實際執行被測程式，輸入相應的測試資料，檢查輸出結果和預期結果是否相符的過程3、按階段劃分：（1）單元測試（unit testing），是指對軟體中的最小可測試單元進行檢查和驗證。

樁模組（stud）是指模擬被測模組所呼叫的模組，驅動模組（driver）是指模擬被測模組的上級模組，驅動模組用來接收測試資料，啟動被測模組並輸出結果。（2）整合測試（integration testing），是單元測試的下一階段，是指將通過測試的單元模組組裝成系統或子系統，再進行測試，重點測試不同模組的介面部門。

整合測試就是用來檢查各個單元模組結合到一起能否協同配合，正常執行。（3）系統測試（system testing），指的是將整個軟體系統看做一個整體進行測試，包括對功能、效能，以及軟體所執行的軟硬體環境進行測試。

系統測試的主要依據是《系統需求規格說明書》文件。（4）驗收測試（acceptance testing），指的是在系統測試的後期，以使用者測試為主，或有測試人員等質量保障人員共同參與的測試，它也是軟體正式交給使用者使用的最後一道工序。

驗收測試又分為a測試和beta測試，其中a測試指的是由使用者、測試人員、開發人員等共同參與的內部測試，而beta測試指的是內測後的公測，即完全交給終端使用者測試。4、黑盒測試分為功能測試和效能測試：1）功能測試（function testing），是黑盒測試的一方面，它檢查實際軟體的功能是否符合使用者的需求。

包括邏輯功能測試（logic function testing） 介面測試（UI testing）UI=User Interface 易用性測試（usability testing）：是指從軟體使用的合理性和方便性等角度對軟體系統進行檢查，來發現軟體中不方便使用者使用的地方。相容性測試（compatibility testing）：包括硬體相容性測試和軟體相容性測試2）效能測試（performance testing） 軟體的效能主要有時間效能和空間效能兩種 時間效能：主要指軟體的一個具體事務的響應時間（respond time）。

空間效能：主要指軟體執行時所消耗的系統資源。軟體效能測試分為：一般效能測試：指的是讓被測系統在正常的軟硬體環境下執行，不向其施加任何壓力的效能測試。

穩定性測試也叫可靠性測試（reliability testing）：是指連續執行被測系統檢查系統執行時的穩定程度。負載測試（load testing）：是指讓被測系統在其能忍受的壓力的極限範圍之內連續執行，來測試系統的穩定性。

壓力測試（stress testing）：是指持續不斷的給被測系統增加壓力，直到將被測系統壓垮為止，用來測試系統所能承受的最大壓力。（Validate the system or software can allowed the biggest stress.）5、其他測試型別：迴歸測試（regression testing）是指對軟體的新的版本測試時，重複執行上一個版本測試時的用例。

（When a new build or release is deployed, repeat all the test cases which has executed in the last build or release.） 冒煙測試（smoke testing），是指在對一個新版本進行大規模的測試之前，先驗證一下軟體的基本功能是否實現，是否具備可測性。（validate the major function is deployed or not in software of system when a new build or release is implement.） 隨機測試（random testing），是指測試中所有的輸入資料都是隨機生成的，其目的是模擬使用者的真實操作，並發現一些邊緣性的錯誤。

（means or all the test data is random, to validate the some edge bugs.） 測試流程1.通用的測試流程：需求——》開發——》自測（開發）——》產品/設計驗收——》提測——》測試——》上線2.流程要持續優化，不斷改進，滿足工作需要（如產品通過發郵件通知，如開發程式碼的review，如單元測試的推進）一切都為了產品的質量。3.持續整合，結果及時反饋。

原發布者：hahehahe90

測試方案目錄1概述32測試資源和環境32.1硬體配置32.2軟體配置32.3測試資料33測試策略33.1.1功能測試33.1.2使用者介面（UI）測試43.1.3效能測試43.1.4安全性測試53.1.5相容性測試53.1.6迴歸測試53.2測試實施階段64測試通過標準65測試需求及測試用例追溯表66測試用例模板77測試進度7概述軟體的錯誤是不可避免的，所以必須經過嚴格的測試。通過對本軟體的測試，儘可能的發現軟體中的錯誤，藉以減少系統內部各模組的邏輯，功能上的缺陷和錯誤，保證每個單元能正確地實現其預期的功能。檢測和排除子系統（或系統）結構或相應程式結構上的錯誤，使所有的系統單元配合合適，整體的效能和功能完整。並且使組裝好的軟體的功能與使用者要求一致。測試資源和環境硬體配置軟體配置測試資料本方案的測試資料來源於測試需求及測試用例。測試策略系統測試型別及各種測試型別所採用的方法、工具等介紹如下：功能測試使用者介面（UI）測試效能測試安全性測試相容性測試迴歸測試測試實施階段測試通過標準系統無業務邏輯錯誤和二級的BUG。經確定的所有缺陷都已得到了商定的解決結果。所設計的測試用例已全部重新執行，已知的所有缺陷都已按照商定的方式進行了處理，而且沒有發現新的缺陷。注：缺陷的嚴重等級說明：A：嚴重影響系統執行的錯誤；B：功能方面一般缺陷，影響

原發布者：快樂的依一

硬體測試一、測試基本內容測試執行包括：整機、功能、效能、指標、可靠性測試測試分為3輪：第一輪，進行所有的測試；第二輪，開發修改問題後，迴歸測試；第三輪，開發修改後仍然有問題，再次修改後迴歸測試；硬體測試的目的主要是保障硬體的可靠性，以及硬體和硬體的聯接關係的正確性與準確性。硬體測試除了要對嵌入式的程式進行測試之外，還需要對原理圖、結構圖、元件選擇等等很多硬體研發過程中涉及的方面進行驗證測試，保證每個環節的正確性。同時，還需要對每個環節的銜接進行反覆驗證硬體測試的內容：1、測試設計（1）設計專業測試平臺（2）設計測試夾具（3）設計測試軟體（4）設計測試裝置（5）設計測試用例，測試方法2、白盒測試主要包括訊號測試，時序測試，電源測試等。3、功能測試測試產品的所有介面或者模組的功能4、效能測試主要包括穩定性、可靠性和相容性測試5、容錯測試容錯測試的主要目的是要檢驗系統對異常情況是否有足夠的保護，是否會由於某些異常條件造成故障不能自動恢復的嚴重後果。容錯測試的一般方法就是採用故障插入的方式，模擬一些在生產使用過程中可能會產生的故障因素，進而考察產品的可靠性及故障適應能力的一種測試方法。6、長時間驗證測試將產品置於一個相對惡劣的環境中，讓其儘可能大負荷的執行，檢驗其長時間執行的能力。測試問題解決：1、測試問題的危害解決站在使用者的角度看待測試問題，小問題也是問題（1）產品的最終使

首先是專案立項

然後測試和開發各自分析專案設計規格

階段一、測試先測試方案，開發寫需求

互相評審

階段二、測試寫測試用例，開發編碼

各自評審

階段三、測試人員開始SDV測試並提問題單，開發人員修改問題

幾輪SDV後

階段四、驗收測試人員驗收測試，開發人員修改問題單

幾輪驗收測試後

階段五、版本釋出

以上是華為專案標準流程，我們一直是這麼做的

1 簡介 1.1編寫目的 本測試報告為安天科技專案的測試報告，目的在於總結測試階段的測試以及分析測試結果，描述系統是否符合ATKJ-使用者需求說明書。

預期參考人員包括使用者、測試人員、開發人員、專案管理者、質量管理人員和需要閱讀本報告的高層經理。TestAge 中國軟體測試時代！T/d5sPAl 1.2專案背景 本產品是為天安科技有限公司開發的外貿企業管理系統。

本產品依據EasyTrade基礎模型研發，形成一個完善的以業務管理系統為核心，以基礎資訊、系統維護支援的外貿企業管理系統。主要功能是對該公司生產銷售過程，財務過程實現資訊化管理。

1.3系統簡介 1.4術語和縮寫詞 無 1.5參考資料 1、安天科技專案需求與設計、2、安天科技專案測試計劃、3、安天科技專案測試用例、4、安天科技專案缺陷報告單、系統測試報告 5、公司CMMI體系檔案《TS002_測試報告》 2 測試概要 2.1測試用例設計 本次測試用例設計主要採用黑盒測試方法，功能模組及整合測試採用的具體方法有等價類劃分、邊界值劃分、正交分解、因果圖分析和錯誤猜測。在系統測試時依據業務流程採用迴歸測試。

2.2測試環境與配置 測試伺服器配置： 伺服器地址：10.0.0.39 作業系統：Windows XP Professional SP2 CPU: Intel(R) Pentium(R)4 CPU 3.00HZ 硬碟可用空間：74GB 資料庫：Microsoft SQL Server 8.00.2039 應用伺服器：EasyTrade伺服器 測試物件：EasyTradeS3.exe 缺陷工具：Mercury Interactive TD8.0 SP2 2.3測試方法（和工具） 主要是黑盒測試，測試的重點集中在業務流程、資料提取和各功能模組間的介面。其中單元測試由開發人員直接完成；功能模組採用黑盒測試的常用方法；整合測試模組採用非漸增式測試，偏重系統的介面和資料提取方面；系統測試主要體現在業務流程的測試，主要採用迴歸測試 3 測試結果及缺陷分析 3.1測試執行情況與記錄 3.1.1測試組織 3j5Ylc i2r/{8TestAge 中國軟體測試時代 `4Nri0N,_$T9X測試經理：劉義照TestAge 中國軟體測試時代m!iL)S"_I­S 主要測試人員：李志學 TestAge 中國軟體測試時代（tWA ]3lh$t#K陳龍 參與測試人員：張士紅（模組測試用例編寫） 3.1.2測試時間 測試型別 實際開始時間 實際結束時間 總工作日 功能測試 貿易管理 2008-04-14 2008-04-15 2 生產管理 2008-04-14 2008-04-15 2 採購管理 2008-04-14 2008-04-16 3 財務管理 2008-04-15 2008-04-16 2 發運單 2008-04-15 2008-04-16 2 整合測試 2008-04-16 2008-04-18 2 系統測試 2008-04-18 2008-04-24 6 安裝測試 2008-04-25 2008-04-25 1 3.1.3測試版本 版本號 修訂日期 修訂人 修訂內容說明 EASYTRADE 2008.04.16 劉義照 EASYTRADE3 2008.04.26 劉義照 3.2覆蓋分析 3.2.1需求覆蓋 功能模組 功能名稱 編號 是否通過 備註 基礎資料 （JC） 國家程式碼 JC01 Y 世界港口 JC02 Y 貨幣設定 JC03 Y 計量單位 JC04 Y 退稅率設定 JC05 Y 附件類別 JC06 Y 材料類別 JC07 Y 單據編號 JC08 Y 工藝說明 JC09 Y 線說明 JC10 Y 銀行利息設定 JC11 Y 貿易管理 （MY） 客戶資料 MY01 Y 款式工藝 MY02 Y ▲ 客戶訂單 MY03 Y ▲ 訂單款式工藝 MY04 Y ▲ 大貨跟蹤表 MY06 Y ▲ 通訊錄 MY05 Y 排產管理 （PC） 服裝工廠資料 PC01 Y 訂貨合同 PC02 Y ▲ 生產工藝資料 PC03 Y ▲ 大貨生產狀態確認 PC04 Y 採購管理 （CG） 供應商資料 CG01 Y 訂購單 CG02 Y ▲ 發貨單 CG03 Y ▲ 退貨單 CG04 Y ▲ 產品清單彙總 CG05 Y 單證管理 （DZ） 發運單 DZ01 Y ▲ 成本核算單 DZ02 Y ▲ 財務管理 （CW） 服裝工廠往來帳目 CW01 Y 服裝廠配料擔保賬目 CW02 Y 服裝工廠結算單 CW03 Y ▲ 供應商擔保賬目 CW04 Y 注：TestAge 中國軟體測試時代­r*fm:Z1W3~?[Y][P][N][N/A]四項值依據TestAge 中國軟體測試時代測試結果，按編號給出每一測試需求的通過與否結論。

P表示部分通過，N/A表示不可測試或者用例不適用。▲表示為測試重點部分。

D­dduS­a6} ihV WW8需求覆蓋率=Y項數/需求項數 *100%=33/33*100%=100% 3.2.2測試覆蓋 模組 用例個數 執行數 未執行數 未執行/漏測原因 貿易管理 28 28 生產管理 38 38 採購管理 39 39 單證管理 17 17 財務管理 11 11 合計 133 133 .o Knz)u5 ~5_zD }mI-N9c8測試覆蓋率=執行總數/用例總數 *100%=133/133*100%=100% 3.3缺陷的統計與分析 3.3.1缺陷彙總 缺陷總數：105 按缺陷嚴重程度：1-Low: 16個 所佔百分比：15.238% 2-Medium: 77個 所佔百分比：73.342% 3-High: 12個 所佔百分比：11.420%。

需求分析需求分析（Requirment Analyzing）應該說是軟體測試的一個重要環節，測試開發人員對這一環節的理解程度如何將直接影響到接下來有關測試工作的開展。

可能有些人認為測試需求分析無關緊要，這種想法是很不對的。需求分析不但重要，而且至關重要。

一般而言，需求分析包括軟體功能需求分析、測試環境需求分析、測試資源需求分析等。其中最基本的是軟體功能需求分析，測一款軟體首先要知道軟體能實現哪些功能以及是怎樣實現的。

比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我們就應該知道軟體是怎樣來實現這些功能的，為了實現這些功能需要哪些測試裝置以及如何搭建相應測試環境等，否則測試就無從談起！既然談了需求分析，那麼我們根據什麼來分析呢？總不能憑空設想吧。

總得說來，做測試需求分析的依據有軟體需求文件、軟體規格書以及開發人員的設計文件等，相信管理一些規範的公司在軟體開發過程中都有這些文件。測試計劃測試計劃（Test Plan）一般由測試負責人來編寫。

測試計劃的依據主要是專案開發計劃和測試需求分析結果而制定。測試計劃一般包括以下一些方面：1. 測試背景a. 軟體專案介紹；b. 專案涉及人員（如軟硬體專案負責人等）介紹以及相應聯絡方式等。

2. 測試依據a. 軟體需求文件；b. 軟體規格書；c. 軟體設計文件；d. 其他，如參考產品等。3. 測試資源a. 測試裝置需求；b. 測試人員需求；c. 測試環境需求；d. 其他。

4. 測試策略a. 採取測試方法；b. 搭建哪些測試環境；c. 採取哪些測試工具以測試管理工具；d. 對測試人員進行培訓等。5. 測試日程a. 測試需求分析；b. 測試用例編寫；c. 測試實施，根據專案計劃，測試分成哪些測試階段（如單元測試、整合測試、系統測試階段，α、β測試階段等），每個階段的工作重點以及投入資源等。

6. 其他。測試計劃還要包括測試計劃編寫的日期、作者等資訊，計劃越詳細越好了。

計劃趕不上變化，一份計劃做的再好，當實際實施的時候就會發現往往很難按照原有計劃開展。如在軟體開發過程中資源匱乏、人員流動等都會對測試造成一定的影響。

所以，這些就要求測試負責人能夠從巨集觀上來調控了。在變化面前能夠做到應對自如、處亂不驚那是最好不過了。

測試設計測試設計主要包括測試用例編寫和測試場景設計兩方面。一份好的測試用例對測試有很好的指導作用，能夠發現很多軟體問題。

關於測試用例編寫，請參見前面寫的《也談測試用例》一文，裡面有詳細闡述。測試場景設計主要也就是測試環境問題了。

測試環境搭建不同軟體產品對測試環境有著不同的要求。如C/S及B/S架構相關的軟體產品，那麼對不同作業系統，如Windows系列、unix、linux甚至蘋果OS等，這些測試環境都是必須的。

而對於一些嵌入式軟體，如手機軟體，如果我們想測試一下有關功能模組的耗電情況，手機待機時間等，那麼我們可能就需要搭建相應的電流測試環境了。當然測試中對於如手機網路等環境都有所要求。

測試環境很重要，符合要求的測試環境能夠幫助我們準確的測出軟體問題，並且做出正確的斷。為了測試一款軟體，我們可能根據不同的需求點要使用很多不同的測試環境。

有些測試環境我們是可以搭建的，有些環境我們無法搭建或者搭建成本很高。不管如何，我們的目標是測試軟體問題，保證軟體質量。

測試環境問題，還是根據具體產品以及開發者的實際情況而採取最經濟的方式吧。測試執行測試執行過程又可以分為以下階段：單元測試→整合測試→系統測試→出廠測試，其中每個階段還有迴歸測試等。

從測試的角度而言，測試執行包括一個量和度的問題。也就是測試範圍和測試程度的問題。

比如一個版本需要測試哪些方面？每個方面要測試到什麼程度？從管理的角度而言，在有限的時間內，在人員有限甚至短缺的情況下，要考慮如何分工，如何合理地利用資源來開展測試。當然還要考慮以下問題：1. 當測試人員測試的執行不到位、敷衍了事時該如何解決？2. 測試效率問題，怎樣提高測試效率？3. 根據版本的不同特點是隻做驗證測試還是採取冒煙測試亦或是系統全面測試？4. 當測試過程中遇到一些偶然性隨機問題該怎樣處理？5. 當版本中出現很多新問題時該怎樣對待？測試停止標準？。

1.1 軟體測試過程概述

軟體測試過程是一種抽象的模型，用於定義軟體測試的流程和方法。眾所周知，開發過程的質量決定了軟體的質量，同樣的，測試過程的質量將直接影響測試結果的準確性和有效性。軟體測試過程和軟體開發過程一樣，都遵循軟體工程原理，遵循管理學原理。

隨著測試過程管理的發展，軟體測試專家通過實踐總結出了很多很好的測試過程模型。這些模型將測試活動進行了抽象，並與開發活動有機的進行了結合，是測試過程管理的重要參考依據。

1.2 軟體測試過程模型介紹

V模型

V模型最早是由Paul Rook在20世紀80年代後期提出的，旨在改進軟體開發的效率和效果。V模型反映出了測試活動與分析設計活動的關係。在圖1-1中，從左到右描述了基本的開發過程和測試行為，非常明確的標註了測試過程中存在的不同型別的測試，並且清楚的描述了這些測試階段和開發過程期間各階段的對應關係。

圖1-1 軟體測試V模型

V模型指出，單元和整合測試應檢測程式的執行是否滿足軟體設計的要求；系統測試應檢測系統功能、效能的質量特性是否達到系統要求的指標；驗收測試確定軟體的實現是否滿足使用者需要或合同的要求。

但V模型存在一定的侷限性，它僅僅把測試作為在編碼之後的一個階段，是針對程式進行的尋找錯誤的活動，而忽視了測試活動對需求分析、系統設計等活動的驗證和確認的功能。

W模型

W模型由Evolutif公司公司提出，相對於V模型，W模型增加了軟體各開發階段中應同步進行的驗證和確認活動。如圖1-2所示，W模型由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的並行關係。

W模型強調：測試伴隨著整個軟體開發週期，而且測試的物件不僅僅是程式，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。W模型有利於儘早地全面的發現問題。例如，需求分析完成後，測試人員就應該參與到對需求的驗證和確認活動中，以儘早地找出缺陷所在。同時，對需求的測試也有利於及時瞭解專案難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快專案進度。

但W模型也存在侷限性。在W模型中，需求、設計、編碼等活動被視為序列的，同時，測試和開發活動也保持著一種線性的前後關係，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支援迭代的開發模型。對於當前軟體開發複雜多變的情況，W模型並不能解除測試管理面臨著困惑。

圖1-2 軟體測試W模型