讓Quality Center走下神壇--測試管理工具大PK（轉）

讓Quality Center走下神壇--測試管理工具QC/ALM 和 RQM、Jira、TP、SCTM大PK

　　在寫完了《讓QTP走下神壇》以後，如今來談談測試管理工具，獻給全部正在或打算作測試管理工做的同行。

　　固然，話題離不了Quality Center——但又不僅是談QC，我會結合對比各類主流的企業級測試管理工具，包括標題提到的：HP QC/ALM、IBM RQM、51Testing TP、Micro Focus SCTM、Atlassian Jira。可是不會說起Bugzilla、Bugfree、Mantis這些，由於它們只能屬於缺陷管理工具，和以上幾款工具不在一個級別上。

　　固然，得先從QC提及。

　　既然說起Quality Center，就得先談Mercury，而既然說起Mercury，就得先談HP。畢竟是大環境的衰敗造就了QC的沒落，難道不是嗎？

　　（一）所以，先說HP。

　　HP原來有三大業務：PSG、IPG、EB，分別是我的電腦，打印和影像設備，企業級業務（軟件服務）。PC業務利潤微薄，壓力大，HP早已江河日下；打印機掃描儀隨着iPad等設備出現，早已經疲態盡顯；HP倒一直想模仿IBM轉型服務，號稱要打造「Service Anywhere（一切皆服務）」，但從QTP、LoadRunner和Quality Center多年以來除了更換了華麗的界面，新增了零星半點的小特性，愈來愈耗資源，愈來愈不穩定，甚至繼續保留着一堆N年之前的Bug，……，管中窺豹，可知其所謂的服務愈來愈流於表面了。

　　聽說今年HP對外宣稱本身作組織架構調整，變爲PPS（打印）、EG（企業集團）、ES（企業服務）和HP Software（軟件），我對HP內部不太熟，不過在我看來換湯不換藥。它們在歷史上架構不知道調整了多少次，用業內人的說法是「老是在用一個錯誤糾正另外一個錯誤」。

　　（二）再說Mercury和Quality Center。

　　HP在2006年7月以45億美圓收購了Mercury公司。而在此以前，Mercury是專一與軟件測試工具研發的專業廠商，曾幾什麼時候在測試工具這塊與Rational、Segue號稱「測試三巨頭」。它們推出的每一款產品都堪稱劃時代：測試管理工具TestDirector、性能測試工具LoadRunner、功能測試自動化工具WinRunner/QuickTest，分別迅速佔領了全球70%左右的市場，時至今日，仍然威震江湖。

　　QC爲何能有很強大的用戶基礎，其實不是由於QC的強大，歸根結底，是TD當年打下大片江山，佔盡了用戶基礎。我是從TD(TestDirector 7.2)開始用的，十年前當我第一次看到TestDirector真的是「亮瞎了眼」！世界上竟然有這麼Cool的測試管理工具！亮點在哪裏？

　　TD的安裝至關簡單，幾乎是傻瓜式操做，「下一步」、「下一步」、……、「完成」。連數據庫都刪繁就簡的採用Access，安裝的便捷，怎一個爽字了得！

　　並且基本不太消耗內存資源，使用起來一點都不卡。

　　二、強大的易用性。

　　TD的設計思路簡單清晰，整個過程就是：寫測試需求–》寫測試用例–》執行測試用例–》提交缺陷、跟蹤缺陷。總共只有四件事，並且徹底符合Testers的平常工做流程。在當時同類競爭對手幾乎只有缺陷管理工具Mantis、Bugfree、Bugzilla、ClearQuest，論強大論易用性都明顯被拉開了一大截——絕對領先優點！

　　三、放號策略。

　　你們應該都還記得著名的TD License吧？有人稱之爲「Sale Policy」。什麼意思呢？就是當初Mercury推出TD 7.6的時候，網上馬上有人出來發佈TD 7.2的License；當Mercury推出8.0的時候，網上馬上有人出來發佈TD 7.6的License；當HP Mercury推出Quality Center 8.2的時候，網上馬上有人出來發佈TD 8.0的License……

