——————网友kuailederen————————————————————————————
如果测试时间不够，肯定不能全功能覆盖，我们是否应该只测客户比较关心的，比较常用的功能？
——我觉得软件测试是一门需要用科学的精神去对待的学科，结果只有正确的才算科学，过程是需要仔细严谨的对待，而方法可以有多种，但只有一种才是最高效的。所以我们的测试工作是用仔细严谨的态度，去寻找一条最有效的方法，然后把测试工作做的最好，而不会存在模棱两可和含糊的结果。
——作为测试，碰到时间紧张，测试资源欠缺，所唯一能做的是上报公司，让他们协调人工和资源，做延期处理。这样做公司可能因不能如期交付而受到一些经济上的损失，但交付一个合格的产品给客户，绝对不会有信誉上的损失，从长久看，会有更多的收益。作为测试，你没有任何权利自己做风险处理---测“客户关心的，测主要功能”，都是错误的做法。作为测试，坚守住自己的职业道德，只做自己职责范围的工作和力所能及的事；作为测试，不但要为支付给你工资的老板负责，也请为你手中的软件负责，为客户支付的金钱负责。
——————网友allenzgw————————————————————————————
全方位管控这个问题
——对外，与客户沟通，获得客户支持
——对内，与领导沟通，争取资源和支持；与开发人员沟通，要求开发人员协助；至于测试内部有以下几点
b). 根据80-20原理，80%的重要缺陷是发现在20%的代码中的，实际中可能不是完全一致。但是这对我们打到最高的效益有相当的指导意义。
c). 分析历史数据，或者从QA那里得到相关的数据，查看同类型的产品，或者本产品的以前版本，发现的各种类型的缺陷的分布，然后和我们当前的测试数据比较，看看我们的具体的未发现的问题主要可能在什么地方，然后重点测试。这里其实能分析出来的问题非常多，具体内容可以单独另辟文章讨论
d). 和系统分析员、开发负责人一起分析，各个模块的重要性，哪些地方关联度最高，缺陷影响最大，这些地方一定要测试。就是把模块按照重要程度排序，然后测试顺序按照这个顺序测试，这可以保证测试完最重要的模块，和主流程。和需求人员、维护人员沟通，找出以前的上线版本经常出现的问题，现在尽早关注搞定。
e). 测试过程，指导测试人员，对于某些非主流程模块，小缺陷不需要写入缺陷库，找出来记住就好了，不影响功能的话，不写，直接写影响功能的缺陷，因为写缺陷还是消耗不少时间的，还有有些缺陷是否可以直接跟开发讲，自己同时记下来，但是不写到缺陷库，我这里是说可以考虑这么做，但是这样的话对后期的缺陷分析有一点问题，后期也可以补充，这些方法可以考虑，自己权衡
f). 跟项目总负责人，QA打好招呼，裁剪流程，某些不必要的文档工作，先等等再说，文档的中间过程可以尽量省略，但是最后的重要讨论结果最好记录
g). 项目进行过程中，注重沟通而不是文档，加强口头沟通，并加强沟通效率，面对面的沟通能减少很多非必要的时间消耗，并且问题说明的更加清楚。这个刚开始要和开发负责人打好招呼，否则这么多沟通，人家不一定愿意，可能他会认为这样浪费了他们时间，这个一定要达成共识，当然，你确实要保证沟通高效
h). 优化项目内部测试人员安排， 一般情况下，我们都是经验丰富的人，能力强的人做比较复杂的模块，能力一般的人，做简单的模块，这时候，我们可以考虑时间效益，是否需要让一个能力强的对业务熟悉去做相对简单的模块，这样可能只需要50%的时间，让那个能力一般的做难的部分，可能只多用30%的时间，这样你还多赚了20%的时间。尽管有一定风险，但是你可以考虑，这里我只是说考虑这些因素，考虑优化人员的安排。
i). 以前可能测试人员对业务的了解都需要看需求文档等等，但是，在目前时间紧迫的情况下，可以考虑直接让需求人员来讲解，然后测试理解，再复述给需求人员听，然后需求人员再问他们问题，通过这种方式来确保对业务的理解，同样对开发也是尽量多口头沟通，少书面沟通。
c). 分析历史数据，或者从QA那里得到相关的数据，查看同类型的产品，或者本产品的以前版本，发现的各种类型的缺陷的分布，然后和我们当前的测试数据比较，看看我们的具体的未发现的问题主要可能在什么地方，然后重点测试。这里其实能分析出来的问题非常多，具体内容可以单独另辟文章讨论
d). 和系统分析员、开发负责人一起分析，各个模块的重要性，哪些地方关联度最高，缺陷影响最大，这些地方一定要测试。就是把模块按照重要程度排序，然后测试顺序按照这个顺序测试，这可以保证测试完最重要的模块，和主流程。和需求人员、维护人员沟通，找出以前的上线版本经常出现的问题，现在尽早关注搞定。
e). 测试过程，指导测试人员，对于某些非主流程模块，小缺陷不需要写入缺陷库，找出来记住就好了，不影响功能的话，不写，直接写影响功能的缺陷，因为写缺陷还是消耗不少时间的，还有有些缺陷是否可以直接跟开发讲，自己同时记下来，但是不写到缺陷库，我这里是说可以考虑这么做，但是这样的话对后期的缺陷分析有一点问题，后期也可以补充，这些方法可以考虑，自己权衡
f). 跟项目总负责人，QA打好招呼，裁剪流程，某些不必要的文档工作，先等等再说，文档的中间过程可以尽量省略，但是最后的重要讨论结果最好记录
g). 项目进行过程中，注重沟通而不是文档，加强口头沟通，并加强沟通效率，面对面的沟通能减少很多非必要的时间消耗，并且问题说明的更加清楚。这个刚开始要和开发负责人打好招呼，否则这么多沟通，人家不一定愿意，可能他会认为这样浪费了他们时间，这个一定要达成共识，当然，你确实要保证沟通高效
h). 优化项目内部测试人员安排， 一般情况下，我们都是经验丰富的人，能力强的人做比较复杂的模块，能力一般的人，做简单的模块，这时候，我们可以考虑时间效益，是否需要让一个能力强的对业务熟悉去做相对简单的模块，这样可能只需要50%的时间，让那个能力一般的做难的部分，可能只多用30%的时间，这样你还多赚了20%的时间。尽管有一定风险，但是你可以考虑，这里我只是说考虑这些因素，考虑优化人员的安排。
i). 以前可能测试人员对业务的了解都需要看需求文档等等，但是，在目前时间紧迫的情况下，可以考虑直接让需求人员来讲解，然后测试理解，再复述给需求人员听，然后需求人员再问他们问题，通过这种方式来确保对业务的理解，同样对开发也是尽量多口头沟通，少书面沟通。
——————网友yolander————————————————————————————
基于风险的测试策略
其实这是个如何制定测试策略的问题，首先前提假设出来说进度紧，资源不充分，而反过来说即使是在理想条件下，给你足够的资源预留足够的进度，你能做到100%测试么？显而易见的答案，不能！
作为每个测试人员，都要明确这一点“YOU CAN NOT TEST EVERTHING!”，测试不是提高质量，而是降低风险的手段之一，如果项目团队给你的资源不充分，进度紧，OK，那我们一起来做个风险分析吧，而事实上，无论是否资源充分，我们也都需要在制定测试计划前，先做风险分析，再基于风险来制定测试策略，那么这个基于风险分析的测试策略到底是如何制定呢
一、风险分析团队组建：
这时我们需要有两队人马，一队是技术专家，另一队是用户代表（不一定是最终用户、服务人员、市场人员、有经验的资深测试人员都可以担当此角色）
二、风险分析活动流程：
1、首先做需求分析，形成功能列表
2、技术专家为列表中的每一条功能进行评估、打分，至少要考虑如下几条计分项，如：人员经验（新人风险高，有经验的老员工则风险较低），是否采用新技术（全新技术风险高，复用已有技术平台则风险低），该功能的接口和与其他功能的交互性（毫无疑问的，接口和交互越多的，则风险就越高）等等，其他的可以根据需要来自我界定
3、用户代表为列表中的每一条功能进行评估、打分，至少要考虑如下几条计分项，如：失效影响（一旦失效是否有安全隐患？肯定的答案则得分高），商业价值（是否为产品的卖点），用户的使用频率（频率越高，被探测到问题的风险也就越高），如有需要还可以增加计分项
4、将各项分数统计之后，形成风险矩阵，横纵坐标分别为技术风险得分和用户代表评估风险得分，此时，就可以将功能列表中的功能项划分出四种不同的风险区间，两项得分居高的，肯定是测试重点，也是测试力度最应该投入的部分，采取的测试手段也应该是最严谨的，居中的两个区间（分别为高技术风险或者高用户代表评估风险），则可以适当投入力度和资源，风险最低的区间内可以权衡项目的QCD目标来确定要不要投入力度和资源
以上，一切取决于项目团队的集体意见，并非是测试人员一个人要考虑的问题，对于预留风险的接受情况一定是经过集体权衡出来的结果，并不是测试人员的个人职责，也就是说风险要共同分担，质量是掌握在每个人的手里，并非测试人员说了算
三、根据风险矩阵得出测试策略后，再合理分配测试资源投入情况
以上方法适用于所有的项目，并非只有紧急或者资源不足的时候才需要做，因为在任何时候，测试都需要平衡资源投入以提高效率，因为“YOU CAN NOT TEST EVERYTHING”……
作为每个测试人员，都要明确这一点“YOU CAN NOT TEST EVERTHING!”，测试不是提高质量，而是降低风险的手段之一，如果项目团队给你的资源不充分，进度紧，OK，那我们一起来做个风险分析吧，而事实上，无论是否资源充分，我们也都需要在制定测试计划前，先做风险分析，再基于风险来制定测试策略，那么这个基于风险分析的测试策略到底是如何制定呢
一、风险分析团队组建：
这时我们需要有两队人马，一队是技术专家，另一队是用户代表（不一定是最终用户、服务人员、市场人员、有经验的资深测试人员都可以担当此角色）
二、风险分析活动流程：
1、首先做需求分析，形成功能列表
2、技术专家为列表中的每一条功能进行评估、打分，至少要考虑如下几条计分项，如：人员经验（新人风险高，有经验的老员工则风险较低），是否采用新技术（全新技术风险高，复用已有技术平台则风险低），该功能的接口和与其他功能的交互性（毫无疑问的，接口和交互越多的，则风险就越高）等等，其他的可以根据需要来自我界定
3、用户代表为列表中的每一条功能进行评估、打分，至少要考虑如下几条计分项，如：失效影响（一旦失效是否有安全隐患？肯定的答案则得分高），商业价值（是否为产品的卖点），用户的使用频率（频率越高，被探测到问题的风险也就越高），如有需要还可以增加计分项
4、将各项分数统计之后，形成风险矩阵，横纵坐标分别为技术风险得分和用户代表评估风险得分，此时，就可以将功能列表中的功能项划分出四种不同的风险区间，两项得分居高的，肯定是测试重点，也是测试力度最应该投入的部分，采取的测试手段也应该是最严谨的，居中的两个区间（分别为高技术风险或者高用户代表评估风险），则可以适当投入力度和资源，风险最低的区间内可以权衡项目的QCD目标来确定要不要投入力度和资源
以上，一切取决于项目团队的集体意见，并非是测试人员一个人要考虑的问题，对于预留风险的接受情况一定是经过集体权衡出来的结果，并不是测试人员的个人职责，也就是说风险要共同分担，质量是掌握在每个人的手里，并非测试人员说了算
三、根据风险矩阵得出测试策略后，再合理分配测试资源投入情况
以上方法适用于所有的项目，并非只有紧急或者资源不足的时候才需要做，因为在任何时候，测试都需要平衡资源投入以提高效率，因为“YOU CAN NOT TEST EVERYTHING”……
——————网友becky07————————————————————————————
1.对需求要明确，对需求的优先级也要明确，在项目的过程中就可以少做变更的工作。减少测试的工作量。
2.由资深测试工程师对测试用例进行设计，并进行用例评审。
3.用例要重点覆盖主要功能和主要流程，重点关注存在的严重死机或数据严重丢失等BUG。尽量把所有最严重的问题都能找出来。
4.对以往的BUG进行分析，关注容易出现BUG的模块，例如在程序中有耦合关系的模块等等。
5.与开发团队合用，督促开发尽快关闭已知BUG，加快BUG的收敛。
2.由资深测试工程师对测试用例进行设计，并进行用例评审。
3.用例要重点覆盖主要功能和主要流程，重点关注存在的严重死机或数据严重丢失等BUG。尽量把所有最严重的问题都能找出来。
4.对以往的BUG进行分析，关注容易出现BUG的模块，例如在程序中有耦合关系的模块等等。
5.与开发团队合用，督促开发尽快关闭已知BUG，加快BUG的收敛。
