在进度较紧的情况下，如何开展测试工作？（09-04-7）（获奖名单已公布）

默默巫

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

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	allenzgw	当当购物卡50元	29#
二等奖	yolander	300论坛积分	10#
三等奖	kuailederen	100论坛积分	6#

相关文章：

如何在快速变更的环境中开展测试工作

六年测试工作的思考

如何做好测试工作

更多内容请点击＞＞＞

hongyan

在进度较紧而资源也不是十分充足的情况下,个人认为可以先考虑以下几个测试点:
1.分析该项目中,哪些功能是最重要的.
2.哪些功能对用户最明显?用户最关心的是什么?
3.哪些问题对安全问题存在高风险?
4.在开发过程中,哪些功能点可以先进行测试.
5.哪一部分的代码最复杂最容易出错.哪些是在时间比较紧迫的情况下研发出来的.
6.开发人员认为在应用软件中哪些部分是高风险的
7.哪些测试可以容易地覆盖多种功能,
8.哪些测试在覆盖高风险部分的测试时使用时间最少

hutter2006

从问题的本身来看显得提问者有点浮躁，进度紧张到什么程度？资源怎么个不足？这些情况作为回答者都不太清楚，当然，做了这么多的测试项目我也遇到过类似的情况，例如一个中型的旅游网站今天改版好，老板说明天就要上线的情况，测试组3个人，如何在12小时内完成功能测试？（吃个盒饭，睡觉就别想了）
我们需要关注的问题：
1. 网站的主要业务流程要全部跑通（订单的查询、预订、生成、支付、成功出票等）
2. 会员的登录等
3. 积分的计算以及奖励方式等。

另外我想说的是，开展这类测试工作需要结合项目本身的性质。有些小项目完全可以搞定。有些则不然。这个度需要你自己把握好。

luna_jia

进度紧张的情况在做客户项目的时候可能经常遇到，软件交付的时间是定好了的。一个比较无奈的办法是和业务部门或者客户沟通，适当延缓几天，交出一个合格的产品比按时交付有利无害，这对一些比较小的项目可能并不困难，但对一些大的客户，本身对按时交付要求比较严格的，在前期的的需求和开发阶段已经挤占了测试时间的情况下，测试方面能采用的应对方法：
1、关注重点功能，次要功能仅做简单测试，只保证不出现严重错误。比如业务系统主要测试业务操作功能，对基础资料一类的功能适当减少测试时间。
2、保证在正常业务操作下的测试，减少边界测试、非法数据等比较极端的异常测试，异常方面用几条数据稍做测试即可。
3、允许软件中存在并不严重的BUG，不要追求尽善尽美。这些BUG可以暂时不改，或者不做回归测试。可以到系统上线实施的这个缓冲阶段中逐步修复这些早已发现的问题。
4、资源紧张是一个内部的问题。如果能协调其他的人员，比如客服人员等做一些简单的功能、UI方面的测试，开发人员到了测试阶段，任务相对也少一些，可以加强单元测试，让一些BUG不要流到测试这里来。这样都可以减少测试人员本身的一些工作量。
5、超时加班。不过要记得维护自己的合法权益哦。

sogoc

测试按最低标准来测试，也就是输入正常的数据，保存，提交，编辑...等等的操作都不会有错误。不去测试比如：特殊字符，字段长度，输入非法，输入错误等等的反应，整个系统只针对正确输入输入后表现是否正确即可！

[ 本帖最后由 sogoc 于 2009-4-8 10:40 编辑 ]

kuailederen

看了大家的回答，我后面讲述了自己的一个亲身经历

这个问题很含糊，缺少背景，不好回答。如同问题：早上起晚了，时间比较紧张，交通又不是很方便，那我应该怎么去上班？
原问题：有一个测试项目马上上线，时间比较紧张，测试资源又不是十分充分，那我们应该怎么展开测试？
问题解读：
1.早上起晚了，必须是一个比较的结果，说明以往起的要早些。
     同样，这个测试项目的工作，按以往经验需要两个月，而现在只有1个月多 点。
2.时间比较紧张，说明如果顺利的话，还是能够按时上班的。
     同样，测试项目如果顺利的话，少bulid次，也是可以顺利上线的。
3.交通不是很方便，指出准时上班存在的风险，万一我要等的公交车迟迟不来呢？
    同样，测试资源不充分，说明缺少一些测试环境，测试工具，软硬件设施等，导致一些测试工作无从展开。
