一 軟件測試行業(yè)基礎介紹

1. 為什么需要軟件測試

• 一款軟件從無到有會經(jīng)歷很多開發(fā)階段由不同的人來參與開發(fā)，所以最終產(chǎn)出的軟件功能會存在問題。因此為了保證軟件的功能是可用的，我們必須進行測試；

• 當前的軟件行業(yè)已經(jīng)不再是功能為王了，用戶不僅僅只盯著功能是否滿足需求，還會對軟件是否容易上手，執(zhí)行效率是否ok...等一系列其他體驗都有了更高的需求，所以這也需要我們對軟件進行大量的測試。

2. 為什么選擇軟件測試

• 國內(nèi)的軟件行業(yè)對于專業(yè)的軟件測試人員需求是慢慢變大；
• 有些人喜歡喜歡創(chuàng)造世界所以他們做了開發(fā)，而我們就是希望世界更加完美。

3. 為什么不讓開發(fā)自己做測試

• 當前行業(yè)有許多的測試從業(yè)人員本身之前都是開發(fā)崗；
• 專業(yè)度：軟件測試和軟件開發(fā)分別屬于軟件行業(yè)當中兩個不同的技術方向。所以讓專業(yè)的人做專業(yè)的事對質(zhì)量更加有保證；
• 思維定式：在軟件的開發(fā)周期中，對于程序員來說他們大多數(shù)的時間都是思考如何實現(xiàn)具體的軟件功能，而不會從用戶的角度考慮如何去“奇葩”的使用這些功能；
• 測試用例：相對于開發(fā)來說，產(chǎn)品就相當于是他們的“孩子”，所以“下手”就不會那么狠。

二 軟件測試基本介紹

軟件知識回顧
1. 軟件的組成

• 程序
• 數(shù)據(jù)
• 文檔

2. 軟件的分類

• 按層次劃分：系統(tǒng)軟件、應用軟件

• 按組織劃分：商業(yè)軟件、開源軟件

• 按結構劃分：單機軟件、C/S結構、B/S結構

1. 軟件測試定義

使用人工或自動化手段運行程序，為了發(fā)現(xiàn)軟件的錯誤而執(zhí)行檢驗的一個過程。

2. 軟件測試目的

以最少的人力、物力、時間找到軟件中的缺陷并修改，從而回避風險。

3.軟件測試作用

• 通過測試工作可以發(fā)現(xiàn)并修復軟件當中存在的缺陷，從而提高用戶對產(chǎn)品的使用信心；
• 測試可以記錄軟件 運行過程中產(chǎn)生的一些數(shù)據(jù)，從而為決策提供數(shù)據(jù)支持；
• 測試可以降低同類型產(chǎn)品開發(fā)遇到問題的風險。

4. 軟件測試的七個原則

所謂的測試的原則就是我們在執(zhí)行測試工作時必須要遵循的一些規(guī)則。

• 測試顯示軟件存在缺陷(Testing shows presence of defects)
  測試只能證明軟件中存在缺陷，但并不能證明軟件中不存在缺陷。軟件測試是為了降低存在缺陷的可能性，即便是沒有找到缺陷，也不能證明軟件是完美的。
• 窮盡測試是不可能的(Exhaustive testing is impossible)
  現(xiàn)在軟件的國模越來越大，復雜度越來越高，想做到完全性的測試是不可能的。在測試階段，測試人員可以根據(jù)風險和優(yōu)先級來進行集中地高強度的測試，從而保證軟件的質(zhì)量。
• 測試盡早介入(Testing early)
  為什么測試要盡早介入呢，簡單的說就是保證軟件質(zhì)量，降低風險和成本。測試人員一般在需求階段就開始介入，使缺陷在需求
  或設計階段就被發(fā)現(xiàn)，缺陷發(fā)現(xiàn)越早，修復的成本就越小。
• 缺陷集群性(2/8原則) (Defect clusteringe)
  缺陷集群性表名小部分模塊包含大部分的缺陷。軟件測試中存在Pareto原則：80%的缺陷發(fā)現(xiàn)在20%的模塊中；
  一個功能模塊發(fā)現(xiàn)的缺陷越高，那存在的未被發(fā)現(xiàn)的缺陷也越高，故發(fā)現(xiàn)的缺陷與未發(fā)現(xiàn)的缺陷成正比。
