1、測試的概念及目的：在規(guī)定的條件下對程序進行操作，以發(fā)現(xiàn)程序錯誤，衡量軟件質(zhì)量，并對其是否能滿足設計要求進行評估的過程。

軟件測試的主要工作內(nèi)容是驗證和確定

軟件測試的目的：

測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤

一個成功的測試用例在于發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤

一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試

確保產(chǎn)品完成了它所承諾或公布的功能，并且用戶可以訪問到的功能都有明確的書面說明。

確保產(chǎn)品滿足性能和效率的要求

確保產(chǎn)品是健壯的和適應用戶環(huán)境的

軟件測試的原則：

測試用例中一個必須部分是對預期輸出或接過進行定義

程序員應避免測試自己編寫的程序

編寫軟件的組織不應當測試自己編寫的軟件

應當徹底檢查每個測試的執(zhí)行結(jié)果

測試用例的編寫不僅應當根據(jù)有效和預料到的輸入情況，而且也應當根據(jù)無效和未預料到的輸入情況

檢擦程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應該做的”

應避免測試用例用后即棄，除非軟件本身就是個一次性的軟件

計劃測試工作時不應默許假定不會發(fā)現(xiàn)錯誤

程序某部分存在更多錯誤的可能性，與該部分已經(jīng)發(fā)現(xiàn)錯誤的數(shù)量成正比

軟件測試是一項極富創(chuàng)造性，極具智力的挑戰(zhàn)性的工作

2、測試分類

根據(jù)階段分類：

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

單元測試：單元測試是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工作，通常由開發(fā)人員進行。

集成測試：集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發(fā)現(xiàn)與接口有關的問題。由于在產(chǎn)品提交到測試部門前，產(chǎn)品開發(fā)小組都要進行聯(lián)合調(diào)試，因此在大部分企業(yè)中集成測試是由開發(fā)人員來完成的。

系統(tǒng)測試：系統(tǒng)測試是在集成測試通過后進行的，目的是充分運行系統(tǒng)，驗證各子系統(tǒng)是否都能正常工作并完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產(chǎn)品的質(zhì)量有重大的影響。

驗收測試：驗收測試以需求階段的《需求規(guī)格說明書》為驗收標準，測試時要求模擬實際用戶的運行環(huán)境。對于實際項目可以和客戶共同進行，對于產(chǎn)品來說就是最后一次的系統(tǒng)測試。測試內(nèi)容為對功能模塊的全面測試，尤其要進行文檔測試。

按是否看代碼

白盒測試、黑盒測試、灰盒測試

3、黑盒測試設計方法、

等邊界值分析法、等價類劃分、錯誤猜測法、因果圖法、狀態(tài)圖法、測試大綱法、隨機測試、場景法、正交實驗法

4、白盒測試設計方法

語句覆蓋、判定覆蓋、條件覆蓋、路徑覆蓋、條件組合覆蓋

5、測試人員在軟件開發(fā)過程中的任務是什么？

1、盡可能早的找出系統(tǒng)中的Bug；

2、避免軟件開發(fā)過程中缺陷的出現(xiàn)；

3、衡量軟件的品質(zhì)，保證系統(tǒng)的質(zhì)量；

4、關注用戶的需求，并保證系統(tǒng)符合用戶需求。

總的目標是：確保軟件的質(zhì)量。

6、測試用例構成

用例編號?　測試項目?　測試標題?　重要級別?　預置條件　?輸入數(shù)據(jù)?　執(zhí)行步驟　　?預期結(jié)果

7、如何對網(wǎng)站進行端到端的測試？

需求分析——指定測試計劃——設計測試用例——開展測試

首先，查找需求說明、網(wǎng)站設計等相關文檔，分析測試需求。

制定測試計劃，確定測試范圍和測試策略，一般包括以下幾個部分：功能性測試；界面測試；性能測試；數(shù)據(jù)庫測試；安全性測試；兼容性測試

設計測試用例：

功能性測試可以包括，但不限于以下幾個方面：

鏈接測試。鏈接是否正確跳轉(zhuǎn)，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回。

提交功能的測試。

多媒體元素是否可以正確加載和顯示。

多語言支持是否能夠正確顯示選擇的語言等。

界面測試可以包括但不限于一下幾個方面：

頁面是否風格統(tǒng)一，美觀

