1 全過程的軟件測試圖解

傳統(tǒng)的軟件測試，開發(fā)人員完成任務(wù)之后，最后交付給測試人員，這種模式下，測試人員不能及早發(fā)現(xiàn)需求階段的缺陷，同時測試工作的開展也滯后了，產(chǎn)品質(zhì)量得不到有效的過程控制和分析，總體進度可能會由于返工問題造成拖延。

什么是全程軟件測試，也可以說全面的軟件測試，如下圖所示：

在整個SDLC中，三條角色主線和四個階段。

三條角色主線：開發(fā)、QA、測試，文中主要講解測試。

四個階段：需求、開發(fā)、發(fā)布、日常運營。

簡單來說可以歸納為下圖所示：

測試人員貫穿這四個階段，開展測試活動，試實踐活動簡單描述如下圖所示：

每個階段也有開發(fā)人員對應(yīng)的活動，以及QA人員對應(yīng)的活動。

對于產(chǎn)品而言，每次版本迭代，都會經(jīng)歷：需求、開發(fā)、發(fā)布，最后推向日常運營，發(fā)布階段虛線指向的需求階段和日常運營階段，并不是一個終止階段，而是不斷迭代的過程。

那測試人員是如何開展全程軟件測試活動的呢？

2 需求階段測試

在需求階段，開發(fā)人員、測試人員、QA人員主要做的事情，如下表所示：

階段	開發(fā)人員	測試人員	QA人員
需求階段	· 用戶故事分析 · 用戶故事估時	· 參與用戶故事分析、挖掘故事含混性 · 參考經(jīng)驗庫質(zhì)疑開發(fā)的時間估算	· 保證確認(rèn)需求活動符合需求管理過程 · 管理用戶故事評審 · 管理需求變更

作為測試人員的主要實踐如下：

參與用戶故事分析、挖掘故事含混性

在sprint會議上，對用戶故事進行分析，檢查功能性需求和非功能性需求是否描述清晰，其中可以將非功能性需求作為驗收要點，例如一個用戶故事：

“客戶希望提高響應(yīng)時間”

測試人員應(yīng)當(dāng)協(xié)助開發(fā)人員消除故事的含混性：提高什么的響應(yīng)時間和響應(yīng)時間為多少？可以建議修改為：

“客戶信息普通查詢返回結(jié)果的響應(yīng)時間為5s內(nèi)”

說明在“客戶信息”模塊，進行“普通查詢”操作，返回結(jié)果的時間在5s內(nèi)，這個陳述句已經(jīng)清晰表達(dá)了，也達(dá)到了消除含混性的效果。同樣，測試人員可以編寫提高查詢效率的用戶故事：

“客戶在信息查詢模塊，進行普通查詢，能夠在5s內(nèi)返回結(jié)果”

“備注：5s為非功能性需求，也是驗收要點”

參考經(jīng)驗庫質(zhì)疑開發(fā)的時間估算

在sprint會議上，開發(fā)人員根據(jù)經(jīng)驗出牌（團隊自己定義的規(guī)則，用撲克牌）估算時間，當(dāng)給出最終結(jié)果的時候，測試人員應(yīng)當(dāng)對其進行質(zhì)疑。測試人員借鑒歷史經(jīng)驗庫：開發(fā)人員在某方面的技能如何、該模塊曾經(jīng)產(chǎn)生過何種程度的缺陷、修復(fù)缺陷的消耗時間是多少等等，綜合考慮，提出疑問，讓開發(fā)估算最終的時間，盡可能考慮這些因素。當(dāng)然，測試人員能夠質(zhì)疑的其中一個前提是：測試人員具備相關(guān)開發(fā)經(jīng)驗。

小結(jié)：在需求階段，測試人員要發(fā)揮作用，減少含混性需求引入到開發(fā)階段、同時協(xié)助開發(fā)做好時間估算。

3 開發(fā)階段測試

在開發(fā)階段，開發(fā)人員、測試人員、QA人員主要做的事情，如下表所示：