• 殺蟲劑悖論(Pesticide Paradox)
  反復使用相同的殺蟲劑會導致害蟲對殺蟲劑產(chǎn)生免疫而無法殺死害蟲。軟件測試也一樣。如果一直使用相同的測試方法或手段，可能無法發(fā)現(xiàn)新的bug；
  為了解決這個問題，測試用例應當定期修訂和評審，增加新的或不同的測試用例幫助發(fā)現(xiàn)更多的缺陷。
  測試人員不能一直依賴于現(xiàn)有的測試技術，而要不斷地提升測試方法以提高測試效率。
• 測試活動依賴于測試內(nèi)容(Testing is context dependent)
  根據(jù)業(yè)務的不同，軟件測試內(nèi)用也分為不同的行業(yè)，比如游戲行業(yè)、電商行業(yè)、金融行業(yè)。不同的行業(yè)，測試活動的開展都有所不同，比如測試技術、測試工具的選擇，測試流程都不盡相同，所以軟件測試的活動開展依賴于所測試的內(nèi)容。
• 沒有錯誤是好事謬論
  有可能99%沒有bug的軟件也是不能使用的。如果對錯誤的需求進行了徹底的測試，這種情況就發(fā)生了。軟件測試不僅是找出缺陷，同時也需要確認軟件是否滿足需求。如果開發(fā)出來的產(chǎn)品不滿足用戶的需求，即便找到和修復了缺陷也作用不大。

三 測試對象

對于當前的測試行業(yè)來說我們最經(jīng)常測試的主體就是軟件（主體功能），但是需要我們明白的是一個軟件也不僅僅只有功能需要測試。我們可以將軟件分為三個部分組成：功能集合+使用說明+配置數(shù)據(jù)。對于一款軟件來說從無到有需要不同的過程，我們可以將這個過程分為不同的階段，然后每個階段都會相應有測試對象。

1. 需求分析階段：各種需求規(guī)格說明；
2. 軟件架構設計：API接口文檔（接口測試）；
3. 編碼實現(xiàn)階段：源代碼（白盒測試、單元測試）；
4. 系統(tǒng)功能使用：軟件功能主體（當前行業(yè)做的最多的一種測試）。

四、測試級別（測試階段）

軟件的開發(fā)都會依據(jù)相應的開發(fā)模型，而測試級別指的就是在這個模型當中我們?nèi)藶榈拈_發(fā)步驟。其中對于測試來說我們最常見的級別分類如下：
1. 單元測試
單元測試是完成最小的軟件設計單元（一般就是類、函數(shù)、組件）的驗證工作，目標是確保模塊被正確的編碼，通常情況下是白盒的，對代碼風格和規(guī)則、程序設計和結構，業(yè)務邏輯等進行靜態(tài)測試，及早的發(fā)現(xiàn)和解決不易顯現(xiàn)的錯誤。
2. 集成測試
通過測試發(fā)現(xiàn)與模塊接口有關的問題。目標是把通過了單元測試的模塊拿來，構造一個在設計中所描述的程序結構，應當避免一次性的集成（除非軟件規(guī)模很?。?，而采用增量集成。
3. 系統(tǒng)測試
根據(jù)軟件需求規(guī)范的要求進行系統(tǒng)測試，確認系統(tǒng)滿足需求的要求，由測試人員充當用戶的角色對軟件的主體功能進行測試。
4. 回歸測試
當發(fā)現(xiàn)并修改缺陷后，或在軟件中添加新的功能后，重新測試。用來檢查被發(fā)現(xiàn)的缺陷是否被改正，并且所做的修改沒有引發(fā)新的問題?；貧w測試可以通過人工重新行測試用例，也可以使用自動化的工具來進行。
5. 驗收測試

• 配置審查
  確保已開發(fā)軟件的所有文件資料均已編寫齊全，并分類編目。
• Alpha測試
  是由用戶在開發(fā)者的場所來進行的，在一個受控的環(huán)境中進行。
• Beta測試
  由軟件的最終用戶在一個或多個用戶所來進行的，開發(fā)者通常不在現(xiàn)場，用戶記錄測試中遇到對的問題并報告給開發(fā)者，開發(fā)者對系統(tǒng)進行最后的修改，并開始準備發(fā)布最終軟件。

五 系統(tǒng)測試分類

1. 功能測試

驗證當前軟件主體功能是否實現(xiàn)。

2. 兼容性測試

驗證當前軟件在不同的環(huán)境下是否還可以使用。windows環(huán)境能使用嗎？Linux環(huán)境能使用嗎？谷歌瀏覽器能使用嗎？其他瀏覽器呢？不同設備上呢？mac？ipad？

