通用軟件測試實踐

通用軟件測試實踐

軟件分類

軟件缺陷定義

軟件測試定義

測試目的

測試與調試區別

測試對象

整個軟件開發完畢,是否所有功能實現就是確認測試,所有功能確認開發完畢進行系統測試

系統測試耗時最多,模擬環境與真實環境下進行測試。

驗收測試,專門針對特定人羣開發需要驗收測試

職業素養

軟件生命週期

軟件工程

瀑布模型

快速原型模型

Axure,固定的客戶開發軟件產品

增量模型

組件爲單位進行開發,降低軟件開發風險,後續不斷增加新功能

最常用的開發模型

迭代模型

強調開發的深入優化,發佈新版本 新增功能體現增量模型,對已有功能優化就是迭代,修復缺陷是

迭代適應需求的變化比較明顯,變化比較快的場合,需求不穩定自己的產品

螺旋模型

獨有的分險分險功能,更適合大型昂貴的系統開發

 

軟件測試模型

需求分析、測試計劃、測試設計、都需要進行測試

V模型

測試放在了編碼之後

W模型

測試與開發過程獨立開,測試作爲獨立工作內容分開

拿到需求分析,首先驗收軟件具體的驗收點是什麼,驗收通過符合客戶需求,進行測試的設計。

當系統進行分析與系統設計時,要確認系統測試的設計

概要設計,各功能模塊的設計,要確認集成測試的設計,哪些模塊之間合併與集成,聯繫

詳細設計文檔,要確定單元測試的設計,每一個模塊做什麼的,功能模塊的單元測試

有了代碼以後,開始進行模塊測試,集成測試,所有程序都合併進行系統測試與確認測試,交付用戶要進行驗收測試。

所有執行都依賴前面確定的思路方法文檔。

H、X模型

H模型一般第三方測試外部,完全獨立從開發中獨立出來,測試活動要儘早準備與執行

X模型

針對小的功能模塊,探索性隨機測試,傳統測試要提前進行規劃,對有可能出現問題的地方隨機測試,有經驗

測試過程理念

測試人員要站在用戶角度思考問題與發現問題,邀請用戶參與測試也是必要的

測試越多發現問題越多

軟件測試分類

確認測試驗證功能是否實現,走一遍軟件流程

系統測試必須要確認測試之後進行,要在不同環境下

白盒檢查內部邏輯正確,又稱爲結構測試。

黑盒檢查功能是否安裝需求文檔都實現

灰盒測試,判斷輸入與輸出的正確性,判斷內部運行狀態,接口測試用來檢測輸入輸出及結果,只關注一部分接口代碼。

程序規範標準,有沒有註釋,空格測試靜態的,是否真正符合用戶需求,實際界面與需求中的說明是否相等,靜態測試檢查文檔。

動態測試,輸入數據與輸出數據是否符合預期。

功能黑盒測試,功能是否滿足要求,是否符合大衆使用習慣,考慮全面

性能測試,時間性能與空間性能

迴歸測試 ,測試用例就是測試的過程,除了測試新的功能還得要用以前的測試對新功能測試,兼容性驗證,測試以前的缺陷是否已經修復。

測試流程

第一步明確知道對哪些方向,需求進行測試,會有多少個功能模塊。

第二步編寫測試計劃,要測試哪些內容,場景,對模塊與模塊之間內在聯繫與規則該如何去測試。

測試生命週期

軟件測試原則

事先制定質量標準,再進行測試,根據標準判斷測試結果準確性,是否爲缺陷能否通過

 

錯誤缺陷都會有集中,調用錯誤會造成錯誤,深挖還有錯誤

保存好測試計劃、測試用例、測試報告

 

職業發展

測試需求與需求分析

溝通的問題

顯示需求文檔提及的與隱式需求,常理默認

用戶需求能不能實現相應的功能,通過界面實現

需求分析

在什麼環境下使用,什麼用戶會使用,會有什麼操作行爲

缺陷分佈

隱性需求不滿足也是缺陷

多注重用戶任務,而不是系統都有哪些功能

