softhome 发表于 2010-8-27 19:03:48

时间很紧的情况下,如何做测试计划

最近负责一个项目的测试

我所供职的公司是属于人家的子公司, 发布的软件包需要母公司确认。 我们这里的说法叫发版。

因为需求的变更,经常会有发版的事情,而每次发版都是在前一版的基础上做新增或修改。 前不久发了一版,结果被母公司退回来了,理由是cpu占用太高,无法使用

我们这边测试的时候,由于时间非常紧,常常是只有1天甚至只有0.5天的测试时间,所以没有仔细想过整体的测试(cpu 在之前都是好的), 这样难免会出现漏测的情况

老板challenge我的理由是: 为什么不做计划? 我对你很失望,早知道应该把你从leader的位置上踢下来!

请问下各位,我应该如何做好测试计划,并有效执行?

(注:手下没有固定的member, 需要随时找主管借人)

msnshow 发表于 2010-8-27 22:48:34

手下没有固定的成员那就更需要做好测试计划了

这样才能借到人,安排好工作,不能需要的时候才去借,那就晚了

susan0605a 发表于 2010-8-29 22:38:22

人手安排也是规避风险的一种,如果自己做leader,其实最好就是自己只负责25%-40%的测试工作,否则自己压力太大 也没有精力看看整体测试

suoyuzishui 发表于 2010-8-31 15:56:01

他们应该早点把需求变更通知你,这样你也可以在他们更改前,就开始做测试计划了。
我没做过管理,但是如果测试人员是最后一个知道需求或需求变更的人,是件很不合理的事。测试的时间在很多情况下本来时间就紧。应该跟开发人员同步。

windshl 发表于 2010-8-31 17:17:32

个人一点看法:
1.尽早了解清楚需求变更情况,根据需求变更情况确定测试范围;
2.对于基准版,整理一些主要的检查点,每次发布新版前回归;
因为时间紧张,要抓住主要功能点,抓大放小,尽量争取固定的Member,测试人员的熟练程度对测试效率影响还是比较大的。

archonwang 发表于 2010-9-1 10:28:10

这个应该是变更控制的问题。

建议是MIT方法测试,保障最重要功能。

另外需注意引入功能自动化校验的方式。

至于计划,个人觉得并不是这类事件的重点。等你拿到版本做计划,测试时间几乎就没有了。

你的boss说的计划对于这么短时间的测试几乎是无能为力的。可能唯一可以做得是:尽早得到相关的发版信息,尽早安排相关工作。但是感觉你那边变更频繁,且上下沟通存在壁垒。。。。

softhome 发表于 2010-9-1 14:51:16

回复 4# 的帖子

谢谢,我会跟老板提这个问题

softhome 发表于 2010-9-1 14:53:09

回复 5# 的帖子

这个确实,由于新加入的人员不太熟悉,也抓不住测试重点,所以测试进度也很慢,我需要花时间来教他如何测试,搞得自己也很累。

softhome 发表于 2010-9-1 14:55:24

回复 6# 的帖子

请问下什么是MIT 方法测试? 有什么好的书籍或资料推荐吗?

softhome 发表于 2010-9-1 15:04:39

谢谢大家的回复!

archonwang 发表于 2010-9-1 15:44:25

软件度量,好像是一个微软的测试主管写得。国内有译本。most important testing

http://www.51testing.com/html/14/n-79114.html

http://www.china-pub.com/35680

[ 本帖最后由 archonwang 于 2010-9-1 15:45 编辑 ]

YangMay 发表于 2010-9-10 14:09:45

计划是很重要的,另外沟通也是很重要的:
计划的时候涉及到预估工作量,同时也是找主管沟通要人的一个关键依据。另外我觉得如果是在规定时间内没有办法完成的,要找原因,是人力资源还是时间进度紧张造成的漏测。
发现很多企业都是想要马儿跑得快,又想马儿不吃草的。

yvon_ren 发表于 2010-9-10 16:08:09

我曾经也做过一个简单的测试计划,基本上就抽取了几个重要的计划项,然后列成一张excel表。
希望对你有帮助。

功能点 准备条件(硬/软件)测试类型描述 测试方法/ 工具 估计用时(min) 人员安排...

yzylion 发表于 2010-9-11 13:57:39

个人观点,欢迎拍砖

我觉得你的问题还是流程的问题,由于需求的变更从而导致你们的发版比较频繁,如果要最初制定一个切实可行的计划是不太可能。

看了楼上的一位朋友有提到,就是因为你手下没有固定的member,所以你要做一个计划,对于这一点我个人是认可的。你也说到,每次变更就是对既有的系统进行新增和修改,那么你最初可以依据现行的系统做一个粗的计算,同时在计划里面做好新增的功能这一块的风险的预防。获的领导的审批同意,这样,到时候你要借人的时候也方便一些,毕竟有领导的支撑不是,呵呵。那么后面就需要跟踪计划的执行情况,作为项目的负责人来说,更多的需要监控项目执行的整体情况,只有这样你才能知道你的计划当前执行的情况,是否需要做调整,需要做什么样的调整吧。

另外,从这次你们总公司发回来的不能接受的原因为cpu占用过高,这个属于性能问题,那么你就要考虑是否可以对版本的变更性能方面如何去验证。这个可以跟功能测试并行执行。不影响功能的测试。只要修改的部分不牵涉到通信协议的变更,脚本能够模拟相应的业务操作,那就是没问题的。

恩,祝楼主好运,有经验了分享。

我QQ是75587880.备注:51testing测试管理计划。
欢迎讨论和指导,谢谢

lamuda 发表于 2010-9-11 15:22:20

没有做好风险分析,如果改动较大,应该做要性能测试的。这也的确是计划没有做好。

heporen 发表于 2010-9-13 09:07:48

学习

学习学习学习

softhome 发表于 2010-9-14 10:50:02

回复 14# 的帖子

谢谢你中肯的建议。

在测试功能的同时,我今后也会加强对性能测试这块的测试力度

feihushenjun 发表于 2023-1-13 09:55:31

不如这么问,如何在1秒内做出测试计划
页: [1]
查看完整版本: 时间很紧的情况下,如何做测试计划