3. 安全測試

驗證軟件是否只是對授權用戶提供功能使用。比如銀行卡，支付寶等等。

4. 性能測試

相當于當前軟件消耗的資源，產(chǎn)出能力；運行效率。

六 常用系統(tǒng)測試方法

1. 按測試對象分類

• 白盒測試
  軟件底層代碼功能實現(xiàn)，同時邏輯正確。
• 黑盒測試
  測試軟件外在功能是否可用（點點點）。
• 灰盒測試
  介于兩者之間（接口測試）。

2. 按測試對象是否執(zhí)行分類

• 靜態(tài)測試
  測試對象不運行，側重文檔和界面。
• 動態(tài)測試
  將軟件運行在真實環(huán)境當中
  思考：黑盒測試屬于靜態(tài)還是動態(tài)？白盒呢？
  黑盒測試有可能是動態(tài)測試（運行程序，看輸入輸出），也有可能是靜態(tài)測試（不運行，只看界面）
  白盒測試有可能是動態(tài)測試（運行程序并分析代碼結構），也有可能是靜態(tài)測試(不運行程序，只靜態(tài)查看代碼
  動態(tài)測試有可能是黑盒測試（運行，只看輸入輸出），也有可能是白盒測試（運行并分析代碼結構）
  靜態(tài)測試有可能是黑盒測試（不運行，只查看界面），也有可能是白盒測試（不運行，只查看代碼）

3. 按測試手段分類

• 手工測試
  由測試人員動手的對被測對象進行驗證，優(yōu)點就是可以靈活的改變測試操作和環(huán)境。
• 自動化測試
  兩種形式：一種是自己寫測試腳本，另外一種是通過第三方測試工具對被測試對象進行測試
  優(yōu)點：高效率完成人不能做的測試。

七 軟件質(zhì)量特性

描述當前軟件是否好用，在當前的軟件行業(yè)里面我們所采用的的一套標準是基于ISO這個組織定制的，從軟件測試角度而言，測試工程師需要了解每個特性及其子特性，以便于在分析測試需求、提取測試需求及評價被測對象時有的放矢，依據(jù)標準開展有效的測試活動。

1. 功能性：指軟件在指定條件下使用時，滿足用戶明確和隱含需求的功能的能力。

• 適合性：軟件為指定的任務和用戶目標提供一組合適功能的能力；
• 準確性：軟件提供具體有所需精確度的正確或相符的結果或效果的能力；
• 互操作性：軟件與一個或更多的規(guī)定系統(tǒng)進行交互的能力；
• 保密安全性：軟件保護信息和數(shù)據(jù)的能力，以使未授權的人員或系統(tǒng)不能閱讀或修改這些信息和數(shù)據(jù)，而不拒絕授權人員或系統(tǒng)對它們的訪問；
• 功能性依從性：軟件遵循與功能性相關的標準、約定或法規(guī)以及類似規(guī)定的能力。這些標準要考慮國際標準、國家標準、行業(yè)標準、企業(yè)內(nèi)部規(guī)范等；

2. 易用性：指在指定條件下使用時，軟件被理解、學習、使用和吸引用戶的能力。

• 易理解性：軟件使用戶能理解軟件是否合適，以及如何能將軟件用于特定的任務和使用環(huán)境的能力；
• 易學性：軟件使用戶能學習其應用的能力；
• 易操作性：軟件使用戶能操作和控制它的能力；
• 吸引性：軟件吸引用戶的能力；
• 易用性依從性：軟件遵循與易用性相關的標準、約定、風格指南或法規(guī)的能力。這些標準要考慮國際標準、國家標準、行業(yè)標準、企業(yè)內(nèi)部規(guī)范等，如企業(yè)內(nèi)部的界面規(guī)范等；

3. 可靠性：可靠性是指軟件在指定條件下使用時，維持規(guī)定的性能級別的能力?？煽啃砸笥袃蓚€重要的概念：平均故障修復時間（mean time to repair，MTTR）、平均無故障時間（mean timebetween failures，MTBF），MTTR值越小，說明故障修復時間越短，故障處理響應速度較快，MTBF值越大，說明軟件故障率低，系統(tǒng)可靠性高。

• 成熟性： 軟件避免因為某些錯誤而導致失效或故障的能力；
• 容錯性： 在軟件出現(xiàn)故障或者違反指定接口的情況下，軟件維持規(guī)定的性能級別的能力；
• 易恢復性： 在失效發(fā)生的情況下，軟件重建規(guī)定的性能級別并恢復受直接影響的數(shù)據(jù)的能力；
• 可靠性依從性： 軟件遵循與可靠性相關的標準、約定或法規(guī)的能力。

4.效率性：效率是指在規(guī)定條件下，相對于所用資源的數(shù)量，軟件可提供適當性能的能力。

• 時間特性：在規(guī)定條件下，軟件執(zhí)行其功能時，提供適當?shù)捻憫吞幚頃r間以及吞吐率的能力，即完成用戶的某個功能需要的響應時間；
• 資源利用性：在規(guī)定條件下，軟件執(zhí)行其功能時，使用合適的資源數(shù)量和類別的能力；
• 效率依從性：軟件遵循與效率相關的標準或約定的能力。

