【文章內容簡介】 性能、可靠性和內存使用之間存在著平衡關系。需求是否可測？對于軟件測試人員來說判斷需求是否可測是這個過程中最重要的工作。十一、需求測試方法復查review走查walkthrough審查inspection十二、測試策略的內容確定測試范圍 軟件是無法被完全測試的確定測試方法 不同的系統(tǒng)需要不同的測試方法定義測試標準 入口標準，暫停和繼續(xù)的標準，出口標準等十三、軟件測試結束的標準基于測試用例的使用規(guī)則1)構造測試用例（由相關人員進行評審）2)執(zhí)行測試用例中，當測試用例的不通過率達到20%則拒絕繼續(xù)測試，待開發(fā)人員修正軟件后再繼續(xù)。3)當功能性測試用例通過率達到100%，非功能性測試用例通過率達到90%時，允許正常結束?；凇皽y試期缺陷密度”規(guī)則含義：對軟件測試一個cpu小時發(fā)現(xiàn)的缺陷數(shù)，比較適用于系統(tǒng)測試基于“運行期缺陷密度”規(guī)則含義：把軟件運行一個cpu小時發(fā)現(xiàn)的缺陷數(shù)，比較適用于驗收測試注：一個階段的出口標準!下一個階段的入口標準系統(tǒng)測試結束的標準!軟件的發(fā)布標準發(fā)布標準!軟件0缺陷選擇測試工具 是否需要，需要什么工具，怎么獲取降低軟件測試代價是企業(yè)普遍關注的問題，可通過；(萬般無奈下)十四、測試環(huán)境基本內容：設備環(huán)境、軟件環(huán)境、數(shù)據環(huán)境需考慮的因素 計算機平臺操作系統(tǒng) 瀏覽器 軟件支持平臺 外圍設備 網絡環(huán)境 其他專用設備 搭建測試環(huán)境時的配置原則：使用的頻度或范圍實效的可能性最大限度的模擬真實環(huán)境十五、測試管理由于測試工程中設計的人員、活動、工具是很多的，在制定測試計劃時需要對這些因素進行管理 選擇缺陷管理工具和測試管理工具定義工作進度建立風險管理計劃(1)可能遇到的風險、編碼階段出現(xiàn)大量質量問題，導致測試工作量時間增加、發(fā)生了大量的需求變更，(2)風險管理的過程+測試設計與開發(fā)+總體設計投入產出：測試設計的輸入是測試計劃，輸出是評審過的測試用例集合定義設計目標遵循的原則(清楚地說明沒項測試的目標使每項測試的目標單一，可以對應到規(guī)格說明書中的一項需求只說明測試應該完成什么工作，而不說明如何完成)流程：總體設計開發(fā)測試用例評審測試用例+測試用例——概念：為特定目標開發(fā)的測試輸入、執(zhí)行條件和預期結果的集合。+好的測試用例：，可重復性+測試用例的作用指導測試的實施 作為編寫測試腳本的“設計規(guī)格說明書”評估測試標準的度量基準分析缺陷的標準 +白盒測試用例設計+設計方法+邏輯覆蓋法( 語句覆蓋 判定覆蓋 條件覆蓋 判定條件覆蓋條件組合覆蓋 路經覆蓋基本路經法)+輔助模塊設計(：相當于被測程序的主程序。接受測試數(shù)據，把這些數(shù)據傳給被測模塊然后輸出實際測試結果。：用于調用被測模塊調用的子模塊?？梢宰錾倭康臄?shù)據操作，不需要把子模塊的所有功能都帶進來，但不容許什么都不做。)+黑盒測試用例設計等價類劃分法邊界值法——“缺陷遺漏在角落里，聚集在邊界上?！币蚬麍D法彌補等價類和邊界值法的不足錯誤推測法測試用例的管理可以通過配置管理工具cvs,vss,clearcase等實現(xiàn)，以保證測試是可重復的。+常見錯誤分析用戶界面問題輸入無合法性檢查和值域檢查。界面信息不能及時更新，不能正確反映數(shù)據狀態(tài)，甚至對用戶產生誤導。表達不清或過于模糊的信息提示。要求用戶輸入多余的本來系統(tǒng)可以自己得到的數(shù)據。為了得到某個設置或對話框用戶必須做許多冗余的操作，如對話框嵌套太多。不能記憶用戶的設置或操作習慣，使每次進入系統(tǒng)用戶都需重新操作一次初始環(huán)境。不經用戶確認就對系統(tǒng)或數(shù)據進行了重大修改。形象類問題不符合用戶的操作習慣。如，快捷鍵定義不科學不實用，甚至無快捷鍵。不夠專業(yè)，缺乏基本知識。界面中英文混雜，甚至拼寫錯誤。說明書或幫助的排版格式不專業(yè)：中英文不對應，標點的半全角問題，沒有排版準則。界面元素參差不齊，文字不能完全顯示。－穩(wěn)定性問題不可重現(xiàn)的死機，或不斷申請但不能完全釋放資源，使系統(tǒng)性能越來越低。主系統(tǒng)和子系統(tǒng)使用了相同的臨界資源而相互不知道。如：使用相同的類名或臨時文件名、使用同樣的數(shù)據庫字段名或登陸帳號。不能重現(xiàn)的錯誤，許多與代碼中的未初始化變量有關，有些與系統(tǒng)不檢查異常情況(網絡中斷、內存申請不成功、長時間無響應等)有關。其他問題運行時不檢查內存、硬盤空間、數(shù)據庫等。無根據的假設用戶環(huán)境：硬件/網絡情況；有些動態(tài)庫；假設網絡隨時都是聯(lián)通的。提供的版本帶病毒。提供錯誤的版本給測試組或測試用戶，或程序員與測試組使用不同版本。用戶現(xiàn)場開放和修改，又沒有記錄和保留。版本中部分內容或接口倒退，或出現(xiàn)版本管理混亂。有些選項永遠都是灰的，或有些在該變灰時沒變灰。+測試用例的評審測試或測試組件完全針對的是需求中列出的功能嗎？測試組件是否覆蓋了所有的需求？有冗余的嗎？每個測試步驟都有清楚描述的預期結果嗎？+優(yōu)先級+3級優(yōu)先級1：此測試用例必須執(zhí)行2：有時間就執(zhí)行3：可以不執(zhí)行+5級1：此測試必須通過，否則產品發(fā)布存在危險2：在發(fā)布前必須執(zhí)行3：時間允許就執(zhí)行4：此測試可以在下一次發(fā)布或發(fā)布后短期內執(zhí)行5：可以不測試第二篇：軟件測試技術面試總結軟件測試就是為了發(fā)現(xiàn)程序中的錯誤而分析和執(zhí)行程序的過程。——概念+基本知識+軟件開發(fā)過程定義計劃實現(xiàn)穩(wěn)定化部署+軟件開發(fā)模型(四種典型的模型)+瀑布模型概述：包括計劃，需求分析，設計，編碼，測試，運行維護六個階段。六個階段自上而下、相互銜接，以固定的次序進行。特點：；； ；。缺點：不適合需求模糊的系統(tǒng)+原型模型概述：先建立一個能夠反映用戶需求的原型系統(tǒng)，使得用戶和開發(fā)者可以對目標系統(tǒng)的概貌進行評價和判斷，然后對原型系統(tǒng)進行反復的擴充、改進、求精，最終建立符合用戶需求的目標系統(tǒng)。特點：；； 。分類：按照對原型的處理方式，可以分為漸進型和拋棄型。+增量模型概述：在增量模型中每個階段都生成軟件的一個可發(fā)布版本，階段交錯進行，版本逐漸完善。同原型模型的最大區(qū)別在于，在原型模型中每個階段發(fā)布一個原型而在增量模型中則完成一個正式版本。+螺旋模型概述：適用于大型軟件的開發(fā)，它將瀑布模型和快速原型模型結合起來，并加入了風險分析。特點：，風險分析，實施工程，評審四個階段；，每迭代一次螺旋線增一周，工程前進一個層次，系統(tǒng)生成一個新版本， 投入新的時間成本，最終得到客戶滿意的版本。軟件測試從需求開始：現(xiàn)代的軟件測試將測試滲入到軟件開發(fā)的各個階段，即使瀑布模型，表面看測試工作是在測試階段開始的，事實上，在計劃、需求、設計階段，測試人員便已經開始了他們的工作，如：了解軟件需求，編寫測試計劃，搭建測試環(huán)境。測試用例三要素：前提條件和操作步驟、預期結果、實際結果。必須以需求為依據。軟件測試分類是否關注軟件結構和算法黑盒測試：基于軟件需求的測試方法。白盒測試：基于軟件內部設計和程序實現(xiàn)的測試方法。是否執(zhí)行被測試軟件動態(tài)測試：在測試過程中執(zhí)行被測試軟件的測試方法。靜態(tài)測試：不。基于不同的測試階段：單元測試：主要測試軟件的單元模塊，需要編寫額外的測試驅動程序，采用白盒測試的方法，一般由 開發(fā)人員完成。集成測試：將一些“構件”集成在一起時測試他們是否能正常運行，構件可以是程序