Shopping缺陷管理文档

Shopping项目缺陷管理
一、 缺陷的发现：
1、 项目模块分配
2、 项目命名统一原则
3、 商品、订单排序
4、 发布时间及前台显示
5、 广告修改图片问题
6、 会员修改信息密码问题
7、 发票抬头
8、 商品添加订购数量
9、 错误信息提示跳转
10、 网页后退
11、 购物车数量更新
12、 送货默认时间
13、 商品信息添加 不填 保存 500错误 乱码
14、 公告发布时间和失效时间 发布时间要小于失效时间（且自动失效）
15、 商品分类的添加
16、 商品前台搜索显示
17、 订单查询 订单号 订单状态 查询有问题
18、 后台统计管理 点击 有误
二、缺陷信息及解决
首先我们必须知道软件中的缺陷（Defect或Bug）是软件开发过程中的"副产品"。
通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。
（1）本小组的Shopping项目总共有六个模块：用户管理、商品管理、服务管理、
购物管理、订单管理、统计管理。这六个模块总共被划分为了三个部分，用户管理和商
品管理、服务管理和订单管理、购物管理和统计管理。当初一开始并没有仔细去分析模
块之间的联系，所以模块与模块之间的联系自然就不清楚，只是按照一难一易搭配分配
项目模块。这样的模块分配就是这个项目的第一个缺陷，其实用户和商品本身联系并不
紧密，用户和购物的联系较为紧密，因为本项目在设计当中，用户不需要通过登录也能
查看商品信息，只是不能进行购买和评论。而订单和服务也没什么直接联系，订单是一
个比较独立的模块，它的数据来源于数据库。至于统计和购物倒是有一点联系，有户购
买商品会使得商品的购买数量增加，从而影响销售统计。
（2）项目初期，对于项目命名统一虽然编制了一份属于自己的规范文档，但是实
施不够到位，导致项目的下的包名或者是VO字段，数据库字段命名都没有统一，幸亏
问题发现及时，将命名及时统一，将整个项目的后台代码一共分为了五部分，即五个主
要的包。数据库字段统一改写，这个为我们小组后期项目整合有很大帮助。
（3）通常在后台进行对信息的添加前台即可立即显示，但是项目完成初期，后台
信息添加后，前台显示在最后一条记录，这个在实际应用当中很不合理，所以在数据库
查询时增加了排序功能，按照创建时间先后排序，这样最新添加的就可以在信息显示页
面最上面。
（4）在服务管理模块当中，广告和公告都是有一定时间限制的。但是一开始忽略
了广告和公告发布时间和在前台显示的关系，如果发布时间晚于系统当前时间是不应该
让广告和公告显示的，所以为了解决这一问题，在从数据库取出公告和广告信息是增加
了一个时间控制，让创建时间和系统时间相减做判断控制取出的信息。
（5）广告在添加时没有上面问题，但是广告要修改时，发现如果不修改图片上传
图片路径的话，那么提交修改信息以后数据库中图片的路径就不存在了只剩下一个
“images/”的路径，后来发现原来在修改广告信息时，广告的所有信息都是根据修改
页面上的控件信息全部提交覆盖原有信息的，而在修改时，除了图片浏览空间没有默认
值之外，其他控件都有默认值，即广告原有信息，这样如果图片没有新的更新信息就是
空信息，就获取不到图片名。解决这一缺陷，在提交广告修改信息时，首先判断图片是
否有上传新的图片路径值，如果有就用新的覆盖原有的信息，如果没有就取出数据库中
原有的传入到参数当中，设置到Preparement中作为新信息覆盖原有的。
（6）会员的密码作为机密，一般是不能透露的，但是一开始只是想要展现功能，
于是在用户修改个人资料时，把用户密码作为一项信息输出在了页面上，后来老师提示
用户原始密码必须要由用户自己输入，这样才更具有安全性。
（7）发票抬头，引用了JS控制，用户可以选择需要还是不需要发票，如果不需要
发票，则发票抬头就会隐藏，如果需要就会显示。其实整个处理方法是正确的，原因在
于在判断多选框是否被选中时出了差错，当多选框被选中时，其属性值与“on”是匹配
的，但是在判断时我用的是inv. equals (“on”)，由于当没有选多选框时，inv的值为
null，自然不能应用
equals方法，因为这个是适用于字符串类型的。所以将方法改一下

