全面的軟件測試

1 全過程的軟件測試圖解

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

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

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

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

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

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

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

每個階段也有開發人員對應的活動，以及QA人員對應的活動。

對於產品而言，每次版本迭代，都會經歷：需求、開發、發布，最后推向日常運營，發布階段虛線指向的需求階段和日常運營階段，並不是一個終止階段，而是不斷迭代的過程。

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

2 需求階段測試

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

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

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

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

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

“客戶希望提高響應時間”

測試人員應當協助開發人員消除故事的含混性：提高什么的響應時間和響應時間為多少？可以建議修改為：

“客戶信息普通查詢返回結果的響應時間為5s內”

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

“客戶在信息查詢模塊，進行普通查詢，能夠在5s內返回結果”

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

參考經驗庫質疑開發的時間估算

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

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

3 開發階段測試

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

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

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

功能要點確認

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

 

圖-5-腦圖用例模板

測試用例設計

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

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

Feature：把測試分類到某個模塊，並對這個特性本身的業務目的進行相關描述，帶進業 務目標，傳遞業務知識。

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

描述，場景中的數據使用Examples中列出的。

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

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

Requirement：關聯需求管理系統的需求id。

隨着敏捷越來越廣為人知，敏捷測試也更多受到了大家的關注。在這里，我想談一下我在敏捷項目中遇到的一個自動化測試相關問題以及我們如何借助DSL領域專用語言來解決它。

對敏捷軟件開發方法有一定了解的人都知道，敏捷軟件開發過程是一個迭代式交付的過程。每個迭代相當於比較小型的交付周期。那么，為了配合頻繁的軟件交付，敏捷測試相對於傳統測試必須要做相應的調整。這也導致了敏捷項目中的測試面臨幾個特有的挑戰：

1. 頻繁的回歸測試以確保每個迭代的成果都是可交付的
2. 讓整個開發團隊參與到測試活動中以縮短質量信息的反饋周期
3. 讓客戶參與到測試活動中來幫助提高測試的有效性

自動化測試在應對頻繁的回歸測試這個挑戰上起着非常關鍵的作用。自動化測試做不好，團隊最終會被每個迭代都會增加的回歸測試工作量壓垮。

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

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

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

1. 自動化測試是圍繞着實現細節展開的。隨着數量的增多，業務的輪廓很容易迷失在細節中。
2. 在功能級別喪失了對測試的追蹤。由於測試人員無法具體知曉那些測試案例被自動化測試覆蓋。每次回歸的時候，團隊都需要回歸整個測試組。

於是，我們的手動測試越來越難得到自動化測試的幫助。它開始成了項目的雞肋。測試代碼閱讀困難、維護困難以及測試結果的看起來也很費勁。這直接導致了我們不僅要投入相當的時間來增加自動化測試，也要投入不少時間來閱讀並利用測試結果。

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

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

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秒以后，斷言頁面應該出現的文字。

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

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

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

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

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

我們的解決辦法是DSL領域專用語言。

什么是領域專用語言？在馬丁大叔的博客里有比較詳細的描述。大致來說，領域專用語言就是針對某個領域的特定目的編程語言。不像Java、C#等通用語言，可以解決任何領域的問題。領域專用語言通過自己獨特的語法結構來描述更接近於專業領域語言的業務。

讓測試的描述能夠接近被測系統的領域語言、使測試意圖得到清晰表達就是我們想要得到的效果。DSL正好能夠幫我們實現。

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

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!”))

由於使用的是通用語言，在我們這個特定的使用場景中顯得過於細節化、過程化，不能清晰表達測試意圖。

換成DSL，我們的測試就可以直接用驗收標准的語言來描述如下：

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

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

當然，在我們的現實應用場景中，這個需求沒有那么簡單，我們的驗收標准還會考慮不同的數據比如輸入不同組合的用戶名密碼：

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

以及更多的測試數據。

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

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

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

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關鍵字，我們把測試分類到login這個大特性下的，並對這個特性本身的業務目的進行相關描述，帶進業務目標，傳遞業務知識；然后用Scenario關鍵字來提高挈領的標明我們這個測試場景中做的是測試登錄成功的情況，並且把步驟都寫出來；最后，我們用Examples關鍵字引出具體的數據表格把用到的數據都展示出來，避免我們的相同步驟因為測試數據的變化而重復若干遍造成冗余。萬一碰上了需求的變化，要求同時提供用戶名、密碼和驗證碼，那我們的測試也只需要改動較少的地方就足夠了。

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

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

用例評審

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

測試探索

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

其中：功能測試、Bug Tracking、回歸測試、系統測試、驗收測試都是日常測試工作所需環節。

燃盡圖發布

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

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

圖-6-燃盡圖

圖形特點：

1）剩余工時在計划基准上方，代表進度有所延遲，應抓緊進度；

發現此類問題，需要分析總結，原則是保證交付時間，對相應任務進行調整，擁抱變化，發現任務粒度太大，該拆分的繼續拆分；對於重構需要慎重，不要過度深入重構，給測試帶來額外工作量，影響整個進度，對於整個版本而言，只有開發、測試在承諾的時間內完成任務，才是真正完成，僅僅開發完成交付算不上成功。

2）剩余工時在計划基准接近，代表進展良好，繼續保持；

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

缺陷經驗庫

每個團隊都存在開發/測試新人和開發/測試老人，當測試人員與開發新人進行需求確認的時候，還需要進行缺陷經驗教訓的提醒，避免多走彎路。

提升開發自測質量

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

 