5. 可維護性：可維護性是指軟件可被修改的能力。修改可能包括修正、改進或軟件對環(huán)境、需求和功能規(guī)格說明變化的適應。

• 易分析性：軟件診斷軟件中的缺陷、失效原因或識別待修改部分的能力；
• 易改變性：軟件使指定的修改可以被實現(xiàn)的能力；
• 穩(wěn)定性：軟件避免由于軟件修改而造成意外結果的能力；
• 易測試性：軟件使已修改軟件能被確認的能力；
• 維護性依從性：軟件遵循與維護性相關的標準或約定的能力。

6. 可移植性：可移植性是指軟件從一種環(huán)境遷移到另外一種環(huán)境的能力。

• 適應性：軟件無須采用有別于為考慮該軟件的目的而準備的活動或手段，就可能適應不同指定環(huán)境的能力；
• 易安裝性：軟件在指定環(huán)境中被安裝的能力；
• 共存性：軟件在公共環(huán)境中同與其分享公共資源的其他獨立軟件共存的能力；
• 易替換性：軟件在同樣環(huán)境下，替代另一個相同用途的指定軟件產(chǎn)品的能力；
• 可移植性依從性：軟件遵循與可移植性相關的標準或約定的能力。

八 軟件測試流程

1.需求分析評審

• 需求分析目的是理解需求，理解業(yè)務
• 弄清楚我們的產(chǎn)品有哪些功能？有哪些非功能性需求？
• 明白我們的用戶群體是什么？用戶會如何來使用我們的產(chǎn)品？

• 需求是否合理？技術實現(xiàn)難度？

  
  
  需求分析.jpg
  
  

  具體執(zhí)行如下：

  
  
  需求分析方法.jpg

2. 測試計劃制定

當對需求有完整和全面的理解后，接下來我們需要制定詳細的測試計劃，為即將開始的測試工作做好充足的準備

• 資源估算：整個項目需要多少資源？硬件資源，人力、時間資源等
• 進度控制：每個測試活動時間點控制
• 風險控制：對于在測試活動過程中出現(xiàn)問題的解決方案
• 資源配置：如何更有效率的使用資源
• 驗收標準：文檔、項目、測試過程的驗收標準定義
• 測試策略：測試中使用的測試策略

3. 測試用例設計

測試用例設計是軟件測試工作的靈魂
任何一項測試活動的核心都是測試思維，即如何進行測試。而測試用例就是測試思維的體現(xiàn)。功能的測試優(yōu)先級、如何操作、輸入什么數(shù)據(jù)、應該有什么的結果等等都體現(xiàn)在測試用例中。

4.測試用例評審

測試用例的評審就是為了給測試用例進行查漏補缺。
評審方式：

• 測試內(nèi)部評審
• 項目組評審：項目相關人員參與評審（開發(fā)、測試、產(chǎn)品等等）

5.執(zhí)行測試用例

前面的工作做的充足的話，在執(zhí)行測試用例的時候就會非常簡單了。只需要根據(jù)測試用例一條一條去執(zhí)行程序即可。發(fā)現(xiàn)缺陷就提交缺陷，測試通過就繼續(xù)執(zhí)行。
其實測試執(zhí)行的過程真的很簡單，只是在執(zhí)行的過程中各部門的協(xié)作，溝通以及各項文檔的輸出很復雜。

