軟件測試教程 第二節(jié) 概念篇

從這節(jié)課開始，我們將開始正式進(jìn)入測試課程，在開始第一次軟件測試之前，我們需要先了解軟件測試的一些基本概念。

這些基本概念將幫助我們更加明確工作的目標(biāo)，以便于更快的融入到測試團(tuán)隊中去

在這里我們將回答以下問題：

• 軟件測試的目的和原則
• 什么是需求
• 什么是bug
• 什么是測試用例
• 開發(fā)模型和測試流程
• 配置管理和軟件測試
• 軟件質(zhì)量與軟件測試

軟件測試的目的和原則

1. 好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案。

2. 成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。

3. 測試并不僅僅是為了找出錯誤。通過分析錯誤產(chǎn)生的原因和錯誤的發(fā)生趨勢，可以幫助項目管理者發(fā)現(xiàn)當(dāng)前軟件開發(fā)過程中的缺陷，以便及時改進(jìn)。這種分析也能幫助測試人員設(shè)計出有針對性的測試方法，改善測試的效率和有效性。

4. 沒有發(fā)現(xiàn)錯誤的測試也是有價值的，完整的測試是評定軟件質(zhì)量的一種方法。

5. 根據(jù)測試目的的不同，還有回歸測試、壓力測試、性能測試、安全測試等，分別為了檢驗修改或優(yōu)化過程是否引發(fā)新的問題、軟件所能達(dá)到處理能力和是否達(dá)到預(yù)期的處理能力等。

6. 軟件測試為了建立軟件的信心。

7. 從測試的目的出發(fā)，大概可以分為兩類：為了驗證程序能正常工作的測試；為了驗證程序不能正常運(yùn)行的測試

什么是需求

IEEE定義：軟件需求是
(1)用戶解決問題或達(dá)到目標(biāo)所需條件或權(quán)能(Capability)。
(2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。
(3)一種反映上面(1)或(2)所述條件或權(quán)能的文檔說明。它包括功能性需求及非功能性需求，非功能性需求對設(shè)計和實現(xiàn)提出了限制，比如性能要求，質(zhì)量標(biāo)準(zhǔn)，或者設(shè)計限制。

在多數(shù)軟件公司，會有兩部分需求，一部分是用戶需求，一部分是軟件需求

用戶需求：可以簡單理解為甲方提出的需求，如果沒有甲方，那么就是終端用戶使用產(chǎn)品時必須要完成的任務(wù)。該需求一般比較簡略。

軟件需求：或者叫功能需求，該需求會詳細(xì)描述開發(fā)人員必須實現(xiàn)的軟件功能。

軟件需求是測試人員進(jìn)行測試工作的基本依據(jù)。

案例：

一、用戶需求：

平臺支持郵箱注冊

二、軟件需求：

1.1.1.1     注冊賬號

1.1.1.1.1    功能概述

用戶可以通過填寫郵箱信息在平臺注冊個人用戶。

1.1.1.1.2    用戶角色

匿名用戶。

1.1.1.1.3    前置條件

無。

1.1.1.1.4    輸入

| **序號** | **欄位名稱** | **欄位說明**            | **長度**  | **類型** | **備注** |
| ------ | -------- | ------------------- | ------- | ------ | ------ |
| 1      | 姓名       | 必填，錄入個人姓名           |         | 字符型    |        |
| 2      | 電子郵箱     | 必填，錄入電子郵箱           |         | 字符型    |        |
| 3      | 密碼       | 必輸，輸入的密碼隱藏*號顯示，最短6位 | 6至15    | 字符型    |        |
| 4      | 確認(rèn)密碼     | 必輸，輸入的密碼隱藏*號顯示，最短6位 | 6至15個字符 | 字符型    |        |
| 5      | 驗證碼      | 必填，錄入驗證碼            |         | 字符型    |        |
| 6      | 注冊       | 注冊操作                |         | 操作型    |        |

1.1.1.1.5    處理

1.1.1.1.5.1   基本事件流

1、 用戶選擇注冊；

2、 系統(tǒng)展現(xiàn)用戶協(xié)議界面，并請用戶確認(rèn)是否同意用戶協(xié)議

1)      若用戶不同意協(xié)議，系統(tǒng)禁止用戶注冊。

