测试工作安排
作为一个测试计划来讲,核心的三个要素是时间,资源,范围。(这句话摘自微软的软件测试培训材料),时间就是什么时候做以及要花多久做,资源就是你要调用的人力、机器等资源,范围是你要测试的东西以及测试重点。
- 时间:我们每天除了完成相应的模块分工之外,都有进行粗略的测试,大体测试一下功能能不能走通。另外第二天开始新模块之前,也会进行一次测试。更为集中的测试安排在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.测试时从用户本身的角度出发,符合用户场景。
时间: 2024-10-22 12:13:31