　　呵呵，就這麼巧合，至於爲何會這樣，明眼人一看就知。如今明白什麼叫「Sale Policy」了嗎？我先讓你用舊版的，等你用上了之後，數據都在上面了，而後我推新版的，誘惑你用，……，一步步讓你深陷其中，當你有一天發現你已經離不開個人時候，我對你實行收費……WOW！pfpf，果真厲害！因此，一代又一代的Test Manager前赴後繼，大力推行TD。51Testing軟件測試網%t Vm%}'p！i+_

　　可是大家看，如今HP ALM還有嗎？我絕不懷疑，沒有繼續延續以前的戰略方針，ALM確實正在不斷失守城池。《2012年測試從業人員調查報告》能夠清晰看到，下面會有詳細描述。

　（三）嫁對男人是女人一輩子的事業。

　　悲劇就在這裏，自從HP收購了Mercury，內部發生了大動亂，HP素以摳門聞名，收購了Mercury研發團隊後，不少人的薪資被砍掉了三分之二！因而整個團隊分崩離析……

　　這也是爲何你們總感受當初使用Mercury工具的時候那樣心潮澎湃，如今往往看到HP的升級版卻諸多失望多於指望。由於最核心的高層、架構師和專家早已離開了HP Mercury團隊。

　　因此，大家都看到了，……，就像QTP的新版本UFT同樣，加了什麼PDF驗證、類加強、支持移動設備……，都有啥用啊？！你內核沒有改變啊，大俠。。。一一大幫子人作了一全年就加了這麼一點東西，還好意思拿出來講啊？！

　　QC也莫過於此。

　　（四）關於「更名」的樂趣。

　　從頻繁更名就能夠知道HP的無能——沒有本事升級內核，只能改改花哨的界面，加一點噱頭，再換個名字，看看都有啥名字吧。

　　測試管理工具：TestDirectoràQuality CenteràALM

　　自動化測試：Astra QuickTestàQuickTest ProfessionalàUFT

　　HP確定會說：你不瞭解名字背後的意義，好吧，我替大家來講：TD升級爲QC的本意是從測試整合爲質量中心，把QTP捆綁進來，QC更名爲ALM就是但願它再也不只是針對測試或質量的管理平臺，而是一個完整的軟件生命週期管理平臺。

　　我想問一句：累不累啊？真覺得改了名字之後用戶就收穫了什麼好處嗎？我倒以爲反而增長了用戶的認知成本、使用成本，最終反而傷害了本身的品牌。

　　（五）沒落是一個不爭的事實。

　　好吧，廢話不說，下圖是咱們針對國內測試從業人員作的問卷調查。你能夠看到QC正在市場上節節敗退，按正常估計，明年必定跌破四成——極有可能被Atlassian Jira取代霸主地位。

　　看到了嗎？QC從昔日的一股獨大，變成了今天羣雄並爭。最明顯的就是Jira，從2009年的14%上升爲24%！！猛增10個百分點哦！這風頭在自動化那邊也是一樣，Selenium從2009年的4%上升爲12%。

　　爲何？不少緣由。且聽我細細道來。爲了更好的說明，我以和它體量至關的大型測試管理平臺好比Micro Focus SCTM(Silk Central Test Manager)、51Testing TestPlatform、IBM RQM來跟它作個簡單對比——爲何不拿Atlassian Jira對比？由於Jira如今雖然也在朝着「全生命週期管理」的方向靠，也有需求管理、錯誤跟蹤這些模塊，可是走的路數和QC不太同樣（設計思路不太同樣，Jira走的是敏捷&項目管理模式），並且對測試需求和測試用例沒有提供直接的方式進行管理（能夠和別的工具集成），很差對比。固然後面仍是會說起。

版權聲明：本文出自 songfun 的51Testing軟件測試博客：copy Bookmark http://www.51testing.com/?songfun

原創做品，轉載時請務必以超連接形式標明本文原始出處、做者信息和本聲明，不然將追究法律責任。

相關文章：

讓Quality Center走下神壇--測試管理工具大PK（中）