頁面布局是否合理，重點內(nèi)容和熱點內(nèi)容是否突出

控件是否正常使用

對于必須但未安裝的控件，是否提供自動下載并安裝的功能

文字檢查

性能測試一般從以下兩個方面考慮：

壓力測試；負載測試；強度測試

數(shù)據(jù)庫測試要具體決定是否需要開展。數(shù)據(jù)庫一般需要考慮連結(jié)性，對數(shù)據(jù)的存取操作，數(shù)據(jù)內(nèi)容的驗證等方面。

安全性測試：

基本的登錄功能的檢查

是否存在溢出錯誤，導致系統(tǒng)崩潰或者權限泄露

相關開發(fā)語言的常見安全性問題檢查，例如SQL注入等

如果需要高級的安全性測試，確定獲得專業(yè)安全公司的幫助，外包測試，或者獲取支持

兼容性測試，根據(jù)需求說明的內(nèi)容，確定支持的平臺組合：

瀏覽器的兼容性；

操作系統(tǒng)的兼容性；

軟件平臺的兼容性；

數(shù)據(jù)庫的兼容性

開展測試，并記錄缺陷。合理的安排調(diào)整測試進度，提前獲取測試所需的資源，建立管理體系（例如，需求變更、風險、配置、測試文檔、缺陷報告、人力資源等內(nèi)容）。

定期評審，對測試進行評估和總結(jié)，調(diào)整測試的內(nèi)容

8、軟件生存周期及其模型是什么？

軟件生存周期（Software life cycle）又稱為軟件生命期，生存期。是指從形成開發(fā)軟件概念起，所開發(fā)的軟件使用以后，知道失去使用價值消亡為止的整個過程。一般來說，整個生存周期包括計劃（定義）、開發(fā)、運行（維護）三個時期，每個時期又劃分為若干個階段。每個階段有明確的任務。

周期模型（典型的幾種）：

瀑布模型

快速原型模型：快速原型模型允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，快速設計開發(fā)出軟件系統(tǒng)的原型，該原型向用戶展示待開發(fā)軟件的全部或部分功能和性能；用戶對該原型進行測試評定，給出具體改進意見以豐富細化軟件需求；開發(fā)人員據(jù)此對軟件進行修改完善，直至用戶滿意認可之后，進行軟件的完整實現(xiàn)及測試、維護。

迭代模型：迭代包括產(chǎn)生產(chǎn)品發(fā)布（穩(wěn)定、可執(zhí)行的產(chǎn)品版本）的全部開發(fā)活動和要使用該發(fā)布必需的所有其他外圍元素。在某種程度上，開發(fā)迭代是一次 完整地經(jīng)過所有工作流程的過程：需求分析、設計、實施和測試工作流程。實質(zhì)上，它類似小型的瀑布式項目。RUP認為，所有的階段都可以細分為迭代。每一次 的迭代都會產(chǎn)生一個可以發(fā)布的產(chǎn)品，這個產(chǎn)品是最終產(chǎn)品的一個子集。

生命周期階段：

軟件計劃與可行性分析

需求分析

軟件設計

編碼

軟件測試

運行與維護

9、什么是軟件質(zhì)量？

概括地說，軟件質(zhì)量就是“軟件與明確的和隱含的定義的需求相一致的程度”。具體地說，軟件質(zhì)量是軟件符合明確敘述的功能和性能需求、文檔中明確描述 的開發(fā)標準、以及所有專業(yè)開發(fā)的軟件都應具有的隱含特征的程度。 影響軟件質(zhì)量的主要因素，這些因素是從管理角度對軟件質(zhì)量的度量。可劃分為三組，分別反應用戶在使用軟件產(chǎn)品時的三種觀點。正確性、健壯性、效率、完整性、可用性、風險（產(chǎn)品運行）；可理解性、可維修性、靈活性、可測試性（產(chǎn)品修改）；可移植性、可再用性、互運行性（產(chǎn)品轉(zhuǎn)移）。

10、軟件產(chǎn)品質(zhì)量特性是什么?

功能性：適應性、準確性、互操作性、依從性、安全性。

可靠性：成熟性、容錯性、易恢復性。

可使用性：易理解性、易學習性、易操作性。

效率：時間特性、資源特性。

可維護性：易分析性、易變更性、穩(wěn)定性、易測試性。

