软件测试

本條目存在以下問題，請協助改善本條目或在討論頁針對議題發表看法。 此條目可参照英語維基百科相應條目来扩充。 若您熟悉来源语言和主题，请协助参考外语维基百科扩充条目。请勿直接提交机械翻译，也不要翻译不可靠、低品质内容。依版权协议，译文需在编辑摘要注明来源，或于讨论页顶部标记{{Translated page}}标签。 此條目已列出參考文獻，但因為沒有文內引註而使來源仍然不明。 (2013年11月20日) 请加上合适的文內引註来改善这篇条目。 此條目需要精通或熟悉相关主题的编者参与及协助编辑。 請邀請適合的人士改善本条目。更多的細節與詳情請參见討論頁。 此條目需要編修，以確保文法、用詞、语气、格式、標點等使用恰当。 請按照校對指引，幫助编辑這個條目。（幫助、討論）

软件开发
核心行动
过程 需求 设计 工程 构造（英语：Software construction） 测试 偵錯 部署 維護
范式与模式
原型设计（英语：Software prototyping） 净室（英语：Cleanroom software engineering） 增量建模（英语：Incremental build model） 瀑布模型 敏捷软件开发 螺旋模型
方法论与框架
快速應用程式開發 DevOps 极限编程 团队软件流程（英语：Team software process） 個人軟體程序 动态系统开发方法（英语：Dynamic systems development method） MSF（英语：Microsoft Solutions Framework） Scrum 看板 V模型 FDD（英语：Feature-driven development） MDD 迭代式开发 精實开发 统一流程（英语：Unified Process）
支持行为
配置管理 文档 质量保证 项目管理 用户体验
实践
ATDD（英语：Acceptance test–driven development） 行为驱动开发 持續整合 持續交付 領域驅動設計 结对编程 站会 测试驱动开发
工具
編譯器 偵錯器 性能分析 GUI设计器（英语：Graphical user interface builder） 建模（英语：UML tools） 集成开发环境 組建自動化 发布自动化（英语：Application release automation） 测试
标准与知识体系
能力成熟度模型集成 IEEE标准 ISO 9001 ISO/IEC标准（英语：ISO/IEC JTC 1/SC 7） SWEBOK（英语：SWEBOK） 项目管理知识体系 BABOK（英语：BABOK）
查 论 编

軟體測試（英語：software testing），描述一種用來促進鑑定軟體的正確性、完整性、安全性和品質的過程。依照可計算理論（計算機科學的一個支派）一個簡單的數學證明推斷出下列結果：不可能完全解決所謂「當機」，指任意電腦程式是否會進入無窮迴圈，或者罷工並產生輸出問題。換句話說，軟體測試是一種實際輸出與預期輸出間的稽核或者比較過程。

软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量軟體品質，并对其是否能满足设计要求进行评估的过程。

軟體測試有許多方法，但對複雜的產品執行有效測試不僅僅是研究過程，更是創造並嚴格遵守某些呆板步驟的大事。測試的其中一個定義：為了評估而質疑產品的過程；這裡的“質疑”是測試員試著對產品做的事，而產品以測試者腳本行為反應作為回答。雖然大部分測試的質疑過程不外乎回顧、檢查，然而「測試」這個词意味著產品動態分析──讓產品流暢運行。程式品質可能，而且通常會，隨系統不同而有差異；不過某些公認特性是共通的：可靠性、穩定性、輕便性、易於維護、以及實用性。請參照至ISO標準ISO 9126有更詳盡的說明。

Alpha測試通常是阶段性的開發完成後所開始進行，一直持續到進入Beta測試階段前的階段。Alpha測試是一種驗證測試，在模擬的環境中以模擬的資料來執行。

在這個階段中，通常是在開發單位由開發人員與測試的測試人員，以模擬或實際操作性的方式進行驗證測試。

在系統測試中通常先進行Alpha測試以驗證資訊系統符合使用者以及設計需求所期望的功能。當Alpha階段完成後，開發過程進入到Beta階段，由公眾參與的測試的階段。Beta測試可稱為確認測試，在一個真實的環境中以實際的資料來執行測試，以確認效能，系統執行有效率，系統復原與備份作業正常，透過測試讓資訊系統日後可以更趨完善。

封閉測試（Closed Beta，常簡作封測或CB）是軟體或服務等產品在開發完成後、將公開上市前的測試過程。相對於公開測試，封閉測試的主要用途是測試軟件的功能和檢查程式錯誤等等，因此通常只提供給少數人進行測試。有些公司會要求參與測試者簽署保密協定，以避免測試的產品提前外流。MMORPG的封測結束之後，遊戲公司常會將角色資料刪除，但也有少數不会删除。

公开测试（Open Beta，常簡作公測或OB），一般常指軟體或服務等產品在正式上市前開放給不特定人試用，雖然原意是希望試用者能夠提報bug，但並不是把試用者當做真正的驗證人員。由於通常為免費性質，故常常能夠吸引到大批的試用者參與，可視為另一種行銷策略。另一方面也節省下測試人員的成本，和驗證穩定度（對於多人使用的頻寬及機器是否能負載，又稱壓力測試）的時間。

Gamma测试是一个很少被提及的非正式测试阶段，该测试阶段对应的是对“存在缺陷”产品的测试。考虑到任何产品都可以被称为“存在缺陷”的产品（测试只能发现产品中存在的问题，不能说明产品不存在问题），因此这个概念存在一定的不确定性。 对Alpha和Beta测试常见的一个誤解是「Beta测试＝黑盒测试」。实际上，Alpha和Beta测试对应在软件产品发布之前的Alpha和Beta阶段，而白盒、黑盒和灰盒测试技术是从技术和方法层面对测试的描述，不应该将这两部分概念混淆。