　一、莫名其妙的架構設計。

　　前面提到過TestDirector的架構設計，徹底走輕快的路子，B/S架構，基於Windows 2000平臺，安裝IIS4.0便可，數據庫能夠是Access/Sybase/SQL Server6.5,7.0,2000/Oracle7,8,9這些，內存只須要128M，CPU只要PentiumⅡ足矣。

　　可是到了QC的時候，莫名其妙的變成了Java EE架構，號稱能夠安裝在Windows、Linux、Solaris等系統上，Web服務器能夠是Apache、IIS，應用服務器能夠是JBOSS、WebLogic、WebSphere，一個比一個複雜，一個比一個強大，……，架構師對外宣稱QC能夠更好的支持企業級用戶，支持高併發……

　　到了QC 11.5(ALM 11.5)的時候，官方的建議配置變成了Windows 2008 sp2 64bit + JBOSS 5.1 + SQLServer 2008 sp1，最低配置也得是Windows 2003 sp2 + (IIS 6) + JBoss 5.1 + SQL Server 2005 sp3，而硬件方面的最低配置更讓人咂舌——最低內存8 GB！硬盤最少8GB！並且連客戶端的內存最低配置都必須是2GB！

　　各位都明白了嗎？這也是爲何愈來愈多的用戶拋棄了HP Quality Center的緣由，內存要求短短几年之間翻了62.5倍！！驚人吧！！！

　　看到這裏我狂汗啊！要知道，微軟Windows 2000這麼龐大的系統，不過動用了1700個開發，3200個測試，世界上有幾個微軟這種巨量級的軟件研發公司？難道他們的架構師沒有讀過《長尾理論》？事實上，大部分的公司測試開發比原本就很低，真正考慮到實時併發的話，能作到一兩百併發讀寫已經很好了，並且就像Infosys、Tata這樣的航空母艦級的外包服務公司，也沒有必要整個公司只用一個QC啊——再者說了，就算出於企業級管理的須要，這樣的公司能有幾家，爲這些大公司定製化一個不就好了嗎？真正要考慮的是廣大的受衆羣體所在的企業規模和研發團隊規模啊！兄弟，這只是一個內部研發管理系統！對內的系統決定了對性能的要求不可能像對外開放的大型系統那麼高，既不是12306，也不是天貓，更不是谷歌/百度首頁，設計這樣的架構，我想問一句：有那必要嗎？圖啥呢？

　　假如還以爲不夠的話，那麼咱們對比看看如今也很是流行的TestLink——一款能夠和Jira、Bugzill、Mantis集成的測試過程管理工具。它的架構很是的簡單：WAMP/LAMP，也就是Windows/Linux + Apache + PHP + MySQL。由於如今有大量的一鍵集成安裝包（如WAMP Server、XAMPP），因此安裝過程極其簡單方便。正是由於TestLink的便捷性，這幾年使用的用戶比例也在攀升，並且別忘了，它能夠集成不少主流的缺陷管理工具哦！

　　二、複雜繁瑣的安裝和登陸、驚人的資源消耗。

　　QC的服務器端姑且不提，看看其複雜而坑爹的客戶端——其實仍是架構設計的問題。

　　相信不少朋友都見過下圖的這個頁面吧？

　　假如你真的常用Quality Center的話，必定對這個頁面再熟悉不過，相信你們都有同感，這個頁面每每須要下載很是的久，運氣很差的話得下載5-10分鐘，並且還常常下載到最後了打不開！！這時還得檢查有沒有關閉UAC(User Account Control)、DEP(Data Extension Prevention)等等，這種BT的架構設計真的讓人難以想象了：這明明是B/S架構的系統，爲啥須要下載安裝這麼多ActiveX？這不是掛羊頭賣狗肉，打着B/S的旗幟，行C/S之事嗎？與其這麼麻煩，還不如你就作成C/S算了！

