第一章 基本概念
一漂辐、軟件生命周期(SDLC)的六個階段
（1）問題的定義
? ? ? 此階段是軟件開發(fā)方與需求方共同討論，主要確定軟件的開發(fā)目標及其可行性绳慎。
（2）需求分析
? ? ? 在確定軟件開發(fā)可行的情況下，對軟件需要實現(xiàn)的各個功能進行詳細分析。需求分析階段是一個很重要的階段慨蛙，這一階段做得好辽聊，將為整個軟件開發(fā)項目的成功打下良好的基礎。"唯一不變的是變化本身期贫。"跟匆，同樣需求也是在整個軟件開發(fā)過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化通砍，以保護整個項目的順利進行玛臂。
（3）軟件設計
? ? ? 此階段主要根據(jù)需求分析的結(jié)果，對整個軟件系統(tǒng)進行設計封孙，如系統(tǒng)框架設計迹冤，數(shù)據(jù)庫設計等等。軟件設計一般分為總體設計和詳細設計敛瓷。好的軟件設計將為軟件程序編寫打下良好的基礎叁巨。
（4）程序編碼
此階段是將軟件設計的結(jié)果轉(zhuǎn)換成計算機可運行的程序代碼。在程序編碼中必須要制定統(tǒng)一呐籽，符合標準的編寫規(guī)范锋勺。以保證程序的可讀性，易維護性狡蝶，提高程序的運行效率庶橱。
（5）軟件測試
? ? ? 在軟件設計完成后要經(jīng)過嚴密的測試，以發(fā)現(xiàn)軟件在整個設計過程中存在的問題并加以糾正贪惹。整個測試過程分單元測試苏章、組裝測試以及系統(tǒng)測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種奏瞬。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試枫绅，以減少測試的隨意性。
（6）運行維護
軟件維護是軟件生命周期中持續(xù)時間最長的階段硼端。在軟件開發(fā)完成并投入使用后并淋，由于多方面的原因，軟件不能繼續(xù)適應用戶的要求珍昨。要延續(xù)軟件的使用壽命县耽，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面镣典。
二兔毙、.軟件生命周期模型
典型的幾種生命周期模型包括瀑布模型、快速原型模型兄春、迭代模型澎剥、螺旋模型。
1.瀑布模型
傳統(tǒng)的軟件開發(fā)流程赶舆。即：問題定義肴裙、需求分析趾唱、設計、編碼蜻懦、測試、運行維護六個階段夕晓。
2.V模型
在V模型中宛乃，測試過程被加在開發(fā)過程的后半部分，單元測試所檢測代碼的開發(fā)是否符合詳細設計的要求蒸辆。集成測試所檢測此前測試過的各組成部分是否能完好地結(jié)合到一起征炼。系統(tǒng)測試所檢測已集成在一起的產(chǎn)品是否符合系統(tǒng)規(guī)格說明書的要求。而驗收測試則檢測產(chǎn)品是否符合最終用戶的需求躬贡。
V模型的缺陷：
僅僅把測試過程作為在需求分析谆奥、系統(tǒng)設計及編碼之后的一個階段 ；
忽視了測試對需求分析,系統(tǒng)設計的驗證拂玻，一直到后期的驗收測試才被發(fā)現(xiàn)酸些。
3.W模型
對于V模型，W模型增加了軟件各開發(fā)階段中應同步進行的驗證和確認活動檐蚜。W模型由兩個V字型模型組成魄懂，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關系闯第。
W模型強調(diào)：測試伴隨著整個軟件開發(fā)周期市栗，而且測試的對象不僅僅是程序，需求咳短、設計等同樣要測試填帽，也就是說，測試與開發(fā)是同步進行的咙好。W模型有利于盡早地全面的發(fā)現(xiàn)問題篡腌。例如，需求分析完成后敷扫，測試人員就應該參與到對需求的驗證和確認活動中哀蘑，以盡早地找出缺陷所在。同時葵第，對需求的測試也有利于及時了解項目難度和測試風險绘迁，及早制定應對措施，這將顯著減少總體測試時間卒密，加快項目進度缀台。
但W模型也存在局限性。在W模型中哮奇，需求膛腐、設計睛约、編碼等活動被視為串行的，同時哲身，測試和開發(fā)活動也保持著一種線性的前后關系辩涝，上一階段完全結(jié)束，才可正式開始下一個階段工作勘天。這樣就無法支持迭代的開發(fā)模型怔揩。對于當前軟件開發(fā)復雜多變的情況，W模型并不能解除測試管理面臨著困惑脯丝。
W模型的優(yōu)點：
測試的活動與軟件開發(fā)同步進行商膊；
測試的對象不僅僅是程序，還包括需求和設計宠进；
盡早發(fā)現(xiàn)軟件缺陷可降低軟件開發(fā)的成本晕拆。
補充：
軟件測試生命周期：需求分析→測試計劃 → 測試設計 → 測試執(zhí)行→ 測試評估
三、軟測的定義材蹬、目的及原則
1.定義：是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程实幕。
2.目的：在軟件投入運行之前，盡可能多地發(fā)現(xiàn)軟件中的錯誤和缺陷赚导，以確保軟件的質(zhì)量茬缩。
3.原則：
軟件測試應盡早執(zhí)行，并貫穿于整個軟件生命周期
軟件測試應追溯需求
測試應由第三方來構(gòu)造
窮舉測試是不可能的,要遵循Good-enough原則
必須確定預期輸出（或結(jié)果）
必須徹底檢查每個測試結(jié)果
充分注意測試中的群集現(xiàn)象
缺陷的二八定理
嚴格執(zhí)行測試計劃吼旧，排除測試的隨意性
注意合法合理的輸入凰锡，也要注意非法的非預期的輸入
檢查程序是否做了不該做的
測試應從“小規(guī)模”開始圈暗，逐步轉(zhuǎn)向“大規(guī)牡辔”
反復使用同樣的測試會使軟件具有抵抗力
關注缺陷的修復
四、軟件缺陷的定義
? 即計算機系統(tǒng)或者程序中存在的任何一種破壞正常運行能力的問題员串、錯誤勇哗，或者隱藏的功能缺陷、瑕疵寸齐。精確定義：
（1） 軟件未達到產(chǎn)品說明書要求的功能
（2） 軟件出現(xiàn)了產(chǎn)品說明書指明不會出現(xiàn)的錯誤欲诺。
（3） 軟件功能超出了產(chǎn)品說明書規(guī)定的功能
（4） 軟件未實現(xiàn)產(chǎn)品說明書雖未明確指出但應該實現(xiàn)的目標
（5） 軟件難以理解，不易使用渺鹦，運行緩慢或者最終用戶認為使用效果不好扰法。
五、軟件測試的分類
1．按軟件測試的生命周期：
（1） 單元測試：程序員完成毅厚。檢查每個程序單元能否正確實現(xiàn)詳細設計說明中的模塊功能塞颁、性能、接口和設計約束等要求，發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種錯誤祠锣。
（2） 集成測試：白盒測試人員或開發(fā)人員完成酷窥。檢查各個單元模塊結(jié)合到一塊是否協(xié)同配合，正常運行伴网。
（3） 確認測試：運用黑盒測試檢驗被測軟件是否滿足需求規(guī)格說明書規(guī)定的要求蓬推。
（4） 系統(tǒng)測試：黑盒測試人員完成。將已確認的軟件澡腾、計算機硬件拳氢、外設、網(wǎng)絡等其他元素結(jié)合在一起蛋铆，進行信息系統(tǒng)的各種集成測試和確認測試。目的是發(fā)現(xiàn)所開發(fā)系統(tǒng)與用戶需求不符或矛盾的地方放接。
（5） 驗收測試：用戶測試為主刺啦。
2.按軟件技術(shù)：白盒、黑盒纠脾、灰盒
其中白盒測試可以分為兩大類：靜態(tài)測試玛瘸、動態(tài)測試
靜態(tài)測試（不運行程序）：代碼檢查、靜態(tài)結(jié)構(gòu)分析
動態(tài)測試（運行程序）：邏輯覆蓋苟蹈、路徑分析
3.按測試內(nèi)容：功能測試糊渊、性能測試、易用性測試慧脱、可移植性測試渺绒、可靠性測試等
六、軟件質(zhì)量保證和軟件測試的關系
同：目的都是盡力確保軟件產(chǎn)品滿足需求菱鸥，從而開發(fā)出高質(zhì)量的軟件產(chǎn)品宗兼。
異：軟件質(zhì)量保證工作側(cè)重對軟件開發(fā)流程中的各個過程進行管理與控制，杜絕軟件缺陷的產(chǎn)生氮采。而測試是對已經(jīng)產(chǎn)生的軟件缺陷進行修復殷绍。
七、能力成熟度模型CMM
? CMM是指“能力成熟度模型”鹊漠，是對于軟件組織在定義主到、實施、度量躯概、控制和改善其軟件過程的實踐中各個發(fā)展階段的描述登钥。CMM的核心是把軟件開發(fā)視為一個過程，并根據(jù)這一原則對軟件開發(fā)和維護進行過程監(jiān)控和研究楞陷，以使其更加科學化怔鳖、標準化、使企業(yè)能夠更好地實現(xiàn)商業(yè)目標。
CMM是一種用于評價軟件承包能力并幫助其改善軟件質(zhì)量的方法结执，側(cè)重于軟件開發(fā)過程的管理及工程能力的提高與評估度陆。CMM分為五個等級：一級為初始級，二級為可重復級献幔，三級為已定義級懂傀，四級為已管理級，五級為優(yōu)化級蜡感。
八蹬蚁、黑盒測試
1.定義：又稱功能測試或數(shù)據(jù)驅(qū)動測試，是針對軟件的功能需求/實現(xiàn)進行測試郑兴，通過測試來檢測每個功能是否符合需求犀斋，不考慮程序內(nèi)部的邏輯結(jié)構(gòu)。
2.黑盒測試方法：等價類劃分情连、邊界值分析叽粹、決策表法、因果圖却舀、錯誤推測等
九虫几、白盒測試
1.白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，必須知道軟件內(nèi)部工作過程挽拔，通過測試來檢測軟件內(nèi)部是否按照需求辆脸、設計正常運行
2.白盒測試的主要方法是：
動態(tài)測試需要在開發(fā)/測試環(huán)境或?qū)嶋H運行環(huán)境中運行軟件，并使用測試用例去查找軟件缺陷螃诅。主要有邏輯覆蓋啡氢、路經(jīng)分析測試
靜態(tài)測試不實際運行軟件，主要是對軟件的編程格式州刽、結(jié)構(gòu)等方面進行評估.靜態(tài)測試包括代碼檢查空执、程序結(jié)構(gòu)分析、代碼質(zhì)量度量等穗椅。它可以由人工進行辨绊，也可以借助軟件工具自動進行。主要有：靜態(tài)結(jié)構(gòu)分析匹表、代碼檢查
十门坷、手工測試和自動測試
1..手工測試缺點在于測試工作量大，重復多袍镀，回歸測試難以實現(xiàn)
2.自動測試利用軟件測試工具自動實現(xiàn)全部或部分測試工作：管理默蚌、設計、執(zhí)行和報告苇羡；節(jié)省大量的測試開銷绸吸，并能夠完成一些手工測試無法實現(xiàn)的測試
? 手工完成測試的全部過程無法保證測試的科學性與嚴密性:
– 修改的缺陷越多，回歸測試越困難
– 沒有人能向決策層提供精確的數(shù)據(jù)以度量當前的工作進度及工作效率
– 反復測試帶來的倦怠情緒及其他人為因素使得測試標準前后不一
– 測試花費的時間越長，測試的嚴格性也就越低
? 自動測試將測試人員從反復锦茁、煩雜的測試執(zhí)行中解放出來攘轩，用更多的時間進行測試設計和結(jié)果分析
? 軟件測試不可能完全自動化
? 不能完成所有手工測試任務
? 無創(chuàng)造性且靈活性差，不能改進測試的有效性
? 過程中可能會遇到許多意想不到的問題码俩，特別是當軟件不穩(wěn)定時
? 測試腳本的維護高
十一度帮、軟件測試工程師的素質(zhì)
? 良好的溝通能力
? 掌握比較全面的技術(shù)
? 充分的自信心
? 足夠的耐心和責任感
? 具備懷疑精神和學習能力
? 超強的記憶力和良好的洞察力
十二、軟件測試的生命周期
需求分析→測試計劃 → 測試設計 → 測試執(zhí)行 → 測試評估
第二章 軟件測試從編寫開始各個階段
一稿存、各階段介紹
1.單元測試
? 通常情況下是面向白盒的
? 對代碼風格和規(guī)則笨篷、程序設計和結(jié)構(gòu)、業(yè)務邏輯等進行靜態(tài)測試瓣履，及早地發(fā)現(xiàn)和解決不易顯現(xiàn)的錯誤
? 單元測試的內(nèi)容
– 接口測試
– 內(nèi)部數(shù)據(jù)結(jié)構(gòu)
– 全局數(shù)據(jù)結(jié)構(gòu)
– 邊界測試
– 語句覆蓋
– 錯誤處理測試
– 路徑測試
? 單元測試的策略有哪些率翅？
邏輯覆蓋、循環(huán)覆蓋袖迎、同行評審安聘、桌前檢查、代碼走查瓢棒、代碼評審、景泰數(shù)據(jù)流分析
2.集成測試
? 通過測試發(fā)現(xiàn)與模塊接口有關的問題
? 目標是把通過了單元測試的模塊拿來丘喻，構(gòu)造一個在設計中所描述的程序結(jié)構(gòu)
? 應當避免一次性的集成（除非軟件規(guī)模很懈蕖），而采用增量集成
? 主要內(nèi)容：API泉粉、API/參數(shù)組合
3.確認測試
? 又稱為有效性測試连霉，目的是驗證軟件的功能和性能及其特性是否與客戶的要求一致，是否滿足軟件需求規(guī)格說明書中的規(guī)定嗡靡。
4．系統(tǒng)測試
? 目的是驗證最終軟件系統(tǒng)是否滿足產(chǎn)品需求并且遵循系統(tǒng)設計
? 系統(tǒng)測試人員相當于用戶代言人
? 在需求分析階段要確定軟件的可測性跺撼，保證有效完成系統(tǒng)測試工作
? 系統(tǒng)測試主要內(nèi)容
? 所有功能需求得到滿足
? 所有性能需求得到滿足
? 其他需求（例如安全性、容錯性讨彼、兼容性等）得到滿足
? ? 常見的系統(tǒng)測試方法
? 安全測試
? 正確性測試
? 可靠性測試
? 兼容性測試
5.用戶驗收測試
? Alpha測試
– 是由用戶在開發(fā)者的場所來進行的歉井，Alpha測試是在一個受控的環(huán)境中進行的
? Beta測試
– 由軟件的最終用戶在一個或多個用戶場所來進行的，開發(fā)者通常不在現(xiàn)場哈误，用戶記錄測試中遇到的問題并報告給開發(fā)者
二哩至、各階段測試任務與可交付文檔
第三章 各個文檔內(nèi)容介紹
一、 測試計劃
1.如何編寫測試計劃
測試計劃編寫6要素（5W1H）
1）why—為什么要進行這些測試蜜自；
2) what—測試哪些方面菩貌，不同階段的工作內(nèi)容；
3) when—測試不同階段的起止時間重荠；
4) where—相應文檔箭阶，缺陷的存放位置，測試環(huán)境等；
5) who—項目有關人員組成仇参，安排哪些測試人員進行測試
6) how—如何去做嘹叫，使用哪些測試工具以及測試方法進行測試。
2.通用測試計劃應包含以下幾個項目：
? 測試目的冈敛、背景待笑、范圍
? 具體目標：列出需要測試和不需要測試部分
? 測試的策略：采用的測試方法
? 測試通過的標準，以及沒有通過的處理辦法
? 停止測試的標準
? 測試用例
? 測試的基本支持
? 部門責任分工抓谴、人力資源分配
? 測試進度安排
? 風險估計和危機處理
3.測試計劃的組成部分
? 引言：目的暮蹂、背景、范圍癌压、定義仰泻、參考資料
? 測試內(nèi)容：測試功能清單
? 測試規(guī)則：進入準則，暫停/退出準則滩届、測試方法集侯、測試手段、測試要點帜消、測試工具
? 測試環(huán)境：硬件環(huán)境棠枉、軟件環(huán)境、特定測試環(huán)境要求
? 項目任務：測試規(guī)劃泡挺，測試設計辈讶，測試執(zhí)行準備，測試執(zhí)行娄猫，測試總結(jié)
? 實施計劃：工作量估計贱除、人員需求及安排、進度安排媳溺、其它資源需求及安排月幌、可交付工件
? 風險管理
二、 缺陷報告（bug報告）
三悬蔽、 測試用例
測試用例應該包含：測試用例表扯躺、測試用例清單、測試結(jié)果統(tǒng)計表蝎困、測試結(jié)果統(tǒng)計表缅帘、測試問題表、測試問題統(tǒng)計表难衰、測試進度表钦无、測試總結(jié)表（測試評估）
1.測試用例表的組成部分
項目名稱? 測試編號 功能模塊名 功能特性 測試目的 優(yōu)先級 測試類型 預置條件 操作步驟 預期結(jié)果 實際結(jié)果 備注
四、測試總結(jié)
1.測試報告的版本
2.測試的人員和時間
3.測試所覆蓋的缺陷——測試組在這輪測試中所有處理的缺陷盖袭，報告了測試組長處理的缺陷和實施工程師驗證的缺陷失暂。不僅要寫出覆蓋缺陷的總數(shù)彼宠，還要寫明這些缺陷的去向，測試新發(fā)現(xiàn)的缺陷數(shù)量 弟塞，上一版本活動缺陷的數(shù)量 凭峡，經(jīng)過此輪測試蕊连，所有活動缺陷的數(shù)量及其狀態(tài)分類 作瞄。
4.測試評估——寫明在這一版本中，那些功能被實現(xiàn)了瓣窄，那些還沒有實現(xiàn)系宫，這里只需寫明和上一版本不同之處即可
5.急待解決的問題——寫明當前項目組中面臨的最優(yōu)先的問題索昂，可以重復提出
另外一種測試報告的內(nèi)容：
l 測試資源概述——多少人、多長時間
l 測試結(jié)果摘要——分別描述各個測試需求的測試結(jié)果扩借，產(chǎn)品實現(xiàn)了哪些功能點椒惨，哪些還沒有實現(xiàn)
l 缺陷分析——按照缺陷的屬性分類進行分析
l 測試需求覆蓋率——原先列舉的測試需求的測試覆蓋率，可能一部分測試需求因為資源和優(yōu)先級的因素沒有進行測試潮罪，那么在這里要進行說明
l 測試評估——從總體對項目質(zhì)量進行評估
測試組建議——從測試組的角度為項目組提出工作建議
