測試是為發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。
破壞性過程。心理學(xué)和經(jīng)濟(jì)學(xué)。
軟件測試的對象包括：程序、數(shù)據(jù)、文檔。目標(biāo)程序和源程序都屬于程序。
軟件測試的原則
- 測試用例中一個必需部分是對預(yù)期輸出或結(jié)果的定義。
- 對程序的輸入數(shù)據(jù)的描述。
- 對程序在上述輸入數(shù)據(jù)下的正確輸出結(jié)果的精確描述。
防止某個似是而非而實際錯誤的結(jié)果被解釋成正確結(jié)論。
- 程序員應(yīng)當(dāng)避免測試自己編寫的程序。
- 編寫軟件的組織不應(yīng)當(dāng)測試自己編寫的軟件。
- 應(yīng)當(dāng)徹底檢查每個測試的執(zhí)行結(jié)果。
- 測試用例的編寫不僅應(yīng)當(dāng)根據(jù)有效和預(yù)期的輸入情況，而且也應(yīng)當(dāng)根據(jù)無效和未預(yù)料到的輸入情況。
- 檢查程序是否“未做其應(yīng)該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應(yīng)該做的”。
- 應(yīng)當(dāng)避免測試用例用后即棄，除非軟件本身就是一個一次性的軟件。
- 交互式系統(tǒng)測試時較為常見。
- 保留測試用例，當(dāng)程序其他部件發(fā)生更動后重新執(zhí)行，即“回歸測試”。
- 計劃測試工作時不應(yīng)默許假定不會發(fā)現(xiàn)錯誤。
- 程序某部分存在更多錯誤的可能性，與該部分已發(fā)現(xiàn)錯誤的數(shù)量成正比。
- 錯誤總是傾向于聚集存在。
- 軟件測試是一項極富創(chuàng)造性、極具智力挑戰(zhàn)性的工作。
代碼檢查、走查與評審
人工測試方法：代碼檢查、走查以及可用性測試。
- 利用錯誤列表進(jìn)行代碼檢查。
- 小組代碼走查。
- 桌面檢查。
- 通話評審。
同行評審
依據(jù)程序整體質(zhì)量、可維護(hù)性、可擴(kuò)展性、易用性和清晰性對匿名程序進(jìn)行評價的技術(shù)。
軟件測試計劃評審會需要有 項目經(jīng)理、客戶(可選)、配置管理員、測試經(jīng)理、開發(fā)組長等人的參加。
測試用例的設(shè)計
最關(guān)鍵問題：在所有可能的測試用例中，哪個子集最有可能發(fā)現(xiàn)最多的錯誤？
測試用例是測試程序正確性與否的關(guān)鍵。
白盒測試
邏輯驅(qū)動的測試。白盒測試關(guān)注的是測試用例執(zhí)行的程度或覆蓋程序邏輯結(jié)構(gòu)（源代碼）的程度。完全的白盒測試是將程序中的每條路徑都執(zhí)行到，然而對帶有循環(huán)的程序來說，并不現(xiàn)實。
邏輯覆蓋測試
- 語句覆蓋：可執(zhí)行語句至少被執(zhí)行一次；
必要條件，最弱的準(zhǔn)則。語句原本的寫法有誤，無法檢測？ - 判定覆蓋或分支覆蓋：每個判斷的取真分支和取假分支至少經(jīng)歷一次；每條分支路徑都必須至少遍歷一次；每個入口點都必須被至少調(diào)用一次。
可以滿足語句覆蓋。 - 條件覆蓋：每個條件的取值至少滿足一次；
- 判定/條件覆蓋：判斷和條件都滿足；將一個判斷中的每個條件的所有可能的結(jié)果至少執(zhí)行一次，將每個判斷的所有可能結(jié)果至少執(zhí)行一次，將每個入口點都至少調(diào)用一次。
- 條件組合覆蓋（多重條件覆蓋）：每個條件的所有可能都至少出現(xiàn)一次，并且判定結(jié)果至少出現(xiàn)一次 ；
與條件覆蓋的區(qū)別：不是簡單要求每個條件出現(xiàn)“真”和“假”兩種結(jié)果，而是要求這些結(jié)果所有可能至少出現(xiàn)一次； - 路徑測試：執(zhí)行所有可能的執(zhí)行路徑；
- 基本路徑測試：路徑測試執(zhí)行了每個路徑，每個判定的結(jié)果肯定經(jīng)歷過一次。
黑盒測試
數(shù)據(jù)驅(qū)動測試，輸入/輸出驅(qū)動的測試，不需要了解程序內(nèi)部的結(jié)構(gòu)。
- 等價劃分
- 邊界值分析
邊界值分析的基本思想是使用在最小值、略高于最小值、正常值、略低于最大值和最大值處取輸入變量值，記為：min、min+、nom、max-、max。考慮到健壯性測試，還可以加一個略大于最大值max+，以及一個略小于最小值min-的值。 - 因果圖法、判定表驅(qū)動法、正交試驗設(shè)計法、功能圖法、場景法等。
邊界值法既可以用于黑盒測試用例，也可以用于白盒測試用例。
錯誤猜測
模塊（單元）測試
系統(tǒng)集成測試主要包括以下過程：1. 構(gòu)建的確認(rèn)過程。 2. 補(bǔ)丁的確認(rèn)過程。 3. 系統(tǒng)集成測試測試組提交過程。 4. 測試用例設(shè)計過程。 5. 測試代碼編寫過程。 6. Bug的報告過程。 7. 每周/每兩周的構(gòu)建過程。 8. 點對點的測試過程。 9. 組內(nèi)培訓(xùn)過程。
更高級別的測試
軟件開發(fā)過程在很大程度上是溝通有關(guān)最終程序的信息、并將信息從一種形式轉(zhuǎn)換到另一種形式。由于這個原因，絕大部分軟件錯誤都可以歸因為信息溝通和轉(zhuǎn)換時發(fā)生的故障、差錯和干擾。
軟件開發(fā)周期模型：
最終用戶->需求->目標(biāo)->外部規(guī)格說明->系統(tǒng)設(shè)計->程序結(jié)構(gòu)設(shè)計->模塊接口規(guī)格說明->代碼。
可以在每個階段結(jié)束時引入獨立的驗證過程，以防止一些錯誤。
開發(fā)過程與測試過程一對一的聯(lián)系：
驗收測試->系統(tǒng)測試->功能測試->集成測試->模塊測試。
這種結(jié)構(gòu)避免了沒有效果的多余測試。
測試順序不一定是嚴(yán)格的時間順序。
更高級別的測試最適用于軟件產(chǎn)品，而對沒有正規(guī)需求和目標(biāo)的程序，功能測試可能是唯一更高級別的測試。
功能測試
試圖發(fā)現(xiàn)程序與其外部規(guī)格說明之間存在不一致的過程。外部規(guī)格說明是一份從最終用戶角度對程序行為的精確描述。
通常為黑盒操作。（等價類劃分、邊界值分析法、因果圖法、錯誤猜測法）
系統(tǒng)測試
將系統(tǒng)或程序與其初始目標(biāo)進(jìn)行比較。
最難進(jìn)行的測試。
- 系統(tǒng)測試并不局限于系統(tǒng)。如果產(chǎn)品是一個程序，那么系統(tǒng)測試就是一個試圖說明程序作為一個整體是如何不滿足其目標(biāo)的過程。
- 根據(jù)定義，如果產(chǎn)品沒有一組書面的、可度量的目標(biāo)，系統(tǒng)測試也就無法進(jìn)行。
測試用例設(shè)計依據(jù)：程序的用戶文檔或書面材料。
系統(tǒng)測試用例
- 能力測試：確保程序的目標(biāo)功能實現(xiàn)
- 容量測試：發(fā)現(xiàn)處理大容量數(shù)據(jù)時的程序異常
- 強(qiáng)度測試：發(fā)現(xiàn)在大規(guī)模負(fù)載、高強(qiáng)度不間斷持續(xù)的數(shù)據(jù)處理中的異常
- 可用性測試：評估最終用戶在使用軟件并與軟件交互時的可用性問題
- 安全性測試：試圖攻破程序的安全防線
- 性能測試： 評估程序的響應(yīng)時間以及吞吐量瓶頸
- 存儲測試： 確保程序可以證券處理其對存儲的要求，包括系統(tǒng)的存儲和物理上存儲
- 配置測試： 檢查程序是否能在推薦配置上流暢運行
- 兼容性/轉(zhuǎn)換測試： 評估新版本是否能兼容老的版本
- 安裝測試： 確保能夠在所有支持的平臺上安裝軟件
- 可靠性測試：評估程序是否能達(dá)到規(guī)格說明中的運行時常和MTBF（平均故障間隔時間）要求
- 可恢復(fù)性測試：測試系統(tǒng)恢復(fù)相關(guān)的功能是否按設(shè)計要求實現(xiàn)
- 服務(wù)/可維護(hù)性測試：評估系統(tǒng)是否擁有良好的數(shù)據(jù)處理和日志機(jī)制，以備技術(shù)支持和調(diào)試之需
- 文檔測試： 檢驗所有的用戶文檔是否準(zhǔn)確
- 過程測試： 對軟件系統(tǒng)操作或維護(hù)所需涉及的流程進(jìn)行評估和確定
驗收測試
將程序與其最初的需求及最終用戶當(dāng)前的需要進(jìn)行比較的過程。
原則上由程序的客戶或最終用戶來進(jìn)行。
軟件驗收測試分為三類：
正式驗收測試；
非正式驗收測試：α測試（由用戶、測試人員、開發(fā)人員共同參與的內(nèi)部測試。） ，β測試（內(nèi)測后的公測，即完全交給最終用戶測試。）。
安裝測試
測試結(jié)束的準(zhǔn)則
- 用完了安排的測試時間后，測試便結(jié)束。
- 當(dāng)執(zhí)行完所有測試用例都未發(fā)現(xiàn)錯誤，測試便結(jié)束。
以上兩種都是不可取的。
三類較為有用的結(jié)束準(zhǔn)則
- 根據(jù)特定的測試用例設(shè)計技術(shù)。
模塊測試結(jié)束準(zhǔn)則：
測試用例來源于（1）滿足多重條件覆蓋準(zhǔn)則，（2）對模塊接口規(guī)格說明進(jìn)行邊界值分析，產(chǎn)生的所有測試用例最終都是不成功的。
功能測試結(jié)束準(zhǔn)則：
測試用例來源于（1）因果圖分析，（2）邊界值分析，（3）錯誤猜測，產(chǎn)生的所有測試用例最終都是不成功的。
以上方法問題在于：對沒有特定方法的測試階段，如系統(tǒng)測試階段仍不起作用。依賴于主觀度量。沒有設(shè)定目標(biāo)。 - 以確切的數(shù)量來描述結(jié)束測試的條件。
- 在測試過程中記錄每單位時間內(nèi)發(fā)現(xiàn)的錯誤數(shù)量。通過檢查統(tǒng)計曲線的形狀，決定繼續(xù)進(jìn)行測試還是終止測試。
可用性（或用戶體驗）測試
基本上屬于黑盒測試。
可用性測試流程
- 測試用戶的選擇
- 需要多少用戶測試
- 數(shù)據(jù)采集方法
- 可用性調(diào)查問卷
- 何時手工，還是多多益善
調(diào)試
- 確定程序中可疑錯誤的準(zhǔn)確性質(zhì)和位置；
- 修改錯誤。
暴力法調(diào)試
- 利用內(nèi)存信息輸出來調(diào)試。
- 根據(jù)一般的“在程序中插入打印語句”建議來調(diào)試。
- 使用自動化的調(diào)試工具進(jìn)行調(diào)試。
歸納法調(diào)試
演繹法調(diào)試
敏捷開發(fā)模式下的測試
圍繞以用戶為中心，以客戶需求為導(dǎo)向的開發(fā)過程，在此過程中隨時做好“迎接變化”的準(zhǔn)備。
客戶是敏捷的關(guān)鍵環(huán)節(jié)。
特征：依賴客戶的參與、測試驅(qū)動以及緊湊的迭代開發(fā)周期。
敏捷開發(fā)方法：
敏捷建模
敏捷統(tǒng)一過程
動態(tài)系統(tǒng)開發(fā)方法
核心統(tǒng)一過程（EssUP）
極限編程（eXtreme Programming，XP）
功能驅(qū)動開發(fā)（FDD）
開放統(tǒng)一過程
Scrum進(jìn)度跟蹤
一些補(bǔ)充
- 針對手機(jī)應(yīng)用軟件的系統(tǒng)測試，我們通常從如下幾個角度開展：功能模塊測試，交叉事件測試，壓力測試，容量測試，兼容性測試，易用性/用戶體驗測試等。
對手機(jī)可以施加的壓力測試類型主要有：存儲壓力、邊界壓力、 響應(yīng)能力壓力、網(wǎng)絡(luò)流量壓力。 - 測試的分類：
- 人工測試：如個人復(fù)查，抽查和會審等；機(jī)器自動測試；
- 按照否關(guān)軟件內(nèi)部結(jié)構(gòu)具體實現(xiàn)角度：A.白盒測試B.黑盒測試 C.灰盒測試
- 按照軟件發(fā)程按階段：A.單元測試 B.集測試 C.確認(rèn)測試 D.系統(tǒng)測試 E.驗收測試
- 做好文檔測試需要注意的點有哪些?
仔細(xì)閱讀，跟隨每個步驟，檢查每個圖形，嘗試每個示例；
檢查文檔的編寫是否滿足文檔編寫的目的；
內(nèi)容是否齊全，正確，完善；
標(biāo)記是否正確。 - 缺陷分兩種：
- 完全影響軟件的正常運行或者影響客戶的正常體驗。
這種當(dāng)然不能予以通過。 - 不影響產(chǎn)品運行及客戶正常體驗且此軟件急于使用。
以公司利益為出發(fā)，應(yīng)予以通過。但在時間不緊急的情況下應(yīng)不予通過。
一個好的測試人員應(yīng)該有很好的情況分析能力，并且要有擔(dān)當(dāng)。
- 單元測試能發(fā)現(xiàn)約80%的軟件缺陷。
- 常用工具總結(jié)。
LoadRunner-負(fù)載壓力測試：預(yù)測系統(tǒng)性能。預(yù)測系統(tǒng)行為和性能的工業(yè)標(biāo)準(zhǔn)級負(fù)載測試工具。模擬上千萬用戶同時實施并發(fā)操作，來實時監(jiān)控可能發(fā)生的問題。
JMeter+Badboy：基于JAVA的壓力測試工具，Badboy用來進(jìn)行腳本的錄制。
功能測試： 通過自動錄制、檢測和回放用戶的應(yīng)用操作。將輸出記錄同預(yù)先給定的記錄比較。QTP(quicktest professional):自動測試工具。
白盒測試：C++ TEST（做C和C++的白盒測試）、JUnit（Java白盒測試），針對代碼測試。
測試管理工具：對測試需求、計劃、用例、實施進(jìn)行管理。
測試輔助工具：本身不執(zhí)行，可以生成測試數(shù)據(jù)，為測試提供數(shù)據(jù)準(zhǔn)備。
缺陷管理工具：Mantis、BugFree、QC、TD
用例管理工具：TestLink、QC
測試輔助工具：SVN