　　固然，它還真有客戶端，並且官方推薦你使用，叫：QC Explorer。說白了，就是專門爲打開QC開發的一款基於IE內核的瀏覽器。唉，真的無語了，放着那麼多流行的JavaScript. Framework Libraries不用，偏要用ActiveX這種落伍又笨拙的東西。這還沒關係，關鍵是這樣一來，對你的瀏覽器就會很是的挑剔！請看這段官方描述（針對QC客戶端的瀏覽器要求）：Microsoft Internet Explorer 7 or 8。就是說你的客戶端只能用微軟的IE瀏覽器，並且必須是IE 7或者IE 8這個版本，不能用微軟的IE 6或IE 9（必定要用高版本的IE還獲得jboss\server\default\deploy目錄下修改20qcbin.war裏的內容），不能用Chrome、Firefox，更別提什麼Opera、Safari之流了。還有更讓人崩潰的，就是除了瀏覽器以外，你的系統上還必需要安裝：Microsoft .NET Framework 3.5 (SP1)、Visual C++ 2005 SP1 ATL Security Update Redistributable、Microsoft Office 2007 (SP2)等一系列東西，你說有多煩有多煩！！！

　　相比之下，真的建議他們（HP QC的架構師）去學習一下Jira和Micro Focus SCTM，所有是用JavaScript類庫實現，真正意義上的純B/S架構，因此全部的瀏覽器均可以輕鬆訪問，無需額外安裝其餘ActiveX！

　　純B/S架構帶來的好處還有不少，包括友好的用戶體驗，以及無縫切入移動互聯網（手機訪問），這些後面會單獨列出來說起。

　這裏還沒說它的服務器端的安裝呢！假如你曾裝過Quality Center的服務器端，十有八九遇到過「數據庫鏈接屬性不正確」的問題，通常緣由是數據庫那邊還得再作正確的配置，具體得看是SQL Server仍是Oracle，各有各的招，這裏就很少說了。

　　總而言之一堆的問題要注意要設置好，還記得當年我寫的那篇《關於"The RPC server is unavailable"的探討及解決方案》嗎？這個也是其中之一。

　　再來講資源消耗。其實從上面的「最低配置要求8GB內存」你們就能夠大體看出QC有多吃內存了。這麼說吧，咱們51Testing的講師都最怕上QC這門課，不是由於這門課很難，而是很痛苦，每次從虛擬機裏啓動出來至少15分鐘，中間還有不少操做也很是的卡。PS：我用的筆記本是HP ProBook 4230s，CPU是i3-2310M 2.10GHz，內存8GB，也是如此。

　　三、過於簡化的需求管理模塊。

　　QC的需求管理嚴格意義上不屬於真正意義上「開發需求的管理」，而是指針對測試需求的管理，而且能夠結合Release模塊設定簡單的基線，不過若是你用過CaliberRM這種專業級的需求管理工具，就會發現QC的Requirements實在是弱爆了！

　　Micro Focus SCTM就不同了，它支持項目級的需求基線，並且能夠直接切進CaliberRM（這是亮點），這纔是真正意義的需求全生命週期管理。

　　固然假如你的SRS是word文檔，QC倒也能夠把開發需求導入進去，可是問題是QC的word插件很是很是難用，導入的工做量一點都不比你本身手工輸入來的快（由於須要針對每個需求項去打begin和end標記）！！因此一般咱們在企業實戰中只能採用折中的方式，先把SRS轉爲Excel文檔，再經過Excel Addin導入進去，固然導入的過程也不那麼輕鬆，具體能夠參考個人《ALM(Quality Center) Excel Addin深刻剖析》，連接是：

　　http：//wenku.baidu.com/view/04a20cee998fcc22bcd10d81.html

　　四、不三不四的test plan——關於「測試計劃」和「測試用例」的混淆。

　　從TD以來一直到後來的QC、ALM，Quality Center一直把test plan認爲是test cases——從這裏很容易看出來，設計這款工具的人是作開發出身的，不懂測試，呵呵。

　　測試計劃是什麼？首先測試過程會分爲計劃、設計、實現、執行幾個活動（按ISTQB的說法是測試過程分爲計劃和控制階段、分析和設計階段、實現和執行階段、評估出口準則和報告階段以及結束收尾階段），分別解決「作什麼」、「如何作」、「具體步驟是什麼」、「發現缺陷並跟蹤缺陷」、「評估測試報告」這幾個問題。

