• 對于數(shù)值類型，默認(rèn)值為0。
  

課程目標(biāo)

如下圖:

• 課程學(xué)完可以到達(dá)中高級測試工程師
• 到達(dá)第二部分,基礎(chǔ)入門非常重要.
  

1. 入門前的7個基礎(chǔ)問題

1. 什么是軟件測試？

軟件測試是驗證用戶產(chǎn)品死否滿足用戶需求. 是否滿足用戶需要關(guān)乎公司盈利.

2.調(diào)試和測試區(qū)別？

目的:

• 調(diào)試:發(fā)現(xiàn)解決軟件中的缺陷.
• 測試:發(fā)現(xiàn)軟件中的缺陷.

參與角色:

• 調(diào)試: 開發(fā)人員
• 測試:開發(fā)人員,測試人員等 單元測試和集成測試主要由開發(fā)人員完成.

執(zhí)行階段:

• 調(diào)試:編碼階段.
• 測試: 貫穿整個軟件生命周期.

3.軟件測試的崗位

測試工程師:

• 測試開發(fā)工程師
• 測試工程師

職能:

• 測試開發(fā)工程師 :
• • 測試產(chǎn)品質(zhì)量;
• • 開發(fā)效能工具:
• • • 自動化工具,代碼覆蓋工具,數(shù)據(jù)構(gòu)造工具.
• 測試工程師:
• • 測試產(chǎn)品質(zhì)量

軟件研發(fā)工程師和測試開發(fā)工程師的區(qū)別:

• 研發(fā)工程師: 開發(fā)為主.
• 測開工程師: 測試為主,開發(fā)為輔.

4.軟件測試的發(fā)展前景

如下圖:

• 測試管理工具: 禪道開源軟件.
• selenium : 界面自動化工具
• appium:移動平臺上主流的自動化測試工具
• jenkins:自動化工具
• loadrunner,jmeter : 界面的性能工具,
• jmeter: 接口性能工具
• 安全測試: sql注入,xss,白帽子 這些都要求測試人員具備的基礎(chǔ)安全測試.
• 探索性測試: 依靠測試人員的經(jīng)驗.
• 職位路線: 初中高 到 管理
  

5.軟件測試的薪資如何

職友集

• 低級測試泛濫,俗稱 點點點.
• 高級測試稀缺 : 每個階段按年算.
• 高級測試與研發(fā)崗薪資差不多.

6.軟件測試和開發(fā)的區(qū)別

難易程度

• 開發(fā)專業(yè)度高;
• 測試人員掌握內(nèi)容廣度大。

工作環(huán)境辦公用品:

• 筆記本+顯示屏
• 開發(fā)環(huán)境:完全一致。

薪水:

• 中小企業(yè)測試人員薪資比開發(fā)要低一點。
• 中大型企業(yè)測試人員和開發(fā)人員薪資相當(dāng)。
  發(fā)展前景
• 發(fā)展前景和開發(fā)一樣

繁忙程度:

• 執(zhí)行測試一項目上線完成
• 項目上線也需要測試人員跟進(jìn)

技能要求:
+

7.測試人員具備的素質(zhì)

2. 軟件測試基本概念

2.1 需求的概念

2.1.1需求的基本概念

概念:

• 滿足用戶期望或正式規(guī)定文檔（合同、標(biāo)準(zhǔn)、規(guī)范）所具有的條件和權(quán)能，包含用戶需求和軟件需求。
• IEEE定義：軟件需求是 (1)用戶解決問題或達(dá)到目標(biāo)所需條件或權(quán)能(Capability)。 (2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。 一種反映上面(1)或(2)所述條件或權(quán)能的文檔說明。它包括功能性需求及非功能性需求，非功能性需求對設(shè)計和實現(xiàn)提出了限制，比如性能要求，質(zhì)量標(biāo)準(zhǔn)，或者設(shè)計限制.

在多數(shù)軟件公司，會有兩部分需求，一部分是用戶需求，一部分是軟件需求。

用戶需求:

• 可以簡單理解為甲方提出的需求，如果沒有甲方，那么就是終端用戶使用產(chǎn)品時必須要完成
  的任務(wù)。該需求一般比較簡略
• 假如我要給同學(xué)們開發(fā)一個聲控?zé)?，同學(xué)們能夠提出哪些需求?
• • 燈亮的時間、燈何時亮、燈安裝的位置
• • 燈的顏色
• • 燈的形狀
• • 五花八門的用戶需求
• • 燈的材質(zhì)
• • 燈的亮度
• • 燈可以聯(lián)網(wǎng)
• • 燈支持語音識別

