一、軟件測試背景

引言：
軟件測試在軟件生命周期中占據(jù)重要的地位，軟件測試慢慢的獨立發(fā)展成為一個行業(yè)，并且在迅猛發(fā)展。

1. 軟件缺陷與軟件故障

1.1 軟件缺陷與軟件故障案例

1. 美國迪斯尼公司的獅子王游戲軟件BUG
2. 火星登陸事故
3. 跨世紀“千年蟲”問題
4. 2018年拼多多
5. 2014年12306

6. 其他一些例子

   
   
   BUG.png

1.2 軟件缺陷的定義

對于軟件缺陷的精確定義，通常有下列5條描述：

1. 軟件未達到產(chǎn)品說明書的功能 《需求文檔》
2. 軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤
3. 軟件功能超出產(chǎn)品說明書指明范圍
4. 軟件未達到產(chǎn)品說明書雖未指出但應(yīng)達到的目標
5. 軟件測試員認為難以理解、不易使用、運行速度緩慢、或者最終用戶認為不好

1.3 軟件缺陷的特征

1. 軟件的特殊性決定了缺陷不易看到,即“看不到”；
2. 發(fā)現(xiàn)了缺陷,但不易找到問題發(fā)生的原因所在,即“看到但是抓不到”。

思考：

1. 如果你碰到不能復(fù)現(xiàn)的bug你改怎么辦？
2. 測試流程？

2. 軟件缺陷產(chǎn)生的原因

軟件缺陷從哪來？第一大原因就是軟件產(chǎn)品規(guī)格說明書，很多情況下，說明書沒有寫，或?qū)懙牟粔蛉?，?jīng)常更改，或者開發(fā)小組沒有很好的溝通，造成對說明書理解的不一致。第二大原因是軟件設(shè)計，沒有做設(shè)計或設(shè)計不好，經(jīng)常變動等和產(chǎn)品規(guī)格說明書一樣的問題，第三個原因才是編寫代碼和其它原因；前兩個原因至少占了 80%以上。如圖1-1所示

軟件缺陷產(chǎn)生的原因分布.png

通過大量的測試理論研究及測試實踐經(jīng)驗的積累，典型的軟件缺陷產(chǎn)生的原因被歸納為以下幾種類型：
(1)需求解釋有錯誤；
(2)用戶需求定義錯誤；
(3)需求記錄錯誤；
(4)設(shè)計說明有誤；
(5)編碼說明有誤；
(6)程序代碼有誤；
(7)數(shù)據(jù)輸入有誤；
(8)測試錯誤；
(9)問題修改不正確；
(10)不正確的結(jié)果是由于其他的缺陷而產(chǎn)生。

3. 軟件測試和缺陷修復(fù)的代價

缺陷發(fā)現(xiàn)的越早，則修復(fù)這個缺陷的代價就越小，在需求、設(shè)計、編碼、測試、發(fā)布等不同的階段，發(fā)現(xiàn)缺陷后修復(fù)的代價都會比在前一個階段修復(fù)的代價提高10倍（參見圖1-2）。

軟件測試和缺陷修復(fù)的代價.png

二、軟件測試基礎(chǔ)理論

引言：
軟件測試是保證軟件質(zhì)量的一種手段，那么，什么叫軟件測試？

1. 軟件測試定定義

1.1 狹義

“程序測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程”。這個定義，被業(yè)界所認可，經(jīng)常被引用。

1.2 廣義

為了更早地發(fā)現(xiàn)問題，所以將測試延伸到需求評審、設(shè)計審查活動中去，也就是將“軟件質(zhì)量保證”的部分活動歸為測試活動。實際上，在軟件開發(fā)實際操作中，常常將軟件測試和質(zhì)量保證——這兩種努力（efforts）合并起來。延伸后的軟件測試，被認為是一種軟件測試的廣義概念。

1.3 軟件測試的定義

軟件測試是貫穿整個軟件開發(fā)生命周期、對軟件產(chǎn)品（包括階段性產(chǎn)品）進行驗證和確認的活動過程，其目的是盡快盡早地發(fā)現(xiàn)在軟件產(chǎn)品中所存在的各種問題——與用戶需求、預(yù)先定義的不一致性。

2. 軟件測試的現(xiàn)狀

現(xiàn)狀：初期、不成熟、浮躁
公司越來越注重，開發(fā)與測試比例越來越接近
越來越緊缺-跳槽，待遇
畢業(yè)生、想轉(zhuǎn)行
導(dǎo)致浮躁、但真正靜下心來學(xué)習(xí)的不多
基礎(chǔ)知識不扎實：知道基本方法但不深入理解
專業(yè)技術(shù)不夠精通：寫著精通某某工具，實際上只會皮毛
沒有建立器相對完整的測試體系概念：對自己的工作職責(zé)理解不到位
在中國必然會經(jīng)過一個不成熟的階段，但最終會趨于平靜，平穩(wěn)的發(fā)展階段。

3.軟件測試的前景

軟件測試的前景.png

4.新人如何融入一個項目團隊

image.png

5.優(yōu)秀的測試人員的基本素質(zhì)

image.png

1. 參與需求討論，制訂測試計劃，確保測試能順利執(zhí)行并完成；
2. 負責(zé)項目的功能性測試、用戶體驗測試、兼容性測試以及性能測試 ；
3. 負責(zé)測試用例的編寫；編寫測試報告和對測試結(jié)果分析；
4. 與開發(fā)人員、產(chǎn)品經(jīng)理溝通和協(xié)作，推動整個項目的順利進行；
5. 負責(zé)軟件開發(fā)團隊項目進度管理工作；
6. 熟悉Linux常用命令，熟悉常用數(shù)據(jù)庫，熟練使用基本的SQL語句；
7. 熟練使用Loadrunner，Jmeter等至少一種性能測試工具。

6. 軟件工程的目的

成本：項目的開銷，人工成本，工具成本，設(shè)備成本，錯誤成本（BUG）
進度：時間，計劃
質(zhì)量：軟件對顧客需求的滿意程度，一個低質(zhì)量的軟件，即使生產(chǎn)成本很低，進度控制良好，顧客也難以接受。

image.png