2)      若用戶同意協(xié)議，用戶進(jìn)行注冊信息填寫。

3、 用戶填寫注冊信息。

 注冊個人，填寫：姓名，電子郵箱，密碼，確認(rèn)密碼，驗證碼。

4、 用戶提交注冊信息；

5、 系統(tǒng)提示用戶并向用戶注冊的電子郵件地址發(fā)送一封含有激活信息的電子郵件。系統(tǒng)并提示用戶，若未收到激活郵件，可使用注冊的郵箱和密碼登錄系統(tǒng)后再次發(fā)送激活郵件。

6、 用戶可執(zhí)行激活操作，直接跳轉(zhuǎn)至注冊郵箱門戶頁面。

7、 用戶通過接收到的電子郵件中的激活信息激活賬號，用戶注冊完成，流程結(jié)束。

1.1.1.1.5.2   擴(kuò)展事件流

1. 用戶注冊并激活成功后，第一次登錄平臺時，提示用戶完善信息；

1.1.1.1.5.3   異常事件流

1. 若用戶未收到激活郵件，可在登錄界面錄入電子郵件及密碼后，再次發(fā)送激活郵件。
2. 每次發(fā)送的激活郵件，僅在發(fā)送郵件后起24小時之內(nèi)有效，超過24小時后需重新發(fā)送激活郵件。

1.1.1.1.6    輸出

用戶注冊成功

1.1.1.1.7    后置條件

該模塊為用戶登陸等的前置模塊。

什么是bug

第一個bug ：
1945年9月的某天，在一間老式建筑里，從窗外飛進(jìn)來一只飛蛾，此時Hopper正埋頭工作在一臺名為Mark Il的計算機(jī)前，并沒有注意到這只即將造就歷史事件的飛蛾。這臺計算機(jī)使用了大量的繼電器（電子機(jī)械裝置，那時還沒有使用晶體管）。突然，Mark II死機(jī)了。Hopper試了很多次還是不能啟動，他開始用各種方法查找問題，最后定位到了某個電路板的繼電器上。Hopper觀察這個繼電器，驚奇地發(fā)現(xiàn)一只飛蛾已經(jīng)被繼電器打死。Hopper小心地用鑷子將飛蛾夾出來，用透明膠布貼到“事件記錄本”中，寫上“第一個發(fā)現(xiàn)蟲子的實例”。Hopper的事件記錄本，連同那只飛蛾，現(xiàn)在都陳列在美國歷史博物館中。
軟件錯誤的一般定義：程序與規(guī)格說明之前不匹配。

注意：以上說法是片面的，準(zhǔn)確的來說：當(dāng)且僅當(dāng)規(guī)格說明是存在的并且正確，程序與規(guī)格說明之間的不匹配才是錯誤。

當(dāng)沒有需求規(guī)格說明書時，判斷標(biāo)準(zhǔn)以最終用戶為準(zhǔn)：當(dāng)程序沒有實現(xiàn)其最終用戶合理預(yù)期的功能要求時，就是軟件錯誤。

案例：
一、錯誤的需求規(guī)格
常見的有需求文字錯誤、業(yè)務(wù)邏輯錯誤等等，一些業(yè)務(wù)錯誤需要深厚的業(yè)務(wù)知識，不容易發(fā)現(xiàn)，所以測試人員一定要對業(yè)務(wù)熟悉
例如:單位用戶可以進(jìn)入編輯頁面，修改單位名稱、組織機(jī)構(gòu)代碼等信息，保存后生效
---這里要根據(jù)具體的業(yè)務(wù)進(jìn)行分析，例如組織機(jī)構(gòu)代碼是全國唯一的，不能隨便修改，修改需要再次審核
二、需求遺漏或者沒有需求說明書
例如：以上一節(jié)的注冊需求為例，需求說明書沒有考慮到的情況：未激活重復(fù)注冊

什么是測試用例

測試過程中可能會遇到以下問題：
–不知道是否較全面的測試了所有功能
–測試的覆蓋率無法衡量
–對新版本的重復(fù)測試很難實施
–存在大量冗余測試影響測試效率