圖-8-web軟件測試checklist

持續集成

利用持續集成（Jenkins）平台，做到快速的構建開發代碼，自動的單元測試化，來提高開發代碼的效率和質量。

負責單元測試的開發人員，會收到失敗構建的郵件；

負責集成測試的開發人員，會收到失敗構建的郵件；

負責自動化測試（Selenium）的測試負責人員，會收到失敗構建的郵件；

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

圖-9-持續集成

Sonar反饋

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

sonar分析結果

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

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

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

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

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

開發團隊必須保證每個環境的質量目標，才能夠保證整個的質量目標。

小結：

測試人員與開發人員永遠不是敵對關系，而是協助關系，確切來說是質量天枰的兩邊，任何一邊的工作沒有做好，都會失去平衡。

4 發布階段測試

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

階段	開發人員	測試人員	QA人員
發布階段	· 上線申請 · 上線部署 · 服務監控	· 測試報告 · 線上功能檢查	· 管理評審活動 · 管理文檔產物

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

測試報告

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

• 測試發現缺陷總數：測試過程中產生的去除狀態為“無效”、“不用改”的缺陷數目。
• 測試發現嚴重缺陷數：測試過程中產生的並去除狀態為“無效”、“不用改”的、且嚴重性為“Major”和“Critical”的缺陷總數目。
• 測試發現缺陷修復數：測試過程中產生的狀態為“已關閉”的缺陷數量；
• 未解決缺陷數：去除狀態為“無效”、“不用改”、“關閉”的缺陷總數。
• 缺陷修復率：（測試發現缺陷的修復數）÷（測試發現缺陷總數）×100％
• 嚴重缺陷率：（測試發現嚴重缺陷數）÷（測試發現缺陷總數）×100％
• 嚴重缺陷修復率：（已修復的嚴重缺陷數）÷（測試發現嚴重缺陷數）×100％
• 測試需求覆蓋率：已測試需求個數÷需求總數×100%

缺陷統計分析報告

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

按缺陷級別統計：

	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-缺陷統計

按缺陷來源統計：

	開發1	開發2	開發3	開發4	開發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

按缺陷狀態統計：

缺陷總數	已關閉缺陷數	遺留	缺陷修復率	嚴重缺陷數	嚴重缺陷率	已關閉嚴重缺陷數	嚴重缺陷修復率
42	40	2	95%	5	12%	5	100%

測試進度和問題分析：

1. 從BUG的嚴重級別分布來看，Major級別以上的BUG占12%，占的比重不高，說明大部分的主要功能已經實現了；

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

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

4. 在版本測試期間，發現測試環境存在一次代碼被覆蓋、兩次因開發人員操作失誤影響測試執行的情況；

小結：

測試人員應當持續反饋、改進、總結每個版本發生的問題（不管是缺陷，還是過程中出現的），並對缺陷進行分析，總結出一些規律，幫助開發人員建立良好的習慣，改進代碼的質量。

5 日常運營階段測試

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

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

日常運營階段，並不是終止階段，即便需求、開發、發布階段暫停活動，只要產品提供服務，日常運營都存在着。

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

版本問題反饋和改進提議

對日常運營發生的問題，總結反饋，提出改進建議，並且跟蹤實施。

生產故障分析

協助開發排查生產故障，避免測試場景的遺漏。

6 人力資源

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

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

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

這是一個延伸與關聯，過程如下:

TQM是以產品質量為核心，建立起一套科學嚴密高效的質量體系，以提供滿足用戶需要的產品的全部活動.

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

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

（1） 計划:即確定質量目標以及實現這個目標需要采取的措施。制定質量計划是整個質量管理活動的基礎。國家標准對質量下的定義為: 質量是產品或服務滿足明確或隱含需要能力的特征和特性的總和。

對於軟件來說，軟件質量則體現在質量特性上，ISO/IEC9126中規定了6個質量特性，即功能性、可靠性、易用性、效率、可維護性和可一致性，每個特性包含若干子特性。設定質量目標就是要找到用戶的質量需求與這些質量特性的相關性，並將其轉化為開發過程中可度量的技術指標或能力指標，作為質量控制的依據。

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

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

（3） 檢查 ：即把實施的結果和計划的要求對比，檢查計划的執行情況和實施的效果，是否達到預期的目標，並找出原因。在對質量度量的結果進行分析時，往往會用到一些統計工具和方法，如檢查表、直方圖、控制圖、Pareto圖、散布圖、因果圖、運行圖等。這些工具可以幫助確定問題、評估現狀、發現原因甚至形成下一步措施。

（4） 處理 ：即總結經驗教訓，將未解決的問題作為下一階段制定計划的依據。CMM要求對軟件質量測量的結果分析后，應“采取合適的與軟件質量計划相一致的措施，以便使得產品的質量測量結果與軟件質量目標相符合”。

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

希望對您公司IT軟件研發與質量管理有幫助。 其它您可能感興趣的文章：
敏捷軟件質量保證的方法與實踐
構建高效的研發與自動化運維
IT運維監控解決方案介紹
IT持續集成之質量管理
人才公司環境與企業文化
企業績效管理系統之平衡記分卡
企業文化、團隊文化與知識共享
高效能的團隊建設
組織目標與個人目標
餐飲連鎖公司IT信息化解決方案一

如有想了解更多軟件研發 , 系統 IT集成 , 企業信息化，項目管理，企業管理 等資訊，請關注我的微信訂閱號：

 

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
該文章也同時發布在我的獨立博客中-Petter Liu Blog。