7. 程序測試包含哪些內(nèi)容

程序測試包括程序邏輯功能，界面，性能，易用性，兼容性，安裝等測試，當(dāng)然文檔測試也算，排版，字體大小，也算程序測試的內(nèi)容

8. 測試環(huán)境

測試環(huán)境=硬件+軟件+網(wǎng)絡(luò)
硬件環(huán)境：pc機還是筆記本
軟件環(huán)境：不同的操作系統(tǒng)windows10 windows8 windows7 Linux Mac ，
不同瀏覽器firefox chrom
網(wǎng)絡(luò):局域網(wǎng)還是互聯(lián)網(wǎng)

image.png

[圖片上傳中...(image.png-1baa66-1609385241854-0)]

9. 測試流程

需求評審 → 測試計劃制定 → 測試計劃執(zhí)行 → 發(fā)布與測試報告總結(jié)

image.png

三、軟件測試分類

image.png

1.黑盒測試和白盒測試

黑盒測試(Black Box -Test)：把被測試的軟件看做一個黑盒子，我們不去關(guān)心盒子里邊的結(jié)構(gòu)是什么樣子，只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果
有人把黑盒測試比作中醫(yī)，通過“望聞問切”來判斷是否有問題。
“望”：觀察軟件的行為是否正常。
“聞”：檢查輸出的結(jié)果是否正確。
“問”：輸入各種信息，結(jié)合“望”，“聞”來觀察軟件的響應(yīng)。
“切”：像中醫(yī)一樣給軟件“把把脈”，敲擊一下軟件的某些“關(guān)節(jié)”

白盒測試(White Box Testing),指的是把盒子蓋打開，去研究里邊源代碼和程序結(jié)構(gòu)。

image.png

2.靜態(tài)測試和動態(tài)測試

靜態(tài)測試：不實際運行被測試軟件，而只是靜態(tài)的檢查程序代碼、界面或者文檔中可能存在的錯誤的過程。
動態(tài)測試：是指實際運行被測程序，輸入相應(yīng)的測試數(shù)據(jù)，檢查實際輸出結(jié)果和預(yù)期結(jié)果是否相符的過程。

3.功能測試和性能測試

3.1.功能測試

功能測試：是黑盒測試的一部分，它檢查實際軟件的功能是否符合用戶的需求。
功能測試可以細分邏輯功能測試、界面測試、易用性測試、安裝測試和兼容性測試。
邏輯功能測試:測試應(yīng)用是否符合邏輯，比如應(yīng)該先注冊賬號之后，才能進行登錄,登錄之后才能看我的購物車
界面測試:窗口大小，按鈕大小，點擊按鈕彈出什么樣的提示框，是否有滾動條，下拉菜單是否有展示內(nèi)容...
易用性測試:從軟件使用的合理性和方便性等角度對軟件系統(tǒng)進行檢查,比如，軟件窗口長寬比例是否合適，顏色色彩是否賞心悅目，字體大小是否合適
安裝測試:

image.png

3.2.性能測試

時間性能:軟件的一個具體事務(wù)的響應(yīng)時間。比如點擊一個登陸按鈕，到登錄成功(失敗)的反應(yīng)時間，瀏覽器非常常見，ANR（Application not responding 應(yīng)用程序無響應(yīng)）
空間性能:軟件運行時所消耗的系統(tǒng)資源，比如對內(nèi)存和cpu的消耗
一般性能測試:軟件正常運行，不向其施加任何壓力的測試
穩(wěn)定性測試:也叫可靠性測試，是指連續(xù)運行被測系統(tǒng)，檢查系統(tǒng)運行時的穩(wěn)定成都。
負載測試:讓被測系統(tǒng)在其能夠忍受的壓力范圍之內(nèi)連續(xù)運行，來測試系統(tǒng)的穩(wěn)定性。（測試載重）
壓力測試:持續(xù)不斷的給被測試的系統(tǒng)增加壓力，直到被測試的系統(tǒng)壓垮為止，用來測試系統(tǒng)所承受的最大壓力。（測試強度）

image.png

image.png

4.回歸測試、冒煙測試、隨機測試

4.1.回歸測試

是指對軟件的新版本進行測試時，重復(fù)執(zhí)行上一個版本測試時的用例，比如在1.0版本中，有一個bug，到了2.0版本中,再重新測試1.0中這個bug

4.2.冒煙測試

指對一個軟件進行系統(tǒng)大規(guī)模的測試之前，先驗證一下軟件的基本功能是否實現(xiàn)，是否具備可測性。

測試小組在正式測試一個新版本之前，先指派一兩個測試人員測試一下軟件的主要功能，如果沒有實現(xiàn)，則打回開發(fā)組重新開發(fā)，這樣做可以節(jié)省大量的時間成本和人力成本。

4.3.隨機測試

是指測試中所有的輸入數(shù)據(jù)都是隨機生成的，其目的是模擬用戶的真實操作，并發(fā)現(xiàn)一些邊緣性的錯誤。

5.單元測試、集成測試、系統(tǒng)測試和驗收測試

image.png

5.1.單元測試

單元測試（unit testing），是指對軟件中的最小可測試單元進行檢查和驗證。對于單元測試中單元的含義，一般來說，要根據(jù)實際情況去判定其具體含義，如C語言中單元指一個函數(shù)，Java里單元指一個類，圖形化的軟件中可以指一個窗口或一個菜單等。
總的來說，單元就是人為規(guī)定的最小的被測功能模塊。
單元測試當(dāng)一段代碼完成之后，是由白盒測試工程師或者開發(fā)人員自行測試，比如java中執(zhí)行單元測試叫做junit測試。
目前大部分公司單元測試由開發(fā)人員簡單編譯和調(diào)試一下自己的程序，沒有相應(yīng)的單元測試計劃。
單元測試方式:先靜態(tài)地觀察代碼是否符合規(guī)范，然后動態(tài)地運行一下代碼,檢查運行的結(jié)果。
例如：模塊接口測試

