一、軟件的生命周期(SDLC，Systems Development Life Cycle,SDLC)

軟件計(jì)劃與可行性研究（問題定義、可行性研究）；需求分析；軟件設(shè)計(jì)（概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)）；編碼；軟件測(cè)試；運(yùn)行與維護(hù)

生存周期劃分

各階段的任務(wù)彼此間盡可能相對(duì)獨(dú)立，同一個(gè)階段各項(xiàng)任務(wù)的性質(zhì)盡可能相同，從而降低每個(gè)階段任務(wù)的復(fù)雜性，簡(jiǎn)化不 同階段之間的聯(lián)系，有利于軟件開發(fā)過程的組織管理。

生存周期基線

功能基線(functional baseline)

功能基線是指在系統(tǒng)分析與軟件定義階段結(jié)束時(shí)，經(jīng)過正式評(píng)審和批準(zhǔn)的系統(tǒng)設(shè)計(jì)規(guī)格說明書中對(duì)待軟件生命周期開發(fā)系統(tǒng) 的規(guī)格說明；或是指經(jīng)過項(xiàng)目委托單位和項(xiàng)目承辦單位雙方簽字同意的協(xié)議書或合同中所規(guī)定的對(duì)待開發(fā)軟件系統(tǒng) 的 規(guī)格說明；或是由下級(jí)申請(qǐng)經(jīng)上級(jí)同意或直接由上級(jí)下達(dá)的項(xiàng)目任務(wù)書中所規(guī)定的對(duì)待開發(fā)軟件系統(tǒng)的規(guī)格說明。功能基 線是最初批準(zhǔn)的功能配置標(biāo)識(shí)。

指派基線(allocated baseline)

指派基線是指在軟件需求分析階段結(jié)束時(shí)，經(jīng)過正式評(píng)審和批準(zhǔn)的軟件需求的規(guī)格說明。指派基線是最初批準(zhǔn)的指派配置標(biāo) 識(shí)。

產(chǎn)品基線(product baseline)

產(chǎn)品基線是指在軟件組裝與系統(tǒng)測(cè)試階段結(jié)束時(shí)，經(jīng)過正式評(píng)審的批準(zhǔn)的有關(guān)所開發(fā)的軟件產(chǎn)品的全部配置項(xiàng)的規(guī)格說明。 產(chǎn)品基線是最初批準(zhǔn)的產(chǎn)品配置標(biāo)識(shí)。

SDLC的六個(gè)階段

定義及規(guī)劃

此階段是軟件開發(fā)方與需求方共同討論，主要確定軟件的開發(fā)目標(biāo)及其可行性。

需求分析

在確定軟件開發(fā)可行的情況下，對(duì)軟件需要實(shí)現(xiàn)的各個(gè)功能進(jìn)行詳細(xì)分析。需求分析階段是一個(gè)很重要的階段，這一階段做 得好，將為整個(gè)軟件開發(fā)項(xiàng)目的成功打下良好的基礎(chǔ)。"唯一不變的是變化本身。"，同樣需求也是在整個(gè)軟件開發(fā)過程中不 斷變化和深入的，因此我們必須制定需求變更計(jì)劃來應(yīng)付這種變化，以保護(hù)整個(gè)項(xiàng)目的順利進(jìn)行。

軟件設(shè)計(jì)

此階段主要根據(jù)需求分析的結(jié)果，對(duì)整個(gè)軟件系統(tǒng)進(jìn)行設(shè)計(jì)，如系統(tǒng)框架設(shè)計(jì)，數(shù)據(jù)庫設(shè)計(jì)等等。軟件設(shè)計(jì)一般分為總體設(shè) 計(jì)和詳細(xì)設(shè)計(jì)。好的軟件設(shè)計(jì)將為軟件程序編寫打下良好的基礎(chǔ)。

程序編碼

此階段是將軟件設(shè)計(jì)的結(jié)果轉(zhuǎn)換成計(jì)算機(jī)可運(yùn)行的程序代碼。在程序編碼中必須要制定統(tǒng)一，符合標(biāo)準(zhǔn)的編寫規(guī)范。以保證 程序的可讀性，易維護(hù)性，提高程序的運(yùn)行效率。

軟件測(cè)試

在軟件設(shè)計(jì)完成后要經(jīng)過嚴(yán)密的測(cè)試，以發(fā)現(xiàn)軟件在整個(gè)設(shè)計(jì)過程中存在的問題并加以糾正。整個(gè)測(cè)試過程分單元測(cè)試、組 裝測(cè)試以及系統(tǒng)測(cè)試三個(gè)階段進(jìn)行。測(cè)試的方法主要有白盒測(cè)試和黑盒測(cè)試兩種。在測(cè)試過程中需要建立詳細(xì)的測(cè)試計(jì)劃并 嚴(yán)格按照測(cè)試計(jì)劃進(jìn)行測(cè)試，以減少測(cè)試的隨意性。

運(yùn)行維護(hù)

軟件維護(hù)是軟件生命周期中持續(xù)時(shí)間最長(zhǎng)的階段。在軟件開發(fā)完成并投入使用后，由于多方面的原因，軟件不能繼續(xù)適應(yīng)用 戶的要求。要延續(xù)軟件的使用壽命，就必須對(duì)軟件進(jìn)行維護(hù)。軟件軟件生存周期的維護(hù)包括糾錯(cuò)性維護(hù)和改進(jìn)性維護(hù)兩個(gè)方 面。

周期模型

典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型

二、軟件測(cè)試在軟件生命周期（瀑布模型）中的對(duì)應(yīng)關(guān)系

三、軟件測(cè)試過程

第一步：對(duì)要執(zhí)行測(cè)試的產(chǎn)品/項(xiàng)目進(jìn)行分析，確定測(cè)試策略，制定測(cè)試計(jì)劃。該計(jì)劃被審核批準(zhǔn)后轉(zhuǎn)向第二步。測(cè)試工作啟動(dòng)前一定要確定正確的測(cè)試策略和指導(dǎo)方針，這些是后期開展工作的基礎(chǔ)。只有將本次的測(cè)試目標(biāo)和要求分析清楚，才能決定測(cè)試資源的投入。

