一旦你在Schema中定义了字段类型，并指定了你想要应用的分析步骤，你应该测试它以确保它按照你的期望运行。
幸运的是，Solr Admin UI中有一个非常方便的页面可以让你做到这一点。
你可以调用任何文本字段的分析器，提供示例输入，并显示生成的token流。
例如，让我们看一些在bin/solr start -e techproducts示例配置中可用的”Text”字段类型，并使用分析界面（http://localhost:8983/solr/#/techproducts/analysis）来比较在索引时为句子”Running an Analyzer”生成的token如何与稍微不同的查询文本”run my analyzer”匹配。
我们可以从text_ws开始 - 这是可用的最简化的Text字段类型之一：
这显示了分析的每个步骤产生的token的简单输出（在这种情况下是单个步骤）。
分词器以缩写形式显示，将鼠标悬停在上面或点击可查看完整名称。
如果我们通过勾选复选框启用详细输出，将显示更多详细信息：
通过查看每个词条的开始和结束位置，我们可以看到这个字段类型唯一做的事情就是在空白处对文本进行分词。
注意在这个图像中，词条”Running”的开始位置是0，结束位置是7，而”an”的开始位置是8，结束位置是10，”Analyzer”开始于11，结束于19。
如果词条之间的空白也被包括在内，计数应该是21；由于它是19，我们知道空白已经从这个查询中被移除了。
还要注意索引的词条和查询词条仍然非常不同。
“Running”不匹配”run”，”Analyzer”不匹配”analyzer”（对计算机来说），显然”an”和”my”是完全不同的词。
如果我们的目标是允许像”run my analyzer”这样的查询匹配像”Running an Analyzer”这样的索引文本，那么我们需要选择一个不同的字段类型，它在索引和查询时间进行更多的文本分析处理。
特别是我们需要：
- 大小写不敏感，这样”Analyzer”和”analyzer”能够匹配。
- 词干提取，这样像”Run”和”Running”这样的词被认为是等价词条。
- 停用词修剪，这样像”an”和”my”这样的小词不会影响查询。
对于我们的下一次尝试，让我们试试text_general字段类型：
启用详细输出后，我们可以看到我们新分析器的每个阶段如何修改它们接收到的token，然后传递给下一个阶段。
当我们向下滚动到最终输出时，我们可以看到我们确实开始在”analyzer”上从每个输入字符串得到匹配，这要感谢”LCF”阶段，如果你用鼠标悬停，你会看到它是LowerCaseFilter：
text_general字段类型被设计为对任何语言都通常有用，通过解决大小写敏感性问题，它确实让我们比第一个例子中的text_ws更接近我们的目标。
它仍然不太是我们要寻找的，因为我们没有看到词干提取或停用词规则被应用。
所以现在让我们试试text_en字段类型：
现在我们可以看到分析器的”SF”（StopFilter）阶段解决了移除停用词（”an”）的问题，当我们向下滚动时，我们还看到”PSF”（PorterStemFilter）阶段应用了适合我们英语输入的词干提取规则，这样我们的”索引分析器”产生的词条和我们的”查询分析器”产生的词条按照我们期望的方式匹配。
在这一点上，我们可以继续用额外的输入进行实验，验证我们的分析器在我们期望它们匹配时产生匹配的token，在我们不期望它们匹配时产生不同的token，当我们迭代和调整我们的字段类型配置时。