• 應(yīng)對通過所測模塊的數(shù)據(jù)流進行測試
• 調(diào)用所測模塊時的輸入?yún)?shù)與模塊的形式參數(shù)的個數(shù)、屬性和順序是否匹配
• 所測模塊調(diào)用子模塊時，輸入子模塊的參數(shù)與子模塊的形式參數(shù)在個數(shù)、屬性和順序上是否匹配。
• 輸出給標準函數(shù)的參數(shù)的個數(shù)、屬性和順序是否正確。
• 全局變量的定義在各個模塊中是否一致。
• 當(dāng)模塊通過外部設(shè)備進行輸入/輸出操作，文件屬性是否正確、open和close語句是否正確，規(guī)定的I/O格式說明與I/O語句是否匹配；緩沖區(qū)容量是否與記錄長度匹配，在讀寫之前是否打開了文件，讀寫之后是否關(guān)閉了文件，對I/O錯誤是否做了處理。

驅(qū)動模塊：相當(dāng)于所測模塊的主程序，它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給所測模塊，最后再輸出實際結(jié)果

樁模塊：用以代替所測模塊調(diào)用的子模塊。

5.2.集成測試

集成測試是單元測試的下一個階段，是指將通過測試單元模塊組裝成系統(tǒng)或者子系統(tǒng)，再進行測試，重點測試不同模塊的接口部分。

• 在把各個模塊連接起來的時候，穿越各個模塊的接口的數(shù)據(jù)時候會丟失
• 一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響
• 各個子功能組裝完成后，能否達到預(yù)期的父功能
• 全局數(shù)據(jù)結(jié)構(gòu)是否有問題
• 單個模塊產(chǎn)生的誤差累計起來是否會放大

5.3.系統(tǒng)測試和驗收測試

集成測試完成之后，就是系統(tǒng)測試和驗收測試。
系統(tǒng)測試：指的是將整個軟件系統(tǒng)看做一個1個整體進行測試，包括對功能、性能，以及軟件所運行的軟硬件環(huán)境進行測試。
系統(tǒng)測試：由黑盒測試人員在整個系統(tǒng)集成完畢后進行測試，前期主要測試系統(tǒng)的功能是否滿足需求，后期主要測試系統(tǒng)運行的性能是否滿足需求，以及系統(tǒng)在不同的軟硬件環(huán)境的兼容性等。

image.png

6.測試案例

image.png

6.1.需求：

測試一個帶廣告圖案的花紙杯

6.2.功能測試

能否裝水，
除了裝水， 能否裝其他液體。比如可樂，酒精
能裝多少ML的水
杯子是否有刻度表
杯子能否泡茶，跑咖啡
杯子是否能放冰箱，做冰塊
杯子的材質(zhì)是什么（玻璃，塑料,黃金做的）

6.3.界面測試

外觀好不好看。
什么顏色
杯子的形狀是怎么樣的。
杯子的重量是多少
杯子的圖案是否合理

6.4.性能測試

能否裝100度的開水 (泡茶)
能否裝0度冰水
裝滿水，放幾天后，是否會漏水
杯子內(nèi)壁上的涂料是否容易脫落。
杯子上的顏色是否容易褪色或者脫落
風(fēng)吹是否會倒，摔一次是否會摔壞，摔多次是否會摔壞

6.5.安全性測試

制作杯子的材料，是否有毒
放微波爐里轉(zhuǎn)的時候，是否會熔化。
從桌子上掉到水泥地上是否會摔碎。
杯子是否容易長細菌
杯子內(nèi)壁上的材料，是否會溶解到水中
裝進不同液體，是否會有化學(xué)反應(yīng)。

6.6.易用性測試

杯子是否容易燙手
杯子是否好端，好拿
杯子的水是否容易喝到
杯子是否有防滑措施
是否能接受杯子的廣告內(nèi)容與圖案

四、測試分類占比

image.png

五、軟件測試七大原則

1. 測試顯示軟件存在缺陷

測試只能證明軟件中存在缺陷，但并不能證明軟件中不存在缺陷。軟件測試是為了降低存在缺陷的可能性，即便是沒有找到缺陷，也不能證明軟件是完美的。

1. 窮盡測試是不可能的

現(xiàn)在軟件的規(guī)模越來越大，復(fù)雜度越來越高，想做到完全性的測試是不可能的。在測試階段，測試人員可以根據(jù)風(fēng)險和優(yōu)先級來進行集中和高強度的測試，從而保證軟件的質(zhì)量。

3.測試盡早介入

為什么測試要盡早介入呢，簡單的說就是保證軟件質(zhì)量，降低風(fēng)險和成本。測試人員一般在需求階段就開始介入，使缺陷在需求或設(shè)計階段就被發(fā)現(xiàn)，缺陷發(fā)現(xiàn)越早，修復(fù)的成本就越小。

4. 缺陷集群性（2/8原則）

• 缺陷集群性表明小部分模塊包含大部分的缺陷。軟件測試中存在Pareto原則：80%的缺陷發(fā)現(xiàn)在20%的模塊中。
• 一個功能模塊發(fā)現(xiàn)的缺陷越高，那存在的未被發(fā)現(xiàn)的缺陷也越高，故發(fā)現(xiàn)的缺陷與未發(fā)現(xiàn)的缺陷成正比。

5. 殺蟲劑悖論

• 反復(fù)使用相同的殺蟲劑會導(dǎo)致害蟲對殺蟲劑產(chǎn)生免疫而無法殺死害蟲。軟件測試也一樣。如果一直使用相同的測試方法或手段，可能無法發(fā)現(xiàn)新的bug。
• 為了解決這個問題，測試用例應(yīng)當(dāng)定期修訂和評審，增加新的或不同的測試用例幫助發(fā)現(xiàn)更多的缺陷。
• 測試人員不能一直依賴于現(xiàn)有的測試技術(shù)，而要不斷的提升測試方法以提高測試效率。

6. 測試活動依賴于測試內(nèi)容

根據(jù)業(yè)務(wù)的不同，軟件測試內(nèi)部也分為不同的行業(yè)，比如游戲行業(yè)、電商行業(yè)、金融行業(yè)。不同的行業(yè)，測試活動的開展都有所不同，比如測試技術(shù)、測試工具的選擇，測試流程都不盡相同，所以軟件測試的活動開展依賴于所測試的內(nèi)容。