• 測試和開發(fā)的溝通
  “XXX 我這有個問題，你過來看下”
  “什么問題？你演示下我看看”
  “這不是問題，這個地方只能這樣做”或者 “這不是問題，我剛剛跟需求確認過的”
  “這樣做不合邏輯啊！”
  “那你說怎么處理？”
  “我覺得應該....處理”
  “你先跟需求確認下吧”
  測試與開發(fā)溝通無疑是關于某個功能或者產(chǎn)品的，主要圍繞幾個以下幾個點：
  • 程序某個地方存在問題
  • 產(chǎn)品需求信息在測試和開發(fā)中不統(tǒng)一
  • 程序某功能應該是怎么處理
  • 缺陷修復后的驗證
• 測試和需求的溝通
  測試人員與需求的溝通難點主要還是體現(xiàn)在需求不明確或者需求變更上。
  很多時候需求人員的需求文檔都是不全面的，測試人員在寫測試用例時需要一次又一次的與需求進行確認，一來二去，需求估計有種想把桌子里40米長的大刀放桌上來。
  另一方面在項目過程中，不可避免的會出現(xiàn)需求變更，只要出現(xiàn)變更就意味著之前的測試準備工作就作廢。
  測試與需求如何溝通呢：
  • 切記不能停留在口頭溝通，確認
  • 所有的需求確認或者需求變更都需要文檔化，實在不行也需要發(fā)郵件
  • 每一次確認、變更都需要通過項目相關人
  • 建立完善的需求變更體系，流程上控制需求變更
• 測試結果的反饋
  測試結果的反饋容易出現(xiàn)問題的地方就是結果描述不清楚，增加項目的時間和溝通成本。解決這個問題最好的辦法就是將測試結果盡可能的描述清楚。
  測試結果反饋分為兩種：
  • 測試結果反饋分為兩種：
  • 在缺陷管理工具中提交缺陷

6. 缺陷管理

在開發(fā)階段，測試人員最重要的產(chǎn)出就是缺陷。缺陷并不是數(shù)量越多，就越有價值。更應該關注缺陷的質(zhì)量、缺陷的管理以及缺陷分析。

缺陷管理.jpg

缺陷流程圖處理圖：

缺陷流程圖.jpg

7. 輸出測試報告

測試報告一般是在項目測試結束或一個迭代完成之后由測試負責人編寫。若不是項目，只有一兩個測試人員，那就是由該項目主導人來寫，若只有你一個來測試，那就是由你來寫。
測試報告主要內(nèi)容大致可以分為測試范圍、測試進度、缺陷管理、測試結論四大部分，在實際編寫過程中，我們根據(jù)企業(yè)的要求輸出這四個部分或包含這四個部分以上的內(nèi)容即可。

• 測試范圍
  測試范圍主要是寫本次項目或本次迭代需要測試的功能，一般來說是以新增功能和修改功能為主，以回歸測試內(nèi)容為輔，測試報告中的測試范圍可以摘取測試計劃中的測試范圍，再根據(jù)本輪測試活動中實際測試的功能進行補充
• 測試進度
  測試報告中的測試進度由二部分組成：一個是時間進度安排（展示），另一個是人員測試時間花費
• 缺陷管理
  缺陷管理是測試報告中的核心內(nèi)容，而測試報告中需要對本輪測試缺陷從不同維度進行輸出，目的就是為了從缺陷分析中得出軟件質(zhì)量、修改bug的效率、開發(fā)質(zhì)量等
• 測試結論
  測試報告中的測試結論絕對是占C位的，也有企業(yè)寫測試報告只需要測試結論就行； 測試結論中包含對本輪測試過程的總結，主要是得出本輪測試之后項目是否達到了上線標準，所以
  測試結論有測試通過，可以上線，或者是測試不通過，建議不上線

8. 產(chǎn)品發(fā)布

進入發(fā)布階段就意味著產(chǎn)品已經(jīng)通過了測試，可以發(fā)布到線上，交付給用戶使用。

• 測試通過準則規(guī)范
  • 測試需求功能覆蓋率100%
  • 測試用例通過率95%以上
  • 遺留缺陷沒有嚴重程度3級以及以上的缺陷

9. 結束測試

整理整個測試過程中產(chǎn)出的文檔，并進行歸檔整理，以便日后使用。

其實產(chǎn)品發(fā)布之后，也可能會進入到日常維護階段，并不會結束測試。
產(chǎn)品上線后，用戶能穩(wěn)定的長期使用，就意味著發(fā)布的功能進入到日常維護階段。而這里并不是終點，這個階段將一直存在。
在這個階段，測試人員的主要工作就比較簡單：

