?

?

一：軟件測試的定義：根據(jù)用戶需求行業(yè)規(guī)范，采用一些測試方法或一些工具對被測系統(tǒng)（程序數(shù)據(jù)文檔）進(jìn)行相應(yīng)的測試（審核，運行，評估），盡早盡快的發(fā)現(xiàn)軟件問題，提升軟件的質(zhì)量。

?

二：軟件測試的生命周期：

第一階段：問題的定位與規(guī)劃階段? ??

第二階段：需求分析階段? ?

第三階段：軟件的設(shè)計階段（概要設(shè)計，詳細(xì)設(shè)計）

第四階段：軟件編碼階段? ?

第五極端：軟件測試階段? ?

第六階段：運行與維護(hù)階段?

?

三：軟件測試的需求? ?需求規(guī)格說明書（產(chǎn)平經(jīng)理編輯）：收集客戶的反饋，市場人員的調(diào)研，收集市場需求，和市場人員溝通，業(yè)內(nèi)需求（行業(yè)規(guī)范，功能需求）

? ? ? 為什么都要形成文檔：項目管理的需要

? ? ? 作用：描述客戶對于軟件的期望和要求

? ? ? 供大家評審：需求有沒有錯誤或不一致，需求是否可以測試，進(jìn)一步理解用戶的需求，為后續(xù)的測試作準(zhǔn)備第一階段：需求分析

? ? ??需求分析：

1：學(xué)習(xí)需求，充分理解需求? ?

2：找出需求中的問題（模糊不清，有歧義），如需求文檔已經(jīng)發(fā)布或測試已經(jīng)開始執(zhí)行提交文檔bug單的情況 （兩者瞞住一個就需要提文檔bug單）

3：準(zhǔn)確評估測試點和工作量（為寫用例奠定基礎(chǔ)）? ?

?

四：軟件測試的分類：

技術(shù)劃分? ?

-白盒測試；（針對單元測試）對內(nèi)部代碼邏輯進(jìn)行測試，關(guān)注輸出對于輸入的正確性? ?

-灰盒測試：（針對集成測試）基于白盒與黑盒之間? ?

-黑盒測試：（針對系統(tǒng)測試）依據(jù)需對求程序的多面處進(jìn)行測試通過軟件的外部表現(xiàn)來發(fā)現(xiàn)其缺陷。

? ? ? ? ? ? ? ? ? ?

狀態(tài)劃分? ?

1：動態(tài) - 手工，自動化，半自動化

2：靜態(tài) -文檔評審（雪球評審，設(shè)計評審，測試文檔（猜測是計劃，用例，報告），用戶手冊）

? ? ? ? ? ? ?-代碼走查：開發(fā)人員之間相互閱讀代碼檢查代碼是否符合編程規(guī)范? ?注：代碼走查發(fā)現(xiàn)的問題比單元測試的多

? ? ? ? ? ? ? ? ? ? ??

階段劃分? ?

1：單元測試：根據(jù)系統(tǒng)設(shè)計文檔，主要測試程序的源代碼和內(nèi)部邏輯，力度最小，一般是開發(fā)小組采用百合測試?

? ? ? ? ? ? ? ? ? ? 注：不關(guān)注代碼是否符合編程規(guī)范

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

?2：集成測試：依據(jù)系統(tǒng)設(shè)計文檔和需求文檔，屬于單元測試和（確認(rèn)測試）系統(tǒng)測試之間起到橋接的作用??

? ? ? ? ? ? ? ? ? ? 單元測試之后進(jìn)行，由開發(fā)小組運用灰盒測試技術(shù)進(jìn)行測試?

? ? ? ? ? ? ? ? ? ? 即驗證內(nèi)部代碼邏輯又關(guān)注需求實現(xiàn)（跑通基本功能不會像系統(tǒng)測試那樣驗證多種異常場景）

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

3：確認(rèn)測試：依據(jù)需求文檔，在集成測試后，通過集成測試之后，軟件已完全組裝起來，接口方面的錯誤也已排除，

? ? ? ? ? ? ? ? ? ? 確認(rèn)測試即可開始。? ?

