測試的目的：盡可能多的發現缺陷，比如功能的錯誤，性能低下，易用性差。
測試的思路：先假設程序存在什么缺陷，然后執行程序來發現缺陷。
測試類型：白盒測試，黑盒測試。
白盒測試：看得見的程序內部結構，測試源程序的邏輯結構和實現細節。白盒測試必須由開發人員獨立執行，因為測試人員無法理解代碼內部邏輯。
黑盒測試：看不見的程序內部結構，按照規格來測試程序是否符合要求。黑盒測試必須由獨立測試小組執行，因為開發人員難以做到客觀公正。
主要發現以下問題：是否有不正確或遺漏了的功能；在接口上，能否正確的接收輸入，能否輸出正確的結果； ·是否有數據結構錯誤或外部信息訪問錯誤；性能上是否能夠滿足要求；是否有初始化或終止性錯誤； 黑盒測試需要在所有可能的輸入條件和輸出條件中確定測試數據，以檢查程序是否都能產生正確的輸出；有時測試數據量太大，是不現實的。
如：測試一個模塊時，白盒測試：要對所有代碼進行單步跟蹤測試，關注的是程序的內部細節。黑盒測試：只需測試模塊的接口是否要求，關注的是程序的外部實現。
α測試和β測試 ：在軟件交付使用之后，用戶將如何實際使用程序，對於開發者來說是不知道的。通常在軟件發布上市之前需要進行α測試和β測試。 α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試。α測試必須是開發人員和測試小組共同參與完成。
α測試：公司內部對軟件的測試。
α測試的目的是評價軟件產品的FLURPS（功能、局域化、可使用性、可靠性、性能和支持）。尤其注重產品的界面和特色。 α測試可以從軟件產品編碼結束之時開始，或者在模塊（子系統）測試完成之后開始，也可以在確認測試過程中產品達到一定的穩定和可靠程度之后再開始。
β測試：產品正式發布之前，公司外部邀請用戶進行測試。
α、β、λ常用來表示軟件測試過程中的三個階段，α是第一階段，一般只供內部測試使用；β是第二個階段，已經消除了軟件中大部分的不完善之處，但仍有可能還存在缺陷和漏洞，一般只提供給特定的用戶群來測試使用；λ是第三個階段，此時產品已經相當成熟，只需在個別地方再做進一步的優化處理即可上市發行。
封測 的意思就是 游戲制作 剛剛完成，需要在技術上對游戲進行測試，這個階段的測試是純技術的，和游戲的故事情節、人設一點都沒有關系，整個游戲基本處於雛形階段，所以除了有關技術人員以外，別人是接觸不到游戲的。
內測 在這三個階段的測試中，是時間最長的，少則幾周，多則數月，這個階段的測試至關重要，也是對游戲最全面的測試，所有的關於游戲的技術問題，以及關於游戲的故事、人設、風格、人物、服飾、語言、動作、主支線任務的合理性等等諸多方面進行測試和評估，乃至最后的修改。即使是內測，也是很少很少一部分人可以參與，大部分是游戲制作人員，運營代理商和與制作及運營游戲的商家，及一部分普通玩家。
到了 公測 階段，就會有相當一部分玩家參與進來，這個時候游戲已經基本定型，也就是處於正式推出的最后階段的測試。實際上就是聽取玩家的意見和反饋，以便為今后糾正錯誤做統計和准備，糾正錯誤的方式一般采取出補丁的方式。
測試內容：
1、功能測試：檢查軟件的功能是否符合要求。枚舉方法：構造合理的輸入，看是否有期望的輸出。邊界值方法：采用定義域的邊界值進行測試。
2、容錯性測試：檢查軟件在異常情況下的反應，容錯性好的軟件會確保系統不發生難以預料的崩潰。方法：構造一些不合理的數據看系統的反應（錯誤的數據類型或定義域外的值）。
3、性能與效率測試：測試軟件的速度與對資源的利用率。極限測試：持續不停地給服務器發送請求看是否會死掉，給程序輸入特別大的數據看是否能吃得消。獲取測試的絕對值（如數據的傳輸率）：記錄運行環境對軟件的影響。獲取測試的相對值（如該軟件和其他軟件相比快多少倍）：確保被測試的幾個軟件具有相同的軟件和硬件環境中。
4、易用性測試：用戶不用看用戶手冊，即具有好的易用性。
5、文檔測試：檢查文檔的正確性，完備性，可理解性。
上述內容參考該篇內容
測試手機：
1、電話。
是否可以正常接受電話。
是否可以刪除通話記錄。
是否可以拉黑。
輸入錯誤位數號碼是否有提示。
2、短信。
是否可以正常接收短信。
是否可以刪除短信記錄。
是否可以拉黑。
接收短信是否有提示，發送短信是否有成功提示。
發送內容為空時是否有提示。
輸入錯誤位數號碼是否有提示。
3、聯系人。
是否有電話本功能。
是否可以新建刪除更新聯系人信息。
是否可以將聯系人設成常用聯系人或黑名單。
聯系人輸入信息為空是否有提示。
刪除聯系人是否有提示。
更新時是否有提示確認更新。
測試題：
1、在游戲或軟件開發完成的初期，由游戲公司或軟件公司發送限定的激活碼或賬號給玩家，由玩家測試並向游戲公司反饋使用情況和存在的問題，以促進游戲的進一步完善的環節稱為內側。
2、單元測試能發現約80%的軟件缺陷。
3、JUnit主要用來完成什么：單元測試。JUnit是一個Java語言的單元測試框架。Junit測試是程序員測試，即所謂白盒測試。
4、測試驅動開發，英文全稱Test-Driven Development，簡稱TDD，是一種不同於傳統軟件開發流程的新型的開發方法。它要求在編寫某個功能的代碼之前先編寫測試代碼，然后只編寫使測試通過的功能代碼，通過測試來推動整個開發的進行。這有助於編寫簡潔可用和高質量的代碼，並加速開發過程。測試驅動開發可以和結對編程結合使用。
測試驅動開發適合使用CMM/CMMI方法？CMM/CMMI方法這兩種方法屬於測試驅動開發的方式。
CMM是指“能力成熟度模型”，它是對於軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發展階段的描述。CMM的核心是把軟件開發視為一個過程，並根據這一原則對軟件開發和維護進行過程監控和研究，以使其更加科學化、標准化、使企業能夠更好地實現商業目標。
CMMI能力成熟度模型集成將各種能力成熟度模型，整合到同一架構中去，由此建立起包括軟件工程、系統工程和軟件采購等在內的諸模型的集成，以解決除軟件開發以外的軟件系統工程和軟件采購工作中的迫切需求。
5、下圖用基本路徑法測試需要覆蓋幾條路徑？
6、樁函數，也叫stub函數，存根函數。用一個樁函數替換一些接口函數，用於測試當前函數的特性。
在單元測試中被其它模塊調用，
在自頂向下的集成過程中尤其有效
譬如說,要測試一個函數 f()
void f()
{
var = g(...);
}
f()函數中調用了函數 g(),但是在測試f()的時候g()函數可能還沒有寫出來 。
這時可以寫一個g()的 存根(stub)函數,來模擬g()函數,例如讓它僅僅返回一個值.這樣的話就可以完成對函數f()的測試了.
7、軟件測試計划評審會需要哪些人員參加。
軟件測試計划評審會需要有 項目經理、客戶(可選)、配置管理員、測試經理、開發組長，SQA 負責人等人的參加。
SQA-Software Quality Assurance）
8、黑盒測試方法 、白盒測試方法：
白盒測試的測試方法有代碼檢查法、靜態結構分析法、靜態質量度量法、邏輯覆蓋法、基本路徑測試法、域測試、符號測試、路徑覆蓋和程序變異
具體的黑盒測試用例設計方法包括等價類划分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法、場景法等。
白盒測試法的覆蓋標准有 邏輯覆蓋 、循環覆蓋和基本 路徑測試 。其中邏輯覆蓋包括 語句覆蓋 、 判定覆蓋 、 條件覆蓋 、判定/條件覆蓋、 條件組合覆蓋 和 路徑覆蓋 。邊界值法既可以用於黑盒測試用例，也可以用於白盒測試用例。邊界值分析的基本思想是使用在最小值、略高於最小值、正常值、略低於最大值和最大值處取輸入變量值，記為：min、min+、nom、max-、max考慮到健壯性測試，還可以加一個略大於最大值max+，以及一個略小於最小值min-的值。
用邊界值分析法，假定1<X<10，那么X在測試中應該取的邊界值是X=1，X=2，X=9，X=10
白盒測試分為：
1.語句覆蓋：可執行語句至少被執行一次；
2.判斷覆蓋：每個判斷的取真分支和取假分支至少經歷一次；
3.條件覆蓋：每個條件的取值至少滿足一次；
4.判斷條件覆蓋：判斷和條件都滿足；
5.條件組合覆蓋：每個條件的所有可能都至少出現一次，並且判定結果至少出現一次 ；
他與條件覆蓋的區別：他不是簡單要求每個條件出現“真”和“假”兩種結果，而是要求這些結果所有可能至少出現一次；
6.路徑測試：執行所有可能的執行路徑；
7.基本路徑測試：路徑測試執行了每個路徑，每個判定的結果肯定經歷過一次
判定覆蓋是每個判定的真假一次，就會導致所有的結果路徑會實現；
條件覆蓋是每個判定里的條件各取一次，不一定會產生所有的結果；
9、測試方法可以分成哪幾種?
軟件測試可以是人工測試：如個人復查，抽查和會審等
也可以是機器自動測試，又有不同的分類：
按照否關軟件內部結構具體實現角度划
A.白盒測試B.黑盒測試 C.灰盒測試
按照軟件發程按階段划
A.單元測試 B.集測試 C.確認測試 D.系統測試 E.驗收測試
灰盒測試，是介於白盒測試與黑盒測試之間的一種測試，灰盒測試多用於集成測試階段，不僅關注輸出、輸入的正確性，同時也關注程序內部的情況。灰盒測試不像白盒那樣詳細、完整，但又比黑盒測試更關注程序的內部邏輯，常常是通過一些表征性的現象、事件、標志來判斷內部的運行狀態
10、代碼評審員一般由測試員擔任？錯！一般都是開發人員評審
11、測試的關鍵問題是： 如何選擇測試用例
12、系統測試將軟件，硬件，網絡等其他因素結合，對整個軟件進行測試.白盒測試等不是系統測試的內容。
13、V模型大體可以划分為以下幾個不同的階段步驟：需求分析、概要設計、詳細設計、軟件編碼、單元測試、集成測試、系統測試、驗收測試。
需求分析 驗收測試
概要設計 系統測試
詳細設計 集成測試
編碼 單元測試
V
集成測試計划在需求分析階段 末（mo） 提交
14、負載測試是驗證要檢驗的系統的能力最高能達到什么程度
15、測試人員要堅持原則，缺陷未修復完堅決不予通過。請判斷這句話的正確與否。錯！！！！！！！！！！！！
缺陷分兩種：
1、完全影響軟件的正常運行或者影響客戶的正常體驗。
這種當然不能予以通過
2、不影響產品運行及客戶正常體驗且此軟件急於使用。
以公司利益為出發，應予以通過。但在時間不緊急的情況下應不予通過。
一個好的測試人員應該有很好的情況分析能力，並且要有擔當
16、 軟件測試的目的是為了發現錯誤而執行程序的過程，並不涉及改正錯誤。
程序調試的基本步驟有：錯誤定位、修改設計和代碼，以排除錯誤、進行回歸測試，防止引進新的錯誤。程序調試通常稱為Debug，即排錯。
軟件測試的基本准則有：所有測試都應追溯到需求、嚴格執行測試計划，排除測試的隨意性、充分注意測試中的群集現象、程序員應避免檢查
自己的程序、窮舉測試不可能、妥善保存測試計划等文件。
17、
條件覆蓋CC（Condition Coverage），設計足夠多的測試用例，運行被測程序，使得每一判定語句中每個邏輯條件的可能取值至少滿足一次。
條件覆蓋率的公式：條件覆蓋率=被評價到的條件取值的數量/條件取值的總數X100%[1]
條件覆蓋的缺點：只考慮到每個判定語句中的每個表達式，沒有考慮到各個條件分支（或者涉及不到全部分支），即不能夠滿足判定覆蓋.
條件組合覆蓋，也稱多條件覆蓋MCC （Multiple Condition Coverage），設計足夠多的測試用例，使得每個判定中條件的各種可能組合都
至少出現一次（以數軸形式划分區域，提取交集，建立最少的測試用例）。這種方法包含了“分支覆蓋”和“條件覆蓋”的各種要求。滿足條件組合
覆蓋一定滿足判定覆蓋、條件覆蓋、判定條件覆蓋。條件組合覆蓋率的公式：條件組合覆蓋率=被評價到的條件取值組合的數量/條件取值組合的
總數條件組合覆蓋的缺點：判定語句較多時，條件組合值比較多。
語句覆蓋 SC（Statement Coverage），就是設計若干個測試用例，運行被測程序，使得程序中每一可執行語句至少執行一次。這里的“若干個”
，意味着使用測試用例越少越好。語句覆蓋在測試中主要發現缺陷或錯誤語句。
判定條件覆蓋CDC（Condition/ Decision Coverage），設計足夠多的測試用例，使得判定中的每個條件的所有可能（真/假）至少出現一次，
並且每個判定本身的判定結果也至少出現一次。[1] 判定條件覆蓋率的公式：條件判定覆蓋率=被評價到的條件取值和判定分支的數量/（條件取值
總數+判定分支總數）.判定條件覆蓋的缺點：沒有考慮單個判定對整體結果的影響，無法發現邏輯錯誤。
18、
軟件驗收測試分為三類：
正式驗收測試；
非正式驗收測試。其中包括α測試（由用戶、測試人員、開發人員共同參與的內部測試。）
和β測試（內測后的公測，即完全交給最終用戶測試。）
19、
LoadRunner，是一種預測系統行為和性能的負載測試工具。通過以模擬上千萬用戶實施並發負載及實時性能監測的方式來確認和查找問題，
可適用於各種體系架構的自動負載測試，能預測系統行為並評估系統性能。
其測試組件有
1.VuGen Load Generator（虛擬用戶生成器）用於捕獲最終用戶業務流程和創建自動性能測試腳本 （也稱為虛擬用戶腳本）。
2.Controller （控制器）用於組織、驅動、管理和監控負載測試。
3.Analysis （分析器）有助於您查看、分析和比較性能結果。
包括A腳本編輯工具 C測試執行工具 D結果分析工具
20、 系統集成測試主要包括以下過程：1. 構建的確認過程。 2. 補丁的確認過程。 3. 系統集成測試測試組提交過程。
4. 測試用例設計過程。 5. 測試代碼編寫過程。 6. Bug的報告過程。 7. 每周/每兩周的構建過程。 8. 點對點的測試過程。
9. 組內培訓過程。
21、
系統測試的16個測試策略：
功能測試、性能測試、壓力測試、容量測試、安全性測試、GUI測試、可用性測試、安裝測試、配置測試、異常測試,備份測試、健壯性測試、
文檔測試、在線幫助測試、網絡測試、穩定性測試。
22、α測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試，
α測試不能由程序員或測試員完成。α測試發現的錯誤，可以在測試現場立刻反饋給開發人員，由開發人員及時分析和處理。
目的是評價軟件產品的功能、可使用性、可靠性、性能和支持。
尤其注重產品的界面和特色。Alpha測試可以從軟件產品編碼結束之后開始，或在模塊（子系統）測試完成后開始，
也可以在確認測試過程中產品達到一定的穩定和可靠程度之后再開始。
alpha 測試需要用戶參加
alpha 測試是驗收測試的一種
23、 軟件測試用例包括 輸入數據和預期輸出結果
24、項目立項前測試人員不需要提交任何工件。工件是加工過程中的生產對象。項目立項前，測試人員是不需要提供任何工件的。
25、自底向上集成需要測試員編寫驅動程序。自底向上測試是從“原子”模塊（即軟件結構最低層的模塊）開始組裝測試，因測試到較高層模塊時，所需的下層模塊功能均已具備，所以不再需要樁模塊。
自底向上集成方法不用樁模塊，測試用例的設計亦相對簡單，但缺點是程序最后一個模塊加入時才具有整體形象，需要開發驅動模塊。
26、
針對手機應用軟件的系統測試，我們通常從如下幾個角度開展：功能模塊測試，交叉事件測試，壓力測試，容量測試，兼容性測試，易用性/用戶體驗測試等.
對手機可以施加的壓力測試類型主要有：存儲壓力、邊界壓力、 響應能力壓力、網絡流量壓力， 無並發壓力
並發壓力是針對服務器的，因為每次並發是一個客戶端
27、測試設計員的職責有： 設計測試用例， 設計測試過程、腳本。
測試設計人員主要負責設計測試用例以及設計測試過程。 制定測試計划是測試經理來做的；評估測試活動是測試經理組織開發人員來進行的。
28、LoadRunner-負載壓力測試：預測系統性能。
JMeter+Badboy：基於JAVA的壓力測試工具，Badboy用來進行腳本的錄制
功能測試：通過自動錄制、檢測和回放用戶的應用操作。將輸出記錄同預先給定的記錄比較。
Junit：白盒測試工具：針對代碼測試
測試管理工具：對測試需求、計划、用例、實施進行管理
測試輔助工具：本身不執行，可以生成測試數據，為測試提供數據准備
負載壓力測試：LoadRunner:預測系統行為和性能的工業標准級負載測試工具。模擬上千萬用戶同時實施並發操作，來實時監控可能發生的問題。
功能測試： QTP(quicktest professional):自動測試工具
白盒測試：C++ TEST（做C和C++的白盒測試）、JUnit（Java白盒測試）
缺陷管理工具：Mantis、BugFree、QC、TD
用例管理工具：TestLink、QC
測試輔助工具：SVN
28、【軟件需求】是軟件開發之前做好的，軟件開發是根據這個做的，那么軟件測試自然也需要參考該文件 【迭代計划】是軟件的某個周期的計划，自然也需要參考 【可行性】是軟件開發前做好，用於證明該計划可行的，沒有必要參考。可行性研究報告，在軟件開發前做好了，在開發前項目經理已召開進行評估，通過后才開始開發此軟件，所以在測試過程中，不再需要參考次報告
參考鏈接：https://blog.csdn.net/melody_day/article/details/60472607