1983年，Bill Hetzel將軟件測試定義為：軟件測試就是一系列活動，這些活動是為了評估一個程序或者軟件系統(tǒng)的特性或能力，并確定是否達(dá)到了其預(yù)期的效果。

從這話我們可以看出以下兩點(diǎn)：

• 測試試圖驗(yàn)證軟件是“工作的”，也就是驗(yàn)證軟件功能執(zhí)行的正確性
• 測試的活動是以測試人員“預(yù)期的結(jié)果”為依據(jù)，這里的“預(yù)期結(jié)果”指的是需求定義。

• 工作內(nèi)容區(qū)別

開發(fā)人員通過各種編程語言等專業(yè)技能編寫代碼開發(fā)軟件，修改BUG

測試人員設(shè)計(jì)測試用例，編寫自動化測試工具

• 技能要求區(qū)別

測試 ：技能要求廣，專業(yè)度低，業(yè)務(wù)能力，設(shè)計(jì)和架構(gòu)分析能力，測試手段和工具使用，用戶模型分析和理解，編程能力，UI自動化，接口測試，抓包工具，性能測試等

開發(fā)：技能要求深，專業(yè)度高，寫出更高效的代碼

• 薪水

大廠開發(fā)和測試薪資基本一樣

中小企業(yè)總體比研發(fā)低，自動化等專業(yè)測試領(lǐng)域和研發(fā)基本無差距

• 發(fā)展前景

自動化測試、安全測試等領(lǐng)域發(fā)展前景和研發(fā)基本一致。

測試：初級測試工程師 ->中級測試工程師 ->高級測試工程師 ->架構(gòu)師 ->項(xiàng)目經(jīng)理

開發(fā)：初級工程師 ->中級工程師 ->高級工程師 ->架構(gòu)師 ->CTO

• 工作環(huán)境

基本類似

• 繁忙程度

一般比研發(fā)輕松，但敏捷模式下差距不大，產(chǎn)品發(fā)布前壓力比較大

???3.?調(diào)試和測試的區(qū)別是什么？

• 目的不同

調(diào)試：確保程序做了程序員想它做的事情（發(fā)現(xiàn)問題解決問題）

測試：確保程序解決了它該解決的問題 （發(fā)現(xiàn)問題提供解決方案）

• 參與角色不同 （人員）

測試由測試人員和開發(fā)人員來執(zhí)行，黑盒測試主要由測試人員完成、單元/集成測試主要是由開發(fā)人員執(zhí)行。

調(diào)試由開發(fā)人員完成。

• 執(zhí)行的階段不同

測試貫穿整個軟件開發(fā)生命周期（測試在開發(fā)之前就已經(jīng)介入測試，測試在軟件需求階段已經(jīng)開始了）

調(diào)試一般在開發(fā)階段（開發(fā)完成之后，或者邊開發(fā)邊測試）

• 手段區(qū)別

調(diào)試：idea打斷點(diǎn)調(diào)試，分析代碼邏輯

測試：等價類劃分，邊界值，判定表，語句覆蓋，條件覆蓋，條件語句覆蓋......

???4. 軟件測試崗位

• 軟件測試工程師

工程師的主要工作一般包含需求分析、編寫測試計(jì)劃和測試方案、設(shè)計(jì)測試用例、執(zhí)行測試用例、跟蹤BUG、編寫測試報告等。

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

根據(jù)項(xiàng)目的特點(diǎn)來開發(fā)一些自動化測試的腳本，或自動化測試的工具，或者是軟件測試工作中用到的提高工作效率的小工具什么的，從而能夠更有效地進(jìn)行測試，提高軟件產(chǎn)品的質(zhì)量。

測試開發(fā)工程師工作的目的就是為了更高效，更快捷地讓測試工程師進(jìn)行測試工作；測試開發(fā)崗位一般要求一定的開發(fā)能力，解決問題的能力尤為重要。

• 性能測試工程師

針對系統(tǒng)進(jìn)行性能測試，包括使用工具和編寫性能自動化測試腳本。

• 安全測試工程師

