1.測試結束標準是什麼？
2.描述軟件測試活動的生命週期？
3.軟件的缺陷等級應如何劃分？
4.當開發人員說不是BUG時,你如何應付？
5.您認爲做好測試測試用例工作的關鍵是什麼？
6.比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯繫。
7.需求測試注意事項有哪些？
8.簡述一下缺陷的生命週期
9.什麼是兼容性測試？兼容性測試側重哪些方面？
10.測試的策略有哪些？
11.我現在有個程序，發現在windows上運行得很慢，怎麼判別是程序存在問題還是軟硬件系統存在問題？
12.正交表測試用例設計方法的特點是什麼？
13.單元測試的策略有哪些？
14.你所熟悉的軟件測試類型都有哪些？請試着分別比較這些不同的測試類型的區別與聯繫（如功能測試、性能測試……）？
15.軟件的評審一般由哪些人蔘加？其目的是什麼？
16.你認爲做好測試計劃工作的關鍵是什麼？
17.軟件的安全性應從哪幾個方面去測試？
18.軟件配置管理工作開展的情況和認識？
19.你覺得軟件測試通過的標準應該是什麼樣的？
20.一套完整的測試應該由哪些階段組成？
21.單元測試的主要內容？
22.簡述集成測試與系統測試關係？
23.軟件系統中除用戶文檔之外，文檔測試還應該關注哪些文檔？
24.如何理解壓力、負載、性能測試測試？
25.什麼是系統瓶頸？
26.配置和兼容性測試的區別是什麼？
27.測試中的“殺蟲劑怪事”是指什麼？
28.在配置測試中，如何判斷髮現的缺陷是普通問題還是特定的配置問題？
29.軟件測試的風險主要體現在哪裏？
30.軟件測試人員就是QA嗎？
31.性能測試工作的目的是什麼？做好性能測試工作的關鍵是什麼？
31.性能測試工作的目的是什麼？做好性能測試工作的關鍵是什麼？
32.導致軟件缺陷的有原因哪些？
33.什麼是軟件測試？軟件測試的目的是什麼？
34.什麼是獨立測試？獨立測試的好處？
35.軟件測試的生命週期？
36.軟件測試活動流程。
37.軟件系統的用戶文檔包括哪些？
38.簡述軟件系統中用戶文檔的測試要點？
39.軟件測試的原則
1.測試結束標準是什麼？
答：用例全部測試。
覆蓋率達到標準。
缺陷率達到標準。
其他指標達到質量標準。
2.描述軟件測試活動的生命週期？
答：測試周期分爲計劃、設計、實現、執行、總結。其中：
計劃：對整個測試周期中所有活動進行規劃，估計工作量、風險，安排人力物力資源，安排進度等；
設計：完成測試方案，從技術層面上對測試進行規劃；
實現：進行測試用例和測試規程設計；
執行：根據前期完成的計劃、方案、用例、規程等文檔，執行測試用例。
總結：記錄測試結果，進行測試分析，完成測試報告。
3.軟件的缺陷等級應如何劃分？
答：A類-嚴重錯誤，包括：①由於程序所引起的死機,非法退出
②死循環
③數據庫發生死鎖
④因錯誤操作導致的程序中斷
⑤功能錯誤
⑥與數據庫連接錯誤
⑦數據通訊錯誤
B類-較嚴重錯誤，包括：①程序錯誤
②程序接口錯誤
③數據庫的表、業務規則、缺省值未加完整性等約束條件
C類-一般性錯誤，包括：①操作界面錯誤（包括數據窗口內列名定義、含義是否一致）
②打印內容、格式錯誤
③簡單的輸入限制未放在前臺進行控制
④刪除操作未給出提示
⑤數據庫表中有過多的空字段
D類-較小錯誤，包括：①界面不規範
②輔助說明描述不清楚
③輸入輸出不規範
④長操作未給用戶提示
⑤提示窗口文字未採用行業術語
⑥可輸入區域和只讀區域沒有明顯的區分標誌
4.當開發人員說不是BUG時,你如何應付？
答：開發人員說不是bug，有2種情況，一是需求沒有確定，所以我可以這麼做，這個時候可以找來產品經理進行確認，需不需要改動，3方商量確定好後再看要不要改。二是這種情況不可能發生，所以不需要修改，這個時候，我可以先儘可能的說出是BUG的依據是什麼？如果被用戶發現或出了問題，會有什麼不良結果？ 程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不 要修改就不改。其實有些真的不是bug，我也只是建議的方式寫進TD中，如果開發人員不修改也沒有大問題。如果確定是bug的話，一定要堅持自己的立場， 讓問題得到最後的確認。
5.您認爲做好測試測試用例工作的關鍵是什麼？
答：白盒測試用例設計的關鍵是以較少的用例覆蓋儘可能多的內部程序邏輯結果。
黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題。
6.比較一下黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯繫。
答：黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。
白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。
軟件的黑盒測試意味着測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序 的需求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是爲了發現以下幾類錯誤：
(1)是否有不正確或遺漏的功能？
(2)在接口上，輸入是否能正確的接受？能否輸出正確的結果？
(3)是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？
(4)性能上是否能夠滿足要求？
(5)是否有初始化或終止性錯誤？
軟件的白盒測試是對軟件的過程性細節做細緻的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計 或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱爲結構測試或邏輯驅動測 試。白盒測試主要是想對程序模塊進行如下檢查：
(1)對程序模塊的所有獨立的執行路徑至少測試一遍。
(2)對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。
(3)在循環的邊界和運行的界限內執行循環體。
(4)測試內部數據結構的有效性，等等。
單元測試（模塊測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行爲。
單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這麼說，程序員有責任編寫功能代碼，同時也就有責任爲自己的代碼編寫單元測試。執行單元測試，就是爲了證明這段代碼的行爲和我們期望的一致。
集成測試（也叫組裝測試，聯合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經測試過的單元組合成一個組件，並且測試它們之間的接口。從這 一層意義上講，組件是指多個單元的集成聚合。在現實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，並最終擴展進 程，將您的模塊與其他組的模塊一起測試。最後，將構成進程的所有模塊一起測試。
系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）
系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統滿足產品需求並且遵循系統設計。
驗收測試是部署軟件之前的最後一個測試操作。驗收測試的目的是確保軟件準備就緒，並且可以讓最終用戶將其用於執行軟件的既定功能和任務。
驗收測試是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試後，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。
7.需求測試注意事項有哪些？
答：一個良好的需求應當具有一下特點：
完整性：每一項需求都必須將所要實現的功能描述清楚，以使開發人員獲得設計和實現這些功能所需的所有必要信息。
正確性：每一項需求都必須準確地陳述其要開發的功能。
一致性：一致性是指與其它軟件需求或高層（系統，業務）需求不相矛盾。可行性：每一項需求都必須是在已知系統和環境的權能和限制範圍內可以實施的。
無二義性：對所有需求說明的讀者都只能有一個明確統一的解釋，由於自然語言極易導致二義性，所以儘量把每項需求用簡潔明瞭的用戶性的語言表達出來。
健壯性：需求的說明中是否對可能出現的異常進行了分析，並且對這些異常進行了容錯處理。
必要性：“必要性”可以理解爲每項需求都是用來授權你編寫文檔的“根源”。要使每項需求都能回溯至某項客戶的輸入，如 Use Case 或別的來源。
可測試性：每項需求都能通過設計測試用例或其它的驗證方法來進行測試。
可修改性：每項需求只應在 SRS 中出現一次。這樣更改時易於保持一致性。另外，使用目錄表、索引和相互參照列表方法將使軟件需求規格說明書更容易修改。
可跟蹤性：應能在每項軟件需求與它的根源和設計元素、源代碼、測試用例之間建立起鏈接鏈，這種可跟蹤性要求每項需求以一種結構化的，粒度好（fine-grained）的方式編寫並單獨標明，而不是大段大段的敘述。
8.簡述一下缺陷的生命週期
答：軟件缺陷的生命週期指的是一個軟件缺陷被發現、報告到這個缺陷被修復、驗證直至最後關閉的完整過程。簡單的軟件缺陷生命週期：
(1)發現——打開：測試人員找到軟件缺陷並將軟件缺陷提交給開發人員；
(2)打開——修復：開發人員再現、修復缺陷，然後提交測試人員去驗證；
(3)修復——關閉：測試人員驗證修復過的軟件，關閉已不存在的缺陷。
但是這是一種理想的狀態，在實際的工作中是很難有這樣的順利的，需要考慮的各種情況都還是非常多的。
複雜的軟件缺陷生命週期：
(1)新建一個軟件缺陷，這個軟件缺陷是（open）狀態，進行 bug 審查，不是代碼問題，就是設計需要修改；
(2)新建一個軟件缺陷，這個軟件缺陷是（open）狀態，進行 bug 審查，以後修改的，就可以延期；
(3)新建一個軟件缺陷，這個軟件缺陷是（open）狀態，進行 bug 審查，實際沒有這個 bug，可以將其關閉；
(4)新建一個軟件缺陷，這個軟件缺陷是（open）狀態，看是否清楚可重現，如果不能重現，就是缺少信息，需要返回到（open）狀態；如果能夠重現，就進行修正，修正後關閉，進行迴歸測試。
9.什麼是兼容性測試？兼容性測試側重哪些方面？
答：兼容測試主要是檢查軟件在不同的硬件平臺、軟件平臺上是否可以正常的運行，即是通常說的軟件的可移植性。
兼容的類型，如果細分的話，有平臺的兼容，網絡兼容，數據庫兼容，以及數據格式的兼容。
兼容測試的重點是，對兼容環境的分析。通常，是在運行軟件的環境不是很確定的情況下，才需要做兼容。根據軟件運行的需要，或者根據需求文檔，一般都能夠得出用戶會在什麼環境下使用該軟件，把這些環境整理成表單，就得出做兼容測試的兼容環境了。
兼容和配置測試的區別在於，做配置測試通常不是Clean OS下做測試，而兼容測試多是在Clean OS的環境下做的。
10.測試的策略有哪些？
答：黑盒/白盒，靜態/動態，手工/自動，冒煙測試，迴歸測試，公測（Beta測試的策略）
11.我現在有個程序，發現在windows上運行得很慢，怎麼判別是程序存在問題還是軟硬件系統存在問題？
答：(1)檢查系統是否有中毒的特徵；
(2)檢查軟件/硬件的配置是否符合軟件的推薦標準；
(3)確認當前的系統是否是獨立，即沒有對外提供什麼消耗CPU資源的服務；
(4)如果是C/S或者B/S結構的軟件，需要檢查是不是因爲與服務器的連接有問題，或者訪問有問題造成的；
(5)在系統沒有任何負載的情況下，查看性能監視器，確認應用程序對CPU/內存的訪問情況。
12.正交表測試用例設計方法的特點是什麼？
答：用最少的實驗覆蓋最多的操作，測試用例設計很少，效率高，但是很複雜；
對於基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能爲力的；
具體的環境下，正交表一般都很難做的。大多數，只在系統測試的時候使用此方法。
13.單元測試的策略有哪些？
答：邏輯覆蓋、循環覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數據流分析
14.你所熟悉的軟件測試類型都有哪些？請試着分別比較這些不同的測試類型的區別與聯繫（如功能測試、性能測試……）？
答：Compatibility Testing（兼容性測試），也稱“Configuration testing（配置測試）”，測試軟件是否和系統的其它與之交互的元素之間兼容，如：瀏覽器、操作系統、硬件等。驗證測試對象在不同的軟件和硬件配置中的運行情況。
Functional testing (功能測試)，也稱爲behavioral testing（行爲測試），根據產品特徵、操作描述和用戶方案，測試一個產品的特性和可操作行爲以確定它們滿足設計需求。本地化軟件的功能測試，用於驗證應用程序或網站對目標用戶能正確工作。使用適當的平臺、瀏覽器和測試腳本，以保證目標用戶的體驗將足夠好，就像應用程序是專門爲該市場開發的一樣。
Performance testing（性能測試），評價一個產品或組件與性能需求是否符合的測試。包括負載測試、強度測試、數據庫容量測試、基準測試等類型。
其它參考：
測試類型有：功能測試、性能測試、界面測試。
功能測試在測試工作中佔的比例最大，功能測試也叫黑盒測試。是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。
性能測試是通過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。
界面測試，界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設計良好的界面能夠引導用戶自己完成相應的操作，起到嚮導的作用。同時界面如同人的面孔，具有吸引用戶的直接優勢。設計合理的界面能給用戶帶來輕鬆愉悅的感受和成功的感覺，相反由於界面設計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。
區別在於，功能測試關注產品的所有功能上，要考慮到每個細節功能，每個可能存在的功能問題。性能測試主要關注於產品整體的多用戶併發下的穩定性和健壯性。界面測試更關注於用戶體驗上，用戶使用該產品的時候是否易用，是否易懂，是否規範（快捷鍵之類的），是否美觀（能否吸引用戶的注意力），是否安全（儘量在前臺避免用戶無意輸入無效的數據，當然考慮到體驗性，不能太粗魯的彈出警告）？做某個性能測試的時候，首先它可能是個功能點，首先要保證它的功能是沒問題的，然後再考慮該功能點的性能測試。
15.軟件的評審一般由哪些人蔘加？其目的是什麼？
答：在正式的會議上將軟件項目的成果（包括各階段的文檔、產生的代碼等）提交給用戶、客戶或有關部門人員對軟件產品進行評審和批准。其目的是找出可能影響軟件產品質量、開發過程、維護工作的適用性和環境方面的設計缺陷，並採取補救措施，以及找出在性能、安全性和經濟方面的可能的改進。
人員：用戶、客戶或有關部門開發人員，測試人員，需求分析師都可以，就看處於評審那個階段
16.你認爲做好測試計劃工作的關鍵是什麼？
答：軟件測試計劃就是在軟件測試工作正式實施之前明確測試的對象，並且通過對資源、時間、風險、測試範圍和預算等方面的綜合分析和規劃，保證有效的實施軟件測試；
做好測試計劃工作的關鍵 ：目的，管理，規範
(1)明確測試的目標，增強測試計劃的實用性
編寫軟件測試計劃得重要目的就是使測試過程能夠發現更多的軟件缺陷，因此軟件測試計劃的價值取決於它對幫助管理測試項目，並且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試範圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具並且具有較高的實用性，便於使用，生成的測試結果直觀、準確
(2)堅持“5W”規則，明確內容與過程
“5W”規則指的是“What（做什麼）”、“Why（爲什麼做）”、“When（何時做）”、“Where（在哪裏）”、“How（如何做）”。利用“5W”規則創建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的範圍和內容（What），確定測試的開始和結束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。
(3)採用評審和更新機制，保證測試計劃滿足實際需求
測試計劃寫作完成後，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試範圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。
(4)分別創建測試計劃與測試詳細規格、測試用例
應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用於指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
17.軟件的安全性應從哪幾個方面去測試？
答：(1)用戶認證機制：如數據證書、智能卡、雙重認證、安全電子交易協議
(2)加密機制
(3)安全防護策略：如安全日誌、***檢測、隔離防護、漏洞掃描
(4)數據備份與恢復手段：存儲設備、存儲優化、存儲保護、存儲管理
(5)防病毒系統
18.軟件配置管理工作開展的情況和認識？
答：軟件配置管理貫穿於軟件開發、測試活動的始終，覆蓋了開發、測試活動的各個環節，它的重要作用之一就是要全面的管理保存各個配置項，監控各配置項的狀態，並向項目經理及相關的人員報告，從而實現對軟件過程的控制。
軟件測試配置管理包括4個最基本的活動：
配置項標識
配置項控制
配置項狀態報告
配置審計
軟件配置管理通常藉助工具來輔助，主要有MS SourceSafe、Rational ClearCase等
19.你覺得軟件測試通過的標準應該是什麼樣的？
答：缺陷密度值達到客戶的要求
20.一套完整的測試應該由哪些階段組成？
答：測試計劃、測試設計與開發、測試實施、測試評審與測試結論
21.單元測試的主要內容？
答：模塊接口測試、局部數據結構測試、路徑測試、錯誤處理測試、邊界測試
22.簡述集成測試與系統測試關係？
答：（1）集成測試的主要依據概要設計說明書，系統測試的主要依據是需求設計說明書；
（2）集成測試是系統模塊的測試，系統測試是對整個系統的測試，包括相關的軟硬件平臺、網絡以及相關外設的測試。
23.軟件系統中除用戶文檔之外，文檔測試還應該關注哪些文檔？
答：⑴開發文檔
⑵軟件需求說明書
數據庫設計說明書、概要設計說明書、詳細設計說明書、可行性 研究報告
⑶管理文檔
項目開發計劃、測試計劃、測試報告、開發進度月報、開發總結報告
24.如何理解壓力、負載、性能測試測試？
答：性能測試是一個較大的範圍，實際上性能測試本身包含了性能、強度、壓力、負載等多方面的測試內容。
壓力測試是對服務器的穩定性以及負載能力等方面的測試，是一種很平常的測試。增大訪問系統的用戶數量、或者幾個用戶進行大數據量操作都是壓力測試。而負載測試是壓力相對較大的測試，主要是測試系統在一種或者集中極限條件下的相應能力，是性能測試的重要部分。100個用戶對系統進行連續半個小時的訪問可以看作壓力測試，那麼連續訪問8個小時就可以認爲負載測試，1000個用戶連續訪問系統1個小時也可以看作是負載測試。
實際上壓力測試和負載測試沒有明顯的區分。測試人員應該站在關注整體性能的高度上來對系統進行測試。
25.什麼是系統瓶頸？
答：瓶頸主要是指整個軟硬件構成的軟件系統某一方面或者幾個方面能力不能滿足用戶的特定業務要求，“特定”是指瓶頸會在某些條件下會出現，因爲畢竟大多數系統在投入前。
嚴格的從技術角度講，所有的系統都會有瓶頸，因爲大多數系統的資源配置不是協調的，例如CPU使用率剛好達到100％時，內存也正好耗盡的系統不是很多見。因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足用戶需求。在用戶極限使用系統的情況下，系統的響應仍然正常，我們可以認爲改系統沒有瓶頸或者瓶頸不會影響用戶工作。
因此我們測試系統瓶頸主要是實現下面兩個目的：
-發現“表面”的瓶頸。主要是模擬用戶的操作，找出用戶極限使用系統時的瓶頸，然後解決瓶頸，這是性能測試的基本目標。
-發現潛在的瓶頸並解決，保證系統的長期穩定性。主要是考慮用戶在將來擴展系統或者業務發生變化時，系統能夠適應變化。滿足用戶目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟件生命週期能夠不斷適應用戶的變化，或者通過簡單擴展系統就可以適應新的變化。
26.配置和兼容性測試的區別是什麼？
答：配置測試的目的是保證軟件在其相關的硬件上能夠正常運行，而兼容性測試主要是測試軟件能否與不同的軟件正確協作。
配置測試的核心內容就是使用各種硬件來測試軟件的運行情況，一般包括：
（1）軟件在不同的主機上的運行情況，例如Dell和Apple；
（2）軟件在不同的組件上的運行情況，例如開發的撥號程序要測試在不同廠商生產的Modem上的運行情況；
（3）不同的外設；
（4）不同的接口；
（5）不同的可選項，例如不同的內存大小；
兼容性測試的核心內容：
（1）測試軟件是否能在不同的操作系統平臺上兼容；
（2）測試軟件是否能在同一操作系統平臺的不同版本上兼容；
（3）軟件本身能否向前或者向後兼容；
（4）測試軟件能否與其它相關的軟件兼容；
（5）數據兼容性測試，主要是指數據能否共享；
配置和兼容性測試通稱對開發系統類軟件比較重要，例如驅動程序、操作系統、數據庫管理系統等。具體進行時仍然按照測試用例來執行。
27.測試中的“殺蟲劑怪事”是指什麼？
答：“殺蟲劑怪事”一詞由BorisBeizer在其編著的《軟件測試技術》第二版中提出。用於描述測試人員對同一測試對象進行的測試次數越多，發現的缺陷就會越來越少的現象。就像老用一種農藥，害蟲就會有免疫力，農藥發揮不了效力。這種現象的根本原因就是測試人員對測試軟件過於熟悉，形成思維定勢。
爲了克服這種現象，測試人員需要不斷編寫新的測試程序或者測試用例，對程序的不同部分進行測試，以發現更多的缺陷。也可以引用新人來測試軟件，剛剛進來的新手往往能發現一些意想不到的問題。
28.在配置測試中，如何判斷髮現的缺陷是普通問題還是特定的配置問題？
答：在進行配置測試時，測試工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷。因此判斷新發現的問題，需要在不同的配置中重新執行發現軟件缺陷的步驟，如果軟件缺陷不出現了，就可能是配置缺陷；如果在所有的配置中都出現，就可能是普通缺陷。
需要注意的是，配置問題可以在一大類配置中出現。例如，撥號程序可能在所有的外置Modem中都存在問題，而內置的Modem不會有任何問題。
29.軟件測試的風險主要體現在哪裏？
答：我們沒有對軟件進行完全測試，實際就是選擇了風險，因爲缺陷極有可能存在沒有進行測試的部分。舉個例子，程序員爲了方便，在調試程序時會彈出一些提示信息框，而這些提示只在某種條件下會彈出，碰巧程序發佈前這些代碼中的一些沒有被註釋掉。在測試時測試工程師又沒有對其進行測試。如果客戶碰到它，這將是代價昂貴的缺陷，因爲交付後才被客戶發現。
因此，我們要儘可能的選擇最合適的測試量，把風險降低到最小。
30.軟件測試人員就是QA嗎？
答：軟件測試人員和QA完全不是一回事兒。
QA(Quality Assurance),即質量保證,包括各行業，如製造業、工業、船舶業等，在業務各個領域都設有QA部門來監管項目/產品，注意，只是在流程上進行管理、控制。
SQA(Software Quality Assurance)，特指軟件行業上的質量保證，是對軟件開發測試過程中的各環節質量進行管理，看看符不符合公司的規程。其中不單有業務流程上的，也有產品/項目具體質量目標上的。
軟件測試是對軟件產品的質量本身進行測試，是從技術方面出發測試軟件。
SQA偏重於質量管理體系的建立和維護，客戶和認證機構質量體系審覈工作，質量培訓工作等。
爲了更形象地表述兩者區別，必須引入開發人員角色，形成三足鼎立之局面。
舉個例子：
假設軟件產品交付過程等同與學生考試的過程，那麼在這個過程中：
①開發人員是做考卷的學生。
②測試人員是改考卷的老師。
③QA（SQA）人員是輔導員。
軟件產品是開發人員做出來的，產品是否可以在市場使用，考試是否及格，決定性的因素還是在開發。
開發人員提交了結果，學生做完了試卷，是否及格？需要測試人員進行測試的分析與判斷。輔導員對具體課程不必具有特別多的專業知識，但是他會要求開發人員要先複習，然後做模擬題，最後才參加考試。他只監督你是否複習過，這就夠了。因爲他知道，不復習直接考試，基本上就是不及格的命。複習了，總比不復習好。而對於測試人員，他也許不懂如何做題-。-，但知道最終答案術（如執行用例者），只要有標準答案，就可以評定答案是否正確，滿足預期要求（軟件需求）。
所以說，軟件測試與開發一樣，是一個單純的技術活，只是個結果控制。
QA不涉及具體的技術，其實是個過程改進控制過程，是對整個過程的監督和改進，保證所有的標準和程序都被遵守，並且發現和處理相關問題。QA的工作涉及公司的全局，各個相關職能，覆蓋面比較寬廣，是保證生產過程受控或保證產品合格，着重於維護。
31.性能測試工作的目的是什麼？做好性能測試工作的關鍵是什麼？
答：性能測試工作的目的：在正常和大量使用的狀況下，驗證被測系統是否按預期要求運行。
達到這個目的，需要做可擴展性測試、負載測試、壓力測試等。
性能測試工作的關鍵：
①清晰的測試計劃
②文檔的測試環境(測試系統的實驗環境)
③有效的測試用例
④合理的場景分析
⑤準確的瓶頸定位
⑥測試人員對性能測試的理解程度、對測試工具的熟練程度
32.導致軟件缺陷的有原因哪些？
答：給軟件帶來錯誤的原因很多，具體地說，主要有如下幾點：
①交流不夠、交流上有誤解或者根本不進行交流
在應用應該做什麼或不應該做什麼的細節(應用的需求)不清晰的情況下進行開發。
②軟件複雜性
圖形用戶界面(gui)，客戶/服務器結構，分佈式應用，數據通信，超大型關係型數據庫以及龐大的系統規模，使得軟件及系統的複雜性呈指數增長，沒有現代軟件開發經驗的人很難理解它。
③程序設計錯誤
向所有的人一樣，程序員也會出錯。
④需求變化
需求變化的影響是多方面的，客戶可能不瞭解需求變化帶來的影響，也可能知道但又不得不那麼做。需求變化的後果可能是造成系統的重新設計，設計人員的日程的重新安排，已經完成的工作可能要重做或者完全拋棄，對其他項目產生影響，硬件需求可能要因此改變，等等。如果有許多小的改變或者一次大的變化，項目各部分之間已知或未知的依賴性可能會相互影響而導致更多問題的出現，需求改變帶來的複雜性可能導致錯誤，還可能影響工程參與者的積極性。
⑤時間壓力
軟件項目的日程表很難做到準確，很多時候需要預計和猜測。當最終期限迫近和關鍵時刻到來之際，錯誤也就跟着來了。
⑥自負
人更喜歡說:'沒問題','這事情很容易','幾個小時我就能拿出來'，太多不切實際的‘沒問題’，結果只能是引入錯誤。
⑦代碼文檔貧乏
貧乏或者差勁的文檔使得代碼維護和修改變的異常艱辛，其結果是帶來許多錯誤。事實上，在許多機構並不鼓勵其程序員爲代碼編寫文檔，也不鼓勵程序員將代碼寫得清晰和容易理解，相反他們認爲少寫文檔可以更快的進行編碼，無法理解的代碼更易於工作的保密(“寫得艱難必定讀的痛苦”)。
⑧軟件開發工具
可視化工具，類庫，編譯器，腳本工具，等等，它們常常會將自身的錯誤逮到應用軟件中。就象我們所知道的，沒有良好的工程化作爲基礎，使用面嚮對象的技術只會使項目變得更復雜。
33.什麼是軟件測試？軟件測試的目的是什麼？
答：軟件測試：在一定的受控制的條件下，圍繞一個系統或應用程序進行並評價操作結果的過程。控制條件應包括正常條件與異常條件。軟件測試企圖使事情變得很糟糕，從而發現該發生而沒發生，或者不該發生而發生了的事情。軟件測試是以“探測”爲主，在“探測”中發現軟件的毛病。軟件測試貫穿於軟件定義與開發的整個週期 ，軟件的需求規格說明書 ，結構設計及程序編碼，都屬於軟件測試的對象。
軟件測試的目的是爲了保證軟件產品的最終質量，在軟件開發的過程中，對軟件產品進行質量控制。一般來說軟件測試應由獨立的產品評測中心負責，嚴格按照軟件測試流程，制定測試計劃、測試方案、測試規範，實施測試，對測試記錄進行分析，並根據迴歸測試情況撰寫測試報告。測試是爲了證明程序有錯，而不能保證程序沒有錯誤。
①軟件測試是爲了發現錯誤而執行程序的過程；
②測試是爲了證明程序有錯，而不是證明程序無錯誤；
③一個好的測試用例是在於它能發現至今未發現的錯誤；
④一個成功的測試是發現了至今未發現的錯誤的測試。
這種觀點可以提醒人們測試要以查找錯誤爲中心，而不是爲了演示軟件的正確功能。但是僅憑字面意思理解這一觀點可能會產生誤導，認爲發現錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實並非如此。
首先，測試並不僅僅是爲了要找出錯誤。通過分析錯誤產生的原因和錯誤的分佈特徵，可以幫助項目管理者發現當前所採用的軟件過程的缺陷，以便改進。同時，這種分析也能幫助我們設計出有針對性地檢測方法，改善測試的有效性。
其次，沒有發現錯誤的測試也是有價值的，完整的測試是評定測試質量的一種方法。詳細而嚴謹的可靠性增長模型可以證明這一點。例如 bev littlewood發現一個經過測試而正常運行了n小時的系統有繼續正常運行n小時的概率。
34.什麼是獨立測試？獨立測試的好處？
答：獨立測試：軟件測試由在經濟上和管理上獨立於開發機構的組織進行。獨立測試可以避免軟件開發者測試自己開發的軟件，由於心理學上的問題，軟件開發者難以客觀、有效地測試自己的軟件，而找出那些因爲對問題的誤解而產生的錯誤就更加困難。獨立測試還可以避免軟件開發機構測試自己的軟件，軟件產品的開發過程受到時間、成本和質量三者的制約，時間和成本指標便於衡量，而質量卻很難度量，因此在軟件開發過程中，當時間、成本和質量三者發生矛盾時，質量最容易被忽視，如果測試組織與開發組織來自相同的機構，測試過程就會面臨來自與開發組織同一來源的管理方面的壓力，使測試過程受到干擾。
獨立測試的好處：
①客觀性
對軟件測試和軟件中的錯誤抱着客觀的態度，這種客觀的態度可以解決測試中的心理學問題，既能夠以揭露軟件中錯誤的態度工作，也能不受發現的錯誤的影響。經濟上的獨立性使其工作有更充分的條件按測試要求去完成。
②專業性
獨立測試作爲一種專業工作，在長期的工作過程中勢必能夠積累大量實踐經驗，形成自己的專業優勢。同時軟件測試也是技術含量很高的工作，需要有專業隊伍加以研究，並進行工程實踐。專業化分工是提高測試水平，保證測試質量，充分發揮測試效用的必然途徑。
③權威性
由於專業優勢，獨立測試工作形成的測試結果更具信服力，而測試結果常常和對軟件的質量評價聯繫在一起，由專業化的獨立測試機構的評價，更客觀、公正和具有權威性。
④資源有保證
獨立測試機構的主要任務是進行獨立測試工作，這使得測試工作在經費、人力和計劃方面更有保證，不會因爲開發的壓力減少對測試的投入，降低測試的有效性，可以避免開發單位側重軟件開發而對測試工作產生不利的影響。
35.軟件測試的生命週期？
答：計劃、分析、設計、構建、測試周期、最後測試和實施、實施後。
36.軟件測試活動流程。
答：指定測試計劃、設計測試、實施測試、執行單元測試、執行集成測試、執行系統測試、評估測試。
37.軟件系統的用戶文檔包括哪些？
答：軟件測試的文檔測試應當貫穿於軟件生命週期的全過程，其中用戶文檔是文檔測試的重點。
用戶手冊
安裝和設置指導
聯機幫助
指南、嚮導
樣例、示例和模板
授權/註冊登記表
最終用戶許可協議。
38.簡述軟件系統中用戶文檔的測試要點？
答：(1)讀者羣。文檔面向的讀者定位要明確，對於初級用戶、中級用戶以及高級用戶應該有不同的定位。
(2)術語。文檔中用到的術語要適用與定位的讀者羣，用法一直，標準定義與業界規範相吻合。
(3)正確性。測試中需檢查所有信息是否真實正確，查找由於過期產品說明書和銷售人員誇大事實而導致的錯誤。檢查所有的目錄、索引和章節引用是否已更新，嘗試鏈接是否準確，產品支持電話、地址和郵政編碼是否正確。
(4)完整性。對照軟件界面檢查是否有重要的分支沒有描述到，甚至是否有整個大模塊沒有描述到。
(5)一致性。對照文檔描述的操作執行後，檢查軟件返回的結果是否與文檔描述的相同。
(6)易用性。對關鍵步驟以粗體或背景色給用戶以提示，合理的頁面佈局、適量的圖表都可以給用戶更高的易用性。需要注意的是文檔要有助於用戶排除錯誤。不但描述正確操作，也要描述錯誤處理辦法。文檔對於用戶看到的錯誤信息應該有更詳細的文檔解釋。
(7)圖標與界面截圖。檢查所有圖表與界面截圖是否與發行版本相同。
(8)樣例與示例。像用戶一樣載入和使用樣例。如果是一段程序，就輸入數據並執行它。以每一個模塊製作文件，確認它們的正確性。
(9)語言。不出現錯別字，不要出現有二義性的說法。特別要注意的是屏幕截圖或繪製圖形中的文字。
(10)印刷與包裝。檢查印刷質量；手冊厚度與開本是否合適；包裝盒的大小是否合適；有沒有零碎易丟失的小部件等等。
39.軟件測試的原則
答：軟件測試從不同的角度出發會派生出兩種不同的測試原則，從用戶的角度出發，就是希望通過軟件測試能充分暴露軟件中存在的問題和缺陷，從而考慮是否可以接受該產品，從開發者的角度出發，就是希望測試能表明軟件產品不存在錯誤，已經正確地實現了用戶的需求，確立人們對軟件質量的信心。中國軟件評測中心的測試原則就是從用戶和開發者的角度出發進行軟件產品測試的，通過我們的測試，可以爲用戶提供放心的產品，並對優秀的產品進行認證。
爲了達到上述的原則，那麼需要注意以下幾點：
①應當把“儘早和不斷的測試”作爲開發者的座右銘
②程序員應該避免檢查自己的程序，測試工作應該由獨立的專業的軟件測試機構來完成。
③設計測試用例時應該考慮到合法的輸入和不合法的輸入以及各種邊界條件，特殊情況下要製造極端狀態和意外狀態，比如網絡異常中斷、電源斷電等情況。
④一定要注意測試中的錯誤集中發生現象，這和程序員的編程水平和習慣有很大的關係。
⑤對測試錯誤結果一定要有一個確認的過程，一般由A測試出來的錯誤，一定要由一個B來確認，嚴重的錯誤可以召開評審會進行討論和分析。
⑥制定嚴格的測試計劃，並把測試時間安排的儘量寬鬆，不要希望在極短的時間內完成一個高水平的測試。
⑦迴歸測試的關聯性一定要引起充分的注意，修改一個錯誤而引起更多的錯誤出現的現象並不少見。
⑧妥善保存一切測試過程文檔，意義是不言而喻的，測試的重現性往往要靠測試文檔。
在軟件測試中如何配置軟件環境配備測試環境是測試實施的一個重要階段，測試環境適合與否會嚴重影響測試結果的真實性和正確性。測試環境包括硬件環境和軟件環境，硬件環境指測試必需的服務器、客戶端、網絡連接設備以及打印機/掃描儀等輔助硬件設備所構成的環境 ；軟件環境指被測軟件運行時的操作系統、數據庫以及其他應用軟件構成的環境。在實際測試中，軟件環境又可分爲主測試環境和輔測試環境，主測試環境是測試軟件功能、安全可靠性、性能、易用性等大多數指標的主要環境，一般來說，配置主測試環境可遵循下列原則：
①符合軟件運行的最低要求。測試環境首先要保證能支撐軟件正常運行。
②選用比較普遍的操作系統和軟件平臺。例如，一個軟件若聲稱支持“Windows9X/ME/NT Workstation/2000 professional”和“MS OFFICE 97/2000/XP”，一般我們會採用如“Windows 2000professional+MS OFFICE 2000”的流行環境。
③營造相對簡單、獨立的測試環境。除了操作系統，測試機上只安裝軟件運行和測試必需的軟件，以免不相關的軟件影響測試實施。
④無毒的環境。利用有效的正版殺毒軟件檢測軟件環境，保證測試環境中沒有病毒。
輔測試環境常常用來滿足不同的測試需求或特殊測試項目：
兼容性測試：在滿足軟件運行要求的範圍內，可選擇一些典型的操作系統和常用應用軟件對其安裝卸載和主要功能進行驗證。
模擬真實環境測試：有些軟件，特別是面向大衆的商品化軟件，在測試時常常需要考察在真實環境中的表現。如測試殺毒軟件的掃描速度時，硬盤上佈置的不同類型文件的比例要儘量接近真實環境，這樣測試出來的數據纔有實際意義。
橫向對比測試：利用輔測試環境“克隆”出完全一致的測試環境，從而保證各個被測軟件平等對比。