51Testing软件测试论坛

标题: 时间很紧的情况下，如何做测试计划 [打印本页]

作者: softhome 时间: 2010-8-27 19:03
标题: 时间很紧的情况下，如何做测试计划
最近负责一个项目的测试

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

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

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

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

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

（注：手下没有固定的member, 需要随时找主管借人）

作者: msnshow 时间: 2010-8-27 22:48
手下没有固定的成员那就更需要做好测试计划了

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

作者: susan0605a 时间: 2010-8-29 22:38
人手安排也是规避风险的一种，如果自己做leader，其实最好就是自己只负责25%-40%的测试工作，否则自己压力太大也没有精力看看整体测试

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

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

作者: archonwang 时间: 2010-9-1 10:28
这个应该是变更控制的问题。

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

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

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

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

作者: softhome 时间: 2010-9-1 14:51
标题: 回复 4# 的帖子
谢谢，我会跟老板提这个问题

作者: softhome 时间: 2010-9-1 14:53
标题: 回复 5# 的帖子
这个确实，由于新加入的人员不太熟悉，也抓不住测试重点，所以测试进度也很慢，我需要花时间来教他如何测试，搞得自己也很累。

作者: softhome 时间: 2010-9-1 14:55
标题: 回复 6# 的帖子
请问下什么是MIT 方法测试？有什么好的书籍或资料推荐吗？

作者: softhome 时间: 2010-9-1 15:04
谢谢大家的回复！

作者: archonwang 时间: 2010-9-1 15:44
软件度量，好像是一个微软的测试主管写得。国内有译本。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
计划是很重要的,另外沟通也是很重要的:
计划的时候涉及到预估工作量，同时也是找主管沟通要人的一个关键依据。另外我觉得如果是在规定时间内没有办法完成的，要找原因，是人力资源还是时间进度紧张造成的漏测。
发现很多企业都是想要马儿跑得快，又想马儿不吃草的。

作者: yvon_ren 时间: 2010-9-10 16:08
我曾经也做过一个简单的测试计划，基本上就抽取了几个重要的计划项，然后列成一张excel表。
希望对你有帮助。

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

作者: yzylion 时间: 2010-9-11 13:57
个人观点，欢迎拍砖

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

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

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

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

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

作者: lamuda 时间: 2010-9-11 15:22
没有做好风险分析，如果改动较大，应该做要性能测试的。这也的确是计划没有做好。

作者: heporen 时间: 2010-9-13 09:07
标题: 学习
学习学习学习

作者: softhome 时间: 2010-9-14 10:50
标题: 回复 14# 的帖子
谢谢你中肯的建议。

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

作者: feihushenjun 时间: 2023-1-13 09:55
不如这么问，如何在1秒内做出测试计划

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