1. <tt id="5hhch"><source id="5hhch"></source></tt>
    1. <xmp id="5hhch"></xmp>

  2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

    <rp id="5hhch"></rp>
        <dfn id="5hhch"></dfn>

      1. 軟件測試面試筆試題完全版

        時間:2023-04-06 18:19:06 筆試題目 我要投稿
        • 相關推薦

        軟件測試面試筆試題完全版

          一、測試總體

        軟件測試面試筆試題完全版

          1. 什么是軟件測試?

          答:為了發現程序中的錯誤而執行程序的過程

          2. 軟件測試的目的?

          答:首先,測試并不僅僅是為了要找出錯誤。通過分析錯誤產生的原因和錯誤的分布特征,可以幫助項目管理者發現當前所采用的軟件過程的缺陷,以便改進。同時,這種分析也能幫助我們設計出有針對性地檢測方法,改善測試的有效性。

          其次,沒有發現錯誤的測試也是有價值的,完整的測試是評定測試質量的一種方法。詳細而嚴謹的可靠性增長模型可以證明這一點。

          測試的目的是按照用戶所需軟件的質量,檢查開發軟件過程出現的bug, 使得開發人員及時修改,可以避免在開發結束的時候發現軟件存在質量問題,避免公司不必要的損失。贏得用戶對公司產品的認可。

          測試的目的是以最少人力、物力和時間找出軟件中潛在各種錯誤和缺陷,通過修正種錯誤和缺陷提高軟件質量,回避軟件發布后由于潛在的軟件缺陷和錯誤造成的隱患帶來的商業風險。

          測試的附帶收獲是,它能夠證明軟件的功能和性能與需求說明相符合。實施測試收集到的測試結果數據為可靠性分析提供了依據。測試不能表明軟件中不存在錯誤,它只能說明軟件中存在錯誤。

          3. 軟件測試的目標

          答:發現盡可能多的錯誤。測試是一個為了尋找錯誤而運行程序的過程。一個好的測試案例是指很可能找到迄今為止尚未發現的錯誤的用例。一個成功的測試是指揭示了迄今為止尚未發現的錯誤的測試。

          4. 軟件測試的原則

          1) 應當把"盡早地和不斷地進行軟件測試"作為軟件開發者的座右銘。

          2) 測試用例應由測試輸入數據和對應的預期輸出結果這兩部分組成。

          3) 程序員應避免檢查自己的程序。

          4) 在設計測試用例時,應包括合理的輸入條件和不合理的輸入條件。

          5) 軟件測試的原則

          6) 充分注意測試中的群集現象。經驗表明,測試后程序中殘存的錯誤數目與該程序中已發現的錯誤數目成正比。

          7) 嚴格執行測試計劃,排除測試的隨意性。

          8) 應當對每一個測試結果做全面檢查。

          9) 妥善保存測試計劃,測試用例,出錯統計和最終分析報告,為維護提供方便。

          5. 測試的職責

          測試經理:

          1、制定測試計劃。

          2、確保測試過程正常進行。

          測試工程師

          1、編寫測試用例

          2、搭建測試環境

          3、執行測試

          6. 軟件都有多少種分類?

          答:根據功能的不同,電腦軟件可以粗略地分成四個層次:

          最貼近電腦硬件的是一些小巧的軟件。它們實現一些最基本的功能,通常"固化"在只讀存儲器芯片中,因此稱為固件。

          系統軟件包括操作系統和編譯器軟件等。系統軟件和硬件一起提供一個"平臺"。它們管理和優化電腦硬件資源的使用。

          支持軟件。包括圖形用戶界面、軟件開發工具、軟件評測工具、數據庫管理系統、中間件等。

          應用軟件種類最多,包括辦公軟件、電子商務軟件、通信軟件、行業軟件,游戲軟件等等。

          7. 測試的主要方面

          答:A、功能測試:a、鏈接測試b、表單測試c、Cookies 測試d、設計語言測試e、數據庫測試

          B、性能測試:a、連接速度測試b、負載測試c、壓力測試

          C、接口測試:a、服務器接口b、外部接口c、錯誤處理

          D、可用性測試: a、導航測試b、圖形測試c、內容測試d、整體界面測試

          E、兼容性測試:a、平臺測試b、瀏覽器測試c、視頻測試d、Modem/連接速率測試f、打印機測試g、組合測試

          F、安全測試:a、目錄設置b、登錄c、Session d、日志文件e、加密f、安全漏洞

          G、代碼合法性測試:a、程序代碼合法性檢查b、顯示代碼合法性檢查

          H、文檔測試:

          8. 軟件測試的對象

          答:軟件測試并不等于程序測試。軟件測試應貫穿于軟件定義與開發的整個期間。需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔,包括需求規格說明、概要設計規格說明、詳細設計規格說明以及源程序,都應成為軟件測試的對象

          9. 什么是"測試案例"?

          答:測試案例是一份文檔,它描述了一個輸入、反應、或者是與其相應的預期的響應,以便來判斷應用軟件的工作是否正常。測試案例應當包括測試標識、測試案例的名稱、目標、測試條件/設置、輸入數據要求、步驟、以及預期的結果。

          注:開發一個應用軟件的測試案例的過程,需要全面、深入地考慮該軟件的操作,所以有助于發現在其需求或設計里面的問題。因此,如果有可能,在開發周期中應當盡早準備測試案例。

          10. 怎么編寫案例?

          答:案例的編寫與測試階段的定義有很大的關系。系統測試和unit 測試的案例可能不同?傮w而言測試案例根據系統的需求而定。

          11. 軟件測試的兩種方法

          答:黑盒測試和白盒測試

          黑盒:這種方法是把測試對象看做一個黑盒子,測試人員完全不考慮程序內部的邏輯結構和內部特性,只依據程序的需求規格說明書,檢查程序的功能是否符合它的功能說明。黑盒測試又叫做功能測試或數據驅動測試。

          白盒:此方法把測試對象看做一個透明的盒子,它允許測試人員利用程序內部的邏輯結構及有關信息,設計或選擇測試用例,對程序所有邏輯路徑進行測試。通過在不同點檢查程序的狀態,確定實際的狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。

          12. 測試結束的標準是什么?

          答:1.用例全部執行。2.覆蓋率達到標準。3.缺陷率達到標準。4.其他指標達到質量標準

          13. 軟件的生命周期

          答:軟件生命周期是指一個計算機軟件從功能確定、設計,到開發成功投入使用,并在使用中不斷地修改、增補和完善,直到停止該軟件的使用的全過程(從醞釀到廢棄的過程)

          14. 什么是軟件的生命周期?

          生命周期從收到應用軟件開始算起,到該軟件不再使用為止。它有如下各方面的內容:

          初始構思、需求分析、功能設計、內部設計、文檔計劃、測試計劃、文檔準備、集成、測試、維護、升級、再測試、逐步淘汰(phase-out)、等等。

          15. 軟件測試按過程分為三個步驟

          答:單元測試:單元測試又稱模塊測試,是針對軟件設計的最小單位─ 程序模塊,進行正確性檢驗的測試工作。其目的在于發現各模塊內部可能存在的各種差錯。

          單元測試需要從程序的內部結構出發設計測試用例。多個模塊可以平行地獨立進行單元測試。

          集成測試:在運行(可能是不完整)的應用中保證軟件單元被結合后能正常操作的測試執行的階段

          系統測試:當應用作為整體運行時的測試執行階段

          16. 面向對象的設計如何影響測試?

          答:好的面向對象的工程設計使得從代碼追溯內部設計、再到功能測試,最后追溯到需求,成為一件容易的事。因為它對黑盒測試的影響很少(不需要了解應用軟件的內部設計) ,而白盒測試只需針對該應用軟件的對象。如果該應用軟件設計得好,就可簡化測試設計。

          17. 軟件帶來錯誤的原因很多。主要的原因有哪些?

          1) 交流不夠、交流上有誤解或者根本不進行交流

          2) 軟件復雜性

          3) 程序設計錯誤

          4) 需求變化

          5) 時間壓力

          6) 代碼文檔貧乏

          7) 軟件開發工具

          18. 軟件測試的步驟是什么?

          1) 測試過程按4 個步驟進行,即單元測試(Unit Testing)、集成測試(Integrated Testing)、確認測試(Validation Testing)和系統測試(System Testing)及發版測試。

          2) 開始是單元測試,集中對用源代碼實現的每一個程序單元進行測試,檢查各個程序模塊是否正確地實現了規定的功能。

          3) 集成測試把已測試過的模塊組裝起來,主要對與設計相關的軟件體系結構的構造進行測試。

          4) 確認測試則是要檢查已實現的軟件是否滿足了需求規格說明中確定了的各種需求,以及軟件配置是否完全、正確。

          19. 如何錄制測試腳本?

          1) 新建一個腳本(Web/HTML 協議)

          2) 點擊錄制按鈕,在彈出的對話框的URL 中輸入"about:blank"。

          3) 在打開的瀏覽器中進行正常操作流程后,結束錄制。

          4) 調試腳本并保存?赡芤⒁獾阶址年P聯。

          5) 設置測試場景

          6) 針對性能設置測試場景,主要判斷在正常情況下,系統的平均事務響應時間是否達標

          7) 針對壓力負載設置測試場景,主要判斷在長時間處于滿負荷或者超出系統承載能力的條件下,系統是否會崩潰

          20. 完全測試是不可能的,必須對測試的各項進行等價劃分。

          1.概念

          等價分配:軟件有無限的測試案例,我們要想辦法把軟件的相似輸入、輸出、操作分成一組,來使無限的測試案例減小到同樣有效的小范圍,這個過程稱為等價分配。

          邊界條件:軟件計劃的操作界限所在的邊緣條件,即如果超出這個邊界條件,就可能會引出錯誤。

          2 原因

          輸入量太大

          輸出結果太多

          軟件實現途徑太多

          軟件說明書沒有客觀標準。從不同的角度看,軟件缺陷的標準不同。

          3 方法

          (1)數據測試:

          1) 確定輸入的邊界條件,對邊界線上的及邊界線兩邊的數據進行測試;

          2) 邊界線可能是2 的乘方,默認值、空白值、零值等;每一個軟件測試問題各不相同,

          可能包含格式各樣邊界的不同數據。

          (2)狀態測試(軟件的狀態是指軟件當前所處的情況或者模式)

          1) 每種狀態至少訪問一次;

          2) 測試看起來最常見最普遍的狀態轉換;

          3) 測試狀態之間最不常用的分支;

          4) 測試所有錯誤狀態及其返回值;

          5) 測試隨機狀態轉換。

          21. 應該考慮進行如何測試的測試方法

          黑盒測試(Black box testing) ── 不考慮內部設計和代碼,根據需求和功能進行測試。

          白盒測試(White box testing) ── 根據應用軟件的代碼的內部邏輯,按照代碼的語句、分支、路徑和條件進行測試。

          功能測試(functional testing)--對一個應用軟件的功能模塊進行黑盒測試。這種測試應當由測試人員進行。但這并不意味著程序員在推出軟件之前不進行代碼檢查。(這一原則適用于所有的測試階段。)

          系統測試── 針對全部需求說明進行黑盒測試,包括系統中所有的部件。

          回歸測試(regression testing) ── 每當軟件經過了整理、修改、或者其環境發生變化,都重復進行測試。很難說需要進行多少次回歸測試,特別是是到了開發周期的最后階段。進行此種測試,特別適于使用自動測試工具。

          負荷試驗(load testing) ── 在大負荷條件下對應用軟件進行測試。例如測試一個網站在不同負荷情況下的狀況,以確定在什么情況下系統響應速度下降或是出現故障。

          壓力測試(stress testing) ── 經常可以與"負荷測試"或"性能測試"相互代替。這種測試是用來檢查系統在下列條件下的情況:在非正常的巨大負荷下、某些動作和輸入大量重復、輸入大數、對數據庫進行非常復雜的查詢,等等。

          性能測試(performance testing) ── 經?梢耘c"壓力測試"或"負荷測試"相互代替。理想的"性能測試"(也包括其他任何類型的測試) 都應在質量保障和測試計劃的文檔終予以規定。

          可用性測試(usability testing) ── 是專為"對用戶友好"的特性進行測試。這是一種主觀的感覺,取決于最終用戶或顧客?梢赃M行用戶會見、檢查、對用戶會議錄像、或者使用其他技術。程序員和測試人員通常不參加可用性測試。

          安裝/卸載測試(install/uninstall testing) ── 對安裝/卸載進行測試(包括全部、部分、升級操作)。

          安全測試(security testing) ── 測試系統在應付非授權的內部/外部訪問、故意的損壞時的防護情況。這需要精密復雜的測試技術。

          兼容性測試(compatability testing) ── 測試在特殊的硬件/軟件/操作系統/網絡環境下的軟件表現。

          α 測試(alpha testing) ── 在開發一個應用軟件即將完成時所進行的測試。此時還允許有較小的設計修改。通常由最終用戶或其他人進行這種測試,而不是由程序員和測試人員來進行。

          β 測試(beta testing) ── 當開發和測試已基本完成,需要在正式發行之前最后尋找毛病而進行的測試。通常由最終用戶或其他人進行這種測試,而不是由程序員和測試人員來進行。

          22. 怎樣估計測試工作量?

          效率假設:即測試隊伍的工作效率。對于功能測試,這主要依賴于應用的復雜度,

          窗口的個數,每個窗口中的動作數目。對容量測試,主要依賴于建立測試所需數據的工作量大小。

          測試假設:為了驗證一個測試需求所需測試動作數目。

          應用的維數:應用的復雜度指標。例如要加入一個記錄,測試需求的維數就是這個記錄中域的數目。

          所處測試周期的階段:有些階段主要工作都在設計,有些階段主要是測試執行。

          23. 測試設計的問題

          1) 不做測試設計,測試過程也是胡亂建立的。

          2) 測試設計不詳細,不是基于可量度的測試策略,例如測試計劃覆蓋一個集合或者測試需求的一個子集。

          3) 測試過程沒有采用最好的技術來檢驗Windows C/S 結構的測試需求

          4) 測試用例的選擇規則

          5) 選擇與測試需求的實質部分最相關的測試用例。

          6) 選擇的測試用例應該不容易應用程序的改變的影響。

          24. 當測試過程發生錯誤時,有哪幾種解決辦法?

          1) 跳轉到別的測試過程

          2) 調用一個能夠清除錯誤的過程

          3) 退出過程,啟動另一個

          4) 退出過程和應用程序,重新啟動啟動Windows,在失敗的地方重新開始測試

          25. 測試執行的問題

          1) 自動化測試沒有有效的利用,使得手工測試太多。

          2) 測試結果的捕獲沒有系統性,而且沒有查看或調查

          3) 缺陷報告必須用手工加入缺陷跟蹤系統

          錯誤分類

          1、測試用例失敗

          正常錯誤

          2、腳本命令失敗

          當測試過程不能不能執行錄制過程中的某個功能時,回產生這種錯誤,如鼠標單擊按鈕或選擇菜單項等。它也能指示是缺陷還是測試過程的設計問題。

          3、致命錯誤

          導致測試停止,這種情況最好重起Windows。

          具體步驟:

          1) 建立測試系統

          2) 準備測試過程

          3) 運行初始化過程

          4) 執行測試

          5) 從終止的測試恢復

          6) 驗證預期結果

          7) 調查突發結果

          8) 記錄缺陷日記

        【軟件測試面試筆試題完全版】相關文章:

        軟件測試面試題11-06

        軟件測試英文面試題07-26

        軟件測試 試題12-12

        軟件測試類英文面試題08-08

        軟件測試面試02-16

        軟件測試筆試題11-03

        軟件測試筆試題目12-11

        軟件測試筆試題及答案02-10

        軟件測試筆試題201511-24

        中興軟件測試筆試題11-02

        国产高潮无套免费视频_久久九九兔免费精品6_99精品热6080YY久久_国产91久久久久久无码

        1. <tt id="5hhch"><source id="5hhch"></source></tt>
          1. <xmp id="5hhch"></xmp>

        2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

          <rp id="5hhch"></rp>
              <dfn id="5hhch"></dfn>