51Testing软件测试论坛

标题: 在进度较紧的情况下，如何开展测试工作？（09-04-7）（获奖名单已公布） [打印本页]

作者: 默默巫 时间: 2009-4-7 13:20
标题: 在进度较紧的情况下，如何开展测试工作？（09-04-7）（获奖名单已公布）
在进度较紧、资源也不是十分充足的情况下，如何开展测试工作

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

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

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

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

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

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

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

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

作者: kuailederen 时间: 2009-4-8 10:54
看了大家的回答，我后面讲述了自己的一个亲身经历

这个问题很含糊，缺少背景，不好回答。如同问题：早上起晚了，时间比较紧张，交通又不是很方便，那我应该怎么去上班？
原问题：有一个测试项目马上上线，时间比较紧张，测试资源又不是十分充分，那我们应该怎么展开测试？
问题解读：
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 时间: 2009-4-8 11:47
个人认为还是能测什么就测什么，如果时间不允许了，那就看那些重要就先测那些

作者: black_tulip 时间: 2009-4-9 09:55
我靠，此类帖子看到现在，六楼 kuailederen 朋友的回帖最高质量！

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

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

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

作者: uChrist 时间: 2009-4-9 13:10

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

LS回答很专业，受教了

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

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

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

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

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

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

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

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

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

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

作者: yolander 时间: 2009-4-10 16:47

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

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

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

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

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

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

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

作者: yoyoalphax 时间: 2009-4-13 13:21

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

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

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

作者: yoyoalphax 时间: 2009-4-13 13:24

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

作者: 阿七 时间: 2009-4-13 14:43
这样的情况会导致一个结果-----那就是加班!

作者: hyj785 时间: 2009-4-13 17:21
看项目的规模，进度，和人手。需求的变动频率。但是实际上说老实话，看公司和客户要求了。
但是最基本上要求所有业务流程都要跑通。使用时没有太过明显的延时，不会经常出现数据库报错等情况。
时间来不急，就拿着流程图和需求测吧。分清主次，凭经验了。代码出来就按流程跑下。bug就截图，标注发生页面，不写步骤了。直接截图快些。验证如果是js做的,就去看看方法。那就靠经验了。测试数据就自己来，直接在数据库插。一句话，靠自己。
上面只是自己能做的，实际情况，如果是公家单位，就不要急。只要能保证基本上能用，就是我上述的标准，拖到最后，也就完工了。

作者: yolander 时间: 2009-4-14 17:26

原帖由 yoyoalphax 于 2009-4-13 13:21 发表

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

还有这句话..:测试不是提高质量，而是降低风险的手段之一
用既..也..是不是比较恰当？毕竟，说测试不是提高质量有点说不过去...质量的定义不是物 ...

不是评审需求分析，测试人员参加需求分析的评审，其主要目的是帮助需求文档去除二义性，并提高其可测试性，对不可测试的需求尽早发现，并建议采用其他方式，如设计评审等来控制

另外关于“测试不能够提高质量，而是降低风险的手段”，那是因为产品的质量无论是从前，还是现在都是源于设计，它从设计开发人员手中出生的那一刻，就已经决定了其品质的好坏，测试只能帮助把它出问题的风险降低到可控制的范围内

作者: tengmy 时间: 2009-4-15 11:29
路过，留下几笔

http://www.51testing.com/?uid-47 ... space-itemid-117069

作者: imutou 时间: 2009-4-15 14:05

貌似碰到下午客户说要需求，明天就要给他们。当然这是maintain的。加上中美的12小时时差，能挤的几乎全用上了。

作者: aman_cao 时间: 2009-4-15 16:48
测试过程中，这个问题比较突出
成本与完全测试是矛盾的，在当这种情况下，同意2＃的观点，测试的重点是软件是否实现了客户的需求，所以将客户的需求整成列表，按工作量和优先级（影响范围）进行分类。优先测试高优先级，高影响范围的功能
如果是时间短，刚可多人并行工作，如果是硬件问题，则要再投入硬件成本
呵呵，虽然进度紧急，但测试人员还是要坚守测试原则的。

作者: zhyb_2008 时间: 2009-4-15 23:26
看贴学知识.

作者: allenzgw 时间: 2009-4-16 16:43
标题: 全方位管控这个问题
首先，我觉得这个问题是一个非常具有现实意义的问题，特别是国内企业，这类问题很严重，相对国外企业项目也会遇到这类问题，但是相对而言更容易解决。基本上在任何一个项目都没有说是人员充足，时间充足的，这个永远都是多多益善。主要谈一下我自己的经验和看法：在进度较紧、资源也不是十分充足的情况下，如何开展测试工作
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 编辑 ]

作者: 一刀仙 时间: 2009-4-16 17:37
1、增加人手，合理分工
2、邀请研发人员参于测试
3、关注主要业务流程的实现

作者: aliceella 时间: 2009-4-17 11:38
标题: 回复 16# 的帖子
主要的问题是在于不是每个公司都会很重视测试工作的，有的公司在做项目需求分析、概要设计包括详细设计，都不让测试人员参与，包括测试计划都是由开发人员在编写，就相当于开发人员根本就没有把测试放在眼里，等系统做好了，就直接把系统扔给测试人员，说了大体的功能，测试人员就开始盲目的测试了！