7. 沒有錯誤是好是謬論

有可能99%沒有bug的軟件也是不能使用的。如果對錯誤的需求進行了徹底的測試，這種情況就發(fā)生了。軟件測試不僅是找出缺陷，同時也需要確認軟件是否滿足需求。如果開發(fā)出來的產(chǎn)品不滿足用戶的需求，即便找到和修復(fù)了缺陷也作用不大。

注意：

1. 應(yīng)當(dāng)把“盡早和不斷地測試”作為開發(fā)者的座右銘。
2. 設(shè)計測試用例時，應(yīng)該考慮到合法的輸入和不合法的輸入，以及各種邊界條件，特殊情況下要制造極端狀態(tài)和意外狀態(tài)，比如網(wǎng)絡(luò)異常中斷、電源斷電等情況。
3. 一定要注意測試中的錯誤集中發(fā)生現(xiàn)象，這和程序員的編程水平和習(xí)慣有很大的關(guān)系。
4. 對測試錯誤結(jié)果一定要有一個確認的過程。一般有A測試出來的錯誤，一定要有一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。
5. 制定嚴格的測試計劃，并把測試時間安排得盡量寬松，不要希望在極短的時間內(nèi)完成一個高水平的測試。
6. 回歸測試的關(guān)聯(lián)性一定要引起充分的注意，修改一個錯誤而引起更多錯誤出現(xiàn)的現(xiàn)象并不少見。
7. 妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現(xiàn)性往往要靠測試文檔。

六、軟件的開發(fā)模式

1. 線性模型與漸進式模型

線性模型：最常見的“瀑布模型”，基礎(chǔ)框架，但缺點在于“集成之日就是爆炸之日”。（立項分析-需求分析-設(shè)計-編碼-測試-維護）很多企業(yè)使用后使用迭代進行修改。
漸進式模型：最常見的“螺旋模型”，（需求分析-風(fēng)險分析-設(shè)計、編碼-測試、評審），迭代開發(fā)和增量開發(fā)模式。
注意：每一次迭代原型出來后，測試人員都需要從原型界面，系統(tǒng)主要功能，性能等方面對原型進行評審。

2. 迭代和增量的理解

image.png

image.png

七、 軟件生命周期模型

軟件生命周期同任何事物一樣，一個軟件產(chǎn)品或軟件系統(tǒng)也要經(jīng)歷孕育、誕生、成長、成熟、衰亡等階段，一般稱為軟件生命周期（軟件生存周期） 。軟件生命周期模型是指人們?yōu)殚_發(fā)更好的軟件而歸納總結(jié)的軟件生命周期的典型實踐參考。

image.png

1.邊做邊改模型

許多產(chǎn)品都是使用“邊做邊改”模型來開發(fā)的。在這種模型中，既沒有規(guī)格說明，也沒有經(jīng)過設(shè)計，軟件隨著客戶的需要一次又一次地不斷被修改。

image.png

在這個模型中，開發(fā)人員拿到項目立即根據(jù)需求編寫程序，調(diào)試通過后生成軟件的第一個版本。在提供給用戶使用后，如果程序出現(xiàn)錯誤，或者用戶提出新的要求，開發(fā)人員重新修改代碼，直到用戶滿意為止。
這是一種類似作坊的開發(fā)方式，對編寫幾百行的小程序來說還不錯，但這種方法對任何規(guī)模的開發(fā)來說都是不能令人滿意的，其主要問題在于：
（1） 缺少規(guī)劃和設(shè)計環(huán)節(jié)，軟件的結(jié)構(gòu)隨著不斷的修改越來越糟，導(dǎo)致無法繼續(xù)修改；
（2） 忽略需求環(huán)節(jié)，給軟件開發(fā)帶來很大的風(fēng)險；
（3） 沒有考慮測試和程序的可維護性，也沒有任何文檔，軟件的維護十分困難。

2.瀑布模型

瀑布模型是最早出現(xiàn)的軟件開發(fā)模型，在軟件工程中占有重要的地位，它提供了軟件開發(fā)的基本框架。其過程是從上一項活動接收該項活動的工作對象作為輸入，利用這一輸入實施該項活動應(yīng)完成的內(nèi)容給出該項活動的工作成果，并作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續(xù)下一項活動；否則返回前面，甚至更前面的活動。對于經(jīng)常變化的項目而言，瀑布模型毫無價值。

image.png

瀑布型簡單地說就是按照需求、設(shè)計、編碼、測試、軟件維護這個基本的順序來研發(fā)軟件，前面一個步驟不完成，后面的步驟不能開始，否則問題會滾到下個階段，帶來更多的問題
優(yōu)點：

• 為項目提供了按階段劃分的檢查點
• 當(dāng)前一階段完成后，只需要去關(guān)注后續(xù)階段。
  缺點：
• 各個階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量。
• 由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果，從而增加了開發(fā)風(fēng)險。
• 通過過多的強制完成日期和里程碑來跟蹤各個項目階段。
• 瀑布模型的突出缺點是不適應(yīng)用戶需求的變化。

3. 原型化模型

原型化模型的第一步是建造一個快速原型，實現(xiàn)客戶或未來的用戶與系統(tǒng)的交互，經(jīng)過和用戶針對原型的討論和交流，弄清需求以便真正把握用戶需要的軟件產(chǎn)品是什么樣子的。充分了解后，再在原型基礎(chǔ)上開發(fā)出用戶滿意的產(chǎn)品。
如圖所示：原型嚴格來說不算一種軟件生命周期模型，它只是一種獲取需求的方法，在實際工作中該方法是相當(dāng)重要的方法。

image.png

模型要點：瀑布和原型模型相結(jié)合，強調(diào)版本升級。
該模式的特點是一次性地獲取全部的需求，然后做出分版本實現(xiàn)各需求的計劃，每個版本只實現(xiàn)一部分需求，通過多個版本逐步實現(xiàn)全部需求，而每個版本可以認為是一個“小瀑布”。
該模型的好處是可以盡快讓系統(tǒng)上線，讓客戶先使用部分功能，盡早實現(xiàn)系統(tǒng)的價值。
該模型比較能符合實際的情況，我們往往也是通過多個版本來逐步實現(xiàn)全部需求，但需求是不可能在一開始就完全確定的，實際情況是往往只能確定80%，而后期通過各版本我們還會獲取更多的新需求以及需求調(diào)整。將此模型稍微調(diào)整后，可以適用于大部分的實際項目。