軟件需求:

• 或者叫功能需求，該需求會詳細(xì)描述開發(fā)人員必須實現(xiàn)的軟件功能。
• 大多數(shù)公司在進(jìn)行軟件開發(fā)會把用戶需求轉(zhuǎn)化為軟件需求。
• 用戶需求不能夠直接作為開發(fā)和測試人員工作的依據(jù)。
• 原因是需要對用戶的需求進(jìn)行分析:
• • 市場可行性(成本）
• • 技術(shù)可行性（技術(shù)上是否能實現(xiàn)，技術(shù)上實現(xiàn)死否有難度，投入的人力和時間成本是否遠(yuǎn)遠(yuǎn)大于市場收益。

2.1.2 從軟件測試人員角度看需求

需求是測試人員開展軟件測試工作的依據(jù)。（重點）

在具體設(shè)計測試用例的時候，首先需要搞清楚每一個業(yè)務(wù)需求對應(yīng)的多個軟件功能需求點，然后分析出
每個軟件功能需求點對應(yīng)的多個測試需求點，然后針對每個測試需求點設(shè)計測試用例。

過程如下，業(yè)務(wù)需求—>軟件功能需求點—>測試需求點—>測試用例

2.1.3 為什么需求對軟件測試人員如此重要？

• 測試需求點到測試用例的產(chǎn)出，都是對需求進(jìn)行分析發(fā)現(xiàn)的。
• 測試需求點關(guān)乎到測試用例的測試覆蓋率。

2.1.4 如何才可以深入理解被測試軟件的需求

• 在產(chǎn)品分析階段或設(shè)計階段開始時介入,因為軟件測試貫穿軟件的整個生命周期。
• 只有真正理解了原始業(yè)務(wù)需求之后，才有可能從業(yè)務(wù)需求的角度去設(shè)計針對性明確，從終端用戶的使用場景到端到端的覆蓋率較高的測試用例集。

2.2 bug的概念(了解)

• 當(dāng)且僅當(dāng)規(guī)格說明是存在的并且正確，程序與規(guī)格說明之間的不匹配才是錯誤。
• 當(dāng)需求規(guī)格說明書沒有提到的功能，判斷標(biāo)準(zhǔn)以最終用戶為準(zhǔn)：當(dāng)程序沒有實現(xiàn)其最終用戶合理預(yù)期的功能要求時，就是軟件錯誤.

2.3測試用例的概念

2.3.1 概念

測試用例（Test Case）是為了實施測試而向被測試的系統(tǒng)提供的一組集合，這組集合包含：測試環(huán)
境、操作步驟、測試數(shù)據(jù)、預(yù)期結(jié)果等要素。

測試用例解決了兩大問題：測什么，怎么測。

例如如下圖,編寫注冊網(wǎng)頁郵箱的測試用例:

2.3.2 為什么要設(shè)計測試用例?

兩點原因:

• 圍繞著軟件需求來設(shè)計測試用例。
• 解決了重復(fù)測試問題。- - 可以避免測試用例用后即棄。

2.4 軟件生命周期

軟件生命周期是指從軟件產(chǎn)品的設(shè)想開始到軟件不再使用而結(jié)束的時間。 如果把軟件看成是有生命的事
物，那么軟件的生命期可以分成6個階段，即需求分析、計劃、、設(shè)計、編碼、測試、運行維護(hù)。

• 需求分析 : 分析用戶需求是否合理( 市場分析,軟件需求上的技術(shù)分析) ,編寫出軟件需求文檔
• 計劃 : 指定需求執(zhí)行計劃, 即確認(rèn)需求要執(zhí)行多久,什么時候開始,什么時候結(jié)束,安排多少人力,投入成本,產(chǎn)出計劃文檔
• 設(shè)計 : 將用戶需求細(xì)化成一個個任務(wù),進(jìn)行技術(shù)設(shè)計(設(shè)計那些接口,采用那些技術(shù)).產(chǎn)出設(shè)計文檔
• 編碼 : 開發(fā)人員按照需求文檔以及設(shè)計文檔進(jìn)行編碼
• 測試 : 測試人員參考測試用例來執(zhí)行測試
• 運行維護(hù) : 項目上線之后對產(chǎn)品進(jìn)行線上的維護(hù):
• • 修復(fù)性維護(hù) : 對項目中未發(fā)現(xiàn)的問題進(jìn)行修復(fù)
• • 完善性維護(hù):對功能進(jìn)行完善
• • 預(yù)防性維護(hù)(居安思危):為了避免產(chǎn)品在線上出現(xiàn)一些其他的問題，進(jìn)行一些預(yù)防的手段

2.5 開發(fā)模型

2.5.1 瀑布模型（Waterfall Model）

特點 ：

• 線性的開發(fā)流程、不能夠應(yīng)對需求的變化

缺陷：

• 測試被后置
• • 風(fēng)險往往遲至后期的測試階段才顯露，因而失去及早糾正的機(jī)會
• • 需要有足夠的時間預(yù)留給測試活動，否則將導(dǎo)致測試不充分，從而把缺陷直接造留給用戶

主要缺陷：

• 可以運行的產(chǎn)品很遲才能被檢測。風(fēng)險往往被后至發(fā)現(xiàn)，因而失去及時糾正的機(jī)會。

使用場景：

• 需求固定的小項目。 - -

2.5.2 螺旋模型 （Spiral Model)

