軟體測試歷史：

上世紀三四十年代，含義狹隘，開發自測，產品質量低；

上世紀八九十年代，開始成型，但沒有廣泛的應用；

二十一世紀初，迅猛發展，對軟體質量要求越來越高，軟體系統化測試登上舞臺。

 

軟體測試的目的：

提高軟體質量，降低成本；

 

軟體測試的概念：

在規定時間、條件下對程式進行操作，以發現錯誤為目的，對軟體質量進行評估的過程。

 

缺陷（Bug）

1947年09月，第一個Bug被發現。中繼器故障（飛蛾引起）

 

軟體缺陷的定義：

不符合使用者要求，或軟體在開發或者維護過程中存在的錯誤、毛病以及各種問題；

(軟體缺陷，英文名詞bug，是計算機軟體或程式中存在的某種破壞正常執行能力的問題、

錯誤、或者隱藏的功能缺陷。缺陷的存在會導致軟體產品在某種程度上不能滿足使用者的需求；)

 

為什麼會出現軟體缺陷：

1、 需求不明確（最常見）

2、 系統結構非常複雜

3、 開發人員疏忽，程式碼寫錯

4、 其他。

 

缺陷等級：

致命

嚴重

一般

輕微

 

 

缺陷修復成本：

幾何級數增長(成倍增長）隨著專案的深入，缺陷越後被發現，修復成本就越高！

 

Page10  軟體測試的原則：

1-7

不可能進行完全測試

軟體測試是有風險的行為

測試無法顯示潛伏的軟體缺陷

充分注意軟體缺陷的群集現象（程式設計師的疏忽）

要避免軟體測試的殺蟲劑現象

並非所有的軟體缺陷都能修復

 

即將上線的軟體突然發現Bug，，可根據自身經驗評估，如果缺陷風險不大、但修復成本較高，可以等軟體升級的時候再修復。

 

軟體測試模型：

V模型：（最常用）  需求分析（需求：（外包：使用者需求；自研：來自市場調研））、概要設計（前端研發的過程）、詳細設計（前端研發的過程），編碼實現，單元測試，整合測試，系統測試，驗收測試

W模型：（由2個V模型組成）page16

H模型

X模型

迭代式模型

敏捷式模型

等

 

 

軟體測試流程：

需求分析（評審）

測試計劃（測什麼）

測試用例（為了更有效地發現軟體缺陷，避免測試的盲目性，降低測試成本，提高測試效率）

執行用例

迴歸測試

測試報告

 

測試計劃包含哪些內容：

概述：（編寫目的、專案背景、專案質量目標（儘可能高）、預期結果（應與需求相符合）、參考資料）；

測試環境：LAMP=Linux+Apache+MySQL+PHP；

測試計劃：測試範圍，開發組成員及其職責等；

測試策略：測試方法；

工作彙報

 

評審即開會討論（測試組內部會議）

評審內容：評審時間、地點、主持人（專案經理、測試經理等）、參加部門人員、評審內容、評審過程、評審結果

 

測試用例八大要素：

  用例編號、用例標題、專案名稱、優先順序、預知條件、測試輸入、操作步驟、預期結果

用例編號：   產品編號_ST_專案名_001

其中 單元UT 整合 IT 系統 ST

用例標題：即用一句簡單的話描述用例的關注點

優先順序：高中低

確認優先等級的三項指標：

• 風險 ②開發部門的進度安排 ③使用者協議（使用者定義為高）

 

寫測試點：應從多個方面入手，包括功能、效能、安全性、可靠性等。

 

編寫測試用例的目的：

• 編寫用例可以避免測試點的遺漏；
• 編寫用例是為了更好地進行測試，提高測試效率
• 測試用例是根據需求來寫的，用例完成後要進行評審，還可以儘可能避免開發和測試對需求的不同理解造成的缺陷。

 

軟體的生命週期：

一個軟體產品或系統也要經歷孕育、誕生、成長、成熟、衰亡的階段，軟體的生命週期是軟體從產生到報廢停止使用的過程。

 

缺陷的生命週期：

測試人員發現bug，將其提交缺陷管理系統（禪道）並指派給對應的開發人員，開發人員進行確認，是bug就修復，不是bug就返回給測試人員，將修復好的bug也發回給測試人員，測試人員進行迴歸測試，已修復便關閉，未修復餓返回給開發。

 

軟體測試分類：

功能測試、效能測試、安全性測試、可靠性測試、驗收測試；

 

軟體測試方法分類：

黑盒測試、白盒測試、灰盒測試

 

功能測試：也叫黑盒測試，是把測試物件看作一個黑盒子，利用黑盒測試方法進行動態地測試需要測試的軟體產品的一個過程

 

黑盒測試：

• 等價類 ②邊界值 ③錯誤推測法 ④因果法 ⑤場景法 ⑥正交法

等價類：把所有可能的輸入資料（即程式）的輸入域劃分為若干部分（子集），然後從每個子集中選取少量具有代表性的資料作為測試用例（分為有效等價類和無效等價類兩種）

邊界值：是對等價類分析方法的一個補充，因此針對各種邊界情況設計測試用例可查出更多的錯誤（6-10個字元，6-10為內點，5和11為離點）

錯誤推測法：是指在測試程式時，人們根據直覺或經驗推測程式中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法。

。。。

 

 

白盒測試：測試人員知道了產品的功能以及內部結構，一般程式設計師開發完一種功能，測試員就立馬測試功能

 

白盒測試方法：

程式碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法等

 

灰盒測試：介於白盒測試和黑盒測試間的一種方法

目的：確保並提高軟體質量

 

單元測試：是指對軟體中最小可測試單元進行檢查和驗證，對於單元測試中的單元的含義，一般來說，需根據實際情況去判斷其定義，總的來說，單元就是認為規定的最小被測試的功能模組

 

C中，單元指的是一個函式

Java中，單元指的是一個物件

圖形化介面中，單元指的是一個視窗或選單

 

整合測試：

  也叫組裝測試，聯合測試，，即對程式模組採用一次性或增值方式組裝起來，對系統的介面進行正確性檢驗的測試工作，整合測試在單元測試的基礎上，將所有模組按照設計要求，組裝成為子系統或系統。

 

測試用例的特點：（用最少的用例覆蓋100%的需求）

內部評審（測試組）->同行評審（專案組所有參與人員）

 

系統測試：

    概念：是將已經確認的軟體或者計算機硬體、外設、網路等其他元素結合在一起，

          進行資訊系統的各種組裝、測試和確認測試。

      系統測試：包括（功能測試，效能測試，壓力測試，安全性測試，可靠性測試等）

                  功能測試（找Ｂｕｇ）（點點點，又稱黑盒測試佔大部分時間） 概念：即對產品的各種功能進行驗證，根據功能測試用例逐項測試，檢查產品是否達到使用者要求的功能，只需要考慮測試的各個功能，不需要考慮整個軟體的內部結構及程式碼，功能測試也叫黑盒測試或者資料驅動測試。

                        流程：需求分析-》測試計劃（評審）-》測試用例（，，，預測，專案組中每個成員都要寫）-》環境搭建（LAMP）-》冒煙測試（用3-5條優先順序高的用例去執行，看結果是否符合需求 ，3-5小時，，，正式測試）-》迴歸測試（第一輪：主要功能；第二輪：細節功能；第三輪：根據時間進度、Bug遺留、版本做測試報告）-》測試報告（整個專案組一份）

                        測試報告包含的內容：人員的配置（測試組成員）、測試模組（每個模組測試的開始時間、結束時間、寫了多少用例、通過多少用例、失敗的用例是多少）、Bug統計、遺留和風險、專案總結、評價該專案是否符合上線標準、日期，簽名，主管簽名；

                  效能測試 （測試軟體的“負載能力”）：概念：效能測試是通過自動測試工具模擬多種正常峰值，以及異常負載條件來對系統的各項效能指標進行測試。

                             工具：Loadrunner:是效能的負載測試工具，，主要功能：虛擬使用者，真實負載，定位效能，分析結果，重複測試

                             效能測試的目的：1.評估，評估系統是否滿足系統性能需求；2.調優，解決效能測試中發現的瓶頸和問題；３，穩定，驗證系統是否穩定可靠。

                     　　　效能測試的指標值：

                     １.事務（ｗｅｂ效能測試中，一個事務表示一個“使用者－ｗｅｂ　ｓｅｒｖｅｒ－ＤＢ－ｗｅｂ　ｓｅｒｖｅｒ－使用者”的過程），

                     ２.響應時間，（毫秒級別，，是從客戶端發起一個請求開始，到客戶端接收到從伺服器端返回的響應結束　這個過程所耗費的時間，以毫秒為單位）

                     ３.ＴＰＳ（每秒傳輸的事務個數，指伺服器在單位時間內（秒）可以處理的事務數量），

                     ４.吞吐量（指單位時間內可處理的客戶端請求數量），

                     ５.點選率（每秒傳送的ｈｔｔｐ請求的數量，點選率越高，對ｓｅｒｖｅｒ造成的壓力就越大），

                     ６.併發使用者數（指同時進行請求的使用者的數量，併發數用於模擬使用者的真實情況，，，特點：同一時刻＼對伺服器有負載），

                     ７.資源利用率

 

ｈｔｔｐ和ｈｔｔｐｓ的區別：

ｈｔｔｐｓ需要申請證書，一般免費證書很少，因而需要一定費用。

ｈｔｔｐ是超文字傳輸協議，資訊明文傳輸，，https則是具有安全性的加密傳輸協議。

http與https採用完全不同的連線方式，用的埠號也不一樣，前者為80，後者是443；

http連結是無狀態的，https構建的可進行加密傳輸、身份認證的網路協議，，比http安全；

https加密會影響一部分效能，如果沒有特定的需求，無需加密

 

                  安全性測試

                  可靠性測試

 

=====================================================================APP測試：

  1.功能：進行100%的測試

  2.安全解除安裝：能否正常安裝啟動，，記憶體已滿能否安裝，，有沒有自帶的解除安裝功能。

  3.流暢度：開啟是否會卡頓，同時開啟多個服務會不會卡死。

  4.相容性：安卓系統，IOS系統等

  5.網路（弱網測試）

  6.流量消耗：主要考慮斷開WiFi會不會偷跑流量

  7.低配手機

 

=====================================================================

wifi---------4G---------3G---------2G---------無網

 

           1.5M/s     500k/s     60k/s

 

夜神模擬器

 

----------------

（效能測試的一種）壓力測試：

 

  概念：也被稱為強度測試、負載測試，壓力測試模擬實際應用的軟硬體環境及使用者使用過程系統負荷，長時間或超大負荷地執行測試軟體，來測試被測系統的效能、可靠性、穩定性等。

 

目的：是在軟體投入使用以前或軟體負載達到極限以前通過執行可重複的負載測試，瞭解系統可靠性、穩定性，減少系統的宕機（電腦無法正常工作）時間的因此帶來的損失。在軟體工程中，壓力測試是對系統不斷施加壓力的測試，是通過確認一個系統的瓶頸或者不能接收的效能點，來獲得系統能提供的最大服務級別的測試。

 

 壓力測試的方法：

 1.敏感性測試：旨在測量單個重要風險因素或少數幾項關係密切的因素，由於假設變動對系統的影響。

 

 2.情景測試：即一組風險因子定義為某種情景，分析在個別情景下的損失，因而此類方法稱為情景分析；

 

 

可靠性測試：

  概念：也稱為可靠性評估，指根據產品可靠性結構、壽命型別和各單元的可靠性試驗資訊，利用概率統計方法，評估出產品的可靠性特徵量。

 

  目的：

   1.通過在有使用代表性的環境中執行軟體，以證實軟體需求是否實現。

   2.為進行可靠性評估採集準確的資料

   3.通過軟體可靠性測試找出所有對軟體可靠性影響較大的錯誤。

 

  特點：

  （1）軟體可靠性跟硬體可靠性不同，軟體可靠性失效一般是由設計缺陷造成的。軟體可靠性測試強調按實際使用的概率分佈隨機選擇輸入，並強調測試需求的覆蓋面。

  （2）軟體可靠性測試也不同於一般的軟體功能測試，軟體功能測試可能比較注重於找Bug，而軟體可靠性測試必須按照使用的概率分佈隨機地選擇測試用例，這樣才能得到比較準確的可靠性評估，也有利於找出對軟體可靠性影響較大的故障原因。

 

  效果：經過軟體可靠性測試的軟體，並不能保證殘留的錯誤數量少，但能保證該軟體的可靠性達到較高要求。

 

安全性測試：

 

  定義：安全性測試是在IT軟體產品的生命週期中，特別是產品基本開發完成到釋出階段，對產品進行檢驗，以驗證產品符合安全需求定義和產品質量標準的過程。

 

 目的：提升產品的安全質量，儘可能在釋出前找到安全問題予以修補、降低成本。

 

  區別：

1.目標不同：功能測試以發現Bug為目標，安全性測試以發現安全隱患為目標。

2.假設條件不同：一般功能測試：測試假設導致問題的資料是需求或研發不小心造成的；安全性測試假設導致的問題的資料是攻擊者處心積慮構造的，需要考慮所有可能的攻擊途徑。

3.問題發現模組不同：一般功能測試以違反功能定義為判斷依據，安全性測試以違反許可權與能力的約束為判斷依據。

 

 安全性測試包括：

使用者認證安全測試

系統網路安全測試

資料庫安全測試

 

…………………………………………………………………………………………

軟體開發生命週期中每一階段都應該包含軟體測試

在典型的軟體開發專案中，軟體測試工作量往往佔軟體開發總工作量的 40％以上。而

在軟體開發的總成本中，用在測試上的開銷要佔30％到 50％。

-----------------------

遇到問題無法解決：

   先獨立解決（百度等）再尋求幫助；

 

驗證測試：

  定義：也稱為使用者交付測試，是部署軟體之前的最後一個測試操作，它是技術測試的最後一個階段。

  目的：是確保軟體準備就緒並且可以讓終端使用者將其用於執行軟體的既定功能和任務。

  方法:Alpha(有開發人員，測試人員，使用者或第三方測試公司等組成)：阿爾法測試是在使用者組織模擬軟體系統的執行環境下的一種驗收測試，由使用者或第三方進行的測試。非正式驗收。。。

       Beta（測試組，使用者）：貝塔測試是使用者公司組織多個使用者在一個或多個使用者的實際使用環境下進行的測試。（常用）。正式驗收。。。

       兩者區別：

         Alpha測試是在模擬環境下進行的測試，Beta測試是在實際使用環境中進行的。

         Alpha測試有開發在現場，Beta測試開發不在。

  驗收測試三個過程：

       1.驗收測試進入準則：

         （1）軟體產品通過單元測試、整合測試和系統測試；

         （2）專案組提交（給使用者）測試計劃、測試用例、測試報告（一般在SVN中提交）

       2.對使用者手冊和幫助的測試規定：

         （1）使用者手冊和幫助的編制要使用非專門術語，充分地描述該軟體系統所具有的功能以及基本的使用方法。

         （2）使使用者能夠通過手冊瞭解該軟體的用途，並且能夠確定在什麼情況下、如何使用它。

         （3）語言通順簡潔、語義明確、錯別字小於0.1%

         （4）對相關名詞解釋應易於被使用者理解；

         （5）保證使用者手冊、幫助能夠正確指導使用者使用軟體。

       3.軟體驗收測試合格通過的準則：

         （1）軟體需求分析說明書中定義的所有功能已全部實現

         （2）所有測試項必須符合如下標準：

            致命錯誤：無  功能錯誤：無 功能缺陷：通過稽核 介面缺陷：通過稽核

         （3）需求分析文件、設計文件、和編碼實現一致（開發）；

         （4）使用者手冊及幫助符合驗收規定；

         （5）驗收測試（要寫測試計劃、策劃報告）文件齊全；

         （6）以上條件其中之一不能滿足要求，視為不合格。

 

電子商城需求分析文件（想出測試點，然後根據測試點寫測試用例）

 業務流程描述：

  1.使用者註冊：填寫個人資料，最後提交，註冊成功；

  2.使用者登入：按照註冊好的使用者名稱、密碼登入

  3.個人資料修改，使用者可以修改個人資料；

  4.選擇商品，選擇好商品後可以自由更改需求購買商品數量，確定後提交新增進購物車；

  5.購物車：購物車中可以選擇移除選好的商品，可以更改商品數量，可以確認購買，購買後可以繼續返回購買數量

  6.付款：付款方式，可查詢購買的商品物流情況

  7.購買商品交易成功後，對商品做出評價。