在进度较紧、资源也不是十分充足的情况下，如何开展测试工作？

首先，这个问题是一个非常具有现实意义的问题，特别是国内企业，这类问题很严重，相对国外企业项目也会遇到这类问题，但是相对而言更容易解决。基本上在任何一个项目都没有说是人员充足，时间充足的，这个永远都是多多益善。主要谈一下我自己的经验和看法：在进度较紧、资源也不是十分充足的情况下，如何开展测试工作？

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、以上步骤，同步进行，自己作为项目测试负责人，一定要心里有谱，同时尽量放权，让每个人责任清晰明确，意识到当前的形势，尽早反馈他们发现的问题，提出各类风险。自己做主要掌控全局的人，同时抽查各个地方的质量。

总体这么多吧，实际操作完全看个人能力和以前对队伍的培养了。因为平时是流程起作用，但是流程的弹性不够，关键时刻一定是人的因素更重要。