可移植性： 適應性、易安裝性、遵循性、易替換性

11、軟件驗收測試的合格通過準則

軟件需求分析說明書中定義的所有功能已全部實現(xiàn)，性能指標全部達到要求。

所有測試項沒有殘余的一級二級三級的錯誤。

立項審批表、需求分析文檔、設計文檔和編碼實現(xiàn)一致。

驗收測試工件齊全（測試計劃，測試用例，測試日志，測試通知單，測試分析報告）

12、軟件驗收測試包括

正式驗收測試

非正式驗收測試：包括α測s試和【由用戶、測試人員、開發(fā)人員共同參與的內(nèi)部測試】、β測試【內(nèi)側(cè)后的公測，即完全交給最終用戶的測試】

13、系統(tǒng)測試的策略

功能測試、性能測試、壓力測試、容量測試、安全性測試、可用性測試、GUI測試、安裝測試、配置測試、異常測試、備份測試、健壯性測試、文檔測試、在線幫助測試、網(wǎng)絡測試、穩(wěn)定性測試

14、設計系統(tǒng)測試計劃需要參考的項目文檔

軟件測試計劃

軟件需求規(guī)范

迭代計劃

15、系統(tǒng)集成測試主要包括以下過程：

1. 構建的確認過程。

2. 補丁的確認過程。

3. 系統(tǒng)集成測試測試組提交過程。

4. 測試用例設計過程。

5. 測試代碼編寫過程。

6. Bug的報告過程。

7. 每周/每兩周的構建過程。

8. 點對點的測試過程。

9. 組內(nèi)培訓過程

16、性能測試類型包括負載測試，強度測試，容量測試。

負載測試- 【在一定的工作負荷下，系統(tǒng)的負荷及響應時間】核實在保持配置不變的情況下，測試對象在不同操作條件（如不同用戶數(shù)、事務數(shù)等）下性能行為的可接受性。

強度測試- 【在一定的工作負荷下，在較長時間跨度內(nèi)系統(tǒng)連續(xù)運行給系統(tǒng)性能所造成的影響】核實測試對象性能行為在異?；驑O端條件（如資源減少或用戶數(shù)過多）之下的可接受性。

容量測試- 核實測試用戶同時使用軟件程序的最大數(shù)量。容量測試是面向數(shù)據(jù)的，并且它的目的是顯示系統(tǒng)可以處理目標內(nèi)確定的數(shù)據(jù)表容量。容量測試的目的是通過測試預先分析出反應軟件應用特征的某項指標的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)），系統(tǒng)在其極限值狀態(tài)在沒有出現(xiàn)任何軟件故障或還能保持主要功能正常運行。

17、典型的軟件開發(fā)模型

瀑布模型：

　　計劃 → 需求分析?→ ?設計?→ ?編碼?→ ?測試?→ ?運行維護

特點：①軟件開發(fā)的各項活動嚴格按照線性方式進行。

　　　 ②當前活動接受上一項活動的工作結(jié)果。

　　? ? ③當前活動的工作結(jié)果需要進行驗證。

缺點：①由于開發(fā)模型是線性的，增加了開發(fā)的風險。

　　? ? ②早期的錯誤可能要等到開發(fā)后期的階段才能發(fā)現(xiàn)。

原型模型：

　　根據(jù)用戶的主要需求，建立一個軟件原型，然后讓用戶進行評價，然后根據(jù)用戶的評價和提出的更多的需求來開發(fā)出相應的軟件產(chǎn)品?？蛻襞c開發(fā)公司緊密聯(lián)系，開發(fā)周期長。開發(fā)會受到需求變更的影響。

特征：①實現(xiàn)客戶與系統(tǒng)的交互。

? ? ? ? ? ? ② 進一步細化待開發(fā)軟件需求。

　　　? ③開發(fā)人員可以確定客戶的真正需求是什么。

螺旋模型：

　　制定計劃 →?? 風險分析 →?? 實施工程（需求確認、軟件需求、軟件產(chǎn)品設計、設計確認與認證、詳細設計、開發(fā)、測試）?→?? 客戶評估

特點：①螺旋模型是將瀑布模型與快速原型模型結(jié)合起來。

　　 ?　②強調(diào)了其他模型所忽視的風險分析。

