从登陆测试谈测试用例

标签(空格分隔): 登陆测试安全


谈谈登陆测试:

可能你会说,“用户登陆”这个测试对象也有点太简单了吧,我只要找一个用户,让他在界面上输入用户名和密码,而后点击“确 认”按钮,验证一下是否登陆成功就能够了。的确,这构成了一个最基本、最典型的测试用例,这也是终端用户在使用系统时最典 型的场景。
可是做为测试工程师,你的目标是要保证系统在各类应用场景下的功能是符合设计要求的,因此你须要考虑的测试用例就须要更
多、更全面,因而你可能会根据“用户登陆”功能的需求描述,结合等价类划分和边界值分析方法来设计一系列的测试用例。性能

等价类,边界值:

  • 那什么是等价类划分和边界值分析方法呢?首先,这两者都隶属于最经常使用、最典型、也是最重要的黑盒测试方法。
    等价类划分方法,是将全部可能的输入数据划分红若干个子集,在每一个子集中,若是任意一个输入数据对于揭露程序中潜在错
    误都具备同等效果,那么这样的子集就构成了一个等价类。后续只要从每一个等价类中任意选取一个值进行测试,就能够用少许
    具备表明性的测试输入取得较好的测试覆盖结果。
  • 边界值分析方法,是选取输入、输出的边界值进行测试。由于一般大量的软件错误是发生在输入或输出范围的边界上,因此需
    要对边界值进行重点测试,一般选取正好等于、刚刚大于或刚刚小于边界的值做为测试数据
  • 从方法论上能够看出来,边界值分析是对等价类划分的补充,因此这两种测试方法常常结合起来使用

如今,针对“用户登陆”功能,基于等价类划分和边界值分析方法,咱们设计的测试用例包括:

image.png-454.1kB
列出这些测试用例后,你可能已经以为比较满意了,由于你感受已经把本身的测试知识都用在这些用例设计中了。
的确,上面的测试用例集已经涵盖了主要的功能测试场景。可是在一个优秀的测试工程师眼中,这些用例只能达到勉强及格的标
准。
什么?才刚刚及格?若是你有这个想法,那我建议你在继续看下面的内容前,先仔细思考一下,这些测试用例是否真的还须要扩
充。
如今,分享一下有经验的测试工程师会再增长的测试用例:
image.png-536.6kB
看完这些用例,你可能会说:“哇塞,原来一个简简单单的登陆功能竟然有这么多须要测试的点”。可是,你别高兴得太早,“用
户登陆”功能的测试还没结束。
虽然改进后的测试用例集相比以前的测试覆盖率的确已经提升了不少,可是站在资深测试人员的角度来看,还有不少用例须要设
计。
经我这么一说,你可能已经发现,上面全部的测试用例设计都是围绕显式功能性需求的验证展开的,换句话说,这些用例都是直接
针对“用户登陆”功能的功能性进行验证和测试的。
可是,一个质量过硬的软件系统,除了显式功能性需求之外,其余的非功能性需求即隐式功能性需求也是极其关键的。 显式功能性需求(Functional requirement)的含义从字面上就能够很好地理解,指的是软件自己须要实现的具体功能, 好比“正
经常使用户使用正确的用户名和密码能够成功登陆”、“非注册用户没法登陆”等,这都是属于典型的显式功能性需求描述。
那什么是非功能性需求(Non-functional requirement)呢?从软件测试的维度来看,非功能性需求主要涉及安全性、性能以及兼 容性三大方面。 在上面全部的测试用例设计中,咱们彻底没有考虑对非功能性需求的测试,但这些每每是决定软件质量的关键因 素。
明白了非功能性需求测试的重要性后,你能够先思考一下还须要设计哪些测试用例,而后再来看看我会给出哪些用例,相信这种方
式对你的帮助会更大。测试

安全测试用例:

image.png-601.1kB

性能测试用例:

image.png-264.5kB

兼容性测试用例:

image.png-247.5kB

说到这里,你还会以为“用户登陆”功能的测试很是简单、不值一提么?一个看似简单的功能测试,竟然涵盖了如此多的测试用
例,除了要覆盖明确的功能性需求,还须要考虑其余诸多的非功能性需求。
另外,经过这些测试用例的设计,你也能够发现,一个优秀的测试工程师必须具备很宽广的知识面,若是你不能对被测系统的设计 有深刻的理解、不明白安全攻击的基本原理、没有掌握性能测试的基本设计方法,很难设计出“有的放矢”的测试用例。
经过“用户登陆”功能测试这个实例,我但愿能够激发你对测试更多的思考,而且开拓你设计测试用例的思路,以达到抛砖引玉的
效果。
看完了这些测试用例,你可能会说还有一些遗漏的测试点没有覆盖到,这个功能的测试点还不够全面。ui

  • 测试的不可穷尽性,即绝大多数状况下,是不可能进行穷尽测试的。
    所谓的“穷尽测试”是指包含了软件输入值和前提条件全部可能组合的测试方法,完成穷尽测试的系统里应该不残留任何未知的软 件缺陷。 由于若是有未知的软件缺陷,你能够经过作更多的测试来找到它们,也就是说你的测试尚未穷尽。
    可是,在绝大多数的软件工程实践中,测试因为受限于时间成本和经济成本,是不可能去穷尽全部可能的组合的,而是采用基于风
    险驱动的模式,有所侧重地选择测试范围和设计测试用例,以寻求缺陷风险和研发成本之间的平衡。
  • 总结 首先,对于高质量的软件测试,用例设计不只须要考虑明确的显式功能性需求,还要涉及兼容性、安全性和性能等一系列的非功能 性需求,这些非功能性需求对软件系统的质量有着举足轻重的做用。 其次,优秀的测试工程师必须具备宽广的知识面,才能设计出有针对性、更易于发现问题的测试用例。 最后,软件测试的用例设计是不可穷尽的,工程实践中不免受制于时间成本和经济成本,因此优秀的测试工程师须要兼顾缺陷风险 和研发成本之间的平衡。