階段	開發(fā)人員	測試人員	QA人員
需求階段	· 用戶故事分析 · 用戶故事估時	· 參與用戶故事分析、挖掘故事含混性 · 參考經(jīng)驗庫質(zhì)疑開發(fā)的時間估算	· 保證確認(rèn)需求活動符合需求管理過程 · 管理用戶故事評審 · 管理需求變更

作為測試人員的主要實踐如下：

功能要點確認(rèn)

Xmind是一個非常好用的腦圖工具，通常在開發(fā)人員進行編碼前，測試人員會針對需求處理的用戶故事，與開發(fā)人員進行確認(rèn)，修正理解偏差，確保需求理解一致。

圖-5-腦圖用例模板

測試用例設(shè)計

測試人員主要設(shè)計測試故事點，使用DSL(Domain Specific language)，對測試用例進行描述，包括三個基本要素：

Feature、Scenario、Example，補充要素：xmind、Requirement。

Feature：把測試分類到某個模塊，并對這個特性本身的業(yè)務(wù)目的進行相關(guān)描述，帶進業(yè) 務(wù)目標(biāo)，傳遞業(yè)務(wù)知識。

Scenario：標(biāo)明這個Feature的測試場景，可以使用文字描述步驟，或者使用xmind腦圖

描述，場景中的數(shù)據(jù)使用Examples中列出的。

Example：引出具體的數(shù)據(jù)表格把用到的數(shù)據(jù)都展示出來，避免相同步驟因為測試數(shù)據(jù) 的變化而重復(fù)若干遍造成冗余。

Xmind：腦圖文件，展示測試故事點

Requirement：關(guān)聯(lián)需求管理系統(tǒng)的需求id。

隨著敏捷越來越廣為人知，敏捷測試也更多受到了大家的關(guān)注。在這里，我想談一下我在敏捷項目中遇到的一個自動化測試相關(guān)問題以及我們?nèi)绾谓柚鶧SL領(lǐng)域?qū)Ｓ谜Z言來解決它。

對敏捷軟件開發(fā)方法有一定了解的人都知道，敏捷軟件開發(fā)過程是一個迭代式交付的過程。每個迭代相當(dāng)于比較小型的交付周期。那么，為了配合頻繁的軟件交付，敏捷測試相對于傳統(tǒng)測試必須要做相應(yīng)的調(diào)整。這也導(dǎo)致了敏捷項目中的測試面臨幾個特有的挑戰(zhàn)：

頻繁的回歸測試以確保每個迭代的成果都是可交付的

讓整個開發(fā)團隊參與到測試活動中以縮短質(zhì)量信息的反饋周期

讓客戶參與到測試活動中來幫助提高測試的有效性

自動化測試在應(yīng)對頻繁的回歸測試這個挑戰(zhàn)上起著非常關(guān)鍵的作用。自動化測試做不好，團隊最終會被每個迭代都會增加的回歸測試工作量壓垮。

我經(jīng)歷過的一個團隊，在這個團隊中，大家很早就意識到了自動化測試的重要性，在自動化測試上的投入不遺余力。我們相信自動化功能測試增加到足夠多的時候，它就能指導(dǎo)手動回歸測試，保證整個交付過程順利進行。

的確，自動化測試剛開始進行的時候，我們收益頗多。每增加一個自動化測試，我們就能減少一些手動測試。自動化測試讓我們我們有比較充裕的時間來手動測試那些還沒有來得及自動化的、難以被自動化的功能點上，而且還能有時間和精力做探索性測試。這個結(jié)果讓團隊感到生活很美好，也讓我們對自動化測試堅信不疑

然而好景不長，隨著自動化測試的不斷增加，我們會面臨這樣一些問題：

自動化測試是圍繞著實現(xiàn)細(xì)節(jié)展開的。隨著數(shù)量的增多，業(yè)務(wù)的輪廓很容易迷失在細(xì)節(jié)中。

在功能級別喪失了對測試的追蹤。由于測試人員無法具體知曉那些測試案例被自動化測試覆蓋。每次回歸的時候，團隊都需要回歸整個測試組。

于是，我們的手動測試越來越難得到自動化測試的幫助。它開始成了項目的雞肋。測試代碼閱讀困難、維護困難以及測試結(jié)果的看起來也很費勁。這直接導(dǎo)致了我們不僅要投入相當(dāng)?shù)臅r間來增加自動化測試，也要投入不少時間來閱讀并利用測試結(jié)果。

