学习笔记 8-23
1、数据库,建表
创建一张学生信息表Student
Sno学号为整型5位,主键
Sname姓名为字符型20位,不能为空
Ssex性别只能是男或女,不能为空
Sage年龄整型2位
Sdept所在系为字符型20位
1 CREATE TABLE student 2 ( 3 sno INT(5) PRIMARY KEY, 4 sname CHAR(20) NOT NULL, 5 ssex ENUM("M","F") NOT NULL, 6 sage INTEGER(2), 7 sdept CHAR(20) 8 );
--------------------------------------------------------------------------------
2、一个完整的缺陷报告
微信号:张小龙发送三张图片在朋友圈,公开查看方式,好友马化腾无法看到图片
--------------------------------------------------------------------------------
3、一个完整的测试用例
点外卖,30元减5红包。宫保鸡丁:15.6元;豆腐12.8元;米饭2元;打包盒3元。设计一条测试用例。选择使用红包
--------------------------------------------------------------------------------
4、数据库,表操作
学生表Student(Sno,Sname,Ssex,Sstep)
课程表Course(Cno,Cname,Cpno,Ccredit)
成绩表SG(Sno,Cno,Grade)
将计算机系全体学生成绩清零
1 UPDATE sg 2 SET grade =0 3 WHERE sno IN( 4 SELECT sno 5 FROM student 6 WHERE sdept LIKE "computer%" 7 );
--------------------------------------------------------------------------------
5、安装测试要检测的点有哪些?
1、检查正常安装能否安装;
2、检查覆盖安装能否安装;
3、检查升级安装能否正常安装;
4、将一个软件卸载后重新安装;
5、安装时取消安装,检查能否终止;
6、安装时取消安装,检查能否再次安装;
7、检查在不同操作系统安装能否正常安装;
8、检查在其他软件(比如杀毒软件)正在运行时能否正常安装软件;
9、检查内存资源不足时能否正常安装软件;以及出错时系统是否给出合适提示;
10、检查cpu资源时能否正常安装软件;以及出错时系统是否给出合适提示;
11、检查安装时走不同安装路径,能否正常安装;
12、检查安装完成后,软件能否正常运行。
--------------------------------------------------------------------------------
6、系统测试的测试类型有哪些?
- 功能测试
测试要点:单功能测试、功能交互测试、业务流程测试
- 性能测试
负载测试与压力测试的区别
负载测试:不断增加服务器的并发用户数,测试在预期并发下,系统的性能响应情况(见好就收)
压力测试:不断增加服务器的并发用户数,测试在极限情况下,系统的性能响应情况(使劲折腾)
- 界面测试
测试要点:
主要核对原型图,检查被测试系统排版布局是否合理,检查有没有错别字,有没有乱码;
检查页面控件大小、位置是否合适;
检查图片是否清晰,是否有变形;
- 兼容测试
思路:
a) 硬件兼容(各种屏幕尺寸台式机、笔记本、ipad、手机)
b) 软件兼容
i.操作系统的兼容(win7、win10、linux、MacOS、android、IOS)
ii.数据库不同版本的兼容
iii.浏览器的兼容(ie、Firefox、chrome、Safari)
iv.被测软件前后版本的兼容
- 安全测试
测试要点:检查密码是否明文显示、检查是否存在sql注入漏洞、检查是否存在跨站脚本漏洞、检查文件上传时是否可以上传可执行文件、权限漏洞
- 易用性测试
- 可靠性测试
- 文档测试
- 安装测试
- 升级测试
- 卸载测试
- 容量测试
- 接口测试
-------------------------------------------------------------------------------
7、用判定表分析ABC三个数能否组成三角形以及什么类型的三角形
--------------------------------------------------------------------------------
8、当测试发现一个BUG后和项目经理,开发之间是如何交互的
流程描述
- 测试人员发现bug提交给开发。
- 开发人员判断是否是bug。
- 如果是bug,进行修改,修改完成后更改bug状态为已解决。
- 如果不是bug,退回给测试人员并描述退回原因,或为设计如此,或为外部原因,或者不能重现。
- 开发人员修改完成的bug,由测试人员进行验证,确认修改正确,关闭bug。
- 验证未通过的bug重新激活,开发人员继续修改,直至验证通过,关闭bug。
- 测试人员需要对开发人员退回的bug进行确认。
- 确认不是bug关闭。
- 如与开发人员意见不一致,认为是bug,需提交项目负责人(需求人员)仲裁。
- 项目负责人确认是bug由开发人员修改,不是bug由测试人员关闭。
各角色应关注的状态
开发人员:激活、重新打开
激活:开发人员要对处于激活状态的bug进行处理,处理后将其状态置成“已解决”、“设计如此”、“无法重现”、“外部原因”、“重复bug”或“延期处理”。
重新打开:重新打开的bug是已解决的bug经过测试人员验证,未修改正确,需要继续修改。
测试人员:已解决、无法重现、设计如此、外部原因、延期处理
已解决:测试人员发现状态为“已解决”的BUG,要及时验证,如果确实已解决,要将其置为“关闭”。否则“重新打开”
无法重现:测试人员发现状态为“无法重现”的BUG,要及时修改,把步骤描述清楚,并将其状态置为“重新打开”。
设计如此:测试人员发现状态为“设计如此”和“外部原因”的BUG,要及时通知项目经理,由项目经理来决定是否修改;对“延期处理”的问题要进行定期跟踪,如发现问题没有按注释进行修改要及时通知开发人员或汇报给相关负责人。
项目经理:设计如此、外部原因、延期处理
设计如此:因为这些BUG都是测试人员和开发人员有争议的BUG,因此项目经理必须及时关注这些BUG,及时给出合理的定夺,如果不需修改把状态置成“关闭”,如果需要立刻解决置成“重新打开”,否则置成“以后解决”。同时,项目经理也要关注“延期处理”的BUG,以免其被漏掉或遗忘从而影响到项目上线。