軟件測試的實質
- 不需要修復軟件缺陷的原因有幾個：
- 沒有足夠的時間
- 不算真正的軟件缺陷
- 修復的風險太大
- 不值得修復
- 軟件缺陷的定義
- 軟件未實現產品說明書要求的功能
- 軟件出現了產品說明書指明不應該出現的錯誤
- 軟件實現了產品說明書未提到的功能
- 軟件未實現產品說明書雖未明確提及但應該實現的目標
- 軟件難以理解、不易使用、運行速度慢或者軟件測試員認爲最終用戶會認爲不好
檢查產品說明書
- 測試在大分類上可以分爲黑盒測試和白盒測試，也可以分爲靜態測試和動態測試。
- 測試產品說明書屬於靜態黑盒測試
- 對產品說明書進行高級審查
- 假設自己是客戶。瞭解並測試軟件是否符合客戶的要求。
- 研究現有的規範和標準。舉例：公司慣用語和規定，行業要求，政府標準，圖形用戶界面，安全標準。
- 審查和測試類似的軟件。審查競爭產品時需要注意規模，複雜性，測試性，質量和可靠性，安全性。
- 產品說明書低層次測試技術
- 檢查產品說明書屬性：完整，準確，精確，一致，貼切，合理，代碼無關，可測試性。
- 產品說明書術語檢查清單
- 總是、每一種、沒有、所有、從不：看到這些術語，需要考慮違反這些情況的用例。
- 當然、因此、明顯、顯然、必然：這些術語在說服你接受某種假定情況，測試用例需要考慮是否會出現這種假定情況。
- 某些、有時、常常、通常、慣常、經常、大多、幾乎：這些詞太過模糊，有時發生的功能無法進行測試。
- 等等、諸如此類、以此類推、例如：用這種詞語結束的功能清單無法進行測試。功能清單要絕對或者就解釋明確。
- 良好、迅速、廉價、高效、小、穩定：這些是無法量化的術語，無法進行測試。如果說明書中出現這些術語，必須進一步準確定義含義。
- 處理、進行、拒絕、跳過、排除：這些詞語隱藏了大量需要說明的功能。
- 如果···那麼···：這個語句缺少了配套的否則，那麼如果沒有發生會怎麼樣。
黑盒測試
- 動態黑盒測試又叫做行爲測試。清楚了被測試軟件的輸入和輸出之後，接下來要開始定義測試用例。
- 通過性測試和失效性測試是測試軟件的兩種方法。
- 通過性測試實際上是確認軟件至少能做什麼，而不會考驗其能力。
- 失效性測試或錯誤強制測試是純粹爲了破壞軟件而設計和執行的測試用例。
- 等價類劃分
- 在尋找等價類劃分時，可以把軟件具有相似的輸入、相似的輸出、相似的操作的分爲一組。
- 一個等價類或者等價類劃分是指測試相同目標或者暴露相同軟件缺陷的一組測試。
- 等價類劃分的目標是把可能的測試用例集縮減到可控制且仍然足以測試軟件的小範圍內。
- 數據測試
- 對數據進行軟件測試就是在檢查用戶輸入的信息、返回的結果以及中間計算結果是否正確。
- 邊界條件：邊界條件是指軟件運行在計劃操作界限的邊界的情況。提出邊界條件時，一定要測試臨界邊界的有效數據，測試最後一個可能的有效數據，同時測試剛超過邊界的無效數據。
邊界條件數據類型:數值，字符，位置，數量，速度，地點，尺寸。
緩衝區溢出是由邊界條件缺陷引起的，是造成軟件安全問題的頭號原因。 - 次邊界條件（內部邊界條件）：在軟件邊界內部，最終用戶看不到的邊界也是需要檢查的。
-
2的冪：在建立等價類劃分的時候，要考慮等價類劃分是否需要包含2的冪的邊界條件。
冪單位 中文 範圍或值 Bit 位 0 or 1 Nibble 半字節 0-15 Byte 字節 0-255 Word 字 Kilo Mega Giga Tera -
ASCII表：舉例：如果測試進行文本輸入或者文本轉化的軟件，在定義數據劃分包含那些值時，參考一下ASCII。如果規定輸入字符是a ~ z和A ~ Z，那麼非法劃分就應該包含ASCII表中這些字符前後的值@、[、’、和{
字符 ASCII值 字符 ASCII值 Null 0 B 66 Space 32 Y 89 / 47 Z 90 0 48 [ 91 1 49 ’ 96 2 50 a 97 9 57 b 98 : 58 y 121 @ 64 z 122 A 65 { 123
-
- 默認、空白、空值、零值和無：好的軟件通常將輸入內容默認爲邊界內的最小合法值，或者在合法劃分中間的某個合理值，或者返回錯誤提示信息。因爲這些值在軟件中通常進行不同的處理，所以不要把這些值與合法情況進行混合。
- 非法、錯誤、不正確和垃圾數據：這些都是失效性測試的對象。
- 狀態測試：軟件狀態是指軟件當前所處的條件或者模式。軟件測試的另一個方面就是通過不同的狀態驗證程序的邏輯流程，軟件測試員必須測試程序的狀態及其轉換。
- 測試軟件的邏輯流程
- 建立狀態轉換圖
轉換圖應該包含：
軟件可能進入的每一種獨立狀態
從一種狀態進入另一種狀態所需要輸入的條件。這個條件可能是按鍵、菜單選擇、傳感器信號或者電話振鈴等。
進入或者退出某種狀態時的設置條件及輸出結果。包括顯示的菜單和按鈕、設置的標誌位、產生的打印輸出、執行的運算等。這些是狀態轉換時發生的全部或部分現象。 - 減少要測試的狀態及轉換的數量
- 每種狀態至少訪問一次。
- 測試看起來是最常見和最普遍的狀態轉換。
- 測試狀態之間最不常用的分支。
- 測試所有錯誤狀態及其返回值。
- 測試隨機狀態轉換。
- 測試狀態及其轉換包括檢查所有狀態變量，與進入和退出狀態相關的靜態條件、信息、值、功能等。
- 建立狀態轉換圖
- 失敗狀態測試
- 競爭條件和時序錯亂
計算機具備多任務執行能力導致競爭條件問題，由於軟件未預料到運行過程會被中斷，以致造成混亂。 競爭條件測試難以設計，最好是首先仔細查看狀態轉換圖中的每一個狀態，以找出哪些外部影響會中斷該狀態。
以下可能面臨競爭條件：
兩個不同程序同時保存和打開文檔。
共享同一臺打印機，通信端口或者其他外圍設備。
當軟件處於讀取或者改變狀態時按鍵或者單機鼠標
同時關閉或者啓動軟件的多個實例
同時使用不同程序訪問同一個數據庫 - 重複、壓迫和重負：這個測試的目標是那些處理程序員沒有考慮到，但是在極端惡劣的條件下可能發生問題的狀態。
重複測試是不斷執行同樣的操作。進行這種反覆測試的主要原因是檢查是否存在內存泄漏。
壓迫測試使軟件在不夠理想的條件下運行（比如內存小，磁盤空間小、CPU速度慢、調制解調器速度低）。
重負測試儘量提供條件任其發揮。比如，讓軟件處理儘可能大的文件，最大限度發掘軟件的能力。
重複、壓迫和重負測試可以聯合使用，同時進行。
- 競爭條件和時序錯亂
- 測試軟件的邏輯流程
動態白盒測試
- 動態白盒測試（結構化測試）是指利用查看代碼功能和實現方式得到的信息來確定哪些需要測試，哪些不需要測試，如何展開測試。在進行白盒測試之前要先進行黑盒測試。
- 動態白盒測試不僅僅是查看代碼的運行情況，還包括直接測試和控制軟件。
動態白盒測試包括以下4個部分
- 直接測試底層函數、過程、子程序和庫
- 以完整程序的方式從頂層測試軟件
- 從軟件獲得讀取變量和狀態信息的訪問權，以便確定測試與預期結果是否相符，同時強制軟件以正常測試難以實現的方式運行
- 估計執行測試時命中的代碼量和具體代碼，然後調整測試 - 分段測試
- 單元測試和集成測試：採取這種策略很容易隔離軟件缺陷。這種測試有兩條途徑，自底向上和自頂向下。
自底向上的方式需要編寫測試驅動模塊。
自頂向下的方式需要編寫樁模塊。
- 單元測試和集成測試：採取這種策略很容易隔離軟件缺陷。這種測試有兩條途徑，自底向上和自頂向下。
- 數據覆蓋
- 數據流覆蓋指在軟件中完全跟蹤一批數據。
- 次邊界
- 公式和等式通常隱藏在代碼中，從外部看，其形式和影響不是非常明顯。
- 錯誤強制如果執行在調試器中測試的程序，不僅能夠觀察到變量的值，還可以強制改變變量的值。
- 代碼覆蓋
測試數據只是一半的工作，爲了全面覆蓋，還必須測試程序的狀態以及程序的流程。
代碼覆蓋要求通過完全訪問代碼以查看運行測試用例時經過了哪些部分。
代碼覆蓋測試最簡單的形式是利用編譯環境的調試器通過單步執行程序查看代碼。
對於大多數程序進行代碼覆蓋測試要用到稱爲代碼覆蓋分析器（code coverage analyze）- 程序語句和代碼行覆蓋：代碼覆蓋最直接的形式稱爲語句覆蓋或者代碼行覆蓋。目標是保證程序中的每一條語句最少執行一次。
- 分支覆蓋：試圖覆蓋軟件中的所有路徑稱爲路徑覆蓋，而路徑測試中最簡單的是分支測試。分支測試就是每個判斷取真分支和取假分支至少經歷一次。
- 條件覆蓋：使得每個判斷中每個條件的可能取值至少滿足一次，但是未必覆蓋全部的分支。
- 條件組合覆蓋：使得每個判定中條件的各種可能組合至少出現一次。
兼容性測試
- 綜合性測試綜述：軟件兼容性測試是指檢查軟件之間是否能夠正確地交互和共享信息。
- 平臺和應用程序版本
- 向前兼容指可以使用軟件的未來版本。
- 向後兼容指可以使用軟件的以前版本。
- 兼容性測試
在開始兼容性測試任務之前，需要對所有可能的軟件組合等價劃分，使其成爲驗證軟件之間正確交互的最小有效集合。
- 標準和規範
- 高級標準是產品普遍遵守的規則，例如外觀和感受、支持的特性等等。
- 低級標準是本質細節，例如文件格式和網絡通信協議。
- 數據共享兼容性
- 在應用程序之間共享數據實際上是增強軟件的功能。
文件保存和文件讀取是人人共知的數據共享方式。
文件導出和文件導入是許多程序與自身以前版本、其他程序保持兼容的方式。
剪切、複製和粘貼是程序之間無需藉助磁盤傳輸數據的最常見的數據共享方式。
DDE,COM,OLE是Windows中在兩個程序之間傳輸數據的方式。DDE表示動態數據交換，而OLE表示對象鏈接和嵌入。DDE和OLE數據可以實時地在兩個程序之間流動，數據傳輸可以自動進行。
- 在應用程序之間共享數據實際上是增強軟件的功能。
易用性測試
- 優秀的UI標準
-符合標準和規範
-直觀
-一致
-靈活
-舒適
-正確
-實用- 符合標準和規範：如果測試在特定平臺上運行的軟件，就需要把該平臺的標準和規範作爲產品說明書的補充內容。
- 直觀：考慮用戶界面是否潔淨、不唐突、不擁擠。UI的組織和佈局要合理。是否有多餘的功能。
- 一致：被測試軟件本身以及與其他軟件的一致是一個關鍵屬性。在審查產品時考慮以下幾個術語：快捷鍵和菜單選項。術語和命名。聽衆。OK和Cancel按鈕位置。
- 靈活：不要太多，但是足以允許他們選擇想要做的和怎麼做。
狀態跳轉：靈活的軟件在實現同一任務上有更多選擇和方式。結果是增加了通向軟件各種狀態的途徑。狀態轉換圖將變得更加複雜，則需要花更多的時間決定測試的路徑。
狀態終止和跳過：測試具有跳過衆多提示直接去達想要的地方的功能的軟件時，如果中間狀態被跳過或者提前終止，就需要保證在跳過所有狀態或提前終止時變量被設置正確。
數據輸入和輸出：用戶希望有多種方式輸入數據和查看結果。 - 舒適
恰當：軟件外觀和感覺應該與所做的工作和使用者相符。
錯誤處理：程序應該在用戶執行關鍵操作之前提出警告，並且允許用戶恢復由於錯誤操作而丟失的數據。
性能：如果操作緩慢，至少應該向用戶反饋操作持續時間，並且顯示它正在工作。 - 正確：測試UI是否完成了應該做的事情
一般正確性問題在測試產品說明書時可以發現，但是要特別注意：市場定位性偏差，語言和拼寫，不良媒體，是否所見即所得。 - 實用：實用不是指軟件是否實用，而是指具體特性是否實用。
- 輔助選項測試
- 需要考慮視力損傷，聽力損傷，運動損傷，認知和語言障礙。
- 軟件可以有兩種方式提供輔助。最容易的方式是利用平臺或者操作系統內置的支持，軟件只需要遵守啓用輔助選項與鍵盤、鼠標、聲卡和顯示器通信的平臺標準。如果測試軟件不在這些平臺上運行或者本身就是平臺，就需要定義、編制和測試自己的輔助選項。
- Windows提供了以下能力
粘滯鍵，允許Shift、Ctrl或者Alt持續生效，直至按下其他鍵。
篩選鍵，主要防止簡短，重複擊鍵被認可。
切換鍵，在Caps Lock、Scroll Lock 或者NumLock鍵盤模式開啓時播放聲音。
聲音衛士，每當系統發出聲音時，給出可視警告。
聲音顯示，讓程序顯示其聲音或者講話的標題。
高對比度，利用爲了便於視力損傷閱讀而設計的顏色或者字體設置屏幕。
鼠標鍵，允許用鍵盤代替鼠標操作。
串行鍵，設置一個通信端口讀取來自外部非鍵盤設備的擊鍵。
測試文檔
- 軟件文檔類型
- 包裝文字和圖形
- 市場宣傳材料、廣告以及其他插頁
- 授權/註冊登記表
- 最終用戶許可協議(EULA)
- 標籤和不乾膠條
- 安裝和設置指導
- 用戶手冊
- 聯機幫助
- 指南、嚮導和CBT
- 樣例、示例和模板
- 錯誤提示信息
- 好的軟件文檔以下3種方式確保產品的整體質量
- 提高易用性
- 提高可靠性，可靠性是指軟件穩定和堅固的程度。
- 降低支持費用
- 審查文檔要做什麼
- 如果文檔時非代碼的，那麼可以用靜態的過程，可以視之爲技術編輯和技術校對。
- 如果文檔和代碼緊密結合，就要用到動態測試。
計劃測試工作
- 軟件測試文檔：規定測試活動的範圍、方法、資源和進度。明確正在測試的項目，要測試的特性、要執行的測試任務、每個任務的負責人，以及與計劃相關的風險。
- 測試計劃主題
- 定義測試小組的高級期望，明確要測試的是什麼產品，測試計劃過程和軟件測試計劃的目的是什麼，產品的質量和可靠性目標是什麼？
- 人、地點和事，測試計劃明確項目種工作的人，知道如何和他聯繫；知道文檔放在哪裏等等。
- 定義
- 構造，測試計劃應該定義構造的頻率以及期望的質量等級。
- 測試發佈文檔(TRD)，對每一個構造都聲明新特性、不同特性、修復問題和準備測試內容。
- Alpha版本，意在對少數主要客戶和市場進行數量有限的分發。
- Beta版本，意在向潛在客戶廣泛發佈正式的構造。
- 說明書完成，說明書預計完成並且不再更改的日程安排。
- 特性完成，程序員不再向代碼增加新特性，並集中修復缺陷的日期安排。
- 軟件缺陷會議。由測試經理、項目經理、開發經理和產品支持經理組成的團隊，每週召開會議審查軟件缺陷，並確定哪些需要修復，應該如何修復。
- 團隊之間的責任，團隊之間的責任是明確指出可能影響測試工作的任務和交付內容。
- 明確哪些需要測試，哪些不需要測試。
- 測試的階段，要計劃測試的階段，並決定在項目期間是採用一個測試階段還是分階段測試。測試的計劃過程應該明確每一個預定的測試階段，並告知項目小組。
與測試階段相關聯的兩個重要概念是進入和退出規則。每一個階段都必須有客觀定義的規則，明確聲明本階段結束，下一階段開始。 - 測試策略，描述測試小組用於測試整體和每個階段的方法。
- 資源需求，計劃資源需求是確定實現測試策略必備條件的過程，需要考慮到人員，設備，辦公室和實驗室空間，軟件，外包測試公司等等。
- 測試進度。測試進度需要以上所述的全部信息，並將其映射到整個項目進度中。
測試任務擺脫進度破壞的一個方法是測試進度避免定死啓動和停止的日期。
如果測試進度根據測試階段定義的進入和退出規則採用相對日期，那麼明顯測試任務依賴於其他先完成的可交付內容。 - 測試用例。測試計劃過程將決定用什麼方法編寫測試用例，在哪裏保存測試用例，如何使用和維護測試用例。
- 軟件缺陷報告。報告可以有多種方法，使用哪些方法需要進行計劃，以便每個軟件缺陷從發現到修復過程中都被跟蹤。
- 度量和統計。度量和統計是跟蹤項目發展、成效和測試的手段。
實用的測試度量的例子如下
在項目期間每天發現的軟件缺陷總數
仍然需要修復的軟件缺陷清單
根據嚴重程度對當前軟件缺陷評級
每個測試員找出的軟件缺陷總數
從每個特性或者區域發現的軟件缺陷數目 - 風險和問題。測試計劃中常用並且非常實用的部分是明確指出項目的潛在問題或者風險區域。
編寫和跟蹤測試用例
- 測試用例計劃的目標
- 組織。正確的計劃會組織好用例，以便全體測試員與其他項目小組成員有效地審查和使用。
- 重複性。在項目期間有必要多次執行同樣的測試，以尋找新的軟件缺陷，保證老的軟件缺陷得以修復。
- 跟蹤。在整個項目期間需要回答這些問題：計劃執行多少個測試用例？在軟件最終發行版本上執行多少個測試用例？多少個通過，多少個失敗？有被忽略的測試用例嗎？
- 測試（或者不測試）證實。在少數高風險行業中，軟件測試小組必須證明確實執行了計劃執行的測試。正確的測試用例計劃和跟蹤提供了一種證明測試內容的手段。
- 測試用例計劃綜述
- 測試設計說明的目的是組織和描述針對具體特性需要進行的測試。
- 測試設計的內容
標識符，用於引用和標記測試設計說明的唯一標識符。
要測試的特性，測試設計說明包含的軟件特性描述。該部分還將明確指出作爲主要特性的輔助特性需要間接測試的特性。還要列出不被測試的特性。
方法，描述測試軟件特性的通用方法。
測試用例確認，對用於檢查特性的具體測試用例的高級描述和引用。重要的是，這部分不定義實際測試用例值。
通過/失敗規則，描述測試特性的通過和失敗由什麼構成。 - 測試用例
包含信息：
標識符，由測試設計過程說明和測試程序說明引用的唯一標識符
測試項，描述被測試的詳細特性，代碼模塊。應該比測試設計說明中所列的特性更加具體。
輸入說明，該說明列舉送到軟件執行測試用例的所有輸入內容和條件。
輸出說明，描述進行測試用例預期結果。
環境要求，執行測試用例必要的硬件、軟件、測試工具、實用工具、人員等。
特殊過程要求，描述執行測試必須做到的特殊過程要求。
用例之間的依賴性.
表達測試用例的其他選擇有簡單列表、大綱甚至諸如狀態表或數據流程圖之類的圖表。 - 測試程序
標識符，把測試程序與相關測試用例和測試設計捆綁在一起的唯一標識符。
目的，程序的目的以及將要執行的測試用例的引用信息。
特殊要求，執行程序所需的其他程序、特殊測試技術或者特殊設備。
程序步驟，關於執行測試的詳細描述
日誌，指出用什麼方式方法記錄結果和現象
設置，說明如何準備測試
啓動，說明啓動測試的步驟
程序，描述用於運行測試的步驟
度量，描述如何判斷結果
關閉，說明由於意外原因掛起測試的步驟
重啓，告訴測試人員如果出現故障或者關閉以後如何在恰當的時候重啓測試
終止，描述測試正常停止的步驟
重置，說明如何把環境恢復到測試前的狀態
偶然事件，說明如何處理計劃之外的情況。
- 測試用例組織和跟蹤
- 管理和跟蹤系統的方法：
書面文檔，對於小項目可以用紙筆來管理測試用例。
電子表格，這種方法容易使用，容易建立，可以爲測試提供很好的跟蹤和證明。
自定義數據庫，測試用例管理工具，一種爲處理測試用例而專門編程設計的數據庫。
- 管理和跟蹤系統的方法：