于是我們開始重新審視自動化測試的做法，繼續(xù)摸索更好的方式。

很快，我們發(fā)現(xiàn)“能夠跑起來”并不是好的自動化測試僅需的特性。讓我們通過一段測試代碼來看一下具體怎么回事。

selenium.open(“/”) selenium.type(“id=username”, “myname”) selenium.type(“id=password”, “mypassword”) selenium.click(“id=btnLogin”) selenium.waitForPageToLoad(30000) assertTrue(selenium.isTextPresent(“Welcome to our website!”))

這個測試中，我們首先打開了一個頁面，在頁面中尋找一個id為username的輸入框，輸入“myname”，然后再尋找一個id為password的輸入框，輸入“password”，然后點擊一個id為btnLogin的按鈕，等待30秒以后，斷言頁面應(yīng)該出現(xiàn)的文字。

我們可以看到，這個測試的實現(xiàn)很完整的描述了測試的操作過程，是一個面向步驟而不是目的的描述。當(dāng)然，稍加分析，我們也可以看出來這個測試的目的是測用戶登錄成功系統(tǒng)。

但是，想象當(dāng)我們有很多這樣面向步驟來描述的測試時，要從中抽離出被無數(shù)細(xì)碎的操作步驟所淹沒的測試意圖，并把測試的結(jié)果利用起來，其實并沒有那么直觀。而且，如果在測試中出現(xiàn)了錯誤，對于問題的具體功能點的定位也不是那么容易。

與此同時，并不是團隊中所有的成員都有能力閱讀和編寫這樣的測試。這無疑降低了團隊成員對于自動化測試的參與度。對于客戶，自動化測試更是一個黑盒子，做了什么，沒做什么，基本上搞不清，更談不上參與到自動化測試中，幫助提高測試的有效性。

種種狀況，究其原因就是測試可讀性太差，測試意圖不夠明顯。可運行并且容易讀的測試才是好的自動化測試。這樣才能夠保證任何時候，我們不會喪失對于測試案例的跟蹤與管理。測試人員隨時都可以通過快速閱讀測試，了解那些功能已經(jīng)被自動化測試覆蓋，有效規(guī)劃手工測試的工作量。

怎么提高測試的可讀性呢？

我們的解決辦法是DSL領(lǐng)域?qū)Ｓ谜Z言。

什么是領(lǐng)域?qū)Ｓ谜Z言？在馬丁大叔的博客里有比較詳細(xì)的描述。大致來說，領(lǐng)域?qū)Ｓ谜Z言就是針對某個領(lǐng)域的特定目的編程語言。不像Java、C#等通用語言，可以解決任何領(lǐng)域的問題。領(lǐng)域?qū)Ｓ谜Z言通過自己獨特的語法結(jié)構(gòu)來描述更接近于專業(yè)領(lǐng)域語言的業(yè)務(wù)。

讓測試的描述能夠接近被測系統(tǒng)的領(lǐng)域語言、使測試意圖得到清晰表達(dá)就是我們想要得到的效果。DSL正好能夠幫我們實現(xiàn)。

讓我們再看看之前的那段代碼：

selenium.open(“/”) selenium.type(“id=username”, “myname”) selenium.type(“id=password”, “mypassword”) selenium.click(“id=btnLogin”) selenium.waitForPageToLoad(30000) assertTrue(selenium.isTextPresent(“Welcome to our website!”))

由于使用的是通用語言，在我們這個特定的使用場景中顯得過于細(xì)節(jié)化、過程化，不能清晰表達(dá)測試意圖。

換成DSL，我們的測試就可以直接用驗收標(biāo)準(zhǔn)的語言來描述如下：

Given I am on login page When I provide username and password Then I can enter the system

