在进度较紧的情形下如何开展测试工作Word文档下载推荐.docx
《在进度较紧的情形下如何开展测试工作Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《在进度较紧的情形下如何开展测试工作Word文档下载推荐.docx（19页珍藏版）》请在冰豆网上搜索。
作为测试人员，咱们绝不能消极等待或一味抱怨开发人员的不睬解和不重视。
咱们第一需要正视自己、改良自己，通过自身的不断尽力让开发人员真正体会到测试的价值；
同时也需要明白得并配合开发人员的工作；
如此才能博得开发人员的支持。
配合好了，工作的效率及质也就提高了。
方法（六）：
增强沟通和信息搜集
我碰着过很多如此的案例：
测试人员测试了一段时刻以后，才发觉用户的需求已经变更了，而测试时参考的仍是原先的需求。
致使这种情形的缘故很明显是缺乏沟通。
显现类似如此的情形，有些测试人员比较喜爱把责任归咎于需求分析人员或项目领导没能将变更以后的需求及时告知测试人员（固然项目领导和需求分析人员是有责任的）。
但要幸免这种问题，咱们测试人员是完全能够做到的，咱们只需要在测试前，和项目组相关人员沟通一下就能够够了。
以上六大方法希望对人员有帮忙，也希望软件测试工作能够做的加倍的完善。
在进度较紧的情形下，如何开展测试工作?
1hongyan发表于2020-4-716:
32
在进度较紧而资源也不是十分充沛的情形下,个人以为能够先考虑以下几个测试点:
1.分析该项目中,哪些功能是最重要的.
2.哪些功能对用户最明显?
用户最关心的是什么?
3.哪些问题对安全问题存在高风险?
4.在开发过程中,哪些功能点可以先进行测试.
5.哪一部分的代码最复杂最容易出错.哪些是在时间比较紧迫的情况下研发出来的.
6.开发人员认为在应用软件中哪些部分是高风险的
7.哪些测试可以容易地覆盖多种功能,
8.哪些测试在覆盖高风险部分的测试时使用时间最少
2hutter2006发表于2020-4-717:
57
从问题的本身来看显得提问者有点急躁，进度紧张到什么程度？
资源怎么个不足？
这些情形作为回答者都不太清楚，固然，做了这么多的测试项目我也碰到过类似的情形，例如一个中型的旅行网站今天改版好，老板说明天就要上线的情形，测试组3个人，如安在12小时内完成功能测试？
（吃个盒饭，睡觉就别想了）
我们需要关注的问题：
1.网站的主要业务流程要全部跑通（订单的查询、预订、生成、支付、成功出票等）
2.会员的登录等
3.积分的计算以及奖励方式等。
另外我想说的是，开展这类测试工作需要结合项目本身的性质。
有些小项目完全可以搞定。
有些则不然。
这个度需要你自己把握好。
3luna_jia发表于2020-4-810:
06
进度紧张的情形在做客户项目的时候可能常常碰到，软件交付的时刻是定好了的。
一个比较无奈的方法是和业务部门或客户沟通，适当延缓几天，交出一个合格的产品比按时交付有利无害，这对一些比较小的项目可能并非困难，但对一些大的客户，本身对按时交付要求比较严格的，在前期的的需求和开发时期已经挤占了测试时刻的情形下，测试方面能采纳的应付方式：
1、关注重点功能，次要功能仅做简单测试，只保证不出现严重错误。
比如业务系统主要测试业务操作功能，对基础资料一类的功能适当减少测试时间。
2、保证在正常业务操作下的测试，减少边界测试、非法数据等比较极端的异常测试，异常方面用几条数据稍做测试即可。
3、允许软件中存在并不严重的BUG，不要追求尽善尽美。
这些BUG可以暂时不改，或者不做回归测试。
可以到系统上线实施的这个缓冲阶段中逐步修复这些早已发现的问题。
4、资源紧张是一个内部的问题。
如果能协调其他的人员，比如客服人员等做一些简单的功能、UI方面的测试，开发人员到了测试阶段，任务相对也少一些，可以加强单元测试，让一些BUG不要流到测试这里来。
这样都可以减少测试人员本身的一些工作量。
5、超时加班。
不过要记得维护自己的合法权益哦。
4sogoc发表于2020-4-810:
37
测试按最低标准来测试，也确实是输入正常的数据，保留，提交，编辑...等等的操作都可不能有错误。
不去测试比如：
特殊字符，字段长度，输入非法，输入错误等等的反映，整个系统只针对正确输入输入后表现是不是正确即可！
[[i]本帖最后由sogoc于2009-4-810:
40编辑[/i]]
5kuailederen发表于2020-4-810:
54
[color=Red]看了大伙儿的回答，我后面讲述了自己的一个切身经历[/color]
这个问题很含糊，缺少背景，不好回答。
如同问题：
早上起晚了，时间比较紧张，交通又不是很方便，那我应该怎么去上班？
原问题：
有一个测试项目马上上线，时间比较紧张，测试资源又不是十分充分，那我们应该怎么展开测试？
问题解读：
1.早上起晚了，必须是一个比较的结果，说明以往起的要早些。
同样，这个测试项目的工作，按以往经验需要两个月，而现在只有1个月多点。
2.时间比较紧张，说明如果顺利的话，还是能够按时上班的。
同样，测试项目如果顺利的话，少bulid次，也是可以顺利上线的。
3.交通不是很方便，指出准时上班存在的风险，万一我要等的公交车迟迟不来呢？
同样，测试资源不充分，说明缺少一些测试环境，测试工具，软硬件设施等，导致一些测试工作无从展开。
4.我们怎么去上班呢？
这才是问题的关键，只有知道迟到的后果，才决定我们怎么去上班的决心和应该付出怎样的代价。
如果上班迟到一次就辞退，那么你必须考虑是否找一位飙车高手载你上班，顺便说服警车为你开道；
如果迟到一次，领导会批评你，然后扣100元钱，那么你只需要尽量赶到就行，迟到了只是让领导发发官威，损失点人民币而已；
如果迟到不会收到惩罚，那你还担心什么呢？
晨练完再去上班吧。
同样，对这个项目的测试必须有个预期，也就是测试要达到的目标。
①若是项目不能延期，而且必需全功能覆盖，那么增加人手来抵消时刻紧张，必需去购买（或其它途径）缺少的测试资源，来知足测试需要；
②若是项目能够延期，但也必需全功能覆盖，那么考虑到测试本钱，能够不增加人手的前提下稍作延期，但测试资源的投入仍是必需的；
③若是项目能够延期，而且缺少测试资源的部份非重要功能，本次上线能够意外，那么项目做延期，测试该测的功能就好了。
④若是问题的原意是：
项目测试时刻明显不够，既不能增加人手，缺少的测试资源确信不能知足，又要求全功能覆盖，必需按时上线，那咱们怎么才能把测试工作做的尽可能好呢？
我的回答是，兄弟跑路吧，这次测试你肯定做不好。
如果不想跑路，那么兄弟要雄起一次，大胆的说不。
针对这种情况，可能很多人采取的措施是：
在现有的条件下，先从能测的重要的功能测起，在有限的时间里测多少算多少。
如同考试一样，
明知道答卷时间不够了，那就先找分多的，容易的做起，蒙上选择题，最后能做多少做多好吧。
试问，试卷你可以得50分不及格，那么我们的软件可以不及格吗？
试卷上有选择题可以蒙，1/4的概率，我们的软件功能点只有正确和不正确，1/2的概率，但你能蒙吗？
试卷这次不会，回头老师可以答疑，而我们的软件可以答疑吗？
我觉得软件测试是一门需要用科学的精神去对待的学科，结果只有正确的才算科学，过程是需要仔细严谨的对待，而方法可以有多种，但只有一种才是最高效的。
所以我们的测试工作是用仔细严谨的态度，去寻找一条最有效的方法，然后把测试工作做的最好，而不会存在模棱两可和含糊的结果。
[color=Red]我的经历：
[/color]如果测试时间不够，肯定不能全功能覆盖，我们是否应该只测客户比较关心的，比较常用的功能？
测试目前主要是产品测试和项目测试。
做自己公司的产品测试，如果碰到不能按原计划完成，本着为质量负责，一般都可以申请延期。
如果是做项目，迫于合同和客户验收的压力，碰到不能按原计划完成的情况，就是项目风险了。
而处理的方式基本都是“先测客户比较关心的，比较常用的功能”，保证通过客户验收，拿到项目款。
分析客户验收所关心的功能点（比如客户最近几天提过什么需求，肯定要测试，因为时间短，他肯定记得），分析系统最脆弱的地方，走通所有业务流程等。
而客户验收时候，不关心和不可能想到得地方可以不测试（比如系统中很多同步功能）。
我讲个自己的经历，做的是国内最大保险公司的一个平台，由几个系统共同构成。
由于前期公司为了节约成本，一直投入比较少的资源，到了后期，明显感觉到项目不可能如期完成，更要命的是，测试前期没有跟进，对于这个项目的质量没有任何把握。
公司处理措施：
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.公司失去了一个大客户。
这是血的教训，对于公司损失的是钱和信誉，对于客户损失的是钱和无限拖延的项目以及产品延期造成的竞争力影响。
对于开发，除了疯狂加班的劳累，还有开除的冤屈；
对于测试，没有坚持自己的职业道德。
我讲述的这个经历，可能大部分的项目都不会发展到这种地步，到我们必须充分意识到风险的存在。
所以我觉得作为测试，碰到时间紧张，测试资源欠缺，所唯一能做的是上报公司，让他们协调人工和资源，做延期处理。
这样做公司可能因不能如期交付而受到一些经济上的损失，但交付一个合格的产品给客户，绝对不会有信誉上的损失，从长久看，会有更多的收益。
作为测试，你没有任何权利自己做风险处理---测“客户关心的，测主要功能”，都是错误的做法。
作为测试，坚守住自己的职业道德，只做自己职责范围的工作和力所能及的事；
作为测试，不但要为支付给你工资的老板负责，也请为你手中的软件负责，为客户支付的金钱负责。
[[i]本帖最后由kuailederen于2009-4-1516:
53编辑[/i]]
6Ancen发表于2020-4-811:
05
这种情形，应该时有发生，只是问题不太详细，是一个很短的时刻仍是一个小的开发周期内？
这里就列下我们在一个星期的时候遇到这种问题的处理方法吧：
1.确定重新确定当前测试目标，并进行计划和任务重新划分。
2.列出软件功能列表，确定优先级。
（使用最频繁的模块，最容易出错的模块，最重要的模块）
3.在时间按照优先级对功能列表逐个测试，这过程需要确定一个schedule,详细到每人每天。
4.首先，功能的完整实现是必须要求的。
如果在时间不够的情况下，对一些用户体验性方面的bug可以延后再去做。
5.此过程中必会存在测试用例疏漏和覆盖不完整的情况。
这里我们建议是暂时先测试，项目结束后再维护测试用例。
6.因为时间上的紧迫我们就需要开发即时的解决问题和测试即时的回测。
那这样也就需要测试人员保持与开发的沟通，跟踪open的bug，push对应的开发人员。
7.要求dailybuild，如果时间紧肯定也会要求更频繁的发布，但必须确定系统修改无影响部分功能避免测似人员太多的重复工作。
这样也是为了让bug即时的被关闭。
8.另外还有一个难以避免的方法就是加班。
7sn_asd520发表于2020-4-811:
47
个人以为仍是能测什么就测什么，若是时刻不许诺了，那就看那些重要就先测那些
8black_tulip发表于2020-4-909:
55
我靠，此类帖子看到此刻，六楼kuailederen朋友的回帖最高质量！
同样是列12345，此人逻辑最清楚。
9yolander发表于2020-4-912:
11
其实这是个如何制定测试策略的问题，第一前提假设出来讲进度紧，资源不充分，而反过来讲即便是在理想条件下，给你足够的资源预留足够的进度，你能做到100%测试么？
显而易见的答案，不能！
作为每个测试人员，都要明确这一点“YOUCANNOTTESTEVERTHING!
”，测试不是提高质量，而是降低风险的手段之一，如果项目团队给你的资源不充分，进度紧，OK，那我们一起来做个风险分析吧，而事实上，无论是否资源充分，我们也都需要在制定测试计划前，先做风险分析，再基于风险来制定测试策略，那么这个基于风险分析的测试策略到底是如何制定呢
一、风险分析团队组建：
这时我们需要有两队人马，一队是技术专家，另一队是用户代表（不一定是最终用户、服务人员、市场人员、有经验的资深测试人员都可以担当此角色）
二、风险分析活动流程：
1、首先做需求分析，形成功能列表
2、技术专家为列表中的每一条功能进行评估、打分，至少要考虑如下几条计分项，如：
人员经验（新人风险高，有经验的老员工则风险较低），是否采用新技术（全新技术风险高，复用已有技术平台则风险低），该功能的接口和与其他功能的交互性（毫无疑问的，接口和交互越多的，则风险就越高）等等，其他的可以根据需要来自我界定
3、用户代表为列表中的每一条功能进行评估、打分，至少要考虑如下几条计分项，如：
失效影响（一旦失效是否有安全隐患？
肯定的答案则得分高），商业价值（是否为产品的卖点），用户的使用频率（频率越高，被探测到问题的风险也就越高），如有需要还可以增加计分项
4、将各项分数统计之后，形成风险矩阵，横纵坐标分别为技术风险得分和用户代表评估风险得分，此时，就可以将功能列表中的功能项划分出四种不同的风险区间，两项得分居高的，肯定是测试重点，也是测试力度最应该投入的部分，采取的测试手段也应该是最严谨的，居中的两个区间（分别为高技术风险或者高用户代表评估风险），则可以适当投入力度和资源，风险最低的区间内可以权衡项目的QCD目标来确定要不要投入力度和资源
以上，一切取决于项目团队的集体意见，并非是测试人员一个人要考虑的问题，对于预留风险的接受情况一定是经过集体权衡出来的结果，并不是测试人员的个人职责，也就是说风险要共同分担，质量是掌握在每个人的手里，并非测试人员说了算
三、根据风险矩阵得出测试策略后，再合理分配测试资源投入情况
以上方法适用于所有的项目，并非只有紧急或者资源不足的时候才需要做，因为在任何时候，测试都需要平衡资源投入以提高效率，因为“YOUCANNOTTESTEVERYTHING”……
[[i]本帖最后由yolander于2009-4-912:
13编辑[/i]]
10uChrist发表于2020-4-913:
10
[quote]原帖由[i]yolander[/i]于2020-4-912:
11发表[url=&
pid=1197994&
ptid=145131][img]
其实这是个如何制定测试策略的问题，首先前提假设出来说进度紧，资源不充分，而反过来说即使是在理想条件下，给你足够的资源预留足够的进度，你能做到100%测试么？
作为每个测试人员，都要明...[/quote]
LS回答很专业，受教了
11liuchunyanli发表于2020-4-917:
23
严峻同意6楼的回答，借用10楼的一句话
测试人员：
YOUCANNOTTESTEVERTHING!
同理，测试人员：
YOUCANNOTCONTROLEVERTHING!
如果是一般的“进度较紧、资源也不是十分充足的情况下”，可以通过加班和尽量协调来完成，但其工作方式也由具体情况决定，无法一刀切。
6楼切重要害，严重同意，作为测试人员，或只主管测试工作，能做的也只有这么多
10楼的回答有点类似于回答“和谐社会如何实现”
[[i]本帖最后由liuchunyanli于2009-4-917:
25编辑[/i]]
12yolander发表于2020-4-917:
33
呵呵，和谐社会如何实现，这目标太高贵，不敢奢望了
我说的其实跟六楼的回答并不冲突，他说的更多的是一种想法，而我说的是做法
引用他的回帖里的一句“明知道答卷时间不够了，那就先找分多的，容易的做起，蒙上选择题，最后能做多少做多好吧。
”——这就是办法了
但是被测试的系统不是白纸黑字的考卷，分数都已经标在了上面，所以才需要我们基于风险对系统的各项功能进行打分，这样才能知道哪些题目的分数高，哪些题目的分数低，也好把精力更多的投入到更有用的地方去，尽可能的减少测试的盲目性，即使是加班，也要进行合理规划，让加班也加的更有意义些吧
13liuchunyanli发表于2020-4-1010:
53
只是感觉“yolander”的说法更适用于项目主管人员，而不只是测试人员或测试主管的工作。
并且其中提到的一些工作，包括评估、客户关注点等，在项目开始时就应该做好了，如果到测试阶段再考虑已经来不及了。
测试人员拿到的是需求、设计和相关客户分析文档，哪些分值高、哪些会做，已一目了然，只要根据客户现有的要求，决定这些题目所用的时间并做完、做好、做对就可以了。
如果按照“yolander”的做法，我们还需要提到测试后，针对开发人员对BUG的修改进行回归测试等工作，需要对修改BUG后出现的不可预期的问题进行评估，整个过程的时间都需要调整。
而对于测试人员，我们不是QA，我们不是项目经理，做好本职的测试工作，提出测试过程中和过程后可能遇到的各种情况，在规定的时间内完成可完成的工作，尽量找出中存在的BUG就够了。
呵呵，纯因问题进行讨论，观点供大家评论
[[i]本帖最后由liuchunyanli于2009-4-1010:
54编辑[/i]]
14feifeimao发表于2020-4-1011:
30
说说我的观点吧
进度紧，资源不充足，建议这样测试：
1、全员测试：
开发人员、质保人员、项目经理等等一切可调用的资源都投入测试中，前提当然是不耽误他们的本职工作哈。
但又由于进度紧，那么加班也是不可避免的哈。
2、保证最常用、最重要功能点的测试。
由于进度紧，这些模块发现的bug如果不能及时修改的话，建议要有全面的bug记录，这样可以在用户面对系统吹毛求疵的时候说明，我们知道这些问题的，并且都已经记录下来了，放在下一阶段进行修改。
3、保证功能测试和性能测试。
因为开展白盒测试需要编写额外的一些程序，花的时间会多一些。
所以建议保证进行功能测试和性能测试。
交付用户时，对自己的系统性能毕竟是要有了解的吧。
4、必要时提起变更。
列出理由和如果不进行变更会有什么风险，提出自己的意见和建议，给领导决策去吧。
下面再来说说我的另外一点想法
进度紧资源不充足下测试，在大家的公司里肯定都存在吧。
那为什么会造成这个问题呢？
现在中国大多软件公司都存在这样的现象，开发计划，开始开发，工期假定为6个月，如果前期工作反工较多，那么最后压缩的必然是测试的时间，于是就造成这次讨论的话题。
就像我们常说的治标不治本，这次讨论的是治标的问题，求其根源，还是要治本才行。
以上是个人的一点看法，有不当之处，还请大家批评指正:
）
15yolander发表于2020-4-1016:
[quote]原帖由[i]liuchunyanli[/i]于2020-4-1010:
53发表[url=&
pid=1198560&
只是觉得“yolander”的说法更适用于项目主管人员，而不只是测试人员或测试主管的工作。
测试人...[/quote]
所以我一直比较提倡测试人员要尽可能早的参与项目过程，而不是等开发人员一切都就绪了，他们才开始准备，在系统工程中，要将测试跟开发提到平等地位，而且测试与开发的过程也是互相促进，相辅相成，不能总是居于开发之后，否则就永远无法改变测试人员的被动和无奈
16kuailederen发表于2020-4-1017:
39
讨论的很喧闹
讨论的很喧闹，论坛很少有这种气氛了。
其实我6楼说的，只是一个意思，测试人员要坚持自己的原则。
我们的出发点不是考虑项目成本，也不考虑项目周期，这些不是测试人员关心的，我们所考
升级会员 