google搜索 站内搜索                 软件测试门户 | 软件测试培训 | 文章资料精选 | 软件测试论坛 | 测试解决方案 | 软件测试博客 | 测试招聘求职 
打印

[讨论] 如果某天早上拿到一个软件,只有一天时间测完,你打算怎么测试?

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

TOP

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

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

TOP

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

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

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

TOP

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

TOP

你牛完成的


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

TOP

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

TOP

如此这般


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

TOP

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

TOP

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

TOP

有没有试过Exploratory testing?就是要解决这种问题的pattern
----------------------------------------------
庖丁在线
http://ds-qa.blogspot.com/

TOP

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

TOP

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

TOP

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

TOP

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

TOP

只能凭经验来报BUG了。
天使想給海豚一個吻,可是海太深暸!
海豚想給天使一個擁抱,可是天太高暸!

TOP

测试时间不充分,这些本身就是有风险的,他给你的时候你就告诉他不可能测试全面。 不过我觉得像这种测试可以从广度上去考虑,不必要从深度去考虑测试,优先考虑重要的模块,客户最需要的功能,保证基本功能就可以了。
¥听风五柳声  窗镜噙孤月  秋雨萧萧落  天寒烟步尘¥ QQ:50745724  MSN:rien2128@hotmail.com

TOP

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

TOP

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

TOP

先测试,在总结
测试以人为本

TOP

我也会时不进接到一个项目,要求一天内给结果的,但基本都是有针对性的测试,比如客户处报上来一个BUG,开发要求重现问题之类的,或者是旧项目加了一些新功能,如果是一个完整的新项目,一天内怎么着都不可能完成吧,除非这个足够小....

TOP

 
当前时区 GMT+8, 现在时间是 2008-12-5 14:46Copyright(C)上海博为峰软件技术有限公司 2001-2007 电话:021-64471599-8017
当您在访问网站、论坛及博客过程中遇到问题时可发送email:webmaster@51testing.com或发送论坛短信至管理员风在吹