1.軟件生命周期模型
從概念提出的那一刻開始，軟件產(chǎn)品就進(jìn)入了軟件生命周期。在經(jīng)歷需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、部署后，軟件將被使用并進(jìn)入維護(hù)階段，直到最后由于缺少維護(hù)費(fèi)用而逐漸消亡。這樣的一個(gè)過程，稱為"生命周期模型"（Life Cycle Model）。
典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型。
瀑布模型的特點(diǎn)（文檔是主體），很多的問題在最后才會(huì)暴露出來。迭代模型比瀑布模型問題暴露的要早；快速原型法比瀑布模型直觀。
2.軟件測試概念
廣義概念：指軟件生存周期中所有的檢查、評審和確認(rèn)工作，其中包括了對分析、設(shè)計(jì)階段，以及完成開發(fā)后維護(hù)階段的各類文檔、代碼的審查和確認(rèn)
狹義概念：識別軟件缺陷的過程，即實(shí)際結(jié)果與預(yù)期結(jié)果的不一致
3.軟件測試目的
ü 測試的目的就是發(fā)現(xiàn)軟件中的各種缺陷
ü 測試只能證明軟件存在缺陷，不能證明軟件不存在缺陷
ü 測試可以使軟件中缺陷降低到一定程度，而不是徹底消滅
ü 以較少的用例、時(shí)間和人力找出軟件中的各種錯(cuò)誤和缺陷，以確保軟件的質(zhì)量
4．軟件測試原則
ü Good-enough: 一種權(quán)衡投入/產(chǎn)出比的原則
ü 保證測試的覆蓋程度，但窮舉測試是不可能的
ü 所有的測試都應(yīng)追溯到用戶需求
ü 越早測試越好，測試過程與開發(fā)過程應(yīng)是相結(jié)合的
ü 測試的規(guī)模由小而大，從單元測試到系統(tǒng)測試
ü 為了盡可能地發(fā)現(xiàn)錯(cuò)誤，應(yīng)該由獨(dú)立的第三方來測試
ü 不能為了便于測試擅自修改程序
ü 既應(yīng)該測試軟件該做什么也應(yīng)該測試軟件不該做什么
5．軟件測試的的重點(diǎn)
ü 測試用例的設(shè)計(jì)
– 測試用例的設(shè)計(jì)是整個(gè)軟件測試工作的核心
– 測試用例反映對被測對象的質(zhì)量要求，決定對測試對象的質(zhì)量評估
ü 測試工作的管理
– 尤其是對包含多個(gè)子系統(tǒng)的大型軟件系統(tǒng)，其測試工作涉及大量人力和物力，有效的測試工作管理是保證有效測試工作的必要前提
ü 測試環(huán)境的建立
– 測試環(huán)境應(yīng)該與實(shí)際測試環(huán)境一致
6．黑盒測試
ü 什么是黑盒測試
– 又稱功能測試或數(shù)據(jù)驅(qū)動(dòng)測試，是針對軟件的功能需求/實(shí)現(xiàn)進(jìn)行測試，通過測試來檢測每個(gè)功能是否符合需求，不考慮程序內(nèi)部的邏輯結(jié)構(gòu)
ü 黑盒測試方法
– 功能劃分
– 等價(jià)類劃分
– 邊界值分析
– 因果圖
– 錯(cuò)誤推測等
7．什么是白盒測試
– 白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動(dòng)測試，必須知道軟件內(nèi)部工作過程，通過測試來檢測軟件內(nèi)部是否按照需求、設(shè)計(jì)正常運(yùn)行
– 白盒測試的主要方法
– 對應(yīng)于程序的一些主要結(jié)構(gòu)：語句、分支、邏輯路徑、變量；白盒測試的主要方法是：
– 語句覆蓋方法
– 分支覆蓋方法
– 邏輯覆蓋方法
8. 什么是動(dòng)態(tài)測試
動(dòng)態(tài)測試需要在開發(fā)/測試環(huán)境或?qū)嶋H運(yùn)行環(huán)境中運(yùn)行軟件，并使用測試用例去查找軟件缺陷；動(dòng)態(tài)測試包括功能確認(rèn)與接口測試、覆蓋率分析、性能分析、內(nèi)存分析等
9.什么是靜態(tài)測試
靜態(tài)測試不實(shí)際運(yùn)行軟件，主要是對軟件的編程格式、結(jié)構(gòu)等方面進(jìn)行評估.靜態(tài)測試包括代碼檢查、程序結(jié)構(gòu)分析、代碼質(zhì)量度量等。它可以由人工進(jìn)行，也可以借助軟件工具自動(dòng)進(jìn)行
10.手工測試和自動(dòng)測試
a.手工測試缺點(diǎn)在于測試工作量大，重復(fù)多，回歸測試難以實(shí)現(xiàn)
b.自動(dòng)測試?yán)密浖y試工具自動(dòng)實(shí)現(xiàn)全部或部分測試工作：管理、設(shè)計(jì)、執(zhí)行和報(bào)告；節(jié)省大量的測試開銷，并能夠完成一些手工測試無法實(shí)現(xiàn)的測試
ü 手工完成測試的全部過程無法保證測試的科學(xué)性與嚴(yán)密性:
– 修改的缺陷越多，回歸測試越困難
– 沒有人能向決策層提供精確的數(shù)據(jù)以度量當(dāng)前的工作進(jìn)度及工作效率
– 反復(fù)測試帶來的倦怠情緒及其他人為因素使得測試標(biāo)準(zhǔn)前后不一
– 測試花費(fèi)的時(shí)間越長，測試的嚴(yán)格性也就越低
ü 自動(dòng)測試將測試人員從反復(fù)、煩雜的測試執(zhí)行中解放出來，用更多的時(shí)間進(jìn)行測試設(shè)計(jì)和結(jié)果分析
ü 軟件測試不可能完全自動(dòng)化
ü 不能完成所有手工測試任務(wù)
ü 無創(chuàng)造性且靈活性差，不能改進(jìn)測試的有效性
ü 過程中可能會(huì)遇到許多意想不到的問題，特別是當(dāng)軟件不穩(wěn)定時(shí)
ü 測試腳本的維護(hù)高
11. 測試流程
ü 單元測試
ü 集成測試
ü 系統(tǒng)測試
ü 用戶驗(yàn)收測試
ü
12.單元測試
ü 完成對最小的軟件設(shè)計(jì)單元—模塊的驗(yàn)證工作
ü 目標(biāo)是確保模塊被正確地編碼
ü 使用過程設(shè)計(jì)描述作為指南，對重要的控制路徑進(jìn)行測試以發(fā)現(xiàn)模塊內(nèi)的錯(cuò)誤
ü 通常情況下是面向白盒的
ü 對代碼風(fēng)格和規(guī)則、程序設(shè)計(jì)和結(jié)構(gòu)、業(yè)務(wù)邏輯等進(jìn)行靜態(tài)測試，及早地發(fā)現(xiàn)和解決不易顯現(xiàn)的錯(cuò)誤
ü 單元測試的內(nèi)容
– 接口測試
– 內(nèi)部數(shù)據(jù)結(jié)構(gòu)
– 全局?jǐn)?shù)據(jù)結(jié)構(gòu)
– 邊界
– 語句覆蓋，錯(cuò)誤路徑
13.集成測試
ü 通過測試發(fā)現(xiàn)與模塊接口有關(guān)的問題
ü 目標(biāo)是把通過了單元測試的模塊拿來，構(gòu)造一個(gè)在設(shè)計(jì)中所描述的程序結(jié)構(gòu)
ü 應(yīng)當(dāng)避免一次性的集成（除非軟件規(guī)模很?。捎迷隽考?/span>
集成測試主要內(nèi)容
ü API
ü API/參數(shù)組合
14．系統(tǒng)測試
ü 根據(jù)軟件需求規(guī)范的要求進(jìn)行系統(tǒng)測試，確認(rèn)系統(tǒng)滿足需求的要求
ü 系統(tǒng)測試人員相當(dāng)于用戶代言人
ü 在需求分析階段要確定軟件的可測性，保證有效完成系統(tǒng)測試工作
ü 系統(tǒng)測試主要內(nèi)容
ü 所有功能需求得到滿足
ü 所有性能需求得到滿足
ü 其他需求（例如安全性、容錯(cuò)性、兼容性等）得到滿足
15.用戶驗(yàn)收/確認(rèn)測試
ü Alpha測試
– 是由用戶在開發(fā)者的場所來進(jìn)行的，Alpha測試是在一個(gè)受控的環(huán)境中進(jìn)行的
ü Beta測試
– 由軟件的最終用戶在一個(gè)或多個(gè)用戶場所來進(jìn)行的，開發(fā)者通常不在現(xiàn)場，用戶記錄測試中遇到的問題并報(bào)告給開發(fā)者
16．壓力測試VS性能測試
性能測試的目的不是去找bugs,而是排除系統(tǒng)的瓶頸，以及為以后的回歸測試建立一個(gè)基準(zhǔn)。而性能測試的操作，實(shí)際上就是一個(gè)非常小心受控的測量分析過程。在理想的情況下，被測軟件在這個(gè)時(shí)候已經(jīng)是足夠穩(wěn)定了
性能測試是為了檢查系統(tǒng)的反映，運(yùn)行速度等性能指標(biāo)，他的前提是要求在一定負(fù)載下，如檢查一個(gè)網(wǎng)站在100人同時(shí)在線的情況下的性能指標(biāo)，每個(gè)用戶是否都還可以正常的完成操作等。
概括就是：在不同負(fù)載下（負(fù)載一定）時(shí)，通過一些系統(tǒng)參數(shù)（如反應(yīng)時(shí)間等）檢查系統(tǒng)的運(yùn)行情況；
壓力測試是為了發(fā)現(xiàn)系統(tǒng)能支持的最大負(fù)載，他的前提是要求系統(tǒng)性能處在可以接受的范圍內(nèi)，比如經(jīng)常規(guī)定的葉面3秒鐘內(nèi)響應(yīng)；概括就是：在性能可以接受的前提下，測試系統(tǒng)可以支持的最大負(fù)載。
舉例說明：針對一個(gè)網(wǎng)站進(jìn)行測試，模擬10到50個(gè)用戶就是在進(jìn)行常規(guī)性能測試，用戶增加到1000乃至上萬就變成了壓力/負(fù)載測試。如果同時(shí)對系統(tǒng)進(jìn)行大量的數(shù)據(jù)查詢操作，就包含了強(qiáng)度測試。
17. 主流測試工具的測試流程
========winrunner
1 啟動(dòng)時(shí)選擇要加載的插件
2 進(jìn)行一些設(shè)置（如錄制模式等）
3 識別應(yīng)用程序的GUI，即創(chuàng)建map(就是學(xué)習(xí)被測試軟件的界面）
4 建立測試腳本（錄制及編寫）
5 對腳本除錯(cuò)及調(diào)試（保證能夠運(yùn)行完）
6 插入各種檢查點(diǎn)（圖片，文字，控件等）
7 在新版應(yīng)用程序中執(zhí)行測試腳本
8 分析結(jié)果，回報(bào)缺陷
=========quicktestpro========
1 準(zhǔn)備錄制
打開你要對其進(jìn)行測試的應(yīng)用程序，并檢查QuickTest中的各項(xiàng)設(shè)置是否適合當(dāng)前的要求。
2 進(jìn)行錄制
打開QuickTest的錄制功能，按測試用例中的描述，操作被測試應(yīng)用程序。
3 編輯測試腳本
通過加入檢測點(diǎn)、參數(shù)化測試，以及添加分支、循環(huán)等控制語句，來增強(qiáng)測試腳本的功能，使將來的回歸測試真正能夠自動(dòng)化。
4 調(diào)試腳本
調(diào)試腳本，檢查腳本是否存在錯(cuò)誤。
5 在回歸測試中運(yùn)行測試
在對應(yīng)用程序的回歸測試中，通過QuickTest回放對應(yīng)用程序的操作，檢驗(yàn)軟件正確性，實(shí)現(xiàn)測試的自動(dòng)化進(jìn)行。
6 分析結(jié)果，報(bào)告問題
查看QuickTest記錄的運(yùn)行結(jié)果，記錄問題，報(bào)告測試結(jié)果。
＝＝＝＝TestDirect============
安裝好后，先進(jìn)入站點(diǎn)管理
1 創(chuàng)建域及工程
2 添加用戶
3 編輯licenses及本服務(wù)器
4 編輯數(shù)據(jù)庫
－－TD
1 選擇新建的工程進(jìn)行定制(列表，用戶，組，版本等)
2 在require中增加需求
3 把需求轉(zhuǎn)化為plan
4 在testlab中由計(jì)劃新建測試具體用例與執(zhí)行
5 發(fā)現(xiàn)bug，在defect中提交bug
（每一部分都可以相對獨(dú)立地使用）
======loadrunner
1 制定負(fù)載測試計(jì)劃
(分析應(yīng)用程序， 確定測試目標(biāo)，計(jì)劃怎樣執(zhí)行LoadRunner）
2 開發(fā)測試腳本
（錄制基本的用戶腳本，完善測試腳本）
3 創(chuàng)建運(yùn)行場景
（選擇場景類型為Manual Scenario，選擇場景類型，理解各種類型，場景的類型轉(zhuǎn)化）
4 運(yùn)行測試
5 監(jiān)視場景
（MEMORY 相關(guān)，PROCESSOR相關(guān)，網(wǎng)絡(luò)吞量以及帶寬，磁盤相關(guān)，WEB應(yīng)用程序 ，IIS5.0，SQL SERVER，NETWORK DELAY等)
6 分析測試結(jié)果
(分析實(shí)時(shí)監(jiān)視圖表,分析事務(wù)的響應(yīng)時(shí)間,分解頁面,確定WEBSERVER的問題,其他有用的功能)
