A:●創建測試計劃,肯定測試標準和測試範圍 測試面試寶典 程序員
●設計典型場景的測試用例,覆蓋經常使用業務流程和不經常使用的業務流程等。面試
●根據測試用例,開發自動測試腳本和場景數據庫
●錄製測試腳本:新建一個腳本(Web/HTML協議);點擊錄製按鈕,在彈出的對話框的URL中輸入」about:blank」;在打開的瀏覽器中進行正常操做流程後,結束錄製;調試腳本並保存,可能要注意到字符集的關聯。瀏覽器
●設置測試場景:針對性能設置測試場景,主要判斷在正常狀況下,系統的平均事務響應時間是否達標;針對壓力負載設置測試場景,主要判斷在長時間處於滿負荷或者超出系統承載能力的條件下,系統是否會崩潰;執行測試,獲取測試結果,分析測試結果。安全
A:軟件是計算機系統中與硬件相互依存的另外一部分,與計算機系統操做有關的計算機程序、規程、規則,以及可能有的文件、文檔及數據。網絡
軟件複用(SoftWare Reuse)是將已有軟件的各類有關知識用於創建新的軟件,以縮減軟件開發和維護的花費。軟件複用是提升軟件生產力和質量的一種重要技術。早期的軟件複用主要是代碼級複用,被複用的知識專指程序,後來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、代碼和文檔等一切有關方面。工具
能夠被複用的軟件成分通常稱做可複用構件。性能
A:軟件生存週期(Software life cycle)又稱爲軟件生命期,生存期。是指從造成開發軟件概念起,所開發的軟件使用之後,知道失去使用價值消亡爲止的整個過程。通常來講,整個生存週期包括計劃(定義)、開發、運行(維護)三個時期,每一個時期又劃分爲若干個階段。每一個階段有明確的任務。單元測試
週期模型(典型的幾種):學習
●瀑布模型:
快速原型模型:快速原型模型容許在需求分析階段對軟件的需求進行初步而非徹底的分析和定義,快速設計開發出軟件系統的原型,該原型向用戶展現待開發軟件的所有或部分功能和性能;用戶對該原型進行測試評定,給出具體改進意見以豐富細化軟件需求;開發人員據此對軟件進行修改完善,直至用戶滿意承認以後,進行軟件的完整實現及測試、維護。
●迭代模型:
迭代包括產生產品發佈(穩定、可執行的產品版本)的所有開發活動和要使用該發佈必需的全部其餘外圍元素。在某種程度上,開發迭代是一次 完整地通過全部工做流程的過程:需求分析、設計、實施和測試工做流程。實質上,它相似小型的瀑布式項目。RUP認爲,全部的階段均可以細分爲迭代。每一次 的迭代都會產生一個能夠發佈的產品,這個產品是最終產品的一個子集。
生命週期階段:
軟件計劃與可行性分析
需求分析
軟件設計
編碼
軟件測試
運行與維護 測試面試寶典
A:在規定的條件下對程序進行操做,以發現程序錯誤,衡量軟件質量,並對其是否能知足設計要求進行評估的過程。
軟件測試的目的:
測試是程序的執行過程,目的在於發現錯誤
一個成功的測試用例在於發現至今未發現的錯誤
一個成功的測試是發現了至今未發現的錯誤的測試
確保產品完成了它所承諾或公佈的功能,而且用戶能夠訪問到的功能都有明確的書面說明。
確保產品知足性能和效率的要求
確保產品是健壯的和適應用戶環境的
軟件測試的原則:
測試用例中一個必須部分是對預期輸出或接過進行定義
程序員應避免測試本身編寫的程序
編寫軟件的組織不該當測試本身編寫的軟件
應當完全檢查每一個測試的執行結果
測試用例的編寫不只應當根據有效和預料到的輸入狀況,並且也應當根據無效和未預料到的輸入狀況
檢查程序是否「未作其應該作的」僅是測試的一半,測試的另外一半是檢查程序是否「作了其不該該作的」
應避免測試用例用後即棄,除非軟件自己就是個一次性的軟件
計劃測試工做時不該默許假定不會發現錯誤
程序某部分存在更多錯誤的可能性,與該部分已經發現錯誤的數量成正比
軟件測試是一項極富創造性,極具智力的挑戰性的工做。
A:軟件配置管理(Software Configuration Management,SCM)是一種標識、組織和控制修改的技術。軟件配置管理應用於整個軟件工程過程。在軟件創建時變動是不可避免的,而變動加重了項目中軟件開發者之間的混亂。SCM活動的目標就是爲了標識變動、控制變動、確保變動正確實現並向其餘有關人員報告變動。從某種角度講,SCM是一種標識、組織和控制修改的技術,目的是使錯誤降爲最小並最有效地提升生產效率。
軟件配置包括以下內容:配置項識別、工做空間管理、版本控制、變動控制、狀態報告、配置審計
A:歸納地說,軟件質量就是「軟件與明確的和隱含的定義的需求相一致的程度」。具體地說,軟件質量是軟件符合明確敘述的功能和性能需求、文檔中明確描述 的開發標準、以及全部專業開發的軟件都應具備的隱含特徵的程度。影響軟件質量的主要因素,這些因素是從管理角度對軟件質量的度量。可劃分爲三組,分別反應用戶在使用軟件產品時的三種觀點。正確性、健壯性、效率、完整性、可用性、風險(產品運行);可理解性、可維修性、靈活性、可測試性(產品修改);可移植性、可再用性、互運行性(產品轉移)。
A:白盒測試:邏輯覆蓋、循環覆蓋、基本路徑覆蓋
黑盒測試:邊界值分析法、等價類劃分、錯誤猜想法、因果圖法、狀態圖法、測試大綱法、隨機測試、場景法
A:軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不一樣測試策略也不一樣。 測試面試寶典
用戶認證安全的測試要考慮問題: 明確區分系統中不一樣用戶權限 、系統中會不會出現用戶衝突 、系統會不會因用戶的權限的改變形成混亂 、用戶登錄密碼是不是可見、可複製 、是否能夠經過絕對途徑登錄系統(拷貝用戶登錄後的連接直接進入系統)、用戶退出系統後是否刪除了全部鑑權標記,是否可使用後退鍵而不經過輸入口令進入 系統 、系統網絡安全的測試要考慮問題 、測試採起的防禦措施是否正確裝配好,有關係統的補丁是否打上 、模擬非受權攻擊,看防禦系統是否堅固 、採用成熟的網絡漏洞檢查工具檢查系統相關漏洞(即用最專業的黑客攻擊工具攻擊試一下,如今最經常使用的是 NBSI 系列和 IPhacker IP ) 、採用各類木馬檢查工具檢查系統木馬狀況 、採用各類防外掛工具檢查系統各組程序的外掛漏洞.
數據庫安全考慮問題: 系統數據是否機密(好比對銀行系統,這一點就特別重要,通常的網站就沒有過高要求)、系統數據的完整性(我剛剛結束的企業實名覈查服務系統中就曾存在數據 的不完整,對於這個系統的功能實現有了障礙) 、系統數據可管理性 、系統數據的獨立性 、系統數據可備份和恢復能力(數據備份是否完整,能否恢復,恢復是否能夠完整)
A:爲實施測試而向被測試系統提供的輸入數據、操做或各類環境設置以及指望結果的一個特定的集合。
測試腳本是爲了進行自動化測試而編寫的腳本。
測試腳本的編寫必須對應相應的測試用例。
A:●靜態測試是不運行程序自己而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。
●動態測試是實際運行被測程序,輸入相應的測試實例,檢查運行結果與預期結果的差別,斷定執行結果是否符合要求,從而檢驗程序的正確性、可靠性和有效性,並分析系統運行效率和健壯性等性能。
●黑盒測試通常用來確認軟件功能的正確性和可操做性,目的是檢測軟件的各個功能是否能得以實現,把被測試的程序看成一個黑盒,不考慮其內部結構,在知道該程序的輸入和輸出之間的關係或程序功能的狀況下,依靠軟件規格說明書來肯定測試用例和推斷測試結果的正確性。
●白盒測試根據軟件內部的邏輯結構分析來進行測試,是基於代碼的測試,測試人員經過閱讀程序代碼或者經過使用開發工具中的單步調試來判斷軟件的質量,通常黑盒測試由項目經理在程序員開發中來實現。
●α測試是由一個用戶在開發環境下進行的測試,也能夠是公司內部的用戶在模擬實際操做環境下進行的受控測試,Alpha測試不能由程序員或測試員完成。
●β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者一般不在測試現場,Beta測試不能由程序員或測試員完成。
A:SQA由一套軟件工程過程和方法組成,以保證(軟件的)質量。SQA貫穿整個軟件開發過程,(它)應包括需求文檔評審、代碼控制、代碼評審、變動管理、配置管理、版本管理和軟件測試。
軟件質量保證(SQA-Software Quality Assurance)是創建一套有計劃,有系統的方法,來向管理層保證擬定出的標準、步驟、實踐和方法可以正確地被全部項目所採用。軟件質量保證的目的是使軟件過程對於管理人員來講是可見的。它經過對軟件產品和活動進行評審和審計來驗證軟件是合乎標準的。軟件質量保證組在項目開始時就一塊兒參與創建計劃、標準和過程。這些將使軟件項目知足機構方針的要求。
A:功能性:適應性、準確性、互操做性、依從性、安全性。
可靠性:成熟性、容錯性、易恢復性。
可以使用性:易理解性、易學習性、易操做性。
效率:時間特性、資源特性。
可維護性:易分析性、易變動性、穩定性、易測試性。
可移植性:適應性、易安裝性、遵循性、易替換性
A:軟件測試策略:在必定的軟件測試標準、測試規範的指導下,依據測試項目的特定環境約束而規定的軟件測試的原則、方式、方法的集合。
A:和開發過程相對應,測試過程會依次經歷單元測試、集成測試、系統測試、驗收測試 測試面試寶典
四個主要階段:
●單元測試:單元測試是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工做,一般由開發人員進行
●集成測試:集成測試是將模塊按照設計要求組裝起來進行測試,主要目的是發現與接口有關的問題。因爲在產品提交到測試部門前,產品開發小組都要進行聯合調試,所以在大部分企業中集成測試是由開發人員來完成的。
●系統測試:系統測試是在集成測試經過後進行的,目的是充分運行系統,驗證各子系統是否都能正常工做並完成設計的要求。它主要由測試部門進行,是測試部門最大最重要的一個測試,對產品的質量有重大的影響。
●驗收測試:驗收測試以需求階段的《需求規格說明書》爲驗收標準,測試時要求模擬實際用戶的運行環境。對於實際項目能夠和客戶共同進行,對於產品來講就是最後一次的系統測試。測試內容爲對功能模塊的全面測試,尤爲要進行文檔測試。
單元測試測試策略:
自頂向下的單元測試策略:比孤立單元測試的成本高不少,不是單元測試的一個好的選擇。
自底向上的單元測試策略:比較合理的單元測試策略,但測試周期較長。
孤立單元測試策略:最好的單元測試策略。
集成測試的測試策略:
大爆炸集成:適應於一個維護型項目或被測試系統較小
自頂向下集成:適應於產品控制結構比較清晰和穩定;高層接口變化較小;底層接口未定義或常常可能被修改;產口控制組件具備較大的技術風險,須要儘早被驗證;但願儘早能看到產品的系統功能行爲。
自底向上集成:適應於底層接口比較穩定;高層接口變化比較頻繁;底層組件較早被完成。
基於進度的集成
優勢:具備較高的並行度;可以有效縮短項目的開發進度。
缺點:樁和驅動工做量較大;有些接口測試不充分;有些測試重複和浪費。
系統測試的測試策略:
數據和數據庫完整性測試;功能測試;用戶界面測試;性能評測;負載測試;強度測試;容量測試;安全性和訪問控制測試;故障轉移和恢復測試;配置測試;安裝測試;加密測試;可用性測試;版本驗證測試;文檔測試
A:單元測試階段:各獨立單元模塊在與系統地其餘部分相隔離的狀況下進行測試,單元測試針對每個程序模塊進行正確性校驗,檢查各個程序模塊是否正確地實現了規定的功能。生成單元測試報告,提交缺陷報告。
集成測試階段:集成測試是在單元測試的基礎上,測試在將全部的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程當中各部分工做是否達到或實現相應技術指標及要求的活動。該階段生成集成測試報告,提交缺陷報告。
系統測試階段:將經過確認測試的軟件,做爲整個給予計算機系統的一個元素,與計算機硬件、外設、某些支持軟件、數據和人員等其餘系統元素結合在一塊兒,在實際運行環境下,對計算機系統進行全面的功能覆蓋。該階段須要提交測試總結和缺陷報告。
A:一、儘量早的找出系統中的Bug;
二、避免軟件開發過程當中缺陷的出現;
三、衡量軟件的品質,保證系統的質量;
四、關注用戶的需求,並保證系統符合用戶需求。 測試面試寶典
總的目標是:確保軟件的質量。