1. 自動化測試碰到比較難解決的問題是什麼
有關自動化測試的誤區
目前，有些人對自動化測試的認識存在一定的誤區，因此有必要對自動化測試樹立正確的認識，以防止對其有過高的期望。
1．自動化測試工具是「萬能」的
很多人一聽到自動化測試，就認為自動化測試工具可以完成一切測試工作，從測試計劃到測試執行再到測試結果分析，都不需要任何人工干預。顯然，這是一種理想狀態，現實中還沒有哪個測試工具有這個能力，並且將來也不會有。在現實中有關的測試設計、測試案例，以及一些關鍵的測試任務還是需要人工參與的，即自動化測試是對手工測試的輔助和補充，它永遠也不可能完全取代手工測試。
2．測試工具可適用於所有的測試
每種自動化測試工具都有它的應用范圍和可用對象，所以不能認為一種自動化測試工具能夠滿足所有測試的需求。針對不同的測試目的和測試對象，應該選擇合適的測試工具來對它進行測試。在很多情況下，需要利用多種測試工具或者開發自動化測試框架才能達到自動化測試的目的。商業和開源的測試工具能夠用來進行自動化測試，但是我們需要根據自身產品的特點，開發自動化測試框架，在框架中提供常用的測試用例，加快測試速度，達到測試用例復用，這是今後測試自動化發展的道路。
3．測試工具能使工作量大幅度減少
事實上，引入自動化測試工具不會馬上減少測試工作，相反，在更多情況下，首次將自動化測試工具引入企業時，測試工作實際上變得更艱巨了。只有在正確合理地使用測試工具，並有一定的技術積累之後，測試工作量才能逐漸減輕。
4．測試工具能實現100%的測試覆蓋率
由於自動化測試可以增加測試覆蓋的深度和廣度，利用白盒測試工具可能實現語句全覆蓋、邏輯路徑全覆蓋等，但因為窮舉測試必須使用所有可能的數據，包括有效的和無效的測試數據，所以在有限的資源下也不可能進行100%的測試。
5．自動化測試工具容易使用
對於這一點，很多測試工程師有同樣的錯誤觀點，認為測試工具可以簡單地通過捕獲（錄制）客戶端操作生成腳本，且腳本不加編輯就可用於回放使用。事實上，自動化測試不是那麼簡單的，捕獲的操作是否正確，以及腳本編輯是否合理都會影響測試結果。因此，自動化測試需要更多的技能，也需要更多的培訓。
6．自動化測試能發現大量新缺陷
發現更多的新缺陷應該是手工測試的主要目的，不能期望自動化測試去發現更多新缺陷。事實上，自動化測試主要用於發現原來的缺陷。自動化測試用於回歸測試，而大量的新業務測試更多地還是依賴手工測試。
2. 自動化覆蓋率是什麼
覆蓋率是度量測試完整性的一個手段，是測試有效性的一個度量。通過已執行代碼表示，用於可靠性、穩定性以及性能的評測。測試覆蓋是對測試完全程度的評測。測試覆蓋是由測試需求和測試用例的覆蓋或已執行代碼的覆蓋表示的。建立在對測試結果的評估和對測試過程中確定的變更請求（缺陷）的分析的基礎上。
3. 自動化測試會占整個測試多大比例
目前的趨勢是用自動化測試取代人工手動測試，從而提高效率和節約成本，但是自動化前期投入比較高，所以佔比要看公司的投入情況
4. 軟體測試面試常見問題及答案是什麼
黑盒測試的優點有：
比較簡單，不需要了解程序內部的代碼及實現，與軟體的內部實現無關，從用戶角度出發，能很容易地知道用戶會用到哪些功能，會遇到哪些問題，基於軟體開發文檔，所以也能知道軟體實現了文檔中的哪些功能；在做軟體自動化測試時較為方便。
黑盒測試的缺點有：
不可能覆蓋所有的代碼，覆蓋率較低，大概只能達到總代碼量的30%，自動化測試的復用性較低。
白盒測試的優點有：
幫助軟體測試人員增大代碼的覆蓋率，提高代碼的質量，發現代碼中隱 藏的問題。
白盒測試的缺點有：
程序運行會有很多不同的路徑，不可能測試所有的運行路徑；測試基於代碼，智能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。
嚴重級別的錯誤：
影響系統整體基本流程運行的錯誤，由於某一操作造成系統死循環或伺服器崩潰的錯誤。
較嚴重：功能實現錯誤、內部計算錯誤。
一般：UI錯誤，一些易用性的錯誤或建。
5. 白盒測試各種覆蓋率分別表示什麼含義它們之間的關系
case1走ace路線，2條語句都被執行了，所以語句覆蓋率為2/2，即100%。case1走abe路線，只執行了1條語句，所以語句覆蓋率為1/2，即50%。
白盒測試時基於程序結構的邏輯驅動測試，白盒覆蓋中最常見的是邏輯覆蓋（也叫代碼覆蓋或結構化覆蓋），邏輯覆蓋包括語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋。
(5)前端自動化測試覆蓋率擴展閱讀：
注意事項：
以靜力分析結果為基礎，採用規范檢驗和動態試驗的方法進一步確認靜力分析結果，提高試驗效率和精度。
覆蓋測試是白盒測試的重要手段，可以作為測試報告中量化指標的依據。對於軟體的關鍵模塊，應該使用各種覆蓋率標准來度量代碼覆蓋率。
驗收測試階段：根據開發經驗的需求，產品能否滿足使用要求，能否達到原來的設計水平，完成的功能如何，是否符合用戶的需求，以達到預期的目的。
6. 衡量軟體測試質量的指標 測試用例覆蓋率概念
第一個問題：我想在測試之前，你需要寫一個測試計劃，其中最重要的是本次測試使用的測試方法，測試工具，測試環境使用。人事安排和進度輸出後的工件每個測試階段，也是一個風險評估。這些前的准備工作做的測試，所以測試時會更有條理。
第二個問題：質量控制的測試，我認為最好的是一個很好的測試案例的設計，所以你可以控制的覆蓋范圍的測試。
補充：如果有足夠的時間來審查設計使用的情況下，這可以提高測試的質量。然而，在實際工作中通常不能實現。 。 。 。
下面列出的在線軟測量筆試題，很多單位在筆試復制下來作為一支筆的問題的時候，我至少召開兩次會議，還有其他的問題筆，但它並沒有列出。
True或False（每題1分，12分，正確的√，錯誤╳）
1。軟體測試的目的是盡可能多地確定一個軟體缺陷。 （）
2。 Beta測試是驗收測試。 （）
3。驗收測試是由最終用戶實施。 （）
4。項目測定測試者不需要提交任何工件。 （）
五，單元測試發現，大約有80％的軟體缺陷。 （）
六個。，代碼審查是檢查源代碼模塊的設計要求。 （）
七個。，自底向上的集成需要測試人員編寫驅動程序。 （）
八個。負載測試，以驗證該系統的能力被測試到什麼程度。 （）
九個。，測試人員應堅持的原則，缺陷未修復完堅決不予通過。 （）
10。代碼評審一般由測試人員舉行。 （）
11。我們可以人為地使軟體配置的問題不存在。 （）
12。集成測試計劃，需求分析階段結束時提交。 （）
二，揮發選擇題（每題2分，10分）
1。合格的軟體驗收測試標準是：（）
A.軟體需求分析說明書中定義的所有功能已經實現，性能指標均達到要求。
B.所有測試項目無殘留的一級，二級和三級錯誤。
C.項目審批表，需求分析文檔，設計文檔和編碼來達到同樣的。
D.驗收測試是完整的工件。
2。軟體測試計劃將評估需要哪些人參加？ （）
A.項目經理
B. SQA負責人
C.負責人配置
D.試驗組
3 。在alpha測試下面的描述是：（）
A. alpha測試的需要用戶代表
B. alpha測試不需要用戶代表
C. alpha測試是系統測試的
D. alpha測試驗收測試一類
4。測試設計師職責：（）
A.測試計劃
B.設計測試用例
C.設計測試過程中，該腳本
D.評估測試活動
>
5。軟體實施活動的進入准則：（）
A.需求工件基線技術
B.詳細設計的基線
C.框架的工件的工件一直有一直基線
D.項目階段成果已經基線
三，填補空白（每空1分，24分）
1。軟體驗收測試（正式驗收測試）（非正式驗收測試和alpha測試），（公開測試）三種類型。
2。系統測試策略功能測試（性能測試），負載測試，壓力測試，可用性測試（能力測試），（強度試驗），（也被稱為兼容性測試），本地化測試（BVT測試）， （裸機試驗），（安全測試），（），（容錯試驗），（恢復試驗），（）15的方式。
3。設計系統測試計劃需要參考項目文檔（要求規范），（），和迭代計劃。
4。面向過程的系統集成策略（），（）兩種。
5個。編寫測試用例一步繪制因果圖，為五個步驟的狀態圖和因果關系圖。
四，簡答題（37分）
1。階段評估和同行評議的差異。 （4分）
2。什麼是軟體測試。 （3分）
回答：以手動或自動的方式對系統進行測試，以驗證系統是否滿足預定的功能是要弄清楚實際結果和預期結果之間的差異。
3。簡述集成測試的過程中。 （5分）
回答：單元的單元測試，模塊組合再進行測試，按照設計要求。是否有檢查的程序界面上的焦點問題。
過程：首先，集成測試的測試計劃？測試 - >測試 - 開發 - > - >測試 - 評估測試用例執行，缺陷跟蹤。
4。如何做一個文件測試？ （4分）
答：文檔測試時應注意以下幾點：觀眾的文件，術語的文檔的正確性，文件，文件的完整性，一致性的文件，文檔，易用性示例例如，語言的文件，
5。白盒測試幾種方法？ （6分）
答：白盒測試方法分為：靜態測試和動態測試
靜態測試方法：（1）編碼標准和原則（2）演練（3）審查（ 4）評估
動態測試方法：①語句覆蓋（2）確定的條件（3）蓋蓋（4）判斷 - 條件覆蓋⑤條件組合覆蓋⑥路徑覆蓋
⑦條件組合+路徑覆蓋
6。系統測試計劃需要進行同行評審，為什麼？ （4分）
答：系統測試計劃是同行評審，測試需要很長一段時間，甚至可能
免疫系統的現象，它可以是一個同行評議，減少疲勞疲勞試驗系統測試在同一系統上。
7。測試和β測試的區別。 （4分）
8。比較負載測試，容量測試和壓力測試的區別。 （6分）
9。測試結束的標準是什麼？ （3分）
7. 軟體測試中覆蓋率是什麼意思
簡單說就是測試中需要測試到的東西你測試了多少。比如：正常測試需要測試100個點，你測試了85個，說明你的測試覆蓋率為85%。覆蓋率越高測試的質量相對越好。
8. 為什麼要對程序做代碼覆蓋率測試
關於代碼覆蓋率，之前6年的工作經歷中，只是依稀聽聞過。之前的組織里，從未關注過這個指標，只是有一段時間用NUnit做了單元測試，主要是測試一些關鍵類關鍵方法是否正常，對代碼覆蓋率的印象就真的一直是停留在聽聞的程度。汗一個!
前些時日，關於自動測試的討論中有人提及到代碼覆蓋率，激發了我的好奇，到底什麼是代碼覆蓋率?最重要的是於測試工作而言有怎樣的價值呢?今天花了一點時間查了一下，有了初步的認識。大致歸納如下：
一、基本概念
代碼覆蓋率是單元測試活動任務之一;
覆蓋率分語句覆蓋率(即通常所說的行覆蓋率)和分支覆蓋率。
二、價值
代碼覆蓋率的分析能在一定程度上評判代碼質量，一般覆蓋率高的代碼出錯的幾率會相對低一些。但是高覆蓋率只是表示執行了很多的代碼，並不意味著這些代碼被很好地執行了。所以，似乎覆蓋率測試結果出來並不能幫我准確的評價代碼質量。那麼我們為什麼要做覆蓋率測試呢?如何讓它給我們帶來價值呢?
1. 盡早評估代碼質量
比如在開發的過程中，定時的去看整個項目的代碼覆蓋率，監控覆蓋報告可以幫助開發團隊迅速找出不斷增長的但是沒有相應測試的代碼。例如，在一周開始時運行覆蓋報告，顯示項目中一個關鍵的軟體包的覆蓋率是 70%。如果幾天後，覆蓋率下降到了 60%，那麼您可以推斷：軟體包的代碼行增加了，但是沒有為新代碼編寫相應的測試(或者是新增加的測試不能有效地覆蓋新代碼)。能夠監控事情的發展，無疑是件好事。定期地查閱報告使得設定目標(例如獲得覆蓋率、維護代碼行的測試案例的比例等)並監控事情的發展變得更為容易。如果您發現測試沒有如期編寫，您可以提前採取一些行動，例如對開發人員進行培訓、指導或幫助。
2. 為功能測試關注點提供情報
假設覆蓋報告在指出沒有經過足夠測試的代碼部分方面非常有效，那麼質量保證人員可以使用這些數據來評定與功能測試有關的關注區域，可以更有針對性地加強這些區域的測試，因為沒有被測試代碼覆蓋到的區域，出錯的幾率應該相對更高。
3. 估計修改已有代碼所需的時間
對一個開發團隊而言，針對代碼編寫測試案例自然可以增加集體的信心。與沒有相應測試案例的代碼相比，經過測試的代碼更容易重構、維護和增強。測試案例因為暗示了代碼在測試工作中是如何工作的，所以還可以充當內行的文檔。在另一方面，沒有經過相應測試的代碼更難於理解和安全地修改。因此，知道代碼有沒有被測試，並看看實際的測試覆蓋數值，可以讓開發人員和管理人員更准確地預知修改已有代碼所需的時間。
當然，這樣的理解還是比較淺層的，我想實際應用中除了以上三點之外，還有一個很重要的工作就是提高測試代碼的質量來更好的體現代碼覆蓋率的價值。
9. 自動化測試是軟體測試的重要手段，自動化測試有什麼優勢和手工測試有什麼不同
自動化測試相對於手工測試優點如下：
1、可以模擬人工測試，減少重復機械的測試工作量，大量用於回歸測試；
2、可以提高測試精度，例如進行大數據量的正確性校驗；
3、進行人工難以執行的測試，例如單元測試、統計測試覆蓋率等等；
4、用於模擬多線程的並發；
5、更好地利用資源。將繁瑣的任務自動化。
6、測試具有一致性和可重復性。
7、測試的復用性。由於自動測試通常採用腳本技術，領測認為這樣就有可能只需要做少量的甚至不做修改，實現在不同的測試過程中使用相同的用例。
8、增加軟體信任度。
10. 軟體測試中執行覆蓋率怎麼計算。
軟體測試覆蓋率
覆蓋率=(至少被執行一次的item數)/item的總數
語句覆蓋率=(至少被執行一次的語句數量)/(可執行的語句總數)
判定覆蓋率=(判定結果被評價的次數)/(判定結果總數)
條件覆蓋率=(條件操作數值至少被評價一次的數量)/(條件操作數值的總數)
判定條件覆蓋率=(條件操作數值或判定結果至少被評價一次的數量)/(條件操作數值總數+判定結果總數)
路徑覆蓋率=(至少被執行一次的路徑數)/(總的路徑數)
需求覆蓋率=(被驗證到的需求數量)/(總的需求數量)
繼承上下文判定覆蓋率=(累加每個上下文內執行到的判定分支數)/(上下文數*上下文內的判定分支總數)
基於狀態的上下文入口覆蓋率=(累加每個狀態內執行到的方法數)/(狀態數*類內方法總數)
函數覆蓋率=(至少被執行一次的函數數量)/(系統中函數的總數)
指令塊覆蓋率=(至少被執行的一次指令塊的數量)/(系統中指令塊總數)
DDP覆蓋率=(至少被執行的一次的判定路徑數量)/( 系統中判定路徑總數)
分支條件組合覆蓋率=(被評測到的分支條件組合數)/(分支條件組合數)
PPP覆蓋率=(至少被執行的一次的PPP數量)/( 系統中PPP總數)