相對軟件開發理論的成熟度來講，測試理論還非常的稚嫩。（當然，和工業開發理論比較，軟件開發理論也是非常的稚嫩。）測試行業的興起，將會有很大一部分取決于測試理論的成熟度。
現在的測試（技術和管理）還有一些問題是沒有定論的，也是我在一直思考的問題（也許這些問題已經有人解決，小生孤僻寡聞而已），下面將這些問題作一個總結，以期望能在以后找到解答。
1. 測試的終點在哪里？
作為一個工程過程，無法清晰的定義活動的結束準則，就像在大海中航行的船只，沒有自己的目的地，是一件很可怕的事情。測試就是這么一條沒有目標的船。
最合適的測試結束的準則應該是缺陷數控制在一個可以接受的范圍內。但是在實際的過程中，是永遠無法知道未發現的缺陷的數量的，雖然會有方法可以估計出未知缺陷的數目，可是其準確性和所付出的成本使其的可行性并不高。所以雖然這個準則最合適，但是并不實用。
另外一個測試結束準則是以過程為衡量標準。按照測試過程走完了相應的步驟，完成了該作的工作，就算測試完成。這種測試結束準則和沒有準則沒有什么兩樣，根本沒有達到驗收的目的。換句話說，該結束準則有一個假設，這個假設就是已定義的測試過程是完全有效的，在這種情況下，才能采用這個準則來結束掉測試活動。所以這個準則雖然不是很準確，卻是最常見的測試結束的準則。
還有一個也是很常見的準則，就是時間線結束準則。到了 dead line 了，不管怎么樣，就算結束。這種準則也會經常在一些不規范的公司遇到。個人認為這種準則對測試的危害最大，遇到組織里是以這個準則來結束測試的話，測試質量只能靠上帝來保佑了。
綜上所述，如果能夠定義出一個既能作為客觀的評價標準，又比較容易實施的測試結束準則的話，是將會對測試理論的成熟有深遠的影響。
2. 如何評價測試員的優劣
作為測試活動的行為主體，測試員的優劣直接影響測試活動的優劣�？墒侨绾尾拍茉u價測試員的優劣呢？
不能以發現缺陷的數量去衡量測試員的水平，這樣做只能將測試引到以發現表面的缺陷為主的活動。
不能編寫的文檔的數量時間比去衡量測試員的水平。
不能以被接受的缺陷數去衡量測試員的水平
優秀的測試員能見微知著；
優秀的測試員有獨特的思維方法，能不斷創新測試方法；
優秀的測試員能清晰的將缺陷描述清楚，并能說服開發人員改正；
優秀的測試員能從用最小的信息獲得對系統的最大理解；
優秀的測試員需要思維靈活，知識全面。
這些都是定性的分析，有很大的主觀因素在里面，如果能有一種方法，能將這些與結果掛鉤，進行量化，將會對測試方面的人力資源管理有很大的幫助。
3. 如何體現測試的價值
測試作為開發的一個服務部門，能不能很好的體現自己的價值，這將是以后測試能不能良性的發展的一個重要因素。
體現測試的價值有很多的難點，下面我逐一說明：
1. 測試的成果多是無形資產，很難衡量。產品質量和企業形象這類資產可以說是測試能產生的最直接結果，但是這種資產，將會很難度量。測試能產生的第二類成果是提高開發的能力，也同樣屬于難以衡量的結果。
2. 被識別的測試成果很容易被忽略是測試的價值。一提到優秀的軟件，很多人首先想到的就是高超的程序設計，嫻熟的編程技巧，成熟的軟件過程，很少人想到是經過了嚴格而全面的測試。測試總是生存在這個被遺忘的角落。
3. 過多的體現測試的價值會造成開發和測試的對立。測試能產生的最直觀的結果就是缺陷，而缺陷恰恰是證明了開發的不足（雖然說是對事不對人，但是誰有能看到自己寫的程序被人吹毛求疵，還拿結果來作為其工作成果而保證不大動肝火呢？）過多的強調測試價值，會讓敵對的情緒滋生，所以明智的產品經理，往往會弱化測試的功效，而趨向于建立起一種平衡。
所以，現階段測試價值的體現，往往決定于領導者對測試的態度，測試的價值也只有在他的心中能有所體現。這種不能得到大多數人廣泛認同的局面，明顯是不利于建立測試的權威性和其它人員對測試活動的支持的。找到恰當的體現測試價值的方法，是困擾測試經理和對測試有良好認識的產品經理的一個大問題。
4. 有關測試模式的思考
對測試模式的想法完全起源于設計模式。既然能夠把復雜的體系結構設計能抽象，總結成這么一套東西，為什么不能對測試活動也如是觀之呢？
現在我對模式的理解還不是很深，也沒有很多的測試經驗，所以到現在為止，只能抽象成一種模式，我將其命名為包含模式（ include ）
模塊 A 中引用模塊 B 作為 A 的子功能，這時的測試方法應該是先測試 B 模塊，然后再將 B 模塊中的任何一個路徑作為 A 的一部分來測試 A 模塊，這時 B 模塊中的任何一條路徑，已經被同化成等價類（雖然在 B 模塊的測試中，它們可能不屬于同一個等價類）
（這只是一種思維構想，希望能夠拋磚引玉，能將這個體系完善起來）
5. 測試與開發的關系
測試到底和開發處在怎么樣的一個關系下才能夠較好的產生測試應該達到的效果呢？
測試部門獨立于開發部門。這種模式可能源于傳統制造行業的 QC 和生產部門的分開。其目的是為了保證測試過程和測試結果的客觀性和有效性。這種模式相當于把測試和開發分成兩個涇渭分明的活動，并沒有過多的考慮兩種活動之間的互為補益。在這種模式下，很可能演變成測試和開發之間的對立，或者增加測試和開發之間的溝通成本。
邊測試，邊開發。這是 XP 的輕量級開發過程所倡導的，現在的測試驅動開發理論就是符合了這種模式。采用先設計測試，再進行開發，當開發的軟件通過了所有的測試，軟件就完成了。這種方式其實并沒有規避自己測試自己代碼所產生的局限性問題，只是將思維的順序作了些改變，降低了思維定式對軟件開發產生缺陷的影響。
測試部門屬于研發中心，但獨立于項目組。這種模式保證了測試與項目組之間的最終目標的一致性（高質量的軟件產品），能有效的降低溝通成本，又能保證測試人員有一定的獨立性，不會過分的受產品經理的控制，避免測試失效現象產生。但在這種情況下，相比兩個部門獨立，測試的結果有可能不會被項目組所重視，需要頻繁的進行協調，才能及時處理缺陷。