　　《測試計劃》，是有國際性的模板的，即IEEE 829。請各位參考維基百科：http：//zh.wikipedia.org/wiki/IEEE_829內容包括明確組織形式（強矩陣、平衡矩陣、弱矩陣），明確測試對象，明確測試的需求跟蹤和覆蓋，明確測試的「經過/失敗」標準，明確測試的掛起標準和恢復條件，明確工做的任務分配，明確項目可交付物。

　　然而，QC裏所謂的測試計劃（test plan）對於以上這些通通沒有涉及，實質上倒是編寫測試用例的模塊，你能夠看到用例的目錄規劃、用例的名稱、用例的步驟，還能夠看到用例的類型（是手工測試仍是自動化測試），……，總而言之，這就是Test Cases。

　　而它的Release模塊倒能夠理解爲粗略的測試計劃模塊，只是太粗糙了點兒。

　　真正作到了能夠沿着IEEE 829的樣板編寫測試計劃的工具目前尚未，不過IBM RQM算是比較接近的，它們可定義作到的是定義測試目標，定義過程，定義每次迭代的進度並對重要的milestone跟蹤，能夠估計工做量，能夠列出測試環境，定義開始和結束的標準，……，整體來講還算不錯。

　　還有就是咱們51Testing的TP(Test Platform)，也有獨立的測試計劃管理模塊，能夠創建多級測試計劃，也包含了任務分配、工做量估計、風險管理、測試環境管理和分配等，也能經過度量監控測試的執行進度，質量情況。

　　五、華而不實的Business Components。

　　QC中有個HP本身鼓吹的「業務驅動測試」的概念，叫：Business Components。核心理念是：BPT(Business Process Testing)，業務流程測試。

　　幹嗎用呢？簡單的說，就是讓SME（主題事件專家，也就是「業務專家」）能夠藉助自身對業務的熟悉經過對系統的熟練操做，讓這個Business Components把全部操做記錄下來，生成一個自動化腳本，而後經過QTP進行迴歸測試（只能經過QTP）。實際上若是你們對QTP的Keyword View比較熟悉的話，就能明白是怎麼回事了。HP認定作測試的人主要分爲兩類：一類熟悉測試技術（包括精通編程、數據庫，但對業務不甚精熟），一類則熟悉業務（但多是編程白癡），這兩類人都有測試的盲點，經過這個業務設計讓兩類大相徑庭的人得以協做。很美好吧？其實也有一點兒TDD的味道（沾邊）。

　　SCTM也有個相似的東西叫workbench，基於StoryBoard技術，也不須要編程（Visual Test）。

　　但事實上，不多有公司能夠作到清晰的劃分這些，每每作測試的必須懂業務，即便你是自動化測試工程師，也得了解業務。因此，……，就黃了，這個組件根本沒有辦法大面積推廣開，在內部被證實失敗以後，HP開始轉型作 Sprinter——這個東西后面會提，是個神器！不過國內尚未漢化，也幾乎沒人深刻研究，大部分testers還沒能體會到它的強大。

版權聲明：本文出自 songfun 的51Testing軟件測試博客：copy Bookmark http://www.51testing.com/?songfun

原創做品，轉載時請務必以超連接形式標明本文原始出處、做者信息和本聲明，不然將追究法律責任。

相關文章：

讓Quality Center走下神壇--測試管理工具大PK（上）

讓Quality Center走下神壇--測試管理工具大PK（下）

　六、測試設計分析的薄弱。

　　QC把本身的架構作的很複雜很「強大」，可遺憾的是，在測試的分析設計上卻很是的薄弱，能夠說幾乎沒有——很難想象一個被假設爲如此強大的公司竟然會沒有測試分析？這種感受就像給一個拖拉機安上了波音747的引擎。

