[TOC] ## **一、軟件工程** <details> <summary>1. 闡述軟件生命周期都有哪些階段？常見的軟件生命周期模型有哪些？</summary> ``` 軟件生命周期是指一個計算機軟件從功能確定、設計，到開發成功投入使用，并在使用 中不斷地修改、增補和完善，直到停止該軟件的使用的全過程（從醞釀到廢棄的過程）。 生命周期從收到應用軟件開始算起，到該軟件不再使用為止。它有如下各方面的內容： 初始構思、需求分析、功能設計、內部設計、文檔計劃、測試計劃、文檔準備、集成、 測試、維護、升級、再測試、逐步淘汰 (phase-out)、等等。 瀑布模型，迭代式模型，快速原型模型，螺旋模型。 ``` </details> <br/> <details> <summary>2. 什么是版本控制，常用的版本控制系統有哪些？</summary> ``` 版本控制（Revision control）是一種軟體工程技巧，籍以在開發的過程中，確保由不同 人所編輯的同一檔案都得到更新。 Git(讀音為/g?t/。)是一個開源的分布式版本控制系統，可以有效、高速的處理從很小到 非常大的項目版本管理。 Git 是Linus Torvalds 為了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控 制軟件。https://git-scm.com/doc SVN 是 Subversion 的簡稱，是一個開放源代碼的版本控制系統，相較于 RCS、CVS， 它采用了分支管理系統，它的設計目標就是取代CVS。互聯網上很多版本控制服務已從CVS 遷移到Subversion。https://tortoisesvn.net/support.html ``` </details> <br/> <details> <summary>3. 簡述軟件測試與軟件開發之間的關系？</summary> ``` （1）項目規劃階段：負責從單元測試到系統測試的整個測試階段的監控。 （2）需求分析階段：確定測試需求分析、系統測試計劃的制定，評審后成為管理項目。 測試需求分析是對產品生命周期中測試所需求的資源、配置、每階段評判通過的規約； 系統測試計劃則是依據軟件的需求規格說明書，制定測試計劃和設計相應的測試用例。 （3）詳細設計和概要設計階段：確保集成測試計劃和單元測試計劃完成。 （4）編碼階段：由開發人員進行自己負責部分的代碼的測試。在項目較大時，由專人 進行編碼階段的測試任務。 （5）測試階段（單元、集成、系統測試）：依據測試代碼進行測試，并提交相應的測 試狀態報告和測試結束報告。 開發和測試是一個有機的整體！在產品的發布之前，開發和測試是循環進行的，測出的 缺陷要經開發人員修改后繼續測試。在開發的同時測試經理開始編寫測試用例，測試文 檔要參考開發文檔，所以開發和測試是不可分割的，少了任何一個都不能開發出產品。 從角色方面看，像理論和實驗的關系，開發人員通過自己的想象創造出一套思想，之后 測試人員再對它進行檢驗、證偽，開發人員再修改的過程從而不斷豐富產品。從方法方 面看，是演繹和歸納的關系，一個要掌握大量的技術，一個要不斷的從實例中學習。因 這兩方面的不同，所以開發和測試看上去做的工作很不一樣。 開發與測試是相輔相承、密不可分的，開發人員開發出新的產品后要通過測試判斷產品 是否完全滿足用戶的需求。如果發現缺陷，提交給開發人員進行修復，然后再轉交測試 人員進行回歸測試，直到產品符合需求規格說明。一個符合用戶需求的產品是開發和測 試共同努力的成果。 ``` </details> <br /> <details> <summary>4. 什么是軟件測試，定義和目的？ </summary> ``` 目的：用最少的人力、物力、時間來找到軟件的錯誤并修復，從而降低商業風險 定義：使用人工和自動手段來檢測軟件是否滿足需求 ``` </details> <br /> ## **二、測試模型** <details> <summary>5. 常見測試模型有哪些</summary>  * 特點：這是一種古老的瀑布模型，反映了實際和測試之間的關系 * 局限：僅僅把測試過程作為編碼之后的一個階段，忽視了測試對需求分析,系統設計的驗證，如果前面設計錯誤，得一直到后期的驗收測試才被發現，耗時耗力。  * 特點：測試與開發同時進行，在 V 模型的基礎上，增加了在開發階段的同步測試 * 局限：仍然不支持迭代，減少了一定錯誤發生率，但是需按照流水線進行設計、編碼和測試 </details> <br /> <details> <summary>6. 請根據”V”模型分別概述測試人員在軟件的需求定義階段、設計階段、編碼階段、系統集成階段的工作任務及其相應生成的文檔？ </summary> ``` 統集成階段的工作任務及其相應生成的文檔？ 需求定義階段：根據項目需求提取測試需求 并形成測試需求文檔，根據提取的測試需求和項目計 劃進行測試計劃的擬定，測試計劃文檔 設計階段：根據測試需求擬定測試方案并形成測試方案文檔；根據測試方案制定測試用例，并形 成測試用例文檔 編碼階段：執行測試并完善測試用例文檔 系統集成階段：測試總結報告，階段問題統計報告，測試問題報告 ``` </details> <br /> <details> <summary>7. W 模型的描述？</summary> ``` 軟件測試主要內容是對軟件正確性、完整性、安全性和質量確認及驗證。為了驗證這些，軟件測 試是與開發同步進行的，它們之間的關系同步進行一一對應，當開發進行需求分析、概要設計、 詳細設計、編碼實現、模塊集成、系統構建與實施、交付運行時，測試人員對應工作是需求測 試、概要設計測試、詳細設計測試、單元測試、集成測試、系統測試、驗收測試。 圖中顯示W模型增加了軟件開發各階段中同步進行的驗證和確認活動，測試的活動與軟件開發整 體是同步進行，測試的對象不僅僅是程序，還包括需求和設計，有利于盡早地全面的發現問題可 降低軟件開發和成本。 ``` </details> <br /> ## **三、測試計劃** <details> <summary>8. 編寫測試計劃的目的是？</summary> 使測試工作順利進行；使項目參與人員溝通更舒暢；使測試工作更加系統化。 </details> <br /> <details> <summary>9. 測試計劃編寫的六要素？</summary> ``` why——為什么要進行這些測試 what—測試哪些方面，不同階段的工作內容 when—測試不同階段的起止時間 where—相應文檔，缺陷的存放位置，測試環境等 who—項目有關人員組成，安排哪些測試人員進行測試 how—如何去做，使用哪些測試工具以及測試方法進行測試。 ``` </details> <br /> <details> <summary>10.項目版本執行過程中，測試人員如何把控測試進度？</summary> ``` 在項目的系統測試過程中，測試負責人要及時了解測試進度，跟蹤 BUG 提交、修復及驗證情況 以及系統的拷機情況。 在開發初期階段，測試組執行 BBFV 時，很多模塊、功能點的開發完成進度和原計劃會存在一定 的偏差，就需要測試負責人動態的刷新 WBS 計劃，根據實際的開發進度調整測試計劃。 在開發階段，存在版本編譯不出來導致無法測試，開發人員修復代碼太隨意導致版本穩定性反 復，需求變更過大導致后端測試開發變更嚴重等現象，會導致測試工作無法正常進行。就需要測 試負責人及時反饋出來，根據項目本身的特點進行對應的處理。 當測試進度出現延期時，要及時確認問題原因，如果是問題協查導致，則需及時與研發人員進行 溝通協商，看問題是否必須在測試環境進行排查，若為必現問題可與研發協商要求其在自己環境 進行排查，若必須占用測試環境，則需及時調整測試計劃，若因此可能影響版本的發布，則應及 時與 SE 確認。 若發現有較多 BUG 未解決，則應主動聯系 SE 及研發人員召開 BUG 會確定問題的解決時間。若 發現有較多 BUG未驗證，則應提醒項目組的測試人員及時進行驗證，對于一些拷機或非必現的 BUG，建議測試人員在此 BUG 上現做拷機標記，連續拷機一周未再復現的做關閉處理，若再次 復現則繼續進行排查。 疑難問題的跟控：比較難復現的問題，怎么去嘗試復現。比較難定位的問題，怎么驅動、反饋給 SE，協調開發人員定位問題。比較難處理的問題，怎么跟控反饋進度等 每天下班前需確認拷機內容，每天上班第一件事需確認拷機結果，只有這樣才能保證拷機的效 果，實現拷機的真正意義。 ``` </details> <br /> <details> <summary>11.測試人員在軟件開發過程中的任務是什么？</summary> ``` 尋找 Bug；避免軟件開發過程中的缺陷；衡量軟件的品質；關注用戶的需求。總的目標是：確保 軟件的質量。 ``` </details> <br /> <details> <summary>12.請列出你所知道的軟件測試種類，至少 5 項？</summary>  </details> <br /> ## **四、測試類型** <details> <summary>13.黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別與聯系？</summary> ``` 黑盒測試：把測試對象當成一個黑盒子，測試人員完全不考慮邏輯結構和內部特性， 只 依據程式的需求說明書來檢查程序的功能是否滿足它的功能說明。 白盒測試：把測試對象當成一個透明的盒子，允許測試人員利用程序內部邏輯結構及相 關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。 單元測試：白盒測試的一種，對軟件設計中的單元模塊進行測試。 集成測試：在單元測試的基礎上，對單元模塊之間的連接和組裝進行測試。 系統測試：在所有都考慮的情況下，對系統進行測試。 驗收測試：第三方進行的確認軟件滿足需求的測試。 ``` </details> <br /> <details> <summary>14.黑盒測試和白盒測試常用的測試方法有哪些，舉個例子？</summary> ``` 黑盒有等價類劃分法，邊界分析法，因果圖法和錯誤猜測法。 白盒有邏輯覆蓋法，循環測試路徑選擇，基本路徑測試。 例子：在一次輸入多個條件的完整性查詢中。利用等價類劃分法則和邊界分析法則，首 先利用等價類劃分法，可以一個或多個結果是OK的測試用例，然后確認多個NG的測試 用例，然后利用邊界值分析法，可以對結果分別是OK和NG的測試用例進行擴展和補充。 ``` </details> <br /> <details> <summary>15. 簡述黑盒測試和白盒測試的優缺點？</summary> ※ 黑盒測試的優點有： 1. 比較簡單，不需要了解程序內部的代碼及實現； 2. 與軟件的內部實現無關； 3. 從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題； 4. 基于軟件開發文檔，所以也能知道軟件實現了文檔中的哪些功能； 5. 在做軟件自動化測試時較為方便。 ※ 黑盒測試的缺點有： 1. 不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的 30%； 2. 自動化測試的復用性較低。 ※ 白盒測試的優點有： 1. 幫助軟件測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱藏的問題。 ※ 白盒測試的缺點有： 1. 程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基于代碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。 </details> <br /> <details> <summary>16.在沒有產品說明書和需求文檔的情況下能夠進行黑盒測試的設計嗎？</summary> ``` 能，可以通過其他工作內容去替代產品說明書和需求文檔 根據客戶的功能點整理測試需求追溯表 根據開發人員的 Software Specification List 整理功能測試點 開展項目跨部門討論會，主要整理對功能點的理解和認識 測試人員整理用例需求疑問提交項目組或者產品 項目內部的用例品勝 郵件客戶代表確認部分爭議問題 項目的 Demo 和部分已經開發的系統 參考同行業和競爭對手的類似產品 交叉模塊之間的測試 咨詢客戶或相關者 ``` </details> <br /> <details> <summary>17.單元測試的策略有哪些，主要內容有哪些？</summary> 邏輯覆蓋，循環覆蓋，同行評審，桌前檢查，代碼走查，代碼評審，靜態數據流分析。 </details> <br /> <details> <summary>18. 白盒測試邏輯覆蓋有哪幾種覆蓋標準，覆蓋率最高的是什么？</summary> 語句覆蓋，分支覆蓋，條件覆蓋，路徑覆蓋，分支條件覆蓋，覆蓋率最高的是路徑覆蓋。 ``` 1.語句覆蓋：就是設計若干個測試用例，運行被測程序，使得每一可執行語句至少執行一次。 2.判定覆蓋：使設計的測試用例保證程序中每個判斷的每個取值分支至少經歷一次。 3.條件覆蓋：條件覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，判定中每個 條件的所有可能結果至少出現一次，但未必能覆蓋全部分支 4.判定條件覆蓋：判定-條件覆蓋就是設計足夠的測試用例，使得判斷中每個條件的所有 可能取值至少執行一次，同時每個判斷的所有可能判斷結果至少執行，即要求各個判斷的 所有可能的條件取值組合至少執行一次。 5.條件組合覆蓋：在白盒測試法中，選擇足夠的測試用例，使所有判定中各條件判斷結果 的所有組合至少出現一次，滿足這種覆蓋標準成為條件組合覆蓋。 6.路徑覆蓋：是每條可能執行到的路徑至少執行一次。 補充： （1）語句覆蓋在所有的測試方法中是一種最弱的覆蓋。 （2）判定覆蓋和條件覆蓋比語句覆蓋強，滿足判定/條件覆蓋標準的測試用例一定也滿足 判定覆蓋、條件覆蓋和語句覆蓋 （3）路徑覆蓋也是一種比較強的覆蓋，但未必考慮判定條件結果的組合，并不能代替條 件覆蓋和條件組合覆蓋。 ``` </details> <br /> <details> <summary>19. Beta測試和Alpha測試有什么區別？</summary> ``` 大型通用軟件，在正式發布前，通常需要執行 Alpha 和 Beta 測試，目的是從實際終端用 戶的使用角度，對軟件的功能和性能進行測試，以發現可能只有最終用戶才能發現的錯 誤。 Alpha 測試是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實 際操作環境下進行的受控測試，Alpha 測試不能由程序員或測試員完成。Alpha 測試發現 的錯誤，可以在測試現場立刻反饋給開發人員，由開發人員及時分析和處理。目的是評 價軟件產品的功能、可使用性、可靠性、性能和支持。尤其注重產品的界面和特色。 Alpha 測試可以從軟件產品編碼結束之后開始，或在模塊（子系統）測試完成后開始， 也可以在確認測試過程中產品達到一定的穩定和可靠程度之后再開始。有關的手冊（草 稿）等應該在 Alpha 測試前準備好。 Beta 測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通 常不在測試現場，Beta測試不能由程序員或測試員完成。因而，Beta 測試是在開發者無 法控制的環境下進行的軟件現場應用。在 Beta 測試中，由用戶記下遇到的所有問題，包 括真實的以及主管認定的，定期向開發者報告，開發者在綜合用戶的報告后，做出修 改，最后將軟件產品交付給全體用戶使用。Beta 測試著重于產品的支持性，包括文檔、 客戶培訓和支持產品的生產能力。只有當 Alpha 測試達到一定的可靠程度后，才能開始 Beta 測試。由于Beta 測試的主要目標是測試可支持性，所以Beta測試應該盡可能由主持 產品發行的人員來管理。 ``` </details> <br /> ## **五、測試流程** <details> <summary>20. 軟件測試的基本流程有哪些？</summary> ``` 需求分析、編寫測試用例、評審測試用例、搭建環境、等待程序開發包、部署程序開發包、 冒煙測試、執行具體的測試用例細節、Bug 跟蹤處理回歸測試、N 輪之后滿足需求，測試結束。 ``` </details> <br /> <details> <summary>21. 測試結束的標準是什么？</summary> ``` 第一類標準：測試超過了預定時間，則停止測試。 第二類標準：執行了所有的測試用例，但并沒有發現故障，則停止測試。 第三類標準：使用特定的測試用例設計方案作為判斷測試停止的基礎。 第四類標準：正面指出停止測試的具體要求，即停止測試的標準可定義為查出某一預訂 數目的故障。 第五類標準：根據單位時間內查出故障的數量決定是否停止測試。 ``` </details> <br /> <details> <summary>22.軟件測試的原則是什么？</summary> ``` 1) 應當把“盡早地和不斷地進行軟件測試”作為軟件開發者的座右銘。 2) 測試用例應由測試輸入數據和對應的預期輸出結果這兩部分組成。 3) 程序員應避免檢查自己的程序。 4) 在設計測試用例時，應包括合理的輸入條件和不合理的輸入條件。 5) 軟件測試的原則 6) 充分注意測試中的群集現象。 經驗表明，測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目成正比。 7) 嚴格執行測試計劃，排除測試的隨意性。 8) 應當對每一個測試結果做全面檢查。 9) 妥善保存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。 ``` </details> <br /> ## **六、用例設計** <details> <summary>23. 什么是測試用例，測試用例的基本要素？</summary> ``` 測試用例是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試 某個程序路徑或核實是否滿足某個特定需求。 測試用例的基本元素： 測試索引，測試環境，測試輸入，測試操作，預期結果，評價標 準。 ``` </details> <br /> <details> <summary>24.描述測試用例設計的完整過程？</summary> ``` 首先根據需求文檔、概要設計、測試計劃、測試方案細分出各功能模塊的測試項； 再根據各測試項，按照概要設計、詳細設計以及測試方案中測試的覆蓋率細分出測試子 項； 最后按照測試子項、根據測試用例的設計方法（因果圖、邊界值、等價類等的設計方 法）書寫測試用例。 注意： 選用適合的用例管理工具（如 word，excel）；?l 用例一定要及時更新（補充新的想法，刪除過時的需求）； 做好用例分級； 做好用例評審，寫用例之前可以征詢相關人員的意見，如果評審通過可以參考其執行測 試，如果未通過，需要繼續修改直到通過為止。 可以考慮結對編寫，這個是不錯的主意； 要全面，包括功能、性能、兼容性、安全性、易用性、容錯性等等； 注意把握適當的顆粒度。 ``` </details> <br /> <details> <summary>25.好的測試用例有哪些特點？</summary> ``` 質量屬性： 正確性：確保測試標題描述部分的內容正確性。 經濟性：只為確定需要的目的設計相應的測試步驟。 可重復性：自我一致性，即不管誰執行此用例，結果一樣。 適應性：既能適應短期需要，又能考慮長遠需要。 可追蹤性：用例能追蹤到一個具體的需求。 自我清理性：單個用例不會影響整個測試環境，即用例執行完了可以恢復原有的測試環境。 結構化和可測試性 含有規范的測試標題和編號。 含有一個確定的測試某一個特定需求的目的。 含有關于測試方法的描述。 指定條件信息\-環境、數據、預置的條件測試、安全入口等。 含有操作步驟和預期結果。 陳述任何輔助證據，例如截圖報告并確保這些東西妥善保存。 確保測試環境的干凈（即用例不會影響整個環境）。 描述時使用主動語氣結構。 操作步驟不要超過 15 步。 確保單個用例測試執行時用時不超過 20 分鐘。 自動化腳本用例添加必要的注釋，比如目的、輸入和期望結果。 如果可能，建議提供可選擇性的預置條件測試。 用例之間的先后順序是否跟業務流程一致，即用例在業務流程中的彼此順序關系是否合理。 配置管理： 采用命名和編號規范歸檔。 保存為特定的格式，文件類型。 用例版本是否與當前被測試軟件版本一致（對應）。 包含用例需要的相應測試對象，如特定數據庫。 存檔閱讀。 存檔時按角色控制訪問方式 當網絡備份時存檔。 離線歸檔。 ``` </details> <br /> <details> <summary>26.寫測試用例時要注意什么問題</summary> ``` 1、復用率：如果隨著產品不停得升級，需要設計的詳細些，追求一勞永逸；僅使用一兩次，則 沒有必要設計的過于詳細； 2、項目進展：項目時間如果允許可以設計的詳細些，反之則能執行即可； 3、使用對象：測試用例如果供多人使用，尤其讓后參加測試的工程師來執行，則需要設計的詳細些。 4、用例的冗余 5、操作步驟要細分簡明，可執行。 ``` </details> <br /> <details> <summary>27.如何在有限的情況下提高測試效率，保證產品的上線質量？</summary> ``` 1、一個詳細合理的詳細的測試計劃 2、測試盡早的介入項目，連接項目的業務需求，做好測試的前期準備 3、對測試項目前景充滿信心，調整最佳心態，保持愉悅的工作心情 4、提高測試接受的標準，減少測試版本的送測次數 ``` </details> <br /> <details> <summary>28.如何降低漏測率</summary> ``` 1、需求評審 2、梳理需求，盡早與開發人員、需求人員進行需求確認，統一不同角色對需求的認識 3、用例設計及評審 4、測試執行 5、bug 回歸 6、發布前的功能回歸 ``` </details> <br /> <details> <summary>29.測試用例的基本設計方法</summary> ``` 1、等價類劃分法 (有效等價類:對于程序規格說明來說，是合理的，有意義的輸入數據構成的集合) (無效等價類:對于程序規格說明來說，是不合理的，無意義的輸入數據構成的集合) 2、邊界值分析法 3、錯誤推斷法 4、因果圖判定表法 5、正交實驗法 6、流程法 7、場景法 ``` </details> <br /> <details> <summary>30.測試為什么要寫測試用例</summary> ``` 1、深入了解需求的過程 2、測試執行的指導 3、規劃測試數據的準備 4、反應測試進度 5、舉一反三發現隱藏缺陷 6、分析缺陷標準 ``` </details> <br /> ## **七、缺陷 bug** <details> <summary>31.什么是缺陷報告，缺陷報告的作用，缺陷報告的要點</summary> ``` （1）缺陷報告是描述軟件缺陷現象和重現步驟的集合。軟件缺陷報告 Software Bug Report(SBR)或軟件問題報告 software Problem Report(SPR)。 （2）缺陷報告是軟件測試人員的工作成果之一，體現軟件測試的價值缺陷報告可以把軟 件存在的缺陷準確的描述出來，便于開發人員修正缺陷報告可以反映項目/產品當前的質 量狀態，便于項目整體進度和質量控制軟件測試缺陷報告是軟件測試的輸出成果之一， 可以衡量測試人員的工作能力。 （3）標題(Title)簡潔、準確、完整、反映缺陷本質、方便查詢前綴+標題正文，標題正文 采用結果和動作，或者現象和位置的方式表達；步驟(Steps)可復現、完整、簡潔、準確 按數字編號；實際結果(Actual results)準確、詳細描述軟件的現象和特征；期望結果 (Expected results)準確、豐富、有理有據；平臺(Platforms)準確；截圖(Sereenshots)準 確反映缺陷特征；注釋(Notes)關于缺陷的輔助說明。 ``` </details> <br /> <details> <summary>32.軟件測試缺陷報告的 5C 原則</summary> ``` Correct（準確）：每個組成部分的描述準確，不會引起誤解； Clear（清晰）：每個組成部分的描述清晰，易于理解； Concise（簡潔）：只包含必不可少的信息，不包括任何多余的內容； Complete（完整）：包含復現該缺陷的完整步驟和其他本質信息； Consistent（一致）：按照一致的格式書寫全部缺陷報告。 ``` </details> <br /> <details> <summary>34.缺陷描述（報告單）中應該包括哪些內容？</summary> ``` 缺陷的標題，簡要描述。缺陷的類型。缺陷的詳細步驟描述。缺陷的實際結果。期望結 果。有的缺陷需要上傳截圖，日志信息。缺陷的等級。缺陷指派給開發同事。（開發主 管） ``` </details> <br /> <details> <summary>35.如何提高缺陷的記錄質量？</summary> ``` 通用 UI 要統一、準確；盡量使用業界慣用的表達術語和表達方法；使用業界慣用的表達 術語和表達方法，保證表達準確，體現專業化；每條缺陷報告只包括一個缺陷；不可重 現的缺陷也要報告；明確指明缺陷類型；明確指明缺陷嚴重等級和優先等級；描述 (Description) ，簡潔、準確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置；短行 之間使用自動數字序號，使用相同的字體、字號、行間距； 每一個步驟盡量只記錄一個 操作；確認步驟完整，準確，簡短；根據缺陷，可選擇是否進行圖象捕捉； 檢查拼寫和 語法缺陷；盡量使用短語和短句，避免復雜句型句式；缺陷描述內容。 ``` </details> <br /> <details> <summary>36.如果一個缺陷被提交后，開發人員認為不是問題，怎么處理？</summary> ``` a)首先，將問題提交到缺陷管理庫里面進行備案。 b)然后，要獲取判斷的依據和標準： v.根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據； vi.如果沒有文檔依據，可以根據類似軟件的一般特性來說明是否存在不一致的地方，來確認是否是缺陷； vii.根據用戶的一般使用習慣，來確認是否是缺陷； viii.與設計人員、開發人員和客戶代表等相關人員探討，確認是否是缺陷； c)合理的論述，向測試經理說明自己的判斷的理由，注意客觀、嚴謹，不摻雜個人情 緒。 d)等待測試經理做出最終決定，如果仍然存在爭議，可以通過公司政策所提供的渠道， 向上級反映，并有上級做出決定。 ``` </details> <br /> <details> <summary>37.缺陷的優先級劃分和描述</summary> ``` 一般來說按照下面的來分，具體的是由每個公司而定。 軟件缺陷有四種級別，分別為：致命的(Fatal)，嚴重的(Critical)，一般的(Major)，微小 的(Minor)。 A 類—致命的軟件缺陷(Fatal):造成系統或應用程序崩潰、死機、系統掛起，或造成數據 丟失，主要功能完全喪失，導致本模塊以及相關模塊異常等問題。如代碼錯誤，死循 環，數據庫發生死鎖、與數據庫連接錯誤或數據通訊錯誤，未考慮異常操作，功能錯誤 等。 B 類—嚴重錯誤的軟件缺陷（critical）：系統的主要功能部分喪失、數據不能保存，系 統的次要功能完全喪失。 問題局限在本模塊，導致模塊功能失效或異常退出。如致命的 錯誤聲明，程序接口錯誤，數據庫的表、業務規則、缺省值未加完整性等約束條件。 C 類—一般錯誤的軟件缺陷（major）：次要功能沒有完全實現但不影響使用。如提示信 息不太準確，或用戶界面差，操作時間長，模塊功能部分失效等，打印內容、格式錯 誤，刪除操作未給出提示，數據庫表中有過多的空字段。 D 類—較小錯誤的軟件缺陷（Minor）:使操作者不方便或遇到麻煩，但它不影響功能過 的操作和執行，如錯別字、界面不規范（字體大小不統一，文字排列不整齊，可輸入區 域和只讀區域沒有明顯的區分標志），輔助說明描述不清。 E 類- 建議問題的軟件缺陷（Enhancemental）：由問題提出人對測試對象的改進意見或 測試人員提出的建議、質疑。 ``` </details> <br /> ## **八、測試實例** <details> <summary>38.一個有廣告的紙杯子，請設計測試用例？</summary> 測試項目：杯子 ``` 需求測試：查看杯子使用說明書 界面測試：查看杯子外觀 功能度：用水杯裝水看漏不漏；水能不能被喝到 安全性：杯子有沒有毒或細菌 可靠性：杯子從不同高度落下的損壞程度 可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用 兼容性：杯子是否能夠容納果汁、白水、酒精、汽油等 易用性：杯子是否燙手、是否有防滑措施、是否方便飲用 用戶文檔：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述 疲勞測試：將杯子盛上水（案例一）放 24 小時檢查泄漏時間和情況；盛上汽油（案例二）放 24 小時檢查泄漏 時間和情況等 壓力測試：用根針并在針上面不斷加重量，看壓強多大時會穿透 跌落測試: 杯子加包裝(有填充物),在多高的情況摔下不破損 震動測試: 杯子加包裝(有填充物),六面震動,檢查產品是否能應對惡劣的鐵路\公路\航空運輸 基本功能測試（邏輯功能測試）。 （1）硬度：是否達到設計標準。 裝載能力：在杯子內分別裝入少量的、半杯的、滿杯的，看其裝載量是否達到設計標準。 裝載種類：開水（是否產生異味）、溫水、冷水、冰水、咖啡... （2）界面測試（UI 測試）。 看其形狀、大小設計是否適合人方便拿起。 外觀是否吸引人（廣告嘛），賞心悅目。 帶廣告的圖案沾水受是否掉色、模糊。 （3）易用性測試。 看其形狀、大小設計是否適合人方便拿起。 殘疾人士用此杯去喝水的容程度。 杯子設計是否上大下小，在運輸過程中可以套在一起有效利用空間，在使用時也容易拿開。 （4）穩定性測試（24 X 7 測試）。裝入液體后記錄其多少以后漏水。 （5）安全性測試。杯子所用的材料（包括紙基、涂層和廣告顏料）是否符合食品衛生標準，在 內外溫度等環境因素下是否會與所盛各種飲料相反應，而產生對人體有害的物質。 （6）本地化測試。為國際化和本地化的需要，廣告圖案和文字是否在政治、宗教和文化方面具 有廣泛的適用性。 （7）對設計的改進建議。“如果是一次性杯子，能否標示已使用（比如變色）”和“杯子是否有使 用者標貼（多人使用時防止混淆）”。 ``` </details> <br /> <details> <summary>39.一個身份證號碼輸入框，怎么設計用例？</summary> ``` 校驗身份證號規則的有效性（包括地址碼、生日期碼、順序碼和校驗碼 校驗 15 位身份證號和 18 位身份正好都是可用的 校驗末位是 X 的情況 校驗不足 15 位、16-17 位和大于 18 位的情況 如果是必輸項，校驗不輸入的時候會不會有正確的提示 如果不是必輸項，則要校驗不輸入的時候流程能否正常進行 校驗輸入非數字的情況，是否會有正確提示信息（包括大小寫字母、漢字、特殊字符和標點符號） 校驗輸入全角的數字的時候，系統是否會識別（這個得根據需求確定是否可以使用全角的數字） ``` </details> <br /> <details> <summary>40.登錄功能怎么設計測試用例？</summary> ``` 具體需求： 有一個登錄頁面，有一個賬號和一個密碼輸入框, 一個提交按鈕。 此題的考察目的： 1、了解需求（測什么都是從了解需求開始）； 2、是否有設計 Test Case 的能力 3、是否熟悉各種測試方法； 4、是否有豐富的 Web 測試經驗； 5、是否了解 Web 開發； 了解需求： 1、登錄界面應該是彈出窗口式的，還是直接在網頁里面； 2、賬號長度和密碼的強度（比如需要多少位、大小寫敏感、特殊字符混搭等）； 3、界面美觀是否有特殊要求？（即是否要進行 UI 測試）； 4、···· 用例設計： 測試需求分析完成后，開始用例設計，主要可以從以下幾個方面考慮： 功能測試(Function Test) 1、輸入正確的賬號和密碼，點擊提交按鈕，驗證是否能正確登錄。（正常輸入） 2、輸入錯誤的賬號或者密碼, 驗證登錄會失敗，并且提示相應的錯誤信息。（錯誤校驗） 3、登錄成功后能否跳轉到正確的頁面（低） 4、賬號和密碼，如果太短或者太長，應該怎么處理（安全性，密碼太短時是否有提示） 5、賬號和密碼，中有特殊字符（比如空格），和其他非英文的情況（是否做了過濾） 6、記住賬號的功能 7、登錄失敗后，不能記錄密碼的功能 8、賬號和密碼前后有空格的處理 9、密碼是否加密顯示（星號圓點等） 10、牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使用者），刷新或換一個按鈕是否好用 11、登錄頁面中的注冊、忘記密碼，登出用另一帳號登錄等鏈接是否正確 12、輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。 13、什么都不輸入，點擊提交按鈕，看提示信息。（非空檢查） 界面測試(UI Test) 1、布局是否合理，2 個 Testbox 和一個按鈕是否對齊 2、Testbox 和按鈕的長度，高度是否符合要求 3、界面的設計風格是否與 UI 的設計風格統一 4、界面中的文字簡潔易懂，沒有錯別字。 性能測試(Performance Test) 1、打開登錄頁面，需要幾秒 2 、輸入正確的賬號和密碼后，登錄成功跳轉到新頁面，不超過 5 秒 安全性測試(Security Test) 1、登錄成功后生成的 Cookie 是否有 HttpOnly(降低腳本盜取風險) 2、賬號和密碼是否通過加密的方式，發送給 Web 服務器 3、賬號和密碼的驗證，應該是用服務器端驗證，而不能單單是在客戶端用 javaScript 驗證 4、賬號和密碼的輸入框，應該屏蔽 SQL 注入攻擊 5、賬號和密碼的輸入框，應該禁止輸入腳本（防止 XSS 攻擊） 6、錯誤登錄的次數限制（防止暴力破解） 7、考慮是否支持多用戶在同一機器上登錄； 8、考慮一用戶在多臺機器上登錄 可用性測試(Usability Test) 1、是否可以全用鍵盤操作，是否有快捷鍵 2、輸入賬號，密碼后按回車，是否可以登錄 3、輸入框是否可以以 Tab 鍵切換 兼容性測試（Compatibility Test） 1、主流的瀏覽器下能否顯示正常已經功能正常（IE6~11, FireFox, Chrome, Safari 等 ） 2、不同的平臺是否能正常工作，比如 Windows, Mac 3、移動設備上是否正常工作，比如 iPhone, Android 4、不同的分辨率 本地化測試 （Localization Test） 1、不同語言環境下，頁面的顯示是否正確。 軟件輔助性測試 （Accessibility Test） 軟件輔助功能測試是指測試軟件是否向殘疾用戶提供足夠的輔助功能 1、高對比度下能否顯示正常（視力不好的人使用） ``` </details> <br /> <details> <summary>41.移動端和 web 端測試有什么區別</summary> ``` 單純從功能測試的層面上來講的話，APP 測試、web 測試 在流程和功能測試上是沒有區別的。 根據兩者載體不一樣，則區別如下： 系統結構方面 web 項目，b/s 架構，基于瀏覽器的；web 測試只要更新了服務器端，客戶端就會同步會更新。 app 項目，c/s 結構的，必須要有客戶端；app 修改了服務端，則客戶端用戶所有核心版本都需要進行回歸 測試一遍。 性能方面 web 項目 需監測 響應時間、CPU、Memory app 項目 除了監測 響應時間、CPU、Memory 外，還需監測 流量、電量等 兼容方面 （1）web 項目： 1. 瀏覽器（火狐、谷歌、IE 等） 2. 操作系統（Windows7、Windows10、Linux 等） （2）app 項目： 1. 設備系統:iOS（ipad、iphone）、Android（三星、華為、聯想等） 、Windows（Win7、Win8）、 OSX（Mac） 2. 手機設備可根據 手機型號、分辨率不同 相對于 Wed 項目，APP 有專項測試 1. 干擾測試：中斷，來電，短信，關機，重啟等 2. 弱網絡測試（模擬 2g、3g、4g，wifi 網絡狀態以及丟包情況）；網絡切換測試（網絡斷開后重連、3g 切 換到 4g/wifi 等） 3. 安裝、更新、卸載 安裝：需考慮安裝時的中斷、弱網、安裝后刪除安裝文件等情況 卸載：需考慮 卸載后是否刪除 app 相關的文件 更新：分強制更新、非強制更新、增量包更新、斷點續傳、弱網狀態下更新 4. 界面操作：關于手機端測試，需注意手勢，橫豎屏切換，多點觸控，前后臺切換 5. 安全測試：安裝包是否可反編譯代碼、安裝包是否簽名、權限設置，例如訪問通訊錄等 6. 邊界測試：可用存儲空間少、沒有 SD 卡/雙 SD 卡、飛行模式、系統時間有誤、第三方依賴（QQ、微信 登錄）等 7. 權限測試：設置某個 App 是否可以獲取該權限，例如是否可訪問通訊錄、相冊、照相機等 測試工具方面 自動化工具：APP 一般使用 Appium; Web 一般使用 Selenium 性能測試工具：APP 一般使用 JMeter; Web 一般使用 LR、JMeter ``` </details> <br /> <details> <summary>42.測試一個 C/S 客戶端時，需要考慮的因素 </summary> ``` 客戶端安裝測試 客戶端升級測試 客戶端可維護性測試 （1）個體的客戶端應用以“分離的”模式被測試——不考慮服務器和底層 網絡的運行； （2）客戶端軟件和關聯的服務器端應用被一起測試，但網絡運行不被明 顯的考慮； （3）完整的 C/S 體系結構，包括網絡運行和性能被測試。 應用功能測試——客戶端應用被獨立地執行，以揭示在其運行中的錯誤。 服務器測試——測試服務器的協調和數據管理功能，也考慮服務器性能 （整體反映時間和數據吞吐量）。 數據庫測試——測試服務器存儲的數據的精確性和完整性，檢查客戶端應 用提交的事務，以保證數據被正確地 存儲、更新和檢索。 事務測試——創建一系列的測試以保證每類事務被按照需求處理。測試著 重于處理的正確性，也關注性能問題。 網絡通信測試——這些測試驗證網絡節點間的通信正常地發生，并且消息 傳遞、事務和相關的網絡交通無錯的 發生。 ``` </details> <br /> <details> <summary>43.測試電梯，請詳細描述 </summary> **如果給你一臺電梯，請問你如何測試它，分析如下：** ``` 1.功能：上升、下降、停止、開門、關門、梯內電話、燈光、指示燈等； 2.性能：速度、反應時間、關門時間等； 3.壓力：超載、尖銳物碰撞電梯壁等； 4.安全：停電、報警裝置、轎箱停靠位置、有人扒門時的情況等； 5.可用性：按鍵高度、操作是否方便、舒適程度等； 6.UI：美觀程度、光滑程度、形狀、質感等； 7.穩定性：長時間運行情況等； 8.兼容性：不同電壓是否可工作、不同類型電話是否可安裝等。其實在簡單分析的過程中，發現許多東西根本測試不全，比如電話、燈光、材質、調度程序、可維修性等，當發現在一個用例中無法說清楚時，這些應該拆分開來分別測試。可以告訴主考官，你需要模塊化地測試電話、燈光等。再有在一起的組裝測試。 下面是詳細的測試點： 需求測試：查看電梯使用說明書、安全說明書等 界面測試：查看電梯外觀 功能測試： 1. 測試電梯能否實現正常的上升和下降功能。 2. 電梯的按鈕是否都可以使用。 3. 電梯門的打開，關閉是否正常。 4. 報警裝置是否可用。 5. 與其他電梯之間是否協作良好。 6. 通風狀況如何。 7. 突然停電時的情況。 8. 上升途中的響應。 1）電梯本來在 1 樓，如果有人按 18 樓，那么電梯在上升到 5 樓的時候，有人按了 10 樓，這時候是否會 在 10 樓先停下來 2）電梯下降到 10 層時顯示滿員，此時若 8 層有人等待電梯，是否在 8 層停。 9. 是否有手機信號 可靠性測試： 1. 門關上的一剎那出現障礙物。 2. 同時按關門和開門按鈕。 3. 點擊當前樓層號碼 4. 多次點擊同一樓層號碼 5. 同時按上鍵和下鍵 易用性：電梯的按鈕的設計符合一般人的習慣嗎 用戶文檔：使用手冊是否對電梯的用法、限制、使用條件等有詳細的描述 壓力測試：1.看電梯的最大承重量，在負載過重時報警裝置是否有提醒 穩定性測試：看墊底在最大負載下平行運行的最長時間 ``` </details> <br /> <details> <summary>44.對一只圓珠筆進行測試</summary> ``` 1.界面測試，無論我們做那類軟件（嵌入式別提），只要給用戶有看到的東西，從測試的角度，就要考慮 界面測試，這個呢，現在針對微軟的產品，某公司開發了一套界面檢查表，我這里有一份，想要可以找 我。 界面測試測什么，怎么測呢？針對這個問題我是這樣回答的，印刷在產品上的圖片，文字，這可能涉及不 同的東西，有圓珠筆廠家的信息，也有針對不同用戶的信息（譬如小孩子喜歡顏色搭配多一點的，而成人 用穩重的產品等），可能涉及的還有人的審美觀，你圓珠筆色彩搭配之類的 2. 功能測試，這是我們測試的重點，也是客戶針對某家公司產品給出滿意度的參考點，圓珠筆功能主要是 書寫， 這里面涉及一個功用方面的焦點——書寫的快慢程度，也就是流利不流利的問題（這涉及筆芯的材 質問題） 針對這方面的測試，個人認為應從以下幾點 ： a.材質問題，這涉及程序員和用戶之間的關系，兩者利益均有，程序員考慮成本問題，用戶考慮污染問 題，也 就是說制作圓珠筆的材料與環境的問題，廠商考慮價格因素，用戶考慮環境因素以及安全性因素 這就把安全性測試給說出來了，大的方面因為筆油材質的問題，和使用者之間的健康問題有聯系， 要測小 的方面，筆油的速率，以及書寫后是否馬上可以涂抹，可否修改，這都涉及安全性的問題 b. 性能問題，溫度，濕度，氣壓對筆芯產生不同的影響 3. 安全性問題 測試不同的高度，筆身做自由落體損壞程度 4. 兼容性問題 不同的筆筒和筆芯之間的互相兼容 5. 強度測試 彈簧在不同的壓力之下，承受變形的程度 6. 在金山面試時候，考官特意問我針對筆芯那個米珠如何測試 或者 1、界面測試 界面測試也就是對其外表先進行判斷。 尺寸是否適合用戶使用？用戶需要的是什么樣的尺寸，小孩和成年人使用的尺寸是有區別的； 色彩搭配是否合理？形狀是否美觀？ 是否方便攜帶和存放？ 筆芯顏色是否與客戶要求一致？ 筆身印的 logo 或者文字是否這么正確 2、功能測試 筆筒開合； 筆芯替換； 出墨快慢； 筆頭出墨粗細； 是不是可操作性簽字筆； 3、性能測試 筆芯的壽命； 筆墨的氣味； 寫過的字用紙水浸透后，筆墨是否會暈開 壓力測試：筆尖在多大壓力范圍內可以正常寫字，不能正常出墨，太重損壞筆尖或紙張； 筆殼能在多大壓力范圍內正常使用？成人用力太重掰斷筆殼，掉到地上易摔， 能在紙上寫出清晰的字 4、性能測試 握筆的地方紋路是否會硌手或太滑； 書寫的流暢度； 寫出的墨水多久能干； 高溫和低溫環境對筆芯出墨和筆殼的影響； 長時間不蓋筆套，或筆蓋蓋多長時間不用，會不會對筆下次寫字有影響 5、安全測試 筆墨是否有易燃性； 筆墨是否對皮膚有害； 筆桿折斷，材質是否容易刮傷手； 誤食筆芯是否會引起中毒（有小孩或者有人喜歡咬筆頭） 6、兼容性測試 筆殼和筆芯是否能夠很好的適應主流簽字筆尺寸； 這個筆芯的筆尖如果損壞，換上其他的筆芯的筆尖是否能用； 這個筆芯的筆墨如果用完，換上其他筆芯的筆墨是否可以使用； 筆的筆墨如果在其他筆的筆墨上寫字是否可以成功覆蓋 7、其他測試 （1）比較測試 與其他品牌簽字筆比較，優劣在哪些地方？ （2）場景測試 筆從高處摔到地上，筆尖是否會摔壞； 倒著寫，是否可以寫出很多字來； 扔到水里，筆墨會不會一直暈開； 筆在粗糙的紙上是否能寫出字… ``` </details> <br /> <details> <summary>45.測試一個網上購物的購物車 </summary> ``` 界面測試： ·打開頁面后，頁面的布局是否合理，顯示是否完整； ·鼠標浮動在購物車按鈕，迷你購物車界面顯示是否正常； ·不同賣家的商品在不同的 table 區域顯示，區分明顯； ·頁面的 tooltips 能正常顯示； 功能測試： ·所有頁面鏈接功能正常，可以點擊到正確頁面； ·頁面關聯本地軟件阿里旺旺的 icon 點擊后，能打開軟件； ·從商品信息頁面添加的商品能顯示在購物車中； ·購物車頁面打開的同時，在其他頁面添加了商品，購物車頁面刷新后，新的商品能顯示； ·若未登錄，點擊購物車，則提示用戶輸入用戶名和密碼，或者提示其他的非注冊用戶購物方式； ·商品未勾選的狀態下，結算按鈕是灰色無法點擊的； ·勾選商品后，已選商品的總價會顯示，結算按鈕變高亮可點擊工作； ·勾選商品，點擊結算按鈕后，進入確認訂單信息頁面； ·購物車頁面中，可以對添加的商品信息做信息的修改，并自動保存成功； ·賣家在線的時候，旺旺 icon 高亮，反之，灰色； ·購物車有商品降價或者庫存告急的，那么點擊對應的 tab，降價或者告急商品會歸類后顯示； ·購物車能添加的商品種類是有數量上限的； ·不要的商品，可以刪除； （其他特有的功能不做贅述，只討論常見通用功能） 若商品已經失效，購物車的商品是否可以繼續結算 已進入支付界面但支付未成功，重新進入購物車，又重新添加了一些物品，則原有的物品是否能正確保留； （感覺這個還挺關鍵，經常是沒完成支付，又添加了一些物品，最后再一起支付） 性能測試： ·打開購物車頁面要多久； 可用性測試： ·快捷鍵功能知否支持 兼容測試： ·不同瀏覽器上的測試功能是否正常； ·app 上測試 ``` </details> <br /> <details> <summary>46.請以微信點贊，功能點進行測試 </summary> ``` 1. 功能測試 考慮功能是否符合預期 2. 接口 考慮各內部和外部的接口，比如朋友圈客戶端和服務端的交互接口的功能。朋友圈點贊功能和消息提示功 能的 接口（點了贊之后對應的朋友收到提示信息） 3. 平臺 手機版 pad 版 web 版 4. 用戶操作場景 測試用戶常用場景，比如：用戶打開微信看到十條消息提示，點擊后進入朋友圈界面顯示了“誰誰誰點了贊” 5. 速度、延遲 6. 性能測試 模擬一些多用戶并發操作的場景 7. 安全 ``` </details> <br /> <details> <summary>47.搜索框怎么測</summary> 增： 搜索功能分為簡單搜索和高級搜索 簡單搜索： 先展示百度的簡單搜索界面，僅供參考：  ``` 界面測試 ·搜索框 UI 顯示正常，布局合理； ·搜索頁面布局合理，無錯別字； ·搜索出的結果展示，布局合理； ·已查看過的結果鏈接，鏈接的眼神要灰化處理，和沒有點擊過的結果鏈接區分； ·結果數量龐大時，頁面的分頁布局合理； 功能測試 ·鏈接測試：頁面上的鏈接都可連接至正確的頁面 ·搜索歷史內容記錄，便于查找檢索過的內容 ·搜索內容聯想輸入，便于用戶搜索的便捷與準確性 ·搜索功能測試（重點） ·搜索內容為空，驗證系統如何處理 ·搜索內容為空格，查看系統如何處理 ·邊界值驗證，在允許的字符串范圍內外，驗證系統的處理 ·超長字符串的輸入，系統是否會截取允許的長度來檢索結果 ·合法的字符串長度后，加空格，驗證檢索結果 ·多個關鍵詞中間加入空格，tab，逗號后，驗證系統的結果是否正確 ·驗證每種合法的輸入，結果是否正確 ·是否支持檢索內容的復制、粘貼、編輯等操作 ·是否支持回車鍵搜索 ·多次輸入相同的內容，查看系統每次檢索的結果是否正確，相同 ·特殊字符，轉義符，html 腳本等需作處理 ·敏感詞匯，提示用戶無權限等信息 ·輸入的內容，是否支持快捷鍵操作等 ·只能輸入允許的字符串長度 安全性測試（沒有做過，只能列出一些簡單的注意點） ·腳本的禁用 ·SQl 注入，檢索 sql select 語句等 ·敏感內容的檢索是禁止的 ·特殊字符的檢索 ·被刪除、加密、授權的數據，不允許被查出來的，是否有安全控制設計 兼容性測試 ·多平臺 windows，mac ·移動平臺 ios，android ·多瀏覽器 FF，Chrome，IE，國內主流瀏覽器等 性能測試 ·搜索頁面打開的速度是否滿足設計要求 ·搜索出結果消耗的時間，是否滿足設計要求 本地化測試 ·登錄時，自動切換至相應語言國家的搜索主頁 高級搜索： 先展示百度的高級搜索頁面，僅供參考： ```  場景法測試，主要是為了驗證搜索結果的正確性：  每個場景，對應了一種高級搜索活動從開始到退出搜索的完整過程 </details> <br />