第二步：設(shè)計(jì)測(cè)試用例。設(shè)計(jì)測(cè)試用例要根據(jù)測(cè)試需求和測(cè)試策略來進(jìn)行，進(jìn)度壓力不大時(shí)，應(yīng)該設(shè)計(jì)的詳細(xì)，如果進(jìn)度、成本壓力較大，則應(yīng)該保證測(cè)試用例覆蓋到關(guān)鍵性的測(cè)試需求。該用例被批準(zhǔn)后轉(zhuǎn)向第三步。

第三步：如果滿足“啟動(dòng)準(zhǔn)則”（EntryCriteria），那么執(zhí)行測(cè)試。執(zhí)行測(cè)試主要是搭建測(cè)試環(huán)境，執(zhí)行測(cè)試用例。執(zhí)行測(cè)試時(shí)要進(jìn)行進(jìn)度控制、項(xiàng)目協(xié)調(diào)等工作。

第四步：提交缺陷。這里要進(jìn)行缺陷審核和驗(yàn)證等工作。

第五步：消除軟件缺陷。通常情況下，開發(fā)經(jīng)理需要審核缺陷，并進(jìn)行缺陷分配。程序員修改自己負(fù)責(zé)的缺陷。在程序員修改完成后，進(jìn)入到回歸測(cè)試階段。如果滿足“完成準(zhǔn)則”（ExitCriteria），那么正常結(jié)束測(cè)試。

第六步：撰寫測(cè)試報(bào)告。對(duì)測(cè)試進(jìn)行分析，總結(jié)本次的經(jīng)驗(yàn)教訓(xùn)，在下一次的工作中改。

軟件測(cè)試過程管理，主要包括軟件測(cè)試是什么樣的過程，如何評(píng)價(jià)一個(gè)軟件測(cè)試過程，如何進(jìn)行配置管理和測(cè)試風(fēng)險(xiǎn)分析以及測(cè)試成本的管理。

四、軟件測(cè)試流程（與第三條對(duì)應(yīng)）

1、制定測(cè)試計(jì)劃

2、編輯測(cè)試用例

3、執(zhí)行測(cè)試用例

4、發(fā)現(xiàn)并提交BUG

5、開發(fā)組修正BUG

6、對(duì)已修正BUG進(jìn)行返測(cè)

7、修正完成的BUG將狀態(tài)置為已關(guān)閉，未正確修正的BUG重新激活

五、測(cè)試用例

測(cè)試用例（Test Case）是為某個(gè)特殊目標(biāo)而編制的一組測(cè)試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測(cè)試某個(gè)程序路徑或核實(shí)是否滿足某個(gè)特定需求。

測(cè)試用例的要素為：版本號(hào)、模塊名稱、用例編號(hào)、用例名稱、用例級(jí)別、預(yù)置條件、驗(yàn)證步驟、期望結(jié)果（含判斷標(biāo)準(zhǔn)）、測(cè)試結(jié)果、測(cè)試時(shí)間、測(cè)試人員等。（其中核心要素為預(yù)置條件、驗(yàn)證步驟、期望結(jié)果）

測(cè)試用例的設(shè)計(jì)方法：等價(jià)類劃分、邊界值分析、錯(cuò)誤推測(cè)法、因果圖法、場(chǎng)景設(shè)計(jì)法

一份好的測(cè)試用例所要達(dá)到以下幾點(diǎn)要求：測(cè)試用例必須完成對(duì)需求的完整覆蓋（即用例和需求的雙向可追溯性）；測(cè)試用例必須是可執(zhí)行的；測(cè)試用例的結(jié)果唯一性；測(cè)試用例必須簡(jiǎn)潔明了

六、缺陷報(bào)告（提交bug）

一份有效的缺陷報(bào)告要素通常包括：標(biāo)題、前提、測(cè)試環(huán)境、操作步驟、實(shí)際結(jié)果、期望結(jié)果、出現(xiàn)的頻率、優(yōu)先級(jí)、嚴(yán)重等級(jí)、附件（一般是圖片形式）。

另外還會(huì)有一些附加信息，如測(cè)試人員、開發(fā)負(fù)責(zé)人等。

標(biāo)題：簡(jiǎn)明扼要，無歧義

優(yōu)先級(jí) Priority（4個(gè)等級(jí)）：軟件被修復(fù)的緊急程度

1--立即解決：缺陷導(dǎo)致系統(tǒng)幾乎不能運(yùn)行使用 或 嚴(yán)重妨礙測(cè)試的執(zhí)行（需立即修改）

2--高優(yōu)先級(jí)：缺陷嚴(yán)重，影響到測(cè)試了（當(dāng)天或第二天要及時(shí)解決的）

3--正常：一般錯(cuò)誤

4--低優(yōu)先級(jí)：可以在開發(fā)有時(shí)間的時(shí)候處理，如頁面文本框?qū)R顯示

嚴(yán)重等級(jí) Severity（4個(gè)等級(jí)）：缺陷引起的故障對(duì)用戶使用系統(tǒng)的影響

1--致命的：主流程不通，導(dǎo)致系統(tǒng)功能缺失、用戶數(shù)據(jù)被破壞、系統(tǒng)崩潰、死機(jī)

2--嚴(yán)重的：影響流程的 比較嚴(yán)重的，比如系統(tǒng)主要功能部分未實(shí)現(xiàn)

3--一般：系統(tǒng)的次要功能沒有完全實(shí)現(xiàn)，但不影響用戶的正常使用

4--較小：操作不方便或遇到麻煩，但不影響功能的使用，如字體不美觀、按鈕大小不合適、文字排列對(duì)齊等（屬于建議性或者美觀方面的）

一般來說，缺陷越嚴(yán)重，優(yōu)先級(jí)越高，但也有例外：

1）從用戶角度看，缺陷不是很嚴(yán)重，但可能影響到測(cè)試執(zhí)行了（優(yōu)先級(jí)高嚴(yán)重等級(jí)低）

