测试工作安排
作为一个测试计划来讲，核心的三个要素是时间，资源，范围。（这句话摘自微软的软件测试培训材料），时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。
- 时间：我们每天除了完成相应的模块分工之外，都有进行粗略的测试，大体测试一下功能能不能走通。另外第二天开始新模块之前，也会进行一次测试。更为集中的测试安排在12.4日晚上，我们白天完成了项目剩余的模块之后。
- 资源：除了我们小组团队的四个人之外，我们还借助了实验室其他学长学姐们的帮助，一起完成了对这个项目的测试工作。机器的话，有的是在Windows系统的台式机上进行测试，有些是在自己的笔记本上。
- 范围：我们对项目的四大模块都进行了测试，因为时间关系我们的测试重点集中在功能测试上。
- 测试策略：当天完成模块之后由自己测试自己的代码，隔天的测试进行互测。12.4日的测试主要由他人（实验室学长学姐）进行测试，我们及时修改bug
功能测试用例：
数据管理员
1.新增企业时，操作失败
2.添加政府/企业/第三方，操作失败
3.新增企业/政府/第三方时没有做名字和编号判重
单元：
1.修改企业信息失败
2.编号已经存在，但是还是能提交数据
3.新增企业之后，使用这个新增的企业编号和密码登录，界面如下
4.添加单元时，单元编号没有做数字判定，其他模块类似
5.用新增的企业编号登入，无法登入
6.联系方式没有添加正则式验证
7.企业单元树，新增没有提示，未选择父节点
8.企业自查风险管理和风险上报，查询无效
9.风险上报上传了图片，但是在图片查看里面看不到图片
10.企业自评员模块当中，时间查询无效
11.导入不成功，所有角色的导入均不成功
12.所有模块中导出Excel没有将编号换成对应的文字
13.此处导入单元数据成功，右侧红框数据为新增的导入数据，正确；只是单元树没有实时刷出这个节点。但是导出单元数据时最好命名为“企业名单元信息表”
14.头像没有出来
15.修改控制措施时没有将已报的控制措施带进窗口
16.添加后果之后走提交，提示出错，但是最终界面有将后果和评价结果插入，但是没有图片，是因为添加时上传图片出错。
17.第三方接受、收回委托的逻辑有误，委托结束时间已经超过当前时间了，不应再提示第三方接受委托了
18.统计结果不对
测试体会
- 在本次测试当中，发现很多细节没有弄清楚，比如电话，邮箱的正则式验证，这些都是很基础的常识，让团队有点羞愧，还有就是在添加时没有对编号和单元名字做判重， 没有对编号做判重，在同一角色之下，用一样的编号登入就会出错，没有对单元名字做判重的话，在做导入的时候，无法根据Excel表里的名字做相应的判断。
- 在做测试的时候，我们应该要明白我们不是要去验证我们做的产品的正确性，而是去发现产品错误的地方。
- 在本次的测试当中，由于时间问题，未能做性能测试，未能在数据量大，并发性强的情况的去考虑系统的承受力。
- 软件测试应该存在于软件过程的整个生命周期，因此，我们每天在完成每天的代码量之余，会适当加入一些团队自身的测试，偶尔会让实验室的学长学姐一起帮忙测试，团队自身的测试可能存在一些思维惯性，就会出现我们是去验证这个系统的正确性这个错误的方向。
项目测试评述
1.测试高效覆改各个功能点需求
2.在委托和核实这两个需求之下，测试优先级合理。
3.测试的前提条件明确，预期结果目的明确，避免模棱两可的情况发生。
4.测试时从用户本身的角度出发，符合用户场景。