軟體缺陷：

1）軟體未實現產品說明書要求的功能

2）軟體出現了產品說明書指明不應該出現的錯誤

3）軟體實現了產品說明書未提到的功能

4）軟體未實現產品說明書雖未明確提及但應該實現的目標

5）軟體難以理解、不易使用、執行緩慢或者從測試員的角度看終端使用者會認為不好。

軟體測試：為了發現軟體產品中的各種缺陷，而對軟體產品進行驗證和確認的活動過程，此過程貫穿整個軟體開發生命週期。 簡單的說，軟體測試是以發現錯誤為目的而執行的一個程式或系統的過程。

軟體測試的目的：

1.驗證軟體需求和功能是否得到完整實現
2.驗證軟體是否可以釋出
3.儘可能多的發現軟體中的bug
4.儘可能早的發現軟體中的bug
5.對軟體質量做出合理評估
6.預防下個版本可能出現的問題
7.預防使用者使用可能出現的問題
8.發現開發過程中的問題和風險

軟體測試的原則：

1、所有測試的標準都是建立在使用者需求之上 。
2、合理控制測試深度與廣度，完全測試不可能，測試的投入與產出要均衡。
3、80-20原則，軟體中80%的bug可以在分析、設計與評審階段就能被發現與修正，16%的缺陷在系統的軟體測試中發現，最後剩下的4%是使用者長期使用的過程中才能暴露出來。
4、儘可能早的開展測試，越早發現錯誤，修改的代價越小。
5、發現錯誤較多的程式段，應進行更深入的測試。
6、軟體專案一啟動，軟體測試也就是開始，而不是等程式寫完，才開始進行測試 。
7、軟體開發人員即程式設計師應當避免測試自己的程式
8、嚴格執行測試計劃，排除測試的隨意性，以避免發生疏漏或者重複無效的工作

軟體測試的流程

web測試和APP測試的區別

僅僅從功能測試的層面上來講的話，在流程和功能測試上是沒有區別的。那麼區別在哪裡呢？
由於載體不一樣，所以系統測試和一些細節可能會不一樣。
那麼我們就要先來了解，web和app的區別。

web專案，一般都是b/s架構，基於瀏覽器的，而app則是c/s的，必須要有客戶端。那麼在系統測試測試的時候就會產生區別了。

首先從系統架構來看的話，web測試只要更新了伺服器端，客戶端就會同步會更新。而且客戶端是可以保證每一個使用者的客戶端完全一致的。但是app端是不能夠保證完全一致的，除非使用者更新客戶端。如果是app下修改了服務端，意味著客戶端使用者所使用的核心版本都需要進行迴歸測試一遍。

接著是效能方面，web頁面可能只會關注響應時間，而app則還需要關心流量、電量、CPU、GPU、Memory這些了。至於服務端的效能是沒區別，這裡就不談。

相比較web測試，app更是多了一些專項測試：

健壯性測試：

一些異常場景的考慮以及弱網路測試。這裡的異常場景就是中斷，來電，簡訊，關機，重啟等。

而弱網測試是app測試中必須執行的一項測試。包含弱網和網路切換測試。需要測試弱網所造成的使用者體驗，重點要考慮回退和重新整理是否會造成二次提交。需要測試丟包，延時的處理機制。避免使用者的流失。這些在前面的弱網測試那篇已經講過，這裡不再講了。
　　
安裝、解除安裝、更新：
　　web測試是基於瀏覽器的所以不必考慮這些。而app是客戶端的，則必須測試安裝、更新、解除安裝。除了常規的安裝、更新、解除安裝還要考慮到異常場景。包括安裝時的中斷、弱網、安裝後刪除安裝檔案，更新的強制更新與非強制更新、增量包更新、斷點續傳、弱網，解除安裝後刪除app相關的檔案等等。
　　
就自動化來講，web大多用的selenium、webdriver，而app則是appium。
效能使用的工具web則是LR，app使用Jmeter要多一點

如何提交高質量的缺陷報告單

1、 缺陷的概要描述要清晰準確，要使相關開發負責人員能夠一目瞭然問題是什麼。
2、 一個完整的缺陷報告單，必須包含其必要的元素資訊，例如：概要描述，缺陷發現人，測試環境，瀏覽器，缺陷重現步驟，嚴重等級，指派人，所屬功能模組等等，必要元素資訊必須描述全面清楚。
3、 缺陷的重現步驟必須描寫清晰明瞭，使相關開發負責人能夠根據重現步驟準確的重現所提交的缺陷，使其定位缺陷的原因所在。
4、測試資料，測試的資料作為重現缺陷的一個重要元素資訊，一定要將測試時所使用的資訊給描寫清楚準確。讓開發人員根據測試所提供的測試資料準確重現缺陷。
5、附件截圖資訊，附件或截圖資訊能讓開發人員能夠一目瞭然的清楚問題的所在。

如何對web系統進行全面測試？

一、 功能測試
　　1、連結測試
　　連結是Web應用系統的一個主要特徵，它是在頁面之間切換和指導使用者去一些不知道地址的頁面的主要手段。連結測試可分為三個方面。首先，測試所有連結是否按指示的那樣確實連結到了該連結的頁面;其次，測試所連結的頁面是否存在;最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有連結指向該頁面，只有知道正確的URL地址才能訪問。 連結測試可以自動進行，現在已經有許多工具可以採用。連結測試必須在整合測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之後進行連結測試。
　　2、表單測試
　　當用戶給Web應用系統管理員提交資訊時，就需要使用表單操作，例如使用者註冊、登陸、資訊提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給伺服器的資訊的正確性。例如：使用者填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了預設值，還要檢驗預設值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字元，測試時可以跳過這些字元，看系統是否會報錯。
　　3、Cookies測試
　　Cookies通常用來儲存使用者資訊和使用者在某應用系統的操作，當一個使用者使用Cookies訪問了某一個應用系統時，Web伺服器將傳送關於使用者的資訊，把該資訊以Cookies的形式儲存在客戶端計算機上，這可用來建立動態和自定義頁面或者儲存登陸等資訊。 如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用，是否按預定的時間進行儲存，重新整理對Cookies有什麼影響等。
　　4、設計語言測試
　　Web設計語言版本的差異可以引起客戶端或伺服器端嚴重的問題，例如使用哪種版本的HTML等。當在分散式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的指令碼語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。
　　5、資料庫測試
　　在Web應用技術中，資料庫起著重要的作用，資料庫為Web應用系統的管理、執行、查詢和實現使用者對資料儲存的請求等提供空間。在Web應用中，最常用的資料庫型別是關係型資料庫，可以使用SQL對資訊進行處理。 在使用了資料庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是資料一致性錯誤和輸出錯誤。資料一致性錯誤主要是由於使用者提交的表單資訊不正確而造成的，而輸出錯誤主要是由於網路速度或程式設計問題等引起的，針對這兩種情況，可分別進行測試。