2） 有些缺陷比較嚴(yán)重，但由于技術(shù)的限制，暫時(shí)沒法修改。這時(shí)優(yōu)先級(jí)就降低了

附件

有時(shí)候，用文字很難清楚描述缺陷，此時(shí)用圖片（畫筆指明問題）就很直觀了

如何有效的報(bào)告缺陷？

單一準(zhǔn)確：每個(gè)報(bào)告只針對(duì)一個(gè)缺陷，如果有多個(gè)缺陷，可能開發(fā)只修正了其中一個(gè)，其他的沒有得到修改，加長(zhǎng)了缺陷的生命周期

可以再現(xiàn)：不能忽視或省略任何一項(xiàng)操作步驟，特別是關(guān)鍵性的操作，如描述的不夠清楚，RD（Research and Development engineer）就會(huì)過來溝通怎么操作的，浪費(fèi)了大家的時(shí)間

完整統(tǒng)一：完整的描述信息

短小簡(jiǎn)練：使用關(guān)鍵詞

特定條件：有些問題只在特定環(huán)境下存在

七、測(cè)試報(bào)告

測(cè)試報(bào)告是指把測(cè)試的過程和結(jié)果寫成文檔，對(duì)發(fā)現(xiàn)的問題和缺陷進(jìn)行分析，為糾正軟件的存在的質(zhì)量問題提供依據(jù)，同時(shí)為軟件驗(yàn)收和交付打下基礎(chǔ)。

一份詳細(xì)的測(cè)試報(bào)告包含足夠的信息，包括產(chǎn)品質(zhì)量和測(cè)試過程的評(píng)價(jià)，測(cè)試報(bào)告基于測(cè)試中的數(shù)據(jù)采集以及對(duì)最終的測(cè)試結(jié)果分析。

測(cè)試報(bào)告的主體框架為：

1、首頁

·· 報(bào)告名稱（軟件名稱+版本號(hào)+用戶端類型（android，iphone，后臺(tái)管理等等）+測(cè)試范圍（單元，集成，系統(tǒng)，模塊等等）+測(cè)試報(bào)告）

·· 報(bào)告委托方，報(bào)告責(zé)任方，報(bào)告日期等

·· 版本變化歷史

·· 密級(jí)

2、引言

2.1編寫目的

本測(cè)試報(bào)告的具體編寫目的，指出預(yù)期的讀者范圍。

2.2 項(xiàng)目背景

對(duì)項(xiàng)目目標(biāo)和目的進(jìn)行簡(jiǎn)要說明。必要時(shí)包括簡(jiǎn)史，這部分不需要腦力勞動(dòng)，直接從需求或者招標(biāo)文件中拷貝即可。

2.3 系統(tǒng)簡(jiǎn)介

如果設(shè)計(jì)說明書有此部分，照抄。注意必要的框架圖和網(wǎng)絡(luò)拓?fù)鋱D能吸引眼球。

2.4 術(shù)語和縮略語

列出設(shè)計(jì)本系統(tǒng)/項(xiàng)目的專用術(shù)語和縮寫語約定。對(duì)于技術(shù)相關(guān)的名詞和與多義詞一定要注明清楚，以便閱讀時(shí)不會(huì)產(chǎn)生歧義。

2.5 參考資料

3、測(cè)試概要

測(cè)試的概要介紹，包括測(cè)試的一些聲明、測(cè)試范圍、測(cè)試目的等等，主要是測(cè)試情況簡(jiǎn)介。（其他測(cè)試經(jīng)理和質(zhì)量人員關(guān)注部分）

3.1測(cè)試方法(和工具)

簡(jiǎn)要介紹測(cè)試中采用的方法(和工具)。

3.2測(cè)試范圍

介紹本次所測(cè)試的軟件功能

3.3測(cè)試環(huán)境與配置

簡(jiǎn)要介紹測(cè)試環(huán)境及其配置。

4、測(cè)試結(jié)果與缺陷分析

整個(gè)測(cè)試報(bào)告中這是最激動(dòng)人心的部分，這部分主要匯總各種數(shù)據(jù)并進(jìn)行度量，度量包括對(duì)測(cè)試過程的度量和能力評(píng)估、對(duì)軟件產(chǎn)品的質(zhì)量度量和產(chǎn)品評(píng)估。對(duì)于不需要過程度量或者相對(duì)較小的項(xiàng)目，例如用于驗(yàn)收時(shí)提交用戶的測(cè)試報(bào)告、小型項(xiàng)目的測(cè)試報(bào)告，可省略過程方面的度量部分；而采用了CMM/ISO或者其他工程標(biāo)準(zhǔn)過程的，需要提供過程改進(jìn)建議和參考的測(cè)試報(bào)告－主要用于公司內(nèi)部測(cè)試改進(jìn)和缺陷預(yù)防機(jī)制－則過程度量需要列出。

4.1測(cè)試執(zhí)行情況與記錄

描述測(cè)試資源消耗情況，記錄實(shí)際數(shù)據(jù)。（測(cè)試、項(xiàng)目經(jīng)理關(guān)注部分）

4.1.1測(cè)試組織

可列出簡(jiǎn)單的測(cè)試組架構(gòu)圖

4.1.2測(cè)試時(shí)間

列出測(cè)試的跨度和工作量，最好區(qū)分測(cè)試文檔和活動(dòng)的時(shí)間。數(shù)據(jù)可供過程度量使用。

4.1.3測(cè)試版本

4.2覆蓋分析

4.2.1需求覆蓋

需求覆蓋率是指經(jīng)過測(cè)試的需求/功能和需求規(guī)格說明書中所有需求/功能的比值，通常情況下要達(dá)到100%的目標(biāo)。

4.2.2測(cè)試覆蓋

需求/功能（或編號(hào)） 用例個(gè)數(shù) 執(zhí)行總數(shù) 未執(zhí)行 未/漏測(cè)分析和原因

測(cè)試覆蓋率計(jì)算 執(zhí)行數(shù)/用例總數(shù) ×100%

.3缺陷的統(tǒng)計(jì)與分析

