一個測試活動完整的過程
項目立項前測試人員不需要提供任何工件
項目經理 通過和客戶交流，完成 需求文檔，由開發人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現的功能的地方。
項目經理通過綜合開發人員、測試人員以及客戶的意見，完成 項目計劃。然后SQA進入項目，開始進行統計和跟蹤
開發人員 根據需求文檔完成 需求分析文檔，測試人員進行評審，評審的內容包括是否有遺漏或者雙方理解不同的地方。測試人員 完成 測試計劃文檔。
測試人員 根據修改好的需求分析文檔開始寫 測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔作為測試人員撰寫測試用例的補充材料。
測試用例完成后，測試和開發需要進行評審
測試人員搭建測試環境
開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現bug后提交給
開發提交第二個版本，包括 Bug Fix 以及增加了部分功能，測試人員進行測試。
重復上面的工作，一般是 3-4 個版本后 BUG 數量減少，達到出貨的要求。
如果有客戶反饋的問題，需要測試人員協助重現并重新測試。
測試計劃工作的目的、測試計劃文檔的內容包括什么？
目的：指導測試過程的綱領性文件
內容：產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流風險分析等內容。
測試用例通常包括那些內容？
不同結構的用例包括的不一樣。（版本、編號、項目、設計人員、設計日期、輸入、預期輸出??）
軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操作步驟、預期結果。
用例編號： 測試用例的編號有一定的規則，比如系統測試用例的編號這樣定義規則：
-ST-001 ，命名規則是項目名稱＋測試階段類型（系統測試階段）＋編號。定義測試用例編號，便于查找測試用例，便于測試用例的跟蹤。
測試標題： 對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。比如 “ 測試用戶登錄時輸入錯誤密碼時，軟件的響應情況 ” 。
重要級別： 定義測試用例的優先級別，可以籠統的分為 “ 高 ” 和 “ 低 ” 兩個級別。一般來說，如果軟件需求的優先級為 “ 高 ” ，那么針對該需求的測試用例優先級也為“ 高 ” ；反之亦然，一般而言，是 5 級劃分。
測試輸入： 提供測試執行中的各種輸入條件。根據需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那么測試用例設計中會遇到很大的障礙。
操作步驟： 提供測試執行過程的步驟。對于復雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內容在操作步驟中詳細列出。
預期結果： 提供測試執行的預期結果，預期結果應該根據軟件需求中的輸出得出。如果在
測試人員在軟件開發過程中的任務是什么？
尋找bug；
避免軟件開發過程中的缺陷；
衡量軟件的品質；
關注用戶的需求。
總的目標是：確保軟件的質量。
軟件測試分為幾個階段，各階段的測試策略和要求是什么？
按階段分為：單元測試、集成測試、系統測試、驗收測試
單元測試
單元測試能發現80%的軟件缺陷。
針對軟件設計的最小單位——程序模塊甚至是代碼段進行正確性檢驗的測試工作，通常由開發人員進行。通常情況下是白盒的，對代碼風格和規則、程序設計和結構、業務邏輯等進行靜態測試，及早的發現和解決不易顯現的錯誤。
單元測試測試策略：邏輯覆蓋、循環覆蓋、同行評審、桌前檢查、代碼走查、代碼評審、景泰數據流分析
自頂向下的單元測試
方法
先對最頂層的基本單元進行測試，把所有調用的單元做成樁模塊。然后再對第二層的基本單元進行測試，使用上面已測試的單元做驅動模塊。依此類推直到測試完所有基本單元。
優點
在集成測試前提供早期的集成途徑。在執行上和詳細設計的順序一致。不需要開發驅動模塊。
缺點
隨著測試的進行，測試過程越來越復雜，開發和維護成本增加。
總結
比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。
自底向上的單元測試
方法
先對最底層的基本單元進行測試，模擬調用該單元的單元做驅動模塊。然后再對上面一層進行測試，用下面已被測試過的單元做樁模塊。依此類推，直到測試完所有單元。
優點
在集成測試前提供系統早期的集成途徑。不需要開發樁模塊。
缺點
隨著測試的進行，測試過程越來越復雜。
總結
比較合理的單元測試策略，但測試周期較長。
孤立單元測試
方法
不考慮每個單元與其它單元之間的關系，為每個單元設計樁模塊或驅動模塊。每個模塊進行獨立的單元測試。
優點
簡單、容易操作，可達到高的結構覆蓋率。
缺點
不提供一種系統早期的集成途徑。
總結
最好的單元測試策略。
集成測試
將模塊按照設計要求組裝起來進行測試，主要目的是發現與接口有關的問題。由于在產品提交到測試部門前，產品開發小組都要進行聯合調試，因此在大部分企業中集成測試是由開發人員來完成的。
集成測試測試策略
大爆炸集成：適用于一個維護項目或被測試系統較小
自頂向下集成：適應于產品控制結構比較清晰和穩定；高層接口變化較小，底層接口未定義或經常可能被修改；產品控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統功能行為。
自頂向下測試：是從程序的初始模塊開始測試。
（1）該方法會在早期發現頂層的錯誤。
（2）早期的程序框架可以進行演示
（3）需要開發樁模塊輔助測試。有些甚至需要多個樁模塊輔助，加大了樁模塊本來的錯誤影響。
（4）測試完一個上層模塊后，挑選哪個模塊作為下一個測試模塊，以及測試的順序沒有唯一的界定標準。
優點：較早地驗證了主要控制和判斷點；按深度優先可以首先實現和驗證一個完整的軟件功能；功能較早證實，帶來信心；只需一個驅動，減少驅動器開發的費用；支持故障隔離。
缺點：柱的開發量大；底層驗證被推遲；底層組件測試不充分。
注意;自底向上才需要驅動開發模塊。
自底向上集成：是從程序的底層模塊開始測試。
（1）I/O操作可以提前測試，更好提交測試用例。
（2）測試后比較容易觀察輸出。
（3）需要開發驅動模塊。
（4）直到最后一個模塊提交，程序才能完整的系統測試。
優點：對底層組件行為較早驗證；工作最初可以并行集成，比自頂向下效率高；減少了樁的工作量；支持故障隔離。
缺點：驅動的開發工作量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。
4. 基于進度的集成：優點具有較高的并行度，能夠有效縮短項目的開發進度。缺點：樁和驅動工作量較大，有些接口測試不充分，有些測試重復和浪費。
系統測試
在集成測試通過后進行的，目的是充分運行系統，驗證各子系統是否都能正常工作并完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。是基于系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。
系統測試的測試策略
數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試。
回歸測試
回歸測試是指在發生修改之后重新測試先前的測試用例以保證修改的正確性。理論上，軟件產生新版本，都需要進行回歸測試，驗證以前發現和修復的錯誤是否在新軟件版本上再次出現。根據修復好了的缺陷再重新進行測試。回歸測試的目的在于驗證以前出現過但已經修復好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測試。
驗收測試
驗收測試是指系統開發生命周期方法論的一個階段，這時相關的用戶或獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統用戶決定是否接收系統。它是一項確定產品是否能夠滿足合同或用戶所規定需求的測試。驗收測試包括Alpha測試和Beta測試。
Alpha測試：是由用戶在開發者的場所來進行的，在一個受控的環境中進行。
Beta測試：由軟件的最終用戶在一個或多個用戶場所來進行的，開發者通常不在現場，用戶記錄測試中遇到的問題并報告給開發者，開發者對系統進行最后的修改，并開始準備發布最終的軟件。
請回答集成測試和系統測試的區別，以及它們的應用場景主要是什么？
區別：
1、計劃和用例編制的先后順序：從V模型來講，在需求階段就要制定系統測試計劃和用例，HLD的時候做集成測試計劃和用例，有些公司的具體實踐不一樣，但是順序肯定是先做系統測試計劃用例，再做集成。
2、用例的粒度：系統測試用例相對很接近用戶接受測試用例，集成測試用例比系統測試用例更詳細，而且對于接口部分要重點寫，畢竟要集成各個模塊或者子系統。
3、執行測試的順序：先執行集成測試，待集成測試出的問題修復之后，再做系統測試。
應用場景：
集成測試：完成單元測試后，各模塊聯調測試；集中在各模塊的接口是否一致、各模塊間的數據流和控制流是否按照設計實現其功能、以及結果的正確性驗證等等；可以是整個產品的集成測試，也可以是大模塊的集成測試；集成測試主要是針對程序內部結構進行測試，特別是對程序之間的接口進行測試。集成測試對測試人員的編寫腳本能力要求比較高。測試方法一般選用黑盒測試和白盒測試相結合。
系統測試：針對整個產品的全面測試，既包含各模塊的驗證性測試（驗證前兩個階段測試的正確性）和功能性（產品提交個用戶的功能）測試，又包括對整個產品的健壯性、安全性、可維護性及各種性能參數的測試。系統測試測試軟件《需求規格說明書》中提到的功能是否有遺漏，是否正確的實現。做系統測試要嚴格按照《需求規格說明書》，以它為標準。測試方法一般都使用黑盒測試法。
你在測試中發現了一個bug，但是開發經理認為這不是一個bug，你應該怎么解決？
將問題提交到缺陷管理庫里邊進行備案；
獲取判斷的依據和標準：根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；如果沒有文檔依據，可以根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；
合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不摻雜個人情緒。
等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，并有上級做出決定。
請問你覺得測試項目具體工作是什么？
搭建測試環境
撰寫測試用例
執行測試用例
寫測試計劃，測試報告
測試，并提交BUG表單
跟蹤bug修改情況
執行自動化測試，編寫腳本，執行，分析，報告
進行性能測試，壓力測試等其他測試，執行，分析，調優，報告
常用的軟件測試方法有兩大類：靜態測試方法和動態測試方法
靜態測試
不要求在計算機上實際執行所測程序，主要以一些人工的模擬技術對軟件進行分析和測試。
動態測試
通過輸入一組預先按照一定的測試準則構造的實例數據來動態運行程序，而達到發現程序錯誤的過程。在動態分析技術中,最主要的測試有白盒和黑盒。
黑盒測試
也叫功能測試或數據驅動測試，已知產品應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看做一個不能打開的黑盒子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序接口進行測試，只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息，并且保持外部信息（如數據庫或文件）的完整性。
“黑盒”法著眼于程序外部結構、不考慮內部邏輯結構、針對軟件界面和軟件功能進行測試。“黑盒”法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，因此不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
常用的黑盒測試方法有：等價類劃分法；邊界值分析法；因果圖法；場景法；正交實驗設計法；判定表驅動分析法；錯誤推測法；功能圖分析法。
邊界值分析法
某購物中心電梯限坐15人。在電梯中安裝計數器來統計乘客數量。如出現超出規定人數以外的任何情況，會有不同的警示音。軟件編寫后進行邊界值測試，應選取的邊界值是：（ ）
0,1,15,16
因果圖法
等價類劃分法和邊界值分析法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合，輸入條件之間的相互制約關系，這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。
如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮采用一種適合于描述多種條件的組合，相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）。
因果圖法要需要注意考慮：
所有輸入/輸出條件的相互制約關系以及組合關系
輸入條件的依賴關系，也就是什么樣的輸入組合會產生什么樣的輸出結果，即“因果關系”
因果圖中的基本符號
通常在因果圖中用Ci表示原因，用Ei表示結果，各結點表示狀態，可取值‘0’或‘1’。‘0’表示某狀態不出現‘1‘表示某狀態出現。
案例：交通一卡通自動充值軟件系統需求
系統只接收50或100元紙幣白盒測試又稱邏輯，一次只能使用一張紙幣，一次蟲子金額只能為50元或100元；
若輸入50元紙幣，并選擇充值50元，完成充值后退卡，提示充值成功；
若輸入50元紙幣，并選擇充值100元，提示輸入金額不足，并退回50元；
若輸入100元紙幣，并選擇充值50元，完成充值后退卡，提示充值成功，找零50元；
若輸入100元紙幣，并選擇充值100元，完成充值后退卡，提示充值成功；
若輸入紙幣后在規定時間內不選擇充值按鈕，退回輸入的紙幣，并提示錯誤；
若選擇充值按鈕后不輸入紙幣，提示錯誤
找到所有輸入條件編號
找到所有輸出條件編號
找出所有輸入，輸出的制約關系
判定表法
也叫決策表，能表示輸入條件的組合，以及與每一輸入組合對應的動作組合，與因果圖法相似，但更側重輸入條件之間的邏輯關系。
包括5個部分：
條件樁：列出所有可能的條件
條件項：列出所有的條件取值組合
動作樁：列出所有可能的操作
條件項：列出在每一種條件取值組合的情況下，執行動作樁中的哪些動作。
規則：一種條件取值組合與其對應的動作組合（即判定表中貫穿條件項和動作項的一列）構成判定表的一個規則。條件組合的數目就是規則的數目。
白盒測試
白盒測試也稱為結構測試或邏輯驅動測試，是針對被測單元內部是如何進行工作的測試。它根據程序的控制結構設計測試用例，主要用于軟件或程序驗證。白盒測試法檢查程序內部邏輯結構白盒測試又稱邏輯，對所有的邏輯路徑進行測試，是一種窮舉路徑的測試方法，但即使每條路徑都測試過了，但仍然有可能存在錯誤。因為：窮舉路徑測試無法檢查出程序本身是否違反了設計規范，即程序是否是一個錯誤的程序；窮舉路徑測試不可能檢查出程序因為遺漏路徑而出錯；窮舉路徑測試發現不了一些與數據相關的錯誤。
白盒測試包括：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋,其中最強的邏輯覆蓋法是（條件組合覆蓋）
語句覆蓋
“語句覆蓋”是一個比較弱的測試標準，它的含義是：在測試時，首先設計若干個測試用例，然后運行被測程序， 使程序中的每個可執行語句至少執行一次。這時所謂“若干個”，自然是越少越好。
語句覆蓋在測試被測程序中，除去對檢查不可執行語句有一定作用外，并沒有排除被測程序包含錯誤的風險。
判定覆蓋
比“語句覆蓋”稍強的覆蓋標準是“判定覆蓋”(或稱 分支覆蓋)標準。判定覆蓋準則進行測試是指，設計若干測試用例，運行被側程序，使得程序中每個判斷的取真分支和取假分支至少經歷一次，即判斷的真假值均曾被滿足。判定覆 蓋又稱為分支覆蓋。
條件覆蓋
程序中每個判斷中每個條件的可能值至少得到一次。條件覆蓋并不能保證判定覆蓋，條件覆蓋只能保證每個條件至少有一次為真，而不是考慮所有判定的結果。
判定/條件覆蓋
判斷中每個條件的所有（真、假）取值至少出現一次，并且每個判斷的所有（真、假）判斷結果也至少出現一次
條件組合覆蓋
每個判定中各條件的每一種組合至少出現一次。
為下列代碼設計測試用例，要求滿足條件組合覆蓋，需要設計測試用例的個數為（ ）
都符合，都不符合，一個符合一個不符合（有兩種情況）。
路徑覆蓋使程序中每一條可能的路徑至少執行一次。
性能測試
測試人員通常是做為軟件質量控制的一個角色，不僅僅是找bug,需要對整個軟件的質量負責，性能也屬于質量的一部分，因此測試人員眼中的性能應該是全面的，考慮的東西也需要全面。
測試人員需要考慮全面的性能，包括用戶、開發、管理員等各個視角的性能。
測試人員在做性能測試時除開要關注表面的現象如響應時間，也需要關注本質，比如用戶看不到的服務器資料利用率，架構設計是否合理？代碼是否合理等方方面面。
性能測試類型
1.基準測試：在給系統施加較低壓力時，查看系統的運行狀況并記錄相關數據作為基礎參考
負載測試：是指對系統不斷地增加壓力或增加一定壓力下的持續時間，知道系統的某項或多項性能指標達到安全臨界值，例如某種資源已經達到飽和狀態等
模擬實際軟件系統所承受的負載條件的系統負荷，通過不斷加載（如逐漸增加模擬用戶的數量）或其它加載方式來觀察不同負載下系統的響應時間和數據吞吐量、系統占用的資源（如CPU、內存）等，以檢驗系統的行為和特性，以發現系統可能存在的性能瓶頸、內存泄漏、不能實時同步等問題。負載測試更多地體現了一種方法或一種技術。
壓力測試:壓力測試是評估系統處于或超過預期負載時系統的運行情況，關注點在于系統在峰值負載或超出最大載荷情況下的處理能力。
是在**強負載（大數據量、大量并發用戶等）**下的測試，查看應用系統在峰值使用情況下操作行為，從而有效地發現系統的某項功能隱患、系統是否具有良好的容錯能力和可恢復能力。壓力測試分為高負載下的長時間（如24小時以上）的穩定性壓力測試和極限負載情況下導致系統崩潰的破壞性壓力測試。
壓力測試可以被看作是負載測試的一種，即高負載下的負載測試，或者說壓力測試采用負載測試技術。通過壓力測試，可以更快地發現內存泄漏問題，還可以更快地發現影響系統穩定性的問題。例如，在正常負載情況下，某些功能不能正常使用或系統出錯的概率比較低，可能一個月只出現一次，但在高負載（壓力測試）下，可能一天就出現，從而發現有缺陷的功能或其它系統問題。
通過負載測試，可以證明這一點，某個電子商務網站的訂單提交功能，在10個并發用戶時錯誤率是零，在50個并發用戶時錯誤率是1%，而在200個并發用戶時錯誤率是20％。
負載測試是為了發現系統的性能問題，負載測試需要通過系統性能特性或行為來發現問題，從而為性能改進提供幫助，從這個意義看，負載測試可以看作性能測試的一部分。但它們兩者的目的是不一樣的，負載測試是為了發現缺陷，而性能測試是為了獲取性能指標。因為性能測試過程中，也可以不調整負載，而是在同樣負載情況下改變系統的結構、改變算法、改變硬件配置等等來得到性能指標數據，從這個意義看，負載測試可以看作是性能測試所屬的一種技術，即性能測試使用負載測試的技術、使用負載測試的工具。性能測試要獲得在不同的負載情況下的性能指標數據。
通過負載測試和壓力測試都可以獲得系統正常工作時的極限負載或最大容量。容量測試，自然也是采用負載測試技術來實現，而在破壞性的壓力測試中，容量的確定可以看作是一種副產品——間接結果。
壓力測試
穩定性測試：在給系統加載一定業務壓力的情況下，使系統運行一段時間，以此檢測系統是否穩定
并發測試：測試多個用戶同時訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或者其他性能問題
容量測試（ ）：確定系統最大承受量，譬如系統最大用戶數，最大存儲量，最多處理的數據流量等
性能測試應用場景（領域）主要有：能力驗證、規劃能力、性能調優、缺陷發現、性能基準比較
恢復測試
恢復測試檢測系統的容錯能力。檢測方法是采用各種方法讓系統故障，檢驗系統是否按照要求從故障中恢復過來，并在約定的時間內開始事務處理，而且不對系統造成任何傷害。
強度測試
對系統在異常情況下的承受能力的測試，是檢查系統在極限狀態下運行時，性能下降的幅度是否允許的范圍內。檢查系統能力的最高實際限度，即軟件在一些超負荷情況下的運行情況。
疲勞強度測試
指材料在無限多次交變載荷作用而不會產生破壞的最大應力，稱為疲勞強度或疲勞極限。就像是尋找項目的極值，當到達極值后，會首先出現內存泄漏。
內存泄漏（ Leak）是指程序中己動態分配的堆內存由于某種原因程序未釋放或無法釋放，造成系統內存的浪費，導致程序運行速度減慢甚至系統崩潰等嚴重后果。
每一階段測試基于的文檔
單元測試：軟件設計文檔
集成測試：軟件結構設計文檔
配置項設置：需求規格說明書
系統測試：用戶需求
驗收測試：軟件研制合同