測試用例的產(chǎn)生就是為了解決上述的問題。

測試用例（Test Case）是為了實施測試而向被測試的系統(tǒng)提供的一組集合，這組集合包含：測試環(huán)境、操作步驟、測試數(shù)據(jù)、預(yù)期結(jié)果等要素。

開發(fā)模型和測試流程

隨著軟件工程學(xué)科的發(fā)展，人們對計算機(jī)軟件的認(rèn)識逐漸深入。軟件工作的范圍不僅僅局限在程序編寫，而是擴(kuò)展到了整個軟件生命周期，如軟件基本概念的形成、需求分析、設(shè)計、實現(xiàn)、測試、安裝部署、運(yùn)行維護(hù)，直到軟件被更新和替換新的版本。軟件工程還包括很多技術(shù)性的管理工作，例如過程管理、產(chǎn)品管理、資源管理和質(zhì)量管理，在這些方面也逐步地建立起了標(biāo)準(zhǔn)或規(guī)范。

軟件的生命周期

軟件生命周期是指從軟件產(chǎn)品的設(shè)想開始到軟件不再使用而結(jié)束的時間。
如果把軟件看成是有生命的事物，那么軟件的生命周期可以分成6個階段，即計劃、需求分析、設(shè)計、編碼、測試、運(yùn)行維護(hù)。

瀑布模型（Waterfall Model）:

st=>start: start
op=>operation: 計劃
op1=>operation: 需求分析
op2=>operation: 設(shè)計
op3=>operation: 編碼
op4=>operation: 測試
op5=>operation: 運(yùn)行維護(hù)
e=>end

st(right)->op(right)->op1(right)->op2(right)->op3(right)->op4(right)->e

瀑布模型在軟件工程中占有重要地位，是所有其他模型的基礎(chǔ)框架。瀑布模型的每一個階段都只執(zhí)行一次，因此是線性順序進(jìn)行的軟件開發(fā)模式。

優(yōu)點：
–強(qiáng)調(diào)開發(fā)的階段性；
–強(qiáng)調(diào)早期計劃及需求調(diào)查；
–強(qiáng)調(diào)產(chǎn)品測試。
?缺點：
–依賴于早期進(jìn)行的唯一一次需求調(diào)查，不能適應(yīng)需求的變化；
–由于是單一流程，開發(fā)中的經(jīng)驗教訓(xùn)不能反饋應(yīng)用于本產(chǎn)品的過程；
–風(fēng)險往往遲至后期的測試階段才顯露，因而失去及早糾正的機(jī)會。

瀑布模型的一個最大缺陷在于，可以運(yùn)行的產(chǎn)品很遲才能被看到。這會給項目帶來很大的風(fēng)險，尤其是集成的風(fēng)險。因為如果在需求引入的一個缺陷要到測試階段甚至更后的階段才發(fā)現(xiàn)，通常會導(dǎo)致前面階段的工作大面積返工，業(yè)界流行的說法是：“集成之日就是爆炸之日”。盡管瀑布模型存在很大的缺陷，例如，在前期階段未發(fā)現(xiàn)的錯誤會傳遞并擴(kuò)散到后面的階段，而在后面階段發(fā)現(xiàn)這些錯誤時，可能已經(jīng)很難回頭再修正，從而導(dǎo)致項目的失敗。但是目前很多軟件企業(yè)還是沿用了瀑布模型的線性思想，在這個基礎(chǔ)上做出自己的修改。例如細(xì)化了各個階段，在某些重點關(guān)注的階段之間摻入迭代的思想。

在瀑布模型中，測試階段處于軟件實現(xiàn)后，這意味著必須在代碼完成后有足夠的時間預(yù)留給測試活動，否則將導(dǎo)致測試不充分，從而把缺陷直接遺留給用戶。

螺旋模型（Spiral Model）

一般在軟件開發(fā)初期階段需求不是很明確時，采用漸進(jìn)式的開發(fā)模式。螺旋模型是漸進(jìn)式開發(fā)模型的代表之一。