二、 效能測試
　　1、連線速度測試
　　使用者連線到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬頻上網。當下載一個程式時，使用者可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長(例如超過5秒鐘)，使用者就會因沒有耐心等待而離開。 另外，有些頁面有超時的限制，如果響應速度太慢，使用者可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連線速度太慢，還可能引起資料丟失，使使用者得不到真實的頁面。
　　2、負載測試
　　負載測試是為了測量Web系統在某一負載級別上的效能，以保證Web系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的使用者數量，也可以是線上資料處理的數量。例如：Web應用系統能允許多少個使用者同時線上?如果超過了這個數量，會出現什麼現象?Web應用系統能否處理大量使用者對同一個頁面的請求?
　　3、壓力測試
　　負載測試應該安排在Web系統釋出以後，在實際的網路環境中進行測試。因為一個企業內部員工，特別是專案組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。 進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。黑客常常提供錯誤的資料負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。 壓力測試的區域包括表單、登陸和其他資訊傳輸頁面等。

三、 可用性測試
　　1、導航測試
　　導航描述了使用者在一個頁面內操作的方式，在不同的使用者介面控制之間，例如按鈕、對話方塊、列表和視窗等;或在不同的連線頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易於導航：導航是否直觀?Web系統的主要部分是否可通過主頁存取?Web系統是否需要站點地圖、搜尋引擎或其他的導航幫助? 在一個頁面上放太多的資訊往往起到與預期相反的效果。Web應用系統的使用者趨向於目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的資訊，如果沒有，就會很快地離開。很少有使用者願意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要儘可能地準確。 導航的另一個重要方面是Web應用系統的頁面結構、導航、選單、連線的風格是否一致。確保使用者憑直覺就知道Web應用系統裡面是否還有內容，內容在什麼地方。 Web應用系統的層次一旦決定，就要著手測試使用者導航功能，讓終端使用者參與這種測試，效果將更加明顯。
　　2、圖形測試
　　 在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字型、背景、按鈕等。
　　圖形測試的內容有：
　　(1)要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要儘量地小，並且要能清楚地說明某件事情，一般都連結到某個具體的頁面。
　　(2)驗證所有頁面字型的風格是否一致。
　　(3)背景顏色應該與字型顏色和前景顏色相搭配。
　　(4)圖片的大小和質量也是一個很重要的因素，一般採用JPG或GIF壓縮。
　　3、內容測試
　　內容測試用來檢驗Web應用系統提供資訊的正確性、準確性和相關性。 資訊的正確性是指資訊是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛;資訊的準確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文書處理軟體來進行，例如使用Microsoft Word的拼音與語法檢查功能;資訊的相關性是指是否在當前頁面可以找到與當前瀏覽資訊相關的資訊列表或入口，也就是一般Web站點中的所謂相關文章列表。
　　4、整體介面測試
　　整體介面是指整個Web應用系統的頁面結構設計，是給使用者的一個整體感。例如：當用戶瀏覽Web應用系統時是否感到舒適，是否憑直覺就知道要找的資訊在什麼地方?整個Web應用系統的設計風格是否一致? 對整體介面的測試過程，其實是一個對終端使用者進行調查的過程。一般Web應用系統採取在主頁上做一個調查問卷的形式，來得到終端使用者的反饋資訊。 對所有的可用性測試來說，都需要有外部人員(與Web應用系統開發沒有聯絡或聯絡很少的人員)的參與，最好是終端使用者的參與。

四、 客戶端相容性測試
　　1、平臺測試
　　市場上有很多不同的作業系統型別，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的終端使用者究竟使用哪一種作業系統，取決於使用者系統的配置。這樣，就可能會發生相容性問題，同一個應用可能在某些作業系統下能正常執行，但在另外的作業系統下可能會執行失敗。 因此，在Web系統釋出之前，需要在各種作業系統下對Web系統進行相容性測試。
　　2、瀏覽器測試
　　瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML規格有不同的支援。例如，ActiveX是Microsoft的產品，是為Internet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設定也不一樣。 測試瀏覽器相容性的一個方法是建立一個相容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設定的適應性。

五、 安全性測試
　　Web應用系統的安全性測試區域主要有：
　　(1)現在的Web應用系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的使用者名稱和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
　　(2)Web應用系統是否有超時的限制，也就是說，使用者登陸後在一定時間內(例如15分鐘)沒有點選任何頁面，是否需要重新登陸才能正常使用。
　　(3)為了保證Web應用系統的安全性，日誌檔案是至關重要的。需要測試相關資訊是否寫進了日誌檔案、是否可追蹤。
　　(4)當使用了安全套接字時，還要測試加密是否正確，檢查資訊的完整性。
　　(5)伺服器端的指令碼常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在伺服器端放置和編輯指令碼的問題。

優秀測試人員應具備的素質：

1）溝通能力與表達能力
2）好奇心與懷疑精神
3）責任感與抗壓能力
4）自信心，堅持自己的觀點
5）耐心與細心
6）逆向思維的能力
7）善於學習與總結
8）團隊協作精神
9）文件編寫能力

優秀測試人員應具備的技能：

1）精通業務知識
2）具備軟體程式設計能力，比如C,C++,JAVA等。
3）可以用指令碼語言編寫小測試工具
4）主流作業系統應用與網路知識，可以搭建測試環境
5）熟練掌握各種資料庫知識
6）精通軟體測試理論與方法
7）掌握常用測試與開發工具的使用
8）優秀的文件編寫能力

軟體測試的分類：

1）按照是否執行被測試軟體來分：

靜態測試：是指不執行軟體，測試包括程式碼檢查、靜態結構分析、程式碼質量度量等，主要對軟體需求說明書、設計說明書、軟體原始碼進行檢查與分析。

動態測試：指通過執行被測程式，檢查執行結果與預期結果的差異，分析差異原因，並分析軟體執行效率、健壯性等效能。 動態測試是目前公司主要的測試方式

2）按照測試技術分為黑盒測試和白盒測試：

黑盒測試：黑盒測試又叫功能測試或資料驅動測試，在完全不考慮程式內部結構和內部特性的情況下，通過軟體的外部表現來發現其缺陷和錯誤。

白盒測試：白盒測試也稱結構測試或邏輯驅動測試，它是按照程式內部的結構進行測試程式，通過測試來檢測產品內部邏輯是否按照設計規格說明書的規定正常進行，檢驗程式中的每條通路是否都能按預定要求正確工作。

3）按照測試手段來分，可以分為手工測試和自動化測試

4）按照過程階段來分，可以分為單元測試、整合測試、系統測試和驗收測試

單元測試：通過模組(類/方法/函式)測試，使程式碼達到設計要求 主要目的是針對編碼過程中可能存在的各種錯誤，例如使用者輸入驗證過程中的邊界值的錯誤。