這樣測試的內(nèi)容就直觀多了，還包含了一些業(yè)務(wù)信息，讓我們知道這個是在測試一個登錄的場景，而不是任意的輸入信息，兼顧傳遞了業(yè)務(wù)知識的職責(zé)。至于這些DSL背后能夠運行的代碼，也被隱藏起來。如果是不能夠閱讀原來那樣的測試代碼的人（不管是需求分析人員還是客戶甚至一些對自動化代碼關(guān)注比較少的測試人員）想要加入到自動化測試活動中進行反饋，就不會被DSL背后的代碼帶來的“噪音”所影響。

當(dāng)然，在我們的現(xiàn)實應(yīng)用場景中，這個需求沒有那么簡單，我們的驗收標(biāo)準(zhǔn)還會考慮不同的數(shù)據(jù)比如輸入不同組合的用戶名密碼：

Given I am on login page When I provide ‘david’ and ‘davidpassword’ Then I can enter the system Given I am on login page When I provide ‘kate’ and ‘kate_p@ssword’ Then I can enter the system

以及更多的測試數(shù)據(jù)。

那么這種情況下，僅僅是比較通俗的語言還是不夠的，畢竟測試數(shù)量在那擺著。如果測試數(shù)量不能減少，維護起來仍然很麻煩。打個比方，如果系統(tǒng)的實現(xiàn)變成了每次都要輸入用戶名、密碼和一個隨機驗證碼，我們就需要在我們的自動化測試中修改多處，比較繁瑣。因此，我們需要在可讀性比較好的自然語言描述的測試上，把它的抽象層次再提高一點。

幸運的是，我們當(dāng)時選擇的DSL工具是cucumber，它除了提供了幾個測試的描述層次：Feature，Scenario，Steps，還提供了非常好的一種組織方式—數(shù)據(jù)表。

這樣，我們的這個自動化測試就可以把之前的那個登錄的功能根據(jù)特性、場景總結(jié)和具體的步驟分離開來，清晰的分層，同時利用數(shù)據(jù)表我們的測試精簡成一系列被重復(fù)多次但輸入數(shù)據(jù)有所變化的操作過程，如下：

Feature: authentication In order to have personalized information I want to access my account by providing authentication information So that the system can know who I am Scenario Outline: login successfully Given I am on login page When I provide ‘<username>’ and ‘<password>’ Then I can enter the system Examples: |username |password | |david |davidpass | |kate |kate_p@ssword|

測試這下看起來就更清爽了。首先，用Feature關(guān)鍵字，我們把測試分類到login這個大特性下的，并對這個特性本身的業(yè)務(wù)目的進行相關(guān)描述，帶進業(yè)務(wù)目標(biāo)，傳遞業(yè)務(wù)知識；然后用Scenario關(guān)鍵字來提高挈領(lǐng)的標(biāo)明我們這個測試場景中做的是測試登錄成功的情況，并且把步驟都寫出來；最后，我們用Examples關(guān)鍵字引出具體的數(shù)據(jù)表格把用到的數(shù)據(jù)都展示出來，避免我們的相同步驟因為測試數(shù)據(jù)的變化而重復(fù)若干遍造成冗余。萬一碰上了需求的變化，要求同時提供用戶名、密碼和驗證碼，那我們的測試也只需要改動較少的地方就足夠了。

更棒的是，用了這種數(shù)據(jù)表的方式，整個團隊的協(xié)作效率提高了。對于寫代碼沒有那么順暢的測試人員來說，增加自動化測試也就是增加更多測試數(shù)據(jù)，填充到數(shù)據(jù)表里就可以了。

就這樣，我們用DSL實現(xiàn)了可執(zhí)行的可讀性高的文檔。幫助了回歸測試，降低了文檔維護難度，也促進團隊成員利用測試來傳遞知識的積極性，讓更多人能夠參與到測試中。

用例評審

主要是堅持同行評審的原則，主要在測試組內(nèi)進行，負(fù)責(zé)該任務(wù)的開發(fā)人員也會參與，簡單來說就是對測試用例進行查漏補缺的工作。

測試探索

進行了“功能要點確認(rèn)”和“用例評審”后，為了保證測試場景的覆蓋率，需要再進行測試探索。在開發(fā)人員完成雛形之后，使用探索式測試的策略，對功能基本流程進行有目的的快速走查，挖掘功能不確定的地方和補充測試場景，避免不確定的因素拖延到開發(fā)階段后期，造成返工。