保證需求沒有歧義

需求狀態,已確定,待確定

評審是否可行性

需求改變,變更說明書,要二次評審,對其他模塊有無影響

Axure使用

跟蹤矩陣

判斷需求是否具有可測性

開發正向,測試逆向思維,考慮的越全面越好,想法越多越好

價格排序,功能單一不用拆分,測試文本框可以拆分,按照規則與不按照規則進行拆分

正向測試在需求範圍內的,反向不再需求範圍內的就是反向的,測試要點根據測試標準去定

 

評審

開會

對軟件需求規格說明書進行評審

測試需求不深入,找不全也會有問題

概要設計

詳細設計

代碼規範

評審分類

評審流程

 

評審規則流程

開會流程

評審規則

開會爲了發現問題,而不是解決問題

需求評審,代碼評審與測試評審,與測試相關的人員

會籤應該提前提前閱讀被評審作品

評審誤區

非實質性不是本質問題

評審記錄表

問題來源,對測試需求跟蹤矩陣的某一行,記錄需求跟蹤矩陣編號

提的問題認不認可,一定要和產品作者進行確認,開完會要對所有問題進行確認,確認問題進行標註

需求編號命名都是相同的,功能點名稱,功能和軟件界面元素和控件來實現

需求是對前面功能的描述,查詢功能,查詢文本框輸入內容,點擊查詢按鈕,把結果,列表等所有相關內容都要體現

需求拆分,正向在需求描述範圍內的,反向不在需求範圍內

測試要點,輸入正確獲取驗證碼按鈕纔可以點擊,要點如果怎麼樣,會怎麼樣,判斷標準如果滿足需求會怎麼樣,不滿足怎樣

需求跟蹤矩陣,評審記錄

驗證碼獲取有前提條件,輸入正確手機號才能獲取驗證碼,對應的手機號會受到驗證碼短信,這是對驗證碼測試,劃分要詳細

需求拆分,怎麼獲取的驗證碼,獲取之後會怎麼樣,測試點缺失覆蓋不全,根據社會經驗

獲取兩次驗證碼,第一次爲準還是第二次爲準,驗證碼獲取時間間隔 ,不能一天無限制的獲取驗證碼

測試要點,做了操作要有什麼效果與結果都要列舉,要有判斷條件與判斷條件的結果都要明確,必須是肯定語句,固定標準。

不顯示出來的東西,沒法測試,測試要點沒有的不用去測試,檢查版本的過程不會給客戶提示,界面沒有的東西不能測試

不能出現是否,必須用確定話語。

界面組件是按鈕不是功能,功能不要與組件名衝突

不能把缺陷的標準寫在需求文檔中,是bug,需求拆分只用寫怎麼操作的會有什麼結果,兩個完全相反的不能同時定義需求

功能點必須要拆分爲單一的,功能對應需求,需求要對功能做相應描述要一一對應。

測試要點也要分開

測試要點必須要明確,有什麼,沒什麼怎麼樣

語言描述,所有人都能理解的了,清晰明確

需求描述不能有歧義

功能說明清除一些,不能用組件界面內容代替

測試計劃

第一產品介紹說明,要確定版本,確定目標用戶,產品背景

測試引用出處,引用設計原型

詳細規定測試用例(文檔類型)

嚴重程度,客觀評價,影響範圍與程度

測試術語

測試策略與方案

哪個模塊怎麼測試,通過標準是什麼都要說明

軟件不但要測試正確的,也要測試不正確非法的,並提示錯誤信息。

不但強調功能還得要強調易用性,友善人性化

完成標準參考測試需求跟蹤矩陣,正確操作有什麼結果,錯誤操作有什麼結果

單元測試進入的條件,關聯模塊開發完畢就可以進入繼承測試,就是進入標準

集成測試完成,確認測試所有功能完畢就可以進行系統測試

所有單元測試完畢退出單元測是

理論上功能測試要覆蓋所有的功能項

設計錯誤,有沒有合乎場景,整體考慮,考慮功能的優先級與風險

