軟件測試管理的基本要素
1. 符合軟件開(kāi)發(fā)計劃時(shí)間框架的軟件測試計劃
軟件測試計劃是一個(gè)老生常談的問(wèn)題了，不同的人對計劃的理解往往是大相徑庭的。這里讓我們回顧一下何為計劃，一般來(lái)說(shuō)計劃的目的是用來(lái)識別任務(wù)，分析風(fēng)險，規劃資源和確定進(jìn)度。從計劃的定義上來(lái)看，計劃并不是一張時(shí)間進(jìn)度表，而是一個(gè)動(dòng)態(tài)的過(guò)程，最終以系列文檔的形式確定下來(lái)。擬定軟件測試計劃需要測試項目管理人員的積極參與，這是因為主項目計劃已經(jīng)確定了整體項目的一個(gè)時(shí)間框架，軟件測試作為階段工作必須服從時(shí)間和資源上的約定。
2. 一個(gè)完整的測試計劃應該包含以下幾個(gè)方面：
(1) 對測試范圍的界定，簡(jiǎn)單的說(shuō)就是測試活動(dòng)需要覆蓋的范圍。在有時(shí)間約束，工作產(chǎn)品質(zhì)量約束的情況下，唯一能夠調整就是范圍。在實(shí)際的工作中，我們總是不自覺(jué)的在調整軟件測試的范圍，比如在時(shí)間緊張的情況下，通常優(yōu)先完成重要功能的測試。這就是一種測試范圍上調整。所以作為測試管理者在接收到一項任務(wù)的時(shí)候，需要根據主項目計劃的時(shí)間來(lái)確定測試范圍。如果在確定范圍上出現偏差，會(huì )給測試執行工作帶來(lái)消極的影響，例如加班。確定范圍前需要管理人員來(lái)進(jìn)行任務(wù)的劃分，簡(jiǎn)單的說(shuō)就是分解測試任務(wù)。分解任務(wù)有兩個(gè)方面的目的，一個(gè)是識別子任務(wù)，二是方便估算資源的需求。完成了上述的任務(wù)之后，管理者便需要根據項目的歷史數據估算出完成這些子任務(wù)一共需要消耗的時(shí)間和資源。通常意義上說(shuō)，執行一次完整的全面測試幾乎是不可能的事情，我們總是要在測試的范圍上面做出有策略的妥協(xié)。
(2) 風(fēng)險的確定，項目中總是有不確定的因素。這些因素一旦發(fā)生之后記錄對項目的順利執行產(chǎn)生相當大的消極影響。所以在項目中，首先需要識別出存在的風(fēng)險。風(fēng)險識別的原則可以有很多，常見(jiàn)的一種就是如果一件事情發(fā)生后，會(huì )對項目的進(jìn)度產(chǎn)生較大影響，那么就可以把該事件做為一個(gè)風(fēng)險。風(fēng)險識別出之后，管理者需要按照這些風(fēng)險制定出規避風(fēng)險的方法。在小的項目中，識別風(fēng)險和制定規避方法可以省略。
(3) 資源的規劃，確定完成任務(wù)需要消耗的人力資源，物資資源。這些是保證項目執行的物資要素。物資資源是管理者容易忽略的問(wèn)題，實(shí)際上物資資源是人得以開(kāi)展工作的工具，細致的規劃可以讓人更有效的去執行項目。常見(jiàn)的物資資源有計算機硬件，軟件，測試環(huán)境的搭建等等。
(4) 時(shí)間表的制定，在識別出子任務(wù)和資源之后，我們便可以將任務(wù)，資源和時(shí)間關(guān)聯(lián)起來(lái)形成時(shí)間進(jìn)度表。本質(zhì)上說(shuō)，時(shí)間表是對前3項任務(wù)的一個(gè)概括。沒(méi)有前三步的工作，時(shí)間進(jìn)度表是沒(méi)有意義的。
3. 溝通
溝通的測試管理人員的必須的技能。雖然我們制定出詳細的項目計劃，當這不意味著(zhù)有了這個(gè)契約之后，項目中的各種角色就不需要溝通了。做為測試的管理者，需要將測試發(fā)現的問(wèn)題及時(shí)的反饋給開(kāi)發(fā)人員，同時(shí)也要積極的去了解外界產(chǎn)生的變更。項目中存在變化是普遍現象，而作為管理者就是要去管理這里變化，及時(shí)的修訂計劃。嚴格的說(shuō)，如果沒(méi)有這些變化，做為測試管理者的你就沒(méi)有多少存在的價(jià)值。有些人認為一旦有了計劃這個(gè)契約之后，只要按照要求去執行就可以，但是項目本身是一個(gè)動(dòng)態(tài)的過(guò)程，計劃是項目在某一個(gè)時(shí)刻、段的靜態(tài)體現，所以要按照發(fā)展的眼光來(lái)對待計劃。溝通是了解外界變化的積極手段，所以就測試管理者而言。其計劃溝通能力的要求要高于測試技能的要求。
4. 執行
去年國內流行一本書(shū)，名稱(chēng)為執行力。書(shū)中的作者認為大多數項目沒(méi)有成功的原因在于執行。軟件測試也存在一個(gè)執行的能力問(wèn)題，有人會(huì )說(shuō)我把要求的事情按照要求做完了不就可以了嗎? 的確，按照期望去執行任務(wù)是正解，但是這里有一個(gè)問(wèn)題就是如何保證執行者對期望的理解同要求者的期望是完全一致的呢?所以執行的背后還是一個(gè)溝通的問(wèn)題，這里的溝通是測試管理者和執行者之間的溝通。所以作為一名測試管理人員一定要在測試工程師開(kāi)始工作之前明確任務(wù)的意圖，前提和結果。
5. 版本控制
前面說(shuō)道的幾點(diǎn)都是過(guò)程，個(gè)人技能方面的要求。這里我們要討論的是純粹的工程活動(dòng)——版本控制。對于版本控制這個(gè)概念大家都不陌生，它是軟件配置管理的初期表現形式，來(lái)于于測試對穩定環(huán)境的要求。測試版本控制簡(jiǎn)單的說(shuō)就是測試版本有明確的標識，說(shuō)明。并且測試版本的交付是在項目管理人員的控制之下的。
測試版本的標識用來(lái)識別所用的版本。版本號碼的用處很多，例如在填寫(xiě)錯誤報告的時(shí)候往往需要提供發(fā)現錯誤的那個(gè)版本。在做缺陷分析時(shí)，我們可以利用版本號來(lái)區別缺陷和判斷缺陷的發(fā)展趨勢。
測試版本的說(shuō)明，它是開(kāi)發(fā)人員和測試人員之間交流的有效形式。測試人員可以通過(guò)這份文檔了解到當前的測試版本中就上一版本而言有那些顯著(zhù)的變化，明確了這些之后，測試人員可以更加高效，有針對性的執行測試。
測試版本交付，測試版本的控制必須納于測試管理人員的控制之下。常見(jiàn)的形式就是測試管理者控制測試版本的更新和發(fā)布。開(kāi)發(fā)人員在看到錯誤報告之后，總是傾向于馬上修正這些錯誤并且發(fā)布給測試工程師做驗證。
考慮到大多數的開(kāi)發(fā)人員是典型的完美主義者，這樣的做法無(wú)可厚非，但是過(guò)于頻繁的版本更新會(huì )較低測試的效率。試想，如果你是一名測試工程師，當測試用例剛剛執行到一半的時(shí)候突然發(fā)布出一個(gè)新的測試版本，在這樣的情況下，已經(jīng)執行完畢的測試用例是否還需要再次執行一遍呢? 為了規避修改代碼帶來(lái)的副作用，我們有必要執行回歸測試。質(zhì)量是有保證了，但是效率較低了。測試在進(jìn)度上被迫延遲了。所以測試版本的控制有助于保證進(jìn)度和測試的效率。
以上是測試管理中需要注意的幾個(gè)要點(diǎn)，構成一個(gè)成功的軟件測試項目還有其他很多重要的因素，例如測試人員的個(gè)人能力，管理者的綜合素質(zhì)，公司的開(kāi)發(fā)過(guò)程等等，在這里筆者就不一一贅述了。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