4. 增量模型

增量模型也是原型化開發(fā)方法。如圖所示

image.png

5. 螺旋模型

螺旋模型是一個演化軟件過程模型，將原型實現(xiàn)的迭代特征與線性順序（瀑布）模型中控制的和系統(tǒng)化的方面結(jié)合起來。使得軟件的增量版本的快速開發(fā)成為可能。在螺旋模型中，軟件開發(fā)是一系列的增量發(fā)布。螺旋模型的整個開發(fā)過程如圖所示。

image.png

圖中的螺旋線代表隨著時間推進的工作進展；開發(fā)過程具有周期性重復(fù)的螺旋線形狀。4個象限分別標志每個周期所劃分的4 個階段：制定計劃、風(fēng)險分析、實施工程和客戶評估。螺旋模型要點：統(tǒng)一了瀑布模型與原型模型，與增量模型相似，更強調(diào)風(fēng)險分析。

1. 軟件分多個版本開發(fā)，每個版本就是一次螺旋。
2. 每個版本按照這樣的順序進行：
   1）確定軟件目標，選取定實施方案，弄清項目開發(fā)的限制條件；（圖中左上象限）
   2）分析所選取方案，考慮如何識別和消除風(fēng)險；（圖中右上象限）
   3）實施軟件開發(fā)；（圖中右下象限）
   4）評價開發(fā)工作，提出修正建議，調(diào)整計劃。（圖中右下象限、左下象限）
   3.需求不是一次獲取和實現(xiàn)的，通過多個螺旋來完善。
   4.計劃也不是一次成型的，每次螺旋都需要調(diào)整。

優(yōu)點：
1）設(shè)計上很靈活，可以在項目的各個階段進行變更；
2）以小的分段來構(gòu)建大型系統(tǒng)，使成本計算變得簡單容易；(國企項目)
3）客戶始終參與每個階段的開發(fā)，保證了項目不偏離正確方向以及項目的可控性；
4）隨著項目推進，客戶始終掌握項目的最新信息 , 從而能夠和管理層有效地交互；
5）客戶認可這種公司內(nèi)部的開發(fā)方式帶來的良好的溝通和高質(zhì)量的產(chǎn)品。
缺點：
螺旋模型強調(diào)風(fēng)險分析，但要求許多客戶接受和相信這種分析，并做出相關(guān)反應(yīng)是不容易的。
因此，這種模型往往適應(yīng)于內(nèi)部的大規(guī)模軟件開發(fā)。該模型建設(shè)周期長，而軟件技術(shù)發(fā)展比較快，所以經(jīng)常出現(xiàn)軟件開發(fā)完畢后，和當(dāng)前的技術(shù)水平有了較大的差距，無法滿足當(dāng)前用戶需求。

6.Ｖ模型

V 模型的左邊下降的是開發(fā)過程各階段，與此相對應(yīng)的是右邊上升的部分，即各測試過程的各個階段。
V 模型的優(yōu)點在于它非常明確地標明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)各階段的對應(yīng)關(guān)系。

V模型

1、需求分析階段對應(yīng)生成需求規(guī)格說明書，對應(yīng)測試生成系統(tǒng)測試方案，即為系統(tǒng)測試準備的，該階段已經(jīng)完成了單元測試和集成測試，主要是對軟件產(chǎn)品的功能與非功能進行測試，幾乎不測試代碼，所以測試方法以黑盒為主；
2、概要設(shè)計階段對應(yīng)生成概要設(shè)計說明書，對應(yīng)測試生成集成測試方案，該階段已完成單元測試，是將各個功能模塊組裝起來進行的測試，所以也叫組裝測試。主要看模塊調(diào)用是否正常，接口是否可用，數(shù)據(jù)傳輸是否正確等，所以用到的測試方法幾乎是白盒的方法，如路徑覆蓋，條件組合覆蓋等；
3、詳細設(shè)計階段對應(yīng)生成詳細設(shè)計說明書，對應(yīng)測試生成單元測試方案，該階段是開發(fā)人員編碼后的第一個測試階段，是對開發(fā)出來的單獨模塊進行測試，以確保每一個功能模塊的功能正常，可以構(gòu)建樁模塊和驅(qū)動模塊來回調(diào)用，方法也是以白盒為主。
4、白盒測試的準則是盡可能覆蓋程序內(nèi)部的邏輯結(jié)構(gòu)，黑盒則是盡可能覆蓋所有的輸入輸出接口，包括文檔等一些靜態(tài)的測試。除常用的測試方法外，仍需補充大范圍的隨機測試，盡可能達到覆蓋率100%。

• V模型的缺陷及解決思路
  V模型僅僅把測試過程作為在需求分析、系統(tǒng)設(shè)計及編碼之后的一個階段，忽視了測試對需求分析,系統(tǒng)設(shè)計的驗證，需求的滿足情況一直到后期的驗收測試才被驗證。
  解決的思路是，當(dāng)一個軟件開發(fā)的時候，研發(fā)人員和測試人員需要同時工作，測試在軟件做需求分析的同時就會有測試用例的跟蹤，這樣，可以盡快找出程序錯誤和需求偏離，從而更高效的提高程序質(zhì)量，最大可能的減少成本，同時滿足用戶的實際軟件需求。

7. Ｗ模型

相對于V模型，W模型更科學(xué)。W模型是V模型的發(fā)展，強調(diào)的是測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、功能和設(shè)計同樣要測試。測試與開發(fā)是同步進行的，從而有利于盡早地發(fā)現(xiàn)問題。

image.png

八、敏捷開發(fā)和測試

image.png

敏捷開發(fā)
敏捷開發(fā)是針對傳統(tǒng)的瀑布開發(fā)模式的弊端而產(chǎn)生的一種新的開發(fā)模式，目標是提高開發(fā)效率和響應(yīng)能力。敏捷開發(fā)以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。

