从表单提交看“软件开发及测试中的边界问题”

有一个PHP后台表单功能,可以绑定50个商品的url及其他数据。今天有用户反馈出Bug. 当添加30个商品保存后商品数据丢失。我就自己测试了下添加了12个商品保存正常,当商品添加到30个时保存果然就消失了。开始以为是逻辑中有数量限制错误,检查后发现没有问题。

以前呢也遇到过POST保存失败的问题的几个case:

1. 表单动态添加POI列表,每个列表有两个隐藏的input存储原始数据, 两个真实供用户修改的input. 因为是后台功能,当时的考虑是将隐藏的input的原始数据跟用户看到的input提交后做比较,每次只更新修改过的值,减少数据的无意义更新操作。然而有个表单中有300个条目的列表,但是提交到服务呢会发现数据少了。经过查找发现是php.ini中默认的max_input_vars值为1000.表单数据300*4=1200超过了最大提交变量的限制,导致保存失败。可以修改max_input_vars大小,这里我是将隐藏的字段砍掉,改成提交后从数据库查询原始的数据。

2. 表单也是动态列表提交,含有大量图片数据,提交后服务直接返回“413 request Entity too Large” 。请求没有到达PHP就返回了,google搜了下发现是nginx配置问题,nginx跟php一样,也有相关配置设置最大POST提交长度:用client_max_body_size来限制表单提交。

3. 这个是在node.js 的express项目中遇到的,也是表单动态列表提交,所有的列表存在一个数组里,类似<input name=”arr[][‘name’]”>这种,期望后台收到arr的数组arr[]进行for in循环处理,正常测试两三个元素没问题,但是上线后反馈保存失败,发现当添加超过10个元素时,后台打印出得居然是对象{‘1’:{name: ‘xx’}},怀疑是bodyparser解析的bug. 然后程序做了兼容处理用forEach进行了循环。

所以重点要来了,遇到上面case时就猜测遇到了数据没有提交正确

a. 所以第一次测试时先添加了12个元素,验证是不是之前遇到的case3的问题。但是验证后排除了

b. 接着验证是不是case1和case2问题,浏览器开发者模式记录network请求,服务器PHP后端打印出接收到的数据,再用终端显示出nginx及php-fpm的日志。经过再次30个商品提交测试,发现从客户端请求,到服务器php进程接收都打印出正确地数据。

c. 然后推断是代码问题,逐步进行断点打印测试,最后定格在数据保存到数据库的这行,发现也没有出错,但是保存成功后页面仍然展示不出商品列表。

d. 然后检查了数据库发现字段有值,这个商品列表数据是用json_encode后作为一个字段存入的,接着推测是不是字段长度问题导致被截取,看字段定义为Text型。但是记得Mysql Text长度为65535字符长度,试着推测是不是长度超限了,用PHP的mb_strlen($str, ‘utf-8’)测了下提交的json数据是100281个字符。然后再细看数据库数据发现json果然被数据库截取了,验证了这个推论,json结构被截取破坏导致json_decode()失败出现空白显示。于是将数据库这个字段改为了medium text。至此这个case4圆满解决。

重点真的来了– -,经过这次表单提交问题就反思了下,程序开发测试中,我们经常只是动态添加几个例子去测试功能是否OK。往往开发及测试中都没有问题,但是上线以后总会出现各种用户真实数据的批量添加导致程序运行错误,我暂且称之为边界问题。真实地用户在实际使用中由于强烈地需求,致使添加了更多的数据量,触碰到了程序或者软件的某个极限边界导致产生不合逻辑的返回。

这给我们程序开发人员及测试人员也敲了钟。必须进行真实数据的测试以及边界条件的测试才能确保程序功能的正确性,用事实说话(ps. 焦点访谈)。我想这也是现代测试用例中需要注意的地方。

Leave a Reply

电子邮件地址不会被公开。 必填项已用*标注

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>