一、軟件測試背景

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

1. 軟件缺陷與軟件故障

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

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

6. 其他一些例子

   
   
   BUG.png

1.2 軟件缺陷的定義

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

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

1.3 軟件缺陷的特征

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

思考：

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

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

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

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

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

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

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

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

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

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

1. 軟件測試定定義

1.1 狹義

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

1.2 廣義

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

1.3 軟件測試的定義

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

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

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

3.軟件測試的前景

軟件測試的前景.png

4.新人如何融入一個(gè)項(xiàng)目團(tuán)隊(duì)

image.png

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

image.png

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

6. 軟件工程的目的

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

image.png

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

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

8. 測試環(huán)境

測試環(huán)境=硬件+軟件+網(wǎng)絡(luò)
硬件環(huán)境：pc機(jī)還是筆記本
軟件環(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. 測試流程

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

image.png

三、軟件測試分類

image.png

1.黑盒測試和白盒測試

黑盒測試(Black Box -Test)：把被測試的軟件看做一個(gè)黑盒子，我們不去關(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)測試和動(dòng)態(tài)測試

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

3.功能測試和性能測試

3.1.功能測試

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

image.png

3.2.性能測試

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

image.png

image.png

4.回歸測試、冒煙測試、隨機(jī)測試

4.1.回歸測試

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

4.2.冒煙測試

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

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

4.3.隨機(jī)測試

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

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

image.png

5.1.單元測試

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

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

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

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

5.2.集成測試

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

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

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

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

image.png

6.測試案例

image.png

6.1.需求：

測試一個(gè)帶廣告圖案的花紙杯

6.2.功能測試

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

6.3.界面測試

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

6.4.性能測試

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

6.5.安全性測試

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

6.6.易用性測試

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

四、測試分類占比

image.png

五、軟件測試七大原則

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

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

1. 窮盡測試是不可能的

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

3.測試盡早介入

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

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

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

5. 殺蟲劑悖論

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

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

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

7. 沒有錯(cuò)誤是好是謬論

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

注意：

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

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

1. 線性模型與漸進(jìn)式模型

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

2. 迭代和增量的理解

image.png

image.png

七、 軟件生命周期模型

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

image.png

1.邊做邊改模型

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

image.png

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

2.瀑布模型

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

image.png

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

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

3. 原型化模型

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

image.png

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

4. 增量模型

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

image.png

5. 螺旋模型

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

image.png

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

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

優(yōu)點(diǎn)：
1）設(shè)計(jì)上很靈活，可以在項(xiàng)目的各個(gè)階段進(jìn)行變更；
2）以小的分段來構(gòu)建大型系統(tǒng)，使成本計(jì)算變得簡單容易；(國企項(xiàng)目)
3）客戶始終參與每個(gè)階段的開發(fā)，保證了項(xiàng)目不偏離正確方向以及項(xiàng)目的可控性；
4）隨著項(xiàng)目推進(jìn)，客戶始終掌握項(xiàng)目的最新信息 , 從而能夠和管理層有效地交互；
5）客戶認(rèn)可這種公司內(nèi)部的開發(fā)方式帶來的良好的溝通和高質(zhì)量的產(chǎn)品。
缺點(diǎn)：
螺旋模型強(qiáng)調(diào)風(fēng)險(xiǎn)分析，但要求許多客戶接受和相信這種分析，并做出相關(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ā)過程各階段，與此相對(duì)應(yīng)的是右邊上升的部分，即各測試過程的各個(gè)階段。
V 模型的優(yōu)點(diǎn)在于它非常明確地標(biāo)明了測試過程中存在的不同級(jí)別，并且清楚地描述了這些測試階段和開發(fā)各階段的對(duì)應(yīng)關(guān)系。

V模型

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

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

7. Ｗ模型

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

image.png

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

image.png

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

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

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

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

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

image.png

1.軟件的功能性

1.1 適用性

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

1.2 準(zhǔn)確性：

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

1.3 互操作性：

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

image.png

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

1.4 保密安全性：

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

1.5 加密、解密：

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

image.png

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

2. 軟件可靠性

2.1 成熟性

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

2.2容錯(cuò)性

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

2.3 易恢復(fù)性

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

2.4 可靠性依從性

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

3.軟件易用性

3.1 易理解性

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

image.png

3.2易學(xué)性

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

3.3易操作性

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

3.4 吸引性

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

3.5 易用性的依從性

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

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

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

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

4.2資源效率

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

4.3效率依從性

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

image.png

image.png

5.軟件可維護(hù)性

5.1 易分析性

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

5.2易改變性

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

5.3穩(wěn)定性

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

5.4 易測試性

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

5.5 維護(hù)性的依從性

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

6.軟件可移植性

6.1適應(yīng)性

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

6.2易安裝性

主流平臺(tái) 全部測試用例
非主流平臺(tái) 10%測試用例

6.3共存性

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

7.易替換性

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

十、 軟件測試的常識(shí)知識(shí)

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

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

按需求來分類： 1個(gè)組長： 制定測試計(jì)劃 和 對(duì)測試用例的評(píng)審 編寫測試報(bào)告和測試總結(jié)
1個(gè)功能測試： 按照測試用例進(jìn)行點(diǎn)點(diǎn)的人
1個(gè)性能測試/接口測試： 滿足需求文檔上的性能指標(biāo)
1個(gè)自動(dòng)化測試 python uI自動(dòng)化 接口自動(dòng)化 單元自動(dòng)化
Java
按項(xiàng)目模塊劃分： pc 移動(dòng)
具體一級(jí)菜單欄 按底部導(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.斷點(diǎn)替換 d.過濾 e：壓力測試
  性能工具： jmeter Loadrunner （對(duì)業(yè)務(wù)場景測試）
  命令： Linux adb Monkey
  編程語言： python
  自動(dòng)化 ; selenium appnium （ui自動(dòng)化） pytest (測試用例 單元測試) innerHtml （發(fā)送測試報(bào)告） alluer
  數(shù)據(jù)庫 mysql

十一、軟件測試工具

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

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

云測 騰訊云 模擬不同的移動(dòng)端或者是web瀏覽器

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

image.png

1. WinRunner

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

2. LoadRunner

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

3. QTP

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

4. TestDirector

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

5. Selenium

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

6. Appium

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

7. Jmeter

開源，免費(fèi)，簡單，易操作。 開源組織，支持腳本錄制，支持抓包測試，支持測試移動(dòng)端軟件
壓力和負(fù)載測試

8. PostMan

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

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

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

9. 抓包測試

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

Charles，fiddler 抓包工具
抓瀏覽器，抓手機(jī)APP請(qǐng)求