4.我们怎么去上班呢？这才是问题的关键，只有知道迟到的后果，才决定我们怎么去上班的决心和应该付出怎样的代价。如果上班迟到一次就辞退，那么你必须考虑是否找一位飙车高手载你上班，顺便说服警车为你开道；如果迟到一次，领导会批评你，然后扣100元钱，那么你只需要尽量赶到就行，迟到了只是让领导发发官威，损失点人民币而已；如果迟到不会收到惩罚，那你还担心什么呢？晨练完再去上班吧。
   同样，对这个项目的测试必须有个预期，也就是测试要达到的目标。①如果项目不能延期，而且必须全功能覆盖，那么增加人手来抵消时间紧张，必须去购买（或者其它途径）缺少的测试资源，来满足测试需要；②如果项目可以延期，但也必须全功能覆盖，那么考虑到测试成本，可以不增加人手的前提下稍作延期，但测试资源的投入还是必须的；③如果项目可以延期，而且缺少测试资源的部分非重要功能，本次上线可以不测，那么项目做延期，测试该测的功能就行了。

④如果问题的原意是：项目测试时间明显不够，既不能增加人手，缺少的测试资源肯定不能满足，又要求全功能覆盖，必须按时上线，那我们怎么才能把测试工作做的尽量好呢？
          我的回答是，兄弟跑路吧，这次测试你肯定做不好。如果不想跑路，那么兄弟要雄起一次，大胆的说不。
针对这种情况，可能很多人采取的措施是：在现有的条件下，先从能测的重要的功能测起，在有限的时间里测多少算多少。如同考试一样，
明知道答卷时间不够了，那就先找分多的，容易的做起，蒙上选择题，最后能做多少做多好吧。试问，试卷你可以得50分不及格，那么我们的软件可以不及格吗？试卷上有选择题可以蒙，1/4 的概率，我们的软件功能点只有正确和不正确，1/2的概率，但你能蒙吗？试卷这次不会，回头老师可以答疑，而我们的软件可以答疑吗？
      我觉得软件测试是一门需要用科学的精神去对待的学科，结果只有正确的才算科学，过程是需要仔细严谨的对待，而方法可以有多种，但只有一种才是最高效的。所以我们的测试工作是用仔细严谨的态度，去寻找一条最有效的方法，然后把测试工作做的最好，而不会存在模棱两可和含糊的结果。


我的经历：如果测试时间不够，肯定不能全功能覆盖，我们是否应该只测客户比较关心的，比较常用的功能？
    测试目前主要是产品测试和项目测试。做自己公司的产品测试，如果碰到不能按原计划完成，本着为质量负责，一般都可以申请延期。
如果是做项目，迫于合同和客户验收的压力，碰到不能按原计划完成的情况，就是项目风险了。而处理的方式基本都是“先测客户比较关心的，比较常用的功能”，保证通过客户验收，拿到项目款。分析客户验收所关心的功能点（比如客户最近几天提过什么需求，肯定要测试，因为时间短，他肯定记得），分析系统最脆弱的地方，走通所有业务流程等。而客户验收时候，不关心和不可能想到得地方可以不测试（比如系统中很多同步功能）。

    我讲个自己的经历，做的是国内最大保险公司的一个平台，由几个系统共同构成。由于前期公司为了节约成本，一直投入比较少的资源，到了后期，明显感觉到项目不可能如期完成，更要命的是，测试前期没有跟进，对于这个项目的质量没有任何把握。
   公司处理措施：
1.增加研发人手，由前期三人，增到5人；
2.由我带3名测试人员介入，一名性能测试工程师，开始测试。
3.研发部门经理每天跟进进度。
4。提出延期请求。
   客户态度：
1.对前期项目成果极度不满意，狠批改项目的负责人。
2.为了项目进度，非常配合提供测试环境和资源。
3.一顿脸色后，给出15天的延期许可。

公司接下来的工作：
1.完成未完成的功能和客户新提出的功能。
2.在提供的环境上进行测试。
3.集中处理长期积累的缺陷。
4.集成几个系统。
发现问题：
1.没有良好的需求管理，平时客户开会或邮件发来的需求忘记或者没有完全理解。
2.发现测试进展缓慢，人手不够，不了解需求，缺少测试环境，经常发现严重问题而停止测试，发布新的测试版本。
3.几个系统集成后，发现更多的新问题
4.性能测试结果表明，性能无法达到客户的要求。
  项目进入风险处理期，公司的处理：
1.更换项目经理
2.编造谎话应付客户，说一定能如期交付。
3.指示测试人员（具体说是说），只测试客户关心的功能和主要业务流程。
4.指示测试人员（我），修改测试报告，不合格的功能删除，只写测试通过的功能。
5.指示我修改性能测试数据，说明性能指标基本达到。