“on”. Equals(inv)即可。
（8）商品表中有商品订购数量，而且商品的订购数量是不能为空的字段，所以在
商品添加时就要将其添加进数据库，但是商品在没有上架时是没有订购的，所以就将订
购数量设成了隐藏域，默认值为0，和其他商品的信息一起插入数据库当中
（9）在项目当中最严重的缺陷莫过于错误，整个项目开发当中，最常见的就是404
和500错误，404错误还是比较简单的，但是500错误却总是有不一样的理由，是代码
问题的话还能找不出来，不是代码问题而是程序流程控制问题就没法修改了。通常我们
有跳转500错误，就是指权限不够，无法进入下一个页面时，这时页面总会报一个500
错误，为了统一解决这个问题，同时保持页面的美观和可读性，就得为错误作出解释，
而且这种解释用户必须也要能读懂，这是信息“information”必不可少。在Servlet当
中，控制程序流程时，处理程序跳转时必须让所有错误信息跳到一个统一的页面，但是
针对不同的错误有不同的提示信息，所以在Servlet当中，页面跳转前预先设置一个
Attribute，里面存储错误提示信息，在页面当中用$符输出。这样处理不仅做到了页面
美观，也做到了使得用户能理解开发人员所传递的提示信息，更好的掌握整个购物流程。
（10）本小组在项目开发过程当中，开始全然未考虑到页面后退的操作，即使自己
操作也经常是使用浏览器的后退，可是很多时候页面的信息是通过了Servlet之后才能
获得信息的，当Servlet当中的属性值是用request设置时，页面一退一进，页面就无法
保留原有信息了，这样造成了不必要的错误，所以在页面进行操作后所跳转到的页面可
以适当增加后退按钮。
（11）购物车中的商品，用户在最开始选择时，默认都是一件，到了购物车本应该
给予修改数量的权利，一开始使用按钮，进行数量的更新，即用户点击按钮即可将页面
的商品ID传到Servlet,对当前用户的购物车的LIST进行更新，但是有一点，页面的购
物车中的商品都是通过C标签foreach循环输出的，所以造成了点击按钮后更新的往往
是第一个输出商品，具体问题出在哪里，我到现在也没用弄明白，个人认为可能是所有
的name都是一样的。所以后来采用了可编辑文本框，并且对输入的内容进行了相关验
证。
（12）送货默认时间，由于在填写订单提交订单后跳转到Servlet，进行了相关数据
类型的转换，送货时间既是。送货时间在Order表中是引用送货时间表的主键的，所以是int
类型。在填写订单的页面，送货时间统一是用C标签的foreach从数据库取出，循环输出地，
因此不方便定义一个默认的，当用户不进行选择送货时间或不填表单直接提交时，那么就会
有错。因此就在数据库中的送货时间表增加了一个“无时间要求”的送货时间项，在页面中
也不从数据库取，只是将数据库中相应的值直接写在JSP文件中输出，并且定义为默认值，
这样可以防止用户不填写表单就提交表单所造成的问题。
（13）后台商品添加时，如果按照正常操作时，不会有什么问题，但是组员在测试
时发现，如果提交空表单时会出现500错误，这个原因和上面是一样的，因为商品的市
场价格及会员价格都是float类型的，所以在点击提交后，对表单数据会进行获取并进
行类型转换于是会出现NumberFormate异常。为了避免这样的错误，在表单提交后跳
转到Servlet后，首先对表单获取的需要进行数据转换又不能为空的数据进行判断，如
果获取的是null，则让页面跳到提示操作失败的页面，这样就不会出现那样的错误。
（14）公告的发布肯定是有一定的有效期的，而且发布时间必须早于失效时间，同
时一旦公告失效，前台页面不应该再显示，一开始没有注意到这个细节，所以就在公告
添加时做了时间判断的验证，如果用户添加公告时发布时间晚于失效时间，那么在提交
后会跳回该页面并提示错误，同时在前台获取公告的SQL语句里也增加了时间判断和
限制，即datediff函数，可以判断系统时间和指定时间的差值。
（15）商品分类分为大类小类，每一个大类在大类中应该是唯一的，每一个小类在
该父类下也应该是唯一的。因此后来增加了一个JS文件专门用作判断分类是否重复。
（16）商品前台搜索，商品前台搜索只是因为在${}当中List的别名写错了，因此
无法显示出数据，但是分页统计显示时正确的。

三、未能修复的缺陷
后台订单搜索到目前为止仍然是一个问题，订单搜索时，若是订单号和订单状态
同时有值，则只是遵照前者，但是缺少一个又查询无效。SQL语句修改为and则数据
全无。
后台的统计管理没能实现，图片有问题，无法显示。