QC是很出名的強大的管理工具，很多測試愛好者都追逐著它，學習怎么使用它，今天我寫這篇文章不是講解如何使用，而是通過分析這個管理軟件來看看測試管理的思想，其實工具不僅給我們帶來了效率和便捷，更多的是給我們流程上的指導，如果你深刻理解你會發下QC就給了我們一個很好的測試管理指導。好了，廢話不多說，我們就來看看它吧！
首先我們來看下QC的整體管理流程圖，如下圖：
看似簡單的圖，其實蘊藏著很多內容。QC從前期的需求管理到測試點的提取，再到測試用例的形成，測試的執行，以及缺陷的跟蹤管理全部包括了。也許這時候你會問，這有什么新鮮的現在好多管理工具都是這個流程，包括我們現在的流程也是如此，有什么炫耀的？
ok，那咱們就來點真格的。如果你熟悉QC，你會發現QC中的需求是能和測試用例以及相應的Bug關聯的（這就是QC中需求轉化為測試的功能），就這點來說非常實用。為什么這么說呢？大家知道我們基本面對的都是web產品，他的特點就是變化快，更新換代更快，也許這個版本就和上個版本有天壤之別。這是web產品的特點我們無法改變，但我們可以改變自己來適應他。 說白了，就是按照QC的思想，我們來建立需求與測試用例以及Bug之間的關聯。這樣做的好處就是當需求發生變更時，能找到變更的需求涉及到的用例以及Bug。如果你買不起昂貴的QC我們可以這樣來做（個人觀點，如有雷同，純屬巧合）：
1、需求格式規范化，在需求中給出功能模塊劃分圖，以及各個功能的優先級。這樣做的好處是輪到tester分工時可以根據需求中的功能模塊圖來劃分，這樣的話就能避免重復或遺漏功能，同時根據產品人員提供的優先級我們可以直接拿到用例中來，這樣的話需求和用例間就建立了關聯，當然這個關聯關系很弱，還有待改進。
2、測試用例的規范，測試用例的原子化。其實這里仍然是QC中的體現，在上一條中我們提到了功能模塊劃分，那么在測試用例中就根據功能模塊的再次細分，分解到原子狀態。為什么這么做呢？其實功能模塊的劃分相當于QC中的測試點，而我們繼續劃分則分解成了詳細的用例，那么到這一步，我們就建立了需求—>測試點—>測試用例之間的關聯了。
3、接下來這是怎么把用例與Bug關聯起來？可以使用TestLink來管理用例，
TestLink是一個開源的測試管理工具能夠和JIRA等缺陷管理工具集成，這樣就建立了用例與Bug之間的關聯。說實話，TestLink是個不錯的測試管理工具，尤其是對于無法購買昂貴的商業工具的工具來說，但TestLink的易用性我實在不敢恭維啊，用起來超級無敵不順手，但時間長了也就習慣了。
ok，到這里我們仿照QC的思想建立了一個基礎的管理流程，但這里流程還需要加強，如何提高他們之間的關聯度還是個問題，尤其是當需求發生變化時，如何能在最短時間內找到涉及的用例以及Bug。
下面我們繼續關注QC用例方面的思想。我們知道QC能夠很好的和LoadRunner、QTP等HP的測試工具結合，在QC中去調用和管理這些工具，那么這里就設計到一個用例格式以及用例重用的問題。對于測試來說用例是至關重要的，所以用例的規范也是很有必要的。那么這里我就UI Check List、功能測試用例和性能測試用例來說下。
我個人一直認為，對于UI方面以及經常要測試重用性非常高的模塊，我們可以設計成一個Check List，這樣的話看起來方便，執行起來快捷，維護成本也低，拿來就能用，是個很好的方法。
對于功能測試用例以及性能測試用例，我個人比較喜歡把功能測試用例的格式進行擴充轉化為性能測試用例，這樣他們之間的格式和關聯性方面就不會有太大的差異了。下面的圖是我設計的一個性能測試用例，其實它也是源于LoadRunner這個工具的思想演變而來的。
仔細觀察你會發現，這個用例就是功能測試用例的演變，而且非常符合LoadRunner的測試流程，從用例的信息到腳本設計到場景設計再到執行結果能很好的體現出來。而且就測試結果也能簡單明了的反應出來，個人感覺看上去很舒服，O（∩_∩）O~
哦了，寫的也不少了，最后我們以QC的自定義功能來結束這篇文章。QC比其他測試工具更受測試人員喜歡的原因之一就是因為他有強大的自定義功能，能對字段、流程等進行自定義，編寫代碼來完成你想要的各種流程功能。這也就反映了一個道理，任何管理流程都是靈活的，最好的管理流程并不一定適合你，俗話說的好，適合自己的才是最好的。所以，當我們有了一個基本比較完善的測試管理流程后應該慢慢的把他個性化、人性化，而不是一成不變的去死守，加入新鮮元素，加入新的管理理念，給更多人的展示空間才能不斷的去促進流程的改進與提高。