主要分析產(chǎn)品可能會出現(xiàn)的安全問題，做各個方面的滲透測試，提高產(chǎn)品的安全性

• 其它

系統(tǒng)測試工程師，嵌入式測試工程師，硬件測試工程師。

???5. 一個優(yōu)秀的軟件測試人員具備的素質(zhì)

綜合能力

• 溝通能力

測試工程師的溝通能力會直接影響事務(wù)開展的效率。良好清晰的溝通能力，是一個技術(shù)優(yōu)秀的測是工程師是否可以獲得更好發(fā)展的“敲門磚”。

• 快速學(xué)習(xí)的能力

對不同業(yè)務(wù)需求和功能的快速學(xué)習(xí)與理解能力。 對于測試新技術(shù)和新方法的學(xué)習(xí)能力。

• 開發(fā)能力，文字表達(dá)能力
• 責(zé)任感與壓力

責(zé)任感：測試往往是產(chǎn)品的最后一個檢驗(yàn)者；測試的工作成效很難衡量，測試用例執(zhí)行、bug數(shù)目的多少都無法說明產(chǎn)品是否能夠交給用戶使用。所以，責(zé)任感是最重要的測試必備素質(zhì)之一。

壓力：來自開發(fā)人員、用戶、上級、自己的壓力。測試人員的壓力比想象中的要大。

• 掌握自動化測試技術(shù)
• 優(yōu)秀的測試用例設(shè)計(jì)能力

測試用例設(shè)計(jì)能力是指，無論對于什么類型的測試，都能夠設(shè)計(jì)出高效地發(fā)現(xiàn)缺陷，保證產(chǎn)品質(zhì)量的優(yōu)秀測試用例。

• 探索性思維

掌握自動化測試技術(shù)，可以把你從大量重復(fù)性的手工勞動中解放出來，這樣可以把更多的精力花在更多類型的測試上。

逆向思維：開發(fā)蓋房子，測試拆房子。不走尋常路。

案例：手機(jī)中有兩條通話記錄，進(jìn)行刪除。刪除為0后，繼續(xù)刪除。

發(fā)散性思維：探求多項(xiàng)答案

案例：測試一臺自動售票機(jī)。正向，逆向，邊界，壓力，性能，耗電量，斷電，外觀，沒零錢.....

???6. 為什么要做測試

軟件測試是為軟件產(chǎn)品的質(zhì)量把關(guān)的，目前軟件測試的工業(yè)化時代還沒有來臨，自動化軟件測試工具還沒有能統(tǒng)一起來的模式，大部分還是靠人工測試，所以軟件測試有很大的發(fā)展空間和前景。軟件測試并不比軟件開發(fā)輕松，也不比軟件開發(fā)簡單，選擇軟件測試并不是覺得它更容易，而是自己本身對這個行業(yè)更有興趣，做測試也會更投入，所以選擇測試而不是開發(fā)。

如軟件測試貫穿于整個軟件開發(fā)的生命周期，本人喜歡對個階段的測試用例進(jìn)行分析和設(shè)計(jì)，感覺測試更有趣。

對于任何行業(yè)，從業(yè)者的水平分布都是成金字塔形的。測試很有前途也很有挑戰(zhàn)。

二、概念

???1. 衡量軟件測試結(jié)果的依據(jù)—需求

??（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)文檔說明。它包括功能性需求及非功能性需求，非功能性需求對設(shè)計(jì)和實(shí)現(xiàn)提出了限制，比如性能要求，質(zhì)量標(biāo)準(zhǔn)，或者設(shè)計(jì)限制。

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

用戶需求：可以簡單理解為甲方提出的需求，如果沒有甲方，那么就是終端用戶使用產(chǎn)品時必須要完成的任務(wù)。該需求一般比較簡略。

軟件需求：或者叫功能需求，該需求會詳細(xì)描述開發(fā)人員必須實(shí)現(xiàn)的軟件功能。

大多數(shù)公司在進(jìn)行軟件開發(fā)的時候會把用戶需求轉(zhuǎn)化為軟件需求，開發(fā)人員和測試人員工作的直接依據(jù)就是軟件需求。