多個不同設備,兼容性測試

測試進度安排

測試計劃模板

文檔修改記錄

測試範圍測試幾個大階段

參考文檔

測試需求,每個模塊做哪些方面的測試,需求是什麼

測試需求跟蹤矩陣與軟件需求中都會有,主要突出每個功能模塊要做哪些方面的測試,是功能、性能還是安全的測試

測試策略

安裝測試階段,分爲單元、集成、系統

安裝不同模塊測試類型進行測試,分爲數據測試、功能測試、業務週期測試、界面測試

 

測試方法與工具

黑盒測試用例

設計測試用例

測試用例內容

測試項是測試軟件的目的,要測試什麼

輸入1+1,輸出預期結果顯示結果的位置爲2.

反向測試故意輸入錯誤,執行錯誤操作,提示

測試用例模板

模塊名稱/二級模塊名稱,用戶名不算一個模板,不要寫到最底層的葉節點,測試類型Function

依賴用例,刪除必須依賴於添加,之間有業務依賴於聯繫

測試步驟要詳細描述操作步驟與操作流程,詳細到打開瀏覽器,輸入超鏈接,文本框輸入什麼內容,邏輯正確

測試項/目的 ,要用一句話概括主要的內容,目的描述要精確和細微

預期結果要寫到足夠準確,根據程序界面把步驟寫出來,實際結果與預期結果是否相同,設計階段只考慮設計

測試過程測試用例要寫清楚,打開百度首頁url,通過什麼方式走到註冊頁面。

所有到達註冊登錄界面的步驟都得測試,頁面上所有的內容都得測試

一個測試用例最重要的是目的,主要目的勾選協議註冊賬號,查看協議內容是另外的測試用例,目的確定用最少路徑實現目的

根據系統設計要求的流程去做

用例編寫注意

特殊有代表的例子,在有效的時間裏要找到平衡點,差不多就行,多設計測試用例從不同方向測試,差不多就行找到平衡,看的全面一些

反向從不同角度違反規則,測試用例應該越來越多覆蓋面越來越全。

及時更新版本,系統和環境要求

測試用例與測試用例步驟要對等清晰

用例設計方法

黑盒測試輸入等於預期

測試數據的選擇,等價類劃分、邊界值分析

測試步驟設計,通過因果圖法、判定表法、正交實驗法、功能圖法、場景法

等價類劃分

劃分若干個部分,挑選一部分數據進行測試,一個類代表性的等價所有

對數據進行正向反向各種檢測

級聯菜單,省市縣在計算機程序中,符合條件有n個,其他都是無效的

無效等價類從不同角度違反規則,所有等價類合併起來是全部數據整體,數據改變測試目的發生改變

邊界值分析法

重要的地方就在邊界,在邊界安全其他位置更爲安全,邊界數據非常容易出問題,數據類型邊界整形int -2147483648 ~ 2147483647  1字節     8位元組,即8位bit,   可存儲-2^8~2^7   (-128 ~ 127)

數組下標越界

等價類考慮 5與18 邊界值,小的文本框

剛剛,明確個數多1少1,選擇列表第一個與最後一個下拉框,省市,額定電壓221

因果圖測試用例步驟設計方法

分析輸入條件與輸出結果的因果關係,組合關係。

想要得到彈出框、提示框必須要怎麼執行操作的,通過什麼樣的操作才能實現當前步驟,多個因素纔能有一個結果

程序設計階段考慮到的,操作產生結果,上一步操作結果是下一步操作的原因

適合局部小功能

互斥至多有一個成立

判斷表驅動法

當某個條件產生,其他的條件不起作用,主要選擇成立其他影響因素直接被忽略屏蔽

 

正交實驗法

面更加廣泛,比較注重全面,多步驟多組合的分析

排列整齊,統計新思想方法

內容分析,分析出來對測試結果有影響的因素條件都有哪些,條件因素都有幾種取值情況,確保分析的結果每一列不同數字出現次數相等,相同內容出現次數相等,測試每個因素參與實驗機率相同的,保證實驗公平的(字體顏色、字體大小、字體樣式)

 黃色、紅色都出現10次,每一個都是公平的,數字對出現一次不能一個數字對出現兩次

