軟件測試基礎概念
1、什么是軟件測試？其目的是什么？你怎么看待軟件測試？
是為了發現錯誤而執行程序的過程。在軟件投入運行前，對軟件需求分析、設計規格說明和編碼的最終復審，是軟件質量保證的關鍵步驟。
目的是暴露程序中的錯誤。發現測試對象與預期的差異。具體地不同測試階段對應不同測試目的。
軟件測試工作者要站在用戶的額角度思考問題，從用戶的實際使用環境、習慣着手驗證被測對象應用表現。與軟件開發的創造性思維不同，軟測活動的思維模式則是破壞性的通過構建正常、異常輸入去考驗被測對象的健壯性。測試工作是一項極其重要的質量保證活動。因為測試部門是軟件發布質量把控的出口，又可能是用戶意見反饋的入口。
2、軟件測試的生命周期？各階段對應的工作？
測試周期是指從測試項目計划建立到BUG提交的整個測試過程，包括軟件項目測試計划，測試需求分析，測試用例設計，測試用例執行，BUG提交五個階段。軟件測試周期與軟件生命周期並行，存在於軟件生命周期的各個階段。
需求分析階段：測試人員了解需求、對需求進行分解、分析，得出測試需求。
測試計划階段：根據需求編寫測試計划/測試方案。確定測試范圍，測試通過的標准，測試的時間、人力、物力、資源、風險等。輸出測試計划文檔
測試設計、測試開發階段：測試人員搭建測試用例框架，根據需求和設計編寫一部分測試用例。輸出測試方案文檔。
測試執行階段：測試執行階段是軟件測試人員最為重要的工作階段，根據測試用例和計划執行測試。
測試評估階段（BUG提交）：在執行的過程中記錄、管理缺陷，測試完成后編寫測試報告，進行測試評估。
3、測試計划和測試方案的內容和區別？
測試計划確定測試范圍，測試通過的標准，測試的時間、人力、物力、資源、風險等；
測試方案確定測試的方法、類型；確定用例設計的方法，缺陷管理流程；缺陷嚴重程度的划分、用例格式等。
測試計划一般由測試經理、測試主管或項目測試負責人制定，屬於管理文檔，解決的是做什么的問題。測試方案由測試工程師設計，屬於技術文檔，解決的是怎么做的問題。
4、需求評審的內容？參與人員？測試人員為什么要參與需求評審？
內容：同步產品對於需求的詳細設計,收集大家對於需求的各種反饋。
參與人員：產品、設計、研發、運營，測試等其他崗位的人
當面同步需求，對於需求的合理性、全面性的反饋。
5、測試用例的設計方法有哪幾種，分別對應什么典型業務功能？
等價類划分
-
- 等價類即是某個測試對象的輸入域的集合。是一種常用的黑盒測試方法。它將全部輸入數據合理划分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件，從而用少量代表性的測試數據取得較好的測試結果。等價類可分為有效等價類和無效等價類。
- 在輸入條件規定了取值范圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類。
- 在輸入條件規定了輸入值的集合或者規定了"必須如何"的條件的情況下,可確立一個有效等價類和一個無效等價類；
- 在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類
- 在規定了輸入數據的一組值（假定n個）,並且程序要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類
- 在規定了輸入數據必須遵守的規則的情況下,可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）
- 實例：三角形等價類划分https://blog.csdn.net/slforeverlove/article/details/48296121
- 業務：郵件注冊功能。
- 測試用例實際就是各個等價類的排列組合。
邊界值分析
-
- 邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類划分法的補充，這種情況下，其測試用例來自等價類的邊界。
- 大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。
- 構造測試數據是要考慮3個點的選擇：上點，即邊界值點；內點，即與范圍內的點；離點，離上點最近的點，當域是開區間時離點在域內，閉區間時離點在域外。
- 邊界值設計法為每一個有效等價類多增了2個上點的用例。為每一個無效等價類選擇的是離點的用例。
- 應用場景與等價類相同
判定表驅動分析
-
- 在一些數據處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合於處理這類問題。
-
判定表通常由四個部分組成。
1)條件樁（Condition Stub）：列出了問題得所有條件。通常認為列出的條件的次序無關緊要。
2)動作樁（Action Stub）：列出了問題規定可能采取的操作。這些操作的排列順序沒有約束。
3)條件項（Condition Entry）：列出針對它左列條件的取值。在所有可能情況下的真假值。
4)動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。
因果圖法
-
- 等價類划分法和邊界值分析方法都是着重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關系。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視。
- 針對需求規格，將原因及影響對應關系分為兩組：輸入與輸出，輸入與輸入。每種又分別對應四類
- 輸入與輸出：關系主要有恆等、與、或、非。
- 恆等：輸入a，一定產生對應的e。沒有a的輸入，就不會產生e的輸出。
- 與（^）：只有同時有a和b的輸入，才能產生對應的e。
- 或（v）：輸入a或者b，就可以產生對應的e
- 非（~）：只有不輸入a，才能產生對應的e
- 輸入與輸入：異、或、唯一、要求。
- 異：即互斥，所有輸入條件只能成立一個，可以一個都不成立。
- 或：所有輸入條件至少成立一個，可以多個條件共存
- 唯一：所有輸入條件中只能且必須成立一個。
- 要求：如果輸入條件a發生了，那么b也會發生。
-
采用因果圖法設計測試用例的步驟：
1)分析軟件規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 並給每個原因和結果賦予一個標識符。
2)分析軟件規格說明描述中的語義，找出原因與結果之間, 原因與原因之間對應的關系，根據這些關系,畫出因果圖。
3)由於語法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不可能出現，為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件。
4)把因果圖轉換為判定表。
5)把判定表的每一列拿出來作為依據,設計測試用例。
場景設計
-
- 用事件觸發來控制流程的，對於涉及業務流程的軟件系統，使用場景設計法設計是比較恰當的，比狀態遷移類多了些異常的東西。
- 基本流：輸入經過每一個正確的流程運轉最終達到的額預期結果。
- 備選流：表示輸入經過每一個流程運轉時可能產生異常情況，但經過糾正后仍能達到預期的結果。
- 異常流：表示輸入經過每一個流程運轉時，產生的異常終止的現象。
錯誤推測法
-
- 基於經驗和直覺推測程序中所有可能存在的各種錯誤, 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例。從而有針對性的設計測試用例的方法。
6、缺陷的級別及管理流程？
-
- 缺陷等級一般划分為四個等級，致命、嚴重、一般、提示。
致命（Uregent）：主流程無法跑通，系統無法運行，崩潰或業務中斷，應用模塊無法啟動或異常退出，主要功能模塊無法使用。如：1.內存泄漏；2.嚴重的數值計算錯誤；3.系統容易崩潰；4.功能設計與需求嚴重不符；5.系統無法登陸；6.循環報錯，無法正常退出。
嚴重（very high）：影響系統功能或操作，主要功能存在嚴重缺陷，但不會影響到系統穩定性。如：1. 功能未實現；2.功能存在報錯；3.數值輕微的計算錯誤
一般（Medium）：界面、性能缺陷。如：1.邊界條件下錯誤；2.容錯性不好；3.大數據下容易無響應；4.大數據操作時，沒有提供進度條
提示（Low）：易用性及建議性問題。如：1.界面顏色搭配不好；2.文字排列不整齊；3.出現錯別字，但是不影響功能；4.界面格式不規范。
-
- 缺陷管理流程說明：
1、測試人員填寫bug並（Assign）給測試負責人，狀態為New；
2、測試負責人（review）缺陷。主要檢查報告規范，以及確認bug。若是有效的bug，狀態變化為open，並分配給開發人員；若bug無效則指派（Assign）回給測試人員，bug狀態依舊為new
3、開發人員根據缺陷描述確認是否時缺陷，若是則進行修復，修改完成並進行單元測試后，將bug的狀態變為fixed，在comment中說明修改方法，並指派給缺陷發現人。若不是缺陷或者延期修改的，將bug狀態變化為Rejected，同時也在comment中注明原因。
4、測試人員每天查看自己提交的bug的狀態變化，應該成為每個測試人員的例行行為；
5、當bug的狀態變為fixed時，測試人員打開該bug，開始對該bug進行回歸測試；如果該bug回歸測試通過，則狀態變為closed。否則bug的狀態變為reopen（必須說明reopen、closed狀態變化原因或者操作過程）；
6、若對（Reject）的缺陷進行再次確認后測試人員認為是缺陷，則需（Reopen）缺陷至開發人員出，並comment原因。
7、如果回歸測試通過，可是修改的同時又引入新的bug，則重新提交bug，狀態為new。如果需要的時候注明相關聯的bug號；
8、只有當所有的bug狀態為closed，才可發布版本。
注：每當bug狀態改變后，必須給出相應的注釋和說明，以便查看bug生命周期的變化情況。
7、測試准入和通過的標准？
- 准入標准：
- 開發人員編碼結束，並已完成單元測試
- 需求說明書規定的功能或開發人員提交的功能說明書的功能均已實現
- 冒煙測試通過，界面上的功能均實現，符合設計文檔規定的功能。
- 開發人員向測試部提交《測試申請》
- 通過標准：
- 達到100%需求覆蓋
- 所有1、2級用例被執行，3級用例執行率達到95%，4級用例執行率達到80%
- 1級、2級缺陷100%修復，3級95%修復，4級60-80%修復
- 具體缺陷問題需要和用戶溝通確認。
8、測試模型有哪些？
- 瀑布模型（傳統）：需求分析–設計–編程–測試–維護
- V模型：RAD（Rap Application Development，快速應用開發），由於其模型構圖形似字母V，所以又稱軟件測試的V模型。大體可以划分為以下幾個不同的階段：需求分析、概要設計、詳細設計、軟件編碼、單元測試、集成測試、系統測試、驗收測試。適合開發周期短的項目。
缺點有：測試介入較晚，滯后於研發，如果發現前期問題，修復成本非常高；不利於需求的變更；用戶只能在項目交付時才能拿看到成品
- W模型：相對於V模型，W模型增加了軟件開發各階段中同步進行的驗證和確認活動。由兩個V字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的並行關系。測試的對象不僅僅是程序，還包括需求和設計
缺點：需求、設計、編碼等活動被視為串行的，同時，測試和開發活動也保持着一種線性的前后關系，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支持迭代的開發模型。對於當前軟件開發復雜多變的情況，W模型並不能解除測試管理面臨的困惑。
- X模型：對V模型的改進,X模型提出針對單獨的程序片段進行相互分離的編碼和測試,此后通過頻繁的交接,通過集成最終合成為可執行的程序。模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終合成為可執行的程序。右上半部分，這些可執行程序還需要進行測試。已通過集成測試的成品可以進行封版並提交給用戶，也可以作為更大規模和范圍內集成的一部分。X模型還定位了探索性測試（右下方）。
解決滯后於開發的問題
- H模型：相對於V模型和W模型，H模型將測試活動完全獨立出來，形成了一個獨立於研發的流程，將測試准備活動和測試執行活動清晰地體現出來。H模型指出軟件測試要盡早准備, 盡早執行。
缺點：管理型要求高、要求能夠很好的定義每個迭代的規模、測試就緒點分析困難
- 敏捷測試模型（scrum）：關注需求變更、輕文檔，快速迭代
- 前置測試模型：將開發和測試的生命周期整合在一起,標識了項目生命周期從開始到結束之間的關鍵活動。如果其中有些活動沒有得到很好的執行,那么項目成功的可能性就會因此而有所降低。驗收測試和技術測試保持相互獨立。
9、如何保證測試覆蓋率？測試用例評審方式，如何組織，為什么要評審，評審內容？
- 測試覆蓋率：
- 測試需求分析要全面，要進行測試需求評審，保證其准確性和完整性
- 針對測試需求進行用例設計時使用種測試用例設計方法：首先進行等價類划分，必須結合邊界值分析法，可以使用錯誤推測法追加一些測試用例其他的設計方法要根據具體情況選用。
- 用例設計完后要進行用例評審會議
- 用例執行過程中要保證用例100%覆蓋，要繼續對測試用例補充完善，確保提高測試覆蓋率。
- 測試過程中及時更新測試需求和測試用例
- 要將測試需求、測試用例以及發現的bug關聯起來，便於管理和跟蹤，建立需求跟蹤矩陣，同時也便於查看覆蓋率。
- 測試用例評審方式：
- 召開評審會議。與會者在測試用例編寫人員講解之后給出意見或建議，同時記錄下評審會議記錄；
- 通過郵件、及時通訊工具與相關人員溝通。
- 如何組織：首先，測試人員提前准備好用例評審的資料，提前定好會議室發出會議邀約並附上用例評審資料；評審過程中，測試人員要做好會議紀要，如果用例有需要補充或修改的地方快速在Xmind上標注清楚，便於會后進行整理補充測試用例。用例評審會議后整理完善測試用例並再次同步
- 目的和內容：
1、消除產品、開發、測試三方對需求文檔理解的偏差2、保證每個測試人員的質量標准與項目要求標准達成一致；3、為了減少測試人員執行階段做無效工作；（執行無效case，提交無效問題）4、集多人的思想來提高測試的覆蓋率。內容主要有：需求評審、需求實現流程圖評審、測試大綱評審、測試用例檢查
10、敏捷模型？瀑布模型？
詳見題8
11、測試報告的內容有哪些？
12、測試過程中如果發現不可重現的缺陷怎么處理？
不可重現的原因主要有：測試環境不一致，測試配置不一致、內存泄露、數據接口不一致等
解決：1. 測試環境配置充分細致：嚴格核對要求，充分考慮環境變化。另外可以使用Ghost對硬件或某個分區進行鏡像備份。
2. 捕獲系統日志，分析異常信息：測試人員應養成記錄系統錯誤日志的習慣，保留系統在出錯時的真實狀態。比如將IE瀏覽器高級選項設置為“顯示每個腳本錯誤的通知”。
3. 監測系統狀態，異常及時告警：系統運行監測的一個重要內容是需要及時反饋系統運行異常，並提供異常報告。
4. 測試數據翔實，易於追溯：軟件測試開始前，必須制定完整的測試用例，輔以詳細的測試數據，並明確測試數據的操作步驟和每一步的預期結果，這樣，當軟件出現問題，方便重現和定位。
13、測試流程是什么？
即測試周期，詳見第二題
14、測試方法有哪些？
黑盒測試：只關注輸入和輸出，不關注內部邏輯，是基於需求規格說明書的功能測試。主要驗證被測對象的質量及外部特性（功能、性能、界面）。
白盒測試：只關注代碼的內部邏輯結構，是結構測試、邏輯驅動測試，是基於程序代碼內部構成的測試。單元測試中就常使用白盒測試。
灰盒測試：關注模塊之間的數據交互，介於白盒、黑盒之間。同時兼顧被測對象的外部特性和內部結構。如關注日志的集成測試、性能測試和自動化測試
基於風險的測試：指評估測試的優先級。在測試中，首先應該做的是高優先級的測試，如果時間精力不夠，低優先級就可以暫時不做。對於一個用戶很少用到的功能，出問題的概率很小，就算出了問題，影響也不是很大，可以考慮不做測試。
基於模型測試：指用語言將一個系統的行為描述出來，從而定義出它可能的形態以及形態之間的轉換關系，即狀態轉換圖。
15、測試類型有哪些？
功能測試：也叫黑盒測試，主要驗證軟件業務需求實現與否的一項測試活動。其意義是便於用戶理解。
主要檢查被測對象是否存在以下3種錯誤：1、是否有不正確、遺漏或多余的功能。2、是否滿足用戶需求和系統設計的隱藏需求。3、是都對輸入做出正確的響應，輸出結構能否正確展示。
性能測試：通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。
其意義是因為現實情況中資源總是有限的。目的是驗證系統是否具有宣稱的能力
通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。
主要關注cpu、內存、讀寫（響應速度、並發數、業務成功率和資源占用情況）
界面測試：界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。
另外有兼容性測試、安全測試、可靠性測試、可用性測試、移植測試、維護測試、確認測試、回歸測試等
16、α測試和β測試的區別？
兩者都屬於驗收測試，以用戶為主、有用戶參與
α測試：在開發環境下進行，測試環境受控，開發在場
β測試：在實際使用環境下（生產環境）進行，測試環境不受控、開發不在場
17、什么是敏捷測試？什么是探索性測試？
敏捷測試：是適應敏捷方法而采用的新的測試流程、方法和實踐，對傳統的測試流程有所剪裁，有所不同的側重，例如減少測試計划、測試用例設計等工作的比重，增加與產品設計人員、開發人員的交流和協作。在敏捷測試流程中，參與單元測試，關注持續迭代的新功能，針對這些新功能進行足夠的驗收測試，而對原有功能的回歸測試則依賴於自動化測試。由於敏捷方法中迭代周期短，測試人員盡早開始測試，包括及時對需求、開發設計的評審，更重要的是能夠及時、持續的對軟件產品質量進行反饋。簡單地說，敏捷測試就是持續地對軟件質量問題進行及時地反饋
探索性測試：強調測試過程中要有更多的發散思維，拋棄繁雜的測試計划和測試用例設計過程，強調在碰到問題時及時改變測試策略。是用戶故事測試和自動化回歸集的重要補充。由於沒有測試腳本，可以使你的測試超出各種明顯已經測試過的場景。探索測試將學習，測試設計和測試執行整合在一起，形成一種測試方法。探索性測試的最大特色是在對測試對象進行測試的同時學習測試對象並設計測試，在測試過程中運用獲得的關於測試對象的信息設計新的更好的測試。其基本過程如（環節間無絕對順序）：
識別軟件系統的目的;
識別軟件系統提供的功能;
識別軟件系統潛在的不穩定的區域;
在探索軟件系統的過程中記錄關於軟件的消息和問題;
創建一個測試綱要，使用它來執行測試。
18、V模型和W模型的區別？
v模型：測試往往被加在開發過程的后半部分，測試對象只有程序本身，前期面向程序，后期面向用戶。適合工程量小、人力投入少的情況
w模型：測試和開發是同時進行的，測試對象除程序外還有需求、設計等。
19、何為上線？之前工作中上線是怎么做的？
上線：軟件具備正式運行生產的所有必要條件，並且完成發布工作
流程：上線前准備：1、確定上線策略（上線順序、修復數據策略、舊數據分析）
2、寫上線申請郵件（數據配置、上線注意點）
3、配置線上環境數據
上線：一般上線的權限只有幾個人有，所以上線的人員是固定的，上代碼時需要先將線上環境的job停掉，我們也是用jenkins進行自動化部署，只是需要人為的打版號、標簽，部署版本，停Djob任務，上線完全之后，啟動Djob任務等。
上線后：1、灰度測試
2、監控線上數據
全文鏈接：https://zhuanlan.zhihu.com/p/79417003
實例：https://zhuanlan.zhihu.com/p/37584401
20、測試用例的內容、優先級定義、以及如何編寫？
內容：
+ 用例編號（用例id）
+ 一般使用 系統-測試級別-模塊-001 --- 例子：CRM-ST-客戶管理-新增客戶-001
+ 測試標題（用例標題）---- 驗證XXXX 通過/不通過---肯定的語氣
+ 測試項（所屬模塊）
+ 用例屬性（測試類型）--一般為功能測試
+ 重要級別（優先級）---- 1-4級或者 極高-高-中-低
優先級定義：
+ 極高---- 冒煙（主業務流程）
+ 高 ---- 流程類，稍重要的流程
+ 中 ---- 一般流程，界面中比較常用的可能
+ 低 ---- 界面中異常情況，或者很少出現的
如何編寫：
1、划分功能模塊
2、正向功能驗證：正常操作功能是否實現
3、單個功能項驗證：正向+異常
4、功能之間交互驗證：模塊之間的數據傳遞
5、隱形需求：熟悉業務
+ 只要是涉及到輸入框的首先考慮輸入為空的情況
+ 一條用例只測試一個功能點
+ 測試正常和異常的遵循二八原則
+ 操作步驟和預期結果一一對應
+ 如果條件有多個，在實際測試某一個的時候，默認其他條件都滿足
+ 在對一個模塊編寫用例時，首先先對模塊整體的業務走一條冒煙
+ 對一個界面編寫用例時，可以先給頁面一個界面的用例----針對有界面原型的
+ 優先級為高的在這個模塊一般只占5%左右
21、如何測試一個水杯？
尋找水杯是否有說明書，如果有需要充分閱讀並理解水杯說明書，按說明書描述，測試到所有需求點
按測試關注點划分主要分為以下幾個方面：
- 功能測試：
主要關注水杯基本功能
1.1 水杯是否可以正常裝水
1.2 水杯是否可以正常喝水
1.3 水杯是否有蓋子，蓋子是否可以正常蓋住
1.4 水杯是否有保溫功能，保溫功能是否正常保溫
1.5 水杯是否會漏水，蓋住蓋子擰緊后是否會漏水 - 界面測試：
主要關注水杯外觀、顏色、設計等方面
2.1 外觀是否完整
2.2 外觀是否舒適
2.3 顏色搭配及使用是否讓人感到舒適
2.2 杯子外觀大小是否適中
2.3 杯子是否有圖案，圖案是否易磨損 - 易用性測試：
主要關注水杯使用是否方便
3.1 水杯喝水時否方便
3.2 水杯拿起放下是否方便，這里會衍生到水杯形狀的測試
3.3 水杯裝水是否方便
3.4 水杯攜帶是否方方便
3.5 水杯是否有防滑功能
3.6 水杯裝有低溫或者高溫水時，是否會讓手感到不適 - 性能測試：
4.1 水杯裝滿水時，是否會露出來
4.2 水杯最大使用次數
4.3 水杯的保溫性是否達到要求
4.4 水杯的耐寒性是否達到要求
4.5 水杯的耐熱性是否達到要求
4.6 水杯掉落時時，是否可以正常使用
4.7 水杯長時間放置時，是否會發生泄露 - 兼容性測試：
主要關注水杯是否可以裝其他液體，如果汁、汽油、酒精等 - 可移植性測試：
主要關注水杯放置環境等
6.1 將水杯放在常溫環境中，使用是否正常
6.2 將水杯放在零下的環境中，使用是否正常
6.3 將水杯放在高於正常溫度的環境中，使用是否正常 - 安全性測試：
主要關注水杯外觀和各種異常條件下是否釋放有毒物質等
7.1 當水杯裝滿熱水時，水杯是否會燙手
7.2 當水杯裝上水后，是否會產生有毒物質
7.3 把水杯放在零下環境時，是否會產生有毒物質
7.4 把水杯放在高溫環境時，是否會產生有毒物質
22、拆分需求注意事項？
需求是一個整體，整體拆成模塊，模塊拆成小需求，小需求拆成功能點，需求點。測試時，分成整體測試，功能點測試，需求點測試。對於每個需求點根據等價類、邊界值划分等去分析。一個需求就分成了一個樹結構。一層一層的對應。
總體來說主要注意事項如下：
- 了解業務背景（做這個需求的目的是什么）
- 理解業務需求:需求的大致邏輯
- 關注功能需求:為了實現業務需求，軟件應有的功能。
有的是需求文檔明確寫出來的；有的是需求文檔中未提及的，未提及到的則需要我們根據自身的軟件測試經驗來進行補充並想產品確認----這個過程，可以用寫思維導圖體現 - 測試需求:為了實現本期所有功能以及兼容舊用戶使用，所進行一系列測試活動。
包含本期所有的功能需求、以及涉及到可能影響的功能模塊（主要包括上下游模塊和公用方法模塊）、舊數據的兼容、非功能性測試（兼容、性能）–編寫測試子任務
相關題目：給定一句話的需求：“世上無難事，庸人自擾之”，如何拆分測試點來設計測試用例（要求列出測試點）
23、項目組成員包括哪些？
項目經理{開發經理{UI，開發工程師，系統架構師}，測試經理{測試設計、測試工程師}}
24、回歸測試?回歸幾輪？
回歸測試是對已被測試過的程序在修復缺陷后進行的重復測試，目的是驗證修復缺陷有沒有引發新的缺陷或問題。簡單來說就是看有沒有引入新bug。回歸策略有選擇性回歸（一般指針對bug進行回歸，在開始幾輪時候，bug比較多，包括基於風險、 基於操作、基於缺陷）和完全回歸（一般在最后一輪回歸的時候，執行所有用例）。
-一般回歸3輪（如果3輪還未回歸還未修復完bug，再繼續回歸）
25、什么情況下使用自動化測試？
- 需求變更有計划性，更新頻率不高或不會大幅度改版，每次迭代都需要進行驗證；
- 項目周期長（幾年）；
- 腳本重復利用率高；
- 代碼、環境可量化；
- 一個項目可以區分出某部分手動、某部分自動：
比如：基礎性代碼、接口，比較獨立的API、沒有業務依賴，適合自動；
有角度依賴、較復雜的業務邏輯，場景多、類型不一致、因子數多、重度需要人交互，適合手動；
6. 版本穩定后才進行自動化
26、scrum模型中的一些特殊術語？
scrum模型中主要有產品負責人（Product Owner）、ScrumMaster、團隊（Team）。
它由Product backlog開始，經過sprint會議從Prdouct backlog挑選出一些優先級最高的故事（story）形成迭代的sprint backlog（一個sprint一般為1個月）。在sprint中會進行每日站會，迭代結束時會進行演示和回顧會議。
Product Backlog：在項目開始的時候，Product Owner要准備一個根據商業價值排好序的客戶需求列表。這個列表就是Prodct Backlog，一個最終會交付給客戶的產品特性列表，它們根據商業價值來排列優先級。Scrum team會根據這個來做工作量的估計。Product backlog應該涵蓋所有用來構建滿足客戶需要的產品特性，包括技術上的需求。高優先級的一些產品特性需要足夠的細化以便於我們做工作量估計和做測試。對於那些以后將要實現的特性可以不夠詳細。
Sprint Backlog：Sprint Backlog 是Sprint規划會上產出的一個工作成果. 當Scrum team選擇並承諾了Product backlog中要遞交的一些高優先級的產品功能點后，這些功能點就會被細化成為Sprint Backlog:一個完成Product Backlog功能點的必需的任務列表.這些點會被細化為更小的任務，工作量小於2天。Sprint backlog完成后，Scrum team會根據它重新估計工作量，如果這些工作量和原始估計的工作量有較大差異，Scrum team和Product Owner 協商，調整合理得工作量到Sprint中，以確保Sprint的成功實施。
Sprint Planning Meeting（Sprint規划會）、Daily Scrum Meeting（每日站會）、Sprint Review Meeting（Sprint評審會）
https://blog.csdn.net/m0_37561295/article/details/79549499
27、把你熟悉的一個游戲簡單分析如何進行測試？
28、如何搭建測試環境？
- 安裝好Linux操作系統
- 在Linux下安裝JDK
- JDK安好后安裝tomcat
- 安裝MySQL和相關數據庫、安裝測試相關平台、系統
https://www.cnblogs.com/kiki925/p/13490603.html
29、app和web的測試環境有什么區別？
web項目，b/s架構，基於瀏覽器的；web測試只要更新了服務器端，客戶端就會同步會更新
app項目，c/s結構的，必須要有客戶端；app 修改了服務端，則客戶端用戶所有核心版本都需要進行回歸測試一遍
30、系統項目的構成？
前端、UI界面、客戶端、后端、系統服務端代碼、WEB服務器（Apache）、應用服務器（Tomcat輕量級的應用服務器）、數據庫服務器
31、如何構造測試數據？構造測試數據的方式有哪些（接口測試內容）？
1、通過charles工具攔截請求之后，修改響應數據，構造許多數據，模擬mock查看列表及翻頁展示
2、如果有數據庫權限，可以與開發同學協調，讓開發同學幫忙編寫sql語句進行數據添加(當然如果有數據關聯，需要查看下關聯的表結構及關系)。
3、通過UI自動化腳本，錄制或循環運行，進行數據添加。
當然Mock方式還是最簡單和有效驗證的方式。
比如：有些字段返回錯誤，返回異常的字段類型，空的校驗等等，客戶端是否有崩潰，異常產生。
接口端的測試只能保證數據格式和字段是否正確，那么Mock+Selenium/Appium則可以配合進行，驗證我們客戶端的展示是否正確。
一般創建測試數據的方法分為手動創建和采用程序的自動化創建兩種方法
https://blog.csdn.net/zhusongziye/article/details/79078936
32、如何確認測試數據的正確性？
33、你們測試是否與開發共用一個環境？如果是，如何保證測試結果不受影響？
34、什么是接口測試？為什么要做接口測試？怎么做接口測試？
35、接口是否通過測試怎么判斷你？
36、接口測試用例怎么設計？
37、接口自動化是什么？
38、發現缺陷后怎么定位？
先查數據庫，然后查看接口信息，查看前端調試信息，查看相關服務業務處理信息。
ps：夾板思路：先夾大黑盒,再夾小黑盒,逐漸縮小問題發生范圍, 也就是三層 前端 服務 數據來夾. 就是大夾板是最大的黑盒 也就是 只管前端 和 數據庫落地 的輸入和輸出,如果這個大夾板沒問題,輸入也對,落地數據也對,那就基本說明,整個處理鏈路是通的.
https://testerhome.com/articles/16966
39、提交的bug研發不認怎么辦？
在確保缺陷提交流程是已經得到開發認可的前提下，先從自身入手：
- 再次驗證所提的 bug 確實是 bug，確保自身對需求的理解無誤；
- 檢查bug的描述是否會產生歧義；
- 檢查是否是環境或數據的問題，在開發處無法復現。
然后與開發確認：
- 了解開發為什么不認可，需求不明確？
- 接收到的需求是否一致？或者理解錯誤？
- 與開發討論，講清楚你的理由，該問題可能對用戶造成的影響。
如果還是沒有解決的話找權威裁決：
- 這種爭議問題一般集中在需求有歧義不明確、或用戶體驗的地方（數據問題、邏輯問題一般不會有爭議）。可以先找產品經理確認。產品經理通過對影響的確認評估是否需要修改。如果對此依然有疑慮，應該表明自己的觀點，由產品經理或項目經理決定。
40、怎么提交一個高質量的缺陷記錄？（缺陷報告有哪些內容？）
在編寫缺陷記錄前檢查問題是否可重現（如果錯誤不可再重現，仍然應該寫下來，但是必須說明問題的偶然性。一個好的處理原則就是在編寫bug report之前反復嘗試3次）。
嘗試編寫bug report之前，必須試着隔離錯誤。可以采用改變一些變量的方法，如系統的配置，它可能可以改變錯誤的症狀。這些信息可以為開發人員着手調試提供思路。
若問題是已隔離，可重現的，則應對其進行歸納。（同一個問題是否出現在其他的模塊或其他的地方？同一個故障是否有更加嚴重的問題？）
檢查該問題是否是回歸錯誤。
在缺陷報告的第一行寫上錯誤的總結。（已發現的錯誤對客戶有何影響）
缺陷報告初稿完成后進行精簡、消除歧義、（集中剔除那些沒有關系的步驟或詞語，隱含的或模糊的說明、對沒有任何關系的細節的描述或者那些在重現錯誤過程中不需要的步驟。同時或其之后隨即應該再仔細檢查報告是否有會產生誤解的地方。測試人員應該盡量避免使用模糊的，會產生歧義的和主觀的詞語。目標是使用能夠表述事實，清楚的，不會產生爭執的詞語。）
缺陷報告的內容有：+測試的結果
+針對本次測試的一個總結---所用的人力，物力，項目介紹
+ 本次用例情況
+ 缺陷的情況
+ 本次測試的遺留問題
41、各類工具的工作原理是什么？工具都可以用來干什么?為什么要用？
42、禪道如何提交缺陷的？缺陷都有哪些狀態？除了管理缺陷以外還能做些什么？
43、Jmeter：接口測試，具體怎么操作的，有哪些控件？
44、Jmeter：依賴性接口如何測試？