資訊專欄INFORMATION COLUMN
摘要：單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測試。隨機(jī)測試隨機(jī)測試是根據(jù)測試說明書執(zhí)行用例測試的重要補(bǔ)充手段，是保證測試覆蓋完整性的有效方式和過程。
? ? ? ? 軟甲測試就是用來確認(rèn)一個程序的品質(zhì)或性能是否符合開發(fā)之前所提出的一些要求，軟件測試就是在軟件投入運(yùn)行前，對軟件進(jìn)行需求分析、設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量保證的關(guān)鍵步驟。
軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程
1）單元測試
單元測試（unit testing），是指對軟件中的最小可測試單元進(jìn)行檢查和驗(yàn)證。對于單元測試中單元
的含義，一般來說，要根據(jù)實(shí)際情況去判定其具體含義，如C語言中單元指一個函數(shù)，Java里單元
指一個類，圖形化的軟件中可以指一個窗口或一個菜單等?？偟膩碚f，單元就是人為規(guī)定的最小的
被測功能模塊。單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動，軟件的獨(dú)立單元將在
與程序的其他部分相隔離的情況下進(jìn)行測試。
2）集成測試
集成測試的含義非常簡單- 將單元測試模塊逐個集成/組合，并將行為測試為組合單元。
該測試的主要功能或目標(biāo)是測試單元/模塊之間的接口。??
我們通常在“單元測試”之后進(jìn)行集成測試。一旦創(chuàng)建并測試了所有單個單元，我們就開始組合這些“單元測試”模塊并開始進(jìn)行集成測試。
該測試的主要功能或目標(biāo)是測試單元/模塊之間的接口。
首先多帶帶測試各個模塊。模塊經(jīng)過單元測試后，逐個集成，直到所有模塊都集成在一起，檢查組合行為，驗(yàn)證需求是否正確實(shí)現(xiàn)。
在這里我們應(yīng)該理解，集成測試不會在周期結(jié)束時發(fā)生，而是與開發(fā)同時進(jìn)行。因此，在大多數(shù)情
況下，所有模塊實(shí)際上都無法測試，這就是測試不存在的東西的挑戰(zhàn)！
3）系統(tǒng)測試
將軟件系統(tǒng)看成是一個系統(tǒng)的測試。包括對功能、性能以及軟件所運(yùn)行的軟硬件環(huán)境進(jìn)行測試。時
間大部分在系統(tǒng)測試執(zhí)行階段，包括回歸測試和冒煙測試。將經(jīng)過測試的子系統(tǒng)裝配成一個完整系
統(tǒng)來測試。它是檢驗(yàn)系統(tǒng)是否確實(shí)能提供系統(tǒng)方案說明書中指定功能的有效方法。測試重點(diǎn)是整個
系統(tǒng)的運(yùn)行以及與其他軟件的兼容性。
4）驗(yàn)收測試
驗(yàn)收測試是部署軟件之前的最后一個測試操作。它是技術(shù)測試的最后一個階段，也稱為交付測試。
驗(yàn)收測試的目的是確保軟件準(zhǔn)備就緒，按照項(xiàng)目合同、任務(wù)書、雙方約定的驗(yàn)收依據(jù)文檔，向軟件
購買者展示該軟件系統(tǒng)滿足原始需求。
1）黑盒測試
黑盒測試是一種重要的測試策略，又稱為數(shù)據(jù)驅(qū)動的測試或輸入/輸出驅(qū)動的測試。使用這種測試
方法時，將程序視為一個黑盒子。測試目標(biāo)與程序的內(nèi)部機(jī)制和結(jié)構(gòu)完全無關(guān)，而是將重點(diǎn)集中放
在發(fā)現(xiàn)程序不按其規(guī)范正確運(yùn)行的條件。
?
2）白盒測試
白盒測試（white-box Testing，又稱邏輯驅(qū)動測試，結(jié)構(gòu)測試），它是知道產(chǎn)品內(nèi)部過程，可通過
測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢
驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏
輯驅(qū)動，基路測試等，主要用于軟件驗(yàn)證。
3）灰盒測試
灰盒測試，是介于白盒測試與黑盒測試之間的，可以這樣理解，灰盒測試關(guān)注輸出對于輸入的正確性，同時也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細(xì)、完整，只是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運(yùn)行狀態(tài)，有時候輸出是正確的，但內(nèi)部其實(shí)已經(jīng)錯誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會很低，因此需要采取這樣的一種灰盒的方法。
1）靜態(tài)測試（static testing）
靜態(tài)測試就是不實(shí)際運(yùn)行被測軟件，而只是靜態(tài)地檢查程序代碼、界面或文檔中可能存在的錯誤的過程。
包括對代碼測試、界面測試和文檔測試三個方面：
? ? 對于代碼測試，主要測試代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范。
? ? 對于界面測試，主要測試軟件的實(shí)際界面與需求中的說明是否相符。
? ? 對于文檔測試，主要測試用戶手冊和需求說明是否符合用戶的實(shí)際需求。
2）動態(tài)測試（dynamic testing）
動態(tài)測試就是實(shí)際運(yùn)行被測程序，輸入相應(yīng)的測試數(shù)據(jù)，檢查實(shí)際輸出結(jié)果和預(yù)期結(jié)果是否相符的過程，所以判斷一個測試屬于動態(tài)測試還是靜態(tài)的，唯一的標(biāo)準(zhǔn)就是看是否運(yùn)行程序。
黑盒測試有可能是動態(tài)測試（運(yùn)行程序，看輸入輸出）, 也有可能是靜態(tài)測試（不運(yùn)行,只看界面）?
白盒測試有可能是動態(tài)測試（運(yùn)行程序并分析代碼結(jié)構(gòu)）, 也有可能是靜態(tài)測試（不運(yùn)行程序 , 只靜態(tài)察看代碼）
動態(tài)測試有可能是黑盒測試（運(yùn)行 , 只看輸入輸出）, 也有可能是白盒測試 （運(yùn)行并分析代碼結(jié)構(gòu)）
? ? 靜態(tài)測試有可能是黑盒測試（不運(yùn)行，只察看界面）, 也有可能是白盒測試（不運(yùn)行 , 只察看代碼）
1）人工測試
人工測試能通過人為的邏輯判斷效驗(yàn)當(dāng)前的步驟是否正確，同時用例的執(zhí)行具有一定步驟跳躍性，能夠清楚知道邏輯，細(xì)致定位問題。
如果修改bug所需時間稍長，那么想將人工測試應(yīng)用于回歸測試將變得異常困難。這是因?yàn)樾枰獪y試的測試用例太多，所以需要引入自動化測試。
2）自動化測試
執(zhí)行的對象是腳本，能通過人為的邏輯判斷效驗(yàn)當(dāng)前的步驟是否正確實(shí)現(xiàn)，用例步驟之間關(guān)聯(lián)性強(qiáng)，不像手工測試用例那么跳躍。另外也是用來保證產(chǎn)品主體功能正確和完整，讓測試人員從繁重的工作中解脫出來。
可以更好的利用資源。在夜間執(zhí)行自動測試用例。測試具有移植性和可重復(fù)性。好的測試腳本往往具有較好的平臺移植性?？梢愿斓貙④浖葡蚴袌觥Ｒ?yàn)樽詣訙y試節(jié)省了大量的時間。但是自動化測試要求的先期投入比較大，而且要求人員必須經(jīng)過嚴(yán)格的培訓(xùn)。
1）冒煙測試
冒煙測試，是對軟件的基本功能進(jìn)行測試，測試對象是每一個新編譯的需要正式測試的軟件版本，
目的是確認(rèn)軟件的基本功能正常，保證軟件系統(tǒng)能正常跑起來，可以進(jìn)行后續(xù)的正常測試工作的進(jìn)
行，如果最基本的測試都有問題了，就直接打回開發(fā)部了，所以正式交付的測試版本，必須先通過
冒煙測試的考驗(yàn)
2）回歸測試
回歸測試是指在發(fā)生修改之后重新測試先前的測試以保證修改的正確性。理論上，對軟件的任何新
版本，都需要進(jìn)行回歸測試，驗(yàn)證以前發(fā)現(xiàn)和修復(fù)的錯誤是否在新軟件版本上再現(xiàn)，并確認(rèn)曾經(jīng)通
過的功能不會出現(xiàn)問題。
3）隨機(jī)測試
隨機(jī)測試是根據(jù)測試說明書執(zhí)行用例測試的重要補(bǔ)充手段，是保證測試覆蓋完整性的有效方式和過
程。?隨機(jī)測試主要是對被測軟件的一些重要功能進(jìn)行復(fù)測，也包括測試那些當(dāng)前的測試用例沒有
覆蓋到的部分。在測試中，測試數(shù)據(jù)是隨機(jī)產(chǎn)生的。
4）探索測試
探索式測試（Exploratory Testing）是一種自由的軟件測試風(fēng)格，強(qiáng)調(diào)測試人員同時展開測試學(xué)
習(xí)、測試設(shè)計(jì)、測試執(zhí)行和測試結(jié)果評估等活動，以持續(xù)優(yōu)化測試工作。
測試專家Cem Kaner博士在1983年提出的。
測試需要探索，而探索需要大量的思考。積極思考的探索式測試是具有挑戰(zhàn)性的智力過程，常常需
要在不確定的順序反復(fù)實(shí)施鉆研、嘗試、迂回、調(diào)整、評估等活動。好的探索式測試不會使測試更
簡單，但是它會使測試更有效，從而在測試速度和缺陷發(fā)現(xiàn)上獲得更多的匯報。
?
工作流程
?
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/121220.html
摘要：在不同場合下，客戶關(guān)系管理可能是一個管理學(xué)術(shù)語，也可能是一個軟件系統(tǒng)。客戶的跟進(jìn)方式時間結(jié)果跟進(jìn)對象以及溝通細(xì)節(jié)全程跟蹤記錄，避免因業(yè)務(wù)人員離職而導(dǎo)致的客戶流失。主要功能包括客戶反饋解決方案滿意度調(diào)查等功能。 在不同場合下，CRM（客戶關(guān)系管理）可能是一個管理學(xué)術(shù)語，也可能是一個軟件系統(tǒng)。我們通常所指的CRM，指用計(jì)算機(jī)自動化分析銷售、市場營銷、客戶服務(wù)以及應(yīng)用等流程的軟件系統(tǒng)。通俗地...
摘要：在不同場合下，客戶關(guān)系管理可能是一個管理學(xué)術(shù)語，也可能是一個軟件系統(tǒng)?？蛻舻母M(jìn)方式時間結(jié)果跟進(jìn)對象以及溝通細(xì)節(jié)全程跟蹤記錄，避免因業(yè)務(wù)人員離職而導(dǎo)致的客戶流失。主要功能包括客戶反饋解決方案滿意度調(diào)查等功能。 在不同場合下，CRM（客戶關(guān)系管理）可能是一個管理學(xué)術(shù)語，也可能是一個軟件系統(tǒng)。我們通常所指的CRM，指用計(jì)算機(jī)自動化分析銷售、市場營銷、客戶服務(wù)以及應(yīng)用等流程的軟件系統(tǒng)。通俗地...
摘要：開始翻譯函數(shù)式編程專有名詞庫在翻譯的過程中，難免會遇到很多描述不太清楚的專有名詞，一個辦法是小組內(nèi)進(jìn)行討論，最后商量出來結(jié)果，小組內(nèi)統(tǒng)一翻譯。因?yàn)楸緯闹黝}是函數(shù)式編程，所以這個名詞庫里大部分都是函數(shù)式編程相關(guān)的專有名詞。 在平時的工作中，我們都會經(jīng)常查閱一些英文文檔來解決平時遇到的問題和拓寬視野。看到好的文章或者書籍有沒有想要和小伙伴分享的沖動，那么我們一起來翻譯吧～ 翻譯主張 信 ...
摘要：開始翻譯函數(shù)式編程專有名詞庫在翻譯的過程中，難免會遇到很多描述不太清楚的專有名詞，一個辦法是小組內(nèi)進(jìn)行討論，最后商量出來結(jié)果，小組內(nèi)統(tǒng)一翻譯。因?yàn)楸緯闹黝}是函數(shù)式編程，所以這個名詞庫里大部分都是函數(shù)式編程相關(guān)的專有名詞。 在平時的工作中，我們都會經(jīng)常查閱一些英文文檔來解決平時遇到的問題和拓寬視野?？吹胶玫奈恼禄蛘邥袥]有想要和小伙伴分享的沖動，那么我們一起來翻譯吧～ 翻譯主張 信 ...
摘要：開始翻譯函數(shù)式編程專有名詞庫在翻譯的過程中，難免會遇到很多描述不太清楚的專有名詞，一個辦法是小組內(nèi)進(jìn)行討論，最后商量出來結(jié)果，小組內(nèi)統(tǒng)一翻譯。因?yàn)楸緯闹黝}是函數(shù)式編程，所以這個名詞庫里大部分都是函數(shù)式編程相關(guān)的專有名詞。 在平時的工作中，我們都會經(jīng)常查閱一些英文文檔來解決平時遇到的問題和拓寬視野?？吹胶玫奈恼禄蛘邥袥]有想要和小伙伴分享的沖動，那么我們一起來翻譯吧～ 翻譯主張 信 ...
閱讀 3855·2021-10-11 10:58
閱讀 2320·2021-10-08 10:05
閱讀 2147·2021-09-27 13:34
閱讀 3743·2019-08-30 15:53
閱讀 2812·2019-08-30 14:02
閱讀 3636·2019-08-29 16:55
閱讀 721·2019-08-29 15:41
閱讀 1256·2019-08-29 15:23