测试人员的处理（我）：
1.请示了测试部经理后，按项目经理的要求做了。

项目的结果：
1.交付了一个客户根本无法正常使用的平台，客户暴怒。
2.客户中止了所有与公司的合同，包括结束了持续两年的合作友谊。
3.客户拒付剩余的项目款。
4.公司开除所有参与项目的开发人员，包括项目经理（虽没有影响到测试，但我感觉公司管理混乱，也主动请辞了）。
5.公司失去了一个大客户。

  这是血的教训，对于公司损失的是钱和信誉，对于客户损失的是钱和无限拖延的项目以及产品延期造成的竞争力影响。
对于开发，除了疯狂加班的劳累，还有开除的冤屈；对于测试，没有坚持自己的职业道德。
  我讲述的这个经历，可能大部分的项目都不会发展到这种地步，到我们必须充分意识到风险的存在。所以我觉得作为测试，碰到时间紧张，测试资源欠缺，所唯一能做的是上报公司，让他们协调人工和资源，做延期处理。这样做公司可能因不能如期交付而受到一些经济上的损失，但交付一个合格的产品给客户，绝对不会有信誉上的损失，从长久看，会有更多的收益。作为测试，你没有任何权利自己做风险处理---测“客户关心的，测主要功能”，都是错误的做法。作为测试，坚守住自己的职业道德，只做自己职责范围的工作和力所能及的事；作为测试，不但要为支付给你工资的老板负责，也请为你手中的软件负责，为客户支付的金钱负责。

[ 本帖最后由 kuailederen 于 2009-4-15 16:53 编辑 ]

sn_asd520

个人认为还是能测什么就测什么，如果时间不允许了，那就看那些重要就先测那些

black_tulip

我靠，此类帖子看到现在，六楼 kuailederen 朋友的回帖最高质量！

同样是列12345，此人逻辑最清楚。

yolander

其实这是个如何制定测试策略的问题，首先前提假设出来说进度紧，资源不充分，而反过来说即使是在理想条件下，给你足够的资源预留足够的进度，你能做到100%测试么？显而易见的答案，不能！
作为每个测试人员，都要明确这一点“YOU CAN NOT TEST EVERTHING!”，测试不是提高质量，而是降低风险的手段之一，如果项目团队给你的资源不充分，进度紧，OK，那我们一起来做个风险分析吧，而事实上，无论是否资源充分，我们也都需要在制定测试计划前，先做风险分析，再基于风险来制定测试策略，那么这个基于风险分析的测试策略到底是如何制定呢
一、风险分析团队组建：
这时我们需要有两队人马，一队是技术专家，另一队是用户代表（不一定是最终用户、服务人员、市场人员、有经验的资深测试人员都可以担当此角色）
二、风险分析活动流程：
1、首先做需求分析，形成功能列表
2、技术专家为列表中的每一条功能进行评估、打分，至少要考虑如下几条计分项，如：人员经验（新人风险高，有经验的老员工则风险较低），是否采用新技术（全新技术风险高，复用已有技术平台则风险低），该功能的接口和与其他功能的交互性（毫无疑问的，接口和交互越多的，则风险就越高）等等，其他的可以根据需要来自我界定
3、用户代表为列表中的每一条功能进行评估、打分，至少要考虑如下几条计分项，如：失效影响（一旦失效是否有安全隐患？肯定的答案则得分高），商业价值（是否为产品的卖点），用户的使用频率（频率越高，被探测到问题的风险也就越高），如有需要还可以增加计分项
4、将各项分数统计之后，形成风险矩阵，横纵坐标分别为技术风险得分和用户代表评估风险得分，此时，就可以将功能列表中的功能项划分出四种不同的风险区间，两项得分居高的，肯定是测试重点，也是测试力度最应该投入的部分，采取的测试手段也应该是最严谨的，居中的两个区间（分别为高技术风险或者高用户代表评估风险），则可以适当投入力度和资源，风险最低的区间内可以权衡项目的QCD目标来确定要不要投入力度和资源
以上，一切取决于项目团队的集体意见，并非是测试人员一个人要考虑的问题，对于预留风险的接受情况一定是经过集体权衡出来的结果，并不是测试人员的个人职责，也就是说风险要共同分担，质量是掌握在每个人的手里，并非测试人员说了算
三、根据风险矩阵得出测试策略后，再合理分配测试资源投入情况
以上方法适用于所有的项目，并非只有紧急或者资源不足的时候才需要做，因为在任何时候，测试都需要平衡资源投入以提高效率，因为“YOU CAN NOT TEST EVERYTHING”……

