軟件測試-常用術語


軟測常用術語:

C/S

C指的是客戶端(Client) , S指的是服務器端(Server) ,這種軟件是基於局域網或互聯網的,需要一臺服務器來安裝服務器端軟件,每臺客戶端都需要安裝客戶端軟件。比如我們經常用的QQ、和各種網絡遊戲就屬於C/S結構的軟件。

B/S

B指的是瀏覽器(Browser) ,S指的是服務器(Server) ,這種軟件同樣是基於局域網或互聯網的,它與結C/S結構軟件的區別就在於,不需要安裝客戶端(client) ,只需要有瀏覽器,就可以直接使用。比如搜狐、新浪等門戶網站及163郵箱都屬於B/S結構的軟件B/S結構軟件是現在軟件的主流,與C/S結構軟件相比,便於升級和維護,是測試的重點。

缺陷[Bug/Defect]

軟件的Bug指的是軟件中(包括程序和文檔)不符合用戶需求的問題

測試環境

軟件測試環境就是軟件運行的平臺,包括軟件、硬件和網絡的集合。用
一個等式來表示:測試環境=軟件+硬件+網絡

測試用例[Test Case]

在測試執行之前設計的一套詳細的測試方案,包括測試環境、測試步驟、測試數據和預期結果。
用一個等式來簡單表示:測試用例=輸入+輸出+測試環境
其中,
“輸入”包括測試數據和操作步驟
“輸出”指的是期望結果
“測試環境”指的是系統環境設置

冒煙測試[Smoke Testing]

在對一個新版本進行系統大規模地測試之前,先驗證一下軟件的基本功能是否實現,是否具備可測性
在這裏插入圖片描述

迴歸測試

檢查之前發現的問題有沒有被修改,是否產生新的bug
迴歸測試是指修改了舊代碼後,重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。自動迴歸測試將大幅降低系統測試、維護升級等階段的成本。
在整個軟件測試過程中佔有很大的工作量比重,軟件開發的各個階段都會進行多次迴歸測試。通過選擇正確的迴歸測試策略來改進迴歸測試的效率和有效性是很有意義的。

內測和公測

內測:
軟件做出來了以後交給實際用戶會不會出現你自己用的時候沒發現的問題,所以要找一些內部人員大家一起用一用看看有沒有啥問題。
公測:
同內測,只不過找的是外部用戶

α測試與Beta測試

€ α測試(Alpha Testing) //重要
α測試是由一個用戶在開發環境下進行的測試,也可以是公司內部的用戶在模擬實際操作環境下進行的測試。α測試的目的是評價軟件產品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
驗收測試的一種,指的是由用戶、測試人員、開發人員等共同參與的內部測試
大型通用軟件,在正式發佈前,通常需要執行Alpha和Beta測試。α測試不能由程序員或測試員完成。

€ β測試(Beta Testing) //重要
Beta測試是一種驗收測試。Beta測試由軟件的最終用戶們在一個或多個客房場所進行。
α測試與Beta測試的區別:

測試的場所不同:Alpha測試是指把用戶請到開發方的場所來測試,beta測試是指在一個或多個用戶的場所進行的測試。

Alpha測試的環境是受開發方控制的,用戶的數量相對比較少,時間比較集中。beta測試的環境是不受開發方控制的,用戶數量相對比較多,時間不集中。

alpha測試先於beta測試執行。通用的軟件產品需要較大規模的beta測試,測試周期比較長。

測試覆蓋率

覆蓋率是用來度量測試完整性的一個手段,同時也是測試技術有效性的一一個度量
覆蓋率= (至少被執行一次的item數) /item的總數
(支付寶有10000個功能點,這一次測試測試了9000個,那就是覆蓋率90%)
特點:
1.通過覆蓋率數據,可以檢測我們的測試是否充分
2.分析出測試的弱點在哪方面
3.指導我們設計能夠增加覆蓋率的測試用例,有效提高測試質量,但是測試用例設計不能- -味追求覆蓋率,因爲測試成本隨覆蓋率的增加而增加。

測試覆蓋率對於黑盒測試來說,主要指兩個方面:
需求覆蓋和用例覆蓋
需求覆蓋
1.定義:它表示在測試中,有哪些函數被測試到了,其被測試到的頻率有多大,這些函數在系統所有函數中佔的比例有多大通過設計一定的測試用例,要求每個需求點都被測試到。
2.計算公式 : 需求覆蓋= (被驗證到的需求數量) / (總的需求總數)

用例覆蓋(非常關鍵的度量元素)
1.定義:主要體現在我們每輪測試驗證通過的用例數在總用例中的比重
2.計算公式 : 用例覆蓋= (驗證通過的用例數量) / (總的用例總數)

測試覆蓋率的運用

簡單的測試覆蓋率 :本次測試執行的用例數/所有用例數
上述覆蓋率統計建立在認爲總用例數編寫全面,一般對於大型系統測試要求覆蓋率100%

主要考查測試人員,對當前版本的策略把控,保證覆蓋率符合測試策略。
覆蓋率的審覈:抽樣驗收

基於產品的測試覆蓋率:已測試需求點/設計所有需求數
以產品、需求維度統計,無論大型項目或是小需求迭代都要求覆蓋率達到100%
更多的是把這份結果交給產品方,由產品方來判斷是否有遺漏的。
覆蓋率的審覈:抽樣驗收

基於白盒的測試覆蓋率: 大多工具判斷語句覆蓋,即單元測試代碼覆蓋代碼行/總代碼行

更多考察研發人員; 更多時候要求覆蓋率達到80%+

缺陷:覆蓋率數據只能代表測試過哪些代碼,不能代表是否測試好這些代碼;容易遺漏邏輯、判斷等場景

基於自動化的測試覆蓋率: 自動化覆蓋的測試場景(測試用例) /所有測試場景(用例)

80/20原則.比如用戶80%的時間在使用20%的功能,20%的功能就可以支撐起用戶最關鍵的業務場景,自動化測試的用例選擇更着重於這20%的核心功能。

用途:自動化測試更着重於迴歸驗證,沒必要追求過高的覆蓋率,而要考慮用例設計(迴歸測試中追逐的是主流程業務)

測試覆蓋率的最終意義

應用最多的地方在測試停止標準,以及考覈測試人員的標準
單純討論測試覆蓋率,在瀑布式開發模型中並不重要,但在螺旋式、敏捷開發模型中,由於不斷迭代累加,很難確定哪些模塊在開發過程中沒有給予足夠的測試

短迭代、DevOps中,更強調用單元測試覆蓋率來評估不斷增加的代碼數量

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