缺陷統(tǒng)計(jì)主要涉及到被測(cè)系統(tǒng)的質(zhì)量，因此，這部分成為開發(fā)人員、質(zhì)量人員重點(diǎn)關(guān)注的部分。

4.3.1缺陷匯總

被測(cè)系統(tǒng) 系統(tǒng)測(cè)試 回歸測(cè)試 總計(jì)

合計(jì)

按嚴(yán)重程度

嚴(yán)重 一般 微小

按缺陷類型

用戶界面 一致性 功能 算法 接口 文檔 用戶界面 其他

按功能分布

功能一 功能二 功能三 功能四 功能五 功能六 功能七

最好給出缺陷的餅狀圖和柱狀圖以便直觀查看。俗話說一圖勝千言，圖標(biāo)能夠使閱讀者迅速獲得信息，尤其是各層面管理人員沒有時(shí)間去逐項(xiàng)閱讀文章。

4.3.2缺陷分析

本部分對(duì)上述缺陷和其他收集數(shù)據(jù)進(jìn)行綜合分析

缺陷綜合分析

缺陷發(fā)現(xiàn)效率 = 缺陷總數(shù)/執(zhí)行測(cè)試用時(shí)

可到具體人員得出平均指標(biāo)

用例質(zhì)量 = 缺陷總數(shù)/測(cè)試用例總數(shù) ×100%

缺陷密度 = 缺陷總數(shù)/功能點(diǎn)總數(shù)

缺陷密度可以得出系統(tǒng)各功能或各需求的缺陷分布情況，開發(fā)人員可以在此分析基礎(chǔ)上得出那部分功能/需求缺陷最多，從而在今后開發(fā)注意避免并注意在實(shí)施時(shí)予與關(guān)注，測(cè)試經(jīng)驗(yàn)表明，測(cè)試缺陷越多的部分，其隱藏的缺陷也越多。

4.3.3殘留缺陷與未解決問題

殘留缺陷

評(píng)價(jià)：對(duì)這些問題的看法，也就是這些問題如果發(fā)出去了會(huì)造成什么樣的影響

5、測(cè)試結(jié)論與建議

5.1 測(cè)試結(jié)論

1． 測(cè)試執(zhí)行是否充分（可以增加對(duì)安全性、可靠性、可維護(hù)性和功能性描述）

2． 對(duì)測(cè)試風(fēng)險(xiǎn)的控制措施和成效

3． 測(cè)試目標(biāo)是否完成

4． 測(cè)試是否通過

5． 是否可以進(jìn)入下一階段項(xiàng)目目標(biāo)

5.2 建議

1．對(duì)系統(tǒng)存在問題的說明，描述測(cè)試所揭露的軟件缺陷和不足，以及可能給軟件實(shí)施和運(yùn)行帶來的影響

2．可能存在的潛在缺陷和后續(xù)工作

3．對(duì)缺陷修改和產(chǎn)品設(shè)計(jì)的建議

4．對(duì)過程改進(jìn)方面的建議

6、附錄

· 缺陷列表

· 缺陷等級(jí)定義標(biāo)準(zhǔn)

· 測(cè)試通過標(biāo)準(zhǔn)

八、測(cè)試策略

策略，百度解釋為：“策略”就是為了實(shí)現(xiàn)某一個(gè)目標(biāo)，首先預(yù)先根據(jù)可能出現(xiàn)的問題制定的若干對(duì)應(yīng)的方案，并且，在實(shí)現(xiàn)目標(biāo)的過程中，根據(jù)形勢(shì)的發(fā)展和變化來制定出新的方案，或者根據(jù)形勢(shì)的發(fā)展和變化來選擇相應(yīng)的方案，最終實(shí)現(xiàn)目標(biāo)。

軟件測(cè)試的目標(biāo)是驗(yàn)證軟件的功能，找出存在的問題，評(píng)估軟件質(zhì)量是否達(dá)到要求。軟件測(cè)試策略要圍繞這么目標(biāo)去考慮和制定。測(cè)試策略描述了測(cè)試項(xiàng)目和測(cè)試任務(wù)之間的關(guān)系。它用來說明要測(cè)什么，如何測(cè)，如何協(xié)調(diào)測(cè)試資源和測(cè)試時(shí)間等。他的目的和作用是指導(dǎo)測(cè)試工程師進(jìn)行測(cè)試工作的總體方向和側(cè)重點(diǎn)。測(cè)試策略制定的是否合理高效會(huì)對(duì)測(cè)試項(xiàng)目的進(jìn)度產(chǎn)生很大的影響。

測(cè)試策略分為了一下幾個(gè)模塊：

1. 測(cè)試安排、發(fā)布計(jì)劃

這個(gè)模塊用來羅列測(cè)試項(xiàng)目本身重要的里程碑，每個(gè)里程碑都需要有明確的結(jié)束時(shí)間，這個(gè)時(shí)間可以指導(dǎo)我們后續(xù)的測(cè)試。如果測(cè)試時(shí)間安排不足，我們就可以在后續(xù)的測(cè)試范圍中挑選優(yōu)先級(jí)比較高的特性來執(zhí)行測(cè)試，這樣可以最大限度的保證產(chǎn)品的質(zhì)量。

2. 測(cè)試范圍（按優(yōu)先級(jí)排列）

這一部分分為In Scope和Out Of Scope.這一部分需要說明哪些產(chǎn)品模塊是在測(cè)試范圍中的，哪些是本階段測(cè)試不考慮的。對(duì)于在測(cè)試范圍中的模塊，需要給出優(yōu)先級(jí)以便相應(yīng)測(cè)試時(shí)間不足的情況；對(duì)于不在測(cè)試范圍中的模塊，需要給出原因（為什么在本測(cè)試階段不考慮測(cè)）。

3. 測(cè)試資源

測(cè)試資源在測(cè)試策略中也是很重要的一環(huán)，它分為人力和工具兩部分。人力資源主要說明參與測(cè)試的人員，當(dāng)然可以包括很多的角色，如何專業(yè)測(cè)試人員，客戶，產(chǎn)品經(jīng)理等。工具主要是指可能用到其他軟件（可能需要license）。

