軟件缺陷：
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、測試數據，測試的數據作為重現缺陷的一個重要元素信息，一定要將測試時所使用的信息給描寫清楚准確。讓開發人員根據測試所提供的測試數據准確重現缺陷。
如何對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-》回歸測試
軟件開發模型：
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測試的策略）
正交表測試用例設計方法的特點是什么？
用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很復雜；
對於基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；
具體的環境下，正交表一般都很難做的。大多數，只在系統測試的時候使用此方法。
描述測試用例設計的完整過程？
需求分析 + 需求變更的維護工作；
根據需求 得出測試需求；
設計測試方案，評審測試方案；
方案評審通過后，設計測試用例，再對測試用例進行評審；
單元測試的策略有哪些？
單元的常見錯誤一般出現在以下五個方面，因此這五個方面是單元測試應該關注的重點。
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個最基本的活動：
配置項標識
配置項控制
配置項狀態報告
配置審計
軟件配置管理通常借助工具來輔助，主要有MS SourceSafe、Rational ClearCase等
- 1
你覺得軟件測試通過的標准應該是什么樣的？
缺陷密度值達到客戶的要求
- 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.輔助性測試：高對比度下能否顯示正常