軟件需求是測試人員進(jìn)行測試工作的基本依據(jù)。

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

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

過程如下，

???????????????? 業(yè)務(wù)需求—>軟件功能需求點(diǎn)—>測試需求點(diǎn)—>測試用例

??（3）為什么需求對軟件測試人員如此重要?

• 從軟件功能需求出發(fā)，無遺漏的識別出測試需求是至關(guān)重要的，這將直接關(guān)系到用例的測試覆蓋率
• 對于識別出的每個測試需求點(diǎn)，需要采用具體的設(shè)計(jì)測試用例的方法來進(jìn)行測試用例的設(shè)計(jì)

??（4）如何才可以深入理解被測試軟件的需求

測試工程師在需求分析和設(shè)計(jì)階段就開始介入，因?yàn)檫@個階段是理解和掌握軟件的原始業(yè)務(wù)需求的最好時機(jī)。

只有真正理解了原始業(yè)務(wù)需求之后，才有可能從業(yè)務(wù)需求的角度去設(shè)計(jì)針對性明確，從終端用戶的使用場景到端到端的覆蓋率較高的測試用例集。

??（5）測試用例的概念

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

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

??測試過程中可能會遇到以下問題：

（1）不知道是否較全面的測試了所有功能?

（2）測試的覆蓋率無法衡量

（3）對新版本的重復(fù)測試很難實(shí)施

（4）存在大量冗余測試影響測試效率

測試用例的產(chǎn)生就是為了解決上述的問題。

嘗試寫一個測試用例

測試標(biāo)題：注冊網(wǎng)易郵箱

測試環(huán)境：win10，Microsoft Edge版本

測試數(shù)據(jù)：

? ? ? ? ? ? ? ? ? 郵箱地址：123456@qq.com

? ? ? ? ? ? ? ? ? 密碼：123456

? ? ? ? ? ? ? ? ? 手機(jī)號：12345678912

測試步驟：1.打開瀏覽器，輸入網(wǎng)易注冊地址： 注冊網(wǎng)易免費(fèi)郵箱 - 你的專業(yè)電子郵局 (163.com)

????????????????2.輸入郵箱地址，密碼，手機(jī)號碼，同意服務(wù)條款

????????????????3. 點(diǎn)擊注冊

測試預(yù)期：展現(xiàn)注冊成功結(jié)果頁，并使用賬號可以登錄成功

?? 刪除微信聊天記錄功能是否正常

基本測試點(diǎn)：

（1）單條刪除；

（2）全部刪除

（3）清空聊天記錄

（4）沒有網(wǎng)絡(luò)的情況下刪除聊天記錄

（5）弱網(wǎng)的情況下刪除聊天記錄

兼容性：

（1）測試不同的微信版本

（2）測試不同的手機(jī)系統(tǒng)（iOS，Android，包括不同安卓機(jī)不同品牌的機(jī)型）

性能：

??刪除聊天記錄時的速度（單條，全部，清空）

???2.?軟件錯誤（BUG）的概念

第一個bug ：

1945年9月的某天，在一間老式建筑里，從窗外飛進(jìn)來一只飛蛾，此時Hopper正埋頭工作在一臺名為Mark Il的計(jì)算機(jī)前，并沒有注意到這只即將造就歷史事件的飛蛾。這臺計(jì)算機(jī)使用了大量的繼電器（電子機(jī)械裝置，那時還沒有使用晶體管）。突然，Mark II死機(jī)了。Hopper試了很多次還是不能啟動，他開始用各種方法查找問題，最后定位到了某個電路板的繼電器上。Hopper觀察這個繼電器，驚奇地發(fā)現(xiàn)一只飛蛾已經(jīng)被繼電器打死。Hopper小心地用鑷子將飛蛾夾出來，用透明膠布貼到“事件記錄本”中，寫上“第一個發(fā)現(xiàn)蟲子的實(shí)例”。Hopper的事件記錄本，連同那只飛蛾，現(xiàn)在都陳列在美國歷史博物館中。 軟件錯誤的一般定義： 程序與規(guī)格說明之前不匹配 。

