x379937330 发表于 2008-1-16 17:01:18

我的做法：
1、在笔记或者纸上简单的写下测试计划(为了防止测试的盲目性),测试用例不用写了,因为有软件的操作说明可以代替测试用例；
2. 用大概1小时的时间去研究软件系统,使自己能够在最短的时间内熟悉系统(可请教开发人员指点);
3. 执行测试,按照性能--功能--界面,进行测试;
4、记录bug并登陆；
4、提交测试报告;

wtucel 发表于 2008-1-16 20:43:09

LZ的这个假设有点意思，而现实中会出现这种情况的条件一般为：你已经对这个软件系统非常熟悉了，该版本为这个软件基线的持续版本。
如果是遇到这种情况我的做法就是：
1、仔细阅读需求说明书，对需求的理解跟开发、SE达成一致。
2、对软件新增功能进行测试
3、跟开发沟通，对新增功能可能影响的其他功能进行测试
4、对该软件系统主要流程进行回归测试（一般使用自动化）

这么短的时间我觉得写测试计划、测试用例是没有必要的，可以写一个测试清单，列出测试过的功能点
另外，在测试报告中一定要阐述软件所存在的风险

ccsosemail 发表于 2008-1-21 16:45:12

这种情况下不必写出测试用例，相信即使是写用例，也不是一天可以完成的。
1.在安装的过程中通读一下该软件的操作手册，明确该软件的基本功能，以及怎样正确操作这个软件。
2.将软件所有的基本功能都要操作一次，用以检查基本功能的可用性。如果一个软件连最起码定义的功能都没有实现，那么下一步的测试就没有必要了。
3.在输入错误的测试数据的情况下，软件的基本功能是否可以正常运行
4.在操作的过程中详细记录发现的问题，以及发现问题的时候的操作及数据

做完以上四步，一天也差不多就要过去了，最后就是总结了，在总结中一定要指出在这么短的时间内不可能做特别详尽的测试，且并指出重点测试的是哪个部分，在什么情况下发现了哪些问题。

[ 本帖最后由 ccsosemail 于 2008-1-21 16:46 编辑 ]

satires 发表于 2008-1-23 18:02:24

能写出用户手册就说明程序已经能跑通了，现在最关键的应该是读用户手册，重点测测功能流程重要的部份

liran 发表于 2008-1-25 15:43:23

你牛完成的

一天时间你就能做这些吗.看来是高手,测试脚本,用例都完成,在提交测试报告.你牛

freash 发表于 2008-1-28 12:18:34

原帖由 ccsosemail 于 2008-1-21 16:45 发表 http://bbs.51testing.com/images/common/back.gif
这种情况下不必写出测试用例，相信即使是写用例，也不是一天可以完成的。
1.在安装的过程中通读一下该软件的操作手册，明确该软件的基本功能，以及怎样正确操作这个软件。
2.将软件所有的基本功能都要操作一次，用 ...
觉得这样的建议最好不过了！那么短的时间，就不要写东西了，但是测试的时候，心里一定要有个重点，步骤也要很明确

maxhoo8003 发表于 2008-1-29 12:12:53

如此这般

1 看完软件需求：系统功能实现
2 主要业务流程
3 找开发人员给你演示下流程
4 自己熟悉一边（开发在）
6 开始测试。。。。
TD 管理缺陷！

junqinghuang 发表于 2008-1-29 15:33:43

一般来讲这种测试为最后的封版测试或者验收测试，当然是黑盒测试
执行测试的前提条件：测试环境必须已经配置完毕，且系统可正常运行。
1，根据手册和与需求人员的沟通，了解主业务流程和系统主模块，了解经典业务流程，其他细枝末节不用关注，形成电子文档（我喜欢用visio绘制业务流程草稿图）
2，粗略定制测试计划，做到时间安排心中有数
3，根据测试量，申请测试资源，主要是人手
4，按照主流程执行测试，测试时业务流程图中补充主要说明
5，形成测试报告文档，说明存在的风险，以及时间的不足性

sunlun98 发表于 2008-2-20 14:30:12

从需求中找出测试的侧重点来，根据优先级高低进行测试测试，毕竟时间紧张，详细情况可以在测试报告中列出。

庖丁解牛 发表于 2008-2-20 16:04:48

有没有试过Exploratory testing？就是要解决这种问题的pattern

泰德李 发表于 2008-2-20 16:38:47

花两个小时看用户手册，然后随机测试，找出严重的影响用户操作的bug

xxcat9901 发表于 2008-2-20 17:02:52

1.首先一定要尽量熟悉软件的功能点以及输出，
2.根据功能点做一个基线测试，
3.在覆盖所有功能点的基线测试上，考虑其他情况做增量测试。

zhoumoya 发表于 2008-3-7 08:30:42

我感觉，因为时间太紧，所以应该从一个用户的角度出发，尽量找出用户最常用到的功能的bug，做完了这些后，如果有时间可以做一些深入点的Ad-hoc测试。

jiang860718 发表于 2008-3-7 10:10:31

一天的时间应该够用了，我做测试一般就是一天，早上9点到下午4点，中午还休息1个多小时，很多的情况下都是半天一个，一天两个！~

lianger 发表于 2008-3-7 11:58:02

只能凭经验来报BUG了。

rien2128 发表于 2008-3-7 18:12:16

测试时间不充分，这些本身就是有风险的，他给你的时候你就告诉他不可能测试全面。 不过我觉得像这种测试可以从广度上去考虑，不必要从深度去考虑测试，优先考虑重要的模块，客户最需要的功能，保证基本功能就可以了。

红色异端 发表于 2008-3-7 21:21:33

把最主要的功能测试下，业务流程测试下，提交BUG，并在测试报告中说明测试情况，和未完成的功能测试有哪些

风华绝代 发表于 2008-5-4 09:20:05

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

云彩 发表于 2008-5-4 10:39:28

先测试，在总结

zhicl 发表于 2008-5-4 10:59:01

我也会时不进接到一个项目,要求一天内给结果的,但基本都是有针对性的测试,比如客户处报上来一个BUG,开发要求重现问题之类的,或者是旧项目加了一些新功能,如果是一个完整的新项目,一天内怎么着都不可能完成吧,除非这个足够小....
页: 1 2 [3] 4
查看完整版本: 如果某天早上拿到一个软件，只有一天时间测完，你打算怎么测试？