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