最新章節

• 附錄B 參考書目和資源
• A.5 系統測試類型
• A.4 根據測試的執行方式進行劃分
• A.3 根據所處的開發階段和作用不同進行劃分
• A.2 根據程序的運行狀態進行劃分
• A.1 根據對代碼的可視程度進行劃分

• 附錄B 參考書目和資源 更新時間：2018-12-30 19:02:02
• A.5 系統測試類型
• A.4 根據測試的執行方式進行劃分
• A.3 根據所處的開發階段和作用不同進行劃分
• A.2 根據程序的運行狀態進行劃分
• A.1 根據對代碼的可視程度進行劃分
• 附錄A 專業名詞解釋
• 13.6.2 選擇一條適合自己的測試康莊大道
• 13.6.1 識別自己——英雄不問出處
• 13.6 通向“羅馬”的測試之路
• 13.5 測試是不可或缺的“一條腿”
• 13.4 挑戰測試新技術
• 13.3 測試設計理念至上
• 13.2.4 測試事業部
• 13.2.3 測試部落
• 13.2.2 測試游擊隊
• 13.2.1 散兵游勇年代
• 13.2 暢想：測試團隊的發展之路
• 13.1 開拓測試管理新思維：測試環境創新
• 第13章 逐軟測之理念
• 12.5.3 案例3：兩個阿慢的故事
• 12.5.2 案例2：測試需求實現的故事
• 12.5.1 案例1：測試工作量評估
• 12.5 優秀測試團隊的組合模式
• 12.4.2 案例2：招聘實習生執行用例
• 12.4.1 案例1：測試時間變長了
• 12.4 測試設計與測試執行人員分開模式
• 12.3.2 案例2：傷不起，自動構建惹的禍
• 12.3.1 案例1：軟件沒有任何更改卻不正常了
• 12.3 基于流程的測試模式
• 12.2.5 案例4：用服的抱怨
• 12.2.4 案例3：我們真的了解用戶嗎
• 12.2.3 案例2：參展機真的累了嗎
• 12.2.2 案例1：生產出來的機器開機失敗
• 12.2.1 識別用戶
• 12.2 基于用戶環的測試模式
• 12.1 了解測試模式設計
• 第12章 試模式的設計
• 11.3 測試的宗旨
• 11.2.4 對質量模型的進一步思考
• 11.2.3 軟件質量模型——工程實踐式解讀
• 11.2.2 測試人員談軟件質量
• 11.2.1 軟件質量的標準定義
• 11.2 軟件質量模型到底是什么
• 11.1 軟件質量與測試的幾個故事
• 第11章 件質量與測試的故事
• 10.5.5 漏測措施執行跟蹤
• 10.5.4 漏測分析實施
• 10.5.3 漏測分析計劃
• 10.5.2 漏測問題收集
• 10.5.1 漏測的定義與漏測分析的意義
• 10.5 漏測分析：測試流程改進的助推器
• 10.4.2 測試配置的構建與應用
• 10.4.1 測試也需“電子眼”
• 10.4 測試配置管理
• 10.3.3 測試與版本號
• 10.3.2 版本接收/停止測試準則
• 10.3.1 版本發布眾生相
• 10.3 測試版本的控制
• 10.2.3 設計檢查單——提高設計質量的有效工具
• 10.2.2 自審檢查單的誕生
• 10.2.1 三級評審機制
• 10.2 測試設計的評審
• 10.1.2 項目測試啟動會
• 10.1.1 測試人員何時投入項目合適
• 10.1 把握測試工作啟動的起點
• 第10章 控制測試過程的實用方法
• 9.5.3 學以致用打折嗎
• 9.5.2 測試知識庫的管理
• 9.5.1 沉淀測試知識庫
• 9.5 測試知識庫設計
• 9.4.2 測試工作日志
• 9.4.1 寫總結的好處
• 9.4 測試總結管理設計
• 9.3.3 測試報告模板設計
• 9.3.2 測試方案模板設計
• 9.3.1 測試計劃模板設計
• 9.3 測試文檔模板設計
• 9.2.3 用例維護的設計
• 9.2.2 用例結構與元素的設計
• 9.2.1 用例管理工具選擇
• 9.2 用例管理
• 9.1.6 處理不可重現的Bug
• 9.1.5 Bug庫的應用雜談
• 9.1.4 約束的力量——Bug管理規范
• 9.1.3 Bug生命周期設計
• 9.1.2 Bug管理工具的選擇
• 9.1.1“Bug單”的故事
• 9.1 Bug管理
• 第9章 測試輸出管理設計
• 8.4.3 交叉測試后的進一步思考
• 8.4.2 交叉測試模式
• 8.4.1 交叉測試的特點
• 8.4 交叉測試
• 8.3.3 基于Bug的回歸測試方法
• 8.3.2 基于用例的回歸測試方法
• 8.3.1 確定回歸內容
• 8.3 回歸測試
• 8.2.3 版本發布的信息傳遞
• 8.2.2 小議冒煙測試
• 8.2.1 版本發布的惡夢
• 8.2 內部版本發布測試
• 8.1.5 需求測試中的幾個問題
• 8.1.4 需求測試檢查點
• 8.1.3 測試設計過程中的測試需求
• 8.1.2 需求外審中的測試需求
• 8.1.1 需求內審中的測試需求
• 8.1 需求測試
• 第8章 測試執行流程設計
• 7.8 用例設計規范的誕生
• 7.7 用例重構
• 7.6 設計可復用的用例
• 7.5 用例的價值
• 7.4 用例有效、無效的正確認識
• 7.3.5 用例設計的綜合策略
• 7.3.4 倒推法
• 7.3.3 反常規操作法
• 7.3.2 分類法
• 7.3.1 隱式邊界
• 7.3 技術攻關：高效用例設計方法
• 7.2 逆境中的用例設計
• 7.1 漏測一個提示界面，不僅損失158萬元
• 第7章 話說用例的設計
• 6.6.2 應用案例
• 6.6.1 代碼更改追溯分析法的原理
• 6.6 代碼更改追溯分析法
• 6.5.2 應用案例
• 6.5.1 業務狀態變遷分析法的原理
• 6.5 業務狀態變遷分析法
• 6.4.2 應用案例
• 6.4.1 多叉樹節點分析法的原理
• 6.4 多叉樹節點分析法
• 6.3.2 應用案例
• 6.3.1 三層架構模式分析法的原理
• 6.3 三層架構模式分析法
• 6.2 創新樂園：多路測試分析方法
• 6.1.3 把握核心——測試方案設計的三步曲
• 6.1.2 測試方案設計的重要性
• 6.1.1 疑問與認識過程
• 6.1 理解測試方案的設計
• 第6章 聚焦測試方案的設計
• 5.7 測試策略需考慮的其他要素
• 5.6 測試計劃與跟蹤機制
• 5.5.5 著眼專項測試
• 5.5.4 部分自動化測試
• 5.5.3 靈活運用灰盒測試
• 5.5.2 適當采用白盒測試
• 5.5.1 黑盒測試不等于手工測試
• 5.5 測試技術的裁剪與合理應用
• 5.4 布道——部署測試策略
• 5.3 確定頂層方向性測試類別
• 5.2.3 不可忽視：從設計需求中提取測試需求
• 5.2.2 需求定義也會錯并不是謊言
• 5.2.1 快速理解需求的捷徑：需求宣講
• 5.2 識別廬山真面目——分析需求
• 5.1.2 考慮可測試性需求
• 5.1.1 多管齊下溯需求
• 5.1 從測試需求開始
• 第5章 測試需求分析與測試策略制定
• 4.4.3 突破起點——搭建測試框架的方法
• 4.4.2 化抽象為具體——測試框架內容
• 4.4.1 相框與測試框架
• 4.4 測試建設之基石——測試框架的設計
• 4.3 萬里航行總舵手——業務測試架構的設計
• 4.2.3 架構合適的測試管理方向發展軌道
• 4.2.2 架構合適的測試技術發展梯隊通道
• 4.2.1 回顧與思考微軟的測試職業發展路線設計
• 4.2 讓每個測試人員都看到希望
• 4.1.2 測試架構設計不僅僅在技術上
• 4.1.1 認知測試架構
• 4.1 思索測試架構
• 第4章 測試架構的設計
• 3.5.2 解開用例失效之謎
• 3.5.1 通信的心跳在狂蹦
• 3.5 好鋼用在刀刃上：測試技術應用之合適設計
• 3.4.3 軟件運行得猶如蝸牛在爬行
• 3.4.2 讓大家一起忙起來
• 3.4.1 認識測試流程
• 3.4 提高測試效率的有力武器：測試流程之設計
• 3.3.3 獨立的測試組織模式
• 3.3.2 以項目經理為核心的組織模式
• 3.3.1 以開發為核心的組織模式
• 3.3 測試管理中的隱形指揮棒：測試組織模式的設計
• 3.2 解讀測試設計
• 3.1 放眼設計
• 第3章 測試設計景觀
• 2.4.3“零缺陷”后的誤區
• 2.4.2“零缺陷”文化
• 2.4.1 缺陷的防與堵
• 2.4 測試的第三重境界：挑戰零缺陷
• 2.3.2 測試的服務鏈
• 2.3.1 測試的價值不僅僅是發現Bug
• 2.3 測試的第二重境界：站在Bug之上
• 2.2.3 驀然回首——關閉Bug
• 2.2.2 為伊消得人憔悴——定位Bug
• 2.2.1 獨上高樓——發現Bug
• 2.2 測試的第一重境界：圍著Bug轉
• 2.1.2 發散性思維
• 2.1.1 逆向思維
• 2.1 情有獨鐘的思維模式
• 第2章 找Bug的核心思維與境界
• 1.4.5 軟件測試流程
• 1.4.4 軟件測試方法
• 1.4.3 軟件測試策略
• 1.4.2 軟件測試基本目的
• 1.4.1 軟件測試基本概念
• 1.4 測試基礎簡要
• 1.3.3 卓越測試
• 1.3.2 優秀測試
• 1.3.1 測試入門
• 1.3 把握測試崗位
• 1.2.3 美F-22機群系統癱瘓，軟件質量威脅國家安全
• 1.2.2 奧運門票銷售系統被迫關閉
• 1.2.1 惠普100款筆記本軟件曝嚴重漏洞
• 1.2 Bug就在我們身邊
• 1.1.2 捉蟲子與挖金礦
• 1.1.1 書中一角到書山一角的跨越
• 1.1 關于軟件測試
• 第1章 朝陽中的軟件測試
• 致謝
• 前言
• 業界專家的評論
• 推薦序
• 再版序
• 版權信息
• 封面