確定因素,如果涉及好按照說明,否則按照等價類邊界值或者每一個因素有多少可選狀態,選擇合適的正交表

每個因素有3個水平,因素數是3^4 影響因素4每個因素取值情況3

場景法

某一個場景有很多動作是一個複雜流程,一個片段代表一個節點,一個場景包含很多內容

一個業務一般只有一個基本流,從整體考慮問題分支比較多,適合流程分析,把每個流程分支在路徑上分析一下,給每一個路徑配測試數據能達到相應結果

具體業務邏輯流程,購物車買東西有很多分支,主分支直接結算,其他分支貨不夠,限賣一件,清空購物車,添加商品數等等其他過程

軟件測試人員一定對業務流程最清晰,認識最深刻,開發正向方式,測試各種組合去破壞,發現缺陷越多

軟件測試從小規模擴展爲大規模,從小到大按照流程去做,用什麼瀏覽器,打開網頁,點擊按鈕,預期結果。第一個輸入框,第二個輸入框輸入,預期結果。

系統,賬號登錄系統(普通員工、審覈員區分),進入後再進行相應操作,測試必須按照一定流程執行,必須根據軟件說明,描述出程序基本流與備選流。

某一個場景某一個小片段,再等價類邊界值因果圖,整體流程按照場景法,設計各種不同場景。

流程清晰的系統都適用於場景法測試

只考慮文本框等價類分析法、考慮請假流程場景法

狀態遷徙圖法(功能圖)

操作系統四大管理功能、進程管理、存儲管理、文件管理、設備管理

優先程序優先級非常高

設計足夠多測試用例,對系統狀態覆蓋,優先狀態必須在一定條件下滿足,對狀態條件組合的覆蓋

列出所有可能的輸入事件,點擊輸入內容,找到空閒狀態,操作A到達一個狀態,後續不能循環操作A

 

不要遺漏任何操作,任何操作都會對軟件狀態產生影響,產生新的狀態

狀態一直變遷,有沒有新產生的狀態,新產生的狀態要繼續分析,由1,2操作來,不能使用1,2操作了

測試大綱法

從根節點對模塊分析,對所有功能點分析,從根節點到不可分割的葉節點爲止就是測試路徑,覆蓋性

探索性測試

必須寫測試用例,憑藉直覺經驗,猴子測試隨意

測試方法選擇策略

首先等價類劃分,只要有文本框肯定要做等價類劃分,任何條件下都要使用邊界值,等價類劃分都要涉及邊界值,有效等價於無效等價類中間通過邊界值劃分。

輸入條件組合情況,要選用因果圖和判定表法(決策表),因果圖就是條件組合和條件之間約束。

參數配置類,正交表法選擇較少組合方式達到最佳效果

狀態遷徙圖通過不同時期條件有效性設計不同測試數據,對軟件進行測試

業務流程清晰的系統,使用場景法貫穿整個案例,流程設計測試用例

錯誤推測法、探索性

對照程序邏輯與測試大綱,測試點樹形結構列出來,一條一條測試,檢查測試用例覆蓋程度,補充足夠多測試用例

表達能力

web測試考慮點

功能連接、表單、cookie、數據庫數據測試、設計語言測試

性能測試、速度、壓力、負載

兼容性測試,從客戶端性能只考慮速度,服務端會考慮壓力與負載

可用性測試與安全測試

軟件缺陷

缺陷類型

缺陷狀態

缺陷來源

軟件生命週期

軟件定向,開始到最後

軟件測試生命週期

獲取測試需求,準備下一版本測試

缺陷生命週期

缺陷描述

缺陷報告

測試報告

衡量測試覆蓋程度,是否所有界面都測試到,界面是否美觀,界面的圖標、文本框,彈出框,文字,信息是否準備,空間準確性。

 

功能需求,非功能需求

缺陷分析報告

質量評估

測試報告模板

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章