軟件測試一般分为黑盒测试和白盒测試。

黑盒測試（black-box testing），也称黑箱测试，是軟體測試方法，測試應用程式的功能，而不是其內部結構或運作。測試者不需具備應用程式的程式碼、內部結構和程式語言的專門知識。測試者只需知道什麼是系統應該做的事，即當鍵入一個特定的輸入，可得到一定的輸出。測試案例是依應用系統應該做的功能，照規範、規格或要求等設計。測試者選擇有效輸入和無效輸入來驗證是否正確的輸出。

此測試方法可適合大部分的軟體測試，例如整合測試（integration testing）以及系統測試（system testing）。

白盒測試（white-box testing，又稱透明盒測試glass box testing、結構測試structural testing等）是一個測試軟體的方法，測試應用程式的內部結構或運作，而不是測試應用程式的功能（即黑箱測試）。在白盒測試時，以程式語言的角度來設計測試案例。測試者輸入資料驗證資料流在程式中的流動路徑，並確定適當的輸出，類似測試電路中的節點。

白箱測試可以應用於單元測試（unit testing）、整合測試（integration testing）和系統的軟體測試流程，可測試在整合過程中每一單元之間的路徑，或者主系統跟子系統中的測試。儘管這種測試的方法可以發現許多的錯誤或問題，它可能無法檢測未使用部分的規範。

功能测试	按照测试软件的各个功能划分进行有条理的测试，在功能测试部分要保证测试项覆盖所有功能和各种功能条件组合。
系统测试	对一个完整的软件以用户的角度来进行测试，系统测试和功能测试的区别是，系统测试利用的所有测试数据和测试的方法都要模拟成和用户的实际使用环境完全一样，测试的软件也是经过系统集成以后的完整软件系统，而不是在功能测试阶段利用的每个功能模块单独编译后生成的可执行程序。
极限值测试	对软件在各种特殊条件，特殊环境下能否正常运行和软件的性能进行测试。 特殊条件一般指的是软件规定的最大值，最小值，以及在超过最大、最小值条件下的测试。 特殊环境一般指的是软件运行的机器处于CPU高负荷，或是网络高负荷状态下的测试，根据软件的不同，特殊环境也有过不同。
性能测试	性能测试是对软件性能的评价。简单的说，软件性能衡量的是软件具有的响应及时度能力。因此，性能测试是采用测试手段对软件的响应及时性进行评价的一种方式。根据软件的不同类型，性能测试的侧重点也不同。

压力测试常常和性能测试相混淆。它们主要不同点是，压力测试要求进行超过规定性能指标的测试。例如一个网站设计容量是100个人同时点击，压力测试就要是采用120个同时点击的条件测试。

压力测试的通常判断准则：

1. 系统能够恢复。
2. 压力过程中不要有明显性能下降。

单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位：函數。
並且使用假資料測試不同狀況下功能使用情況，單元測試還有助於開發人員編寫更好的代碼。
單元測試是基於code的:可讀性、可測試性，它們與開發代碼的構建方式密切相關。因此開發人員最清楚哪些測試最有意義。

整合测试也称综合测试、组装测试、联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。

系统测试主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。

回归测试(regression test)指在软件维护阶段，为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件维护阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。

与普通的测试不同，在回归测试过程开始的时候，测试者有一个完整的测试用例集可供使用，因此，如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向，此外，回归测试的研究方向还涉及自动化工具，面向对象回归测试，测试用例优先级，回归测试用例补充生成等。

• 測試原有功能
• 測試新加入的功能是否有side effect

代碼覆蓋率原本是種白箱測試活動。目標軟體通過特殊選項或者函式館編譯並且/或者在特殊環境（程式裡每個函式都被映射回原始碼裡函式起點）下執行。這個過程允許開發員與品管員檢視系統中在正常情況下極少或從未被讀寫的部分（例如：例外處理之類）並且幫助測試員確認最重要的情況（函式點）都被測過了。

測試員可檢視代碼覆蓋率測試結果來設計測試個案、相對應的輸入或者設定組以增加重要函式的代碼覆蓋率。兩種測試員常用的代碼覆蓋率形式：陳述式覆蓋率（或稱行覆蓋率）以及路徑覆蓋率（或稱邊覆蓋率）。行覆蓋率回報到測試完成時，執行過哪些行，或者記憶體大小。邊覆蓋率回報到測試完成時，哪些分支，或者程式決定點被執行過。正如覆蓋率的「率」字所言，這兩個都以百分比為單位。

通常代碼覆蓋率的工具與函式館要求的效能、記憶體、或者其他資源開銷不為正常的軟體營運接受。因此它們通常只存在實驗室裡。又，你可能會想到軟體裡的許多類無法一一通過這些代碼覆蓋率測試，雖然代碼覆蓋程度可通過分析但不是直接測試。

有些瑕疵也會受這些工具的影響。個別來說某些竞態條件（race condition）或者類似的對即時（real time）敏感度高的操作幾乎不可能在代碼覆蓋率測試環境下偵知；相反的這類的瑕疵只會帶來更多的測試碼開銷。

自動化測試是使用软件工具和既定程序，对软件所进行的测试活动。

• 郑人杰，《计算机软件测试技术》，清华大学出版社

• 程序错误
• 黑盒测试
• 白盒测试
• 软件测试模型
• 软件质量
• 軟體驗證及確認