讓Quality Center走下神壇--測試管理工具大PK（下）
6、測試設計分析的薄弱。
QC把自己的架構做的很復雜很“強大”，可遺憾的是，在測試的分析設計上卻非常的薄弱，可以說幾乎沒有——很難想象一個被假設為如此強大的公司居然會沒有測試分析？這種感覺就像給一個拖拉機安上了波音747的引擎。
關于測試分析：其實業內的大部分測試管理工具往往都是跳過分析這一環直接從測試需求跳到了測試用例設計，而實際上對測試需求分解出來的東西直接進行用例設計的話會造成分解粒度過于粗糙，導致大量測試分析細化的過程無法以可視化的方式體現出來，從而造成漏測。假如你的系統比較復雜，這個過程應該是：從測試需求分解出測試項，測試項分解出測試子項，然后在測試子項中設計測試用例。
TP在這塊上做的很不錯，可以進行繼承性分析、質量模型分析（ISO9126 Model六大特性27子特性）、功能交互分析、用戶場景分析等專業性的分析，通過這些系統性的分析我們可以得到高質量的測試項。而且TP把我們測試人員對分析思考的過程記錄和管理起來，這樣就實現了對分析過程的評審了。
所有做測試的人都知道V&V，即Test = Verification + Validation。“測試”本質上就是驗證和確認，驗證過程的正確性，確認結果的正確性。而TP真正意義上實現了既確認結果，又驗證過程。但很遺憾，QC不具備這個功能。
而測試設計這塊，也就是我們通常提到的等價類劃分、邊界值分析、判定表、因果圖、狀態遷移法、場景法（流程分析法）、正交實驗法、輸出域分析、錯誤猜測法等各種測試用例設計方法。它們同樣在QC中也無法體現，這就意味著我們沒有辦法評審我們測試設計的過程！而漏了這個過程的評審，那么漏測也是在所難免了！比如我們只考慮了邊界值，忽略了兩兩組合的分析（通過判定表或正交實驗），雖然針對需求的覆蓋可以達到100%了，但是仍然忽略了一些情況的考慮，那么QC這時是根本“察覺”不出來的。
目前市面上的所有測試管理工具中，普遍缺少這塊的功能實現，究其原因，我還是認為這些軟件的設計者不是一個經驗豐富的測試專家（應該只是做開發出身的），所以忽略了這些核心模塊的功能實現。
目前做到這一點的，只有51Testing的Test Platform這款工具——這里我得自賣自夸一下，周峰（90年代就已經通過國家系統分析員認證），對測試的理解確實是高瞻遠矚，要比很多人都深入、全面。而他所有的考慮都融入到了TP里面，我也衷心希望同行可以借鑒，把這些功能添加到各自的工具模塊中，畢竟百花齊放、百家爭鳴才是最應該看到的景象。
7、忽略白盒測試，缺少代碼覆蓋率分析。
所有熟知測試過程V模型的人都知道，測試活動分為：單元測試、集成測試、系統測試，驗收測試，分別驗證軟件的內部質量、外部質量、使用質量。
然而QC似乎并不關心這些。因為QC只實現了測試用例對需求的覆蓋關聯，卻沒有辦法進行代碼級別的覆蓋率分析。給人感覺QC更多關注的其實是黑盒層面的測試。
而SCTM則進行全面的關注，它也可以關聯需求，還可以收集Java/.Net的代碼覆蓋率，而且可以提供比較報告，讓SQA隨時掌握代碼覆蓋率的趨勢變化，了解測試用例的充分程度。
這樣可以更好的幫助項目成員一起來使用這個測試管理平臺。
順便說一下，SCTM在單元測試這塊應該是所有測試管理工具中做的最好的，可以支持Fitness、JUnit、NUnit、.Net Explorer、Process Executor、Windows Scripting等主流的單元測試/集成測試框架，而QC根本不支持，除非你做二次開發。差的遠了！
8、最關鍵的缺陷分析和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軟件測試網9o z;R+nG(t2w:V]5LL"m
一句話：QC弱爆了，TP“碉堡了”！！
9、敏捷哪兒去了？
敏捷時代，不能不提敏捷。
“個體與交互勝過過程與工具”——這是著名的《敏捷宣言》的第一條價值觀。不過，有意思的是，工具卻成了今天大多數敏捷團隊的重要組成部分。
做過敏捷的人應該聽說過Rally，這家公司是做敏捷項目生命周期管理工具的。其實還有很多，比如VersionOne、Mingle、DotProject、Redmine等。。。
很遺憾，QC不提供這些工具的集成工具，也沒有技術支持！
這塊做的最好的應該是Micro Focus SCTM，它提供了配套的集成工具，而且還提供技術支持，因為Micro Focus和這些軟件廠商本身就是戰略伙伴。
當然，Atlassian Jira也是具有敏捷基因的工具，它有個GreenHopper插件，可以通過快速創建User Story來建立一個產品Backlog，可以在整個發布過程中管理Backlog、Sprint，并且監控項目的進度。此外，Jira還有一個名為Bonfire的插件，做敏捷測試管理的，不過我還沒有使用過，不敢做太多評論。
10、移動端的訪問。
十年前，我就在想這件事情。作為團隊的項目經理、測試經理，或公司的老板，日理萬機，每天就為了了解項目狀況，得扛著筆記本電腦“飛來飛去”，看上去實在大煞風景。更何況，在講究“碎片化時間利用”的今天，我們在公交上、地鐵里，掏出手機訪問一下我們的測試管理系統，了解下“張三用例寫到哪里了，李四缺陷修復了沒有”豈不更加方便、高效？
要說敏捷，我覺得這也算一種“敏捷”。
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還能撐多久，我們拭目以待！
11、用戶體驗哪兒去了？
其實TD當初的用戶體驗還真的挺好的，但是QC的用戶體驗，唉，不提也罷。
龐大的身軀、臃腫的組件、極差的兼容性、緩慢的運行速度、滯后的設計理念、封閉性……其實前面都已經提到過了。
用戶體驗的精髓在于“Don’t make me think”，而QC卻是“make me think hard”。
12、唯一的亮點：Sprinter，探索性測試（Exploratory Testing）和兼容性測試的頭號利器！
QC唯一的亮點應該就是從QC 11.0開始推出了Sprinter——一個半自動化測試的集成工具。
它既不是QTP，也不是Selenium，而是可以把你手工測試的過程直接記錄下來，進行“自動化回歸”，比如屏幕捕捉（截圖、截視頻）、屏幕記錄（截圖以后可以在上面做標記）、自動數據注入（Data Injection），可以在執行用例的同時直接生成缺陷報告，非常適合做探索式測試。還可以做鏡像測試，也就是同時進行多環境的配置測試，是兼容性測試的利器！我親見過它的強大，確實“亮瞎了眼”！我推薦大家去體驗一把，這種針對手工測試的自動化一點都不需要你有編程基礎，用起來又快又方便，真的是“誰用誰知道”！
只是很可惜，HP沒有足夠的重視Sprinter，沒有把這張王牌打好。因為準確的說，QC是用不了Sprinter的，ALM才能支持Sprinter，這意味這你必須先升級到它們的ALM(QC 11)。這成了它的第十二宗罪！
13、離線模式和版本管理。
隨著GIT的興起，離線開發和離線Repository將成為一種新興的需求和開發模式。
我們51Testing出去和用戶推TP的時候，就遇到有用戶提出這樣的需求（而我們的TP已經實現了離線模式）。但事實上，QC并沒有離線模式，必須始終保持QC Connection，而且消耗你的License！
除了51Testing的TP，Micro Focus SCTM也支持離線模式（通過MTC來支持），也可以在你工作完成后提交測試結果。
好吧，即使我們不談離線模式，就說版本管理，QC仍然在同類測試管理工具中處于下游。QC雖然提供了版本管理的功能，但是非常弱，易用性也極差。比如你編寫了測試用例，經過評審之后修改了用例，過幾天刪除了，過幾天又想恢復……那么這些通過QC實現是幾乎不可能的。
在版本管理這塊，SCTM(Silk Central Test Manager)就不一樣了，它可以支持測試用例的版本化，還可以指定當前測試項目測試用例的活動版本！是不是很強大？！
14、相形見絀的擴展性。
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（中）