? ? ? ? ? ? ? ? ? ? 確認(rèn)測試應(yīng)檢查軟件能否按合同要求進(jìn)行工作，即是否滿足軟件需求說明書中的確認(rèn)標(biāo)準(zhǔn)。

?

4：冒煙測試：進(jìn)行時間：新版本發(fā)布后? ?測試內(nèi)容：對軟件的基本功能點的流程測試確保通過冒煙（軟件能否跑起來）? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

5：系統(tǒng)測試：依據(jù)需求文檔，粒度最大，一般由獨立測試小組采用黑河測試驗證多種場景下功能是否符合課采用手工或自動化

? ? ? ? ?-包括：

? ? ? ? ? ? ? ? ?功能測試-對產(chǎn)品的功能進(jìn)行驗證，根據(jù)測試用例逐項進(jìn)行驗證? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ?性能測試- 測試軟件處理業(yè)務(wù)的速度（同時并發(fā)，同時在線）

? ? ? ? ? ? ? ? ?壓力測試-系統(tǒng)正常運行的極限狀態(tài)

? ? ? ? ? ? ? ? ?健壯性測試-異常情況下軟件正常運行的能力（包括容錯力和恢復(fù)力）

? ? ? ? ? ? ? ? ?可靠性測試-長時間的運行看軟件有沒有問題（如手機用長了會卡頓）? ?

? ? ? ? ? ? ? ? ?安全性測試-指軟件防止非法入侵的能力（屬于技術(shù)問題也屬于管理問題）

?

6：探索性測試：天馬行空的的設(shè)計和執(zhí)行測試用例，利用軟件程序所提供的信息只有發(fā)揮，沒有限制不受任何條件的約束的探索程序的各種功能? ? ??

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

7：alpha和beta測試：

? ? ? ? ? ? ? ? ? ?alpha：（內(nèi)測）在受控制環(huán)境下進(jìn)行的測試，技術(shù)人員會在現(xiàn)場

? ? ? ? ? ? ? ? ? ? beta：（公測）開發(fā)者通常不在測試現(xiàn)場,因而開發(fā)者無法 控制測試現(xiàn)場

? ? ? ? ? ? ? ? ? ? ? ?注：一般應(yīng)用于大型公用軟件，沒有具體用例，這兩種測試都是從實際終端用戶角度出發(fā)對軟件功能和性能進(jìn)行測試

?

8：回歸測試：1：bug修復(fù)后且在新的測試版本發(fā)布后需要進(jìn)行回歸測試

? ? ? ? ? ? ? ? ? ? 2：bug修復(fù)后的回歸測試在交付前需要進(jìn)行全量用例回歸的測試也叫（頂版測試）

? ? ? ? ? ? ? ? ? ? ? ? 確保BUG修改后有沒有引入新的bug導(dǎo)致其他部分有沒有產(chǎn)生錯誤

?

9：驗收測試：驗收測試與系統(tǒng)測試非常相似主要區(qū)別是驗收測試是由客戶或用戶執(zhí)行

?

五：測試工作的開展

測試啟動準(zhǔn)則：

1：需求已經(jīng)就緒，測試計劃制定并通過審核? ?

2：用例已經(jīng)設(shè)計完并通過審核?

3：測試的對象已經(jīng)開發(fā)完等待測試

4：測試環(huán)境已經(jīng)搭建，測試數(shù)據(jù)準(zhǔn)備好了

測試結(jié)束準(zhǔn)則:

1：產(chǎn)品通過驗收測試且用例覆蓋率，用例執(zhí)行率，用例通過率都達(dá)到相應(yīng)的指標(biāo)?

2；出現(xiàn)的問題得以修復(fù)且再次執(zhí)行用例沒有新的問題出現(xiàn)? ?

3：項目規(guī)劃時間到期，測試用例執(zhí)行完成（覆蓋率達(dá)到多少），bug出現(xiàn)收斂

?

基于測試用例的準(zhǔn)則

基于缺陷密度的準(zhǔn)則則

基于試運行期間缺陷密度

?

六：傳統(tǒng)測試流程