　　關於測試分析：其實業內的大部分測試管理工具每每都是跳過度析這一環直接從測試需求跳到了測試用例設計，而實際上對測試需求分解出來的東西直接進行用例設計的話會形成分解粒度過於粗糙，致使大量測試分析細化的過程沒法以可視化的方式體現出來，從而形成漏測。假如你的系統比較複雜，這個過程應該是：從測試需求分解出測試項，測試項分解出測試子項，而後在測試子項中設計測試用例。

　　TP在這塊上作的很不錯，能夠進行繼承性分析、質量模型分析（ISO9126 Model六大特性27子特性）、功能交互分析、用戶場景分析等專業性的分析，經過這些系統性的分析咱們能夠獲得高質量的測試項。並且TP把咱們測試人員對分析思考的過程記錄和管理起來，這樣就實現了對分析過程的評審了。

　　全部作測試的人都知道V&V，即Test = Verification + Validation。「測試」本質上就是驗證和確認，驗證過程的正確性，確認結果的正確性。而TP真正意義上實現了既確認結果，又驗證過程。但很遺憾，QC不具有這個功能。

　　而測試設計這塊，也就是咱們一般提到的等價類劃分、邊界值分析、斷定表、因果圖、狀態遷移法、場景法（流程分析法）、正交實驗法、輸出域分析、錯誤猜想法等各類測試用例設計方法。它們一樣在QC中也沒法體現，這就意味着咱們沒有辦法評審咱們測試設計的過程！而漏了這個過程的評審，那麼漏測也是在所不免了！好比咱們只考慮了邊界值，忽略了兩兩組合的分析（經過斷定表或正交實驗），雖然針對需求的覆蓋能夠達到100%了，可是仍然忽略了一些狀況的考慮，那麼QC這時是根本「察覺」不出來的。

　　目前市面上的全部測試管理工具中，廣泛缺乏這塊的功能實現，究其緣由，我仍是認爲這些軟件的設計者不是一個經驗豐富的測試專家（應該只是作開發出身的），因此忽略了這些核心模塊的功能實現。

　　目前作到這一點的，只有51Testing的Test Platform這款工具——這裏我得自賣自詡一下，周峯（90年代就已經經過國家系統分析員認證），對測試的理解確實是高瞻遠矚，要比不少人都深刻、全面。而他全部的考慮都融入到了TP裏面，我也衷心但願同行能夠借鑑，把這些功能添加到各自的工具模塊中，畢竟百花齊放、百家爭鳴纔是最應該看到的景象。

　　七、忽略白盒測試，缺乏代碼覆蓋率分析。

　　全部熟知測試過程V模型的人都知道，測試活動分爲：單元測試、集成測試、系統測試，驗收測試，分別驗證軟件的內部質量、外部質量、使用質量。

　　然而QC彷佛並不關心這些。由於QC只實現了測試用例對需求的覆蓋關聯，卻沒有辦法進行代碼級別的覆蓋率分析。給人感受QC更多關注的實際上是黑盒層面的測試。

　　而SCTM則進行全面的關注，它也能夠關聯需求，還能夠收集Java/.Net的代碼覆蓋率，並且能夠提供比較報告，讓SQA隨時掌握代碼覆蓋率的趨勢變化，瞭解測試用例的充分程度。

　　這樣能夠更好的幫助項目成員一塊兒來使用這個測試管理平臺。

　　順便說一下，SCTM在單元測試這塊應該是全部測試管理工具中作的最好的，能夠支持Fitness、JUnit、NUnit、.Net Explorer、Process Executor、Windows Scripting等主流的單元測試/集成測試框架，而QC根本不支持，除非你作二次開發。差的遠了！

　　八、最關鍵的缺陷分析和Report功能。

　　常常有朋友問我QC導出報告的問題，好比怎麼把測試用例或缺陷以Excel的方式導出。其實QC的報告導出功能也很弱，特別是在Excel上，並且word的導出一直有Bug，基本上不可定製的，特別是你若是針對前面的Test Plan等模塊作過定製化或二次開發，在導出的時候會有各類問題。