由于版本節(jié)奏比較快，開發(fā)與測試幾乎并行，一個版本周期內(nèi)會有兩版在推動，也就是上圖中提到的波次發(fā)布，波次發(fā)布用于嘗試新加入的功能，做小范圍快速的開發(fā)，驗證和發(fā)布，為下個大版本的功能做實驗和調(diào)研?？焖侔l(fā)版的需求要求測試快速響應(yīng)，敏捷測試模式適應(yīng)項目需求。

模型優(yōu)勢：
工作任務(wù)劃分清晰，工作效率較高
與開發(fā)和產(chǎn)品溝通緊密，團隊協(xié)作性強
測試介入到整個項目的所有會議中，對整體版本信息情況把控全面
迅速占有市場，添加新的功能，吸引更多用戶使用，提升用戶體驗度

模型的缺陷：
模塊提交較快，測試時較有壓迫感
項目規(guī)劃要合理，不然測試時會出現(xiàn)復(fù)測的現(xiàn)象，加大工作量

九、軟件質(zhì)量模型

image.png

1.軟件的功能性

1.1 適用性

所提供的功能是用戶所需要的，用戶所需要的功能軟件系統(tǒng)是否已提供。

1.2 準確性：

軟件系統(tǒng)提供給用戶的功能是否滿足用戶對該功能的精確度要求。

1.3 互操作性：

軟件系統(tǒng)和一個或多個周邊系統(tǒng)進行信息交互的能力。
例如：

image.png

不同型號的打印機與word之間的協(xié)議可能不一致，導(dǎo)致消息傳遞過程中發(fā)生錯誤。
▲應(yīng)該將被測軟件系統(tǒng)和周邊系統(tǒng)的各種主流型號進行互操作性測試。

1.4 保密安全性：

軟件系統(tǒng)保護信息和數(shù)據(jù)的能力。
Ⅰ、防止未得到授權(quán)的人或系統(tǒng)訪問相關(guān)的信息或數(shù)據(jù)
Ⅱ、保證得到授權(quán)的人或系統(tǒng)能正常訪問相關(guān)的信息或數(shù)據(jù)。
不同的系統(tǒng)對于安全性的需求差別很大
常見的安全性測試：
⑴用戶驗證：登錄密碼驗證、IP地址訪問限制等 sql注入
用戶超時:登錄超過30分鐘，重新登錄(安全設(shè)置，cookie過期時間30分鐘)
⑵用戶權(quán)限管理:驗證低級別用戶是否具有了高級別用戶的權(quán)限，各級別用戶權(quán)限都得到了實現(xiàn)。
⑶系統(tǒng)數(shù)據(jù)的保護:對例如系統(tǒng)文件、用戶密碼文件等進行隱藏、密碼驗證、內(nèi)容加密、備份。

1.5 加密、解密：

在計算機通訊中，采用密碼技術(shù)將信息隱蔽起來，再將隱蔽后的信息傳輸出去，使信息在傳輸過程中即使被竊取或截獲，竊取者也不能了解信息的內(nèi)容，從而保證信息傳輸?shù)陌踩?br> token

image.png

Cookie 與session的區(qū)別：
1.cookie是明文傳輸 session的是隱藏專屬
2.Cookie是存在與本機 session是存在與服務(wù)器
3.Cookie的大小是限制在4K session大小限制在5M

2. 軟件可靠性

2.1 成熟性

軟件系統(tǒng)防止內(nèi)部錯誤擴散而導(dǎo)致失效的能力。
▲子系統(tǒng)、模塊、單元模塊的設(shè)計人員應(yīng)該仔細分析和自身有接口關(guān)系的子系統(tǒng)、模塊、單元模塊，識別出這些接口上可能會傳遞過來的錯誤，然后在自己子系統(tǒng)、模塊、單元模塊內(nèi)部對這些可能的錯誤預(yù)先進行防范，規(guī)避這些錯誤傳遞到自身而引起自身的失效。

2.2容錯性

軟件系統(tǒng)防止外部接口錯誤擴散而導(dǎo)致系統(tǒng)失效的能力。
▲設(shè)計人員應(yīng)該充分分析外部接口可能產(chǎn)生的錯誤，然后在設(shè)計上對這些錯誤一一予以防范，防止這些外部傳入的錯誤波及自身而失效。

2.3 易恢復(fù)性

系統(tǒng)失效后重新恢復(fù)原有功能、性能的能力
①原有能力恢復(fù)的程度
②原有能力恢復(fù)的速

2.4 可靠性依從性

遵循相關(guān)的標準（國際標準、國家標準、行業(yè)標準、企業(yè)內(nèi)部規(guī)范等)約定或法規(guī)以及類似規(guī)定的能力。

3.軟件易用性

3.1 易理解性

用戶在使用軟件系統(tǒng)的過程中，系統(tǒng)交互給用戶的信息是否準確、清晰、易懂，能幫助用戶準確理解系統(tǒng)當(dāng)前真實的狀態(tài)，指導(dǎo)其進一步的操作。

image.png

3.2易學(xué)性

軟件系統(tǒng)提供相關(guān)的輔助手段，幫助用戶學(xué)習(xí)使用它
的能力。
例如：是否有用戶手冊，用戶手冊是否有中文版，是否有在
線幫助，界面上控件是否有回顯功能等。

3.3易操作性

例如：
①Nokia手機和Moto手機在編輯短消息時的方便性差異。
②GUI界面，菜單層次不要太深
③安裝軟件的過程
錯誤：給用戶大量的安裝步驟，每步又有大量分支選項
（把用戶當(dāng)成本軟件的專家）
▲測試時應(yīng)該以非專業(yè)的角度來測試過程，往往需要α、
β測試。

3.4 吸引性

美觀：GUI界面、手機外觀等
新穎：如夏新手機來電跳舞功能

3.5 易用性的依從性

遵循相關(guān)的標準（國際標準、國家標準、行業(yè)標準、企業(yè)內(nèi)部規(guī)范等)約定或法規(guī)以及類似規(guī)定的能力。
問：性能測試的標準：
吞吐量
響應(yīng)時間
資源使用率 內(nèi)存使用率 cpu的使用率 電量的損耗 流量使用
成功

4.軟件效率（性能測試）

