前言
為了讓大家更好的理解和學習投入到Python自動化來
找到一份好的資料也是學習程序中，非常重要的一個點，你的檢索能力越強，你就會越容易找到最合適你的資料，
有需要的小伙伴可以復制群號 313782132 這里可免費領取！
暗號：博客，
一、什么是兼容性測驗？兼容性測驗側重哪些方面？
參考答案：
-
兼容測驗主要是檢查軟體在不同的硬體平臺、軟體平臺上是否可以正常的運行，即是通常說的軟體的可移植性，
-
兼容的型別，如果細分的話，有平臺的兼容，網路兼容，資料庫兼容，以及資料格式的兼容，
兼容測驗的重點是，對兼容環境的分析，通常，是在運行軟體的環境不是很確定的情況下，才需要做兼容，根據軟體運行的需要，或者根據需求檔案，一般都能夠得出用戶會在什么環境下使用該軟體，把這些環境整理成表單，就得出做兼容測驗的兼容環境了， -
兼容和配置測驗的區別在于，做配置測驗通常不是Clean OS 下做測驗，而兼容測驗多是在Clean OS 的環境下做的，
二、我現在有個程式，發現在Windows 上運行得很慢，怎么判別是程式存在問題還是軟硬體系統存在問題？
參考答案：
1、檢查系統是否有中毒的特征；
2、檢查軟體/硬體的配置是否符合軟體的推薦標準；
3、確認當前的系統是否是獨立，即沒有對外提供什么消耗CPU 資源的服務；
4、如果是C/S 或者B/S 結構的軟體，需要檢查是不是因為與服務器的連接有問題，或者訪問有問題造成的；
5、在系統沒有任何負載的情況下，查看性能監視器，確認應用程式對CPU/記憶體的訪問情況，
三、測驗的策略有哪些？
參考答案：
黑盒/白盒，靜態/動態，手工/自動，冒煙測驗，回歸測驗，公測（Beta 測驗的策略）
四、正交表測驗用例設計方法的特點是什么？
參考答案：
-
用最少的實驗覆寫最多的操作，測驗用例設計很少，效率高，但是很復雜；
-
對于基本的驗證功能，以及二次集成引起的缺陷，一般都能找出來；但是更深的缺陷，更復雜的缺陷，還是無能為力的；
-
具體的環境下，正交表一般都很難做的，大多數，只在系統測驗的時候使用此方法，
五、描述使用bugzilla 缺陷管理工具對軟體缺陷（BUG）跟蹤的管理的流程？
參考答案：
就是Bugzilla 的狀態轉換圖，
六、描述測驗用例設計的完整程序？
參考答案：
需求分析+ 需求變更的維護作業；
根據需求得出測驗需求；
設計測驗方案，評審測驗方案；
方案評審通過后，設計測驗用例，再對測驗用例進行評審
七、單元測驗的策略有哪些？
參考答案：
邏輯覆寫、回圈覆寫、同行評審、桌前檢查、代碼走查、代碼評審、景泰資料流分析
什么是并發？在lordrunner 中，如何進行并發的測驗？集合點失敗了會怎么樣？
參考答案：
在同一時間點，支持多個不同的操作，
LoadRunner 中提供IP 偽裝，集合點，配合虛擬用戶的設計，以及在多臺電腦上設定，可以比較好的模擬
真實的并發，
集合點，即是多個用戶在某個時刻，某個特定的環境下同時進行虛擬用戶的操作的，集合點失敗，則集合
點的才操作就會取消，測驗就不能進
八、QTP 中的Action 有什么作用？有幾種？
參考答案：
Action 的作用：
? 用Action 可以對步驟集進行分組
? 步驟重組，然后被整體呼叫
? 擁有自己的sheet
? 組合有相同需求的步驟，整體操作
? 具有獨立的物件倉庫
Action 的種類：
? 可復用Action
? 不可復用Action
? 外部Action
九、你所熟悉的軟體測驗型別都有哪些？請試著分別比較這些不同的測驗型別的區別與聯系（如功能測驗、性能測驗……）？
參考答案：
Compatibility Testing（兼容性測驗），也稱“Configuration testing（配置測驗）”，兼容性測驗是
將驗證軟體與其所依賴的環境的依賴程度，包括對硬體的依賴程度，對平臺軟體，其它軟體的依賴程度，來檢
查程式能正常的運行的測驗
Functional testing (功能測驗)，也稱為behavioral testing（行為測驗）或黑盒測驗，根據產品特征、操作描述和用
戶方案，測驗一個產品的特性和可操作行為以確定它們滿足設計需求，本地化軟體的功能測驗，用于驗證應用
程式或網站對目標用戶能正確作業，使用適當的平臺、瀏覽器和測驗腳本，以保證目標用戶的體驗將足夠好，
就像應用程式是專門為該市場開發的一樣，
Performance testing（性能測驗），性能測驗是指通過自動化的測驗工具模擬多種正常、峰值以
及例外負載條件來對系統的各項性能指標進行測驗
主要包括以下三個方面：
-
應用在客戶端性能的測驗
-
應用在網路上性能的測驗和應用在服務器端
-
性能的測驗
十、測驗活動中，如果發現需求檔案不完善或者不準確，怎么處理？
參考答案：
應該立即和相關人員進行協調交流，
十一、你認為做好測驗計劃作業的關鍵是什么？
參考答案：
軟體測驗計劃就是在軟體測驗作業正式實施之前明確測驗的物件，并且通過對資源、時間、風險、測驗范
圍和預算等方面的綜合分析和規劃，保證有效的實施軟體測驗；
做好測驗計劃作業的關鍵：目的，管理，規范
十二、一套完整的測驗應該由哪些階段組成？
參考答案：測驗計劃、測驗設計與開發、測驗實施、測驗評審與測驗結論
十三、單元測驗的主要內容？
模塊介面測驗、區域資料結構測驗、路徑測驗、錯誤處理測驗、邊界測驗
十四、簡述集成測驗與系統測驗關系？
（1）集成測驗的主要依據概要設計說明書，系統測驗的主要依據是需求設計說明書；
（2）集成測驗是系統模塊的測驗，系統測驗是對整個系統的測驗，包括相關的軟硬體平臺、網路以及相關外
設的測驗，
十五、軟體系統中除用戶檔案之外，檔案測驗還應該關注哪些檔案？
參考答案：
開發檔案
軟體需求說明書
資料庫設計說明書
概要設計說明書
詳細設計說明書
可行性研究報告
管理檔案
專案開發計劃
測驗計劃
測驗報告
開發進度月報
開發總結報告
十六、如何理解壓力、負載、性能測驗測驗？
參考答案：
性能測驗是一個較大的范圍，實際上性能測驗本身包含了性能、強度、壓力、負載等多方面的測驗內
容，
壓力測驗是對服務器的穩定性以及負載能力等方面的測驗，是一種很平常的測驗，
增大訪問系統的用戶數量、或者幾個用戶進行大資料量操作都是壓力測驗，而負載測驗是壓力相對較大的測驗，主要是測驗
系統在一種或者集中極限條件下的相應能力，是性能測驗的重要部分，
100 個用戶對系統進行連續半個小時的訪問可以看作壓力測驗，那么連續訪問8 個小時就可以認為負載測驗，1000 個用戶連續訪問系統
1 個小時也可以看作是負載測驗，
實際上壓力測驗和負載測驗沒有明顯的區分，測驗人員應該站在關注整體性能的高度上來對系統進行
測驗，
十七、什么是系統瓶頸？
參考答案：
瓶頸主要是指整個軟硬體構成的軟體系統某一方面或者幾個方面能力不能滿足用戶的特定業務要求，
“特定”是指瓶頸會在某些條件下會出現，因為畢竟大多數系統在投入前，
嚴格的從技術角度講，所有的系統都會有瓶頸，因為大多數系統的資源配置不是協調的，例如CPU 使
用率剛好達到100％時，記憶體也正好耗盡的系統不是很多見，
因此我們討論系統瓶頸要從應用的角度討論：關鍵是看系統能否滿足用戶需求，在用戶極限使用系統的情況下，系統的回應仍然正常，我們可以認為改系統沒有瓶頸或者瓶頸不會影響用戶作業，
因此我們測驗系統瓶頸主要是實作下面兩個目的：
-發現“表面”的瓶頸，主要是模擬用戶的操作，找出用戶極限使用系統時的瓶頸，然后解決瓶頸，這是性
能測驗的基本目標，
-發現潛在的瓶頸并解決，保證系統的長期穩定性，主要是考慮用戶在將來擴展系統或者業務發生變化時，
系統能夠適應變化，滿足用戶目前需求的系統不是最好的，我們設計系統的目標是在保證系統整個軟體
生命周期能夠不斷適應用戶的變化，或者通過簡單擴展系統就可以適應新的變化，
十八、檔案測驗主要包含什么內容？
參考答案：
在國內軟體開發管理中，檔案管理幾乎是最弱的一項，因而在測驗作業中特別容易忽略檔案測驗也就
不足為奇了，要想給用戶提供完整的產品，檔案測驗是必不可少的，檔案測驗一般注重下面幾個方面：
檔案的完整性：主要是測驗檔案內容的全面性與完整性，從總體上把握檔案的質量，例如用戶手冊應
該包括軟體的所有功能模塊，
描述與軟體實際情況的一致性：主要測驗軟體檔案與軟體實際的一致程度，例如用戶手冊基本完整
后，我們還要注意用戶手冊與實際功能描述是否一致，因為檔案往往跟不上軟體版本的更新速度，
易理解性：主要是檢查檔案對關鍵、重要的操作有無圖文說明，文字、圖表是否易于理解，對于關
鍵、重要的操作僅僅只有文字說明肯定是不夠的，應該附有圖表使說明更為直觀和明了，
檔案中提供操作的實體：這項檢查內容主要針對用戶手冊，對主要功能和關鍵操作提供的應用實體是
否豐富，提供的實體描述是否詳細，只有簡單的圖文說明，而無實體的用戶手冊看起來就像是軟體界面的
簡單拷貝，對于用戶來說，實際上沒有什么幫助，
印刷與包裝質量：主要是檢查軟體檔案的商品化程度，有些用戶手冊是簡單列印、裝訂而成，過于粗
糙，不易于用戶保存，優秀的檔案例如用戶手冊和技術白皮書，應提供商品化包裝，并且印刷精美，
十九、功能測驗用例需要詳細到什么程度才是合格的？
參考答案：
這個問題也是測驗工程師經常問的問題，有人主張測驗用例詳細到每個步驟執行什么都要寫出來，目
的是即使一個不了解系統的新手都可以按照測驗用例來執行作業，
主張這類寫法的人還可以舉出例子：
歐美、日本等軟體外包檔案都是這樣做的，另外一種觀點就是主張寫的粗些，類似于撰寫測驗大綱，
主張這種觀點的人是因為軟體開發需求管理不規范，變動十分頻繁，因而不能按照歐美的高標準來撰寫測驗用例，這樣的測驗用例容易維護，可以讓測驗執行人員有更大的發揮空間，
實際上，軟體測驗用例的詳細程度首先要以覆寫到測驗點為基本要求，舉個例子：“用戶登陸系統”
的測驗用例可以不寫出具體的執行資料，但是至少要寫出五種以上情況（），如果只用一句話覆寫了這個
功能是不合格的測驗用例，覆寫功能點不是指列出功能點，而是要寫出功能點的各個方面（如果組合情況
較多時可以采用等價劃分），
另一個影響測驗用例的就是組織的開發能力和測驗物件特點，如果開發力量比較落后，撰寫較詳細的
測驗用例是不現實的，因為根本沒有那么大的資源投入，當然這種情況很隨著團隊的發展而逐漸有所改
善，測驗物件特點重點是指測驗物件在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有
時間寫出高質量的測驗用例的，甚至有些時候測驗作業只是一種輔助作業，因而不撰寫測驗用例，
因此，測驗用例的撰寫要根據測驗物件特點、團隊的執行能力等各個方面綜合起來決定撰寫策略，最
后要注意的是測驗人員一定不能抱怨，力爭在不斷提高測驗用例撰寫水平的同時，不斷地提高自身能力，
# 二十、配置和兼容性測驗的區別是什么？
參考答案：
配置測驗的目的是保證軟體在其相關的硬體上能夠正常運行，而兼容性測驗主要是測驗軟體能否與不同的
軟體正確協作，
配置測驗的核心內容就是使用各種硬體來測驗軟體的運行情況，一般包括：
（1）軟體在不同的主機上的運行情況，例如Dell 和Apple；
（2）軟體在不同的組件上的運行情況，例如開發的撥號程式要測驗在不同廠商生產的Modem 上的運行情
況；
（3）不同的外設；
（4）不同的介面；
（5）不同的可選項，例如不同的記憶體大小；
兼容性測驗的核心內容：
（1）測驗軟體是否能在不同的作業系統平臺上兼容；
（2）測驗軟體是否能在同一作業系統平臺的不同版本上兼容；
（3）軟體本身能否向前或者向后兼容；
（4）測驗軟體能否與其它相關的軟體兼容；
（5）資料兼容性測驗，主要是指資料能否共享；
配置和兼容性測驗通稱對開發系統類軟體比較重要，例如驅動程式、作業系統、資料庫管理系統等，具
體進行時仍然按照測驗用例來執行，
二十一、軟體檔案測驗主要包含什么？
參考答案：
隨著軟體檔案系統日益龐大，檔案測驗已經成為軟體測驗的重要內容，檔案測驗物件主要如下：
-包裝文字和圖形；
-市場宣傳材料、廣告以及其它插頁；
-授權、注冊登記表；
-最終用戶許可協議；
-安裝和設定向導；
-用戶手冊；
-聯機幫助；
-樣例、示范例子和模板；
-……
檔案測驗的目的是提高易用性和可靠性，降低支持費用，因為用戶通過檔案就可以自己解決問題，因文
檔測驗的檢查內容主要如下：
-讀者物件——主要是檔案的內容是否能讓該級別的讀者理解；
-術語——主要是檢查術語是否適合讀者；
-內容和主題——檢查主題是否合適、是否丟失、格式是否規范等；
-圖示和螢屏抓圖——檢查圖表的準確度和精確度；
-樣例和示例——是否與軟體功能一致；
-拼寫和語法；
-檔案的關聯性——是否與其它相關檔案的內容一致，例如與廣告資訊是否一致；
檔案測驗是相當重要的一項測驗作業，不但要給予充分的重視，更要要認真的完成，象做功能測驗一樣來對待
檔案測驗，
二十二、沒有產品說明書和需求檔案地情況下能夠進行黑盒測驗嗎？
參考答案：
這個問題是國內測驗工程師經常遇到的問題，根源就是國內軟體開發檔案管理不規范，對變更的管理
方法就更不合理了，
實際上沒有任何檔案的時候，測驗人員是能夠進行黑盒測驗的，這種測驗方式我們可
以稱之為探索測驗，具體做法就是測驗工程師根據自己的專業技能、領域知識等不斷的深入了解測驗對
象、理解軟體功能，進而發現缺陷，
在這種做法基本上把軟體當成了產品說明書，測驗程序中要和開發人員不斷的進行交流，尤其在作項
目的時候，進度壓力比較大，可以作為加急測驗方案，最大的風險是不知道有些特性是否被遺漏，
二十三、測驗中的“殺蟲劑怪事”是指什么？
參考答案：
“殺蟲劑怪事”一詞由BorisBeizer 在其編著的《軟體測驗技術》第二版中提出，用于描述測驗人員
對同一測驗物件進行的測驗次數越多，發現的缺陷就會越來越少的現象，就像老用一種農藥，害蟲就會有
免疫力，農藥發揮不了效力，
這種現象的根本原因就是測驗人員對測驗軟體過于熟悉，形成思維定勢，
為了克服這種現象，測驗人員需要不斷撰寫新的測驗程式或者測驗用例，對程式的不同部分進行測
試，以發現更多的缺陷，也可以參考新人來測驗軟體，剛剛進來的新手往往能發現一些意想不到的問題，
二十五、在配置測驗中，如何判斷發現的缺陷是普通問題還是特定的配置問題？
參考答案：
在進行配置測驗時，測驗工程師仍然會發現一些普通的缺陷，也就是與配置環境無關的缺陷，因此判
斷新發現的問題，需要在不同的配置中重新執行發現軟體缺陷的步驟，如果軟體缺陷不出現了，就可能是
配置缺陷；如果在所有的配置中都出現，就可能是普通缺陷，
需要注意的是，配置問題可以在一大類配置中出現，例如，撥號程式可能在所有的外置Modem 中都存
在問題，而內置的Modem 不會有任何問題，
二十六、為什么盡量不要讓時間有富裕的員工去做一些測驗？
參考答案：
表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測驗的輕視，測驗和測驗的人有
很大關系，測驗作業人員應該是勤奮并富有耐心，善于學習、思考和發現問題，細心有條理，總結問題，
如果具備這樣的優點，做其它作業同樣也會很出色，因此這里還有一個要求，就是要喜歡測驗這項作業，
如果他是專職的，那么肯定更有經驗和信心，國內的小伙子好象都喜歡做程式員，兩者作業性質不同，待
遇不同，地位不同，對自我實作的價值的認識也不同，這是行業的一個需要改善的問題，如果只是為了完
成任務而完成任務，或者發現了幾個問題就覺得滿意了，這在任何其它作業中都是不行的，
二十七、軟體測驗的風險主要體現在哪里？
參考答案：
我們沒有對軟體進行完全測驗，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測驗的部分，
舉個例子，程式員為了方便，在除錯程式時會彈出一些提示資訊框，而這些提示只在某種條件下會彈出，
碰巧程式發布前這些代碼中的一些沒有被注釋掉，在測驗時測驗工程師又沒有對其進行測驗，如果客戶碰
到它，這將是代價昂貴的缺陷，因為交付后才被客戶發現，
因此，我們要盡可能的選擇最合適的測驗量，把風險降低到最小，
二十八、發現的缺陷越多，說明軟體缺陷越多嗎？
參考答案：
這是一個比較常見的現象，測驗工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個后，會接
二連三的發現很多缺陷，頗有個人成就感，其中的原因主要如下：
-代碼復用、拷貝代碼導致程式員容易犯相同的錯誤，類的繼承導致所有的子類會包含基類的錯誤，反復
拷貝同一代碼意味可能也復制了缺陷，
-程式員比較勞累是可以導致某些連續撰寫的功能缺陷較多，程式員加班是一種司空見慣的現象，因此體
力不只時容易撰寫一些缺陷較多的程式，而這些連續潛伏缺陷恰恰時測驗工程師大顯身手的地方，
“缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象，如果軟體撰寫的比較好，這種現象
就不常見了，測驗人員只要嚴肅認真的測驗程式就可以了，
二十九、發現的缺陷越多，說明軟體缺陷越多嗎？
參考答案：
這是一個比較常見的現象，測驗工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個后，會接
二連三的發現很多缺陷，頗有個人成就感，其中的原因主要如下：
-代碼復用、拷貝代碼導致程式員容易犯相同的錯誤，類的繼承導致所有的子類會包含基類的錯誤，反復
拷貝同一代碼意味可能也復制了缺陷，
-程式員比較勞累是可以導致某些連續撰寫的功能缺陷較多，程式員加班是一種司空見慣的現象，因此體
力不只時容易撰寫一些缺陷較多的程式，而這些連續潛伏缺陷恰恰時測驗工程師大顯身手的地方，
“缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象，如果軟體撰寫的比較好，這種現象
就不常見了，測驗人員只要嚴肅認真的測驗程式就可以了，
三十、所有的軟體缺陷都能修復嗎？所有的軟體缺陷都要修復嗎？
參考答案：
從技術上講，所有的軟體缺陷都是能夠修復的，但是沒有必要修復所有的軟體缺陷，測驗人員要做的
是能夠正確判斷什么時候不能追求軟體的完美，對于整個專案團隊，要做的是對每一個軟體缺陷進行取
舍，根據風險決定那些缺陷要修復，發生這種現象的主要原因如下：
-沒有足夠的時間資源，在任何一個專案中，通常情況下開發人員和測驗人員都是不夠用的，而且在
專案中沒有預算足夠的回歸測驗時間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力
下，必須放棄某些缺陷的修改，
-有些缺陷只是特殊情況下出現，這種缺陷處于商業利益考慮，可以在以后升級中進行修復，
-不是缺陷的缺陷，我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以后有時
間時考慮再處理，
最后要說的是，缺陷是否修改要由軟體測驗人員、專案經理、程式員共同討論來決定是否修復，不同
角色的人員從不同的角度來思考，以做出正確的決定，
如果你
①從事功能測驗，想進階自動化測驗
②在測驗界混了1、2年，依然不會敲代碼
③面試大廠卻屢屢碰壁
我邀你進群吧！來吧~~測驗員，313782132（Q群里有技術大牛一起交流分享，學習資源的價值取決于你的行動，莫做“收藏家”）獲取更多大廠技術、面試資料
如果對python自動化測驗、web自動化、介面自動化、移動端自動化、面試經驗交流等等感興趣的測驗人，可以關注微信公眾號：【傷心的辣條】，獲取軟體測驗工程師大廠面試資料！
最后：
凡事要趁早，特別是技術行業，一定要提升技術功底，豐富自動化專案實戰經驗，這對于你未來幾年職業規劃，以及測驗技術掌握的深度非常有幫助，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/237462.html
標籤：其他
上一篇：基于excel實作介面自動化測驗