4. 測(cè)試環(huán)境

測(cè)試環(huán)境主要包括推薦環(huán)境解決方案，操作系統(tǒng)要求，軟硬件要求。

5. 測(cè)試方法

測(cè)試方法的羅列主要是為了說明針對(duì)測(cè)試項(xiàng)目我們要開展哪些類型的測(cè)試，功能測(cè)試是必須的，非功能測(cè)試是可選的。測(cè)試方法的選擇主要根據(jù)軟件的所要達(dá)到的質(zhì)量特性來決定。軟件的6大質(zhì)量特性為：功能性、可靠性、易用性、效率性、易用性、可維護(hù)性、可移植性

6. 用例設(shè)計(jì)方法

用例設(shè)計(jì)普遍的方法為等價(jià)類劃分、邊界值、因果圖、判定表、場(chǎng)景之類。我想說的是，要提高用例的有效性和對(duì)驗(yàn)證點(diǎn)的覆蓋度，設(shè)計(jì)用例時(shí)需要以軟件所要具備的27個(gè)質(zhì)量子特性為出發(fā)點(diǎn)功能性（適合性、正確性、互操作性、安全保密性、功能依從性）；可靠性（成熟性、容錯(cuò)性、易恢復(fù)性、可靠性依從性）；易用性（易操作性、易理解性、易學(xué)習(xí)性、吸引性、易用性依從性）；效率性（時(shí)間特性、資源特性、效率性依從性）；可維護(hù)性（易分析性、易修改性、穩(wěn)定性、易測(cè)試性、可維護(hù)性依從性）；可移植性（適應(yīng)性、易安裝性、易替換性、共存性、可移植性依從性）

7. 文檔管理

對(duì)于一個(gè)完整的產(chǎn)品來說，文檔是很重要的一環(huán)。它一般包括安裝、升級(jí)文檔，用戶指南等。文檔不單單是一個(gè)文件，它需要經(jīng)過完整的測(cè)試才能發(fā)布給客戶。差的文檔很可能會(huì)誤導(dǎo)用戶，從而使他們對(duì)測(cè)試項(xiàng)目失去信心（雖然客戶很少看文檔……：））

8. 風(fēng)險(xiǎn)管理

風(fēng)險(xiǎn)管理模塊需要羅列出來現(xiàn)在已知的可能會(huì)出現(xiàn)不確定性的因素，這些因素可能來自技術(shù)，資源或者其他方面的。

9. 發(fā)布包驗(yàn)證

這部分有一定的特殊性，并不適用于所有的產(chǎn)品。這部分主要是對(duì)測(cè)試項(xiàng)目安裝包進(jìn)行驗(yàn)證。

九、測(cè)試方案（沒搞清楚和測(cè)試策略的區(qū)別）

十、測(cè)試計(jì)劃（沒搞清楚和測(cè)試策略的區(qū)別）

十一、操作系統(tǒng)命令、數(shù)據(jù)庫命令

熟悉window和linux系統(tǒng)的基本操作命令、因?yàn)榭蛻舳嘶臼褂玫氖莣indow，服務(wù)器大多采用了linux。最起碼得掌握這兩個(gè)操作系統(tǒng)中：文件的新建、查找、修改、刪除，壓縮、解壓縮；軟件的安裝、卸載；程序的啟動(dòng)、停止。

對(duì)于數(shù)據(jù)庫，很多人說我是測(cè)試，我只關(guān)心業(yè)務(wù)，我為啥要懂?dāng)?shù)據(jù)庫的操作。其實(shí)業(yè)務(wù)的本質(zhì)就是操作數(shù)據(jù)庫中的存儲(chǔ)的數(shù)據(jù)。數(shù)據(jù)是開展業(yè)務(wù)的基礎(chǔ)，很多情況下，我們不能只關(guān)注頁面的顯示變化，而是要到數(shù)據(jù)庫中查看數(shù)據(jù)是不是符合業(yè)務(wù)結(jié)果的預(yù)期。所以測(cè)試人員最起碼要掌握sql server、mysql、Oracle這幾種主流數(shù)據(jù)的增刪改查操作命令。一般面試也就問這幾種

十二、UI自動(dòng)化

現(xiàn)在自動(dòng)化測(cè)試已經(jīng)成為測(cè)試人員提高薪資的一個(gè)必要技能，這里推薦幾個(gè)我知道的UI自動(dòng)化的方案：web頁面的自動(dòng)化Python+selenuim；移動(dòng)端的自動(dòng)化（ios+android）Python+appium。其他的方案還有很多，介于我沒接觸過也沒了解過，所有就不瞎說了。要做UI自動(dòng)化，還需要了解的知識(shí)有html、css、javascript。

十三、接口測(cè)試（手工+自動(dòng)化）

同樣的，提高薪資的技能包，這里我用過兩個(gè)方案，一個(gè)是手動(dòng)做接口測(cè)試，推薦postman，適用于對(duì)數(shù)量比較少的接口去做測(cè)試，比如集成其他系統(tǒng)時(shí)的技術(shù)驗(yàn)證。多接口的批跑測(cè)試我接觸到的是ant+jmeter工具，jmeter可以批跑接口，在每個(gè)請(qǐng)求里加上檢查點(diǎn)。ant是Java的一種文件打包集成工具，可以控制調(diào)用jmeter，生產(chǎn)html格式的結(jié)果報(bào)告，方便查看結(jié)果

十四、性能測(cè)試

同樣的，提高薪資的技能包。性能測(cè)試是通過自動(dòng)化的測(cè)試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測(cè)試。負(fù)載測(cè)試和壓力測(cè)試都屬于性能測(cè)試，兩者可以結(jié)合進(jìn)行。通過負(fù)載測(cè)試，確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測(cè)試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測(cè)試是通過確定一個(gè)系統(tǒng)的瓶頸或者不能接受的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級(jí)別的測(cè)試。

在實(shí)際工作中我們經(jīng)常會(huì)對(duì)兩種類型軟件進(jìn)行測(cè)試：bs和cs，這兩方面的性能指標(biāo)一般需要哪些內(nèi)容呢？

