51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: 默默巫
打印 上一主题 下一主题

[活动]迎五一,庆周年,盖高楼(活动结束)

 关闭 [复制链接]

该用户从未签到

521#
发表于 2009-4-30 09:35:54 | 只看该作者
 (3)实施工程:实施软件开发和验证;
回复 支持 反对

使用道具 举报

该用户从未签到

522#
发表于 2009-4-30 09:36:06 | 只看该作者
集成测试
系统测试

评分

参与人数 1综合技术指数 +15 收起 理由
默默巫 + 15 楼层尾数为5的参与奖

查看全部评分

回复 支持 反对

使用道具 举报

  • TA的每日心情
    郁闷
    2018-8-3 13:59
  • 签到天数: 12 天

    连续签到: 1 天

    [LV.3]测试连长

    523#
    发表于 2009-4-30 09:36:14 | 只看该作者
    3.需求不可能被完全定性。有些是隐性的,有些是约定速成的。另外,需求会不断发生着变化。当用户期望值变高了,软件所依赖的环境变化了,有新的领域出现了等,所以软件在不断地升级中完善着需求。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    524#
    发表于 2009-4-30 09:36:16 | 只看该作者
    7、DRE/DRM分析:通过已有项目历史数据,得到软件生命周期各阶段缺陷注入和排除的模型,用于设定各阶段质量目标,评估测试活动。
      至于缺陷预防,基本上是两个方面:
      1、测试活动尽量提前,通过及时消除开发前期阶段引入的缺陷,防止这些缺陷遗留并放大到后续环节;
      2、通过对已有缺陷进行分析(例如上面的ODC分析等),找出产生这些缺陷的技术上不足和流程上不足,通过对这些不足进行改进,防止类似缺陷再次发生。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2018-8-3 13:59
  • 签到天数: 12 天

    连续签到: 1 天

    [LV.3]测试连长

    525#
    发表于 2009-4-30 09:36:28 | 只看该作者
    3.需求不可能被完全定性。有些是隐性的,有些是约定速成的。另外,需求会不断发生着变化。当用户期望值变高了,软件所依赖的环境变化了,有新的领域出现了等,所以软件在不断地升级中完善着需求。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    526#
    发表于 2009-4-30 09:36:29 | 只看该作者
    、缺陷注入分析:对被测软件注入一些缺陷,通过已有用例进行测试,根据这些刻意注入缺陷的发现情况,判断测试的有效性、充分性,预测软件残留缺陷数
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    527#
    发表于 2009-4-30 09:36:45 | 只看该作者
    (2)风险分析:分析评估所选方案,考虑如何识别和消除风险
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2018-8-3 13:59
  • 签到天数: 12 天

    连续签到: 1 天

    [LV.3]测试连长

    528#
    发表于 2009-4-30 09:36:45 | 只看该作者
    4.需求需要多个部门协调完成。上面说的所有共利益者,有与需求有着密不可分的关系。只有建立起一套需求的管理流程,才能协调好各部门人员的写作关系,而目前这方面的工作很少被人重视,甚至提起。也就当大家都弄不明白需求的时候,测试的埋怨开发的,开发的埋怨产品的,产品的没办法,找老板拍板。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    529#
    发表于 2009-4-30 09:36:51 | 只看该作者
    一个网络游戏中有很多不稳定的因素,这些因素对游戏的影响最终都会在产品中体现出来。检查设计的实现情况,提高系统的稳定性,检测同时在线的玩家的负载限度、查找(定位)BUG,测试游戏的平衡性。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2018-8-3 13:59
  • 签到天数: 12 天

    连续签到: 1 天

    [LV.3]测试连长

    530#
    发表于 2009-4-30 09:36:56 | 只看该作者
    4.需求需要多个部门协调完成。上面说的所有共利益者,有与需求有着密不可分的关系。只有建立起一套需求的管理流程,才能协调好各部门人员的写作关系,而目前这方面的工作很少被人重视,甚至提起。也就当大家都弄不明白需求的时候,测试的埋怨开发的,开发的埋怨产品的,产品的没办法,找老板拍板
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    531#
    发表于 2009-4-30 09:37:00 | 只看该作者
    在大型的MMORPG网络游戏中,系统的性能是一个很大的概念,覆盖面非常广泛,包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等,我们这里重点讨论的负载测试。
    性能测试用来保证产品发布后系统的性能满足用户需求。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    532#
    发表于 2009-4-30 09:37:08 | 只看该作者
    3.需求不可能被完全定性。有些是隐性的,有些是约定速成的。另外,需求会不断发生着变化。当用户期望值变高了,软件所依赖的环境变化了,有新的领域出现了等,所以软件在不断地升级中完善着需求

    评分

    参与人数 1综合技术指数 +15 收起 理由
    默默巫 + 15 楼层尾数为5的参与奖

    查看全部评分

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2018-8-3 13:59
  • 签到天数: 12 天

    连续签到: 1 天

    [LV.3]测试连长

    533#
    发表于 2009-4-30 09:37:16 | 只看该作者
    5.不得不说的山西煤老板的心理。新闻上经常报道煤矿事故,可为什么屡禁不止呢? 这就是暴发户煤老板的心理,他所关注的是一天产出多少煤给他带来多少利益,而安全生产能带来直接利益吗? 虽然存在着事故危险,但数钱的感觉抵消了他们的担忧,况且死几个人,只是赔一些钱,再送些给当地的官员和记者也就没事了。而软件公司的老板也是这种心理,他觉得靠自己空想出来的需求,一样开发,一样赚钱。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    534#
    发表于 2009-4-30 09:37:18 | 只看该作者
      X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试,此后将进行频繁的交接,通过集成最终成为可执行的程序,然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户,也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见,X模型还定位了探索性测试,这是不进行事先计划的特殊类型的测试,这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费,对测试员的熟练程度要求比较高。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2018-8-3 13:59
  • 签到天数: 12 天

    连续签到: 1 天

    [LV.3]测试连长

    535#
    发表于 2009-4-30 09:37:25 | 只看该作者
    5.不得不说的山西煤老板的心理。新闻上经常报道煤矿事故,可为什么屡禁不止呢? 这就是暴发户煤老板的心理,他所关注的是一天产出多少煤给他带来多少利益,而安全生产能带来直接利益吗? 虽然存在着事故危险,但数钱的感觉抵消了他们的担忧,况且死几个人,只是赔一些钱,再送些给当地的官员和记者也就没事了。而软件公司的老板也是这种心理,他觉得靠自己空想出来的需求,一样开发,一样赚钱。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    536#
    发表于 2009-4-30 09:37:25 | 只看该作者
    通过测试得到系统运行时的性能表现,如得到系统运行速度,响应时间,占有系统资源等方面的系统数据。
    虽然从单元测试开始,每一测试步骤都包含性能测试,但只有当系统真正集成后,在真实环境中才能全面、可靠地测试系统性能。
    事实上,要求一个服务器在连续的满负荷运转下不出任何异常,要求它设计的近乎完美,这几乎是不太现实的。服务器本身可以出异常,但是,服务器本身应该被设计得足以健壮,“小病小灾”打不垮它,这就要求服务器在异常处理方面要下很多功夫。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    537#
    发表于 2009-4-30 09:37:35 | 只看该作者
    是模拟实际应用的硬件环境、软件环境及玩家游戏使用过程的系统负荷,长时间或超大负荷的运行测试服务器端,来测试被测试MMORPG服务器的性能、可靠性、稳定性等。目的是在网游投入公测以前,通过可重复的负载测试,了解系统可靠性、系统瓶颈等。以提高软件系统的可靠性,稳定性,减少系统脱机时间和因此带来的损失。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    538#
    发表于 2009-4-30 09:37:49 | 只看该作者
    3.需求不可能被完全定性。有些是隐性的,有些是约定速成的。另外,需求会不断发生着变化。当用户期望值变高了,软件所依赖的环境变化了,有新的领域出现了等,所以软件在不断地升级中完善着需求
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    539#
    发表于 2009-4-30 09:37:59 | 只看该作者
    网络游戏终究是商品而不是艺术品,赚钱永远是厂商追求的目标。
    g)        减少玩家流失,稳定收益。
    玩家离开一个网游的原因很多,让大批玩家中途离开的原因通常有2个:游戏性跟稳定性。其中稳定性是让玩家抱怨最多的,也是最打击玩家的积极性的因素。
    h)        减少公测时间,提前收益。
    很多网游为了游戏性跟稳定性,一般需要内部测试(a测试),外部测试(b测试)6个月的时间以上,还需要公测3~6个月的时间。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2018-8-3 13:59
  • 签到天数: 12 天

    连续签到: 1 天

    [LV.3]测试连长

    540#
    发表于 2009-4-30 09:38:13 | 只看该作者
    我觉得需求应该这样管理:

    .明确需求采集渠道。由市场调查反映用户需要,由产品人员整理,加上其它共利益者的需求,生成原始需求。然后提交技术部门做后续工作。51Testing软

    部门健全,明确责任。不要以为公司小就可省去一些职位。需求分析师,架构师等不可省略,更不能让底层的经验不多者担任此角色。


    .借用一种需求管理工具,来管理从需求采集,分析,变更,查询等。

    需求要细分到具体功能点。只有这样的需求才能生成开发用例或者测试用例。

    5.我觉得理论归理论,操作起来一样很难,可能任何一种管理方法都离不开整个公司的文化,团队建设,氛围等。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-19 02:42 , Processed in 0.086628 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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