[ 本帖最后由 yolander 于 2009-4-9 12:13 编辑 ]

uChrist

原帖由 yolander 于 2009-4-9 12:11 发表
其实这是个如何制定测试策略的问题，首先前提假设出来说进度紧，资源不充分，而反过来说即使是在理想条件下，给你足够的资源预留足够的进度，你能做到100%测试么？显而易见的答案，不能！
作为每个测试人员，都要明 ...

LS回答很专业，受教了

liuchunyanli

测试人员：YOU CAN NOT TEST EVERTHING!
同理，测试人员：YOU CAN NOT CONTROL EVERTHING!
如果是一般的“进度较紧、资源也不是十分充足的情况下”，可以通过加班和尽量协调来完成，但其工作方式也由具体情况决定，无法一刀切。
6楼切重要害，严重同意，作为测试人员，或只主管测试工作，能做的也只有这么多
10楼的回答有点类似于回答“和谐社会如何实现”

[ 本帖最后由 liuchunyanli 于 2009-4-9 17:25 编辑 ]

yolander

呵呵，和谐社会如何实现，这目标太崇高，不敢奢望了
我说的其实跟六楼的回答并不冲突，他说的更多的是一种想法，而我说的是做法
引用他的回帖里的一句“明知道答卷时间不够了，那就先找分多的，容易的做起，蒙上选择题，最后能做多少做多好吧。”——这就是办法了
但是被测试的系统不是白纸黑字的考卷，分数都已经标在了上面，所以才需要我们基于风险对系统的各项功能进行打分，这样才能知道哪些题目的分数高，哪些题目的分数低，也好把精力更多的投入到更有用的地方去，尽可能的减少测试的盲目性，即使是加班，也要进行合理规划，让加班也加的更有意义些吧

liuchunyanli

只是觉得“yolander”的说法更适用于项目主管人员，而不只是测试人员或测试主管的工作。
并且其中提到的一些工作，包括评估、客户关注点等，在项目开始时就应该做好了，如果到测试阶段再考虑已经来不及了。
测试人员拿到的是需求、设计和相关客户分析文档，哪些分值高、哪些会做，已一目了然，只要根据客户现有的要求，决定这些题目所用的时间并做完、做好、做对就可以了。

如果按照“yolander”的做法，我们还需要提到测试后，针对开发人员对BUG的修改进行回归测试等工作，需要对修改BUG后出现的不可预期的问题进行评估，整个过程的时间都需要调整。
而对于测试人员，我们不是QA，我们不是项目经理，做好本职的测试工作，提出测试过程中和过程后可能遇到的各种情况，在规定的时间内完成可完成的工作，尽量找出中存在的BUG就够了。
呵呵，纯因问题进行讨论，观点供大家评论

[ 本帖最后由 liuchunyanli 于 2009-4-10 10:54 编辑 ]

feifeimao

说说我的看法吧
进度紧，资源不充足，建议这样测试：
1、全员测试：开发人员、质保人员、项目经理等等一切可调用的资源都投入测试中，前提当然是不耽误他们的本职工作哈。但又由于进度紧，那么加班也是不可避免的哈。
2、保证最常用、最重要功能点的测试。由于进度紧，这些模块发现的bug如果不能及时修改的话，建议要有全面的bug记录，这样可以在用户面对系统吹毛求疵的时候说明，我们知道这些问题的，并且都已经记录下来了，放在下一阶段进行修改。
3、保证功能测试和性能测试。因为开展白盒测试需要编写额外的一些程序，花的时间会多一些。所以建议保证进行功能测试和性能测试。交付用户时，对自己的系统性能毕竟是要有了解的吧。
4、必要时提起变更。列出理由和如果不进行变更会有什么风险，提出自己的意见和建议，给领导决策去吧。

下面再来说说我的另外一点想法
进度紧资源不充足下测试，在大家的公司里肯定都存在吧。
那为什么会造成这个问题呢？
现在中国大多软件公司都存在这样的现象，开发计划，开始开发，工期假定为6个月，如果前期工作反工较多，那么最后压缩的必然是测试的时间，于是就造成这次讨论的话题。

就像我们常说的治标不治本，这次讨论的是治标的问题，求其根源，还是要治本才行。

以上是个人的一点看法，有不当之处，还请大家批评指正

yolander

原帖由 liuchunyanli 于 2009-4-10 10:53 发表
只是觉得“yolander”的说法更适用于项目主管人员，而不只是测试人员或测试主管的工作。
并且其中提到的一些工作，包括评估、客户关注点等，在项目开始时就应该做好了，如果到测试阶段再考虑已经来不及了。
测试人 ...