Bs結(jié)構(gòu)程序一般會(huì)關(guān)注的通用指標(biāo)如下（簡(jiǎn)）：

Web服務(wù)器指標(biāo)指標(biāo)：

* Avg Rps: 平均每秒鐘響應(yīng)次數(shù)=總請(qǐng)求時(shí)間 / 秒數(shù)；

* Avg time to last byte per terstion （mstes）：平均每秒業(yè)務(wù)腳本的迭代次數(shù)，有人會(huì)把這兩者混淆；

* Successful Rounds：成功的請(qǐng)求；

* Failed Rounds ：失敗的請(qǐng)求；

* Successful Hits ：成功的點(diǎn)擊次數(shù)；

* Failed Hits ：失敗的點(diǎn)擊次數(shù)；

* Hits Per Second ：每秒點(diǎn)擊次數(shù)；

* Successful Hits Per Second ：每秒成功的點(diǎn)擊次數(shù)；

* Failed Hits Per Second ：每秒失敗的點(diǎn)擊次數(shù)；

* Attempted Connections ：嘗試鏈接數(shù)；

CS結(jié)構(gòu)程序，由于一般軟件后臺(tái)通常為數(shù)據(jù)庫，所以我們更注重?cái)?shù)據(jù)庫的測(cè)試指標(biāo)：

* User 0 Connections ：用戶連接數(shù)，也就是數(shù)據(jù)庫的連接數(shù)量；

* Number of deadlocks：數(shù)據(jù)庫死鎖；

* Buffer Cache hit ：數(shù)據(jù)庫Cache的命中情況

性能測(cè)試我主要接觸過兩個(gè)工具 loadrunner、jmeter。jmeter比較適合公司自己內(nèi)部做一個(gè)性能評(píng)估，他是免費(fèi)的，輕量型的，安裝和使用都很方便，就是在報(bào)表和結(jié)果分析上沒有那么完善和漂亮。loadrunner，大名鼎鼎，很多對(duì)外提供的數(shù)據(jù)報(bào)告都是只認(rèn)可loadrunner，能生成完善的數(shù)據(jù)分析和漂亮的報(bào)表。

十五、團(tuán)隊(duì)管理

具備團(tuán)隊(duì)管理能力，意味著你不止能自己獨(dú)立工作，你還可以帶領(lǐng)、指導(dǎo)其他人一起完成工作，是一個(gè)升職的必備能力。

團(tuán)隊(duì)管理即是組建和管理一個(gè)測(cè)試團(tuán)隊(duì)，制定和落實(shí)一個(gè)有效的測(cè)試流程，計(jì)劃、設(shè)計(jì)、執(zhí)行并跟蹤輸出項(xiàng)目的測(cè)試報(bào)告，為項(xiàng)目質(zhì)量提供有效保障。

由于我本身沒做過什么管理，看了一篇比較好的文章，這么轉(zhuǎn)發(fā)一下：

測(cè)試團(tuán)隊(duì)的管理劃分為6個(gè)部分：人員管理、流程管理、團(tuán)隊(duì)管理、質(zhì)量管理、風(fēng)險(xiǎn)管理、資源管理。

人員管理：

人員招聘

確定招聘需求和招聘要求，為團(tuán)隊(duì)招募合適的人才。

剛剛走出校園的實(shí)習(xí)生，和社招的資深測(cè)試工程師的能力和經(jīng)驗(yàn)自然是不一樣的，所以對(duì)于社招和應(yīng)屆生的招聘要求需要分開。

通常我在面試社招時(shí)，更多關(guān)注的是社招同學(xué)的項(xiàng)目經(jīng)驗(yàn)，以及過往所承擔(dān)的職責(zé)，自動(dòng)化工具能力，軟性素質(zhì)上更看重協(xié)調(diào)能力和推動(dòng)能力。

而在實(shí)習(xí)生的面試時(shí)，不會(huì)過多去關(guān)注實(shí)習(xí)生的項(xiàng)目經(jīng)驗(yàn)，更多關(guān)注的是實(shí)習(xí)生的學(xué)習(xí)能力和主觀能動(dòng)性，如果能有一些對(duì)軟件測(cè)試崗位的基礎(chǔ)知識(shí)學(xué)習(xí)和理解，那么是很加分的。

人員培養(yǎng)

制定學(xué)習(xí)目標(biāo)和計(jì)劃，因人而異施教，安排專業(yè)的導(dǎo)師，及時(shí)跟進(jìn)新人學(xué)習(xí)進(jìn)度并解疑。使招聘的人才在最短的時(shí)間內(nèi)快速適應(yīng)項(xiàng)目的流程，勝任項(xiàng)目的任務(wù)。

對(duì)于新入職的人而言，一個(gè)類似于這樣的明確的工作任務(wù)和目標(biāo)非常重要。

人員管理

1、職能明確：各崗位職能職責(zé)區(qū)分清楚，避免團(tuán)隊(duì)成員之間職能混亂，出現(xiàn)工作交叉干預(yù)、重復(fù)勞動(dòng)的現(xiàn)象，也避免出現(xiàn)踢皮球的場(chǎng)景。

有的測(cè)試團(tuán)隊(duì)會(huì)按照測(cè)試技術(shù)、測(cè)試設(shè)計(jì)、測(cè)試執(zhí)行的組織結(jié)構(gòu)來管理，這樣每個(gè)團(tuán)隊(duì)都術(shù)有專攻，管理上也會(huì)更容易

有的測(cè)試團(tuán)隊(duì)會(huì)按照個(gè)人全方位能力培養(yǎng)，要求個(gè)人同時(shí)具備測(cè)試技術(shù)、測(cè)試設(shè)計(jì)和測(cè)試執(zhí)行的能力，這樣對(duì)每個(gè)人的長(zhǎng)遠(yuǎn)發(fā)展更有利，但是會(huì)因?yàn)槊總€(gè)人的能力參差不齊，導(dǎo)致團(tuán)隊(duì)的成員能力不均衡，個(gè)人優(yōu)勢(shì)不夠突出