這對于那些規(guī)模龐大、復(fù)雜度高、風(fēng)險大的項目尤其適合。這種迭代開發(fā)的模式給軟件測試帶來了新的要求，它不允許有一段獨立的測試時間和階段，測試必須跟隨開發(fā)的迭代而迭代。因此，回歸測試的重要性就不言而喻了。

2-1.jpg

優(yōu)點：
–強(qiáng)調(diào)嚴(yán)格的全過程風(fēng)險管理。
–強(qiáng)調(diào)各開發(fā)階段的質(zhì)量。
–提供機(jī)會檢討項目是否有價值繼續(xù)下去。
?缺點：
–引入非常嚴(yán)格的風(fēng)險識別、風(fēng)險分析和風(fēng)險控制，這對風(fēng)險管理的技能水平提出了很高的要求。這需要人員、資金和時間的投入。

增量、迭代

增量開發(fā)能顯著降低項目風(fēng)險，結(jié)合軟件持續(xù)構(gòu)建機(jī)制，構(gòu)成了當(dāng)今流行的軟件工程最佳實踐之一。增量開發(fā)模型，鼓勵用戶反饋，在每個達(dá)代過程中，促使開發(fā)小組以一種循環(huán)的、可預(yù)測的方式驅(qū)動產(chǎn)品的開發(fā)。因此，在這種開發(fā)模式下，每一次的迭代都意味著可能有需求的更改、構(gòu)建出新的可執(zhí)行軟件版本，意味著測試需要頻繁進(jìn)行，測試人員需要與開發(fā)人員更加緊密地協(xié)作。

增量通常和迭代混為一談，但是其實兩者是有區(qū)別的。增量是逐塊建造的概念，例如畫一幅人物畫，我們可以先畫人的頭部，再畫身體，再畫手腳……而迭代是反復(fù)求精的概念，同樣是畫人物畫，我們可以采用先畫整體輪廓，再勾勒出基本雛形，再細(xì)化、著色。

敏捷

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人為首的“輕量”過程派聚集在猶他州的Snowbird，決定把“敏捷”(Agile)作為新的過程家族的名稱。

在會議上，他們提出了《敏捷宣言》（http://agilemanifesto.org/）：
我們通過身體力行和幫助他人來揭示更好的軟件開發(fā)方式。經(jīng)由這項工怍，我們形成了如下價值觀。

個體與交互重于過程和工具
可用的軟件重于完備的文檔
客戶協(xié)作重于合同談判
響應(yīng)變化重于遵循計劃
在每對比對中，后者并非全無價值，但我們更看重前者。

由敏捷宣言可以看出，敏捷其實是有關(guān)軟件開發(fā)的社會工程(Social Engineering)的。敏捷的主要貢獻(xiàn)在于他更多地思考了如何去激發(fā)開發(fā)人員的工作熱情，這是在軟件工程幾十年的發(fā)展過程中相對被忽略的領(lǐng)域。

敏捷開發(fā)有很多種方式，其中scrum是比較流行的一種。

scrum

scrum里面的角色

scrum由product owner(產(chǎn)品經(jīng)理)、scrum master(項目經(jīng)理)和team(研發(fā)團(tuán)隊)組成。

• 其中product owner負(fù)責(zé)整理user story(用戶故事)，定義其商業(yè)價值，對其進(jìn)行排序，制定發(fā)布計劃，對產(chǎn)品負(fù)責(zé)。
• scrum master 負(fù)責(zé)召開各種會議，協(xié)調(diào)項目，為研發(fā)團(tuán)隊服務(wù)。
• 研發(fā)團(tuán)隊則由不同技能的成員組成，通過緊密協(xié)同，完成每一次迭代的目標(biāo)，交付產(chǎn)品。

迭代開發(fā)

與瀑布不同，scrum將產(chǎn)品的開發(fā)分解為若干個小sprint(迭代)，其周期從1周到4周不等，但不會超過4周。參與的團(tuán)隊成員一般是5到9人。每期迭代要完成的user story是固定的。每次迭代會產(chǎn)生一定的交付。

scrum的基本流程

scrum概要圖 禪道

scrum的基本流程如上圖所示：

