但是最基本上要求所有业务流程都要跑通。使用时没有太过明显的延时，不会经常出现数据库报错等情况。
时间来不急，就拿着流程图和需求测吧。分清主次，凭经验了。代码出来就按流程跑下。bug就截图，标注发生页面，不写步骤了。直接截图快些。验证如果是js做的,就去看看方法。那就靠经验了。测试数据就自己来，直接在数据库插。一句话，靠自己。
上面只是自己能做的，实际情况，如果是公家单位，就不要急。只要能保证基本上能用，就是我上述的标准，拖到最后，也就完工了。 原帖由 yoyoalphax 于 2009-4-13 13:21 发表 http://bbs.51testing.com/images/common/back.gif
这个回答貌似偏向于评审需求分析吧，并不完全是讨论测试策略吧
还有这句话..:测试不是提高质量，而是降低风险的手段之一
用既..也..是不是比较恰当？毕竟，说测试不是提高质量有点说不过去...质量的定义不是物 ...
不是评审需求分析，测试人员参加需求分析的评审，其主要目的是帮助需求文档去除二义性，并提高其可测试性，对不可测试的需求尽早发现，并建议采用其他方式，如设计评审等来控制
另外关于“测试不能够提高质量，而是降低风险的手段”，那是因为产品的质量无论是从前，还是现在都是源于设计，它从设计开发人员手中出生的那一刻，就已经决定了其品质的好坏，测试只能帮助把它出问题的风险降低到可控制的范围内 路过，留下几笔
http://www.51testing.com/?uid-47068-action-viewspace-itemid-117069 :( 貌似碰到下午客户说要需求，明天就要给他们。当然这是maintain的。加上中美的12小时时差，能挤的几乎全用上了。 测试过程中，这个问题比较突出
成本与完全测试是矛盾的，在当这种情况下，同意2＃的观点，测试的重点是软件是否实现了客户的需求，所以将客户的需求整成列表，按工作量和优先级（影响范围）进行分类。优先测试高优先级，高影响范围的功能
如果是时间短，刚可多人并行工作，如果是硬件问题，则要再投入硬件成本
呵呵，虽然进度紧急，但测试人员还是要坚守测试原则的。 看贴学知识.
全方位管控这个问题
首先，我觉得这个问题是一个非常具有现实意义的问题，特别是国内企业，这类问题很严重，相对国外企业项目也会遇到这类问题，但是相对而言更容易解决。基本上在任何一个项目都没有说是人员充足，时间充足的，这个永远都是多多益善。主要谈一下我自己的经验和看法：在进度较紧、资源也不是十分充足的情况下，如何开展测试工作1.对外部，对客户，如果这个项目是在某个时期才发现时间紧迫，或者出现什么问题才导致这个时间相当紧迫的，那首先第一点，我们要让客户经理，拖住客户，向客户那边找各种理由多要时间，当然，不一定要告诉客户我们真正的困难，因为也许你说出来，客户更要着急。即使不能拖时间，也要最起码不让客户再压缩时间。如果是非常正规的客户，你们也是非常正规的大公司，在和另外一个公司合作，真的有问题，而且很难隐藏的住，那就跟客户明说，并且寻求客户的帮助，很多国外大公司还是相当开明的，并且喜欢坦诚的这种合作，喜欢共同克服问题，这样效益也是最高的。当然这个看具体情况。这个做目的是稳住客户
2. 对内，分3部分看：
1）向领导说明情况（后面会提到不少问题需要老板知道，并且决定，需要首先跟你的老板说明情况）。然后在继续要人手，当然，你要确保人手进来要能提高进度，而不是延慢进度，带来更多问题，最好心有某些人选，无论给不给，先要再说。
2）对开发团队，要求开发协助，开发人员其实很清楚自己的程序那个地方可能有问题，让他们自己说出来，省的你去找了。然后同时需要问开发很多具体的问题，这个我们下面谈测试团队内部问题是会涉及到和开发的合作。这里目的先跟开发打好招呼，需要分一定时间你们合作，到时候不能让他们赖掉。同时跟QA团队也打好招呼，先预告有问题了，在下面具体的论述中我说明谈啥内容。
3）对测试团队内部的处理，这个是重点：
a).首先我们需要搞清楚，我们处理这类问题的原理，我们的目标是我们要在这，比如剩下的1各月时间内，产生最大的效益。同样的一个月，也许我们以前能发现60%的缺陷，假设其中缺陷严重从最严重到最不严重的程度比例是(1:3:6)，那现在我们的目标是，能够发现70%的缺陷，缺陷的比例是(1.5:4:4.5)，就是说达到投入产出比例最高，尽量把所有最严重的问题都能找出来，这个是我们的目的。然后剩下30%的缺陷没有发现怎么办？没关系，首先他不够严重，我们遗留下来的缺陷，是那些客户绝对不会在刚上线使用的前，比如1个月之内会发现的缺陷，我们可以利用上线之后1个月的时间，继续测试这个项目，找出剩下的20%，然后打补丁过去，在客户还没有完全发现这些缺陷之前，我们这个补丁包过去就全部搞定了。当然这个过程需要老板审批，老板决定后面上线后能继续留出多少时间来给这个系统测试，这个也需要先跟老板打好招呼。然后如何做到，下面说具体的方法：
b). 根据80-20原理，80%的重要缺陷是发现在20%的代码中的，实际中可能不是完全一致。但是这对我们打到最高的效益有相当的指导意义。
c). 分析历史数据，或者从QA那里得到相关的数据，查看同类型的产品，或者本产品的以前版本，发现的各种类型的缺陷的分布，然后和我们当前的测试数据比较，看看我们的具体的未发现的问题主要可能在什么地方，然后重点测试。这里其实能分析出来的问题非常多，具体内容可以单独另辟文章讨论
d). 和系统分析员、开发负责人一起分析，各个模块的重要性，哪些地方关联度最高，缺陷影响最大，这些地方一定要测试。就是把模块按照重要程度排序，然后测试顺序按照这个顺序测试，这可以保证测试完最重要的模块，和主流程。和需求人员、维护人员沟通，找出以前的上线版本经常出现的问题，现在尽早关注搞定。
e). 测试过程，指导测试人员，对于某些非主流程模块，小缺陷不需要写入缺陷库，找出来记住就好了，不影响功能的话，不写，直接写影响功能的缺陷，因为写缺陷还是消耗不少时间的，还有有些缺陷是否可以直接跟开发讲，自己同时记下来，但是不写到缺陷库，我这里是说可以考虑这么做，但是这样的话对后期的缺陷分析有一点问题，后期也可以补充，这些方法可以考虑，自己权衡
f). 跟项目总负责人，QA打好招呼，裁剪流程，某些不必要的文档工作，先等等再说，文档的中间过程可以尽量省略，但是最后的重要讨论结果最好记录
g). 项目进行过程中，注重沟通而不是文档，加强口头沟通，并加强沟通效率，面对面的沟通能减少很多非必要的时间消耗，并且问题说明的更加清楚。这个刚开始要和开发负责人打好招呼，否则这么多沟通，人家不一定愿意，可能他会认为这样浪费了他们时间，这个一定要达成共识，当然，你确实要保证沟通高效
h). 优化项目内部测试人员安排， 一般情况下，我们都是经验丰富的人，能力强的人做比较复杂的模块，能力一般的人，做简单的模块，这时候，我们可以考虑时间效益，是否需要让一个能力强的对业务熟悉去做相对简单的模块，这样可能只需要50%的时间，让那个能力一般的做难的部分，可能只多用30%的时间，这样你还多赚了20%的时间。尽管有一定风险，但是你可以考虑，这里我只是说考虑这些因素，考虑优化人员的安排。
i). 以前可能测试人员对业务的了解都需要看需求文档等等，但是，在目前时间紧迫的情况下，可以考虑直接让需求人员来讲解，然后测试理解，再复述给需求人员听，然后需求人员再问他们问题，通过这种方式来确保对业务的理解，同样对开发也是尽量多口头沟通，少书面沟通。
3. 以上步骤，同步进行，自己作为项目测试负责人，一定要心里有谱，同时尽量放权，让每个人责任清晰明确，意识到当前的形势，尽早反馈他们发现的问题，提出各类风险。自己做主要掌控全局的人，同时抽查各个地方的质量。
总体就这么多吧，实际操作完全看个人能力和以前对队伍的培养了。因为平时是流程起作用，但是流程的弹性不够，关键时刻一定是人的因素更重要，
[ 本帖最后由 allenzgw 于 2009-4-16 16:57 编辑 ] 1、增加人手，合理分工
2、邀请研发人员参于测试
3、关注主要业务流程的实现
回复 16# 的帖子
主要的问题是在于不是每个公司都会很重视测试工作的，有的公司在做项目需求分析、概要设计包括详细设计，都不让测试人员参与，包括测试计划都是由开发人员在编写，就相当于开发人员根本就没有把测试放在眼里，等系统做好了，就直接把系统扔给测试人员，说了大体的功能，测试人员就开始盲目的测试了！ 我个人看来，这个是需要根据当前情况，客户最关心的问题测试，还有就是行业的几个测试标准符合就可以了 一、客户1.企业80%的利润来自20%的客户，看是哪类客户吧，这个是从利润角度考虑，从信誉角度考虑当然是个个重要了。
2.事先跟客户沟通，让客户参与裁决什么才是他们最急最重要最关心的功能及其他功能优先级别排序，也可完成重要功能，以后通过补丁提交次要功能。
二、流程
时间统筹安排，能尽早开始测试的不等最后累计一起测试，一些准备工作事先做好，万事俱备，只欠东风嘛。
三、协调
1.与其他部门协调调动人员参与测试。
2.合理分工，正确的人做正确的，各取所长。
3.沟通。与本部门及其他部门完美沟通，避免因沟通不畅产生的效率低下及工作重复。
四、积累
重要模块及易出错模块重点测试，开发个人易犯错习惯等重点测试
效率至上，实在不行，加班吧~:P
但是不管怎么样，与上级沟通目前存在的问题及采取某种手段后的利弊，让上级心里有数:D 在时间不足的情况下，我的做法：
1.走主干、重要功能流程；2.覆盖常见错误点（经验）；3.对些常规性不太重要的功能点略去；4.延迟使用更改bug后的版本；5.使用以前的用例，缺陷报告；6.一定要注意适度，适可而止，不要死钻牛角尖。
学习。。
原帖由 kuailederen 于 2009-4-8 10:54 发表 http://bbs.51testing.com/images/common/back.gif看了大家的回答，我后面讲述了自己的一个亲身经历
这个问题很含糊，缺少背景，不好回答。如同问题：早上起晚了，时间比较紧张，交通又不是很方便，那我应该怎么去上班？
原问题：有一个测试项目马上上线，时间比 ...
经验之谈，学习在学习
个人的一些看法
有些问题，我们作为测试人员本身来说，不用看的太复杂了，讨论的话题是：进度紧张，资源也不是十分充足的情况下，如何开展工作，我现就个人的看法阐述如下，一家之言，不求苟同1.这里的资源也不是十分充足，那么我们首先需要搞清楚，我们自己有的资源是哪些，理论上来说，测试初始的入口文件应该有一个作为上流入口的软件需求规格说明书，并且是已经通过了会议评审通过了的
2.如果可以召集到该项目的客户人员或者客户代表人员，则应该在软件开发的技术人员，测试人员，市场人员，项目经理，测试经理等人的参与下，形成对需求的优先级，重要级进行划分，有的朋友可能会说，你怎么能自己来对需求进行这些划分呢？对，不错，但是，如果我是站在用户的角度呢？测试本身来说不也就是站在用户的角度来对系统或者说软件来进行测试的活动吗？
3.在进行了前面两项的工作后，在于我看来就可以进行测试的相关活动了，比如：测试策略报告的书写，测试的功能特性的用例覆盖情况分析，功能测试矩阵的生产和维护，需求变更对 现行测试的功能特性的影响分析等
4.测试不是来保证产品的质量的，这个相信朋友们会赞成我的，那么在做 了以上的工作后，怎样来尽可能的减低产品上线后的风险呢？我个人的建议是：在产品上线前至少两天，负责管理该项目测试活动的负责人像该项目的项目经理报告该项目现今测试中发现的问题及状态，是closed.fixed还是reopen并对不是closed状态的BUG存在的风险做分析说明，由项目经理确定该项目是否是如期上线，还是寻求市场部门的业务人员进行沟通推迟上线时间等方式
总之作为测试人员在这样的情况下，尽到自己的职责就问心无愧了
以上纯属个人观点，请不惜赐教 刚刚经历了这种情况，只能用一句话说无奈 学习Ing.. 如果是进行回归测试的话，我觉得可以按一下的顺序来考虑：
1.考虑完全重复测试
2.考虑周边影响法
3.如果无法分析对其他模块的影响就考虑覆盖修改法
4.如果没办法分析开发修改的特性就考虑指标达成法的最简单的方法：根据所有用例的百分比来进行执行那些用例，当然这是最无奈的方法）
当然指标达成法也可以覆盖修改和周边影响法搭配使用 受益匪浅 坐以待毙肯定是不行的：
1.争取前期介入
2.争取测试人力资源
3.争取开发资源
4.遴选测试重点
5.选择以往积累的测试脚本开展自动化测试
6.测试报告实话实说