簡介：

• 一般在軟件開發(fā)初期階段需求不是很明確時，采用漸進(jìn)式的開發(fā)模式。螺旋模型是漸進(jìn)式開發(fā)模型的代表之一。
• 這對于那些規(guī)模龐大、復(fù)雜度高、風(fēng)險大的項目尤其適合。
• 這種迭代開發(fā)的模式給軟件測試帶來了新的要求，它不允許有一段獨立的測試時間和階段，測試必須跟隨開發(fā)的迭代而迭代。
• 因此，回歸測試的重要性就不言而喻了。

如下圖、

• 在瀑布模型基礎(chǔ)上，每個階段都給予一次風(fēng)險分析，每次分析完成之后都會生成一個新的原形。
• 例如下圖：從中心開始看，需求計劃生成原型1，風(fēng)險分析到原型2。
• 計劃需要用戶需求轉(zhuǎn)變軟件需求，開始計劃，風(fēng)險分析產(chǎn)出原型3。
• 軟件產(chǎn)品設(shè)計指軟件需求轉(zhuǎn)變接口，風(fēng)險分析產(chǎn)出原型4。
• 詳細(xì)設(shè)計包含編碼，單元測試，等等。
• 客戶評估，客戶提出新的需求，我們在按照原型4進(jìn)行迭代。

螺旋模型的使用場景：

• 規(guī)模龐大，軟件復(fù)雜度高，風(fēng)險大的項目。

缺陷：

• 時間拉長，人力，資金。
• 風(fēng)險分析能力與產(chǎn)品遺留的風(fēng)險成正比。- - 需要有專業(yè)的風(fēng)險分析的人，成本增高。

2.5.3 增量、迭代模型

注意事項：

• 需要區(qū)分增量模型和迭代模型。

簡介：

• 增量開發(fā)能顯著降低項目風(fēng)險，結(jié)合軟件持續(xù)構(gòu)建機(jī)制，構(gòu)成了當(dāng)今流行的軟件工程最佳實踐之一。
• 增量開發(fā)模型，鼓勵用戶反饋，在每個迭代過程中，促使開發(fā)小組以一種循環(huán)的、可預(yù)測的方式驅(qū)動產(chǎn)品的開發(fā)。
• 因此，在這種開發(fā)模式下，每一次的迭代都意味著可能有需求的更改、構(gòu)建出新的可執(zhí)行軟件版本，意味著測試需要頻繁進(jìn)行，測試人員需要與開發(fā)人員更加緊密地協(xié)作。
• 增量通常和迭代混為一談，但是其實兩者是有區(qū)別的。
• 增量是逐塊建造的概念，例如畫一幅人物畫，我們可以先畫人的頭部，再畫身體，再畫手腳……而迭代是反復(fù)求精的概念，同樣是畫人物畫，我們可以采用先畫整體輪廓，再勾勒出基本雛形，再細(xì)化、著色。

詳細(xì)講解：