整合測試：將經過單元測試的模組逐步組裝成完整的程式。 主要目的是檢查各單元與其它程式部分之間的介面是否存在問題，各模組功能之間是否有影響。

系統測試：是將已經確認的軟體、計算機硬體、外設、網路等其他元素結合在一起進行測試。 系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方 ，進行改正。

驗收測試：驗收測試是在軟體產品完成了單元測試、整合測試和系統測試之後，產品釋出之前所進行的最後一次軟體測試活動，也稱為交付測試。 通常由業務專家或使用者進行，以確認產品能真正符合使用者業務上的需要。

軟體開發流程（軟體生命週期）：

計劃-》需求分析-》設計-》程式編寫-》測試-》執行/維護

軟體測試流程：

測試計劃-》需求分析-》測試用例-》測試用例執行-》提交bug-》迴歸測試

軟體開發模型：

軟體測試模型：

V模型：反映了測試與開發階段之間一一對應的特點，測試在開發之後，出錯後迴歸測試量大。

W模型：測試伴隨整個開發週期，測試與開發同步進行，有利於儘早發現問題

H模型：軟體測試活動完全獨立，與其他流程並行。

白盒測試方法

白盒測試方法有 語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。

1.語句覆蓋每條語句至少執行一次。

2.判定覆蓋每個判定的每個分支至少執行一次。

3.條件覆蓋每個判定的每個條件應取到各種可能的值。

4.判定/條件覆蓋同時滿足判定覆蓋條件覆蓋。

5.條件組合覆蓋每個判定中各條件的每一種組合至少出現一次。

6.路徑覆蓋使程式中每一條可能的路徑至少執行一次。

設計用例的方法、依據有那些?

測試分為白盒測試和黑盒測試，回答時，要注意分開說。白盒測試用例設計有如下方法：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋和路徑覆蓋。依據就是程式碼結構。

黑盒測試用例設計方法：基於使用者需求的測試、等價類劃分方法、邊界值分析方法、錯誤推測方法、因果圖方法、判定表驅動分析方法、正交實驗法、場景法。依據是使用者需求規格說明書，詳細設計說明書。

一個測試工程師應具備那些素質和技能?

一個好的測試工程師，不僅要基礎紮實，對自身的性格、責任心都有非常高的要求。具體如下：(1)掌握基本的測試基礎理論(2)本著找出軟體存在的問題的態度進行測試,即客觀吧,不要以挑刺形象出現(3)可熟練閱讀需求規格說明書等文件(4)以使用者的觀點看待問題(5)有著強烈的質量意識(6)細心和責任心(7)良好的有效的溝通方式(與開發人員及客戶)(8)具有以往的測試經驗(9)能夠及時準確地判斷出高危險區在何處.

整合測試通常都有哪些策略?

大致說四點即可，當然說全更好。整合測試有十種策略:(1)大爆炸整合(2)自頂向下整合(3)自底向上整合(4)三明治整合(5)分層整合(6)基幹整合(7)基於功能的整合(8)基於訊息的整合(9)基於風險的整合(10)基於進度的整合.

什麼是相容性測試？相容性測試側重哪些方面？

相容測試主要是檢查軟體在不同的硬體平臺、軟體平臺上是否可以正常的執行，即是通常說的軟體的可移植性。

相容的型別，如果細分的話，有平臺的相容，網路相容，資料庫相容，以及資料格式的相容。

相容測試的重點是，對相容環境的分析。通常，是在執行軟體的環境不是很確定的情況下，才需要做相容。根據軟體執行的需要，或者根據需求文件，一般都能夠得出使用者會在什麼環境下使用該軟體，把這些環境整理成表單，就得出做相容測試的相容環境了。

我現在有個程式，發現在Windows上執行得很慢，怎麼判別是程式存在問題還是軟硬體系統存在問題？

1、檢查系統是否有中毒的特徵；

2、檢查軟體/硬體的配置是否符合軟體的推薦標準；

3、確認當前的系統是否是獨立，即沒有對外提供什麼消耗CPU資源的服務；

4、如果是C/S或者B/S結構的軟體，需要檢查是不是因為與伺服器的連線有問題，或者訪問有問題造成的；

5、在系統沒有任何負載的情況下，檢視效能監視器，確認應用程式對CPU/記憶體的訪問情況。

測試的策略有哪些？

黑盒/白盒，靜態/動態，手工/自動，冒煙測試，迴歸測試，公測（Beta測試的策略）

正交表測試用例設計方法的特點是什麼？

用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很複雜；

對於基本的驗證功能，以及二次整合引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；

具體的環境下，正交表一般都很難做的。大多數，只在系統測試的時候使用此方法。

描述使用bugzilla缺陷管理工具對軟體缺陷（BUG）跟蹤的管理的流程？

在Bugzilla中，Bug報告狀態分為以下幾種狀態，

1 2 3 4 5 6 7 8 9 10 11 12 13

待確認的 unconfirmed 新提交的 new 已分配的 assigned 問題未解決的 reopened 待返測的 resolved 待歸檔的 verified 已歸檔的 closed

Bug處理意見（Resolution）

1 2 3 4 5 6 7 8 9 10 11 12 13

已修改的 fixed 不是問題 nvalid 無法修改 wontfix 以後版本解決 later 保留 remind 重複 duplicate 無法重現 workforme

你覺得bugzilla在使用的過程中，有什麼問題？

介面不穩定；

根據需要配置它的不同的部分，過程很煩瑣。

流程控制上，安全性不好界定，很容易對他人的Bug進行誤操作；

沒有綜合的評分指標，不好確認修復的優先級別。

描述測試用例設計的完整過程？

需求分析 + 需求變更的維護工作；

根據需求 得出測試需求；

設計測試方案，評審測試方案；

方案評審通過後，設計測試用例，再對測試用例進行評審；

單元測試的策略有哪些？

單元的常見錯誤一般出現在以下五個方面，因此這五個方面是單元測試應該關注的重點。

1、單元介面。

2、區域性資料結構。

3、獨立路徑。

4、出錯處理。

5、邊界條件

在單元測試時，由於單元本身不是一個獨立的程式，一個完整的可執行的軟體系統並沒有構成，所以需要設定一些輔助測試單元，輔助測試單元有兩種，一種是驅動單元，另外一種是樁單元。

1、驅動單元（Driver）:用來模擬被測單元的上層單元，相當於被測函式的主函式，如main函式。所以驅動單元主要完成以下4個步驟：

（1）接受測試資料，包含測試用例輸入和預期輸出；

（2）把測試用例輸入傳送給被測單元，驅動被測單元測試；

（3）將被測單元的實際輸出和預期輸出進行比較，得到測試結果；

（4）將測試結果輸出到指定位置。

2、樁單元（Stub）：用來代替被測單元工作過程中呼叫的子單元。

