此文轉載自在 https://blog.csdn.net/weixin_30363263/article/details/80110247，其基礎上做了一些調整去重。
一、你在測試中發現了一個 bug ，但是開發經理認爲這不是一個 bug ，你應該怎樣解決。
1、將問題提交到缺陷管理庫裏面進行備案。
2、要獲取判斷的依據和標準：
根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
如果沒有文檔依據，可以根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷；
根據用戶的一般使用習慣，來確認是否是缺陷；
3、與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷；
4、合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不參雜個人情緒。
等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道，向上級反映，並有上級做出決定。
二、如果給你一個網站，你如何測試？
1、查找需求說明、網站設計 m 等相關文檔，分析測試需求。
2、制定測試計劃，確定測試範圍和測試策略，一般包括以下幾個部分：
功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試
3、設計測試用例：
功能性測試可以包括，但不限於以下幾個方面：
鏈接測試，鏈接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等；
多媒體元素是否可以正確加載和顯示；
多語言支持是否能夠正確顯示選擇的語言等。
界面測試可以包括但不限於以下幾個方面：
頁面是否風格統一，美觀；
頁面佈局是否合理，重點內容和熱點內容是否突出；
控件是否正常使用；
對於必須但爲安裝的空間，是否提供自動下載並安裝的功能；
文字檢查。
性能測試一般從以下三個方面考慮：
壓力測試；負載測試；強度測試。
數據庫測試要具體決定是否需要開展。
數據庫一般需要考慮連接性，對數據的存取操作，數據內容的驗證等方面。
安全性測試：
基本的登錄功能的檢查；
是否存在溢出錯誤，導致系統崩潰或者權限泄露；
關於開發語言的常見安全性問題檢查，例如 SQL 注入；
如果需要高級的安全性測試，確定獲得專業安全公司的幫助，外包測試，或者獲取支持兼容性測試，根據需求說明的內容，確定支持的平臺組合；
兼容性測試：
瀏覽器的兼容性；操作系統的兼容性；軟件平臺的兼容性；數據庫的兼容性。
4、開展測試，並記錄缺陷。
合理的安排調整測試進度，提前獲取測試所需的資源，建立管理體系（例如，需求變更、風險、配置、測試文檔、缺陷報告、人力資源等內容）。定期評審，對測試進行評估和總結，調整測試的內容。
三、軟件生存週期及其模型是什麼？
軟件生存週期是軟件開發全部過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、軟件發佈維護的過程。
在經歷需求、分析、設計、實現、部署後，軟件將被使用並進入維護階段，直到最後由於缺少維護費用而逐漸消亡。這樣的一個過程，稱爲"生命週期模型"（Life Cycle Model）。
四、什麼是軟件測試？軟件測試的目的與原則?
軟件測試是使用人工或自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否滿足規定的需求或弄清預期結果與實際結果之間的差別。
軟件測試的目的：
在於發現錯誤，一個成功的測試用例在於發現至今未發現的錯誤，一個成功的測試是發現了至今未發現的錯誤的測試。
確保產品完成了它所承諾或公佈的功能，並且用戶可以訪問到的功能都有明確的書面說明；
確保產品滿足性能和效率的要求；
確保產品是健壯的和適應用戶環境的。
軟件測試的原則：
軟件測試應儘早執行，並貫穿於整個軟件生命週期；
軟件測試應追溯需求；
軟件測試應由第三方來構造；
窮舉測試是不可能的,要遵循 Good-enough 原則；
必須確定預期輸出（或結果）；
必須徹底檢查每個測試結果；
充分注意測試中的羣集現象；
缺陷的二八定理，即80%的錯誤是由20%的程序錯誤導致的；
嚴格執行測試計劃，排除測試的隨意性；
注意合法合理的輸入，也要注意非法的非預期的輸入；
測試應從“小規模”開始，逐步轉向“大規模”；
反覆使用同樣的測試會使軟件具有抵抗力；
關注缺陷的修復。
五、軟件配置管理的作用？軟件配置包括什麼？
軟件配置管理作爲軟件開發過程的必要環節和軟件開發管理的基礎，貫穿整個軟件生命週期，同時對軟件開發過程的宏觀管理即項目管理也有重要的支持作用。一個軟件開發組織真正有效的實施軟件配置管理，將會使軟件開發過程有更好的可預測性，使系統具有可重複性，大大提高軟件組織的競爭力。
軟件配置包括如下內容：
配置項識別；工作空間管理；版本控制；變更控制；狀態報告；配置審計。
七、目前主要的測試用例設計方法是什麼？
1、白盒測試：
邏輯覆蓋；循環覆蓋；基本路徑覆蓋。
2、黑盒測試：
邊界值分析法；等價類劃分；錯誤猜測法；因果圖法；狀態圖法；測試大綱法；隨機測試；場景法。
八、如何測試一個 紙杯？
1、功能度：用水杯裝水看漏不漏；水能不能被喝到；
2、安全性：杯子有沒有毒或細菌；
3、可靠性：杯子從不同高度落下的損壞程度；
4、可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用；
5、兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等；
6、易用性：杯子是否燙手、是否有防滑措施、是否方便飲用；
7、用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述；
8、疲勞測試：將杯子盛上水（案例一）放 24 小時檢查泄漏時間和情況；盛上汽油（案例二）；
9、放 24 小時檢查泄漏時間和情況等；
10、壓力測試：用根針並在針上面不斷加重量，看壓強多大時會穿透。
九、測試計劃工作的目的是什麼？測試計劃文檔的內容應該包括什麼？其中哪些是最重要的？
1、軟件測試計劃是指導測試過程的綱領性文件。
2、包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。
3、其中最重要的是測試策略和測試方法（最好是能先評審）。
十、一條軟件缺陷（或者叫 Bug ）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（ Bug ）記錄？
1、傳統的 BugZilla 中，BUG 描述應該包括以下的信息
和 BUG 產生對應的軟件版本和模塊
開發的接口人員
BUG 的優先級
BUG 的嚴重程度
BUG 可能屬於的模塊，如果不能確認，可以用開發人員來判斷
BUG 標題，需要清晰的描述現象
BUG 描述，需要儘量給出重新 Bug 的步驟
BUG 附件中能給出相關的日誌和截圖。
預期結果和實際結果
2、高質量的 BUG 記錄就是指很容易理解的 BUG 記錄，所以，對於描述的要求高，能提供的信息多且準確，很好的幫助開發人員定位。
十一、請說明黑盒測試和白盒測試各自的優缺點。
1、黑盒測試的優點：
比較簡單，不需要了解程序內部的代碼及實現；
從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
基於軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能；
在做軟件自動化測試時較爲方便。
2、黑盒測試的缺點：
不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的 30%；
自動化測試的複用性較低。
3、白盒測試的優點：
幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。
4、白盒測試的缺點：
程序運行會有很多不同的路徑，不可能測試所有的運行路徑；
測試基於代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；
系統龐大時，測試開銷會非常大。
十二、軟件測試分爲幾個階段？各個階段的測試策略和要求是什麼？
1、按階段劃分爲單元測試、集成測試、系統測試和驗收測試。
2、各階段測試策略：
單元測試：
自頂向下的單元測試策略：比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。
自底向上的單元測試策略：比較合理的單元測試策略，但測試周期較長。
孤立單元測試策略：最好的單元測試策略。
集成測試：
大爆炸集成：適應於一個維護型項目或被測試系統較小
自頂向下集成：適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或經常可能被修改；產口控制組件具有較大的技術風險，需要儘早被驗證；希望儘早能看到產品的系統功能行爲。
自底向上集成：適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
基於進度的集成：具有較高的並行度；能夠有效縮短項目的開發進度。但是樁和驅動工作量較大；有些接口測試不充分；有些測試重複和浪費。
3、各階段要求和成果物：
單元測試階段：各獨立單元模塊在與系統地其他部分相隔離的情況下進行測試，單元測試針對每一個程序模塊進行正確性校驗，檢查各個程序模塊是否正確地實現了規定的功能。生成單元測試報告，提交缺陷報告。
集成測試階段。集成測試是在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程中各部分工作是否達到或實現相應技術指標及要求的活動。該階段生成集成測試報告，提交缺陷報告。
系統測試階段。將通過確認測試的軟件，作爲整個給予計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行全面的功能覆蓋。該階段需要提交測試總結和缺陷報告。
十三、當開發人員說不是BUG時，你如何應付？
1、首先，開發人員說不是 bug，有以下兩種情況：
2、一是需求沒有確定，所以我可以這麼做，這個時候可以找來產品經理進行確認，需不需要改動，3 方商量確定好後再看要不要改。
3、二是這種情況不可能發生，所以不需要修改，這個時候，我可以先儘可能的說出是 BUG 的依據是什麼？如果被用戶發現或出了問題，會有什麼不良結果？程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是 bug，我也只是建議的方式寫進 TD 中，如果開發人員不修改也沒有大問題。如果確定是 bug 的話，一定要堅持自己的立場，讓問題得到最後的確認。