項目中測試工具的應用(2)

　　除了基本的功能之外，以下的功能需求也可以作為選擇測試工具的參考：

　　1) 報表功能;測試工具生成的結果最終要由人進行解釋，而且，查看最終報告的人員不一定對測試很熟悉，因此，測試工具能否生成結果報表，能夠以什么形勢提供報表是需要考慮的因素。

　　2) 測試工具的集成能力;測試工具的引入是一個長期的過程，應該是伴隨著測試過程改進而進行的一個持續的過程。因此，測試工具的集成能力也是必須考慮的因素，這里的集成包括兩個方面的意思，首先，測試工具能否和開發工具進行良好的集成;其次，測試工具能夠和其他測試工具進行良好的集成。

　　3) 操作系統和開發工具的兼容性;測試工具可否跨平臺，是否適用于公司目前使用的開發工具，這些問題也是在選擇一個測試工具時必須考慮的問題。

　　ii. 價格

　　除了功能之外，價格就應該是最重要的因素了。說句題外話，在論壇上經?？吹接腥苏凑醋韵驳恼f我已經破解了XX測試工具這樣的話，對這種態度我十分不贊成。如果作為軟件從業者的我們都不能尊重別人的勞動，那有怎么能夠指望我們的客戶尊重我們的勞動呢?況且，測試工具的價格并不是真的昂貴到不能承受的程度，例如Numega的DevPartner一個固定license是兩萬多元人民幣，對一個中型的公司來說完全可以承受。

　　iii. 測試工具引入的目的是測試自動化，引入工具需要考慮工具引入的連續性和一致性

　　測試工具是測試自動化的一個重要步驟之一，在引入/選擇測試工具時，必須考慮測試工具引入的連續性。也就是說，對測試工具的選擇必須有一個全盤的考慮，分階段、逐步的引入測試工具。

　　3、 測試工具在測試過程中的應用

　　前面已經對測試工具的分類、測試工具的選擇進行了一些描述，這里，我還想就測試工具在測試過程中的應用說一點自己的看法。

　　對測試工具能夠發揮的作用大家都已經了解并認可了，但是很多引入測試軟件的公司并沒有能夠讓測試軟件發揮應有的作用，其主要原因我總結為三個方面：

　　a) 沒有考慮到公司的實際情況，盲目引入測試工具

　　首先我們要明確一點，并不是每種測試工具都適合公司目前的實際情況。我見過一些公司懷著美好的愿望花了不小的代價引入測試工具，半年一年以后，測試工具卻成了擺設，成了引入者心頭的痛。究其原因，就是沒有能夠考慮公司的現實情況，不切實際地期望測試工具能夠改變公司的現狀，從而導致了失敗。

　　例如，如果一個公司所開發的軟件屬于工程性質的軟件，在整個開發過程中需求和用戶界面變動較大，這種情況下就不適合引入黑盒測試軟件，因為黑盒測試軟件的基本原理是錄制/回放，對于不停變化的需求和界面，可能修改和錄制腳本的工作量還大過測試實施，運用測試工具不但不能減輕工作量，反而加重了測試人員的負擔。

　　我公司引入測試工具時比較成功的(至少從目前來看)，針對我公司的應用項目都存在需求、界面變動比較頻繁的情況，我們暫時沒有引入黑盒測試工具，主要依靠白盒測試工具提升代碼質量。目前我們引入的測試工具包括Compuware的DevPartner和Telelogic的Logiscope，這兩個工具在測試階段和維護階段發揮了應有的作用。

　　b) 沒有形成一個良好的使用測試工具的環境

　　換句話說，就是沒有能夠形成一種機制讓測試工具真正能夠發揮作用。例如，白盒測試工具的一般使用場合是在單元測試階段，而單元測試是由開發人員完成，如果沒有流程來規范開發人員的行為，在項目進度壓力比較大的情況下，開發人員很可能就會有意識地不使用測試工具，來逃避問題。在這種情況下，就必須形成一種有約束力的機制來強制對測試工具的使用。

　　將測試工具的使用明確定義進公司的開發流程，我認為是一種比較好的方式。我們目前的做法是在開發流程中明確說明，在項目里程碑提交的文檔中必須包括測試工具生成的報告，該報告中的數據是決定項目是否合格的依據。根據我公司的實際情況，在提交集成測試時需要提交DevPartner工具生成的測試覆蓋率報告、Logiscope生成的代碼質量報告，并且要求單元測試的代碼覆蓋率必須達到80%以上，代碼質量評價必須在Fair以上。

　　c) 沒有進行有效的測試工具的培訓

　　測試工具的使用者必須對測試工具非常了解，在這方面，有效的培訓是必不可少的。測試工具的培訓是一個長期的過程，不是通過一兩次講課的形式就能達到良好的效果。而且，在實際的使用測試工具的過程中，測試工具的使用者可能還存在著這樣那樣的問題，這也需要有專人負責解決，否則的話，對于測試工具使用者的積極性是很大的打擊。

原文轉自：http://www.uml.org.cn/Test/200807232.asp