樁單元模擬的單元可能是自定義函式：這些自定義函式可能尚未編寫完成，為了測試被測單元，需要構造樁單元來代替它們，可能存在錯誤，會影響測試結果，所以需要構造正確無誤的樁單元來達到隔離的目的。

驅動單元和樁單元都是額外的開銷，雖然在單元測試的時候必須寫，但是並不需要作為最終的產品提供給客戶。

單元測試策略

一般的單元執行策略有三種：孤立的單元測試策略（Isolation Unit Testing），自頂向下的單元測試策略（Top Down Unit Testing）和自底向上的單元測試策略（Bottom Up Unit Testing）。需要注意的是：在整合測試中也有自頂向下和自底向上的測試策略，但是測試物件不同。

1、孤立的單元測試策略（Isolation Unit Testing）

方法：不考慮每個模組與其它模組之間的關係，為每個模組設計樁模組和驅動模組，每個模組進行獨立的單元測試。

優點：這個方法比較簡單，最容易操作，可以達到很高的結構覆蓋率，可以並行開展，該方法是純粹的單元測試。

缺點：樁函式和驅動函式工作量很大，效率低。

2、自頂向下的單元測試策略（Top Down Unit Testing）

方法：先對最頂層的單元進行測試，把頂層所呼叫的單元做成樁模組，其次對第二層進行測試，使用上面已經測試過的單元做驅動模組，以此類推，直到測試完所有模組。

優點：可以節省驅動函式的開發工作，效率高。

缺點：隨著被測單元一個一個被加入，測試過程將變得越來越複雜，並且開發和維護的成本將增加。

3、自底向上的單元測試策略（Bottom Up Unit Testing）

方法：先對最底層的模組進行單元測試，將模擬呼叫該模組的模組設定為驅動模組，然後再對上面一層做單元測試，用下面已經測試好的模組做樁模組，以此類推，直到測試完所有模組。

優點：可以節省樁函式的開發工作量，測試效率較高。

缺點：不是純粹的單元測試，底層函式的測試質量對上層函式的測試將產生很大影響。

LoadRunner分哪三部分？

指令碼生成器；

場景控制器；

結果分析器。

LoadRunner進行測試的流程?

1、 測試設計

2、 建立虛擬使用者指令碼

3、 建立執行場景

4、 執行場景

5、 監視場景

6、 分析測試的結果

以上，最好是結合一個案例，根據以上流程來介紹。

什麼是併發？在lordrunner中，如何進行併發的測試？集合點失敗了會怎麼樣？

在同一時間點，支援多個不同的操作。

LoadRunner中提供IP偽裝，集合點，配合虛擬使用者的設計，以及在多臺電腦上設定，可以比較好的模擬真實的併發。

集合點，即是多個使用者在某個時刻，某個特定的環境下同時進行虛擬使用者的操作的。集合點失敗，則集合點的操作就會取消，測試就不能進行。

TestDirector有些什麼功能，如何對軟體測試過程進行管理？

需求管理

n 定義測試範圍

n 定義需求樹

n 描述需求樹的功能點

測試計劃

n 定義測試目標和測試策略。

n 分解應用程式，建立測試計劃樹。

n 確定每個功能點的測試方法。

n 將每個功能點連線到需求上，使測試計劃覆蓋全部的測試需求。

n 描述手工測試的測試步驟

n 指明需要進行自動測試的功能點

測試執行

n 定義測試集合。

n 為每個測試人員制定測試任務和測試日程安排。

n 執行自動測試。

缺陷跟蹤

n 記錄缺陷

n 檢視新增缺陷，並確定哪些是需要修正的

n 相關技術人員修改缺陷

n 迴歸測試

n 分析缺陷統計圖表，分析應用程式的開發質量。

所熟悉的軟體測試型別都有哪些？請試著分別比較這些不同的測試型別的區別與聯絡（如功能測試、效能測試……）？

Compatibility Testing（相容性測試），也稱“Configuration testing（配置測試）”，測試軟體是否和系統的其它與之互動的元素之間相容，如：瀏覽器、作業系統、硬體等。驗證測試物件在不同的軟體和硬體配置中的執行情況。

Functional testing (功能測試)，也稱為behavioral testing（行為測試），根據產品特徵、操作描述和使用者方案，測試一個產品的特性和可操作行為以確定它們滿足設計需求。本地化軟體的功能測試，用於驗證應用程式或網站對目標使用者能正確工作。使用適當的平臺、瀏覽器和測試指令碼，以保證目標使用者的體驗將足夠好，就像應用程式是專門為該市場開發的一樣。
Performance testing（效能測試），評價一個產品或元件與效能需求是否符合的測試。包括負載測試、強度測試、資料庫容量測試、基準測試等型別。

一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟體缺陷（Bug）記錄？

1.和BUG對應的軟體版本
2.開發的介面人員，測試人員
3.BUG的優先順序
4.BUG的嚴重程度
5.BUG可能屬於的模組
6.BUG的標題
7.BUG的描述
8.BUG的截圖
9.BUG的狀態
10.BUG的錯誤型別（資料，介面。。。。）

Beta測試與Alpha測試有什麼區別？

Beta testing(β測試),測試是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發者通常不在測試現場
Alpha testing (α測試),是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控測試

軟體的評審一般由哪些人蔘加？其目的是什麼？

在正式的會議上將軟體專案的成果（包括各階段的文件、產生的程式碼等）提交給使用者、客戶或有關部門人員對軟體產品進行評審和批准。其目的是找出可能影響軟體產品質量、開發過程、維護工作的適用性和環境方面的設計缺陷，並採取補救措施，以及找出在效能、安全性和經濟方面的可能的改進。

人員：使用者、客戶或有關部門開發人員，測試人員，需求分析師都可以，就看處於評審那個階段

階段評審與專案評審有什麼區別？

階段評審對專案各階段評審：對階段成果和工作

專案評審對專案總體評審：對工作和產品

什麼是扇入？什麼是扇出？

參考答案：

扇入：被調次數，扇出：調其它模組數目

什麼是樁模組？什麼是驅動模組？

樁模組：被測模組呼叫模組

驅動模組：呼叫被測模組

你認為做好測試計劃工作的關鍵是什麼？

軟體測試計劃就是在軟體測試工作正式實施之前明確測試的物件，並且通過對資源、時間、風險、測試範圍和預算等方面的綜合分析和規劃，保證有效的實施軟體測試；

做好測試計劃工作的關鍵：目的，管理，規範

1、 明確測試的目標，增強測試計劃的實用性
編寫軟體測試計劃得重要目的就是使測試過程能夠發現更多的軟體缺陷，因此軟體測試計劃的價值取決於它對幫助管理測試專案，並且找出軟體潛在的缺陷。因此，軟體測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、準確

