軟件測試的存在的難處[2] 軟件測試
體現測試的價值有很多的難點，下面我逐一說明：
1.測試的成果多是無形資產，很難衡量。產品質量和企業形象這類資產可以說是測試能產生的最直接結果，但是這種資產，將會很難度量。測試能產生的第二類成果是提高開發的能力，也同樣屬于難以衡量的結果。
2.被識別的測試成果很容易被忽略是測試的價值。一提到優秀的軟件，很多人首先想到的就是高超的程序設計，嫻熟的編程技巧，成熟的軟件過程，很少人想到是經過了嚴格而全面的測試。測試總是生存在這個被遺忘的角落。
3. 過多的體現測試的價值會造成開發和測試的對立。測試能產生的最直觀的結果就是缺陷，而缺陷恰恰是證明了開發的不足(雖然說是對事不對人，但是誰有能看到自己寫的程序被人吹毛求疵，還拿結果來作為其工作成果而保證不大動肝火呢?)過多的強調測試價值，會讓敵對的情緒滋生，所以明智的產品經理，往往會弱化測試的功效，而趨向于建立起一種平衡。所以，現階段測試價值的體現，往往決定于領導者對測試的態度，測試的價值也只有在他的心中能有所體現。這種不能得到大多數人廣泛認同的局面，明顯是不利于建立測試的權威性和其它人員對測試活動的支持的。找到恰當的體現測試價值的方法，是困擾測試經理和對測試有良好認識的產品經理的一個大問題。
4.有關測試模式的思考對測試模式的想法完全起源于設計模式。既然能夠把復雜的體系結構設計能抽象，總結成這么一套東西，為什么不能對測試活動也如是觀之呢?
現在我對模式的理解還不是很深，也沒有很多的測試經驗，所以到現在為止，只能抽象成一種模式，我將其命名為包含模式(include)模塊A中引用模塊B作為A的子功能，這時的測試方法應該是先測試B模塊，然后再將B模塊中的任何一個路徑作為A的一部分來測試A模塊，這時B模塊中的任何一條路徑，已經被同化成等價類(雖然在B模塊的測試中，它們可能不屬于同一個等價類)
(這只是一種思維構想，希望能夠拋磚引玉，能將這個體系完善起來)
5.測試與開發的關系測試到底和開發處在怎么樣的一個關系下才能夠較好的產生測試應該達到的效果呢?
測試部門獨立于開發部門。這種模式可能源于傳統制造行業的QC和生產部門的分開。其目的是為了保證測試過程和測試結果的客觀性和有效性。這種模式相當于把測試和開發分成兩個涇渭分明的活動，并沒有過多的考慮兩種活動之間的互為補益。在這種模式下，很可能演變成測試和開發之間的對立，或者增加測試和開發之間的溝通成本。邊測試，邊開發。這是XP的輕量級開發過程所倡導的，現在的測試驅動開發理論就是符合了這種模式。采用先設計測試，再進行開發，當開發的軟件通過了所有的測試，軟件就完成了。這種方式其實并沒有規避自己測試自己代碼所產生的局限性問題，只是將思維的順序作了些改變，降低了思維定式對軟件開發產生缺陷的影響。
測試部門屬于研發中心，但獨立于項目組。這種模式保證了測試與項目組之間的最終目標的一致性(高質量的軟件產品)，能有效的降低溝通成本，又能保證測試人員有一定的獨立性，不會過分的受產品經理的控制，避免測試失效現象產生。但在這種情況下，相比兩個部門獨立，測試的結果有可能不會被項目組所重視，需要頻繁的進行協調，才能及時處理缺陷。
文章來源于領測軟件測試網 http://www.kjueaiud.com/