1. 确定系统测试的优先级，对关键功能、系统卖点等模块集中80%的资源进行测试，剩下20%的资源用于尽可能地提高测试覆盖率。
2. 尽量与客户协调时间，如果是产品交付日期但不是最终上市日期，可以尽可能地争取先交付关键部分，剩余部分迟些再交付。
3. 条件允许的情况下打打攻坚战，比如加班加点，当然后期团队激励要做好，不然下次就没有那么积极地加班了。
4. 做好后期的维护和问题收集工作。
明确被测需求
明确功能点
明确人手，
合理分工，
加班加点
。。。。。。。
加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班加班:sleepy:
一、快速测试（敏捷测试）
1、充分理解需求，其实这个不用说————发现需求问题
2、准备好自己的checklist，请项目组成员review。注意只是写出来，不一定按这个来执行测试。————发现自己的测试设计问题
3、测试已业务流程为主线，功能点为辅；业务流程首先保证正常流程，然后再看异常流程的处理————
4、了解代码逻辑和实现方式以及对特殊情况的处理方法，这个可以问开发人员，。————提前发现一些逻辑上的问题
5、了解各部分代码或者各功能之间的关联，可以问开发人员。————bug集群的问题以及debug后的验证
6、测试方法的优化，这个没法细说，只能在实践中随机应变。不过这个能力是可以培养的，事前计划，事后总结，bug分析，都是可以的
7、第一轮测试完后，写个总结，总结自己测试哪些功能点，哪些业务流程，发现了哪些问题，bug优先级以及原因分析。同时之前写的checklist对照一下，看是否有遗漏什么的。
二、smoking test
不要急着去测试，部署好环境后，看看checklist，找一些关联性比较强的功能、主要的业务流程、基础性的功能做个冒烟测试。确保自己的测试能顺利进行，同时也减少了重复劳动，节约时间。
三、ad-hoc（随机测试）
所有发现的bug都修复（或其他方式处理）并测试后，不要着急给出测试结果。做个ad hoc先，ad hoc其实没啥依据，没有特定方法。建议根据bug的产生原因去找找该测试的地方，看看功能点的异常处理情况。
四、风险分析和控制
1、checklist的时候应该能评估一些风险并决定自己在测试的时候是否去考虑测试并模拟——业务问题，开发的技术实现问题
2、测试过程的风险，这个是对自己做的checklist和测试方法的一个评估，语拙，意会
3、运营的风险分析，服务器，性能等
注：未知的问题是风险，已知的问题是缺陷。
最好的方法就是 加班叻
加班
本帖最后由 JackFG 于 2011-8-12 16:22 编辑
1、测试人员是否可以在研发过程中提前介入，加深软件需求熟悉程度，提高测试效率。另外做好需求确认和评审工作，尽量较少需求变更的可能性。
2、是否可以从其他组调配熟练测试人员，增加人数。
3、评估不影响产品测试质量的前提下，是否可以裁减部分测试过程。
4、测试案例最好分级，保证重要功能质量。
5、能否采用迭代模式进行产品开发，测试人员提前介入。
6、做好风险分析，提前把风险规避方法考虑好，以免出现问题才解决，耽误时间。
在执行测试项目的过程当中，经常会遇到项目时间紧迫的情况。例如，项目整体时间紧迫，那么测试时间也会相应减少。或者在项目开展过程中，版本发布日期是确定的，但是由于开发周期延长，也会导致占用测试的时间。这时间不充足的情况下，应该如何保证产品质量，非常值得我们去思考，在工作中，我主要总结了以下几个方面
1.对需求要明确，对需求的优先级也要明确，在项目的过程中就可以少做变更的工作。减少测试的工作量。
2.由资深测试工程师对测试用例进行设计，并进行用例评审。
3.用例要重点覆盖主要功能和主要流程，重点关注存在的严重死机或数据严重丢失等BUG。尽量把所有最严重的问题都能找出来。
4.对以往的BUG进行分析，关注容易出现BUG的模块，例如在程序中有耦合关系的模块等等。
5.与开发团队合用，督促开发尽快关闭已知BUG，加快BUG的收敛。
都是高手，受用了。
1.测试计划：安排好测试时间；
2.测试用例：流程-基本功能点覆盖；
3.根据计划，安排每天任务量，执行用例数，完不成加班；
4.做好测试报告分析。
在测试设备，资源一定的前提下，把testing coverage进行分析，结合以往的不良DATA 进行BREAKDOWN，对不良低的可以舍弃，但需做好记录，QA及时追踪客户端的不良，另对测试时间较长的可否改变测试方法
这需要整个项目组的所有人员大家一起配合
测试方面需要以下几点：
1. 测试经理应该及时向项目经理汇报测试进度，说明测试时间不够的原因，并想方设法的多要点时间。
2. 用例设计方面应着重考虑用户的需求，和用户比较多地需要使用的模块。
3. 加强测试人员之间的沟通交流。
4. 向项目经理详细说明测试工作的重点以及投入使用后可能发现的问题。
5. 针对上述所说的可能发现的问题，在产品投入使用后，尽快拿出解决方案，在用户还未发现前更新产品。
当然，这类问题光有测试部门的高效还是远远不够的，也要项目组其他部门的配合。
1.测试资源：测试度量要明确，需要的工时，人力资源是多少，物力资源是什么
2、测试策略变更：随着测试时间的调整而调整，可以从测试重点和测试测试范围去做调整。
3、加班完成任务了。
写了一篇小文作答如下:handshake：
软件产业迅猛发展，已经渗透到人类社会的各个层面，大到航天军工，小到商店收银，无不有软件的应用。因此这个命题有点大，不同类型的软件，测试特性有所不同，很难以一盖全，这里我只是以一个从事ERP软件测试的人员角度阐述一些观点和实践经验，希望对大家有些许帮助！
1）对时间、成本、质量要有清晰明确的认识。
有过项目经验的人肯定对时间、成本、质量这三轴围成的三角形不陌生，三者是相互作用相互制约的，作为项目管理者希望项目成功，自然要平衡这三要素的关系。时间不充分的前提下，想作好测试工作，这个“好”字就得从项目整体的层面去认识，而不能单纯从质量一条线去衡量了！所以，测试人员有可能接受这样一个背景下的任务时，是不是应该和项目负责人提出一下：如果要力保时间，那么就要在成本上加大投入，另外在质量上必须接受一些瑕疵，我们是不是必须要这样作呢？明确一下我们本次任务的目标到底是什么？如果得到的答案是要抢时间，那么好，我们再去抱怨时间的紧迫就没有意义了，而是应该想一些切实有效的办法来解决这一问题！
2）加大成本。
上一条中我们看到了，如果时间要缩减，质量要求不变的情况下，项目成功度（三角形面积）须要通过加大投入成本来解决，很直接，就是人、财、物！但是那往往这是很理想的状态，绝大多数的情况则是随着时间的不充分，成本同样也不会有过多的追加，否则我们也不会把这个问题作为难点来讨论了。那么我们就只能通过内部挖潜来尝试一下了。
3）需求要对产品有准确的定位和适当的剪裁。
作软件研发业务的最前端，产品定义、需求、设计对产品的成败至关重要，从实践中看，如果前端有一个小环节没有花时间考虑到位，那么后期的编程、测试的过程需要花数倍的时间来返工、弥补，甚至还要承担引发连锁反应的重大风险，因此在测试甚至编程开展之前，需求人员务必把份内工作作足，确保项目需求的准确性和稳定性。同时如果在比较了时间等资源条件与要实现所有功能的工作量之后还是无法平衡，那么就必须作适当有效的剪裁来确保本次开发项目的可完成性。
4）开发人员实现的内容要及时充分印证和验证。
印证是指确保作出的东西是需求要的；验证是指确保作出的东西是可用的、好用的。这方面可以通过各种手段，比如需求验证、单元自测、结对编程、同行评审、和需求测试人员加强沟通等等，原则只有两条：及时、充分。
5）测试的二八法则。
偏向业务的软件产品中，真正核心的流程和场景只占20%，用户往往会把80%的精力放在我们的这20%部分中，对产品的认可度表决权也基于此，因此决定项目是否能顺利验收，产品是否能顺利发布等等，都很大程度取决于此。所以我们在资源不充分的背景下，只能抓大放小，把有限的精力高效利用，找准这20%的重点场景和业务，部署我们80%的测试资源，有侧重的去开展测试业务，作到有的放矢！
6）测试计划的重要性。
往往很多项目一说时间紧，就把计划呀、评审呀这类环节省略了，其实要省时间，即是要敏捷，那么敏捷的朴素思想就是挤掉一切不是必须有的水分，使研发过程LIGHTLY。但是，如果一个环节的省略，会造成后续很大的潜在损失，那么就是必须的环节，因此适当的测试计划我认为恰恰是在短时间保证质量的有效途径，时间紧，则更要求计划作的细，作的好落实，分工给每个测试人员时，大家都很明确自己要作什么、作到什么程度、什么时间作完，同时各项分工整合在一起时还要作到对关键点的全面覆盖、要充分考虑到应变方案以应对可能出现的拖期等意外情况。再有就是在计划中把过程细分成一些关键的里程碑，比如什么时间点把详细需求固化、什么时间把测试方案确定、什么时间进行需求验证等一系列重要的时点，我们管理者在过程的监督和控制上只要抓好这些里程碑，就能比较好的驾驭这个项目，当然里程碑的颗粒度确定要根据项目的实际情况有所区别，量身定制最适合的。另外，计划是否起到良好作用的关键在于执行过程的管理，世间万物都是变化的、唯一不变的就是变化，所以计划中要体现优先级，在执行过程中及时调整，把握好哪些是不能变的，哪些是可以调整可以剪裁掉的，这是非常重要的。
7）风险前置。
开发前期提前实现那些隐患比较大的功能部分，比如基础数据档案、非本部门或本项目组负责的接口方模块、复杂业务逻辑功能点、核心算法和单据、性能要求较高的操作等等，这些内容如在后期发现作的有问题，往往投鼠忌器，修改成本过大，所以这些环节尽量安排提前完成并提交需求、测试人员验证。
8）建立高效的工作流程和沟通机制。
比如站立会议、燃烬图看板、成果演示等敏捷开发的工作方式可以适当尝试，一切以高效顺畅的沟通为底线，当然事情不是不需求讨论，但讨论一定要迅速落实，有了良好的工作流程作保障，会发现很多时间被挤了出来。
9）人的管理。
21世纪什么最贵？人才！只有把人管好用好，事情才谈的上能否作好。首先提升人的能力，通过知识共享、传递、考核等手段，快速把测试人员的能力提升到胜任的水平；第二对人员进行合理的分工安排，关键位置关键人、分组分块、以老带新、男女搭配、交叉测试等各种方式；第三建立适当的授权，充分发挥团队核心人员的作用，一个人的关注度毕竟有限，集权式的管控模式在高效模式下很难运作的好，作为测试经理，如果手下有核心的主测或小组长，只要管好他们就成功大半了，同时有任命必有授权方可名正言顺，如果想基层的负责人顺利开展工作，适度的授权和放权是必须的；第四监督必不可少，没有监督，再多的任务布置都是形同虚设，负责人要在必要的环节、时点作关键的监督，比如抽验等方式对测试人员的工作状态和成果作具体的确认，对好的褒奖，对差的批评指正，累犯不改的害群之马尽早更替；最后还要提的一点是士气很重要，要努力营造一种积极团结，能抗压，爱攻坚的团队氛围，加班虽是捷径但实际上还是工作时间的延长并不是解决时间紧张的途径，而且同时可能会带来人员士气和健康方面的隐患。
10）适度的测试工具引入。
工欲善其事必先利其器，适当引入测试工具代替人工无疑是件提升效率的好事，但一定注意投入产出的平衡，当时间不充分时尤其要考虑这一点，不要费了半天力气好容易把工具用上了，项目时间也所剩无几了，那样的话发挥不了太多作用。也不一定非要用很大而全的商业测试工具，有条件的可以自己开发一些小巧实用却能提升具体某个环节实际工作效率的工具，例如把一些公共可复用的测试用例整合起来作成一个共享的库，通过一些简便快捷的检索和订制就可以生成测试任务的小工具，诸如此类的思想，可以鼓励测试人员作一些创新和尝试，在实践中不断借助工具的力量提高效率。
以上种种，都是在我们实际工作中的一些体会，时间仓促，没有好好整理，很多没想到的地方也欢迎大家补充，希望对大家的测试工作开展有所帮助！
时间紧迫的情况下，
1、首先 需要根据项目的规模去评估下 测试的工作量、测试的进度、人力分配是否充足合理
2、考虑到测试过程中遇到的风险（比如：版本发布延迟、修复BUG产生大量新BUG的预防措施、需求变更
频繁导致测试人员无法及时获取新需求、测试人员对系统了解不够深入、系统业务逻辑复杂）等等
3、如果是一个人测试负责整个项目的话 梳理清楚 （业务基本流程、重点测试模块、基本功能、异常测试、
组合测试）等逐一去进行测试，由整个业务流程->重点测试模块-->基本功能模块-->异常测试-->组合测试
充分熟悉系统，结合系统功能点和需求说明书 去有效地执行测试
4、如果是多个人测试，合理地去分配人员执行系统测试（测试员A 负责整个流程业务测试、B负责核心功能点测试、C负责基本功能点测试、D负责异常测试、.......）
5、建立一个好的激励措施 提高大家的测试效率，尽量做到少加班 甚至不加班......
安装优先级测，加班，向上级反映情况。加人（不太可能，因为预算有限）
时间不够，那是问题的遗留，并堆积到了测试环节
还是比较赞同12楼的说法。
不错的呢。。我看好你噢！吞噬星空http://www.kanshu.la/
貌似写个测试用例要花好长时间呢一般急的时候还来得及写吗 根据重点和客户比较重视的地方增加人手赶紧加班的测吖！
回复 18# fjstc3441
赞成