2、知人善任：依據(jù)各人的特質(zhì)、能力層級(jí)、優(yōu)勢(shì)劣勢(shì)進(jìn)行任務(wù)分配，給團(tuán)隊(duì)成員充分展示優(yōu)點(diǎn)的機(jī)會(huì)，避其缺點(diǎn)，合適的人做合適的事情。

比如有的測(cè)試人員擅長(zhǎng)測(cè)試設(shè)計(jì)，有的測(cè)試人員擅長(zhǎng)挖掘工具自動(dòng)化搭建，有的測(cè)試人員溝通協(xié)調(diào)能力比較強(qiáng)，根據(jù)每個(gè)人的意愿和長(zhǎng)處來安排任務(wù)。

3、善于傾聽：尊重團(tuán)隊(duì)里的每個(gè)人，確保成員能夠無所顧忌地表達(dá)個(gè)人觀點(diǎn)，并能夠及時(shí)覺察成員情緒上的波動(dòng)，換位思考，及時(shí)建立疏通、宣泄的渠道，做好正面引導(dǎo)。

4、敢于授權(quán)：在明確的目標(biāo)要求下，適當(dāng)?shù)姆攀郑寛F(tuán)隊(duì)成員有能力與權(quán)力去承擔(dān)并對(duì)結(jié)果負(fù)責(zé)，但是在過程中，管理者也需要隨時(shí)去抽查，以便及時(shí)發(fā)現(xiàn)落實(shí)過程中的偏差或者問題

5、激發(fā)潛能：不畏懼新人犯第一次錯(cuò)誤，因?yàn)殄e(cuò)誤中的總結(jié)，才能令人印象更深刻，后續(xù)不再犯。而不斷的嘗試新事物，才能夠挖掘團(tuán)隊(duì)成員的潛力。

6、等級(jí)淡化：成為團(tuán)隊(duì)成員的朋友，在成員迷茫時(shí)能給出合適的建議，在困難時(shí)伸出援手，必要的時(shí)候需要言傳身教，做成員的堅(jiān)實(shí)后盾。

這些主要講的是向下管理，另外還有向上管理，如何處理自己與上級(jí)之間的關(guān)系，如何向上級(jí)述職，更好的展現(xiàn)自己和團(tuán)隊(duì)的工作成績(jī)，也是管理的一門學(xué)問。

測(cè)試團(tuán)隊(duì)管理

團(tuán)隊(duì)建設(shè)

1、共同目標(biāo)：

可以是時(shí)間、項(xiàng)目等，團(tuán)隊(duì)成員有著共同的目標(biāo)，才能提高整個(gè)團(tuán)隊(duì)的凝聚力和斗志，從而取得1+1大于2的效果。

2、團(tuán)隊(duì)規(guī)劃：

制定半年、一年，短期和長(zhǎng)期的規(guī)劃，讓團(tuán)隊(duì)成員了解公司的遠(yuǎn)景，讓大家對(duì)團(tuán)隊(duì)、個(gè)人的發(fā)展有信心。

3、樹立標(biāo)桿：

一個(gè)團(tuán)隊(duì)中各個(gè)成員都是不同的個(gè)體，素質(zhì)和能力頗有差異，樹立標(biāo)桿，推廣優(yōu)秀成員的成績(jī)和經(jīng)驗(yàn)，才能提升團(tuán)隊(duì)的能力，使團(tuán)隊(duì)能力最大化。

4、獎(jiǎng)懲激勵(lì)：

團(tuán)隊(duì)成立階段，多獎(jiǎng)勵(lì)，少懲治。及時(shí)的給予鼓勵(lì)和獎(jiǎng)勵(lì)，會(huì)讓團(tuán)隊(duì)成員的被尊重、被信任、被認(rèn)同感提高，工作動(dòng)力和積極性提高。但是，團(tuán)隊(duì)成長(zhǎng)成熟階段，要多規(guī)范，建立多種合理的制度來管理與約束。獎(jiǎng)勵(lì)是激揚(yáng)人性，懲治是壓抑個(gè)性。二者結(jié)合起來，合適的應(yīng)用。

5、績(jī)效管理：

有一套公開、公正的績(jī)效激勵(lì)體系。結(jié)合每個(gè)成員的自身特點(diǎn)和能力制定，制定合理的績(jī)效。

團(tuán)隊(duì)潛能

通過團(tuán)隊(duì)活動(dòng)、團(tuán)隊(duì)培訓(xùn)等方式，培養(yǎng)協(xié)作精神和團(tuán)隊(duì)精神，提升團(tuán)隊(duì)整體的能力，創(chuàng)造一種良好的氛圍，提高團(tuán)隊(duì)的凝聚力。

加強(qiáng)測(cè)試團(tuán)隊(duì)在整個(gè)項(xiàng)目中的地位和影響力，影響力越強(qiáng)，團(tuán)隊(duì)成員的成就感會(huì)更強(qiáng)，工作的動(dòng)力和信心會(huì)更大，更積極正能量的心態(tài)面對(duì)工作。

團(tuán)隊(duì)提升

通過各種各樣的途徑，培訓(xùn)分享，共享資源庫，或者是團(tuán)隊(duì)圖書館也好，提升團(tuán)隊(duì)整理硬性軟性能力。

流程管理

流程建立

大到項(xiàng)目研發(fā)流程和職責(zé)分工，小到測(cè)試缺陷跟蹤流程、案例評(píng)審流程，都有一個(gè)從無到有制定和完善的階段。

流程實(shí)施

推動(dòng)流程的落實(shí)

流程優(yōu)化

流程的落實(shí)過程中，不斷的總結(jié)經(jīng)驗(yàn)，及時(shí)調(diào)整和完善流程。

質(zhì)量管理

測(cè)試質(zhì)量的保證，是測(cè)試團(tuán)隊(duì)的職責(zé)所需，也是首要標(biāo)準(zhǔn)。

質(zhì)量指標(biāo)

前期要確定一些項(xiàng)目中質(zhì)量的指標(biāo)，比如交付時(shí)間要求、BUG修復(fù)率的要求、用例通過率的要求等等。

