51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 5924|回复: 19
打印 上一主题 下一主题

[讨论] 怎样提高测试效率

[复制链接]
  • TA的每日心情
    郁闷
    2015-4-17 13:17
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    跳转到指定楼层
    1#
    发表于 2013-7-1 17:48:09 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
    在工作中,常常会遇到,测试用例写的不符合实际,执行起来比较费劲。执行测试用例的周期太长。怎样才能快速准确地完成测试工作呢。
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    该用户从未签到

    20#
    发表于 2013-7-17 09:45:28 | 只看该作者
    LZ  求给一个参考文档 才开始做测试 上面就扔个alpha来让跑 看bug
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2013-7-15 17:24:43 | 只看该作者
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2015-4-17 13:17
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    18#
     楼主| 发表于 2013-7-12 14:11:38 | 只看该作者
    回复 16# 450174661

    那用例编写规范和粒度,你能给我提供参考吗?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2015-4-17 13:17
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    17#
     楼主| 发表于 2013-7-12 14:09:48 | 只看该作者
    按照各位的意思,我现在只能是适应这种情况了,最多是努力去跟开发沟通,尝试让他们给出一份所谓的需求文档,哪怕是设计框架或是使用说明文档了。我们没有专门的需求分析人员,只有两个测试人员,且都经验不足,预期结果的话,也是通过跟开发人员沟通得来的,有些是根据自己经验按常规推出来的,报上去之后,开发说这个就是这样的,不是错误,我们就把缺陷关闭。就这样,,,我们是创新型公司,所以有些标准不好制定。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2013-7-12 00:12:36 | 只看该作者
    回复 15# Aimelyccc


       完善需求,不应该测试人员来做哦,需求提出人对需求业务的把控能力应该是最强的,建议由需求负责人来完善需求;
       我们公司以前也是没有需要或者开发过程中需求变了也不更新文档,导致测试没有文档依据,或者开发做成什么样就是什么样,只要不报错,功能实现就OK,但是经常被客户返工,说不满足他们的业务需求;其实客户业务在转变为需求,需求再转变为开发设计的过程中,原始信息在层层衰减,如果到测试这边,连文档也没有,对测试是非常不利的,case无法编写、执行,连BUG也不知道是不是BUG;

        没需求文档,相当于没有预期结果;连预期结果都没有,开发如何进行开发?测试又如何进行测试?客户又如何验收呢?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2015-4-17 13:17
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    15#
     楼主| 发表于 2013-7-11 15:49:44 | 只看该作者
    回复 14# 450174661
    好哇,上面没说,是想让我们自己完善呢,但,我又没什么经验,麻烦你了,给我些参考吧。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2013-7-11 13:52:52 | 只看该作者
    需求文档也木有,确实很累,曾经经历过,建议你分析下目前测试现状以及风险,找到原因,让上游协助你完善你们的测试流程;再逐步晚上测试专业的一些东西,比如用例编写规范和粒度,用例执行规范和粒度,如果需要参考文档,我可以提供一些给你
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2013-7-11 13:12:08 | 只看该作者
    编写优秀的测试用例可以很好帮助你完成测试工作,测试用例的编写应该因地制宜,对症下药,科学的方法一定可以最大程度上提高测试的效率
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2013-7-11 12:29:06 | 只看该作者
    需求文档这个东西,除非公司有专门的需求人员,不然都不会太详细的,具体还是看测试人员的沟通协调能力----
    当然了有流程最好了,但是这不是一般底层测试人员所能左右的
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2015-7-6 15:31
  • 签到天数: 4 天

    连续签到: 1 天

    [LV.2]测试排长

    11#
    发表于 2013-7-10 00:02:12 | 只看该作者
    飞鱼所说极是,但从目前楼主描述的情况来看,连需求文档都没有,估计更不会有人主动抽调开发、测试聚一起评审测试用例。。写需求文档的意义在于所有测试点有点可查,有据可依,提纲引擎,测试流程不规范,走到后面更是举步维艰。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2013-7-9 12:25:57 | 只看该作者
    没有需求文档的话,可以把开发人员以及测试人员以及各个老大召集起来确定测试点,会后有会议记录;接下来根据测试范围提取测试点和测试用例,之后就是再召集开发人员和测试人员进行用例评审,确定没有遗漏 测试点。具体执行的话,如果时间较紧可以直接根据测试点和思维导图进行测试,当然这时测试用例的优先级就显得尤为重要了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2013-7-8 09:56:48 | 只看该作者
    测试用例是纲。
    纲举目张。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    5 天前
  • 签到天数: 1050 天

    连续签到: 1 天

    [LV.10]测试总司令

    8#
    发表于 2013-7-2 16:23:13 | 只看该作者
    回复  lsekfe
    但是我们公司真的是没有需求文档的,有不明白的地方,我们就是跟开发频繁沟通,交流。最多我 ...
    Aimelyccc 发表于 2013-7-2 16:09



        恩,这样确实很不方便。我建议你们提出下自己的需求。直接说影响测试的时间。不知道可行吗?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2015-4-17 13:17
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    7#
     楼主| 发表于 2013-7-2 16:09:06 | 只看该作者
    回复 6# lsekfe
    但是我们公司真的是没有需求文档的,有不明白的地方,我们就是跟开发频繁沟通,交流。最多我只能要到一个使用说明,其他什么文档都没有了。这也是我一直很郁闷的地方,因为写用例必须有期望结果,我们列出好多,不知道的就找开发。这样真的很费时间。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    5 天前
  • 签到天数: 1050 天

    连续签到: 1 天

    [LV.10]测试总司令

    6#
    发表于 2013-7-2 14:38:51 | 只看该作者
    回复  lsekfe
    嗯,明白了,原来问题的根本在于需求文档。
    Aimelyccc 发表于 2013-7-2 14:22


    有文档和没文档真的不一样,以前写过一个测试用例。在没文档的情况下,测到后面我已经测不下去了!只能重新来过!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2015-4-17 13:17
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    5#
     楼主| 发表于 2013-7-2 14:22:18 | 只看该作者
    回复 4# lsekfe
    嗯,明白了,原来问题的根本在于需求文档。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    5 天前
  • 签到天数: 1050 天

    连续签到: 1 天

    [LV.10]测试总司令

    4#
    发表于 2013-7-2 13:24:39 | 只看该作者
    回复  lsekfe
    测试用例的编写依据是需求,我们没有文档性的需求,只能是先把应用自己操作熟练,从而再去整 ...
    Aimelyccc 发表于 2013-7-2 12:19



        如果没有测试需求的话,测试用例确实不是很好写!如果自己要写有点深度的话,必须先要了解下测试的项目。其实还是建议能把需求文档拿到手。不然真的时间很难缩短!要么熟悉软件,要么就是有需求文档!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2015-4-17 13:17
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    3#
     楼主| 发表于 2013-7-2 12:19:32 | 只看该作者
    回复 2# lsekfe
    测试用例的编写依据是需求,我们没有文档性的需求,只能是先把应用自己操作熟练,从而再去整理思路,写测试用例。但即使是这样,测试用例中往往体现不出深度来,有时测试过程中会发现很多用例中没有问题。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    5 天前
  • 签到天数: 1050 天

    连续签到: 1 天

    [LV.10]测试总司令

    2#
    发表于 2013-7-2 10:17:56 | 只看该作者
    在工作中,常常会遇到,测试用例写的不符合实际,执行起来比较费劲。执行测试用例的周期太长。怎样才能快速 ...
    Aimelyccc 发表于 2013-7-1 17:48



        其实一个测试用列的完善不是那么简单的,而且不是每个测试用例都能够套用的,为了有效的缩短测试时间,最好再测试之前完善下自己的测试用例,这样你会觉得之后的测试方面快捷很多!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-26 03:59 , Processed in 0.081058 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表