相信在测试过程中，大家都会碰到一个费时又枯燥的工作，即“测试输入项可接受的最大长度是否符合需求。”尤 其是当一个新系统刚开发的时候，有大量的字段需要测试。而当众多的新功能需要测试的时候，这个测试点常常优先级不高，测试人员往往只是挑了其中一些重要的 或者偶然碰到的字段进行了测试，有时甚至忘记这档子事了。不幸的是，根据来自生产环境的缺陷报告，我们几乎每个项目都碰到过由于用户输入了超长的字段而产 生的产品缺陷，有的甚至严重妨碍了用户操作。这个差异告诉我们“应该要测试字段的最大长度，而且要用一种更简单易行的办法使得做这个工作的代价较低。”
James Bach在他的网站(http://www.satisfice.com/tools.shtml)上发布了他写的一个小程序Perlclip，可以用来生成一定规律的指定长度的字串，放在windows的剪贴板中，然后你可以粘贴到任何你想要输入的字段中。这是一个适用范围比较广的小工具，如果你还在自己手工输入长串数据，并且用word去计算这个字串的长度。那么建议你至少可以向前走一步，试试James的工具。
有时，我们还需要贪心一点。想想，James工具只能一个一个地准备数据，而把这些数据粘贴到对应的输入框里还是需要手工来做。看数据字典、生成字串、粘贴、提交、验证；看数据字典、生成字串、粘贴、提交、验证。。。如此五步需要大量重复，是否也可以自动化呢？让我们以一个基于ExtJS的web应用为例，借助Sahi这个开源的轻量级web自动化工具，来尝试测试字段最大长度的更省力的办法。
思路1： 从页面元素得到它的长度限制，然后生成一个最大长度的字串和一个最大长度加1（此处用边界值法简化）的字串，进行测试。但困难在于页面元素的长度限制在UI层得不到，只好放弃。
思路2：在整个页面的字段中找到那个允许长度最长的字段，然后以这个最长的长度加1的随机串去填充各个某种特定输入类型（如textbox或者textarea）的所有字段，保存，看是否每个字段都报错。报错时页面应该提示数据非法（所有有长度校验的字段都失败)，且此时失败的字段个数及相应的提示（最大长度是多少）应与数据字典一致。（需要人工检查）如果DB出了异常，我们应该可以从服务器返回的信息或者异常的日志中知道哪个字段出错。
这个思路没有大的问题，但是在我们具体的程序实现技术下碰到了两个问题。一、我们程序的页面上有些list因为也是textbox类型，所以被赋了值非法的长值。这并不是我们想要的，因为它把非法值的校验的和长度的校验揉杂在一起了。所以，我通过数据字典那边只抽出需要校验自由输入的长度的字段来屏蔽这个问题。二、我发现一些系统生成的只读的textbox字段，如某对象的ID，不应该通过我们的Sahi程序将它的值修改掉。还有一些UI不可见的元素，如开发人员设计中特意用到的一些oid，因为也是textbox类型，如果用我们的长字串代替了就会出错。所以我仅仅对UI可见的且非只读的textbox来做。经过上述修正，最后我的方法如下：
准备工作：
准备一个包含两列的excel，第一列是需要验证字段长度的字段名，第二列是该字段允许的最大长度。当然，你也可以准备一个三列的excel，其中多一列字段的类型，以便你既可以生成字串又可以生成数字。
步骤：
1. 打开一个待测试的页面
2. 跑验证字段长度的脚本
a. 将excel中每个页面label对应的textbox都填上excel中指定长度的字符串，然后一起保存。预期结果应该是保存成功（不因为字段长度的校验而失败）。以此方法还可以顺便就把label拼写错误（UI label与数据字典label匹配不上）的情况轻松地暴露出来。
b. 将excel中每个页面label对应的textbox都填上excel中指定长度再加1的字符串，观察系统行为。如果在前台已经做了校验，则观察前台的提示。如果前台不会禁止掉用户的超长输入，则通过保存来提交后台，预期结果应该是保存失败。