51Testing软件测试论坛

标题: 如果某天早上拿到一个软件，只有一天时间测完，你打算怎么测试？ [打印本页]

作者: 风华绝代 时间: 2007-9-24 11:53
标题: 如果某天早上拿到一个软件，只有一天时间测完，你打算怎么测试？
如果某天早上拿到一个软件，只有一天时间测完，你打算怎么测试？

之前毫无提示。
只有一天时间测完。
有操作文档。有安装软件。
测试完毕提交测试报告。

·该软件有比较复杂的逻辑关系。
·涉及到数据库，数据的新增、修改、删除等。

请问你打算怎么安排测试工作呢？

测试计划？
测试用例？
如果写测试用例，时间可能来不及。
如果不写，难以保证覆盖度？
。。。

[ 本帖最后由风华绝代于 2007-9-24 11:54 编辑 ]

作者: 风华绝代 时间: 2007-9-24 13:33
太无聊了嘛？

作者: 风华绝代 时间: 2007-9-26 09:05
太无聊了嘛？
都升级了～仍然没人来～

作者: 风华绝代 时间: 2007-9-26 09:05
我问的问题有那么差嘛？

作者: null2 时间: 2007-9-26 09:17
测试一天，下班前提一堆bug
开发去加班吧

作者: ellse 时间: 2007-9-26 10:07

原帖由 null2 于 2007-9-26 09:17 发表
测试一天，下班前提一堆bug
开发去加班吧

是不是太坏了阿，呵呵
会有这样的情况吗？

作者: davy_chen 时间: 2007-9-26 10:18
遇到这种情况我的做法：
1、不写测试计划和测试用例；
2、直接进行测试，不用担心漏测，因为时间、资源不足不可能不漏测；
3、尽量多的发现问题，无论大小都要明确记录；
4、提交报告时指出1天测试资源远远不足，因此仅进行了某某测试，发现了某某bug，软件中还可能存在哪些风险，如果要想进行完整测试还需要多少时间等资源。

作者: lichongjiao 时间: 2007-9-26 14:21
LS的做法很好

作者: luhf0129 时间: 2007-9-26 17:04
7楼说得有道理的说！

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

作者: Sayid 时间: 2007-9-27 10:11
标题: 回复 1# 的帖子
1、不写用例，直接测试
2、尽可能多的发现问题，并提交bug
3、提交测试报告，并附带相关风险评估

作者: Ramon22 时间: 2007-9-27 15:58
<1>Review需求文档
<2>根据业务流程，设计测试用例。确保主要功能实现。

作者: dabeixiong 时间: 2007-9-27 18:04
扔进厕所里~nnd~那还测毛啊~

作者: xyxykitty 时间: 2007-9-28 13:27
按照功能模块，进行Free test

作者: cuizhihui 时间: 2007-9-28 15:35
标题: 比较同意10# 兄弟的做法。
测试计划肯定是来不及写了，不过测试用例要写个简要的，
1. 首先尽快看完操作手册，要知道这个软件的大体功能,确定软件的最有价值的功能,
2. 写出主要功能的检查列表,如果不谢很可能测试过程中就落下了某项
3. 按照功能检查列表执行测试, 发现问题及时记录,

另外，补充一点点，就是要做好一天的详细计划，细到小时、半小时，甚至可以细到分钟级别。
越是时间紧，做好计划的重要性就要明显。

例如，花多长时间看完需求、功能描述；然后，花多长时间做好功能检查列表；如果有时间，最好能写个简单的测试用例，哪怕只有用例标题也好。之后，有了对软件的功能了解、测试用例，后面的测试执行过程就会稍微感到轻松些。还要留好一定的时间和开发交流BUG（提交上去只是完成了测试的一部分，重要的是BUG的最终解决），并让开发有一定的时间解决BUG（哪怕是开发晚上加班解决）。这样，经过一天的奋战，相信这个软件拿出去也不会有超低级的问题出现。

以上是本人的看法，欢迎大家讨论。呵呵。。。。。。

作者: hanyanan1985 时间: 2007-9-28 16:00
1.阅读文档.清楚流程,和用户主要运用的模块.(因为这样急的软件,一定不会所有某块一起全部马上就用,大部分是先让用户试着使用,一边使用,一边开发修改)
2.根据对文档,流程的掌握情况进行测试,最好是根据流程一步步地进行.那出错马上向开发组提交问题,让其进行修改这样会节省出很多时间.
3.如要提交测试总结,那么就大致的说明在流程的那个位子出现问题,并说明开发组是否解决.
噢了

作者: zzytion 时间: 2007-10-8 19:04
高手如云,齐心解决大家的问题,不错!@

作者: jinhouzi 时间: 2007-10-10 18:16
1，不写测试计划，
2，对软件进行详细熟悉，去跟研发进行沟通，
3，挑选重要的功能模块进行测试，测试后进行纪录，
4，整理记录写成用例，分析用例
5，再次筛选重要的或者不明确用例进行测试。
6，编写bug报告，并给经理解释这样的测试的危险性

作者: changh08 时间: 2007-10-17 11:50
1，一天时间是测试完就要交付了吗？如果是这样话，测试没有任何意义了，只是走个形式，怎么走都可以。
2，如果不是，同意上面各位大大侠的意见