• 產(chǎn)品負(fù)責(zé)人負(fù)責(zé)整理user story，形成左側(cè)的product backlog。
• 發(fā)布計劃會議：product owner負(fù)責(zé)講解user story，對其進(jìn)行估算和排序，發(fā)布計劃會議的產(chǎn)出就是制定出這一期迭代要完成的story列表，sprint backlog。
• 迭代計劃會議：項目團(tuán)隊對每一個story進(jìn)行任務(wù)分解，分解的標(biāo)準(zhǔn)是完成該story的所有任務(wù)，終每個任務(wù)都有明確的負(fù)責(zé)人，并完成工時的初估計。
• 每日例會：每天scrum master召集站立會議，團(tuán)隊成員回答昨天做了什么今天計劃做什么，有什么問題。
• 演示會議：迭代結(jié)束之后，召開演示會議，相關(guān)人員都受邀參加，團(tuán)隊負(fù)責(zé)向大家展示本次迭代取得的成果。期間大家的反饋記錄下來，由po整理，形成新的story。
• 回顧會議：項目團(tuán)隊對本期迭代進(jìn)行總結(jié)，發(fā)現(xiàn)不足，制定改進(jìn)計劃，下一次迭代繼續(xù)改進(jìn)，已達(dá)到持續(xù)改進(jìn)的效果。

敏捷中的測試

挑戰(zhàn)1：輕文檔或無文檔

挑戰(zhàn)2：快速迭代

1、測試工作的核心內(nèi)客是沒有變的，就是不斷地找Bug，只是要調(diào)整好自己的心態(tài)，一切以敏捷的原則為主。

2、測試人員不能依賴文檔，測試用例作用減弱，更多的采用思維導(dǎo)圖、探索性測試（強(qiáng)調(diào)自由度，設(shè)計和執(zhí)行同時執(zhí)行，根據(jù)測試結(jié)果不斷調(diào)整測試計劃）、自動化測試

3、敏捷講求合作，在敏捷項目組中，測試人員應(yīng)該更主動點，多向開發(fā)人員了解需求、討論設(shè)計、一起研究Bug出現(xiàn)的原因。

軟件測試v模型

2-2.PNG

V模型最早是由Paul Rook在２０世紀(jì)８０年代后期提出的，目的是改進(jìn)軟件開發(fā)的效率和效果。是瀑布模型的變種

• 明確的標(biāo)注了測試過程中存在的不同類型的測試，并且清楚的描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系
• V模型指出，單元和集成測試應(yīng)檢測程序的執(zhí)行是否滿足軟件設(shè)計的要求；系統(tǒng)測試應(yīng)檢測系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo)；驗收測試確定軟件的實現(xiàn)是否滿足用戶需要或合同的要求
• 局限性:僅僅把測試作為在編碼之后的一個階段，未在需求階段就進(jìn)入測試

軟件測試雙V模型

2-3.PNG

• W模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗證和確認(rèn)活動。W模型由兩個V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關(guān)系。

• W模型特點：測試的對象不僅是程序，需求、設(shè)計等同樣要測試，測試與開發(fā)是同步進(jìn)行的

• W模型優(yōu)點：有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后，測試人員就應(yīng)該參與到對需求的驗證和確認(rèn)活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風(fēng)險，及早制定應(yīng)對措施，顯著減少總體測試時間，加快項目進(jìn)度。

• 局限性：需求、設(shè)計、編碼等活動被視為串行的；測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個階段工作。無法支持敏捷開發(fā)模式。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W模型并不能解除測試管理面臨著困惑。

配置管理和軟件測試

是否真正做過項目從對配置管理的熟悉程度來看，是最容易辨別的

SVN &GIT

很多人其實對配置管理并不熟悉，對配置管理的作用也很模糊，存在很多的誤解，認(rèn)為配置管理是可有可無的東西。甚至很多測試人員也對此知之甚少，認(rèn)為軟件測試與配置管理的關(guān)系不大。實際上，一個配置管理做得好的公司，它的測試活動也會開展得比較順利，測試人員在這種環(huán)境下工作也會碰到更少的阻礙和困難。

在參與當(dāng)代軟件開發(fā)時，必須具備軟件配置管理方面的基本素養(yǎng)。不懂軟件項目的配置管理，就不懂軟件開發(fā)管理。沒有對軟件項目進(jìn)行配置管理，其實就沒有進(jìn)行軟件項目開發(fā)管理。

