51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: lsekfe
打印 上一主题 下一主题

【你来问我来答第54期】:笑傲测试----测试对象的识别与分析(已结束)

[复制链接]
  • TA的每日心情
    难过
    2018-4-27 13:33
  • 签到天数: 69 天

    连续签到: 1 天

    [LV.6]测试旅长

    21#
    发表于 2015-1-8 21:07:43 | 只看该作者
    我的提问怎么没看到,太心塞了
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    昨天 09:06
  • 签到天数: 1051 天

    连续签到: 1 天

    [LV.10]测试总司令

    22#
     楼主| 发表于 2015-1-9 08:49:42 | 只看该作者
    心晴~~ 发表于 2015-1-8 21:07
    我的提问怎么没看到,太心塞了

    可能到了后台 在审核吧~
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2018-4-27 13:33
  • 签到天数: 69 天

    连续签到: 1 天

    [LV.6]测试旅长

    23#
    发表于 2015-1-9 08:59:52 | 只看该作者
    lsekfe 发表于 2015-1-9 08:49
    可能到了后台 在审核吧~

    刚刚才看到,呵呵
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2024-11-5 16:17
  • 签到天数: 170 天

    连续签到: 1 天

    [LV.7]测试师长

    24#
    发表于 2015-1-9 13:57:22 | 只看该作者
    我现在负责测试项目是上万人在用的企业EIP管理平台系统,目前准备替换原来的门户管理系统,目前功能需求实现是成熟了,只要是是否满足大量用户的使用,性能的稳定,针对性能测试方面我应该做哪些准备啊?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    擦汗
    2017-10-27 14:21
  • 签到天数: 306 天

    连续签到: 1 天

    [LV.8]测试军长

    25#
    发表于 2015-1-9 16:18:47 | 只看该作者
    您在测试的过程中,关于碎片化有什么好的处理方法,可以分享一下吗?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    擦汗
    2016-11-22 14:32
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    26#
    发表于 2015-1-10 09:14:48 | 只看该作者
    我想问下jmeter分布式测试,响应数据为空是咋回事呢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    27#
    发表于 2015-1-12 13:16:32 | 只看该作者
    Miss_love 发表于 2015-1-8 19:01
    你好、1、针对B/S架构测试,如何对session和cookies进行测试?

    Session和cookie的测试方法并没有什么不同,主要区别在于测试环境的不同(Session在服务器测试,而cookie的测试则在浏览器)
    以下以Session举例,cookie可参考。
    1. 黑盒测试
       1.1黑盒对于Session并没有太好的测试方式。主测试过程为2条:
          1.存储Session(通常是通过事件来触发,如未检索到页面访问请求中的Session ID)-->读取Session(也是通过事件触发,如检索到Session ID)
          2.存储Session-->删除Session-->页面请求消息到来
       1.2测试范围:
          Session的主要测试范围取决于需求,也就是‘存什么’和‘删什么’,通常都是存一些地址,用户信息以及时间的东东。
       1.3其他测试范围(可选):
         1.关联功能测试:如,Session 的 Time out时间测试
         2. 容错测试: 如,B/S会话过程中,消息中断/回复测试
         3. 兼容测试:如,主流的不同浏览器内核
      
    2. 自动化测试
        2.1.自动化测试主要是通过在代码中打测试桩来实现,如,已知服务器某一事件存储Session ID,然后在会话结束的代码前打入测试桩Session["ID"].tostring(),再与工具的验证点进行匹配即可。必要时,也会在浏览器端进行相同的验证。
        至于Session的基础属性,如Time Out,也可以通过直接在代码中打印logs的方式进行验证。(当然,一些潜规则还是需要简单了解,比如,如果Time Out没有设置,则为20min)
        2.2.系统的自动化测试没有接触过,不做分析。
    3.Session 和cookie的区别
       3.1 两者在原理上没有区别,但因为各自运行环境和功能目的不同,导致集合和属性有一些差异,这部分建议在测试之前提前学习。
       3.2 两者在测试范围上,除功能测试外,其他类型的测试在侧重点上有差异,建议根据产品的最终用户环境来进行取舍(如,通常情况下,Session 测试更关注性能,而cookie测试更关注兼容性)
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    28#
    发表于 2015-1-12 14:21:30 | 只看该作者
    心晴~~ 发表于 2015-1-8 21:00
    大神,我想请教一下如何写erp的测试用例,我现在也是在测试自己公司用的erp,但由于平常测试偏向于组装测试 ...

    1. 每个测试团队/个人,选择的测试方法往往与客观环境息息相关,所以,我告诉你的东西并不一定适合你,只希望能给你一些思考方式,你再通过自身结合实际情况,创造出适合你自己的测试方法。

    2. 根据你提供的已有测试信息,建议使用测试目的为导向的测试分类(即首先确认先确认达到什么样的测试目的,再选择测试方法,最后将相似的测试方法进行分类汇总)。
        可参考的测试分类:测试要点控制,测试数据控制,测试流程控制(鉴于以往测试中,未进行较小粒度的测试类型划分,且测试系统相对你个人来说,已经较为熟悉,故不建议使用测试用例控制)
        测试要点控制:复杂场景流/数据清洗,均可使用。建议以思维导图的模型为基础,利用树枝图的特点,将复杂的测试对象按照不同的属性逐层分析(分析的最小粒度标准为简单易懂的元素),在重新分类汇总以后,可以通过组合方法(两两,正交)得到测试要点的场景流和数据流(组合的过程可以在思维导图中完成,也可以使用表格工具完成(如,Excel))
        测试数据控制:有明确的输出验证标准时,还是使用你原先的‘测试流程控制’,如,在ERP中新开发一张客户报表,已有客户数据库及客户历史非ERP报表时,使用测试数据流控制的方式可以更高效。(但是开发人员排查bug的时间会比较长)
        测试流程控制:建议分为2类
                               2.1 简单的ERP功能需求:在需求文档已经足够支撑开发/测试时,并不需要更多的测试策略和设计。此时可以直接‘按需测试’即可。(如,页面添加独立的字段,且与其他页面关联较小的需求)
                               2.2 验收测试中的主流程测试:首先需要清理一份较为完整详细的ERP功能结构图(建议以页面为骨架,页面元素(列表、视图、最好包含字段)为最小颗粒度),在图中尽可能标识出的各个元素关联关系(同一页面元素的关联可以不用标识(复杂的可以标记一下),不同页面元素的关联关系是标识的重点)。 需求开发时,将需求功能刷新到ERP结构图中,可以框定该需求功能的关联测试范围,进而得到验收测试的主流程测试场景(此部分也建议使用思维导图完成)

    3. 测试方法的拓展:当对ERP业务知识了解更深入时,可以调整原有的测试方法。如,添加某个功能的权限,标准测试模型是测试授予/取消权限以及各种授权方式(岗位/角色授权)等;但是如果熟悉ERP权限配置的文件(.XML/.config)以及功能主键(如function id)等,就可以通过检查配置文件和数据库的方式来进行检查测试,而不需要切入ERP复杂的权限场景流中进行逐一的功能测试。(注意:并不是说,在验收测试中,就可以直接拿掉此功能主流程的测试,只是在功能测试中裁剪掉而已)

    备注:公司用例和标准模板不太方便粘贴,请见谅。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2018-4-27 13:33
  • 签到天数: 69 天

    连续签到: 1 天

    [LV.6]测试旅长

    29#
    发表于 2015-1-12 16:01:06 | 只看该作者
    Jackc大神,您的回复已经很细心了,教给我了大体测试方向和方法,帮助我理清现在测试时较混乱的问题,非常谢谢!我需要多一点的时间把您教的内容好好消化一下内容撒花!撒花,再次表示感谢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    30#
    发表于 2015-1-12 17:01:47 | 只看该作者
    zhanghl820716 发表于 2015-1-9 13:57
    我现在负责测试项目是上万人在用的企业EIP管理平台系统,目前准备替换原来的门户管理系统,目前功能需求实 ...

    其实,万人用户这个测试依据其实没有太大的意义,关键条件依然是同时在线的用户数

    1. 输出性能测试标准
        1.1 收集客户使用系统的业务背景资料,主要是客户是怎么用系统的。
              比如,1万用户,每分钟在线的峰值是多少?客户使用频率最高的功能是哪些,各自大约占比为多少?
              这部分资料将为你的性能测试提供重要的评估指标,也将为你在选则性能测试的功能范围提供基础的测试依据。
              理论公式(看看就行,其实它算的相当不准,最终还是要根据收集的资料,对结果数据作二次调整):每分钟在线用户数=用户总数/用户总登陆时间*单个用户操作时间
       1.2 整理服务器资源消耗较大的功能清单。如,EIP中的多层的数据清洗,以及一些复杂界面(复合报表,图形)的加载等等。
       1.3 如你们的EIP是分布式部署,则还需要在1.1&1.2的基础上,按照功能部署的服务器和数据库整理出功能分布清单。功能分布清单主要是在复杂系统中,提供可用于测试目标对象的测试重点。

    2. 分析其他影响因素,着眼点在于服务器关联信息是否存在性能风险。如内网/外网不同的服务器,性能可能不同。

    3. 整理测试工具,哪些可以用开源工具,哪些需要自行开发以及工具需求,最好在测试前期拟定计划并推动。

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    31#
    发表于 2015-1-12 17:52:44 | 只看该作者
    地壳 发表于 2015-1-9 16:18
    您在测试的过程中,关于碎片化有什么好的处理方法,可以分享一下吗?

    你的这个问题,之前的同学已经提到了。
    说实话,移动端的碎片化并没有完美的解决方案,因为完美答案是:在客户可能使用的所有环境中进行最低为验收级别的测试活动(可能除了IOS APP,其他APP基本不能做到这一点)
    以Andorid为例,在Android的开放平台下,我们看上去只有1种方式来为用户手机进行分类汇总:手机型号(其实IOS也是用这个分类来进行兼容测试的,只是IOS型号较少而已)

    没有办法使用标准的方式来框定测试范围,我们只能在容忍部分已知风险下,来进行更大粒度的终端分类:生厂商品牌-->系统版本(品牌版本)--->产品型号--->显示屏规格
    分类原理来源于bugs严重级别评估标准中的’客户发现率‘为基础依据,整理出的测试标准和范围。


    其实国内外在早2年已经识别到这个问题,目前期望于通过云来解决设备共享问题,如东软的易测云,它们虽然不能完全解决移动端目前的碎片化问题(完成整个Android碎片化测试需要几百台不同的移动终端,我个人认为目前还没有测试团队能够达到这个测试环境的要求)

    备注:
    假设终端数量超过了测试团队的人力资源,则可以在用户使用频率较低的终端只验证主要功能,如安装/卸载等



    回复 支持 反对

    使用道具 举报

    该用户从未签到

    32#
    发表于 2015-1-12 18:07:18 | 只看该作者
    wangyixiong 发表于 2015-1-10 09:14
    我想问下jmeter分布式测试,响应数据为空是咋回事呢

    1. 检查一下controller 和agent 的端口号是否被占用。(查看端口使用APPID可以百度)
    2. 检查防火墙
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2018-4-27 13:33
  • 签到天数: 69 天

    连续签到: 1 天

    [LV.6]测试旅长

    33#
    发表于 2015-1-14 10:19:24 | 只看该作者
    Jackc大神,我们公司不是专门的软件公司,现在要开发一款APP,需求只是一些简单的功能点,现在老大说我这边要控制APP产品的质量,我该如何控制呢?压力好大的感觉,也不知道如何控制,感觉完全没有一个标准点去控制?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    34#
    发表于 2015-1-14 15:41:12 | 只看该作者
    请问一下,手机应用APP需要做整机兼容的测试吗?
    如果要做的话,市面上这么多手机品牌,岂不是成本很高?
    是否有需要去做这个兼容呢?
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2020-3-26 08:30
  • 签到天数: 3 天

    连续签到: 2 天

    [LV.2]测试排长

    35#
    发表于 2015-1-15 16:45:42 | 只看该作者
    请问一下,我是测试电力产品的,如电力仪表及电力系统类的,测试电力仪表产品居多,我们公司居多是手工测试,有什么好的建议类,这么测试下去感觉到有些迷茫。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    36#
    发表于 2015-1-15 16:47:28 | 只看该作者
    心晴~~ 发表于 2015-1-14 10:19
    Jackc大神,我们公司不是专门的软件公司,现在要开发一款APP,需求只是一些简单的功能点,现在老大说我这边 ...

    1. 你老大这样说,其实是他对到底怎么控制质量不清楚。不过优秀tester应该具有一定的QA水平。
    2. 简易需求文档一般都能支撑测试策略的实例化,如,测试范围、测试执行实例化(测试方法、测试环境、测试工具等)、测试里程碑等
    3. 简易需求文档通常不能支撑测试执行的细节部分,如,核心逻辑的测试执行实例化、用户感受用例的实例化等


    供参考的测试前期步骤:
    1. 需求分析:
        1.1 需求分类:
              先将需求文档的各个功能划分出来(我通常是按照物理存储数据的用途来分类,如,客户信息、消息信息、配置信息等)。并在每个类型下根据
    需求文档描述的内容,再向下拆分1,2个层次(粒度不需要很细,比如最小粒度为页面或者控件类型就OK了,不需要把同类控件的每个元素都列举出来)
        1.2 需求分析:
              根据1.1的目录,整理出实现效果可能存在二义性的部分(如,某类消息数据存储,既可以存在服务器上,也可以存在本地,而需求文档中未指明实现方式)
              将二义性的部分与设计或者开发人员沟通,确认实现效果。
    2. 测试实例化:
        2.1 先框定需要实例化的测试类型(功能、性能、本地化等),如果某类测试需要前置条件才能实现,将前置条件作为风险写明,而此类测试作为变量安排在后期的测试生命周期里。
              测试类型的选择不难,主要还是需要你自己来度量测试的深度(通常可以和决策者以及开发人员沟通着来制定,如性能部分,只做长周期测试,不做负载测试等。你所有的沟通筹码只有2枚:成本和价值)
       2.2 根据2.1框定范围,细化非功能测试的内容。如工具化使用哪种工具,碎片化选择哪些平台等)
    3. 功能测试用例设计:
        不建议使用测试用例,可以考虑使用测试要点来实现。粒度到可以清晰指导测试执行即可,如,标准文档编辑框(它可以代替文档框的字符类型、字符长度、存储等文本框的测试用例)
    4.  注意事项:
         4.1 在设计出口标准时,多和决策者/设计沟通,了解客户使用场景以及尽可能理解用户的实际期望。
         4.2 此类项目需要频繁与开发人员沟通,在沟通过程中,最好能经常站在用户角度多想一下(很多时候,开发人员能做少就不愿意做多,所以在细节实现上,经常出现功能实现,但使用不便的情况)
         4.3 测试里程碑多和开发Leader沟通,根据开发进度来调整测试进度。
         4.4 如果涉及需要开发辅助的部分,如帮忙写个测试工具什么的。尽早与开发沟通,以便双方明确需求,以及方便开发安排计划。
         4.5 这类项目都建议使用Monkey Test,具体的实例化可以与开发共同完成。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    37#
    发表于 2015-1-15 16:55:59 | 只看该作者
    huyouyou1031 发表于 2015-1-14 15:41
    请问一下,手机应用APP需要做整机兼容的测试吗?
    如果要做的话,市面上这么多手机品牌,岂不是成本很高?
    ...

    其实目前做兼容测试的公司并不多。如果比较关注成本,可以在熟悉平台后,引入一些等价类策略来减低测试成本(如,OS高版本兼容低版本,屏幕分辨率比例占比高低 等。)
    备注:
    这类的等价类策略都会存在一些风险,比如android 4.0 测试通过,实际上并不能完全保证2.3就没有问题,关键还是要看APP在实际开发过程中是否使用调用了4.0新增的API和方法。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    难过
    2018-4-27 13:33
  • 签到天数: 69 天

    连续签到: 1 天

    [LV.6]测试旅长

    38#
    发表于 2015-1-15 21:00:21 | 只看该作者
    Jackc 发表于 2015-1-15 16:47
    1. 你老大这样说,其实是他对到底怎么控制质量不清楚。不过优秀tester应该具有一定的QA水平。
    2. 简易需 ...

    每次jackc大神的回复都很详细,很感谢!读了几遍后,感觉我现阶段只实现了功能点的细分后,就开始手工测试,测试时会记录每个版本的功能点的测试点和发现的bug(我发现记录了这两项后,做回归测试就方便一点了);性能部分,是要测试接口处理请求的响应时间长短吗?我现在测试app时,会发现点击某个按钮,实现某个功能(如取消订单那功能),很久才会提示成功,我现在不知道是服务端接口的问题,还是app前端的问题,能给一些建议吗?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    39#
    发表于 2015-1-16 14:25:22 | 只看该作者
    pilottest 发表于 2015-1-15 16:45
    请问一下,我是测试电力产品的,如电力仪表及电力系统类的,测试电力仪表产品居多,我们公司居多是手工测试 ...

    我以前 也做过 类似 产品 的 测试,不过是 软硬件 结合
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    40#
    发表于 2015-1-17 09:14:10 | 只看该作者
    心晴~~ 发表于 2015-1-15 21:00
    每次jackc大神的回复都很详细,很感谢!读了几遍后,感觉我现阶段只实现了功能点的细分后,就开始手 ...

    ‘性能部分,是要测试接口处理请求的响应时间长短吗?’
    手持终端上比较常用的(性价比较高)性能测试包括:
       * 长周期(LPT):持续运行APP(monkey 可以实现)
        *功耗(PCT):包括电量、内存、流量等(大部分都有现成API或规模化工具,简单开发后可实现。(也可以通过其他方式来间接实现,如反复运行/关闭APP,查看是否存在内存泄露等)
        *响应时间(RTT):程序应用在某个功能上的处理时间,具体测试方法也是五花八门。
                                 1. 最常规的方式是直接在写测试桩,这样基本能得到所有期望的信息。如,你提到的APP与服务器会话的功能,只需要3类测试桩打印出时间logs就可以辅助你定位问题根源:APP上层指令触发会话的事件的时间、APP每次收/发会话消息的时间。如果对协议格式内容有一定了解,也可以将会话内容logs出来,分析head或者body是否存在冗余。
                                 2. 先负载,再做RTT。主要用于存在性能风险的APP功能,如列表页面加载。这类测试在不使用测试桩的方法下,可以使用录像回放的方式来实现。(超过1S的APP响应事件其实都可以用纯黑盒实现)
                                3. 参照物比对。通常在没有性能标准的情况下,可以选择一些业内知名或者成熟的相似APP作为参照物,在相同环境下比对二者之间的差距。
                                (备注:3.1 参照物比对的方式,需要尽量保证2者环境的一致性;因无法做到完全一致,故会容忍一定比例的差异数据以及需要采集多次测试数据
                                             3.2 参照物比对的方式,测试人员需尽量站在用户角度作测试结果判断。如两个APP实现的功能基本一致,但是选择的协议不同,导致测试结果出现差异,也属于bugs,需决策者审核后,才能进入不修复流程,而非开发人员可直接进行非bugs判定。)
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-27 05:53 , Processed in 0.075571 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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