質(zhì)量管控

再通過不同的手段來管控，從而實(shí)現(xiàn)和達(dá)成目標(biāo)。

在達(dá)成的過程中需要研發(fā)、產(chǎn)品、測(cè)試、項(xiàng)目經(jīng)理等多個(gè)角色的共同推動(dòng)規(guī)范項(xiàng)目研發(fā)流程、代碼管理流程、缺陷管理流程、測(cè)試案例評(píng)審流程等等。

并且做好測(cè)試分層，從代碼級(jí)、接口級(jí)和ui級(jí)別進(jìn)行測(cè)試，從工具自動(dòng)化和手工多層面進(jìn)行考慮，從功能、性能、兼容安全性等多緯度進(jìn)行覆蓋。從某些方面來講，流程的管理，是質(zhì)量管理的前提。

質(zhì)量分析

通過對(duì)質(zhì)量的可視化數(shù)據(jù)分析，從而加強(qiáng)管控機(jī)制，改善測(cè)試流程，豐富質(zhì)量指標(biāo)。

資源管理

資源整合

整合測(cè)試相關(guān)的技術(shù)、文檔、工具、專利等，成為測(cè)試團(tuán)隊(duì)的知識(shí)資產(chǎn)；整合測(cè)試內(nèi)部、外部的人力、物力、財(cái)力，成為測(cè)試團(tuán)隊(duì)的能量?jī)?chǔ)備。并且對(duì)存檔的資源進(jìn)行維護(hù)和更新。

資源共享

建立統(tǒng)一的共享平臺(tái)，將測(cè)試資源共享，管理測(cè)試用例、管理缺陷、管理測(cè)試方法、測(cè)試技術(shù)工具，減少團(tuán)隊(duì)成員的重復(fù)勞動(dòng)。

資源協(xié)調(diào)

協(xié)調(diào)測(cè)試組內(nèi)的各種資源，協(xié)調(diào)組外的各種資源，共同達(dá)成目標(biāo)。

在人力的協(xié)調(diào)上，一方面需要和團(tuán)隊(duì)內(nèi)、團(tuán)隊(duì)外的人員建立良好的關(guān)系，取得他們的支持，另一方面，建立跨部門的利益相關(guān)性，成為利益共同體。

風(fēng)險(xiǎn)管理

通過對(duì)風(fēng)險(xiǎn)的識(shí)別和分析，選擇有效的方式，主動(dòng)地、有計(jì)劃地處理風(fēng)險(xiǎn)，以最小成本獲得最大的保證。

風(fēng)險(xiǎn)識(shí)別

項(xiàng)目運(yùn)行的各個(gè)環(huán)節(jié)可能出現(xiàn)的風(fēng)險(xiǎn)都應(yīng)關(guān)注，風(fēng)險(xiǎn)信息收集時(shí)需要注重全面性和多樣性。

l 比如需求上存在的缺失，開發(fā)實(shí)現(xiàn)上可能存在的漏洞，測(cè)試案例上可能存在的遺漏，都是項(xiàng)目中常見的風(fēng)險(xiǎn)。

l 常見信息收集手段如現(xiàn)場(chǎng)訪談、會(huì)議研討、問卷調(diào)查等。

風(fēng)險(xiǎn)評(píng)估

通常可以用可能性、嚴(yán)重性，結(jié)合可控性、相關(guān)性幾個(gè)指標(biāo)來描述風(fēng)險(xiǎn)。

比如當(dāng)判斷一個(gè)不能固定重現(xiàn)的BUG到底是否重要需要在上線前修復(fù)時(shí)，可以參考如下風(fēng)險(xiǎn)評(píng)測(cè)標(biāo)準(zhǔn)：

這個(gè)BUG發(fā)生的概率有多高？

這個(gè)BUG對(duì)用戶的體驗(yàn)和使用影響有多大？

這個(gè)BUG如果在生產(chǎn)上出現(xiàn)了，怎樣可以解決和減少影響？

這個(gè)BUG可能引發(fā)其他的問題嗎？

風(fēng)險(xiǎn)應(yīng)對(duì)

采取各種措施減小風(fēng)險(xiǎn)事件發(fā)生的可能性，或者把可能的損失控制在一定的范圍內(nèi)，以避免在風(fēng)險(xiǎn)事件發(fā)生時(shí)帶來的難以承擔(dān)的損失。

風(fēng)險(xiǎn)應(yīng)對(duì)和控制的四種基本方法是：回避、控制、轉(zhuǎn)移和自留。

比如新增加了一個(gè)功能是展示列表，根據(jù)我對(duì)項(xiàng)目組產(chǎn)品和開發(fā)的了解，他們經(jīng)常會(huì)忘記頁面為空白時(shí)怎么顯示。而這一次我相信如果不提前提出來他們?nèi)詴?huì)出現(xiàn)這個(gè)問題。那么我可以采取如下幾種措施：

我知道可能出現(xiàn)這種風(fēng)險(xiǎn)，但是不打算提出來，也不打算搭理他。準(zhǔn)備直接帶著這個(gè)問題上線。——這是回避。

我把風(fēng)險(xiǎn)提出來，然后聲明，這個(gè)問題一旦出現(xiàn)，需要開發(fā)承擔(dān)責(zé)任。——這是轉(zhuǎn)移。

我默默的認(rèn)為這個(gè)風(fēng)險(xiǎn)影響不大，僅保留給自己知悉。后續(xù)等問題暴露出來，再去處理——這是自留。

我把這個(gè)可能出現(xiàn)的問題提出來，讓產(chǎn)品完善需求，開發(fā)提前處理。避免提測(cè)后這個(gè)bug的出現(xiàn)。——這是控制。

以上所有就是我認(rèn)為一個(gè)測(cè)試人員應(yīng)該具備的知識(shí)體系。其實(shí)還有好多我沒接觸過的，比如滲透測(cè)試、單元測(cè)試、安全測(cè)試之類的。接觸的越多，越能感覺到自己會(huì)的太少，共勉。