不過，在用 AJDT 的 cross-references 視圖檢查切點時，會看到圖 2 所示的內容：
圖 2. AJDT cross-references 視圖中四個建議的聯結點
注意有一個多余的匹配：SearchResult.getWebsite()。您知道這個 Website 不應該突出顯示，因此重新編寫這個切點以排除不需要的匹配。
優缺點
使用 AJDT 的 cross-references 視圖檢查橫切規范有三個主要的好處。首先，cross-references 視圖可以在開發方面時馬上給出反饋。其次，它使您可以容易地發現難于測試的結果。（要編寫驗證 getWebsite() 沒有 突出顯示的測試，需要猜出 getWebsite() 可能會出錯，或者檢查 SearchResult 中每一個 String getter。越不容易出的錯誤，就越難很好地測試。）第三，自動生成的視圖可以驗證正確情況，在代碼中驗證它們是很麻煩的。例如，如果搜索 highlighter 需要影響 20 個聯結點，那么檢查 cross-references 視圖比為每一個聯結點編寫測試更容易。
使用視圖驗證的主要缺點是不能自動檢查。它需要程序員的自律。匆忙的程序員可能看過圖 2，卻沒有發現問題。（下一個模式展示了對這個問題的部分解決方案。）另一個問題是橫切視圖只顯示了基于靜態聯結點 shadow 的匹配。換句話說，如果有依賴于運行時檢查的切點，如 cflow() 或者 if()，那么 cross-references 視圖不能肯定地說聯結點會在運行時匹配，只能說看來如此。
模式 2. 檢查隨橫切比較工具改變
針對 ：橫切規范
概述 ：利用 AJDT 的橫切比較功能在重構之前或者其他代碼改變前保存項目的橫切圖。在完成改變后保存另一個圖。（還可以每晚保存一個圖以便比較。）在橫切比較工具中比較這些圖，以發現受方面影響的聯結點所出現的不希望的改變。注意在撰寫本文時，只有 AJDT 提供橫切比較工具。
例子：改寫一個切點
假定要改正上一個例子中表現出的問題，決定修改切點以使用 Java 5 注釋，如下所示：
public pointcut highlightedTextProperties() :
execution(@Highlighted public String Highlightable+.*())
然后在源代碼中適當位置上添加注釋，例如：
@Highlighted
public String getTitle() {
return title;
}
下一步是比較在改變前后所抓取的項目快照，并得到如圖 3 所示的結果。如您所見，重構消除了 getWebsite() 的建議匹配，但是也消除了 getSummary() 的匹配。（它看上去就像沒有添加上注釋。）
圖 3. 在橫切比較工具中顯示的改變結果
優缺點
這項技術實際上是對上一項技術的優化。通過只顯示改變，橫切比較工具可以幫助防止信息盲點。同時，cross-references 視圖要求選擇需要分析的建議或者類，而橫切比較工具使您可以檢查整個項目的改變。
缺點是橫切比較工具在方面影響多個聯結點時會不好用�？紤]一個記錄所有公共方法的日志。這樣一個方面在哪怕一天的開發后也會增加十來個新改變，使得查看其他更重要
文章來源于領測軟件測試網 http://www.kjueaiud.com/
