我觉得应该凭经验直接测试，进行随即测试。发现bug就提交。在软件测试计划里说明一下。

我觉得要是给的时间不多了，那只有凭经验来测试咯，随机测试（当然是在仔细研度了操作文档的情况下）！

1、放弃原本要编写的文档，测试计划、用例等
2、分析被测对象，划分出测试项、测试子项，可以避免不出现漏测的项
3、先测试基本功能，保证软件大体上无致命的BUG出现
4、其他功能可以考虑把测试密度降低来测试

还是来不及，就加加班吧

非常同意15#

直接测试，设想如果你是用户，拿到这个软件后，你会做什么操作，使用什么功能。

补充一下：总之就是站在客户的角度来测试

个人经验这个时候很有帮助

这个时候当然没有时间写计划和方案了
计划的话当天早上稍微给自己定个大体的，方案和用例一起完成
不过不要针对软件来测试，还是要针对用例的，所以说用例还是要有的
写好用例之后就快执行

不错学习了

觉得应该先明确这个软件的测试标准，要达到什么标准；
然后对关键功能点写测试用例，用例不用太规范，只做为思想指导；
数据库部分应该是测试重点，特别关注一下，毕竟只有一天时间，最后能达到基本功能测试没问题就不错了

引用:

原帖由 davy_chen 于 2007-9-26 10:18 发表
遇到这种情况我的做法：
1、不写测试计划和测试用例；
2、直接进行测试，不用担心漏测，因为时间、资源不足不可能不漏测；
3、尽量多的发现问题，无论大小都要明确记录；
4、提交报告时指出1天测试资源远远不足， ...

说得好...赞同!

时间这么短促，只能按经验测

同意10#、15#的，
保证主要功能的测试，总体要覆盖一下
提交Bug时，可以详细的描述Bug的产生操作步骤,或者直接和开发人员沟通，这个更快：）

我的做法,什么也不写,对着用户使用说明书,对软件进行操作一遍,在进行该操作的同时,用自己平时说学习到的,凭着自己的经验和感觉,觉的那个地方可能会有BUGS的话,那就多试用,然后记录所有的BUGS!!

引用:

原帖由 davy_chen 于 2007-9-26 10:18 发表
遇到这种情况我的做法：
1、不写测试计划和测试用例；
2、直接进行测试，不用担心漏测，因为时间、资源不足不可能不漏测；
3、尽量多的发现问题，无论大小都要明确记录；
4、提交报告时指出1天测试资源远远不足， ...

说的是很对的

读相关文档写测试用例肯定没有时间去执行了，比较同意davy_chen他的！

引用:

原帖由 hdice 于 2007-9-27 09:56 发表
测试计划肯定是来不及写了，不过测试用例要写个简要的，
1. 首先尽快看完操作手册，要知道这个软件的大体功能,确定软件的最有价值的功能,
   
2. 写出主要功能的检查列表,如果不谢很可能测试过程中就落下了某项
3. 按 ...

有的操作手册可能就够看上一天的了。。。操作手册只能作为参考吧，个人觉得找相应的开发人员或者最熟悉这个的人了解最主要的功能
其他的和10楼的差不多的考虑。

先明确软件的主要功能，主要测试这些！不过主要是ad-hoc测试！嗬嗬，学习了！

直接找开发的头问他具体要测试的重点是什么，测重点！

1、熟悉软件的整体功能逻辑，并抽取基础功能逻辑
2、与研发、产品确认测试重点、范围
3、不再编写测试计划和用例
4、和测试经理说明情况，申请人力资源支持
5、无人力资源支持，自己加班完成
6、高效进行bug提单
7、测试结束后，报告中重点说明测试时间不足，存在风险。。