4.1 時間效率(2-5-10) 358

系統(tǒng)在各業(yè)務(wù)場景下完成用戶指定的業(yè)務(wù)請求所需的響應(yīng)時間。

4.2資源效率

系統(tǒng)在各業(yè)務(wù)場景下完成用戶指定的業(yè)務(wù)請求所消耗的系統(tǒng)資源，如CPU占有率 75%內(nèi)存占有率80%、通信帶寬占有率、軟件內(nèi)部消息包資源占有率等。

4.3效率依從性

遵循相關(guān)的標準（國際標準、國家標準、行業(yè)標準、企業(yè)內(nèi)部規(guī)范等)約定或法規(guī)以及類似規(guī)定的能力。

image.png

image.png

5.軟件可維護性

5.1 易分析性

軟件系統(tǒng)提供輔助手段幫助開發(fā)人員分析識別缺陷、失效產(chǎn)生的原因，找出待修復(fù)部分的能力。（降低缺陷定位的成本）

5.2易改變性

對軟件缺陷的修復(fù)容易被實施（降低修復(fù)缺陷成本）
▲設(shè)計上封裝性好、高內(nèi)聚（同層次設(shè)計時，一個實體只完成一個功能）、低耦合，為未來可能的變化留有擴充余地。

5.3穩(wěn)定性

例如：代碼中的有物理含義的數(shù)字，一定用宏代替。

5.4 易測試性

（降低發(fā)現(xiàn)缺陷的成本）
①軟件可控制：
軟件系統(tǒng)提供輔助手段幫助測試工程師控制該系統(tǒng)的運行，實現(xiàn)其測試執(zhí)行步驟的能力（通過打點、改變內(nèi)部狀態(tài)、值等手段）
②可觀察：
軟件系統(tǒng)提供輔助手段幫助測試工程師獲得充分的系統(tǒng)運行信息，以正確判斷系統(tǒng)運行狀態(tài)和測試執(zhí)行結(jié)果的力。
a、設(shè)計單獨的測試模式
b、提供單獨的測試版本
▲測試部（一般指測試系統(tǒng)工程師）應(yīng)該在需求分析階段就提出可測試性需求，可測試性需求和軟件產(chǎn)品其他需求一起納入需求包被分析設(shè)計并實現(xiàn)。

5.5 維護性的依從性

遵循相關(guān)的標準（國際標準、國家標準、行業(yè)標準、企業(yè)內(nèi)部規(guī)范等)約定或法規(guī)以及類似規(guī)定的能力。

6.軟件可移植性

6.1適應(yīng)性

軟件系統(tǒng)無需做任何相應(yīng)變動就能適應(yīng)不同運行環(huán)境（操作系統(tǒng)平臺、數(shù)據(jù)庫平臺、硬件平臺等）的能力。
▲解決平臺無關(guān)、可移植性問題的一個常用思路是構(gòu)造出一個虛擬層，虛擬層將下層細節(jié)屏蔽，對上層提供統(tǒng)一口。

6.2易安裝性

主流平臺 全部測試用例
非主流平臺 10%測試用例

6.3共存性

軟件系統(tǒng)和在公共環(huán)境與其共享資源的其他系統(tǒng)共存的能力。
▲測試不僅需要關(guān)注自身特性的實現(xiàn)，還要關(guān)注本軟件是否影響了其他軟件的正常功能。

7.易替換性

• 軟件系統(tǒng)升級能力（在線升級、打補丁升級等）
  可移植性的依從性
• 遵循相關(guān)的標準（國際標準、國家標準、行業(yè)標準、企業(yè)內(nèi)部規(guī)范等)約定或法規(guī)以及類似規(guī)定的能力。

十、 軟件測試的常識知識

1.測試部門的組織結(jié)構(gòu)

5個開發(fā)（java） 1個測試 2個移動（AND IOS） 1 個前端 1個產(chǎn)品/項目

按需求來分類： 1個組長： 制定測試計劃 和 對測試用例的評審 編寫測試報告和測試總結(jié)
1個功能測試： 按照測試用例進行點點的人
1個性能測試/接口測試： 滿足需求文檔上的性能指標
1個自動化測試 python uI自動化 接口自動化 單元自動化
Java
按項目模塊劃分： pc 移動
具體一級菜單欄 按底部導(dǎo)航欄

image.png

image.png

2. 軟件測試和SQA的關(guān)系

2.1 什么是SQA

image.png

1.1.39.SQA與測試

image.png

• 測試工具的種類：
  文檔工具： word excel
  Bug管理工具： 禪道 jira
  抓包工具： charles fiddler wineshark
  a.抓包 b.模擬弱網(wǎng)測試c.斷點替換 d.過濾 e：壓力測試
  性能工具： jmeter Loadrunner （對業(yè)務(wù)場景測試）
  命令： Linux adb Monkey
  編程語言： python
  自動化 ; selenium appnium （ui自動化） pytest (測試用例 單元測試) innerHtml （發(fā)送測試報告） alluer
  數(shù)據(jù)庫 mysql

十一、軟件測試工具

軟件測試工具是通過一些工具能夠使軟件的一些簡單問題直觀的顯示，使測試人員更好的找出軟件錯誤所在。
軟件測試工具分為自動化軟件測試工具和測試管理(禪道)工具。
軟件測試工具存在的價值是為了提高測試效率，用軟件來代替一些人工輸入。
測試管理工具是為了復(fù)用測試用例，提高軟件測試的價值。
一個好的軟件測試工具和測試管理工具結(jié)合起來使用將會使軟件測試效率大大的提高。

Bug管理工具： 禪道 Jary
自動化 selenium appnium （ui自動化） pytest (測試用例 單元測試) innerHtml （發(fā)送測試報告）
性能測試工具 jmeter Loadrunner、
抓包工具 Fiddler charles (弱網(wǎng)測試的)
接口工具 postman
錄制腳本 bodyboy jmeter

云測 騰訊云 模擬不同的移動端或者是web瀏覽器

命令 Linux adb monkey
數(shù)據(jù)庫 myql
語言 python

image.png

1. WinRunner