其中：功能測試、Bug Tracking、回歸測試、系統(tǒng)測試、驗收測試都是日常測試工作所需環(huán)節(jié)。

燃盡圖發(fā)布

另外，測試人員還有一項重要工作，每日發(fā)布燃盡圖，讓團隊了解當(dāng)前進度情況，總結(jié)問題

所在，尋求耗時超過預(yù)期時間任務(wù)的解決辦法。

圖-6-燃盡圖

圖形特點：

1）剩余工時在計劃基準(zhǔn)上方，代表進度有所延遲，應(yīng)抓緊進度；

發(fā)現(xiàn)此類問題，需要分析總結(jié)，原則是保證交付時間，對相應(yīng)任務(wù)進行調(diào)整，擁抱變化，發(fā)現(xiàn)任務(wù)粒度太大，該拆分的繼續(xù)拆分；對于重構(gòu)需要慎重，不要過度深入重構(gòu)，給測試帶來額外工作量，影響整個進度，對于整個版本而言，只有開發(fā)、測試在承諾的時間內(nèi)完成任務(wù)，才是真正完成，僅僅開發(fā)完成交付算不上成功。

2）剩余工時在計劃基準(zhǔn)接近，代表進展良好，繼續(xù)保持；

此時也需要查看在這種進度下，優(yōu)先級高的任務(wù)是否得到時間保證，而不是因為處理完簡單任務(wù)才使得燃盡圖長的好看。往往有些開發(fā)人員，喜歡挑著任務(wù)來做，把簡單易做、優(yōu)先級的任務(wù)先完成了，因為這些總在預(yù)期內(nèi)能夠完成，所以前期燃盡圖的趨勢看起來沒有問題。

缺陷經(jīng)驗庫

每個團隊都存在開發(fā)/測試新人和開發(fā)/測試?yán)先?#xff0c;當(dāng)測試人員與開發(fā)新人進行需求確認(rèn)的時候，還需要進行缺陷經(jīng)驗教訓(xùn)的提醒，避免多走彎路。

提升開發(fā)自測質(zhì)量

測試人員可以提供相關(guān)checklist（大家可以根據(jù)原作者提供的修改為符合團隊的）幫助開發(fā)人員在編碼過程中關(guān)注開發(fā)自測的要點，從而提升質(zhì)量。

圖-8-web軟件測試checklist

持續(xù)集成

利用持續(xù)集成（Jenkins）平臺，做到快速的構(gòu)建開發(fā)代碼，自動的單元測試化，來提高開發(fā)代碼的效率和質(zhì)量。

負(fù)責(zé)單元測試的開發(fā)人員，會收到失敗構(gòu)建的郵件；

負(fù)責(zé)集成測試的開發(fā)人員，會收到失敗構(gòu)建的郵件；

負(fù)責(zé)自動化測試（Selenium）的測試負(fù)責(zé)人員，會收到失敗構(gòu)建的郵件；

這種方式，確保單元測試、集成測試、自動化測試，有相關(guān)人員關(guān)注和維護。

圖-9-持續(xù)集成

Sonar反饋

Sonar is an open platform to manage code quality. As such, it covers the 7 axes of code quality。

sonar分析結(jié)果

測試人員主要反饋問題如下：

Code coverage：團隊要求代碼覆蓋率在80%以上；

Test success：團隊要求測試成功率在100%；

Duplications：團隊要求代碼重復(fù)率在10%以下；

Violations：團隊要求Major類別的代碼規(guī)則缺陷在20以下；

開發(fā)團隊必須保證每個環(huán)境的質(zhì)量目標(biāo)，才能夠保證整個的質(zhì)量目標(biāo)。

小結(jié)：

測試人員與開發(fā)人員永遠(yuǎn)不是敵對關(guān)系，而是協(xié)助關(guān)系，確切來說是質(zhì)量天枰的兩邊，任何一邊的工作沒有做好，都會失去平衡。

4 發(fā)布階段測試

在發(fā)布階段，開發(fā)人員、測試人員、QA人員主要做的事情，如下表所示：