2．堅持“5W”規則，明確內容與過程
“5W”規則指的是“What（做什麼）”、“Why（為什麼做）”、“When（何時做）”、“Where（在哪裡）”、“How（如何做）”。利用“5W”規則建立軟體測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的範圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文件和軟體的存放位置（Where）。

3．採用評審和更新機制，保證測試計劃滿足實際需求
測試計劃寫作完成後，如果沒有經過評審，直接傳送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟體需求變更引起測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。

4、分別建立測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立建立的測試詳細規格文件，把用於指導測試小組執行測試過程的測試用例放到獨立建立的測試用例文件或測試用例管理資料庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從巨集觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。

簡述一下缺陷的生命週期？

提交->確認->分配->修復->驗證->關閉

軟體的安全性應從哪幾個方面去測試？

(1)使用者認證機制：如資料證書、智慧卡、雙重認證、安全電子交易協議

(2)加密機制

(3)安全防護策略：如安全日誌、入侵檢測、隔離防護、漏洞掃描

(4)資料備份與恢復手段：儲存裝置、儲存優化、儲存保護、儲存管理

(5)防病毒系統

軟體配置管理工作開展的情況和認識？

軟體配置管理貫穿於軟體開發、測試活動的始終，覆蓋了開發、測試活動的各個環節，它的重要作用之一就是要全面的管理儲存各個配置項，監控各配置項的狀態，並向專案經理及相關的人員報告，從而實現對軟體過程的控制。

軟體測試配置管理包括4個最基本的活動：

配置項標識

配置項控制

配置項狀態報告

配置審計

1	軟體配置管理通常藉助工具來輔助，主要有MS SourceSafe、Rational ClearCase等

你覺得軟體測試通過的標準應該是什麼樣的？

1	缺陷密度值達到客戶的要求

引入測試管理的含義？

風險分析，進度控制、角色分配、質量控制

一套完整的測試應該由哪些階段組成？

參考答案：測試計劃、測試設計與開發、測試實施、測試評審與測試結論

單元測試的主要內容？

模組介面測試、區域性資料結構測試、路徑測試、錯誤處理測試、邊界測試

整合測試也叫組裝測試或者聯合測試，請簡述整合測試的主要內容？

（1）在把各個模組連線起來的時候，穿越模組介面的資料是否會丟失；

（2）一個模組的功能是否會對另一個模組的功能產生不利的影響；

（3）各個子功能組合起來，能否達到預期要求的父功能；

（4）全域性資料結構是否有問題；

（5）單個模組的誤差累積起來，是否會放大，從而達到不能接受的程度。

簡述整合測試與系統測試關係？

（1）整合測試的主要依據概要設計說明書，系統測試的主要依據是需求設計說明書；

（2）整合測試是系統模組的測試，系統測試是對整個系統的測試，包括相關的軟硬體平臺、網路以及相關外設的測試。

軟體測試的文件測試應當貫穿於軟體生命週期的全過程，其中使用者文件是文件測試的重點。那麼軟體系統的使用者文件包括哪些？

使用者手冊

安裝和設定指導

聯機幫助

指南、嚮導

樣例、示例和模板

授權/註冊登記表

終端使用者許可協議

軟體系統中除使用者文件之外，文件測試還應該關注哪些文件？

開發文件

軟體需求說明書

1 2 3 4 5 6 7

資料庫設計說明書 概要設計說明書 詳細設計說明書 可行性研究報告

管理文件

1 2 3 4 5 6 7 8 9

專案開發計劃 測試計劃 測試報告 開發進度月報 開發總結報告

簡述軟體系統中使用者文件的測試要點？

（1）讀者群。文件面向的讀者定位要明確。對於初級使用者、中級使用者以及高階使用者應該有不同的定位

（2）術語。文件中用到的術語要適用與定位的讀者群，用法一致，標準定義與業界規範相吻合。

（3）正確性。測試中需檢查所有資訊是否真實正確，查詢由於過期產品說明書和銷售人員誇大事實而導致的錯誤。檢查所有的目錄、索引和章節引用是否已更新，嘗試連結是否準確，產品支援電話、地址和郵政編碼是否正確。

（4）完整性。對照軟體介面檢查是否有重要的分支沒有描述到，甚至是否有整個大模組沒有描述到。

（5）一致性。按照文件描述的操作執行後，檢查軟體返回的結果是否與文件描述的相同。

（6）易用性。對關鍵步驟以粗體或背景色給使用者以提示，合理的頁面佈局、適量的圖表都可以給使用者更高的易用性。需要注意的是文件要有助於使用者排除錯誤。不但描述正確操作，也要描述錯誤處理辦法。文件對於使用者看到的錯誤資訊應當有更詳細的文件解釋。

（7）圖表與介面截圖。檢查所有圖表與介面截圖是否與發行版本相同。

（8）樣例與示例。像使用者一樣載入和使用樣例。如果是一段程式，就輸入資料並執行它。以每一個模組製作檔案，確認它們的正確性。

（9）語言。不出現錯別字，不要出現有二義性的說法。特別要注意的是螢幕截圖或繪製圖形中的文字。

（10）印刷與包裝。檢查印刷質量；手冊厚度與開本是否合適；包裝盒的大小是否合適；有沒有零碎易丟失的小部件等等。

元測試主要內容是什麼？

單元測試大多數由開發人員來完成，測試人員技術背景較好或者開發系統軟體時可能會安排測試人員進行單元測試，大多數進行的單元測試都是開發人員除錯程式或者開發組系統聯合除錯的過程。討論這個問題主要是擴充一下讀者的視野。

單元測試一般包括五個方面的測試：

（1）模組介面測試：模組介面測試是單元測試的基礎。只有在資料能正確流入、流出模組的前提下，其他測試才有意義。模組介面測試也是整合測試的重點，這裡進行的測試主要是為後面打好基礎。測試介面正確與否應該考慮下列因素：

-輸入的實際引數與形式引數的個數是否相同；

-輸入的實際引數與形式引數的屬性是否匹配；

-輸入的實際引數與形式引數的量綱是否一致；

-呼叫其他模組時所給實際引數的個數是否與被調模組的形參個數相同；

-呼叫其他模組時所給實際引數的屬性是否與被調模組的形參屬性匹配；

-呼叫其他模組時所給實際引數的量綱是否與被調模組的形參量綱一致；

-呼叫預定義函式時所用引數的個數、屬性和次序是否正確；

-是否存在與當前入口點無關的引數引用；

-是否修改了只讀型引數；

-對全程變數的定義各模組是否一致；

-是否把某些約束作為引數傳遞。

如果模組功能包括外部輸入輸出，還應該考慮下列因素：

-檔案屬性是否正確；

-OPEN/CLOSE語句是否正確；

-格式說明與輸入輸出語句是否匹配；

-緩衝區大小與記錄長度是否匹配；

-檔案使用前是否已經開啟；

-是否處理了檔案尾；

