• 测试用例设计要注意的问题


    >>测试前:

     

    1)对测试目的有一个清晰的认知

    无论是对任何软件或是模块,编写测试用例前,一定要弄清原始需求。最好能与提出测试需求的人,有一次比较清晰的交流,这样可以避免测试遗漏点。

    2熟悉产品的功能测试点

     

    编写测试用例,一定要覆盖所有需求点,这是我们最基本的工作,一名测试人员专业度的体现。对于功能测试需求,一定要细化到每一个使用细节,并通过测试用例展现出来。

    3熟悉模块原理,避免“互相影响”问题的产生

     

    熟悉模块原理后,注意易于分析软件模块的关联性问题。对于一款软件来说,尤其是大型软件,需要由多个模块共同组合而成。而在测试时,你会发现,软件越大,耦合越大,“互相影响”的可能性就会越高。在设计用例时,如果我们单单从模块本身考虑,不注重“共同作用”的问题,很可能会对其他模块造成“意外伤害”。

    4关注用户场景问题和上网问题

     

    在设计测试用例前,我们还应考虑应用安装在不同设备上,是否会产生使用用户场景不同,而获得的体验不同的问题。另外,网速对软件使用本身也会造成影响,在设计用例时,也需要考虑在内。

    5)不可马虎的关键测试用例设计

     

    在写测试用例时,还有一个值得注意的就是关键测试用例。何为关键测试用例?你可以把它看成是对系统最重要的功能测试用例。

    举个例子:对于手机里的计算器来说,如果他不能执行“3+3=?”这个问题,那么基本这个软件也就“废了”。

    所以,系统的用途决定了关键测试用例的内容。也就是说,关键测试用例必须服务于系统,并且要符合系统用途的要求。包括“正向”要求,比如“3+3”问题。当然,也会包括“逆向”要求。比如在输入银行密码时,一般最多可以错3次,否则就吞卡处理了。

    >>编写测试用例时:

     

    1)构建测试用例框架

     

    一个测试用例框架的构建,往往反映了一个测试人员对软件产品的熟知度,以及整体思路的专业度。而用例框架也是从大到小划分下来,依次是:UI界面、功能、容错、兼容、性能等几个大类。我们需要根据软件的逻辑等,将每个大类划分成小类,后细分到测试点。

    2)测试步骤的设计

     

    测试用例可以写的很详细,也可以写的比较简单。这当然取决于公司的要求,也取决于软件本身的复杂程度。

    关于这个问题,我想说两点心得体会:一是如果步骤过于粗糙很容易出现漏测问题;二是写的过于细致,可能耗时耗力,并且会限制执行人员的思维

    所以,在设计用例时,一定要把握好详细程度的分寸,符合产品本身的整体特点即可。

    >>测试用例设计方法及思考

     

    软件测试用例的基本要素,包括:测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。测试用例设计常用的7种方法,包括:等价类、边界值、场景设计法、判定表、因果图、正交法、错误猜测法。

    关于上述2个内容,我们之前的内容中已经讲解了,再此就不赘述了。不清楚的同学可以翻看我们之前的内容,或者上百度查找,都是可以的。

    下面说说我关于测试用例设计的一些思考。

    1)切记产品测试的主要目标

     

    测试新手们先思考一下产品测试的本质是什么。

    笔者以为,产品测试的本质是发现功能、流程、界面等现存的产品问题,而不是提出功能或界面的产品优化方案。不知道大家认不认可?

    虽然我们的工作也包含给出功能或界面的优化建议,但毕竟,这不是我们的主要任务。根据我的亲身经历,我认为,测试新手往往容易出现这种“本末倒置”的行为:花大量时间去思考如何优化,而非找出产品所隐含的bug。

    为什么会这样呢?笔者以为,这主要是由2个原因造成的。

    一是产品本身存在的优化空间很大。试想,如果你拿到一款完全不符合时下主流风格的产品,是否也会想给他提各种优化意见?这就不难理解测试新手在遇到一款设计界面糟糕的产品时,容易出现跑偏的问题了。

    另一个是思维方式没有及时转变。对于测试新手来说,基于对固有事物的认知,我们往往会带有策划思维,或者追求“圆满性”思维看问题,这两问题也容易造成本末倒置的问题。

    所以,对于测试人员来说,我们必须谨记测试目标,坚持以‘提bug为主,提需求为辅’的状态,来确保我们的工作进度与审美之间的两不误。

    2注意用词精准问题

     

    作为软件上线前的最后一道工序,软件测试既是对产品质量的检测,也是对普通用户的负责。因此,协助开发人员查漏补缺是我们的常态。这就不得不提到沟通问题了。

    之所以笔者要写用词精准问题,主要也是为了解决由于沟通不到位,造成测试人员与开发人员“剑拔弩张”的问题。那么,日常工作我们应该如何合理的提问呢?笔者以为,可以用这个方法来描述问题:产品漏洞是什么+问题在哪里+严重程度+解决办法或意见。

    例如,邮箱登录页面有一个bug。当我在密码栏输入“777777”时,无论原密码是什么,都能打开这个邮箱。这个类似于“万能钥匙”的密码可能会导致邮箱信息泄露,非常严重,请在1-2个工作日内解决。建议检查对应区域代码条件设置是否出现遗漏。

    写在最后

     

    俗话说,以人为鉴,可以明得失;以史为鉴,可以知兴替。希望测试小伙伴们可以通过借鉴别人的经验,查漏补缺,使自己的测试之路走的更通畅,工作更顺利~

    不积跬步,无以至千里;不积小流,无以成江海。
  • 相关阅读:
    FreeSWITCH呼叫参数之sip_cid_type
    FreeSWITCH收到重复的DTMF信号
    ajaxupload.js调用始终进入error回调
    df -h和du -sh显示结果不一样的原因及解决
    公网用户接入NAT后面的freeswitch配置
    Jedis工具类(含分布式锁的调用和释放)
    【读书笔记《Android游戏编程之从零开始》】19.游戏开发基础(游戏音乐与音效)
    【读书笔记《Android游戏编程之从零开始》】18.游戏开发基础(碰撞检测)
    【读书笔记《Android游戏编程之从零开始》】17.游戏开发基础(游戏适屏的简述和作用、让游戏主角动起来)
    【读书笔记《Android游戏编程之从零开始》】16.游戏开发基础(动画)
  • 原文地址:https://www.cnblogs.com/xuezhimin-esage-2020/p/14149852.html
Copyright © 2020-2023  润新知