階段	開發(fā)人員	測試人員	QA人員
發(fā)布階段	· 上線申請 · 上線部署 · 服務(wù)監(jiān)控	· 測試報告 · 線上功能檢查	· 管理評審活動 · 管理文檔產(chǎn)物

作為測試人員的主要實踐如下：

測試報告

完成驗收測試，提供測試報告，給出測試數(shù)據(jù)度量，例如：

• 測試發(fā)現(xiàn)缺陷總數(shù)：測試過程中產(chǎn)生的去除狀態(tài)為“無效”、“不用改”的缺陷數(shù)目。
• 測試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)：測試過程中產(chǎn)生的并去除狀態(tài)為“無效”、“不用改”的、且嚴(yán)重性為“Major”和“Critical”的缺陷總數(shù)目。
• 測試發(fā)現(xiàn)缺陷修復(fù)數(shù)：測試過程中產(chǎn)生的狀態(tài)為“已關(guān)閉”的缺陷數(shù)量；
• 未解決缺陷數(shù)：去除狀態(tài)為“無效”、“不用改”、“關(guān)閉”的缺陷總數(shù)。
• 缺陷修復(fù)率：（測試發(fā)現(xiàn)缺陷的修復(fù)數(shù)）÷（測試發(fā)現(xiàn)缺陷總數(shù)）×100％
• 嚴(yán)重缺陷率：（測試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)）÷（測試發(fā)現(xiàn)缺陷總數(shù)）×100％
• 嚴(yán)重缺陷修復(fù)率：（已修復(fù)的嚴(yán)重缺陷數(shù)）÷（測試發(fā)現(xiàn)嚴(yán)重缺陷數(shù)）×100％
• 測試需求覆蓋率：已測試需求個數(shù)÷需求總數(shù)×100%

缺陷統(tǒng)計分析報告

另外，測試人員還有一項重要工作，對當(dāng)前版本的缺陷進行統(tǒng)計分析：

按缺陷級別統(tǒng)計：

	Critical	Major	Medium	Minor	總計
首頁	0	0	1	0	1
模塊一	0	0	0	2	2
模塊二	0	1	2	10	13
模塊三	0	0	1	4	5
模塊四	0	0	1	2	3
模塊五	0	0	3	2	5
模塊六	0	1	0	1	2
模塊七	0	2	0	6	8
sonar	0	1	2	0	3
總計	0	5	10	27

圖-11-缺陷統(tǒng)計

按缺陷來源統(tǒng)計：

	開發(fā)1	開發(fā)2	開發(fā)3	開發(fā)4	開發(fā)5	遺留
Critical	0	0	0	0	0	0
Major	1	2	0	0	0	2
Medium	1	7	0	1	0	1
Minor	1	7	4	6	3	6
總計	3	16	4	7	3	9

按缺陷狀態(tài)統(tǒng)計：

缺陷總數(shù)	已關(guān)閉缺陷數(shù)	遺留	缺陷修復(fù)率	嚴(yán)重缺陷數(shù)	嚴(yán)重缺陷率	已關(guān)閉嚴(yán)重缺陷數(shù)	嚴(yán)重缺陷修復(fù)率
42	40	2	95%	5	12%	5	100%

測試進度和問題分析：

1. 從BUG的嚴(yán)重級別分布來看，Major級別以上的BUG占12%，占的比重不高，說明大部分的主要功能已經(jīng)實現(xiàn)了；

2. 其中在sonar定義級別的缺陷，主要集中在代碼規(guī)范和單元測試覆蓋率，說明代碼質(zhì)量有待提高；

3. 版本測試的前期時間較充足，后期隨著開發(fā)提交完成的功能點增多，BUG數(shù)量增多，剩余測試時間變得緊張；

4. 在版本測試期間，發(fā)現(xiàn)測試環(huán)境存在一次代碼被覆蓋、兩次因開發(fā)人員操作失誤影響測試執(zhí)行的情況；

小結(jié)：

測試人員應(yīng)當(dāng)持續(xù)反饋、改進、總結(jié)每個版本發(fā)生的問題（不管是缺陷，還是過程中出現(xiàn)的），并對缺陷進行分析，總結(jié)出一些規(guī)律，幫助開發(fā)人員建立良好的習(xí)慣，改進代碼的質(zhì)量。