注意：以上說法是片面的，準(zhǔn)確的來說：當(dāng)且僅當(dāng)規(guī)格說明是存在的并且正確，程序與規(guī)格說明之間的不匹配才是 錯誤 。

當(dāng)需求規(guī)格說明書沒有提到的功能，判斷標(biāo)準(zhǔn)以最終用戶為準(zhǔn)：當(dāng)程序沒有實(shí)現(xiàn)其最終用戶合理預(yù)期的功能要求時，就是 軟件錯誤 。

???3. 開發(fā)模型和測試模型

軟件工作的范圍不僅僅局限在程序編寫，而是擴(kuò)展到了整個軟件生命周期，如軟件基本概念的形成、需求分析、設(shè)計(jì)、實(shí)現(xiàn)、測試、安裝部署、運(yùn)行維護(hù)，直到軟件被更新和替換新的版本。軟件工程還包括很多技術(shù)性的管理工作，例如過程管理、產(chǎn)品管理、資源管理和質(zhì)量管理。

??（1）軟件的生命周期

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

需求分析：分析需求是否正確，是否完整

計(jì)劃：項(xiàng)目什么時候上線，項(xiàng)目什么時候時候開發(fā)，項(xiàng)目由誰做，項(xiàng)目什么時候測試等等

設(shè)計(jì)：技術(shù)文檔，UI設(shè)計(jì)稿

編碼：根據(jù)軟件需求寫代碼

測試：測試軟件是否有BUG

運(yùn)行維護(hù)：出現(xiàn)線上問題，進(jìn)行修復(fù)

??（2）瀑布模型（Waterfall Model）

瀑布模型在軟件工程中占有重要地位，是所有其他模型的基礎(chǔ)框架。瀑布模型的 每一個階段都只執(zhí)行一次， 因此是線性順序進(jìn)行的軟件開發(fā)模式。

優(yōu)點(diǎn)：

強(qiáng)調(diào)開發(fā)的階段性；

強(qiáng)調(diào)早期計(jì)劃及需求調(diào)查；

強(qiáng)調(diào)產(chǎn)品測試。

缺點(diǎn)：

依賴于早期進(jìn)行的唯一一次需求調(diào)查，不能適應(yīng)需求的變化；

由于是單一流程，開發(fā)中的經(jīng)驗(yàn)教訓(xùn)不能反饋應(yīng)用于本產(chǎn)品的過程；

風(fēng)險往往遲至后期的測試階段才顯露，因而失去及早糾正的機(jī)會。

瀑布模型的一個最大缺陷在于，可以運(yùn)行的產(chǎn)品很遲才能被看到。這會給項(xiàng)目帶來很大的風(fēng)險，尤其是集成的風(fēng)險。因?yàn)槿绻谛枨笠氲囊粋€缺陷要到測試階段甚至更后的階段才發(fā)現(xiàn)，通常會導(dǎo)致前面階段的工作大面積返工，業(yè)界流行的說法是：“集成之日就是爆炸之日”。盡管瀑布模型存在很大的缺陷，例如，在前期階段未發(fā)現(xiàn)的錯誤會傳遞并擴(kuò)散到后面的階段，而在后面階段發(fā)現(xiàn)這些錯誤時，可能已經(jīng)很難回頭再修正，從而導(dǎo)致項(xiàng)目的失敗。但是目前很多軟件企業(yè)還是沿用了瀑布模型的線性思想，在這個基礎(chǔ)上做出自己的修改。例如細(xì)化了各個階段，在某些重點(diǎn)關(guān)注的階段之間摻入迭代的思想。

在瀑布模型中，測試階段處于軟件實(shí)現(xiàn)后，這意味著必須在代碼完成后有足夠的時間預(yù)留給測試活動，否則將導(dǎo)致測試不充分，從而把缺陷直接遺留給用戶。

??（3）螺旋模型（Spiral Model）

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