作者: xinyuanjishu 时间: 2007-10-17 15:59
标题: 回复 7# 的帖子
不错，说的合理！

作者: bzfyhfyh 时间: 2007-10-27 19:29
我觉得应该凭经验直接测试，进行随即测试。发现bug就提交。在软件测试计划里说明一下。

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

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

还是来不及，就加加班吧

作者: haixiaoxinyuan 时间: 2007-12-14 15:50
非常同意15#

作者: zm_027 时间: 2007-12-25 21:09
直接测试，设想如果你是用户，拿到这个软件后，你会做什么操作，使用什么功能。

作者: zm_027 时间: 2007-12-25 21:09
补充一下：总之就是站在客户的角度来测试

作者: grice_py 时间: 2007-12-26 14:51
个人经验这个时候很有帮助

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

作者: maomao257 时间: 2007-12-26 18:12
不错学习了

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

作者: 学会洒脱 时间: 2007-12-26 20:35

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

说得好...赞同!

作者: fl2397 时间: 2007-12-27 11:37
时间这么短促，只能按经验测

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

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

作者: tiger_86 时间: 2008-1-14 11:36

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

说的是很对的

作者: capricorn 时间: 2008-1-14 18:27
读相关文档写测试用例肯定没有时间去执行了，比较同意davy_chen他的！

作者: annayin 时间: 2008-1-15 12:17

原帖由 hdice 于 2007-9-27 09:56 发表
测试计划肯定是来不及写了，不过测试用例要写个简要的，
1. 首先尽快看完操作手册，要知道这个软件的大体功能,确定软件的最有价值的功能,

2. 写出主要功能的检查列表,如果不谢很可能测试过程中就落下了某项
3. 按 ...

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

作者: blueteer 时间: 2008-1-16 11:02
先明确软件的主要功能，主要测试这些！不过主要是ad-hoc测试！嗬嗬，学习了！

作者: 雅丹咔咔 时间: 2008-1-16 16:34
标题: 7楼+10楼的，差不多了
直接找开发的头问他具体要测试的重点是什么，测重点！

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

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

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

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

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

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

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

作者: satires 时间: 2008-1-23 18:02
能写出用户手册就说明程序已经能跑通了，现在最关键的应该是读用户手册，重点测测功能流程重要的部份

作者: liran 时间: 2008-1-25 15:43
标题: 你牛完成的
一天时间你就能做这些吗.看来是高手,测试脚本,用例都完成,在提交测试报告.你牛

作者: freash 时间: 2008-1-28 12:18

原帖由 ccsosemail 于 2008-1-21 16:45 发表
这种情况下不必写出测试用例，相信即使是写用例，也不是一天可以完成的。
1.在安装的过程中通读一下该软件的操作手册，明确该软件的基本功能，以及怎样正确操作这个软件。
2.将软件所有的基本功能都要操作一次，用 ...

觉得这样的建议最好不过了！那么短的时间，就不要写东西了，但是测试的时候，心里一定要有个重点，步骤也要很明确

作者: maxhoo8003 时间: 2008-1-29 12:12
标题: 如此这般
1 看完软件需求：系统功能实现
2 主要业务流程
3 找开发人员给你演示下流程
4 自己熟悉一边（开发在）
6 开始测试。。。。
TD 管理缺陷！

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

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

作者: 庖丁解牛 时间: 2008-2-20 16:04
有没有试过Exploratory testing？就是要解决这种问题的pattern

作者: 泰德李 时间: 2008-2-20 16:38
花两个小时看用户手册，然后随机测试，找出严重的影响用户操作的bug

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

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

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

作者: lianger 时间: 2008-3-7 11:58
只能凭经验来报BUG了。

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

作者: 红色异端 时间: 2008-3-7 21:21
把最主要的功能测试下，业务流程测试下，提交BUG，并在测试报告中说明测试情况，和未完成的功能测试有哪些

作者: 风华绝代 时间: 2008-5-4 09:20

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

很职业的做法，学习了。

作者: 云彩 时间: 2008-5-4 10:39
先测试，在总结

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

作者: 美元测试 时间: 2008-5-4 11:03

原帖由 风华绝代 于 2008-5-4 09:20 发表

很职业的做法，学习了。

不是吧，你竟然比较喜欢的是这个答案
让我有点失望...
测试时间只有一天，并不代表你提交完BUG测试工作就结束了
发现的BUG如果完全不修复的话（当然时间上可能无法修复所有发现的bug，但对于必须要修复的和决定要修复的总该回归一下吧？）
那这样的话测试的意义在哪里

测试之前和主要开发人员进行短时间的交流是提高测试效率的一个很好方法
毕竟阅读和理解文档需要一定的时间，而且文档本身也有bug呢？
测试计划能免则免，自己大概写个schedule就ok了
测试用例可以以测试点的形式编写
测试执行focus功能测试中的主要功能测试，异常流和组合情况的测试可以考虑的相对少一些
测试报告是必须的，指明测试的实际执行情况以及风险预估

作者: fen_wu799 时间: 2008-5-4 11:16
我们经常遇到这样的情况，我都是直接进行测试，提交bug。
测试计划、用例向来都是聋子的耳朵-----摆设！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)