5 日常運營階段測試

在日常運營階段，開發(fā)人員、測試人員、QA人員主要做的事情，如下表所示：

階段	開發(fā)人員	測試人員	QA人員
日常運營	生產(chǎn)故障登記	· 版本問題反饋和改進提議 · 生產(chǎn)故障分析	管理日常運營活動

日常運營階段，并不是終止階段，即便需求、開發(fā)、發(fā)布階段暫?；顒?#xff0c;只要產(chǎn)品提供服務(wù)，日常運營都存在著。

作為測試人員的主要實踐如下：

版本問題反饋和改進提議

對日常運營發(fā)生的問題，總結(jié)反饋，提出改進建議，并且跟蹤實施。

生產(chǎn)故障分析

協(xié)助開發(fā)排查生產(chǎn)故障，避免測試場景的遺漏。

6 人力資源

軟件測試并不是保證產(chǎn)品質(zhì)量的最后一道防線，測試人員也不是，測試人員的工作完全可以由更加資深的開發(fā)人員來完成，不過現(xiàn)實總是殘酷的，目前測試與開發(fā)的比例為：1:3，在成熟的團隊是這樣子，另外一些還在持續(xù)改進的團隊，由于資源不足，可能去到1:7。開發(fā)人員在相當(dāng)長的一段時間內(nèi)不可能完全替代測試人員，有個關(guān)鍵要素：思維方式不同，有句古話來形容：江山易改本性難移。當(dāng)開發(fā)人員的思維方式改變的時候，那就成為測試人員了，倒不如把測試人員獨立出來更好，并且培養(yǎng)給開發(fā)人員一定的測試素養(yǎng)，這個對保證產(chǎn)品質(zhì)量都是有幫助的。

全程軟件測試實踐，強調(diào)的是貫穿每個階段的測試活動，不論是開發(fā)、還是測試，要理解雙方的活動價值，什么時候該做什么事情，什么事情該做到什么程度才算好，保證每個環(huán)節(jié)的質(zhì)量，才能夠保證產(chǎn)品的全程質(zhì)量，另外產(chǎn)品質(zhì)量不是測試出來的，而是構(gòu)建過程中沉淀下來的，開發(fā)人員的素養(yǎng)、測試人員的素養(yǎng)、以及團隊對開發(fā)測試過程的重視程度，決定了產(chǎn)品質(zhì)量。產(chǎn)品質(zhì)量就如同一塊蛋糕，應(yīng)當(dāng)切分為小塊，落實到每個人手里，讓每個人嘗到甜頭，擔(dān)當(dāng)起來。

7 TQM(全面質(zhì)量管理) in Software

這是一個延伸與關(guān)聯(lián)，過程如下:

TQM是以產(chǎn)品質(zhì)量為核心，建立起一套科學(xué)嚴(yán)密高效的質(zhì)量體系，以提供滿足用戶需要的產(chǎn)品的全部活動.

在軟件業(yè)，軟件質(zhì)量得不到提高主要原因在于質(zhì)量觀念的缺乏，而將全面質(zhì)量管理的思想運用于軟件業(yè)，是提高軟件產(chǎn)品質(zhì)量、獲取競爭優(yōu)勢的有效手段。CMM不但對于指導(dǎo)過程改進是一項很好的工具，而且把全面質(zhì)量管理概念應(yīng)用到軟件上，實現(xiàn)從需求管理到項目計劃、項目控制、軟件獲取、質(zhì)量保證、配置管理的軟件過程全面質(zhì)量管理。CMM的思想是一切從顧客需求出發(fā)，從全組織層面上實施過程質(zhì)量管理，正符合了TQM的基本原則。因此，它的意義不僅僅是對軟件開發(fā)的過程進程控制，最關(guān)鍵的它還是一種高效的管理方法，有助于企業(yè)最大程度的降低成本，提高質(zhì)量和用戶滿意度。

