2023年4月買的書,2023年1月才讀,罪過罪過,後悔莫及.中括號裡面的內容是自己的評注
第2章:手工測試
1.軟體失效的主要原因是因為開發人員沒有理解,預見或測試所有可以執行軟體的環境 [環境應該只是失效的乙個因素]
2.測試人員擁有那種"如何才能攻破這個功能"的態度和開發人員那種"如何才能實現這個功能"的態度是相輔相成的 [可以說是相輔相成,換個角度也可以說明大家都不完美 ,才導致有分工]
3.程式如果不在真實環境中執行起來,很多缺陷不會被觸發 [參考1,後面也講到環境本身算是一種輸入源]
4.如果想發現與應用程式業務邏輯相關的缺陷,手工測試是最理想的選擇
5.用於記錄探索式測試結果的最佳工具就是那些截圖軟體和記錄擊鍵的工具[有些困惑,難道每次都要記錄?]
6.探索式測試最適用於使用"敏捷開發過程"的web應用程式,因為他們開發時間短,沒時間編寫正式的測試指令碼[依現在的情形看,手機程式應該也是很適合的]
7.探索式測試和指令碼測試算是兩個極端,可以說是一種互補關係
第3章:區域性探索式測試
1.對於軟體測試的艱巨性和複雜性,正確的態度應該是從一開始就要承認無論怎麼做都是不夠的.
2.軟體發布的時候可以達到的目標:所有重要的任務都完成了,而剩下沒做的事情都是比較次要的,這樣就可以較早盡可能地降低發布風險
3.軟體執行的四個基本任務:接受輸入,產生輸出,儲存資料和進行運算
4.測試人員應該牢記,大多數開發人員都不喜歡編寫錯誤處理**[開發與測試的思維方式不同]
5.使用探索式測試法的測試人員必須牢牢抓住顯示的錯誤資訊,我的建議是必須仔細閱讀每一條錯誤資訊
6.測試人員不輸入任何東西並不意味著軟體就不需要花功夫去處理這些情況[此處指預設值]
7.我們選擇下一步使用 哪個輸入的時候,必須考慮從前使用過的那些輸入所造成的累積效應[軟體的狀態]
8.測試人員必須明確知道程式裡可能有哪些分支,並理解哪些輸入會導致軟體走這條分支而不是那一條
第4章:全域性性探索性測試
1.探索式測試的目標
2.任何關於測試計畫的討論都需要首先把軟體劃分成更便於管理的小塊.這裡引入了特性(feature)測試的概念[之前在某公司工作的時候測試計畫裡就會列出程式的feature list]
3.商業區測試:商業區就是軟體包裝盒上描述的那些特性
快遞測試法:快遞移動之時候,能確保系統裡持續更新快遞單子的狀態
深夜測試法/清晨測試法:對應軟體執行維護任務,已經軟體啟動的時候
遍歷測試法:選定乙個目標,然後使用可以發現的最短路徑來訪問目標包含的所有物件
4.歷史區測試:對於軟體來說,它指從前版本遺留下的**,通常難以理解.對於軟體缺陷來說,歷史經常會重演
5.旅遊區:軟體中有些特性對新使用者非常有吸引力
[評注:個人感覺旅遊區裡的方法似乎都是挺通用的方法,歸到旅遊區下顯得有點刻意]
6.娛樂區:軟體的輔助特性和功能
7.旅館區:前面指軟體"休息"的時候的特性(p50),後面指測試計畫中較少描述的次要及輔助功能[兩處地方的定義似乎有點矛盾]
[這兩種同樣是很通用的技巧...]
8.破舊區:
反叛測試法:要求輸入最不可能的資料,或者已知的惡意輸入,不應該出現的資料.以錯誤的順序輸入等
強迫症測試法:反反覆覆地執行同樣的操作,使用者往往會由於弄錯而不得不回頭重乾
第5章:混合探索式測試技術
1.使用者可以根據自己的計畫和時間,隨意增加或減少步驟來改變場景,乙個場景可以演變出許多測試用例
2.通過場景引入變化
刪除步驟:去掉冗餘和可選的步驟
替換步驟:某些步驟有多種方法完成,就可以用替換步驟
重複步驟
替換資料:理解應用程式連線和使用的資料來源
替換環境:替換硬體,替換容器,替換版本,修改本地設定
第6章:實踐中的探索式測試
1.dynamics ax客戶端的漫遊
2.利用漫遊查詢隱錯
3.因為漫遊測試定義了測試什麼和如何測試,所以任何正常的測試人員都能夠執行類似的漫遊,發現類似的缺陷
第7章:漫遊與測試中的棘手問題
1.在微軟公司,對於每乙個被發現的缺陷,明確地討論它應該在什麼時候被發現,基於缺陷的歷史資料分析,我們將學會如何在**審查,單元測試或其他方面我針對性地進行工作
2.農藥悖論:當你向一塊農田裡的作物噴灑農藥時,你將殺死大量的蟲子,但是存活下來的蟲子會增加對這種農藥的抵抗性.要解決殺蟲劑悖論問題,對於測試人員來說,意味著必須調整測試用例,場景和漫遊路徑就是殺蟲劑
3.建好的房屋有一定數量的缺陷,只有人們住進去後才會發現,軟體也不例外.
4.漫遊測試在一定程度上效果更好,因為一條漫遊路徑可以代表任何數量的實際測試用例
第8章:軟體測試的未來
1.thud:測試人員的提示顯示[對於web而言,應該顯示系統日誌,http請求狀態,伺服器狀態等等資訊]
2.測試用例的重用:攜帶環境的測試
3.自我測試能力應該是未來軟體的一項基本功能[這個應該更多地指客戶端程式]
附錄
1.測試門檻很低,但通往精通的道路卻很艱難
2.測試自動化是解決重複勞動的答案
3.我們從開發人員的失敗中學習如何編寫可靠的**.分析我們的成功也同樣重要
4.我們必須使用和尋找產品缺陷一樣的流程來尋找我們自己的測試流程,測試過程中的缺陷
5.相對於那些工程專家,我們對於很多細節從沒有深入思考,而只流於表面的直覺
6.測試過程中考慮使用偵錯程式之類能追蹤動作和軟體狀態的工具
7.每乙個好缺陷背後,都可能隱藏著乙個更好的缺陷.在你確實了解缺陷的影響程度和破壞力之前永遠不要停止搜尋
8.我們不應該抱怨發布日期,而是應該提前警告後果.這是我們的職責範圍,也是我們應該擔心的範圍
9.閱讀源**可以學習到很多東西
10.我們行業所有已知的開發方法所能提供的些許改進,已經遠遠跟不上我們所建立的系統複雜性
11.分析質量問題的流程
12.測試人員評估:真正的評估並不在於衡量找出軟體缺陷的數量,而在於改正這些缺陷後軟體質量得到改善的程度.你可以通過觀察測試人員究竟提高了多少開發人員的工作績效.測試人員是質量控制大師
13.讓設計者以及其他的軟體開發周期裡的角色參與測試才是我們的將來.如果專案中的每個人都理解測試,想象我們需要很少測試人員就可以達到這一目標
14.手工測試能更好地測試業務邏輯,而自動化測試在尋找基礎結構性軟體缺陷上勝過手工測試
15.唯一真正儲存測試歷史智慧型的地方就是在我們的自動化測試工具[個人以為還有測試用例等其他文件]
本文出自"lijingshou"部落格，請務必保留此出處lijingshou.iteye.com/blog/2002829
《軟體測試》 讀書筆記
黑箱測試 在設計測試的過程中，把軟體系統當做乙個 黑箱 無法了解或使用系統的內部結構統計知識。白箱測試 在設計測試的過程中，設計者可以 看到 軟體系統的內部結構，並使用軟體的內部結構和知識來選擇測試資料及具體的測試方法。功能測試 a.單元測試 b.功能測試 c.整合測試 d.場景測試 e.系統測試 ...
軟體測試 讀書筆記
1.軟體測試背景 2002年，軟體測試進一步定義為 測試是為了度量和提高被測試軟體的質量，對測試軟體進行工程設計 實施和維護的整個生命週期過程 2 軟體缺陷 所有的軟體問題都可以統稱為軟體缺陷，可以從以下五點定義軟體缺陷 軟體未達到產品說明書標明的功能 軟體出現了產品說明書指明不會出現的錯誤 軟體功...
《有效軟體測試》 讀書筆記
有效軟體測試 讀書筆記 前言 有效軟體測試 提出提高軟體測試的50條建議。作者從經驗出發，提煉出提公升測試效率的建議。第1章 描述了測試工作在需求階段需要考慮的問題。在需求階段，包括測試組代表在內的主要專案組成員必須參與需求工作，並且必須收到需求變更通知，這是非常 重要的。此外，對於任何大型專案來說...