不过，在用 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 视图要求选择需要分析的建议或者类，而横切比较工具使您可以检查整个项目的改变。
缺点是横切比较工具在方面影响多个联结点时会不好用。考虑一个记录所有公共方法的日志。这样一个方面在哪怕一天的开发后也会增加十来个新改变，使得查看其他更重要
文章来源于领测软件测试网 https://www.ltesting.net/