第一階段：需求分析

• 1：學(xué)習(xí)需求，充分理解需求（了解項目的整個實現(xiàn)背景，挖掘隱藏需求）
• 2：分析需求的合理性，找出需求中的問題（模糊不清，有歧義）
• • 1：功能描述不清晰的
  • 2：有歧義的
  • 3：文字表述錯誤的
  • 4：‘多’‘等’‘長時間’等模糊字眼
  • 5：需求重復(fù)的
  • 6：一些模棱兩可的描述
  • 7：前后功能沖圖
  • 8：潛在性需求可提出（為了產(chǎn)品質(zhì)量更好，如果是客戶定制的那么客戶更加滿意）
  • 9：異常操作需求可提出（是作為軟件系統(tǒng)基本的邏輯異常問題處理機智）
• 3：準(zhǔn)確評估測試點和工作量（為寫用例奠定基礎(chǔ)）
• 4：熟悉業(yè)務(wù)
• 5：羅列出個功能點
• 6：記錄評審的問題，便于跟蹤問題
• 7：對設(shè)計方案看能不給出比較好的建議

第二階段：制定測試計劃：

• why（什么）---什么項目 ??為什們進(jìn)行測試
• what（在那一反面）---測試那些方面（不同階段的測試內(nèi)容）
• when（什么時間）---測試不同階段的起止時間（開始和結(jié)束，里程碑）
• where（在什么地方）---相應(yīng)文檔，缺陷存放在什么位置，測試環(huán)境等
• who（誰；什么人）---項目相關(guān)人員，安排那些人員進(jìn)行測試
• how（如何做）---（測試方案技術(shù)層面）如何去做，使用那些工具以及那些方法進(jìn)行測試
• 計劃作用：在測試之前編寫的，是用來指導(dǎo)測試行為的（管理層面的）

第三階段：測試設(shè)計階段（寫用列）

• + - 黑盒測試的特點：
  • 黑盒測試只有采用窮舉時輸入測試，把所有可能考慮到，實際上測試有無窮多個，完全測試是不可能的
• + - 測試用例概述：
  • 測試用例的定義：設(shè)計一種情況（輸入數(shù)據(jù)）軟件在種場景下能夠正常運行并且達(dá)到期望執(zhí)行結(jié)果則通過如不能正常運行而且重復(fù)發(fā)生，那可能是一個軟件缺陷
  • 軟件測試過程管理：軟件測試是軟件質(zhì)量管理中最實際的行動，同時也是耗時最大的一項工作（組織，步驟，計劃的開展）（量化，測試用例是具體的量化行為之一）