　　後來QC整合了Dashboard（其實就是展示各類數據指標的儀表盤），可是這意味着你必須是Enterprise Edition（收費更高昂），並且即便整合了Dashboard，只是在展現上更華麗了，導出的問題仍是沒解決！而其實「測試報告」纔是關鍵，只要作過項目的兄弟都知道，甲方須要的是漂亮的word報告！

　　而SCTM的報告功能卻很是的豐富，它提供了一個專門的報告引擎BIRT，能夠定製各類報告，也能夠支持項目羣報告、Dashboard，並且最重要的是：它們都是免費的！

　　再說度量和缺陷分析，這更是QC的一大軟肋！嚴格意義上來講，QC的那些數據分析離真正的缺陷分析還很是的遠！能夠說幾乎就沒有。而51Testing TP在這塊上作的很是出衆，提供了專業的ODC分析、Gompertz分析、Rayleigh分析、四象限分析、DRE/DRM等工程分析方法，能夠對缺陷進行單、多維度分析、進行缺陷趨勢分析、對缺陷進行預測等，爲測試工做質量評估、測試退出判斷、遺留缺陷預測提供支撐。51Testing軟件測試網9oz;R+nG(t2w:V]5LL"m

　　一句話：QC弱爆了，TP「碉堡了」！！

　　九、敏捷哪兒去了？

　　敏捷時代，不能不提敏捷。

　　「個體與交互賽過過程與工具」——這是著名的《敏捷宣言》的第一條價值觀。不過，有意思的是，工具卻成了今天大多數敏捷團隊的重要組成部分。

　　作過敏捷的人應該據說過Rally，這家公司是作敏捷項目生命週期管理工具的。其實還有不少，好比VersionOne、Mingle、DotProject、Redmine等。。。

　　很遺憾，QC不提供這些工具的集成工具，也沒有技術支持！

　　這塊作的最好的應該是Micro Focus SCTM，它提供了配套的集成工具，並且還提供技術支持，由於Micro Focus和這些軟件廠商自己就是戰略伙伴。

　　固然，Atlassian Jira也是具備敏捷基因的工具，它有個GreenHopper插件，能夠經過快速建立User Story來創建一個產品Backlog，能夠在整個發佈過程當中管理Backlog、Sprint，而且監控項目的進度。此外，Jira還有一個名爲Bonfire的插件，作敏捷測試管理的，不過我尚未使用過，不敢作太多評論。

 

　十、移動端的訪問。

　　十年前，我就在想這件事情。做爲團隊的項目經理、測試經理，或公司的老闆，日理萬機，天天就爲了瞭解項目情況，得扛着筆記本電腦「飛來飛去」，看上去實在大煞風景。更況且，在講究「碎片化時間利用」的今天，咱們在公交上、地鐵裏，掏出手機訪問一下咱們的測試管理系統，瞭解下「張三用例寫到哪裏了，李四缺陷修復了沒有」豈不更加方便、高效？

　　要說敏捷，我以爲這也算一種「敏捷」。

　　QC有移動端APP嗎？或是能經過手機瀏覽器訪問嗎？道聽途說過，卻從不曾見。我的以爲很不靠譜，爲何？別忘了前面第2點提到的QC客戶端對Windows平臺和IE瀏覽器的依賴，假如咱們用的是iPhone、iPad，或者Android設備，那怎麼可能訪問呢？

　　相比之下，Jira和SCTM就具備這樣的先天優點了。爲何呢？別忘了它們都是用JavaScript類庫實現的，不須要安裝ActiveX，是真正的純B/S——天然能夠經過手機瀏覽器訪問了！

　　事實上，Jira確實有移動端的APP，我剛特意去App Store上搜索了一下，呵呵，見下：

　　並且，連Bugzilla也有移動端的APP了！

　　我的以爲，移動互聯網時代，這些測試管理工具也都將面臨着新一輪的洗牌，HTML5的支持、CSS3的支持、大量的JavaScript類庫……QC還能撐多久，咱們拭目以待！

　　十一、用戶體驗哪兒去了？

　　其實TD當初的用戶體驗還真的挺好的，可是QC的用戶體驗，唉，不提也罷。