所以我一直比较提倡测试人员要尽可能早的参与项目过程，而不是等开发人员一切都就绪了，他们才开始准备，在系统工程中，要将测试跟开发提到平等地位，而且测试与开发的过程也是互相促进，相辅相成，不能总是居于开发之后，否则就永远无法改变测试人员的被动和无奈

kuailederen

讨论的很热闹，论坛很少有这种气氛了。
其实我 6楼说的，只是一个意思，测试人员要坚持自己的原则。
我们的出发点不是考虑项目成本，也不考虑项目周期，这些不是测试人员关心的，我们所考虑的只是我们的测试工作是否做的满意。
时间不够我们要告诉项目负责人，让他解决，资源不够也要告诉他，让他调配。但我们自己不能采取折中的办法，去自作主张的划分测试重点，决定优先测试的内容。这是职责问题，不是推卸责任。而我们所坚持的原则就是，绝对不让测试不充分的软件通过测试。公司领导可以命令停止测试，但我不会在测试报告中证明测试通过，软件运行良好，我必须会如实的说明白测试过的地方如何，而那些没有经过我的测试。
     为什么让测试部门独立？那是为了让这个部门能独立的决断。这个题目，时间不够，资源不够，你肯定测试不好，解决的办法只有一个，延期（或增加人手）和调配资源。 你可以被领导强制要求做10楼写出的那些工作，但一定不要同意出具测试报告证明测试通过。
     现在想想，开发人员大都比较强势，可能是因为缺少坚持原则的测试吧。

UU1983

你说的这种问题在我以前的项目工作中时常发生，如果解决不当对项目来说是致命的
我们来分析下其中的原因
这种问题大多出在国内项目中，为什么会这样呢
主要根源在于甲方和乙方的立场不同，认识不同，导致利益无法达到最大话
一句话互相推卸责任，不能积极合作
我们无法将这种现实扭转所以我们必须积极调动我们每一根神经来应对突发事件
没有资源怎么办？
以前我们的做法是等开发人员搞定需求，我们在来按照需求写测试用例搞测试
现在我们不但没有资源而其没有时间，我们必须调动自己，从开发哪里获取最新需求，如有可能我们可以和客户直接联系获取一首材料，使我们的工作快速的开展
有些人会想这些本不是我们该做的，我们为什么要做，是的这些本不是测试应该做的，但是你要完成你的工作，所以你只能如此
当我们获得了资料如何安排进度呢
其实这个现实可能大家都不愿意接受就是-----加班

但是我们必须接受这个事实

这样的项目通常都是靠我们自己的私人时间加班才堆砌成的。。。。。
所以大家努力吧

liuchunyanli

如果只针对题目，进度较紧，加班；资源不是很充足，在现在资源基础上进行工作，电饭煲可以做饭，高压锅也可以；如果是关键性短缺，无法通过变通解决，且会直接影响测试工作进行，只能申请。
放弃单纯从测试角度考虑，在分工相对细一些的公司，在内部紧张工作的同时，测试负责人可以把该项目的客户经理、项目经理、开发负责人和项目总监聚在一起，开一个会，看看具体是哪个环节出现问题，寻求其他的可能的解决方法。
如果是调研时出了问题，可以让项目经理与客户协商进行顺延等等。
我一直认为测试人员的工作只是完成系统中各环节的测试，可以包括文档和系统的测试。但测试人员无法对整个项目实施过程进行控制，我们不是QA，不是项目经理，我们没有对项目风险控制的权力和责任。我们只在测试测试过程中提出系统中存在的、潜在的问题就可以了。
大家提出了很多理论的东西，但在项目实施过程中，每个公司有每个公司的管理方法，各公司中，具体项目的具体情况也是不同的，没有决对的理论可以解决一切。

yoyoalphax

原帖由 yolander 于 2009-4-9 12:11 发表
其实这是个如何制定测试策略的问题，首先前提假设出来说进度紧，资源不充分，而反过来说即使是在理想条件下，给你足够的资源预留足够的进度，你能做到100%测试么？显而易见的答案，不能！
作为每个测试人员，都要明 ...

这个回答貌似偏向于评审需求分析吧，并不完全是讨论测试策略吧

还有这句话..:测试不是提高质量，而是降低风险的手段之一
用既..也..是不是比较恰当？毕竟，说测试不是提高质量有点说不过去...质量的定义不是物质的某个属性，而是对某个属性的满足程度，不是固定的，而是有度的。不知道我这样理解对不对

yoyoalphax

没什么经验，就不在这里参合了，不过看下来，觉得6楼说的比较实在~
问题本身就有问题...