軟件質(zhì)量管理體現(xiàn)TQM的運行機制 軟件質(zhì)量管理是CMM四級中一個獨立的KPA，其目的是使項目的軟件質(zhì)量管理活動是有計劃的、軟件產(chǎn)品的質(zhì)量目標(biāo)是量化的和受到管理的。它遵循了全面質(zhì)量管理活動的科學(xué)程序—PDCA（Plan、Do、Check、Action），即四個階段:

（1） 計劃:即確定質(zhì)量目標(biāo)以及實現(xiàn)這個目標(biāo)需要采取的措施。制定質(zhì)量計劃是整個質(zhì)量管理活動的基礎(chǔ)。國家標(biāo)準(zhǔn)對質(zhì)量下的定義為: 質(zhì)量是產(chǎn)品或服務(wù)滿足明確或隱含需要能力的特征和特性的總和。

對于軟件來說，軟件質(zhì)量則體現(xiàn)在質(zhì)量特性上，ISO/IEC9126中規(guī)定了6個質(zhì)量特性，即功能性、可靠性、易用性、效率、可維護性和可一致性，每個特性包含若干子特性。設(shè)定質(zhì)量目標(biāo)就是要找到用戶的質(zhì)量需求與這些質(zhì)量特性的相關(guān)性，并將其轉(zhuǎn)化為開發(fā)過程中可度量的技術(shù)指標(biāo)或能力指標(biāo)，作為質(zhì)量控制的依據(jù)。

上述的六大特性屬于軟件的外部屬性，與用戶滿意度直接相關(guān)，可以根據(jù)組織的目標(biāo)和項目的特點建立質(zhì)量模型，并采用一定的方法，如QFD（Quality Function Deployment）、GQM（Goal Question Metrics）等確定量化的質(zhì)量目標(biāo)，但這在實際工作中往往是相當(dāng)復(fù)雜和難以獲得的。因此，更常用的做法是以過程能力目標(biāo)反映產(chǎn)品質(zhì)量目標(biāo)，一個典型的能力指標(biāo)就是缺陷密度（即每單位規(guī)模工作產(chǎn)品中存在的缺陷數(shù)）和相應(yīng)的階段缺陷排錯率，可以根據(jù)歷史數(shù)據(jù)估計產(chǎn)品的規(guī)模和目標(biāo)缺陷密度，從而對每個階段發(fā)現(xiàn)的缺陷數(shù)量進行控制。

（2） 實施 ：即按預(yù)定計劃、目標(biāo)措施及其分工實際執(zhí)行。為了在過程中控制軟件的質(zhì)量，需采取相應(yīng)的手段在預(yù)定的階段點或里程碑上進行軟件工作產(chǎn)品質(zhì)量的測量，常用的方法有 同行評審、原型評價、測試等。這些方法主要從兩方面對軟件的質(zhì)量進行度量，一是內(nèi)部屬性，即過程和活動自身可以度量的屬性，例如工作產(chǎn)品的缺陷密度 ；二是外部屬性，即與用戶環(huán)境相關(guān)的屬性，這些屬性在過程中往往難以度量，只有通過在項目的早期引入用戶測試來予以評價，而讓用戶參與開發(fā)過程，大大有利于產(chǎn)品質(zhì)量的提高。

（3） 檢查 ：即把實施的結(jié)果和計劃的要求對比，檢查計劃的執(zhí)行情況和實施的效果，是否達(dá)到預(yù)期的目標(biāo)，并找出原因。在對質(zhì)量度量的結(jié)果進行分析時，往往會用到一些統(tǒng)計工具和方法，如檢查表、直方圖、控制圖、Pareto圖、散布圖、因果圖、運行圖等。這些工具可以幫助確定問題、評估現(xiàn)狀、發(fā)現(xiàn)原因甚至形成下一步措施。

（4） 處理 ：即總結(jié)經(jīng)驗教訓(xùn)，將未解決的問題作為下一階段制定計劃的依據(jù)。CMM要求對軟件質(zhì)量測量的結(jié)果分析后，應(yīng)“采取合適的與軟件質(zhì)量計劃相一致的措施，以便使得產(chǎn)品的質(zhì)量測量結(jié)果與軟件質(zhì)量目標(biāo)相符合”。

總結(jié)

以上是生活随笔為你收集整理的全面的软件测试-软件测试图解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。