关键词：功能测试，特殊字符
笔者结合自身参与的银行系统功能测试实践经验，针对常见的特殊字符进行了分类，包括：“NULL”、“空白字符”、“汉字生僻字”、“常用分割符”、“数据库相关特殊字符”、“其他特殊符号”等6类，“特殊字符”的测试覆盖规则严格依赖于具体的系统交易字段（页面字段、数据库字段），测试人员在实际测试过程中，先选择要测试的字段，再根据实际情况选择要覆盖的特殊字符类型。
1.1概述“NULL”指数据库中具体字段的“NULL”值。NULL是一个不确定的值（NULL represents an unknown value），所以不包括在任何一个指定的集合中。
常用数据库有DB2,Sybase,Oracle和MySql，不同数据库对NULL的处理存在差异，容易造成程序缺陷，特别是数据库迁移时更容易发生。目前已知的NULL相关缺陷有两类：·应用程序读取字段，未判断null，导致应用抛出异常。·不同数据库NULL处理有差异，导致应用程序逻辑不一致。
1.2典型风险场景该类问题风险场景主要为不同数据库处理机制差异，例如：Sybase对空值的处理为长度为1的空格，而Oracle为NULL，在拼接报文时会出现因缺少字段而报错。测试人员应根据需求说明书逐一对各输入框的必输性进行测试，对于非必输项需测试其为空值的场景。笔者在测试过程中发现非必输项如输入空值，则迁移到Oracle数据库后会报“9998”类型错误，后项目组采取了对所有输入为空值的字段，均用统一默认值替代，解决了因识别空值为NULL而引发报文中字段缺失进而导致交易报错的问题。
2.1概述本文的“空白字符”指空格符（SPACE），制表符（TAB）与换行符（
）。
当前，“账号”“金额”等字段中允许输入空白符，但是应用处理不一致，会导致缺陷。目前已知的缺陷类型有：·字段中间有空白字符，导致业务异常。·字段首尾有空白字符，导致业务异常。
2.2典型风险场景·户名字段输入空白字符，可能会发生对公户和个人户的混淆。例如：“张三”为个人户名，输入空白字符“张三 ”“张 三”后，由于户名长度过长，应用会将个人户识别为对公户，进而发生逻辑错误。
·账户号字段输入空白字符，会发生转账类交易失败等。
3.1概述
功能测试在界面输入字段如输入汉字生僻字类型，可能发生字段输入值校验失败、报文解析报错等，笔者梳理了常见的生僻字，测试人员可结合测试具体情况选择相应的生僻字进行测试。常见汉字生僻字：
3.2典型风险场景
·转账类交易中收款方账户名称校验失败，交易失败。·交易明细中有生僻字，导致报文解析失败。
4.1概述
“常用分隔符”特指“｜”，“－”，“／”，分号，逗号等5个符号。数据库字段存储时会把上述符号作为分隔符处理，如输入数据本身存在分隔符，则会引发字段解析错误，导致报文解析失败。
4.2典型风险场景
·交易明细查询在数据表中存储时，字段间以“|”做分隔符。如果交易数据中某些字段内容本身就包含“|”的话，在进行联机查询时，就会引起字段解析错误，导致明细查询报文解析失败。
·附言/备注中的分隔符“|”，导致关联系统报文解析失败。
5.1概述数据库相关的特殊字符包括：
1、未兼容数据库的特殊字符“_”、“%”等，该类特殊字符会引发数据库存取缓慢，引发系统运行风险等问题；
2、数据库处理机制存在差异的字符类型，如char类型字符在不同数据库的处理机制不同，存在程序逻辑错误风险，在数据库迁移测试中需重点关注；
3、SQL注入是一种WEB应用代码漏洞，测试人员可在输入字段中增加带有附加条件的SQL语句执行测试。
5.2典型风险场景
·未兼容数据库的特殊字符“_”、“%”，查询交易在使用模糊查询时，可能会引起极个别使用特殊字符做户名的客户的数据库查询时间长，进而对系统运行造成风险。
·Sybase和Oracle对于不同字符类别的处理机制不同。以char字符类型处理机制为例，Sybase中历史数据中有长度为1的数据‘6’，迁移到oracle后，取值时为会自动补空格变为‘6 ’，导致程序逻辑出错。刚开始开发人员在程序中通过trim过滤空格，后统一将char类型修改为varchar类型。
·表单中提交1’or1=1;#获取所有账号信息，可通过数据库用户最小化权限等方法解决。
6.1概述
其他特殊符号包括数字符号、货币符号、符号图案、外文字母等，详见下表：
6.2典型风险场景
·输入字段结合项目具体需求选择适配的特殊字符。·重点关注交易明细（翻页）、账户明细（翻页）、转账等交易户名为特殊字符的场景。