2、分析被测对象,划分出测试项、测试子项,可以避免不出现漏测的项
3、先测试基本功能,保证软件大体上无致命的BUG出现
4、其他功能可以考虑把测试密度降低来测试
还是来不及,就加加班吧 非常同意15# 直接测试,设想如果你是用户,拿到这个软件后,你会做什么操作,使用什么功能。 补充一下:总之就是站在客户的角度来测试 个人经验这个时候很有帮助 这个时候当然没有时间写计划和方案了
计划的话当天早上稍微给自己定个大体的,方案和用例一起完成
不过不要针对软件来测试,还是要针对用例的,所以说用例还是要有的
写好用例之后就快执行 不错学习了 觉得应该先明确这个软件的测试标准,要达到什么标准;
然后对关键功能点写测试用例,用例不用太规范,只做为思想指导;
数据库部分应该是测试重点,特别关注一下,毕竟只有一天时间,最后能达到基本功能测试没问题就不错了 原帖由 davy_chen 于 2007-9-26 10:18 发表 http://bbs.51testing.com/images/common/back.gif
遇到这种情况我的做法:
1、不写测试计划和测试用例;
2、直接进行测试,不用担心漏测,因为时间、资源不足不可能不漏测;
3、尽量多的发现问题,无论大小都要明确记录;
4、提交报告时指出1天测试资源远远不足, ...
说得好...赞同! 时间这么短促,只能按经验测 同意10#、15#的,
保证主要功能的测试,总体要覆盖一下
提交Bug时,可以详细的描述Bug的产生操作步骤,或者直接和开发人员沟通,这个更快:) 我的做法,什么也不写,对着用户使用说明书,对软件进行操作一遍,在进行该操作的同时,用自己平时说学习到的,凭着自己的经验和感觉,觉的那个地方可能会有BUGS的话,那就多试用,然后记录所有的BUGS!! 原帖由 davy_chen 于 2007-9-26 10:18 发表 http://bbs.51testing.com/images/common/back.gif
遇到这种情况我的做法:
1、不写测试计划和测试用例;
2、直接进行测试,不用担心漏测,因为时间、资源不足不可能不漏测;
3、尽量多的发现问题,无论大小都要明确记录;
4、提交报告时指出1天测试资源远远不足, ...
说的是很对的 读相关文档写测试用例肯定没有时间去执行了,比较同意davy_chen他的! 原帖由 hdice 于 2007-9-27 09:56 发表 http://bbs.51testing.com/images/common/back.gif
测试计划肯定是来不及写了,不过测试用例要写个简要的,
1. 首先尽快看完操作手册,要知道这个软件的大体功能,确定软件的最有价值的功能,
2. 写出主要功能的检查列表,如果不谢很可能测试过程中就落下了某项
3. 按 ...
有的操作手册可能就够看上一天的了。。。操作手册只能作为参考吧,个人觉得找相应的开发人员或者最熟悉这个的人了解最主要的功能
其他的和10楼的差不多的考虑。 先明确软件的主要功能,主要测试这些!不过主要是ad-hoc测试!嗬嗬,学习了!
7楼+10楼的,差不多了
直接找开发的头问他具体要测试的重点是什么,测重点! 1、熟悉软件的整体功能逻辑,并抽取基础功能逻辑2、与研发、产品确认测试重点、范围
3、不再编写测试计划和用例
4、和测试经理说明情况,申请人力资源支持
5、无人力资源支持,自己加班完成
6、高效进行bug提单
7、测试结束后,报告中重点说明测试时间不足,存在风险。。