　　龐大的身軀、臃腫的組件、極差的兼容性、緩慢的運行速度、滯後的設計理念、封閉性……其實前面都已經提到過了。

　　用戶體驗的精髓在於「Don’t make me think」，而QC倒是「make me think hard」。

　　十二、惟一的亮點：Sprinter，探索性測試（Exploratory Testing）和兼容性測試的頭號利器！

　　QC惟一的亮點應該就是從QC 11.0開始推出了Sprinter——一個半自動化測試的集成工具。

　　它既不是QTP，也不是Selenium，而是能夠把你手工測試的過程直接記錄下來，進行「自動化迴歸」，好比屏幕捕捉（截圖、截視頻）、屏幕記錄（截圖之後能夠在上面作標記）、自動數據注入（Data Injection），能夠在執行用例的同時直接生成缺陷報告，很是適合作探索式測試。還能夠作鏡像測試，也就是同時進行多環境的配置測試，是兼容性測試的利器！我親見過它的強大，確實「亮瞎了眼」！我推薦你們去體驗一把，這種針對手工測試的自動化一點都不須要你有編程基礎，用起來又快又方便，真的是「誰用誰知道」！

　　只是很惋惜，HP沒有足夠的重視Sprinter，沒有把這張王牌打好。由於準確的說，QC是用不了Sprinter的，ALM才能支持Sprinter，這意味這你必須先升級到它們的ALM(QC 11)。這成了它的第十二宗罪！

　　1三、離線模式和版本管理。

　　隨着GIT的興起，離線開發和離線Repository將成爲一種新興的需求和開發模式。

　　咱們51Testing出去和用戶推TP的時候，就遇到有用戶提出這樣的需求（而咱們的TP已經實現了離線模式）。但事實上，QC並無離線模式，必須始終保持QC Connection，並且消耗你的License！

　　除了51Testing的TP，Micro Focus SCTM也支持離線模式（經過MTC來支持），也能夠在你工做完成後提交測試結果。

　　好吧，即便咱們不談離線模式，就說版本管理，QC仍然在同類測試管理工具中處於下游。QC雖然提供了版本管理的功能，可是很是弱，易用性也極差。好比你編寫了測試用例，通過評審以後修改了用例，過幾天刪除了，過幾天又想恢復……那麼這些經過QC實現是幾乎不可能的。

　　在版本管理這塊，SCTM(Silk Central Test Manager)就不同了，它能夠支持測試用例的版本化，還能夠指定當前測試項目測試用例的活動版本！是否是很強大？！

　　1四、相形見絀的擴展性。

　　QC幾乎沒有任何擴展性！雖然它有一個Add-in Pages，可是基本都沒有和業界主流工具集成，上面能夠下載的都是諸如QTP Addin、Excel Addin這種東西，實在不值一提。

　　擴展性這塊，Jira很不錯，不過最強的仍是SCTM，還記得前面發過的文章嗎？——《你見過的這麼強大的開箱即用的測試管理工具嗎？》

　　好吧，這裏再次描述一次：SCTM號稱業界最開放的測試管理平臺，需求部分支持CaliberRM、DOORS、RequisitePro、Word，變動管理部分支持StarTeam、Subversion(SVN)、VSS、CVS、PVCS、VSTS，缺陷管理部分支持Atlassian Jira、Bugzilla、IBM ClearQuest、Microsoft VSTS、StarTeam，自動化測試這塊支持JUnit、NUnit、Fitness、TestPartner、SilkTest、SilkPerformer、VMWare Lab Manager……聽說如今還在增長擴展……不得不讚美一句，牛B！

　　OK，至此，《讓Quality Center走下神壇》已經所有打完收工！

版權聲明：本文出自 songfun 的51Testing軟件測試博客：copy Bookmark http://www.51testing.com/?songfun

原創做品，轉載時請務必以超連接形式標明本文原始出處、做者信息和本聲明，不然將追究法律責任。

相關文章：

讓Quality Center走下神壇--測試管理工具大PK（上）

讓Quality Center走下神壇--測試管理工具大PK（中）