标签：界面 filter 延迟 mat 时间 struts 修复 设备 需求
请根据团队项目中软件的需求文档、功能说明、系统设计和Beta阶段的计划安排，写出软件的测试过程和测试结果，并回答下述问题。
在测试过程中总共发现了多少bug？每个类别的bug分别为多少个？
bug的分类：
a. 修复的bug：
1.当使用添加功能时，没有填写数据会造成空指针异常，跳转到报错页面；
2.当删除有依赖性关系时的，没有提示有记录存在；
3.当有已报修记录时，没有对处理报修单，按钮进行处理，会造成重复报修，出错；
c. 这个产品就是这样设计的，不是bug：
添加设备类型时，部件有添加上限：
d. 没有能力修复，将来也不打算修复；
当某些浏览器使用极速模式时，页面的样式和js效果无法显现
e. 这个bug的确应该修复，但是没有时间在这个版本修复，延迟到下一个版本修复。
只要通过查看源码，可以通过输入网址，就可以进页面（无需登录）：
解决初步策略：
策略1：每个页面都判定一下，session中有没有user存在，如果没有，直接跳转到登录界面；
策略2：使用Filter类过滤，chain方法可以判定每个页面是否有user存在；
策略3：使用struts2自带的拦截器Interceptor，然后在struts.xml配置文件中配置拦截器解决；
场景测试（scenario testing），包括以下内容：
a. 你预期不同的用户会怎样使用你的软件？ 我的用户主要为实验室的同学们，在他们上机的时候发现所用的电脑有问题直接申请报修方便快捷。老师管理那边也很容易看见汇总后自己想要的结果提升效率。
b. 他们有什么需求和目标？学生：摆脱以往的手工登记费事费力的这项工作调动大家都是主人翁的态度积极参与进来：管理老师：方便汇总统计大大提升工作效率
c. 你的软件提供的功能怎么组合起来满足他们的需要？媒人一样牵线搭桥，将学生老师的所需信息汇总分类后给双方各自所需要
你们在什么样的平台、硬件配置、浏览器类型等条件上对你们的软件进行测试？——测试矩阵（test matrix）
你认为你们团队的软件在什么条件下，就可以认定其已经足够好，可以发布Beta版本？——出口条件（exit criteria）
管理员能添加用户、管理实验室及其设备，还有查看报修单，处理完毕后，修改设备状态。
学生登陆系统后，通过之前设置好的选项，能比较轻松地完成报修。
软件发布的同时，在团队博客上写一个发布说明
标签：界面 filter 延迟 mat 时间 struts 修复 设备 需求
原文地址：http://www.cnblogs.com/teamworkers/p/6941691.html