• 如下圖、假設(shè)用戶有一個需求，功能包含ABCD…
• 增量模型完成的流程:
• • 開發(fā)完A我就直接上線提供給用戶使用
• • 開發(fā)完B我就直接上線提供給用戶使用
• • 開發(fā)完C我就直接上線提供給用戶使用
• 迭代模型完成的流程:
• • 先開發(fā)一個基礎(chǔ)版本(包含共A,B,C,D),但是ABCD功能比較簡陋。
• • 接下我們會繼續(xù)在基礎(chǔ)版本上對比功能進(jìn)行迭代優(yōu)化。
• 生活例子理解：一個人物畫
• • 增量模型：
• • • 先畫頭、在畫身體、再畫四肢
• • • 逐漸建造
• • 迭代模型：
• • • 先畫一個輪廓、在細(xì)化、再補色…
      

2.5.4 迭代式開發(fā)和瀑布模型的區(qū)別

• 瀑布模型是完成一個階段才到下一個，如果出現(xiàn)測試問題需要回到上階段進(jìn)行修改。
• 增量式開發(fā)基礎(chǔ)了瀑布模型，將軟件的生命周期劃分為多個階段，每個階段都會完成所有的階段。
• 每輪迭代結(jié)束后，開始新一輪迭代，直到軟件項目被終止，整個生命周期才會結(jié)束，其核心思想是，每次只完成軟件中最迫切需要的一部分功能，并且隨時關(guān)注用戶的反饋信息。
• 它彌補了傳統(tǒng)開發(fā)方式中的一些缺點，具有更高的成功率和生產(chǎn)率。

2.5.4 敏捷模型

簡介:

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人為首的“輕量”過程派聚集在猶他州的Snowbird，決定把“敏捷”(Agile)作為新的過程家族的名稱。

在會議上，他們提出了《敏捷宣言》（http://agilemanifesto.org/）： 我們通過身體力行和幫助他人來
揭示更好的軟件開發(fā)方式。

經(jīng)由這項工怍，我們形成了如下價值觀:

• 個體與交互重于過程和工具 解釋: 輕流程,強調(diào)人與人之間面對面的高效溝通.
• 可用的軟件重于完備的文檔 解釋: 輕文檔,重產(chǎn)出.
• 客戶協(xié)作重于合同談判 解釋: 多于用戶溝通
• 響應(yīng)變化重于遵循計劃 解釋: 用戶需求可能發(fā)生變化,需要我們能快速變化.
• 在每對比對中，后者并非全無價值，但我們更看重前者。

四局宣言表達(dá)敏捷模型的一個特點:輕流程,輕文檔,重目標(biāo),重產(chǎn)出.

由敏捷宣言可以看出，敏捷其實是有關(guān)軟件開發(fā)的社會工程(Social Engineering)的。敏捷的主要貢獻(xiàn)在于他更多地思考了如何去激發(fā)開發(fā)人員的工作熱情，這是在軟件工程幾十年的發(fā)展過程中相對被忽略的領(lǐng)域。
敏捷開發(fā)有很多種方式，其中scrum是比較流行的一種。

2.5.4.1 scrum 敏捷模型

三個角色和五個會議。

三個角色：

• 產(chǎn)品經(jīng)理： 收集用戶的需求，編寫需求文檔，對產(chǎn)品負(fù)責(zé)的人。
• 項目經(jīng)理：負(fù)責(zé)召開各種會議，協(xié)調(diào)項目，為研發(fā)團(tuán)隊服務(wù)。催工.
• 研發(fā)團(tuán)隊：開發(fā)人員，測試人員，ui設(shè)計人員等等。

五個會議：

product Backlog : 需求代辦列表 （需求池）
Sprint Backlog : 周期內(nèi)需要實現(xiàn)的用戶需求.
daily scrum meeting : 每日會議

Potentially Shippable Product Increment : 可交付的軟件

scrum的基本流程如上圖所示：

