测试人员担心的是:逃逸缺陷,自己那块没有测试点没有覆盖到,我常常在思考这些问题:
♦ 怎么知道软件足够好?
♦ 如果软件并不是足够好,怎样才能知道?
♦ 怎么知道已经完成了足够的测试?
测试人员的核心工作:测试软件,能在规定的时间内交付合格的产品。
所以就引申出两点影响我们的测试工作:
♦测试计划很重要计划部分我到后面的文章写一下。
♦还有一个是我们介入测试后具体该怎样测(这个是我今天要解决的)
怎样测试这确是我很关注的一个问题:
首先我们思想中要有一个层级关系:
1.首先用:http://www.cnblogs.com/insane-Mr-Li/p/9049510.html思考问题的方式来搞清楚我们要测的是个什么东西,我们想要对他做些什么,从需求种筛选测试点。
2.明白我们整个web测试点的框架:功能测试,性能测试,可靠性测试,负载测试,易用性测试,强度测试,安全测试,配置测试,安装测试,卸载测试,文档测试,故障恢复测试,界面测试,容量测试,兼容性测试,分布测试。
功能测试:一般都是可以从需求上筛选一些的,我们也可以看到真正做出来的东西再挑一些测试点再用http://www.cnblogs.com/insane-Mr-Li/p/9049510.html思考方法来考虑一遍,筛选出一些通用测试点和这些功能的个性化测试点,再进一步的用用例设计方法来筛选才是点,然后再设计成用例。
例子:上传下载
认识事物:
1.是什么?:根据需求明白这个东西是什么?它主要想实现是什么?
测试点:1.上传附件
2.整个上传文件的界面和操作风格是否与真个系统协调,文字显示是否正确。
3.页面按钮:新增,修改,清除按钮是否生效,
2.为什么?:为什么上传附件,上传的是什么东西?可联系需求的前后关系是否合理。
测试点:1.设计是否有缺陷
2.文件(格式,大小,数量)
3.怎么办?:是怎样上传的?
测试点:1.上传分哪些步骤
4.时间:一般客户会在什么时间来操作系统?操作的相应时间会是多少?多长时间能测试完?
测试点:1.集中使用网速,和并发问题
2.操作的响应时间问题(单个,多个,)
5.地点:从哪里来?现在在哪?去往哪里?
测试点:1.从哪里跳转到这个上传页面
2.上传和下载的位置是否合理
3.上传之后应该上传的东去哪了,上传的对不对
4.上传文件的路径(选择,和手工输入,文件名长度,特殊字符等)
6.人物:谁在使用长传,用什么方式上传?
测试点:1.这个软件使用者是:老人,小孩,年轻人,残疾人(根据每种人的特点做相应个性化)
2.是触屏手点的,鼠标点击,还是只要选中像回车键就可以等
7.效果:实际结果与预期结果
需要自己明白
8.多少:这个任务的量有多少,我多久能测完(属于测试计划中的)
我们还要搞明白这些问题:
1.我们想要一个预期结果,或者是客户所说的一个预期结果。
2.我们现在有哪些?
3.我们还要准备什么数据,或者我们还能从别的地方准备的数据
测试点:1.前期准备的数据
2.我现在有的数据
4.上转到哪里?
再用用例设计方法;
♦上传附件
1.有没有这个上传附件的地方
2.按钮的大小,美观,易用性
♦上传的文件是什么?
等价类边界值:有效的文件,和无效的文件,离点,上点
1.文件格式
2.文件大小
3.文件的数量(单个上传,批量上传)
(在这些有效等价类和无效等价类中,对应的相应提示是否合理)
特殊域:
1.只上传一个文件但是文件的大小以超过上限
2,上传空文件
3,不上传文件点上传
♦上传分哪些步骤:
流程分析:上传界面我还需要做哪些步骤才能完成上传,如果没有这些步骤会有那些结果
♦集中使用网速,和并发问题
场景分析法:1.客户集中在什么时间使用,可能这个时间段用户较多网络服务,或软件运行有压力,我们可以考虑租用高峰期期时间段服务器等措施解决。
2.软件,服务器,网络,等因素的并发问题
♦异常性测试:
1.在上传是断网,又忽然间连上,上传还会不会继续
2.中断了的话下次上传会不会有没有覆盖上一次已上传的部分。
3.批量上传中有效数据中掺杂着一些无效数据会不会筛选出无效数据,把有效数据进行上传。
4.硬盘空间不足
未完待续。。。。