• 封面
• 版權信息
• 再版序
• 推薦序
• 業界專家的評論
• 前言
• 致謝
• 第1章 朝陽中的軟件測試
• 1.1 關于軟件測試
• 1.1.1 書中一角到書山一角的跨越
• 1.1.2 捉蟲子與挖金礦
• 1.2 Bug就在我們身邊
• 1.2.1 惠普100款筆記本軟件曝嚴重漏洞
• 1.2.2 奧運門票銷售系統被迫關閉
• 1.2.3 美F-22機群系統癱瘓，軟件質量威脅國家安全
• 1.3 把握測試崗位
• 1.3.1 測試入門
• 1.3.2 優秀測試
• 1.3.3 卓越測試
• 1.4 測試基礎簡要
• 1.4.1 軟件測試基本概念
• 1.4.2 軟件測試基本目的
• 1.4.3 軟件測試策略
• 1.4.4 軟件測試方法
• 1.4.5 軟件測試流程
• 第2章 找Bug的核心思維與境界
• 2.1 情有獨鐘的思維模式
• 2.1.1 逆向思維
• 2.1.2 發散性思維
• 2.2 測試的第一重境界：圍著Bug轉
• 2.2.1 獨上高樓——發現Bug
• 2.2.2 為伊消得人憔悴——定位Bug
• 2.2.3 驀然回首——關閉Bug
• 2.3 測試的第二重境界：站在Bug之上
• 2.3.1 測試的價值不僅僅是發現Bug
• 2.3.2 測試的服務鏈
• 2.4 測試的第三重境界：挑戰零缺陷
• 2.4.1 缺陷的防與堵
• 2.4.2“零缺陷”文化
• 2.4.3“零缺陷”后的誤區
• 第3章 測試設計景觀
• 3.1 放眼設計
• 3.2 解讀測試設計
• 3.3 測試管理中的隱形指揮棒：測試組織模式的設計
• 3.3.1 以開發為核心的組織模式
• 3.3.2 以項目經理為核心的組織模式
• 3.3.3 獨立的測試組織模式
• 3.4 提高測試效率的有力武器：測試流程之設計
• 3.4.1 認識測試流程
• 3.4.2 讓大家一起忙起來
• 3.4.3 軟件運行得猶如蝸牛在爬行
• 3.5 好鋼用在刀刃上：測試技術應用之合適設計
• 3.5.1 通信的心跳在狂蹦
• 3.5.2 解開用例失效之謎
• 第4章 測試架構的設計
• 4.1 思索測試架構
• 4.1.1 認知測試架構
• 4.1.2 測試架構設計不僅僅在技術上
• 4.2 讓每個測試人員都看到希望
• 4.2.1 回顧與思考微軟的測試職業發展路線設計
• 4.2.2 架構合適的測試技術發展梯隊通道
• 4.2.3 架構合適的測試管理方向發展軌道
• 4.3 萬里航行總舵手——業務測試架構的設計
• 4.4 測試建設之基石——測試框架的設計
• 4.4.1 相框與測試框架
• 4.4.2 化抽象為具體——測試框架內容
• 4.4.3 突破起點——搭建測試框架的方法
• 第5章 測試需求分析與測試策略制定
• 5.1 從測試需求開始
• 5.1.1 多管齊下溯需求
• 5.1.2 考慮可測試性需求
• 5.2 識別廬山真面目——分析需求
• 5.2.1 快速理解需求的捷徑：需求宣講
• 5.2.2 需求定義也會錯并不是謊言
• 5.2.3 不可忽視：從設計需求中提取測試需求
• 5.3 確定頂層方向性測試類別
• 5.4 布道——部署測試策略
• 5.5 測試技術的裁剪與合理應用
• 5.5.1 黑盒測試不等于手工測試
• 5.5.2 適當采用白盒測試
• 5.5.3 靈活運用灰盒測試
• 5.5.4 部分自動化測試
• 5.5.5 著眼專項測試
• 5.6 測試計劃與跟蹤機制
• 5.7 測試策略需考慮的其他要素
• 第6章 聚焦測試方案的設計
• 6.1 理解測試方案的設計
• 6.1.1 疑問與認識過程
• 6.1.2 測試方案設計的重要性
• 6.1.3 把握核心——測試方案設計的三步曲
• 6.2 創新樂園：多路測試分析方法
• 6.3 三層架構模式分析法
• 6.3.1 三層架構模式分析法的原理
• 6.3.2 應用案例
• 6.4 多叉樹節點分析法
• 6.4.1 多叉樹節點分析法的原理
• 6.4.2 應用案例
• 6.5 業務狀態變遷分析法
• 6.5.1 業務狀態變遷分析法的原理
• 6.5.2 應用案例
• 6.6 代碼更改追溯分析法
• 6.6.1 代碼更改追溯分析法的原理
• 6.6.2 應用案例
• 第7章 話說用例的設計
• 7.1 漏測一個提示界面，不僅損失158萬元
• 7.2 逆境中的用例設計
• 7.3 技術攻關：高效用例設計方法
• 7.3.1 隱式邊界
• 7.3.2 分類法
• 7.3.3 反常規操作法
• 7.3.4 倒推法
• 7.3.5 用例設計的綜合策略
• 7.4 用例有效、無效的正確認識
• 7.5 用例的價值
• 7.6 設計可復用的用例
• 7.7 用例重構
• 7.8 用例設計規范的誕生
• 第8章 測試執行流程設計
• 8.1 需求測試
• 8.1.1 需求內審中的測試需求
• 8.1.2 需求外審中的測試需求
• 8.1.3 測試設計過程中的測試需求
• 8.1.4 需求測試檢查點
• 8.1.5 需求測試中的幾個問題
• 8.2 內部版本發布測試
• 8.2.1 版本發布的惡夢
• 8.2.2 小議冒煙測試
• 8.2.3 版本發布的信息傳遞
• 8.3 回歸測試
• 8.3.1 確定回歸內容
• 8.3.2 基于用例的回歸測試方法
• 8.3.3 基于Bug的回歸測試方法
• 8.4 交叉測試
• 8.4.1 交叉測試的特點
• 8.4.2 交叉測試模式
• 8.4.3 交叉測試后的進一步思考
• 第9章 測試輸出管理設計
• 9.1 Bug管理
• 9.1.1“Bug單”的故事
• 9.1.2 Bug管理工具的選擇
• 9.1.3 Bug生命周期設計
• 9.1.4 約束的力量——Bug管理規范
• 9.1.5 Bug庫的應用雜談
• 9.1.6 處理不可重現的Bug
• 9.2 用例管理
• 9.2.1 用例管理工具選擇
• 9.2.2 用例結構與元素的設計
• 9.2.3 用例維護的設計
• 9.3 測試文檔模板設計
• 9.3.1 測試計劃模板設計
• 9.3.2 測試方案模板設計
• 9.3.3 測試報告模板設計
• 9.4 測試總結管理設計
• 9.4.1 寫總結的好處
• 9.4.2 測試工作日志
• 9.5 測試知識庫設計
• 9.5.1 沉淀測試知識庫
• 9.5.2 測試知識庫的管理
• 9.5.3 學以致用打折嗎
• 第10章 控制測試過程的實用方法
• 10.1 把握測試工作啟動的起點
• 10.1.1 測試人員何時投入項目合適
• 10.1.2 項目測試啟動會
• 10.2 測試設計的評審
• 10.2.1 三級評審機制
• 10.2.2 自審檢查單的誕生
• 10.2.3 設計檢查單——提高設計質量的有效工具
• 10.3 測試版本的控制
• 10.3.1 版本發布眾生相
• 10.3.2 版本接收/停止測試準則
• 10.3.3 測試與版本號
• 10.4 測試配置管理
• 10.4.1 測試也需“電子眼”
• 10.4.2 測試配置的構建與應用
• 10.5 漏測分析：測試流程改進的助推器
• 10.5.1 漏測的定義與漏測分析的意義
• 10.5.2 漏測問題收集
• 10.5.3 漏測分析計劃
• 10.5.4 漏測分析實施
• 10.5.5 漏測措施執行跟蹤
• 第11章 件質量與測試的故事
• 11.1 軟件質量與測試的幾個故事
• 11.2 軟件質量模型到底是什么
• 11.2.1 軟件質量的標準定義
• 11.2.2 測試人員談軟件質量
• 11.2.3 軟件質量模型——工程實踐式解讀
• 11.2.4 對質量模型的進一步思考
• 11.3 測試的宗旨
• 第12章 試模式的設計
• 12.1 了解測試模式設計
• 12.2 基于用戶環的測試模式
• 12.2.1 識別用戶
• 12.2.2 案例1：生產出來的機器開機失敗
• 12.2.3 案例2：參展機真的累了嗎
• 12.2.4 案例3：我們真的了解用戶嗎
• 12.2.5 案例4：用服的抱怨
• 12.3 基于流程的測試模式
• 12.3.1 案例1：軟件沒有任何更改卻不正常了
• 12.3.2 案例2：傷不起，自動構建惹的禍
• 12.4 測試設計與測試執行人員分開模式
• 12.4.1 案例1：測試時間變長了
• 12.4.2 案例2：招聘實習生執行用例
• 12.5 優秀測試團隊的組合模式
• 12.5.1 案例1：測試工作量評估
• 12.5.2 案例2：測試需求實現的故事
• 12.5.3 案例3：兩個阿慢的故事
• 第13章 逐軟測之理念
• 13.1 開拓測試管理新思維：測試環境創新
• 13.2 暢想：測試團隊的發展之路
• 13.2.1 散兵游勇年代
• 13.2.2 測試游擊隊
• 13.2.3 測試部落
• 13.2.4 測試事業部
• 13.3 測試設計理念至上
• 13.4 挑戰測試新技術
• 13.5 測試是不可或缺的“一條腿”
• 13.6 通向“羅馬”的測試之路
• 13.6.1 識別自己——英雄不問出處
• 13.6.2 選擇一條適合自己的測試康莊大道
• 附錄A 專業名詞解釋
• A.1 根據對代碼的可視程度進行劃分
• A.2 根據程序的運行狀態進行劃分
• A.3 根據所處的開發階段和作用不同進行劃分
• A.4 根據測試的執行方式進行劃分
• A.5 系統測試類型
• 附錄B 參考書目和資源 更新時間：2018-12-30 19:02:02