• 產(chǎn)品負(fù)責(zé)人負(fù)責(zé)整理user story，形成左側(cè)的product backlog。產(chǎn)品經(jīng)理從需求池里選取幾個需求，開展發(fā)布計劃會議。
• 發(fā)布計劃會議：product owner負(fù)責(zé)講解user story，對其進(jìn)行估算和排序，發(fā)布計劃會議的產(chǎn)出就是制定出這一期迭代要完成的story列表，sprint backlog。
• 迭代計劃會議：項目團(tuán)隊對每一個story進(jìn)行任務(wù)分解，分解的標(biāo)準(zhǔn)是完成該story的所有任務(wù)，每個任務(wù)都有明確的負(fù)責(zé)人，并完成工時的初估計。
• 每日例會：每天scrum master召集站立會議，團(tuán)隊成員回答昨天做了什么今天計劃做什么，有什么問題。即使了解項目進(jìn)度，預(yù)知風(fēng)險，規(guī)避風(fēng)險。
• 產(chǎn)出物: 可交付的軟件。過了一段時間有產(chǎn)出了。
• 演示會議：迭代結(jié)束之后，召開演示會議，相關(guān)人員都受邀參加，團(tuán)隊負(fù)責(zé)向大家展示本次迭代取得的成果。期間大家的反饋記錄下來，由po整理，形成新的story。將新的需求放到需求池了。
• 回顧會議：項目團(tuán)隊對本期迭代進(jìn)行總結(jié)，發(fā)現(xiàn)不足，制定改進(jìn)計劃，下一次迭代繼續(xù)改進(jìn)，已達(dá)到持續(xù)改進(jìn)的效果。

具體案例：

2.5.5 V模型

V模型最早是由Paul Rook在２０世紀(jì)８０年代后期提出的，目的是改進(jìn)軟件開發(fā)的效率和效果。是瀑布模型的變種：

明確的標(biāo)注了測試過程中存在的不同類型的測試，并且清楚的描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系

V模型指出，單元和集成測試應(yīng)檢測程序的執(zhí)行是否滿足軟件設(shè)計的要求；系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo)；驗收測試確定軟件的實現(xiàn)是否滿足用戶需要或合同的要求。

人話將就是，V模型是基于瀑布式開發(fā)模型的，相比瀑布模型，V模型在各階段都給予針對性的測試，例如用戶需求對應(yīng)驗收測試，詳細(xì)設(shè)計對應(yīng)單元測試。

局限性:僅僅把測試作為在編碼之后的一個階段，未在需求階段就進(jìn)入測試。

特點：

• 明確標(biāo)注了測試的類型
• 明確標(biāo)注了測試階段和開發(fā)階段之間的對應(yīng)關(guān)系

缺點：

• 測試后置，未能在需求階段就進(jìn)入測試。

2.5.6 W模型

如上圖，有兩個v模型，對應(yīng)著開發(fā)模型和測試模型。測試從需求開始階段就介入了，用戶需求階段，需要開始準(zhǔn)備驗收測試，用戶需求階段到下一個階段需求分析與系統(tǒng)設(shè)計，需要開始準(zhǔn)備系統(tǒng)測試，一直到編碼階段到測試階段，測試階段順序，
單元測試由開發(fā)人員編寫，開發(fā)人員編寫完集成后集成測試開始，實施后到系統(tǒng)測試，交付階段后驗收測試。

W模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗證和確認(rèn)活動。W模型由兩個V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關(guān)系。

W模型特點：測試的對象不僅是程序，需求、設(shè)計等同樣要測試，測試與開發(fā)是同步進(jìn)行的

W模型優(yōu)點：有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后，測試人員就應(yīng)該參與到對需求的驗證和確認(rèn)活動中，以盡早地找出陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風(fēng)險，及早制定應(yīng)對措施，顯著減少總體測試時間，加快項目進(jìn)度。

局限性：需求、設(shè)計、編碼等活動被視為串行的；測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個階段工作。無法支持敏捷開發(fā)模式。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W模型并不能解除測試管理面臨著困惑。

優(yōu)點：

• 測試從需求開始階段就介入了。

缺點：

• 上一個階段完成下一個階段才能開始。例如：用戶需求階段完成后到需求分析與系統(tǒng)設(shè)計階段。
• 開發(fā)模型和測試模型也保持著一種前后的線性關(guān)系。例如：用戶需求完成后，驗收測試準(zhǔn)備才能開始。
• 重文檔，重過程 - -不支持敏捷模式。

v模型與w模型的區(qū)別：

• W模型中則更強調(diào)測試在整個開發(fā)流程中的重要性，每個階段都有對應(yīng)的測試階段，以減少后期修復(fù)問題的成本。

• 總的來說，V模型相對比較傳統(tǒng)，側(cè)重于階段的順序和階段中的測試，適用于需求已經(jīng)明確，較為穩(wěn)定的項目；而W模型更加靈活，強調(diào)測試在整個開發(fā)過程中的重要性，適用于需求不穩(wěn)定或需求變更頻繁的項目。文章來源地址http://www.zghlxwxcb.cn/news/detail-477047.html

到了這里，關(guān)于1 軟件測試基本概念的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！