-是否處理了輸入/輸出錯誤；

-輸出資訊中是否有文字性錯誤。

-區域性資料結構測試；

-邊界條件測試；

-模組中所有獨立執行通路測試；

（2）區域性資料結構測試：檢查區域性資料結構是為了保證臨時儲存在模組內的資料在程式執行過程中完整、正確，區域性功能是整個功能執行的基礎。重點是一些函式是否正確執行，內部是否執行正確。區域性資料結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：

-不合適或不相容的型別說明；

-變數無初值；

-變數初始化或省缺值有錯；

-不正確的變數名（拼錯或不正確地截斷）；

-出現上溢、下溢和地址異常。

（3）邊界條件測試：邊界條件測試是單元測試中最重要的一項任務。眾所周知，軟體經常在邊界上失效，採用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。邊界條件測試是一項基礎測試，也是後面系統測試中的功能測試的重點，邊界測試執行的較好，可以大大提高程式健壯性。

（4）模組中所有獨立路徑測試：在模組中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證模組中每條語句至少執行一次。測試目的主要是為了發現因錯誤計算、不正確的比較和不適當的控制流造成的錯誤。具體做法就是程式設計師逐條除錯語句。常見的錯誤包括：

-誤解或用錯了算符優先順序；

-混合型別運算；

-變數初值錯；

-精度不夠；

-表示式符號錯。

比較判斷與控制流常常緊密相關，測試時注意下列錯誤：

-不同資料型別的物件之間進行比較；

-錯誤地使用邏輯運算子或優先順序；

-因計算機表示的侷限性，期望理論上相等而實際上不相等的兩個量相等；

-比較運算或變量出錯；

-迴圈終止條件或不可能出現；

-迭代發散時不能退出；

-錯誤地修改了迴圈變數。

模組的各條錯誤處理通路測試：程式在遇到異常情況時不應該退出，好的程式應能預見各種出錯條件，並預設各種出錯處理通路。如果使用者不按照正常操作，程式就退出或者停止工作，實際上也是一種缺陷，因此單元測試要測試各種錯誤處理路徑。一般這種測試著重檢查下列問題：

-輸出的出錯資訊難以理解；

-記錄的錯誤與實際遇到的錯誤不相符；

-在程式自定義的出錯處理段執行之前，系統已介入；

-異常處理不當；

-錯誤陳述中未能提供足夠的定位出錯資訊。

如何理解強度測試？

強度測試是為了確定系統在最差工作環境的工作能力,也可能是用於驗證在標準工作壓力下的各種資源的最下限指標。

它和壓力測試的目標是不同的,壓力測試是在標準工作環境下,不斷增加系統負荷,最終測試出該系統能力達到的最大負荷(穩定和峰值),而強度測試則是在非標準工作環境下,甚至不斷人為降低系統工作環境所需要的資源,如網路頻寬,系統記憶體,資料鎖等等,以測試系統在資源不足的情況下的工作狀態,通過強度測試,可以確定本系統正常工作的最差環境.

強度測試和壓力測試的測試指標相近,大多都是與時間相關的指標,如併發量(吞吐量),延遲(最大\最小\平均)以及順序指標等

強度測試需要對系統的結構熟悉,針對系統的特徵設計強度測試的方法

如何理解壓力、負載、效能測試測試？

效能測試是一個較大的範圍，實際上效能測試本身包含了效能、強度、壓力、負載等多方面的測試內容。

壓力測試是對伺服器的穩定性以及負載能力等方面的測試，是一種很平常的測試。增大訪問系統的使用者數量、或者幾個使用者進行大資料量操作都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是效能測試的重要部分。100個使用者對系統進行連續半個小時的訪問可以看作壓力測試，那麼連續訪問8個小時就可以認為負載測試，1000個使用者連續訪問系統1個小時也可以看作是負載測試。

實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注整體效能的高度上來對系統進行測試。

什麼是系統瓶頸？

瓶頸主要是指整個軟硬體構成的軟體系統某一方面或者幾個方面能力不能滿足使用者的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前。

嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100％時，記憶體也正好耗盡的系統不是很多見。因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足使用者需求。在使用者極限使用系統的情況下，系統的響應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響使用者工作。

因此我們測試系統瓶頸主要是實現下面兩個目的：

-發現“表面”的瓶頸。主要是模擬使用者的操作，找出使用者極限使用系統時的瓶頸，然後解決瓶頸，這是效能測試的基本目標。

-發現潛在的瓶頸並解決，保證系統的長期穩定性。主要是考慮使用者在將來擴充套件系統或者業務發生變化時，系統能夠適應變化。滿足使用者目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟體生命週期能夠不斷適應使用者的變化，或者通過簡單擴充套件系統就可以適應新的變化。

文件測試主要包含什麼內容？

在國內軟體開發管理中，文件管理幾乎是最弱的一項，因而在測試工作中特別容易忽略文件測試也就不足為奇了。要想給使用者提供完整的產品，文件測試是必不可少的。文件測試一般注重下面幾個方面：

文件的完整性：主要是測試文件內容的全面性與完整性，從總體上把握文件的質量。例如使用者手冊應該包括軟體的所有功能模組。

描述與軟體實際情況的一致性：主要測試軟體文件與軟體實際的一致程度。例如使用者手冊基本完整後，我們還要注意使用者手冊與實際功能描述是否一致。因為文件往往跟不上軟體版本的更新速度。

易理解性：主要是檢查文件對關鍵、重要的操作有無圖文說明，文字、圖表是否易於理解。對於關鍵、重要的操作僅僅只有文字說明肯定是不夠的，應該附有圖表使說明更為直觀和明瞭。

文件中提供操作的例項：這項檢查內容主要針對使用者手冊。對主要功能和關鍵操作提供的應用例項是否豐富，提供的例項描述是否詳細。只有簡單的圖文說明，而無例項的使用者手冊看起來就像是軟體介面的簡單拷貝，對於使用者來說，實際上沒有什麼幫助。

印刷與包裝質量：主要是檢查軟體文件的商品化程度。有些使用者手冊是簡單列印、裝訂而成，過於粗糙，不易於使用者儲存。優秀的文件例如使用者手冊和技術白皮書，應提供商品化包裝，並且印刷精美。

配置和相容性測試的區別是什麼？

配置測試的目的是保證軟體在其相關的硬體上能夠正常執行，而相容性測試主要是測試軟體能否與不同的軟體正確協作。

配置測試的核心內容就是使用各種硬體來測試軟體的執行情況，一般包括：

（1）軟體在不同的主機上的執行情況，例如Dell和Apple；

（2）軟體在不同的元件上的執行情況，例如開發的撥號程式要測試在不同廠商生產的Modem上的執行情況；

（3）不同的外設；

（4）不同的介面；

（5）不同的可選項，例如不同的記憶體大小；

相容性測試的核心內容：