• 測試用例設(shè)計方法：
  • 等價類
    • 有效等價類：規(guī)范有意義，合理的輸入
    • 無效等價類:不合理或無意義的輸入
  • 邊界值
    • 邊界值法：以邊界情況的處理作為主要目標(biāo)專門設(shè)計測試用例額的方法
    • 邊界點
      • 上點：邊界上的點
      • 內(nèi)點：區(qū)間內(nèi)的點
      • 離點：離上點最近且不與上點為同一等價類的點
  • 錯誤推敲法
    • 單元測試時列出在模塊中常見的錯誤在模塊
    • 以前產(chǎn)品中曾經(jīng)發(fā)現(xiàn)的錯誤
    • 產(chǎn)品在客戶實用過程中發(fā)現(xiàn)的錯誤
    • 總體體發(fā)生錯誤的情況
    • 一些公共的模塊
    • 修復(fù)了bug功能和模塊
  • 因果突圖法
    • 概述：
      • 分析需求規(guī)格說明書哪些是原因哪些是結(jié)果
      • 選擇條件以及對應(yīng)的結(jié)果
    • 使用范圍：1：多輸入的情況下條件沒有順序性
    • + - 基本步驟
      • 1：分析哪些是原因哪些是結(jié)果
      • 2：分析描述語義的內(nèi)容，并將其表示成連接各個原因與各個結(jié)果的因果圖
      • 3：把因果圖圖寫成判定表
    • 判定表(合并相似的內(nèi)容
      • 條件樁；列出了問題的所有條件
      • 條件項；列出特定條件的的取值
      • 動作樁；列出問題規(guī)定可能采取的所有操作
      • 動作項：各種取值條件下應(yīng)該才去的的動作
  • 正交法（PICT工具）
    • + - 1：在安裝PICT的目錄中新建一個txt文件并把需要組合的參數(shù)輸入進(jìn)去
      • 帳戶名: 空,不存在,超長,超短,正常
      • 密碼: 空,超長,超短,不匹配,正常
      • 驗證碼: 空,超長,超短,不匹配,正常
    • 2：打開開cmd進(jìn)入pict的目錄內(nèi) ?執(zhí)行命令：pict ?參數(shù)文件??(可在命令增加文件保存的路徑)
  • 場景法
    • 概述;：運用場景對系統(tǒng)發(fā)生的功能或業(yè)務(wù)流程進(jìn)行描述，從而列出出問題的一種方法 ?/ ??模擬特點場景發(fā)生的事情事件來觸發(fā)某個動作的發(fā)生，觀察最終結(jié)果，從而來發(fā)現(xiàn)軟件的存在問題
    • 場景法的路徑：基本流（用戶的正常操作）和備選流（基本流以外一系列的異常操作）在基本流和備選流的 過程中可以采用前面的等價值和邊界值，因果圖法等從而達(dá)到各種測試方法的融合。
    • + - 設(shè)計方法
      • 1描述基本流和各項備選流
      • 2根據(jù)基本流備選流生成測試場景
      • 3對每一個場景生成測試用例
        • 1：首先進(jìn)行等價類劃分
        • 2：再進(jìn)行邊界值的劃分
      • 4復(fù)審用例，去掉多余的用例，對每一個測試用例確定測試數(shù)據(jù)值（注：簡單的用列能合并就合并）
    • 是測試使用最多的方法，策略：先對于項目測試先使用用場景法進(jìn)行測試并進(jìn)行場景法編寫用例，盡可能在場景法里面融合其他方法，對于輸入框，可以編寫單獨的用例進(jìn)行進(jìn)一步策測試
• 用例例格式基本要素：
  • 1用例編號
  • 2測試項目
  • 3測試標(biāo)題
  • 4級別（優(yōu)先級）
    • 越基礎(chǔ)的功能和用戶常用的優(yōu)先級越高，復(fù)雜異常的低
  • 5預(yù)置條件
  • 6操作步驟
  • 7預(yù)期輸出
  • + - 8測試結(jié)果
    • pass：表現(xiàn)與預(yù)期一致
    • falt：與預(yù)期不一樣
    • NA：功能未完成/環(huán)境不支持/沒有工具
    • block：有bug阻塞（備注阻塞bug的ID）
  • 9測試者
  • 10測試時間
  • 11：備注
• 需求不明確如何寫用例：
  • 1：可以去問下開發(fā)看看開發(fā)如何去描述的
  • 2：可以參考一下同類競品
  • 3：有經(jīng)驗的話根據(jù)個人經(jīng)驗
  • 4：還可以請教領(lǐng)導(dǎo)
• 測試用例的作用：
  • 1避免盲目測試使測試重點突出目的明確，軟件更新后只需要修改少部分測試用例
  • 2:通用化和復(fù)用化使軟件測試易于開展，有助于不斷改進(jìn)工作。
  • 3時間緊迫的話可以分清重點。 是測試工作的見證
• 測試用例的維護(hù)：
  • 及時更新，及時補充，及時修改，刪除冗余的用例
• + - 如何保證測試用例對需求的覆蓋：
  • 1：測試需求的獲取分為兩步
    • 顯式需求
      • 原始需求說明書
      • 產(chǎn)品規(guī)格說明書
      • 軟件需求文檔
      • 通用的協(xié)議規(guī)范
      • 有無繼承性文檔
      • 經(jīng)驗庫有無課借鑒的
    • 隱性需求
      • 用戶的主觀感受
      • 市場的主流觀點
      • 專業(yè)人士的評價
  • 2：將不同的需求產(chǎn)生一個個需求點
    • 界定需求點的范圍
    • 利用各種測試設(shè)計方法產(chǎn)生不同的測試點
  • 3：需求有變動及時更新用例
  • 4：通過用例評審，團隊人員一起討論補充和完善
  • 5：用例執(zhí)行階段保證100%執(zhí)行率，對新增的需求及時補充用例
  • 6：將測試的需求，測試的用例，發(fā)現(xiàn)的bug關(guān)聯(lián)起來，便于管理和跟蹤，同時也便于查看需求覆蓋率

第四階段：測試（系統(tǒng)測試）執(zhí)行階段——提bug

• 執(zhí)行前（冒煙測試/確認(rèn)測試）
• + - 執(zhí)行中（提交缺陷）
  • + - 1軟件缺陷的定義
    • 軟件未實現(xiàn)產(chǎn)平說書要求的功能明
    • 軟件出現(xiàn)了產(chǎn)品說明書指明不應(yīng)該出現(xiàn)的錯誤
    • 出現(xiàn)了產(chǎn)品說明說未提到的功能
    • 軟件沒有實現(xiàn)產(chǎn)品說明書雖未明確提及但應(yīng)該實現(xiàn)的目標(biāo)功能
    • 軟件難以理解，不易使用 ?運行速度慢，或者軟件測試員人為用戶會認(rèn)為不好的地方
  • + - 2軟件缺陷報告的原則
    • 盡早報告軟件缺陷。有效描述給出說明問題的一系列明確步驟（對事不對人）
    • 對軟件缺陷報告跟蹤到底（每天到公司先看下bug狀態(tài)，監(jiān)視其修復(fù)全過程）
    • 每個報告只針對一個缺陷
  • + - 3軟件缺陷報告描述
    • 缺陷ID
    • 缺陷狀態(tài)
    • 缺陷標(biāo)題
    • 缺陷的詳細(xì)描述
    • 缺陷的嚴(yán)重程度
    • 缺陷的緊急程度
    • 缺陷提交人
    • 缺陷提交時間
    • 缺陷所屬項目/模塊
    • 缺陷指定解決人?解決時間?????最終解決人
    • ·缺陷處理結(jié)果描述
    • 缺陷結(jié)果復(fù)核人
    • 缺陷復(fù)合結(jié)果描述
    • 測試環(huán)境說明
    • 必要的附件（對于某些文職難以描述的結(jié)果使用圖片等附件）
  • + - 4軟件缺陷嚴(yán)重程度：
    • + - A類-（致命）錯誤致命：系統(tǒng)崩潰，數(shù)據(jù)丟失，死機，擁塞等
      • 不能執(zhí)行重要功能
      • 程序硬氣的死機
      • 死循環(huán) ?數(shù)據(jù)庫發(fā)生死鎖
      • 應(yīng)錯誤導(dǎo)致的程序中段
      • 與數(shù)據(jù)庫鏈接錯誤
    • + - B-較（嚴(yán)重）的錯誤（嚴(yán)重的影響系統(tǒng)或基本功能的實現(xiàn)且沒有辦法更正
      • 程序錯誤
      • 程序接口錯誤
      • 數(shù)據(jù)庫的表。業(yè)務(wù)規(guī)則。缺陷值未加完整性等約束條件
    • + - C- 類（一般）描述不清，內(nèi)容錯別字，易用性差
      • 界面不規(guī)范
      • 輔助說明描述不清楚或不描述
      • 輸入輸出不規(guī)范
      • 長操作作未給用戶提示
      • 未采用行業(yè)術(shù)語
      • 可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯區(qū)分標(biāo)志
    • D-類（輕微）建議優(yōu)化：建議軟件優(yōu)化的方面
  • + - 6軟件缺陷的管理
    • 缺陷管理概述：
      • 在軟件的生命周期中識別，管理，溝通任何缺陷的過程，確保軟件跟蹤管理而不丟失
      • 一般需要跟蹤管理工具幫助進(jìn)行管理（禪道 ，bugzila）
    • 缺陷管理作用：
      • 對bug進(jìn)行管理，使得相關(guān)測試人員可以通過該系統(tǒng)進(jìn)行無縫對接，及時交流和溝通并且記錄bug的整個生命周期
  • + - 7軟件缺陷生命周期
    • 發(fā)現(xiàn)識別bug——提交bug——分析和定位bug——修改相應(yīng)的程序處理bug——驗證修改——關(guān)閉缺陷——通過分析bug的共性，防止再次發(fā)生
  • + - 8軟件缺陷處理流程

    • 流程：識別---新建--編輯----提交---分配（重新分配）---修復(fù)--- ??????????????????????????????????????????????????????????????????????????????????驗證(驗證不通過)---關(guān)閉（重新打開）---總結(jié)防止bug再次產(chǎn)生 ?????最后進(jìn)行回歸測試

• 如何定位BUG？

  • WEB：打開f12，進(jìn)入開發(fā)者模式，再去點擊列表，f12里面去看 查詢出來的頁面內(nèi)容，你點擊這個按鈕的時候，他會向后?臺發(fā)送請求，類表查詢，可以從開發(fā)者模式頁面查看具體?請求信息和返回的請求報文信息，看Reponse（響應(yīng)）里 面，如果返回有數(shù)據(jù)，數(shù)據(jù)對的，就是前端的問題，是前端自己沒有獲取到，但是后端是給了你的。

    APP：通過抓包來查看請求或響應(yīng)數(shù)據(jù)

• + - 如何找到高質(zhì)量的bug：
  • 1：充分學(xué)習(xí)產(chǎn)品的需求，知識和流程
  • 2：充分考慮異常包含邏輯異常，甚至開發(fā)設(shè)計中的異常
  • 3：充分了解客戶需求，客戶使用場景，客戶使用流程，多從客戶角度出發(fā)
• + - 如何提交高質(zhì)量的bug：
  • 1：發(fā)現(xiàn)bug先確認(rèn)不是自己的誤操作
  • 2:：記錄bug出現(xiàn)的步驟和保留現(xiàn)場（必要時提供日志和現(xiàn)象截圖）
  • 3：最后提交bug（達(dá)到下面要求）
  • a：準(zhǔn)確——每個組成部分描述準(zhǔn)確
  • b：清晰——描述清晰，易于理解
  • c：簡潔——只包含必要的信息
  • d：完整——復(fù)現(xiàn)bug的完整步驟和其他本質(zhì)信息
  • e：一致——按照一致的格式書寫缺陷報告
• + - 什么是高質(zhì)量的bug：
  • a：影響功能的
  • b：迄今為止都未被發(fā)現(xiàn)的
  • c：造成影響比較大的bug
• + - bug漏測如何處理？
  • 1：對漏測的原因進(jìn)行分析，和自我檢討
  • 2：對漏測的bug進(jìn)行歸類，尋找彌補的方法
  • 3：對此次行為進(jìn)行總結(jié)反省
• + - 提交的bug開發(fā)拒絕了怎么辦：
  • 第一步：首先在bug系統(tǒng)備注溝通（如認(rèn)可開發(fā)的觀點則關(guān)閉）——來回溝通多次
  • 第二步：直接找開當(dāng)面溝通（把我認(rèn)為是bug的理由和需要的證據(jù)給他看）——還不承認(rèn)是bug
    • 告訴開發(fā)這個問題被客戶發(fā)現(xiàn)后產(chǎn)生的影響和后果
  • 第三步：找自己的領(lǐng)導(dǎo)和產(chǎn)品經(jīng)理說明情況（對事不對人）——如果還未解決
  • 第四步：開會討論（一般找了領(lǐng)導(dǎo)就會出結(jié)果）
• + - 對于難以重現(xiàn)的bug該怎么辦？：
  • 1、盡力去查找出錯原因，比如有什么特別的操作或特定的環(huán)境和數(shù)據(jù)
  • 2、在測試報告中詳細(xì)描述測試操作步驟，bug發(fā)生的癥狀，bug發(fā)生的具體環(huán)境描述，這樣對于再次重現(xiàn)有一定的參考作用
  • 3、無法重現(xiàn)的bug嘗試多次，再次出現(xiàn)后可以直接叫程序員過來看
  • 4、無法重現(xiàn)的嚴(yán)重bug，因為幾率原因，重現(xiàn)不了或難以重現(xiàn)的不代表沒有發(fā)生，可以嘗試多次，寫下發(fā)生的概率。開發(fā)對程序比測試熟悉的多，及時無法重現(xiàn)，程序員也需會了解問題所在
• + - 測試時很難發(fā)現(xiàn)bug怎么辦？
  • 第一種正常執(zhí)行用例
    • 1：如果測試的人只有我一個的時候，看測試的版本是開發(fā)中的還是已經(jīng)上線的，如果是開發(fā)中的未上線的版本，未發(fā)現(xiàn)bug就要引起注意了，畢竟大部分情況是能發(fā)現(xiàn)bug的。
    • 2：如果測試的人不止你一個人的時候，看看其他人是否能發(fā)現(xiàn)bug——分組討論

      • 場景1、如果測試的bug不多，那說明軟件質(zhì)量應(yīng)該還不錯， 測試不出來bug 也不要著急，

        場景2、其他人能夠發(fā)現(xiàn)bug，但是你發(fā)現(xiàn)不了， 這個情況就要去思考，你的測試方法是不是不對，?你對需求是否理解到位，是否還有遺漏，?仔細(xì)分析下其他人發(fā)現(xiàn)的bug是否在自己負(fù)責(zé)的模塊存在，這時需要：測試人員需突破思維定勢,打破常規(guī)需要補充新的測試用例.尤其需要補充一些覆蓋無效等價類的測試用例.

  • 第二種情況：
    • 第二種情況：新人到公司， 為了讓新人盡快熟悉業(yè)務(wù)，會讓新人跑跑?測試用例，?這個時候測試的模塊一般都比較成熟了，或者可能都已經(jīng)上線了，?發(fā)現(xiàn)不了bug很正常

第五階段：測試評估階段

• 1：撰寫測試報告：
  • 1：測試的模塊
    • （模塊開始和結(jié)束的測試時間）
    • （設(shè)計的用例數(shù)和執(zhí)行數(shù)）
    • （用例通過多少失敗多少）
    • （有多少bug，已解決多少bug）
    • （遺留的問題）
  • 2：匯報一下大致的結(jié)果
  • 3：遺留問題和風(fēng)險說明
  • 4：評估是否符合上線標(biāo)準(zhǔn)
• 通過：上線
• 不通過：打會修改字后重測

? ?

七：敏捷測試流程

H模型 ?有什么就測就測什么，體現(xiàn)的軟件測試盡早開始? ?

H模型中：軟件測試過程活動完全獨立,貫穿于整個產(chǎn)品的周期,與其他流程并發(fā)地進(jìn)行,某個測試點準(zhǔn)備就緒時,就可以從測試準(zhǔn)備階段進(jìn)行到測試執(zhí)行階段。

軟件測試可以盡早的進(jìn)行,并且可以根據(jù)被測物的不同而分層次進(jìn)行? ?

?

八：企業(yè)測試人員組織

企業(yè)測試人員組織

• 條件特別好的 ?1：1
• 條件比較好的 ?有獨立的測試團隊服務(wù)于多個開發(fā)
• 條件一般的 到達(dá)系統(tǒng)測試測試階段外面調(diào)配測試人員加本公司開發(fā)一起測
• + - 條件差的沒有專門的測試人員
  • 需求：業(yè)務(wù)，學(xué)習(xí)之前的bug單
  • 搭建測試管理系統(tǒng)（禪道，項目軟件搭建運行通過運行軟件進(jìn)一不步了解）
  • 編寫用例，執(zhí)行，文檔化
• + - 測試工程師的分類：
  • 系統(tǒng)測試工程師
  • 性能測試工程師
  • 自動化測試工程
  • 測試開發(fā)工程師

? ? ?

?

?

轉(zhuǎn)載于:https://www.cnblogs.com/ll1996/p/10253991.html

總結(jié)

以上是生活随笔為你收集整理的软件测试 入门理论丶的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。