什么是配置管理

配置管理( Configuration Management)是通過對在軟件生命周期不同的時間點上的軟件配置進(jìn)行標(biāo)識，并對這些被標(biāo)識的軟件配置項的更改進(jìn)行系統(tǒng)控制，從而達(dá)到保證軟件產(chǎn)品的完整性和可溯性的過程。

軟件配置管理的應(yīng)用

軟件開發(fā)過程中會產(chǎn)生大量軟件產(chǎn)品（包括文檔、源代碼和數(shù)據(jù)等），且這些產(chǎn)品之間存在關(guān)聯(lián)關(guān)系。同一軟件產(chǎn)品也會發(fā)生變更，從而產(chǎn)生許多版本。軟件開發(fā)小組必須清晰地知道會有哪些產(chǎn)品、這些產(chǎn)品會有哪些不同的形式和版本。開發(fā)小組必須清晰地知道如何將產(chǎn)品的變更通知給受影響的小組。如果不能有效地了解軟件產(chǎn)品及其變更，開發(fā)小組將很難組裝這些軟件產(chǎn)品，很難得到所需的軟件產(chǎn)品。

實施軟件配置管理的好處

實施軟件配置管理(SCM)，至少能給項目團(tuán)隊帶來如下好處。
(1)能夠?qū)椖恐械奈臋n、代碼等的變化進(jìn)行有效管理。
(2)能夠方便地重現(xiàn)某個文件的歷史版本。
(3)能夠重新編譯某個歷史版本，使維護(hù)工作變得容易。
(4)能夠使異地多團(tuán)隊開發(fā)、并行開發(fā)成為現(xiàn)實。
(5)從公司級看，實行統(tǒng)一的配置管理流程可提高項目組間人員流動時的工作效率。

配置管理與軟件測試

測試人員是SCM中的參與者，有些公司也會把測試人員和配置管理員合二為一。如果配置管理流程不規(guī)范，或者沒有遵循一定的配置管理流程進(jìn)行軟件測試活動，也可能導(dǎo)致很嚴(yán)重的后果。

假設(shè)開發(fā)人員修正了一個Bug，然后找測試人員過去討論，測試人員在開發(fā)人員的機(jī)器上重新測試了一下，發(fā)現(xiàn)Bug沒再出現(xiàn)了，修復(fù)了，這時候，如果測試人員把缺陷關(guān)閉了，則可能導(dǎo)致缺陷莫名其妙地在用戶那邊又出現(xiàn)了。其實，原因可能僅僅是開發(fā)人員把這個Bug修改的代碼沒有提交的到配置管理數(shù)據(jù)庫中。但是作為測試人員有沒有責(zé)任呢？當(dāng)然有，因為測試人員也沒有按照規(guī)范的配置管理流程執(zhí)行測試，測試人員應(yīng)該從配置庫取源代碼編譯后再測試，只有看到新的構(gòu)建版本不再出現(xiàn)那個Bug，才能把缺陷庫中的Bug關(guān)閉。

軟件質(zhì)量與軟件測試

某些公司會把測試人員叫做QA，兩者真的一樣嗎?

• QA不等于測試人員，重要區(qū)別在于：

  測試人員查找的是產(chǎn)品的錯誤，QA查找的是流程的錯誤

• SQA（軟件質(zhì)量保證）工作以流程為主

• SQA 一般包括以下工作內(nèi)容。

  (l)指導(dǎo)并監(jiān)督項目按照過程實施。
  (2)對項目進(jìn)行度量、分析，增加項目的可視性。
  (3)審核工作產(chǎn)品，評價工作產(chǎn)品和過程質(zhì)量目標(biāo)的符合度。
  (4)進(jìn)行缺陷分析、缺陷預(yù)防活動，發(fā)現(xiàn)過程的缺陷，提供決策參考，促進(jìn)過程改進(jìn)。
  

• 質(zhì)量體系有ISO9000以及CMMI等

• 軟件測試人員與軟件質(zhì)量保證人員的工作存在區(qū)別，但是目的都是一樣的，就是確保軟
  件質(zhì)量和用戶需求得到滿足。