作者: 快乐海豚 时间: 2009-4-17 11:57
我个人看来，这个是需要根据当前情况，客户最关心的问题测试，还有就是行业的几个测试标准符合就可以了

作者: 西贝 时间: 2009-4-17 16:34
一、客户
1.企业80%的利润来自20%的客户，看是哪类客户吧，这个是从利润角度考虑，从信誉角度考虑当然是个个重要了。
2.事先跟客户沟通，让客户参与裁决什么才是他们最急最重要最关心的功能及其他功能优先级别排序，也可完成重要功能，以后通过补丁提交次要功能。
二、流程
时间统筹安排，能尽早开始测试的不等最后累计一起测试，一些准备工作事先做好，万事俱备，只欠东风嘛。
三、协调
1.与其他部门协调调动人员参与测试。
2.合理分工，正确的人做正确的，各取所长。
3.沟通。与本部门及其他部门完美沟通，避免因沟通不畅产生的效率低下及工作重复。
四、积累
重要模块及易出错模块重点测试，开发个人易犯错习惯等重点测试

效率至上，实在不行，加班吧~

但是不管怎么样，与上级沟通目前存在的问题及采取某种手段后的利弊，让上级心里有数

作者: fmsbai5 时间: 2009-4-17 18:34
在时间不足的情况下，我的做法：
1.走主干、重要功能流程；2.覆盖常见错误点（经验）；3.对些常规性不太重要的功能点略去；4.延迟使用更改bug后的版本；5.使用以前的用例，缺陷报告；6.一定要注意适度，适可而止，不要死钻牛角尖。

作者: jenvee 时间: 2009-4-17 19:41
标题: 学习。。

原帖由 kuailederen 于 2009-4-8 10:54 发表
看了大家的回答，我后面讲述了自己的一个亲身经历

这个问题很含糊，缺少背景，不好回答。如同问题：早上起晚了，时间比较紧张，交通又不是很方便，那我应该怎么去上班？
原问题：有一个测试项目马上上线，时间比 ...

经验之谈，学习在学习

作者: yzylion 时间: 2009-4-18 22:44
标题: 个人的一些看法
有些问题，我们作为测试人员本身来说，不用看的太复杂了，讨论的话题是：进度紧张，资源也不是十分充足的情况下，如何开展工作，我现就个人的看法阐述如下，一家之言，不求苟同
1.这里的资源也不是十分充足，那么我们首先需要搞清楚，我们自己有的资源是哪些，理论上来说，测试初始的入口文件应该有一个作为上流入口的软件需求规格说明书，并且是已经通过了会议评审通过了的

2.如果可以召集到该项目的客户人员或者客户代表人员，则应该在软件开发的技术人员，测试人员，市场人员，项目经理，测试经理等人的参与下，形成对需求的优先级，重要级进行划分，有的朋友可能会说，你怎么能自己来对需求进行这些划分呢？对，不错，但是，如果我是站在用户的角度呢？测试本身来说不也就是站在用户的角度来对系统或者说软件来进行测试的活动吗？

3.在进行了前面两项的工作后，在于我看来就可以进行测试的相关活动了，比如：测试策略报告的书写，测试的功能特性的用例覆盖情况分析，功能测试矩阵的生产和维护，需求变更对现行测试的功能特性的影响分析等

4.测试不是来保证产品的质量的，这个相信朋友们会赞成我的，那么在做了以上的工作后，怎样来尽可能的减低产品上线后的风险呢？我个人的建议是：在产品上线前至少两天，负责管理该项目测试活动的负责人像该项目的项目经理报告该项目现今测试中发现的问题及状态，是closed.fixed还是reopen并对不是closed状态的BUG存在的风险做分析说明，由项目经理确定该项目是否是如期上线，还是寻求市场部门的业务人员进行沟通推迟上线时间等方式

总之作为测试人员在这样的情况下，尽到自己的职责就问心无愧了

以上纯属个人观点，请不惜赐教

作者: lc448589698 时间: 2009-4-20 11:34
刚刚经历了这种情况，只能用一句话说无奈

作者: 婧子 时间: 2009-4-21 11:45
学习Ing..

作者: 奔Q7的zhu 时间: 2009-4-21 21:12
如果是进行回归测试的话，我觉得可以按一下的顺序来考虑：
1.考虑完全重复测试
2.考虑周边影响法
3.如果无法分析对其他模块的影响就考虑覆盖修改法
4.如果没办法分析开发修改的特性就考虑指标达成法的最简单的方法：根据所有用例的百分比来进行执行那些用例，当然这是最无奈的方法）
当然指标达成法也可以覆盖修改和周边影响法搭配使用

作者: luyan525631120 时间: 2009-4-28 17:33
受益匪浅

作者: bently 时间: 2009-4-28 21:48
坐以待毙肯定是不行的：
1.争取前期介入
2.争取测试人力资源
3.争取开发资源
4.遴选测试重点
5.选择以往积累的测试脚本开展自动化测试
6.测试报告实话实说

作者: litaiwan2 时间: 2011-7-29 19:35
拜读了29楼的文章，写的很全面很具体，看第一条还有点投机的感觉，后面感觉好多了

作者: cherrytesting 时间: 2011-7-31 11:28
回复 29# allenzgw

在测试过程中，怎么知道发现的缺陷有多少百分比，是否达到投入产出比例最高

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)