如果某天早上拿到一个软件，只有一天时间测完，你打算怎么测试？
如果某天早上拿到一个软件，只有一天时间测完，你打算怎么测试？之前毫无提示。
只有一天时间测完。
有操作文档。有安装软件。
测试完毕提交测试报告。
·该软件有比较复杂的逻辑关系。
·涉及到数据库，数据的新增、修改、删除等。
请问你打算怎么安排测试工作呢？
测试计划？
测试用例？
如果写测试用例，时间可能来不及。
如果不写，难以保证覆盖度？
。。。
[ 本帖最后由 风华绝代 于 2007-9-24 11:54 编辑 ] 太无聊了嘛？ 太无聊了嘛？
都升级了～仍然没人来～ 我问的问题有那么差嘛？ 测试一天，下班前提一堆bug
开发去加班吧 原帖由 null2 于 2007-9-26 09:17 发表 http://bbs.51testing.com/images/common/back.gif
测试一天，下班前提一堆bug
开发去加班吧
是不是太坏了阿，呵呵
会有这样的情况吗？ 遇到这种情况我的做法：
1、不写测试计划和测试用例；
2、直接进行测试，不用担心漏测，因为时间、资源不足不可能不漏测；
3、尽量多的发现问题，无论大小都要明确记录；
4、提交报告时指出1天测试资源远远不足，因此仅进行了某某测试，发现了某某bug，软件中还可能存在哪些风险，如果要想进行完整测试还需要多少时间等资源。 LS的做法很好 7楼说得有道理的说！ 测试计划肯定是来不及写了，不过测试用例要写个简要的，
1. 首先尽快看完操作手册，要知道这个软件的大体功能,确定软件的最有价值的功能,
2. 写出主要功能的检查列表,如果不谢很可能测试过程中就落下了某项
3. 按照功能检查列表执行测试, 发现问题及时记录,
回复 1# 的帖子
1、不写用例，直接测试2、尽可能多的发现问题，并提交bug
3、提交测试报告，并附带相关风险评估 <1>Review需求文档
<2>根据业务流程，设计测试用例。确保主要功能实现。 扔进厕所里~nnd~那还测毛啊~ 按照功能模块，进行Free test
比较同意10# 兄弟的做法。
测试计划肯定是来不及写了，不过测试用例要写个简要的，1. 首先尽快看完操作手册，要知道这个软件的大体功能,确定软件的最有价值的功能,
2. 写出主要功能的检查列表,如果不谢很可能测试过程中就落下了某项
3. 按照功能检查列表执行测试, 发现问题及时记录,
另外，补充一点点，就是要做好一天的详细计划，细到小时、半小时，甚至可以细到分钟级别。
越是时间紧，做好计划的重要性就要明显。
例如，花多长时间看完需求、功能描述；然后，花多长时间做好功能检查列表；如果有时间，最好能写个简单的测试用例，哪怕只有用例标题也好。 之后，有了对软件的功能了解、测试用例，后面的测试执行过程就会稍微感到轻松些。 还要留好一定的时间和开发交流BUG（提交上去只是完成了测试的一部分，重要的是BUG的最终解决），并让开发有一定的时间解决BUG（哪怕是开发晚上加班解决）。 这样，经过一天的奋战，相信这个软件拿出去也不会有超低级的问题出现。
以上是本人的看法，欢迎大家讨论。 呵呵。。。。。。:) 1.阅读文档.清楚流程,和用户主要运用的模块.(因为这样急的软件,一定不会所有某块一起全部马上就用,大部分是先让用户试着使用,一边使用,一边开发修改)
2.根据对文档,流程的掌握情况进行测试,最好是根据流程一步步地进行.那出错马上向开发组提交问题,让其进行修改这样会节省出很多时间.
3.如要提交测试总结,那么就大致的说明在流程的那个位子出现问题,并说明开发组是否解决.
噢了:victory: 高手如云,齐心解决大家的问题,不错!@ 1，不写测试计划，
2，对软件进行详细熟悉，去跟研发进行沟通，
3，挑选重要的功能模块进行测试，测试后进行纪录，
4，整理记录写成用例，分析用例
5，再次筛选重要的或者不明确用例进行测试。
6，编写bug报告，并给经理解释这样的测试的危险性 1，一天时间是测试完就要交付了吗？如果是这样话，测试没有任何意义了，只是走个形式，怎么走都可以。
2，如果不是，同意上面各位大大侠的意见