（1）測試軟體是否能在不同的作業系統平臺上相容；

（2）測試軟體是否能在同一作業系統平臺的不同版本上相容；

（3）軟體本身能否向前或者向後相容；

（4）測試軟體能否與其它相關的軟體相容；

（5）資料相容性測試，主要是指資料能否共享；

配置和相容性測試通稱對開發系統類軟體比較重要，例如驅動程式、作業系統、資料庫管理系統等。具體進行時仍然按照測試用例來執行。

軟體文件測試主要包含什麼？

隨著軟體文件系統日益龐大，文件測試已經成為軟體測試的重要內容。文件測試物件主要如下：

-包裝文字和圖形；

-市場宣傳材料、廣告以及其它插頁；

-授權、註冊登記表；

-終端使用者許可協議；

-安裝和設定嚮導；

-使用者手冊；

-聯機幫助；

-樣例、示範例子和模板；

-……

文件測試的目的是提高易用性和可靠性，降低支援費用，因為使用者通過文件就可以自己解決問題。因文件測試的檢查內容主要如下：

-讀者物件——主要是文件的內容是否能讓該級別的讀者理解；

-術語——主要是檢查術語是否適合讀者；

-內容和主題——檢查主題是否合適、是否丟失、格式是否規範等；

-圖示和螢幕抓圖——檢查圖表的準確度和精確度；

-樣例和示例——是否與軟體功能一致；

-拼寫和語法；

-文件的關聯性——是否與其它相關文件的內容一致，例如與廣告資訊是否一致；

文件測試是相當重要的一項測試工作，不但要給予充分的重視，更要要認真的完成，象做功能測試一樣來對待文件測試。

沒有產品說明書和需求文件地情況下能夠進行黑盒測試嗎？

這個問題是國內測試工程師經常遇到的問題，根源就是國內軟體開發文件管理不規範，對變更的管理方法就更不合理了。實際上沒有任何文件的時候，測試人員是能夠進行黑盒測試的，這種測試方式我們可以稱之為探索測試，具體做法就是測試工程師根據自己的專業技能、領域知識等不斷的深入瞭解測試物件、理解軟體功能，進而發現缺陷。

在這種做法基本上把軟體當成了產品說明書，測試過程中要和開發人員不斷的進行交流。尤其在作專案的時候，進度壓力比較大，可以作為加急測試方案。最大的風險是不知道有些特性是否被遺漏。

##3 測試中的“殺蟲劑怪事”是指什麼？
“殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟體測試技術》第二版中提出。用於描述測試人員對同一測試物件進行的測試次數越多，發現的缺陷就會越來越少的現象。就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力。這種現象的根本原因就是測試人員對測試軟體過於熟悉，形成思維定勢。

為了克服這種現象，測試人員需要不斷編寫新的測試程式或者測試用例，對程式的不同部分進行測試，以發現更多的缺陷。也可以引用新人來測試軟體，剛剛進來的新手往往能發現一些意想不到的問題。

在配置測試中，如何判斷髮現的缺陷是普通問題還是特定的配置問題？

在進行配置測試時，測試工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷。因此判斷新發現的問題，需要在不同的配置中重新執行發現軟體缺陷的步驟，如果軟體缺陷不出現了，就可能是配置缺陷；如果在所有的配置中都出現，就可能是普通缺陷。

需要注意的是，配置問題可以在一大類配置中出現。例如，撥號程式可能在所有的外接Modem中都存在問題，而內建的Modem不會有任何問題。

完全測試程式是可能的嗎？

軟體測試初學者可能認為拿到軟體後需要進行完全測試，找到全部的軟體缺陷，使軟體“零缺陷”釋出。實際上完全測試是不可能的。主要有以下一個原因：

-完全測試比較耗時，時間上不允許；

-完全測試通常意味著較多資源投入，這在現實中往往是行不通的；

-輸入量太大，不能一一進行測試；

-輸出結果太多，只能分類進行驗證；

-軟體實現途徑太多；

-軟體產品說明書沒有客觀標準，從不同的角度看，軟體缺陷的標準不同；

因此測試的程度要根據實際情況確定。

軟體測試的風險主要體現在哪裡？

我們沒有對軟體進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。舉個例子，程式設計師為了方便，在除錯程式時會彈出一些提示資訊框，而這些提示只在某種條件下會彈出，碰巧程式釋出前這些程式碼中的一些沒有被註釋掉。在測試時測試工程師又沒有對其進行測試。如果客戶碰到它，這將是代價昂貴的缺陷，因為交付後才被客戶發現。

因此，我們要儘可能的選擇最合適的測試量，把風險降低到最小。

發現的缺陷越多，說明軟體缺陷越多嗎？

這是一個比較常見的現象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個後，會接二連三的發現很多缺陷，頗有個人成就感。其中的原因主要如下：

-程式碼複用、拷貝程式碼導致程式設計師容易犯相同的錯誤。類的繼承導致所有的子類會包含基類的錯誤，反覆拷貝同一程式碼意味可能也複製了缺陷。

-程式設計師比較勞累是可以導致某些連續編寫的功能缺陷較多。程式設計師加班是一種司空見慣的現象，因此體力不只時容易編寫一些缺陷較多的程式。而這些連續潛伏缺陷恰恰時測試工程師大顯身手的地方。

“缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象。如果軟體編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程式就可以了。

所有的軟體缺陷都能修復嗎？所有的軟體缺陷都要修復嗎？

從技術上講，所有的軟體缺陷都是能夠修復的，但是沒有必要修復所有的軟體缺陷。測試人員要做的是能夠正確判斷什麼時候不能追求軟體的完美。對於整個專案團隊，要做的是對每一個軟體缺陷進行取捨，根據風險決定那些缺陷要修復。發生這種現象的主要原因如下：

-沒有足夠的時間資源。在任何一個專案中，通常情況下開發人員和測試人員都是不夠用的，而且在專案中沒有預算足夠的迴歸測試時間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力下，必須放棄某些缺陷的修改。

-有些缺陷只是特殊情況下出現，這種缺陷處於商業利益考慮，可以在以後升級中進行修復。

-不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以後有時間時考慮再處理。

最後要說的是，缺陷是否修改要由軟體測試人員、專案經理、程式設計師共同討論來決定是否修復，不同角色的人員從不同的角度來思考，以做出正確的決定。

軟體測試人員就是QA嗎？

軟體測試人員的職責是儘可能早的找出軟體缺陷，確保得以修復。而質量保證人員（QA）主要職責是建立或者制定標準和方法，提高促進軟體開發能力和減少軟體缺陷。測試人員的主要工作是測試，質量保證人員日常工作重要內容是檢查與評審，測試工作也是測試保證人員的工作物件。

軟體測試和質量是相輔相成的關係，都是為了提高軟體質量而工作。

如何減少測試人員跳槽帶來的損失？