Winrunner 最主要的功能是自動重復(fù)執(zhí)行某一固定的測試過程，它以腳本的形式記錄下手工測試的一系列操作，在環(huán)境相同的情況下重放，檢查其在相同的環(huán)境中有無異常的現(xiàn)象或與預(yù)期結(jié)果不符的地方?？梢詼p少由于人為因素造成結(jié)果錯誤，同時也可以節(jié)省測試人員大量測試時間和精力來做別的事情。功能模塊主要包括：GUI map、檢查點、TSL 腳本編程、批量測試、數(shù)據(jù)驅(qū)動等幾部分

2. LoadRunner

商業(yè)化-掙錢 性能測試工具 響應(yīng)時間，CPU，內(nèi)存，吞吐量....
LoadRunner? 是一種預(yù)測系統(tǒng)行為和性能的工業(yè)標準級負載測試工具。通過以模擬上千萬用戶實施并發(fā)負載及實時性能監(jiān)測的方式來確認和查找問題，LoadRunner 能夠?qū)φ麄€企業(yè)架構(gòu)進行測試。通過使LoadRunner ，企業(yè)能最大限度地縮短測試時間，優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。LoadRunner 是一種適用于各種體系架構(gòu)的自動負載測試工具，它能預(yù)測系統(tǒng)行為并優(yōu)化系統(tǒng)性能。LoadRunner 的測試對象是整個企業(yè)的系統(tǒng)，它通過模擬實際用戶的操作行為和實行實時性能監(jiān)測，來幫助您更快的查找和發(fā)現(xiàn)問題。此外，還能支持廣范的協(xié)議和技術(shù)，為您的特殊環(huán)境提供特殊的解決方案

3. QTP

QTP是一個B/S系統(tǒng)的自動化功能測試的利器,軟件程序測試工具。Mercury的自動化功能測試軟件QuickTest Professional ，可以覆蓋絕大多數(shù)的軟件開發(fā)技術(shù)，簡單高效，并具備測試用例可重用的特點。Mercury QuickTest Pro 是一款先進的自動化測試解決方案，用于創(chuàng)建功能和回歸測試。它自動捕獲、驗證和重放用戶的交互行為。 Mercury QuickTest Pro為每一個重要軟件應(yīng)用和環(huán)境提供功能和回歸測試自動化的行業(yè)最佳解決方案。

4. TestDirector

測試管理工具
基于WEB的測試管理工具，他能夠讓你系統(tǒng)地控制整個測試過程，并創(chuàng)建整個測試工作流的框架和基礎(chǔ)，使整個測試管理過程變得更為簡單和有組織。他能夠幫助你維護一個測試工程數(shù)據(jù)庫，并且能夠覆蓋你的應(yīng)用程序功能性的各個方面。T并且還為你提供了直觀和有效的方式來計劃和執(zhí)行測試集、收集測試結(jié)果并分析數(shù)據(jù)。還專門提供了一個完善的缺陷跟蹤系統(tǒng)。并可以同Mercury公司的測試工具、第三方或者自主開發(fā)的測試工具、需求和配置管理工具、建模工具的整合功能。你可以通過他進行需求定義、測試計劃、測試執(zhí)行和缺陷跟蹤，即整個測試過程的各個階段

5. Selenium

自動化測試工具 支持java python的腳本 python
自動化--寫好腳本，運行腳本，自己執(zhí)行，自己出測試報告，自己發(fā)送到測試和開發(fā)郵箱
80%bug 手動測試出來
Selenium是為正在蓬勃發(fā)展的web應(yīng)用開發(fā)的一套完整的測試系統(tǒng)。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操作一樣。它的主要功能包括：測試與瀏覽器的兼容性——測試你的應(yīng)用程序看是否能夠很好得工作在不同瀏覽器和操作系統(tǒng)之上。測試系統(tǒng)功能——創(chuàng)建衰退測試檢驗軟件功能和用戶需求。支持自動錄制動作和自動生成。Selenium的核心Selenium Core基于JsUnit，完全由JavaScript編寫，因此可運行于任何支持JavaScript的瀏覽器上，包括IE、Mozilla Firefox、Chrome、Safari等

6. Appium

自動化測試工具，android和ios軟件 手機App app
Appium是一個開源、跨平臺的，適用于原生或混合移動應(yīng)用(hybrid mobile apps)的自動化測試平臺。Appium使用WebDriver（JSON wire protocol）驅(qū)動安卓和iOS移動應(yīng)用.Appium的設(shè)計哲學(xué)是不要為了移動端的自動化測試而重新發(fā)明輪子，重新寫一套驚天動地的api，也就是說webdriver協(xié)議里的api已經(jīng)夠好了，拿來改進一下就可以了另外Appium可以把server放在任意機器上，哪怕是云服務(wù)器都可以，所以Appium和WebDriver天生適合做云測試。

7. Jmeter

開源，免費，簡單，易操作。 開源組織，支持腳本錄制，支持抓包測試，支持測試移動端軟件
壓力和負載測試

8. PostMan

接口測試是測試系統(tǒng)組件間接口的一種測試。接口測試主要用于檢測外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個子系統(tǒng)之間的交互點。測試的重點是要檢查數(shù)據(jù)的交換，傳遞和控制管理過程，以及系統(tǒng)間的相互邏輯依賴關(guān)系等。

接口測試的目的是測試接口，尤其是那些與系統(tǒng)相關(guān)聯(lián)的外部接口，測試的重點是要檢查數(shù)據(jù)的交換，傳遞和控制管理過程，還包括處理的次數(shù)。外部接口測試一般是作為系統(tǒng)測試來看待的。
接口自動化

接口上傳參數(shù)的正確性，和服務(wù)器返回值的正確性，容錯性驗證(滴滴)，以及安全性檢測。

9. 抓包測試

包是指數(shù)據(jù)包.目的是分析包的內(nèi)容與相關(guān)協(xié)議,然后衡量是否符合當(dāng)初的設(shè)計或排除故障.
在被測接口并沒有明確的接口文檔給出時，我們需要借助抓包工具來幫助測試，利用抓包工具我們幾乎可以獲得接口文檔中能給你的一切

Charles，fiddler 抓包工具
抓瀏覽器，抓手機APP請求