• 持續(xù)測試，沒有產(chǎn)品是沒有缺陷的
• 即使收集用戶反饋的問題，并盡快組織人員修復
• 長時間穩(wěn)定性測試（自動化測試）
  總結：
  軟件測試整個過程，關注的是在整個軟件生命周期中，各個階段的測試活動
  通過對各個階段的過程質(zhì)量把控，從而提高產(chǎn)品的測試質(zhì)量。產(chǎn)品的質(zhì)量并不是測試能決定的，而是整個項目構建過程中，通過一次次的優(yōu)化過程，不斷的總結成長，是整個項目團隊決定的。
  不同的工種都在這個過程中起到舉足輕重的作用，而全程軟件測試強調(diào)不斷提高每個階段的質(zhì)量，最終提高項目團隊的綜合能力，從而提高產(chǎn)品質(zhì)量。

9. 企業(yè)面試題

1. 寫出你對軟件測試的認識，盡量詳細
   參考答案：
   軟件測試就是在軟件投入運行前，對軟件需求分析、設計規(guī)格說明和編碼的最終復審，是軟件質(zhì)量保證的關鍵步驟
   軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程?；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結構而精心設計一批測試用例（即輸入數(shù)據(jù)及其預期的輸出結果），并利用這些測試用例去運行程序，以發(fā)現(xiàn)程序錯誤的過程。
2. 簡述CS、B\S的優(yōu)缺點
   參考答案：
   B/S最大優(yōu)勢為客戶端免維護，適用于用戶群龐大，或客戶需求經(jīng)常發(fā)生變化的情況。
   C/S功能強大，可以減輕服務端壓力，如果用戶需求特別復雜，用C/S。
3. 測試的目的是什么？測試流程是什么？
   參考答案：
   是想以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷，通過修正各種錯誤和缺陷提高軟件質(zhì)量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造成隱患所帶來的商業(yè)風險。
   需求分析評審-指定測試計劃-編寫測試用例-測試用例評審-測試用例執(zhí)行-輸出測試報告
4. 什么叫QA？什么叫QC？什么叫TEST？他們分別關注產(chǎn)品的哪些階段？
   參考答案：
   QA:質(zhì)量保證。流程的監(jiān)督者，職責是創(chuàng)建和執(zhí)行改進軟件開發(fā)過程，并防止軟件缺陷發(fā)生的標準和方法。
   QC:質(zhì)量控制。也是測試人員，職責是盡可能早的發(fā)現(xiàn)軟件的缺陷，并確保缺陷得到修復
   TEST:執(zhí)行測試。執(zhí)行軟件以驗證其滿足指定的需求并檢測錯誤的過程。
5. 你認為軟件工程師必備的素質(zhì)和技能是什么？
   參考答案：
   素質(zhì)：態(tài)度、責任、溝通能力。
   技能：
   (1) 規(guī)范、標準化的編碼能力
   (2) 認識和運用數(shù)據(jù)庫的能力
   (3) 較強的動手能力和解決實際問題的能力
   (4) 持續(xù)的學習能力、掌握最新的IT技術
   (5) 較強的英文閱讀和寫作能力
   6.單元測試、集成測試、系統(tǒng)測試的側重點是什么？
   參考答案：
   單元測試：模塊、方法
   集成測試：接口
   系統(tǒng)測試：整個系統(tǒng)的把控
6. 黑盒、白盒、回歸、壓力測試的定義
   參考答案：
   黑盒測試：把被測物體看成一個黑盒子，不需了解內(nèi)部結構，注重輸入輸出，所以又稱為功能測試
   白盒測試：又稱為結構測試，因為注重的是軟件的結構、邏輯和算法
   回歸測試：是指在發(fā)生修改之后重新測試先前的測試以保證修改的正要性
   壓力測試：是對系統(tǒng)不斷施加壓力的測試，是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務級別的測試
7. 軟件測試的目的（C）
   A. 避免軟件開發(fā)中出現(xiàn)的錯誤
   B. 發(fā)現(xiàn)軟件開發(fā)中出現(xiàn)的錯誤
   C. 盡可能發(fā)現(xiàn)并排除軟件中潛藏的錯誤，日積月累可靠性
   D. 修改軟件中出現(xiàn)的錯誤
8. 軟件的生命周期從軟件的計劃到廢棄不用為止，劃分為若干階段，并賦予任務和活動，他們分別是：
   參考答案：
   系統(tǒng)調(diào)查、系統(tǒng)分析、系統(tǒng)設計、程序設計、系統(tǒng)測試和運行維護。
9. 在測試中的80-20原則是指:80%的缺陷存在于20%的軟件程序中或模塊中