在IT行業裡跳槽已經是一種司空見慣的現象，而且跳槽無論給公司還是給個人都會帶來一定的損失。測試隊伍也無疑會面臨跳槽的威脅，作為測試經理管理者，只有從日常工作中開始做起，最能最大限度的減少損失。建議我們從以下兩個方面做起：

-加強部門內員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的過程。在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化。

-通常情況下，企業能為員工提供足夠大的發展空間時，如果不是待遇特別低，員工都不會主動離開企業。因此我們要想留住員工，管理者就應該把員工的個人成長和企業的發展聯絡起來，為員工設定合理發展規劃並付諸實現。不過這項要求做起來比較，要有比較好的企業文化為依託.

以windows對檔案的複製粘帖功能為例，儘可能多地寫出測試思路

1、 基本功能測試： 檔案的複製貼上功能，首先關鍵字“檔案”，檔案有不同的分類（圖片、視訊、音訊、文件等），每個分類又有不同的型別（文件型別：txt doc execl pdf等），每個檔案又有不同的大小，而且檔案還有很多許可權，是不是隱藏，是不是隻是管理員可執行。選擇不同分類的不同型別，不同大小的檔案做測試資源。比如：文件型別裡面txt檔案可以分為 1.KB的txt檔案、1MB的txt檔案、1GB的txt檔案。。。。
下一個關鍵字 複製貼上 複製有多種方式 右擊選擇、Ctrl+C、 拖動複製，對應貼上也有各種方式。然後從哪複製，貼上到哪，比如 可以有本機硬碟、行動硬碟、優盤、記憶體卡、軟盤、光碟、連線手機儲存，複製到網路地址等等。複製粘貼後檔案是不是可用，檔案許可權是不是有變化。複製過去容量不夠怎麼處理？複製過後有重名檔案怎麼處理？複製過程中取消、關機、拔優盤怎麼處理？複製過程能不能執行檔案？

2.效能測試：複製貼上功能效能怎麼樣？複製檔案的速度可不可以接受？同時複製多個檔案是不是可以完成?複製檔案過程中佔用CPU資源大不大，耗電量大不大？

3.相容性測試 Windows XP, Windows 7, Windows 8 , Windows 8.1, Windows 10等各種windos版本是不是都支援這個功能。

4.互動測試; 複製貼上檔案時，使用windows儲存的其他功能是否有影響？比如播放本地的音訊、視訊、等同時複製檔案是不是有影響。一邊複製，一邊貼上是不是有影響。

貼上的穩定性：貼上完了大小會不會變化，內容格式會不會變化，貼上不上，誤操作以後還能不能找到複製的內容等

貼上的安全性：貼上的內容貼上好了以後會不會存在別處洩露等

2.效能測試：（1）時間：複製貼上的響應時間？頁面的顯示時間？（2）負載：多次重複進行復制貼上是否有異常？複製貼上容量很大的一個或多個檔案是否能承受？（3）強度：保證容量足夠的條件下，分別複製貼上50GB，100GB，500GB，…大小的檔案，看什麼時候出現失敗，失敗後的表現，能否重新正常複製貼上50G？（4）容量：在不同CPU資源條件下，持續複製貼上5分鐘，最多能複製貼上多少容量的檔案？

5.介面測試：複製貼上時進度條的顯示介面是否與系統的設計風格一致？顯示介面是否有文字性錯誤？顯示介面的布是否合理？介面上的按鈕是否可用（如：是否可以選擇中止？是否可用最小化？）

6.本地化測試：不同語言環境下的顯示正常

7.輔助性測試：高對比度下能否顯示正常

1 、複製貼上方法

快捷鍵測試：測試 Ctrl+C ，是否正確執行復制、 Ctrl+v 是否支援貼上功能

右鍵測試：檢視複製貼上功能是否正確執行；

在 cmd 命令列中使用複製貼上命令；

2 、檔案大小測試

原始檔為空， 0 位元組；

原始檔正常大小；

原始檔為超大檔案： **G/ 等；

3 、檔案格式

測試各種檔案格式下是否正常複製貼上：如：圖片、聲音、視訊、壓縮檔案、辦公檔案： word\excel\ppt 等、二進位制檔案；

測試共享檔案、隱藏檔案

4 、複製和貼上檔案路徑

在系統不同檔案路徑下複製貼上，

測試相對路徑和絕對路徑下檔案複製貼上；

測試資料夾下和另一個不同資料夾複製貼上；

測試不同 C\D\E 盤之間；

測試複製貼上至：行動硬碟、 U 盤、讀卡器以及其它外部儲存裝置；

5 、異常測試

測試被損壞檔案、不完整檔名稱、禁止複製和貼上的檔案、超出規定大小檔案等；

同名稱檔案測試是否提醒替換或覆蓋；

6 、相容性

測試不同作業系統之間、不同應用程式（如： QQ ）；

7 、效能測試：

測試複製貼上可支援最大檔案大小；複製貼上操作的相應速度、執行完畢時間；

一次支援不同格式的檔案同時操作；

支援大量檔案同時複製貼上；

登入介面測試用例設計

一、介面測試點：

1、介面的設計風格是否與UI的設計風格統一；

2、介面中的文字簡潔易懂；

3、介面中沒有錯別字；

二、使用者名稱與密碼在輸入時，要考慮：

1、正確的使用者名稱與正確的密碼；

2、正確的使用者名稱與錯誤的密碼；

3、錯誤的使用者名稱與正確的密碼；

4、錯誤的使用者名稱與錯誤的密碼；

5、空的使用者名稱和空的密碼；

6、正確的使用者名稱和空的密碼；

7、空的使用者名稱和正確的密碼；

8、使用者名稱的前/中/後含有空格；

9、密碼的前/中/後含有空格；

10、使用者名稱與密碼使用的字元範圍及位數限制的測試（等價類及邊界值，會用到強制的複製與貼上來實現不允許輸入的字元，以及一些保留字的測試）；

11、牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使用者），重新整理或換一個按鈕是否好用；

三、安全性測試：

1、密碼是否隱蔽顯示；

3、不能直接輸入，就copy，是否資料檢驗出錯；

還要準確定位每一個輸入框的功能，每一種錯誤情況下，出現的錯誤提示要準確或者合適。

四、相容性測試：

1 2	1.不同瀏覽器測試 2.瀏覽器不同版本測試

五、其他測試點：

1、輸入框之間考慮tab鍵是否支援；

2、登入按鈕要考慮回車鍵是否支援；

3、取消後的預設位置（一般為空白的使用者名稱輸入框）；

4、登入後的跳轉頁面是否正確（一般為首頁）；

5、要考慮多次點選登入和取消按鈕的介面反應；

6、考慮是否支援多使用者在同一機器上登入；

7、考慮一使用者在多臺機器上登入；

8、登入頁面中的註冊等連結是否正確