軟體缺陷：
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報告狀態分為以下幾種狀態，
待確認的 unconfirmed
新提交的 new
已分配的 assigned
問題未解決的 reopened
待返測的 resolved
待歸檔的 verified
已歸檔的 closed
Bug處理意見（Resolution）
已修改的 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個最基本的活動：
配置項標識
配置項控制
配置項狀態報告
配置審計
軟體配置管理通常借助工具來輔助，主要有MS SourceSafe、Rational ClearCase等
你覺得軟體測驗通過的標準應該是什么樣的？
缺陷密度值達到客戶的要求
引入測驗管理的含義？
風險分析，進度控制、角色分配、質量控制
一套完整的測驗應該由哪些階段組成？
參考答案：測驗計劃、測驗設計與開發、測驗實施、測驗評審與測驗結論
單元測驗的主要內容？
模塊介面測驗、區域資料結構測驗、路徑測驗、錯誤處理測驗、邊界測驗
集成測驗也叫組裝測驗或者聯合測驗，請簡述集成測驗的主要內容？
（1）在把各個模塊連接起來的時候，穿越模塊介面的資料是否會丟失；
（2）一個模塊的功能是否會對另一個模塊的功能產生不利的影響；
（3）各個子功能組合起來，能否達到預期要求的父功能；
（4）全域資料結構是否有問題；
（5）單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度，
簡述集成測驗與系統測驗關系？
（1）集成測驗的主要依據概要設計說明書，系統測驗的主要依據是需求設計說明書；
（2）集成測驗是系統模塊的測驗，系統測驗是對整個系統的測驗，包括相關的軟硬體平臺、網路以及相關外設的測驗，
軟體測驗的檔案測驗應當貫穿于軟體生命周期的全程序，其中用戶檔案是檔案測驗的重點，那么軟體系統的用戶檔案包括哪些？
用戶手冊
安裝和設定指導
聯機幫助
指南、向導
樣例、示例和模板
授權/注冊登記表
最終用戶許可協議
軟體系統中除用戶檔案之外，檔案測驗還應該關注哪些檔案？
開發檔案
軟體需求說明書
資料庫設計說明書
概要設計說明書
詳細設計說明書
可行性研究報告
管理檔案
專案開發計劃
測驗計劃
測驗報告
開發進度月報
開發總結報告
簡述軟體系統中用戶檔案的測驗要點？
（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、輸入框之間考慮tab鍵是否支持；
2、登錄按鈕要考慮回車鍵是否支持；
3、取消后的默認位置（一般為空白的用戶名輸入框）；
4、登錄后的跳轉頁面是否正確（一般為首頁）；
5、要考慮多次點擊登錄和取消按鈕的界面反應；
6、考慮是否支持多用戶在同一機器上登錄；
7、考慮一用戶在多臺機器上登錄；
8、登錄頁面中的注冊等鏈接是否正確
看完點贊~養成好習慣~~642830685，群內免費領取最新軟體測驗大廠面試資料和Python自動化、介面、框架搭建學習資料！技術大牛解惑答疑，同行一起交流，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/107670.html
標籤：其他
上一篇：寫博客的初衷