软件测试
 |
建議将封閉測試合併到本條目或章節。（討論） |
軟體測試（英文：Software Test），描述一種用來促進鑑定軟體的正確性、完整性、安全性、和品質的過程。據此，您可能會想，軟體測試永遠不可能完整的確立任意電腦軟體的正確性。然而，在可計算理論──計算機科學的一個支派── 一個簡單的數學證明推斷出下列結果：不可能完全解決所謂「當機」(指任意電腦程式是否會進入 無限迴圈、或者罷工並產生輸出) 問題。換句話說，軟體測試是一種實際輸出與預期輸出間的稽核或者比較過程。
软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量軟體品質，并对其是否能满足设计要求进行评估的过程。
軟體測試有許多方法，但對複雜的產品執行有效測試不僅僅是研究過程，更是創造並嚴格遵守某些呆板步驟的大事。測試的其中一個定義：“為了評估而質疑產品的過程”──這裡的“質疑”是測試員試著對產品做的事，而產品以測試者腳本行為反應作為回答。雖然大部分測試的智力過程不外乎回顧、檢查，然而“測試”這個辭意味著產品動態分析──讓產品流暢運行。程式品質可能，而且通常會，隨系統不同而有差異；不過某些公認特性是共通的：可靠性、穩定性、輕便性、易於維護、以及實用性。請參照至 ISO 標準 ISO 9126 有更詳盡的說明。
| 软件开发 |
| 软件开发步骤 |
| 需求分析 | 软件架构 | 软件设计 | 软件编程 | 软件测试 | 软件部署 |
| 软件开发模式 |
| 敏捷开发 | Cleanroom | 迭代式开发 | RAD | 统一过程 | 螺旋模型 | 瀑布模型 | 极限编程 | Scrum |
| 软件开发辅助领域 |
| 配置管理 | 文档编写 | 质量管理 | 项目管理 | 使用者經驗設計 |
| 软件开发工具 |
| 编译器 | 除错器 | 性能分析 | GUI设计 | 集成开发环境 |
目录 |
[编辑] 软件测试介绍
软件测试一度被认为是编程能力偏低的员工的工作，直到今天，仍然有许多公司把优秀的人才放在编码上，也有更多公司让优秀的人才进行设计，可是很少公司让优秀的人才进行测试工作。实际的软件工程实践证明，让对软件思想有深刻理解的工程师进行软件测试，可以大幅度的提高软件质量。
[编辑] 測試的進程
[编辑] Alpha测试
Alpha测试通常是阶段性的開發完成後所開始進行，一直持續到進入Beta測試階段前的階段。
在這個階段中，通常是在軟體由潛在使用者/客戶或一個獨立的測試團隊，採用現成軟體，以模擬或實際操作性的黑盒测试和灰盒测试進行內部驗收測試。
[编辑] Beta测试
当Alpha阶段完成后，开发过程进入到Beta阶段。在Beta阶段，用于Beta测试的产品被發布(release)到一部分受控制的公司外部人员手中，通过这部分受控制的外部人员的测试和反馈，Beta阶段可以尽量发现产品中存在的缺陷和错误。在某些情况下，Beta版本可能被发放到范围更广的外部人员手中（例如，通过网站下载或是其他方式面向公众发放）。
Beta阶段的测试主要使用黑盒测试技术。当然，在Beta阶段，测试人员仍然可以使用白盒测试技术对产品继续进行测试，但我们一般不认为这些测试是Beta测试的一部分。简单来说，我们认为Beta测试就是由一部分受控制的客户进行的黑盒测试。
[编辑] Gamma测试
Gamma测试是一个很少被提及的非正式测试阶段，该测试阶段对应的是对“存在缺陷”产品的测试。考虑到任何产品都可以被称为“存在缺陷”的产品（测试只能发现产品中存在的问题，不能说明产品不存在问题），因此这个概念存在一定的不确定。
对Alpha和Beta测试常见的一个认识误区是“Beta测试＝黑盒测试”。实际上，Alpha和Beta测试对应在软件产品发布之前的Alpha和Beta阶段，而白盒、黑盒和灰盒测试技术是从技术和方法层面对测试的描述，不应该将这两部分概念混淆。
[编辑] 測試的方法
軟件測試一般分为白箱测试和黑箱测試。
[编辑] 黑箱测试
黑箱測試(black-box testing)是軟體測試方法，測試應用程式的功能，而不是其內部結構或運作。測試者不需具備應用程式的程式碼、內部結構和程式語言的專門知識。測試者只需知道什麼是系統應該做的事，即當鍵入一個特定的輸入，可得到一定的輸出。測試案例是依應用系統應該做的功能，照規範、規格或要求等設計。測試者選擇有效輸入和無效輸入來驗證是否正確的輸出。
此測試方法可適合大部分的軟體測試，例如單元測試(unit testing)、整合測試(integration testing)以及系統測試(system testing)。
[编辑] 白箱测试
白箱測試(white-box testing)（又稱透明盒測試glass box testing、結構測試structural testing等）是一個測試軟體的方法，測試應用程式的內部結構或運作，而不是測試應用程式的功能（即黑箱測試）。在白箱測試時，以程式語言的角度來設計測試案例。測試者輸入資料驗證資料流在程式中的流動路徑，並確定適當的輸出，類似測試電路中的節點。
白箱測試可以應用於單元測試(unit testing)、整合測試(integration testing)和系統的軟體測試流程，可測試在整合過程中每一單元之間的路徑，或者主系統跟子系統中的測試。儘管這種測試的方法可以發現許多的錯誤或問題，它可能無法檢測未使用部分的規範。
[编辑] 測試的類型
| 功能测试 | 按照测试软件的各个功能划分进行有条理的测试，在功能测试部分要保证测试项覆盖所有功能和各种功能条件组合。 |
|---|---|
| 系统测试 | 对一个完整的软件以用户的角度来进行测试，系统测试和功能测试的区别是，系统测试利用的所有测试数据和测试的方法都要模拟成和用户的实际使用环境完全一样，测试的软件也是经过系统集成以后的完整软件系统，而不是在功能测试阶段利用的每个功能模块单独编译后生成的可执行程序。 |
| 极限值测试 | 对软件在各种特殊条件，特殊环境下能否正常运行和软件的性能进行测试。 特殊条件一般指的是软件规定的最大值，最小值，以及在超过最大，小值条件下的测试。 特殊环境一般指的是软件运行的机器处于CPU高负荷，或是网络高负荷状态下的测试，根据软件的不同，特殊环境也有过不同。 |
| 性能测试 | 性能测试是对软件性能的评价。简单的说，软件性能衡量的是软件具有的响应及时度能力。因此，性能测试是采用测试手段对软件的响应及时性进行评价的一种方式。根据软件的不同类型，性能测试的侧重点也不同。 |
[编辑] 压力测试与性能测试
压力测试常常和性能测试相混淆。它们主要不同点是，压力测试要求进行超过规定性能指标的测试。例如一个网站设计容量是100个人同时点击，压力测试就要是采用120个同时点击的条件测试。
压力测试的通常判断准则：
- 系统能够恢复。
- 压力过程中不要有明显性能下降。
[编辑] 測試的階段
[编辑] 单元测试
[编辑] 整合测试
[编辑] 系统测试
系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。
[编辑] 回归测试
回归测试指在软件维护阶段，为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件维护阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。
与普通的测试不同，在回归测试过程开始的时候，测试者有一个完整的测试用例集可供使用，因此，如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向，此外，回归测试的研究方向还涉及自动化工具，面向对象回归测试，测试用例优先级，回归测试用例补充生成等。
[编辑] 测试用例、测试脚本和测试场景
[编辑] 测试过程示例
[编辑] 软件测试活动
[编辑] 代碼覆蓋率
代碼覆蓋率原本是種白箱測試活動。目標軟體通過特殊選項或者函式館編譯並且/或者執行在特殊環境──程式裡每個函式都被映射回原始碼裡函式起點──下。這個過程允許開發員與品管員檢視系統中在正常情況下極少或從未被讀寫的部分 (例如：例外處理之類) 並且幫助測試員確認最重要的情況 (函式點) 都被測過了。
測試員可檢視代碼覆蓋率測試結果來設計測試個案、相對應的輸入或者設定組以增加重要函式的代碼覆蓋率。兩種測試員常用的代碼覆蓋率形式：陳述式覆蓋率(或稱行覆蓋率) 以及路徑覆蓋率 (或稱邊覆蓋率)。行覆蓋率回報到測試完成時，執行過哪些行，或者記憶體大小。邊覆蓋率回報到測試完成時，哪些分支、或者程式決定點被執行過。正如覆蓋率的“率”字所言，這兩個都以百分比為單位。
通常代碼覆蓋率的工具與函式館要求的效能、記憶體、或者其他資源開銷不為正常的軟體營運接受。因此它們通常只存在實驗室裡。又，你可能會想到軟體裡的許多類無法一一通過這些代碼覆蓋率測試，雖然代碼覆蓋程度可通過分析但不是直接測試。
有些瑕疵也會受這些工具的影響。個別來說某些竞態條件 (race condition) 或者類似的對即時 (real time) 敏感度高的操作幾乎不可能在代碼覆蓋率測試環境下偵知；相反的這類的瑕疵只會帶來更多的測試碼開銷。
[编辑] 自动化的测试
使用软件工具和既定程序，对软件所进行的测试活动。
[编辑] 参见
[编辑] 参考
- 郑人杰，《计算机软件测试技术》，清华大学出版社
|
||||||||||||||||||||||||||||||||||||||||||||