強(qiáng)調(diào)嚴(yán)格的全過程風(fēng)險管理。

強(qiáng)調(diào)各開發(fā)階段的質(zhì)量。

提供機(jī)會檢討項(xiàng)目是否有價值繼續(xù)下去。

引入非常嚴(yán)格的風(fēng)險識別、風(fēng)險分析和風(fēng)險控制，這對風(fēng)險管理的技能水平提出了很高

的要求。這需要人員、資金和時間的投入。

??（4）增量、迭代

增量開發(fā)能顯著降低項(xiàng)目風(fēng)險，結(jié)合軟件持續(xù)構(gòu)建機(jī)制，構(gòu)成了當(dāng)今流行的軟件工程最佳實(shí)踐之一。增量開發(fā)模型，鼓勵用戶反饋，在每個迭代過程中，促使開發(fā)小組以一種循環(huán)的、可預(yù)測的方式驅(qū)動產(chǎn)品的開發(fā)。因此，在這種開發(fā)模式下，每一次的迭代都意味著可能有需求的更改、構(gòu)建出新的可執(zhí)行軟件版本，意味著測試需要頻繁進(jìn)行，測試人員需要與開發(fā)人員更加緊密地協(xié)作。

增量通常和迭代混為一談，但是其實(shí)兩者是有區(qū)別的。增量是逐塊建造的概念，例如畫一幅人物畫，我們可以先畫人的頭部，再畫身體，再畫手腳……而迭代是反復(fù)求精的概念，同樣是畫人物畫，我們可以采用先畫整體輪廓，再勾勒出基本雛形，再細(xì)化、著色。

??（5）敏捷

?個體與交互重于過程和工具

可用的軟件重于完備的文檔

客戶協(xié)作重于合同談判

響應(yīng)變化重于遵循計(jì)劃

在每對比對中，后者并非全無價值，但我們更看重前者。

• 挑戰(zhàn)：快速迭代

（1）測試工作的核心內(nèi)客是沒有變的，就是不斷地找Bug，只是要調(diào)整好自己的心態(tài)，一切以敏捷的原則為主。

（2）測試人員不能依賴文檔，測試用例作用減弱，更多的采用思維導(dǎo)圖、探索性測試（強(qiáng)調(diào)自由度，設(shè)計(jì)和執(zhí)行同時執(zhí)行，根據(jù)測試結(jié)果不斷調(diào)整測試計(jì)劃）、自動化測試

（3）敏捷講求合作，在敏捷項(xiàng)目組中，測試人員應(yīng)該更主動點(diǎn)，多向開發(fā)人員了解需求、討論設(shè)計(jì)、一起研究Bug出現(xiàn)的原因。

??（6）軟件測試v模型

• 明確的標(biāo)注了測試過程中存在的不同類型的測試，并且清楚的描述了這些測試階段和開發(fā)過程期間
• 各階段的對應(yīng)關(guān)系：V模型指出，①單元和集成測試應(yīng)檢測程序的執(zhí)行是否滿足軟件設(shè)計(jì)的要求；②系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo)；③驗(yàn)收測試確定軟件的實(shí)現(xiàn)是否滿足用戶需要或合同的要求
• 局限性:僅僅把測試作為在編碼之后的一個階段，未在需求階段就進(jìn)入測試

??（7）軟件測試W模型 ?

• W模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動。W模型由兩個V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關(guān)系。
• W模型特點(diǎn)：測試的對象不僅是程序，需求、設(shè)計(jì)等同樣要測試，測試與開發(fā)是同步進(jìn)行的
• W模型優(yōu)點(diǎn)：有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后，測試人員就應(yīng)該參與到對需 求的驗(yàn)證和確認(rèn)活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項(xiàng)目難度和測試風(fēng)險，及早制定應(yīng)對措施，顯著減少總體測試時間，加快項(xiàng)目進(jìn)度。
• 局限性：需求、設(shè)計(jì)、編碼等活動被視為串行的；測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個階段工作。無法支持敏捷開發(fā)模式。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W模型并不能解除測試管理面臨著困惑。