31、一套完整的測試應該由哪些階段組成？
參考答案：測試計劃、測試設計與開發、測試實施、測試評審與測試結論
32、單元測試的主要内容？
參考答案：
子產品接口測試、局部資料結構測試、路徑測試、錯誤處理測試、邊界測試
33、內建測試也叫組裝測試或者聯合測試，請簡述內建測試的主要内容？
參考答案：
（1）在把各個子產品連接配接起來的時候，穿越子產品接口的資料是否會丢失；
（2）一個子產品的功能是否會對另一個子產品的功能産生不利的影響；
（3）各個子功能組合起來，能否達到預期要求的父功能；
（4）全局資料結構是否有問題；
（5）單個子產品的誤差累積起來，是否會放大，進而達到不能接受的程度。
34、簡述內建測試與系統測試關系？
參考答案：
（1）內建測試的主要依據概要設計說明書，系統測試的主要依據是需求設計說明書；
（2）內建測試是系統子產品的測試，系統測試是對整個系統的測試，包括相關的軟硬體平台、網絡以及相關外設的測試。
35、軟體測試的文檔測試應當貫穿于軟體生命周期的全過程，其中使用者文檔是文檔測試的重點。那麼軟體系統的使用者文檔包括哪些？
參考答案：
使用者手冊
安裝和設定指導
聯機幫助
指南、向導
樣例、示例和模闆
授權/注冊登記表
最終使用者許可協定
36、軟體系統中除使用者文檔之外，文檔測試還應該關注哪些文檔？
參考答案：
開發文檔
軟體需求說明書
資料庫設計說明書
概要設計說明書
詳細設計說明書
可行性研究報告
管理文檔
項目開發計劃
測試計劃
測試報告
開發進度月報
開發總結報告
37、簡述軟體系統中使用者文檔的測試要點？
參考答案：
（1）讀者群。文檔面向的讀者定位要明确。對于初級使用者、中級使用者以及進階使用者應該有不同的定位
（2）術語。文檔中用到的術語要适用與定位的讀者群，用法一緻，标準定義與業界規範相吻合。
（3）正确性。測試中需檢查所有資訊是否真實正确，查找由于過期産品說明書和銷售人員誇大事實而導緻的錯誤。檢查所有的目錄、索引和章節引用是否已更新，嘗試連結是否準确，産品支援電話、位址和郵政編碼是否正确。
（4）完整性。對照軟體界面檢查是否有重要的分支沒有描述到，甚至是否有整個大子產品沒有描述到。
（5）一緻性。按照文檔描述的操作執行後，檢查軟體傳回的結果是否與文檔描述的相同。
（6）易用性。對關鍵步驟以粗體或背景色給使用者以提示，合理的頁面布局、适量的圖表都可以給使用者更高的易用性。需要注意的是文檔要有助于使用者排除錯誤。不但描述正确操作，也要描述錯誤處理辦法。文檔對于使用者看到的錯誤資訊應當有更詳細的文檔解釋。
（7）圖表與界面截圖。檢查所有圖表與界面截圖是否與發行版本相同。
（8）樣例與示例。像使用者一樣載入和使用樣例。如果是一段程式，就輸入資料并執行它。以每一個子產品制作檔案，确認它們的正确性。
（9）語言。不出現錯别字，不要出現有二義性的說法。特别要注意的是螢幕截圖或繪制圖形中的文字。
（10）印刷與包裝。檢查印刷品質；手冊厚度與開本是否合适；包裝盒的大小是否合适；有沒有零碎易丢失的小部件等等。
38、單元測試主要内容是什麼？
參考答案：
單元測試大多數由開發人員來完成，測試人員技術背景較好或者開發系統軟體時可能會安排測試人員進行單元測試，大多數進行的單元測試都是開發人員調試程式或者開發組系統聯合調試的過程。讨論這個問題主要是擴充一下讀者的視野。
單元測試一般包括五個方面的測試：
（1）子產品接口測試：子產品接口測試是單元測試的基礎。隻有在資料能正确流入、流出子產品的前提下，其他測試才有意義。子產品接口測試也是內建測試的重點，這裡進行的測試主要是為後面打好基礎。測試接口正确與否應該考慮下列因素：
-輸入的實際參數與形式參數的個數是否相同；
-輸入的實際參數與形式參數的屬性是否比對；
-輸入的實際參數與形式參數的量綱是否一緻；
-調用其他子產品時所給實際參數的個數是否與被調子產品的形參個數相同；
-調用其他子產品時所給實際參數的屬性是否與被調子產品的形參屬性比對；
-調用其他子產品時所給實際參數的量綱是否與被調子產品的形參量綱一緻；
-調用預定義函數時所用參數的個數、屬性和次序是否正确；
-是否存在與目前入口點無關的參數引用；
-是否修改了隻讀型參數；
-對全程變量的定義各子產品是否一緻；
-是否把某些限制作為參數傳遞。
如果子產品功能包括外部輸入輸出，還應該考慮下列因素：
-檔案屬性是否正确；
-OPEN/CLOSE語句是否正确；
-格式說明與輸入輸出語句是否比對；
-緩沖區大小與記錄長度是否比對；
-檔案使用前是否已經打開；
-是否處理了檔案尾；
-是否處理了輸入/輸出錯誤；
-輸出資訊中是否有文字性錯誤。
-局部資料結構測試；
-邊界條件測試；
-子產品中所有獨立執行通路測試；
（2）局部資料結構測試：檢查局部資料結構是為了保證臨時存儲在子產品内的資料在程式執行過程中完整、正确，局部功能是整個功能運作的基礎。重點是一些函數是否正确執行，内部是否運作正确。局部資料結構往往是錯誤的根源，應仔細設計測試用例，力求發現下面幾類錯誤：
-不合适或不相容的類型說明；
-變量無初值；
-變量初始化或省缺值有錯；
-不正确的變量名（拼錯或不正确地截斷）；
-出現上溢、下溢和位址異常。
（3）邊界條件測試：邊界條件測試是單元測試中最重要的一項任務。衆所周知，軟體經常在邊界上失效，采用邊界值分析技術，針對邊界值及其左、右設計測試用例，很有可能發現新的錯誤。邊界條件測試是一項基礎測試，也是後面系統測試中的功能測試的重點，邊界測試執行的較好，可以大大提高程式健壯性。
（4）子產品中所有獨立路徑測試：在子產品中應對每一條獨立執行路徑進行測試，單元測試的基本任務是保證子產品中每條語句至少執行一次。測試目的主要是為了發現因錯誤計算、不正确的比較和不适當的控制流造成的錯誤。具體做法就是程式員逐條調試語句。常見的錯誤包括：
-誤解或用錯了算符優先級；
-混合類型運算；
-變量初值錯；
-精度不夠；
-表達式符号錯。
比較判斷與控制流常常緊密相關，測試時注意下列錯誤：
-不同資料類型的對象之間進行比較；
-錯誤地使用邏輯運算符或優先級；
-因計算機表示的局限性，期望理論上相等而實際上不相等的兩個量相等；
-比較運算或變量出錯；
-循環終止條件或不可能出現；
-疊代發散時不能退出；
-錯誤地修改了循環變量。
子產品的各條錯誤處理通路測試：程式在遇到異常情況時不應該退出，好的程式應能預見各種出錯條件，并預設各種出錯處理通路。如果使用者不按照正常操作，程式就退出或者停止工作，實際上也是一種缺陷，是以單元測試要測試各種錯誤處理路徑。一般這種測試着重檢查下列問題：
-輸出的出錯資訊難以了解；
-記錄的錯誤與實際遇到的錯誤不相符；
-在程式自定義的出錯處理段運作之前，系統已介入；
-異常處理不當；
-錯誤陳述中未能提供足夠的定位出錯資訊。
39、如何了解強度測試？
參考答案：
強度測試是為了确定系統在最差工作環境的工作能力,也可能是用于驗證在标準工作壓力下的各種資源的最下限名額。
它和壓力測試的目标是不同的,壓力測試是在标準工作環境下,不斷增加系統負荷,最終測試出該系統能力達到的最大負荷(穩定和峰值),而強度測試則是在非标準工作環境下,甚至不斷人為降低系統工作環境所需要的資源,如網絡帶寬,系統記憶體,資料鎖等等,以測試系統在資源不足的情況下的工作狀态,通過強度測試,可以确定本系統正常工作的最差環境.
強度測試和壓力測試的測試名額相近,大多都是與時間相關的名額,如并發量(吞吐量),延遲(最大\最小\平均)以及順序名額等
強度測試需要對系統的結構熟悉,針對系統的特征設計強度測試的方法
40、如何了解壓力、負載、性能測試測試？
參考答案：
性能測試是一個較大的範圍，實際上性能測試本身包含了性能、強度、壓力、負載等多方面的測試内容。
壓力測試是對伺服器的穩定性以及負載能力等方面的測試，是一種很平常的測試。增大通路系統的使用者數量、或者幾個使用者進行大資料量操作都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是性能測試的重要部分。100個使用者對系統進行連續半個小時的通路可以看作壓力測試，那麼連續通路8個小時就可以認為負載測試，1000個使用者連續通路系統1個小時也可以看作是負載測試。
實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注整體性能的高度上來對系統進行測試。
41、什麼是系統瓶頸？
參考答案：
瓶頸主要是指整個軟硬體構成的軟體系統某一方面或者幾個方面能力不能滿足使用者的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前。
嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100％時，記憶體也正好耗盡的系統不是很多見。是以我們讨論系統瓶頸要從應用的角度讨論：關鍵是看系統能否滿足使用者需求。在使用者極限使用系統的情況下，系統的響應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響使用者工作。
是以我們測試系統瓶頸主要是實作下面兩個目的：
-發現“表面”的瓶頸。主要是模拟使用者的操作，找出使用者極限使用系統時的瓶頸，然後解決瓶頸，這是性能測試的基本目标。
-發現潛在的瓶頸并解決，保證系統的長期穩定性。主要是考慮使用者在将來擴充系統或者業務發生變化時，系統能夠适應變化。滿足使用者目前需求的系統不是最好的，我們設計系統的目标是在保證系統整個軟體生命周期能夠不斷适應使用者的變化，或者通過簡單擴充系統就可以适應新的變化。
42、文檔測試主要包含什麼内容？
參考答案：
在國内軟體開發管理中，文檔管理幾乎是最弱的一項，因而在測試工作中特别容易忽略文檔測試也就不足為奇了。要想給使用者提供完整的産品，文檔測試是必不可少的。文檔測試一般注重下面幾個方面：
文檔的完整性：主要是測試文檔内容的全面性與完整性，從總體上把握文檔的品質。例如使用者手冊應該包括軟體的所有功能子產品。
描述與軟體實際情況的一緻性：主要測試軟體文檔與軟體實際的一緻程度。例如使用者手冊基本完整後，我們還要注意使用者手冊與實際功能描述是否一緻。因為文檔往往跟不上軟體版本的更新速度。
易了解性：主要是檢查文檔對關鍵、重要的操作有無圖文說明，文字、圖表是否易于了解。對于關鍵、重要的操作僅僅隻有文字說明肯定是不夠的，應該附有圖表使說明更為直覺和明了。
文檔中提供操作的執行個體：這項檢查内容主要針對使用者手冊。對主要功能和關鍵操作提供的應用執行個體是否豐富，提供的執行個體描述是否詳細。隻有簡單的圖文說明，而無執行個體的使用者手冊看起來就像是軟體界面的簡單拷貝，對于使用者來說，實際上沒有什麼幫助。
印刷與包裝品質：主要是檢查軟體文檔的商品化程度。有些使用者手冊是簡單列印、裝訂而成，過于粗糙，不易于使用者儲存。優秀的文檔例如使用者手冊和技術白皮書，應提供商品化包裝，并且印刷精美。
43、功能測試用例需要詳細到什麼程度才是合格的？
參考答案：
這個問題也是測試工程師經常問的問題。有人主張測試用例詳細到每個步驟執行什麼都要寫出來，目的是即使一個不了解系統的新手都可以按照測試用例來執行工作。主張這類寫法的人還可以舉出例子：歐美、日本等軟體外封包檔都是這樣做的。
另外一種觀點就是主張寫的粗些，類似于編寫測試大綱。主張這種觀點的人是因為軟體開發需求管理不規範，變動十分頻繁，因而不能按照歐美的高标準來編寫測試用例。這樣的測試用例容易維護，可以讓測試執行人員有更大的發揮空間。
實際上，軟體測試用例的詳細程度首先要以覆寫到測試點為基本要求。舉個例子：“使用者登陸系統”的測試用例可以不寫出具體的執行資料，但是至少要寫出五種以上情況（），如果隻用一句話覆寫了這個功能是不合格的測試用例。覆寫功能點不是指列出功能點，而是要寫出功能點的各個方面（如果組合情況較多時可以采用等價劃分）。
另一個影響測試用例的就是組織的開發能力和測試對象特點。如果開發力量比較落後，編寫較詳細的測試用例是不現實的，因為根本沒有那麼大的資源投入，當然這種情況很随着團隊的發展而逐漸有所改善。測試對象特點重點是指測試對象在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高品質的測試用例的，甚至有些時候測試工作隻是一種輔助工作，因而不編寫測試用例。
是以，測試用例的編寫要根據測試對象特點、團隊的執行能力等各個方面綜合起來決定編寫政策。最後要注意的是測試人員一定不能抱怨，力争在不斷提高測試用例編寫水準的同時，不斷地提高自身能力。
44、配置和相容性測試的差別是什麼？
參考答案：
配置測試的目的是保證軟體在其相關的硬體上能夠正常運作，而相容性測試主要是測試軟體能否與不同的軟體正确協作。
配置測試的核心内容就是使用各種硬體來測試軟體的運作情況，一般包括：
（1）軟體在不同的主機上的運作情況，例如Dell和Apple；
（2）軟體在不同的元件上的運作情況，例如開發的撥号程式要測試在不同廠商生産的Modem上的運作情況；
（3）不同的外設；
（4）不同的接口；
（5）不同的可選項，例如不同的記憶體大小；
相容性測試的核心内容：
（1）測試軟體是否能在不同的作業系統平台上相容；
（2）測試軟體是否能在同一作業系統平台的不同版本上相容；
（3）軟體本身能否向前或者向後相容；
（4）測試軟體能否與其它相關的軟體相容；
（5）資料相容性測試，主要是指資料能否共享；
配置和相容性測試通稱對開發系統類軟體比較重要，例如驅動程式、作業系統、資料庫管理系統等。具體進行時仍然按照測試用例來執行。
45、軟體文檔測試主要包含什麼？
參考答案：
随着軟體文檔系統日益龐大，文檔測試已經成為軟體測試的重要内容。文檔測試對象主要如下：
-包裝文字和圖形；
-市場宣傳材料、廣告以及其它插頁；
-授權、注冊登記表；
-最終使用者許可協定；
-安裝和設定向導；
-使用者手冊；
-聯機幫助；
-樣例、示範例子和模闆；
-……
文檔測試的目的是提高易用性和可靠性，降低支援費用，因為使用者通過文檔就可以自己解決問題。因文檔測試的檢查内容主要如下：
-讀者對象——主要是文檔的内容是否能讓該級别的讀者了解；
-術語——主要是檢查術語是否适合讀者；
-内容和主題——檢查主題是否合适、是否丢失、格式是否規範等；
-圖示和螢幕抓圖——檢查圖表的準确度和精确度；
-樣例和示例——是否與軟體功能一緻；
-拼寫和文法；
-文檔的關聯性——是否與其它相關文檔的内容一緻，例如與廣告資訊是否一緻；
文檔測試是相當重要的一項測試工作，不但要給予充分的重視，更要要認真的完成，象做功能測試一樣來對待文檔測試。
46、沒有産品說明書和需求文檔地情況下能夠進行黑盒測試嗎？
參考答案：
這個問題是國内測試工程師經常遇到的問題，根源就是國内軟體開發文檔管理不規範，對變更的管理方法就更不合理了。實際上沒有任何文檔的時候，測試人員是能夠進行黑盒測試的，這種測試方式我們可以稱之為探索測試，具體做法就是測試工程師根據自己的專業技能、領域知識等不斷的深入了解測試對象、了解軟體功能，進而發現缺陷。
在這種做法基本上把軟體當成了産品說明書，測試過程中要和開發人員不斷的進行交流。尤其在作項目的時候，進度壓力比較大，可以作為加急測試方案。最大的風險是不知道有些特性是否被遺漏。
47、測試中的“殺蟲劑怪事”是指什麼？
參考答案：
“殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟體測試技術》第二版中提出。用于描述測試人員對同一測試對象進行的測試次數越多，發現的缺陷就會越來越少的現象。就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力。這種現象的根本原因就是測試人員對測試軟體過于熟悉，形成思維定勢。
為了克服這種現象，測試人員需要不斷編寫新的測試程式或者測試用例，對程式的不同部分進行測試，以發現更多的缺陷。也可以引用新人來測試軟體，剛剛進來的新手往往能發現一些意想不到的問題。
48、在配置測試中，如何判斷發現的缺陷是普通問題還是特定的配置問題？
參考答案：
在進行配置測試時，測試工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷。是以判斷新發現的問題，需要在不同的配置中重新執行發現軟體缺陷的步驟，如果軟體缺陷不出現了，就可能是配置缺陷；如果在所有的配置中都出現，就可能是普通缺陷。
需要注意的是，配置問題可以在一大類配置中出現。例如，撥号程式可能在所有的外置Modem中都存在問題，而内置的Modem不會有任何問題。
49、為什麼盡量不要讓時間有富裕的員工去做一些測試？
參考答案：
表面上看這展現了管理的效率和靈活性，但實際上也展現了管理者對測試的輕視。測試和測試的人有很大關系。測試從業人員應該是勤奮并富有耐心，善于學習、思考和發現問題，細心有條理，總結問題，如果具備這樣的優點，做其它工作同樣也會很出色，是以這裡還有一個要求，就是要喜歡測試這項工作。如果他是專職的，那麼肯定更有經驗和信心。國内的小夥子好象都喜歡做程式員，兩者工作性質不同，待遇不同，地位不同，對自我實作的價值的認識也不同，這是行業的一個需要改善的問題。如果隻是為了完成任務而完成任務，或者發現了幾個問題就覺得滿意了，這在任何其它工作中都是不行的。
50、完全測試程式是可能的嗎？
參考答案：
軟體測試初學者可能認為拿到軟體後需要進行完全測試，找到全部的軟體缺陷，使軟體“零缺陷”釋出。實際上完全測試是不可能的。主要有以下一個原因：
-完全測試比較耗時，時間上不允許；
-完全測試通常意味着較多資源投入，這在現實中往往是行不通的；
-輸入量太大，不能一一進行測試；
-輸出結果太多，隻能分類進行驗證；
-軟體實作途徑太多；
-軟體産品說明書沒有客觀标準，從不同的角度看，軟體缺陷的标準不同；
是以測試的程度要根據實際情況确定。
51、軟體測試的風險主要展現在哪裡？
參考答案：
我們沒有對軟體進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。舉個例子，程式員為了友善，在調試程式時會彈出一些提示資訊框，而這些提示隻在某種條件下會彈出，碰巧程式釋出前這些代碼中的一些沒有被注釋掉。在測試時測試工程師又沒有對其進行測試。如果客戶碰到它，這将是代價昂貴的缺陷，因為傳遞後才被客戶發現。
是以，我們要盡可能的選擇最合适的測試量，把風險降低到最小。
52、發現的缺陷越多，說明軟體缺陷越多嗎？
參考答案：
這是一個比較常見的現象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個後，會接二連三的發現很多缺陷，頗有個人成就感。其中的原因主要如下：
-代碼複用、拷貝代碼導緻程式員容易犯相同的錯誤。類的繼承導緻所有的子類會包含基類的錯誤，反複拷貝同一代碼意味可能也複制了缺陷。
-程式員比較勞累是可以導緻某些連續編寫的功能缺陷較多。程式員加班是一種司空見慣的現象，是以體力不隻時容易編寫一些缺陷較多的程式。而這些連續潛伏缺陷恰恰時測試工程師大顯身手的地方。
“缺陷一個連着一個”不是一個客觀規律，隻是一個常見的現象。如果軟體編寫的比較好，這種現象就不常見了。測試人員隻要嚴肅認真的測試程式就可以了。
53、所有的軟體缺陷都能修複嗎？所有的軟體缺陷都要修複嗎？
參考答案：
從技術上講，所有的軟體缺陷都是能夠修複的，但是沒有必要修複所有的軟體缺陷。測試人員要做的是能夠正确判斷什麼時候不能追求軟體的完美。對于整個項目團隊，要做的是對每一個軟體缺陷進行取舍，根據風險決定那些缺陷要修複。發生這種現象的主要原因如下：
-沒有足夠的時間資源。在任何一個項目中，通常情況下開發人員和測試人員都是不夠用的，而且在項目中沒有預算足夠的回歸測試時間，再加上修改缺陷可能引入新的缺陷，是以在傳遞期限的強大壓力下，必須放棄某些缺陷的修改。
-有些缺陷隻是特殊情況下出現，這種缺陷處于商業利益考慮，可以在以後更新中進行修複。
-不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以後有時間時考慮再處理。
最後要說的是，缺陷是否修改要由軟體測試人員、項目經理、程式員共同讨論來決定是否修複，不同角色的人員從不同的角度來思考，以做出正确的決定。
54、軟體測試人員就是QA嗎？
參考答案：
軟體測試人員的職責是盡可能早的找出軟體缺陷，確定得以修複。而品質保證人員（QA）主要職責是建立或者制定标準和方法，提高促進軟體開發能力和減少軟體缺陷。測試人員的主要工作是測試，品質保證人員日常工作重要内容是檢查與評審，測試工作也是測試保證人員的工作對象。
軟體測試和品質是相輔相成的關系，都是為了提高軟體品質而工作。
55、如何減少測試人員跳槽帶來的損失？
參考答案：
在IT行業裡跳槽已經是一種司空見慣的現象，而且跳槽無論給公司還是給個人都會帶來一定的損失。測試隊伍也無疑會面臨跳槽的威脅，作為測試經理管理者，隻有從日常工作中開始做起，最能最大限度的減少損失。建議我們從以下兩個方面做起：
-加強部門内員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的過程。在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隐性知識到顯性知識的轉化。
-通常情況下，企業能為員工提供足夠大的發展空間時，如果不是待遇特别低，員工都不會主動離開企業。是以我們要想留住員工，管理者就應該把員工的個人成長和企業的發展聯系起來，為員工設定合理發展規劃并付諸實作。不過這項要求做起來比較，要有比較好的企業文化為依托。
56、測試産品與測試項目的差別是什麼？
參考答案：
習慣上把開發完成後進行商業化、幾乎不進行代碼修改就可以售給使用者使用的軟體成為軟體産品，也就是可以買“賣拷貝”的軟體，例如Windows2000。而通常把針對一個或者幾個特定的使用者而開發的軟體成為軟體項目，軟體項目是一種個性化的産品，可以是按照使用者要求全部重新開發，也可以修改已有的軟體産品來滿足特定的使用者需求。項目和産品的不同特點，決定我們測試産品和測試項目仍然會有很多不同的地方：
-品質要求不同。通常産品的品質要高一些，修複釋出後産品的缺陷成本較高，甚至會帶來很多負面的影響。而做項目通常面向某一使用者，雖然品質越高越好，但是一般隻要滿足使用者要求就可以了。
-測試資源投入多少不同。做軟體産品通常是研發中心來開發，進度壓力要小些。同時由于品質要求高，是以會投入較多的人力、物力資源。
-項目最後要和使用者共同驗收測試，這是産品測試不具有的特點。
此外，測試産品與測試項目在缺陷管理方面、測試政策制定都會有很大不同，測試管理者應該結合具體的環境，恰如其分的完成工作。
57、和使用者共同測試（UAT測試）的注意點有哪些？
參考答案：
軟體産品在投産前，通常都會進行使用者驗收測試。如果使用者驗收測試沒有通過，直接結果就是那不到“Money”，間接影響是損害了公司的形象，而後者的影響往往更嚴重。根據作者的經驗，使用者驗收測試一定要讓使用者滿意。
實際上使用者現場測試更趨于是一種示範。在不欺騙使用者的前提下，我們向使用者展示我們軟體的優點，最後讓“上帝”滿意并欣然掏出“銀子”才是我們的目标。是以使用者測試要注意下面的事項：
（1）使用者現場測試不可能測試全部功能，是以要測試核心功能。這需要提前做好準備，這些核心功能一定要預先經過測試，證明沒有問題才可以和使用者共同進行測試。測試核心子產品的目的是建立使用者對軟體的信心。當然如果這些子產品如果問題較多，不應該進行示範。
（2）如果某些子產品确實有問題，我們可以示範其它重要的業務功能子產品，必要時要向使用者做成合理的解釋。争得時間後，及時修改缺陷來彌補。
（3）永遠不能欺騙使用者，蒙混過關。道理很簡單，因為軟體是要給使用者用的，問題早晚會暴露出來，除非你可以馬上修改。
和使用者進行測試還要注意各種交流技巧，争取不但短期利益得到了滿足，還要為後面得合作打好基礎。
58、如何編寫送出給使用者的測試報告？
參考答案：
随着測試工作越來越受重視，開發團隊向客戶提供測試文檔是不可避免的事情。很多人會問：“我們可以把工作中的測試報告提供給客戶嗎？”答案是否定的。因為提供内部測試報告，可能會讓客戶失去信心，甚至否定項目。
測試報告一般分為内部測試報告和外部測試報告。内部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況，這裡不過多讨論，讀者可以參考相關教材。這裡主要讨論一下外部測試報告的寫法，一般外部測試報告要滿足下面幾個要求：
-根據内部測試報告進行編寫，一般可以摘錄；
-不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；
-報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修複的；
-報告上面的内容盡量要真實可靠；
-整個測試報告要仔細審閱，力争不給項目帶來負面作用，尤其是性能測試報告。
總之，外部測試報告要小心謹慎的編寫。
59、測試工具在測試工作中是什麼地位？
參考答案：
國内的很多測試工程師對測試工具相當迷戀，尤其是一些新手，甚至期望測試工具可以取代手工測試。測試工具在測試工作中起的是輔助作用，一般用來提高測試效率。自動化測試彌補了手工測試的不足，減輕一定的工作量。實際上測試工具是無法替代大多數手工測試的，而一些諸如性能測試等自動化測試也是手工所不能完成的。
對于自動測試技術，應當依據軟體的不同情況來分别對待，一般自動技術會應用在引起大量重複性工作的地方、系統的壓力點、以及任何适合使用程式解決大批量輸入資料的地方。然後再尋找合适的自動測試工具，或者自己開發測試程式。一定不要為了使用測試工具而使用。
60、什麼是軟體測試，軟體測試的目的？
參考答案：IEEE軟體測試定義為：使用人工和自動手段來運作或測試某個 系統的過程，其目的在于檢驗它是否滿足規定的 需求或是弄清預期結果與實際結果之間的差異。
該定義明确提出了軟體測試以檢驗是否滿足需求為 目标。
軟體測試的目的在于發現錯誤；一個好的 測試用例在于發現從前未發現的錯誤；一個成功的測試是發現了從前未發現的錯誤的測試。是以更為合适的定義是：測試是為發現錯誤而執行程式的過程。
![職業規劃Android開發職業規劃[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)