　　? ? ?③每一次螺旋包括4個步驟：制定計劃、風險分析、實施工程、客戶評估。

缺點：①強調(diào)風險分析，但要求許多客戶接受并相信這種分析，是不容易的。

敏捷開發(fā)模型：

特點：①短周期開發(fā)。

　　?、谠隽块_發(fā)。

　　　③?由程序員和測試人員編寫的自動化測試來監(jiān)控開發(fā)進度。

　　　④通過口頭溝通、測試和源代碼來交流系統(tǒng)的結(jié)構和意圖。

　　　⑤編寫代碼之前先寫測試代碼。也叫做測試先行。

缺點：?①團隊的組建較難，人員素質(zhì)要求較高。

　　　②對測試員要求完全掌握各種腳本語言編程，會單元測試。

增量模型：

瀑布模型和快速模型都是一次性把軟件提交給客戶的，而增量模型是分批的把軟件提交給客戶的，但也要擔一定的風險，就是最后合在一起未必能成功。把待開發(fā)的軟件系統(tǒng)模塊化，將每個模塊作為一個增量組件，從而分批次地分析、設計、編碼和測試這些增量組件

18、自頂向下測試

目的：從頂層控制（主控模塊）開始，采用同設計順序一樣的思路對被測系統(tǒng)進行測試，來驗證系統(tǒng)的穩(wěn)定性。

定義：自頂向下的集成測試就是按照系統(tǒng)層次結(jié)構圖，以主程序模塊為中心，自上而下按照深度優(yōu)先或者廣度優(yōu)先策略，對各個模塊一邊組裝一邊進行測試

總結(jié)特點：從上到下（分層），從左到右（排序）

這句話可以這樣理解先從整體上從上到下排列

第一層有：M1

第二層有：M3，M4，M2

第三層有：M6，M5

第四層有：M7

然后再從每層進行細分，從左到右排列

第一層排序后：M1

第二層排序后：M2，M3，M4

第三層排序后：M5，M6

第四層排序后：M7

再整合起來，自頂向下測試方法（廣度優(yōu)先）就出來了：M1，M2，M3，M4，M5，M6，M7

原文：https://blog.csdn.net/fbvukn/article/details/85853826

19、自底向上測試方法

目的：從依賴性最小的底層模塊開始，按照層次結(jié)構圖，逐層向上集成，驗證系統(tǒng)的穩(wěn)定性。

定義：自底向上集成是從系統(tǒng)層次結(jié)構圖的最底層模塊開始進行組裝和集成測試的方式。對于某一個層次的特定模塊，因為它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測試完成，所以不再需要樁模塊。在測試過程中，如果想要從子模塊得到信息可以通過直接運行子模塊得到。也就是說，在集成測試的過程中只需要開發(fā)相應的驅(qū)動模塊就可以了。

20、自頂向下測試和自底向上測試方法比較：

自頂向下測試：

優(yōu)點：

1、如果主要的缺陷發(fā)生在程序的頂層將非常有利

2、一旦引入I/O功能，提交測試或更容易

3、早期的程序框架可以進行演示，并可激發(fā)積極性

缺點：

1、必須開發(fā)樁模塊

2、樁模塊要比最初表現(xiàn)的更復雜

3、在引入I/O功能之前，向樁模塊中引入測試用例比較困難

4、創(chuàng)建測試環(huán)境可能很困難，甚至無法實現(xiàn)

5、觀察測試輸出很困難

6、使人誤解設計和測試可以交迭進行

7、會導致特定模塊測試的完成延后

自底向上測試

1、如果主要的缺陷發(fā)生在程序的底層將非常有利

2、測試環(huán)境比較容易建立

3、觀察測試輸出比較容易

缺點：

1、必須開發(fā)驅(qū)動模塊

2、直到最后一個模塊添加進去，程序從才形成一個整體

執(zhí)行測試：

當測試用例造成模塊輸出的實際結(jié)果與預期結(jié)果不匹配的情況時，可能存在：要么該模塊存在錯誤，要么預期結(jié)不正確（測試用例不正確）。為了將這種混亂降低到最小程度，應在測試執(zhí)行之前對測試用例集進行審核或檢查（即對測試用例進行測試）。

---------------------

作者：ValDC_Morning

來源：CSDN

原文：https://blog.csdn.net/ValDC_Morning/article/details/78750328

版權聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！