2016-11-09 15:52:34 zstack_org 阅读数 1561
  • JMETER 性能测试入门到项目实战视频课程

    1、本课程针对JMETER软件性能测试八大组件:配置元件、前置处理器、定时器、sampler(采样器)、后 置处理器、断言、监听器以及逻辑控制器等内容全方位讲解。 2、参数化、badboy测试脚本开发以及录制方法,正则表达式之Regextester工具使用、JMETER 组件作 用域等知识点讲解。 3、本课程注重实践每一个知识点都有相对应的实例,本书覆盖的实例多达上百个,提高学员的动手能 力和解决问题能力。 4、区块链之币币交易所资管系统性能测试,登录、交易买入、交易卖出等测试场景设计、脚本开发/调试、数据 准备、性能调优、性能测试报告。       5、性能测试流程和性能瓶颈定位等知识讲解。

    174732 人正在学习 去看看 陈槐

前各个软件公司都很重视自动化软件测试。甚至会把软件测试自动化率(自动化测试用例占整个测试用例的比例)作为软件测试人员(也叫质量保证工程师)绩效考核的内容之一。追求自动化测试比例的初衷是很好的,但是不顾软件产品的实际情况和软件测试人员的情况,而过分追求高的测试自动化比例,会得到适得其反的效果。我们常常会听到某软件的自动化测试率高达70~80%,可是还是不得不聘请大量的测试人员来进行手动测试。这在无形之中把软件测试引入了误区。

ZStack的测试架构师认为,软件自动化测试的好坏可以用软件缺陷的发现的比率来衡量。换句话说如果整个系统的自动化测试比例达到80%,那么通过自动化测试发现软件缺陷的数量应该达到甚至超过全部软件缺陷数量的80%。举个例子,iSCSI主存储是即将发布的ZStack 0.7版本的重要功能。ZStack现有的自动化测试用例在没有修改一行代码的情况下,就可以用于测试iSCSI主存储的功能。之前开发人员手动测试没有发现的软件缺陷,但是用自动化测试用例发现了5个缺陷。这个就是非常有效的自动化测试用例。

ZStack对软件质量非常看重,因为我们深知人是最聪明也是最不可靠的(以后我们也许可以探讨一下人性与软件测试的相关话题),所以从整个软件设计的开始,ZStack就决定尽可能地依靠全自动的测试手段来探测各种可能出现的软件缺陷。

传统的自动化测试有一个优势就是每轮测试都会严格执行之前定义好的全部测试用例,无一遗漏。通过对前后测试结果的比较,就可以得出质量的变化情况。不过这个优势也是它的弱点。设计软件测试的人员都知道,由于无法穷举所有的测试可能,所以预先设计的测试用例也只能覆盖一部分最常见(或者说是测试人员最希望测试到)的领域。那么对于没有测试到的领域就无法确定其是否存在软件缺陷。这个问题该怎么破呢?为此,ZStack的自动化测试特别引入了一种特别的测试--基于模型的测试(Model-based Testing)。

基于模型的测试是一种人工智能的测试方法,可以用于自动的构造测试场景和测试用例。它要求测试人员首先基于软件功能构造出各种模型(或者叫做行为),然后制定行为和行为之间的关系以及行为和系统的关系(有限状态机),之后自动测试系统就可以智能的根据当前的被测系统的状态(场景)以及预设的规则,选择下一步要执行的行为。理论上这种测试方法可以尽可能的遍历被测试系统中各种可能经历的行为链,从而极大的提高了测试覆盖率。由于它每次执行的路径和以往不同,所以可以构造出完全不同的测试用例,我们也可以称之为智能的软件测试。

下面,我们来大致看看ZStack是怎么构造基于模型的测试的。不过首先我们要说明的是,整个基于模型测试的难点在于提取测试模型,以及编写测试模型验证代码,而非基于模型的测试框架本身和模型算法。所以以后遇到推销基于模型测试“框架”的人,千万不要觉得他们牛的一塌糊涂,真正牛的是实现具体测试的人,而非框架本身。实现测试系统的工程师才是真正的英雄。换句话说,虽然现实中有一些现成的基于模型的测试的框架,但是如果其他IaaS想要重现ZStack的智能测试也绝非易事。

ZStack基于模型的测试首先就是要把各种IaaS操作定义成模型。这里我们拿虚拟机实例的各种操作举例。虚拟机实例通常只有4个状态,状态和状态之间可以定义标准的操作。把状态和操作画出来后,我们就得到了虚拟机实例的状态迁移图(有限状态机)。可以看到上图中Running和Stopped的状态之间可以通过stop和start操作做成状态环。那么智能测试就可以根据预先设定的规则,可能会让虚拟机在这个环里做有限的测试。这一个看起来好像很简单,但是要知道IaaS里面还有很多其他资源的状态迁移图。而且很多资源之间是有相互依赖关系的,例如在某些系统中只有虚拟机处于Stopped的状态才可以做磁盘快照。而且用户在操作IaaS的时候,也不会只做虚拟机状态的改变,通常会和其他资源的actions混合操作。所有当把所有资源的迁移图画完,就会发现整个IaaS的场景和可选的行为之间的关系还是非常非常复杂的。ZStack的测试工程师可是花费了不少的时间来完成这项艰巨的工作。

当创造完场景和行为关系图后,智能测试就可以开始最初的测试工作。一开始的时候,它的智力水平并不高,只能从当前可执行的所有操作中随机的选择一个操作。极端情况,这可能会导致它一直在虚拟机实例的操作中绕圈子,而有些操作从来就没有执行过。慢慢的ZStack工程师就开始给他添加了两个更高的智慧:公平调度算法和基于历史测试路径的调度算法。

公平调度算法会让智能测试系统尽量选择最少执行的行为作为下一个操作。

而基于历史测试路径的算法可以让智能系统选择曾经没有测试过的路径。有了这两种更加智能的调度算法,智能测试系统也就可以更好的发挥它的能力,未来ZStack的测试工程师们还会设计出一些更高级的复合测试算法,来增加智能测试系统的智商。除了发现一些常规的问题外,通过基于模型的测试还发现了不少我们称之为Corner Case的缺陷,它们可能是90%的ZStack用户永远也不会触发的问题。虽说是corner case,但是一旦在开发的阶段没有发现,等到用户遇到的时候,就会花费很大的力气来修复,有一些可能还是致命的。所以这种基于模型的智能测试给ZStack带来了很大的好处。

基于模型的测试和ZStack的另外两大自动化测试系统:集成测试和系统测试构成了ZStack质量控制的三驾马车。在当今DevOps当道的今天,我们希望ZStack的测试和研发投入比力求做到1:1(以后我们也许可以和大家交流为什么纯粹的靠开发人员来做测试是有问题的) ,我们希望把软件质量永远放在ZStack的第一位。

希望今天浅析的ZStack智能测试方法能给广大软件质量保证师从实践角度带来一些好的想法。最后我们想要感谢全世界的软件测试工程师,感谢你们在每一件软件产品后面付出的辛苦努力!


2018-10-25 16:28:31 qq_39758812 阅读数 3339
  • JMETER 性能测试入门到项目实战视频课程

    1、本课程针对JMETER软件性能测试八大组件:配置元件、前置处理器、定时器、sampler(采样器)、后 置处理器、断言、监听器以及逻辑控制器等内容全方位讲解。 2、参数化、badboy测试脚本开发以及录制方法,正则表达式之Regextester工具使用、JMETER 组件作 用域等知识点讲解。 3、本课程注重实践每一个知识点都有相对应的实例,本书覆盖的实例多达上百个,提高学员的动手能 力和解决问题能力。 4、区块链之币币交易所资管系统性能测试,登录、交易买入、交易卖出等测试场景设计、脚本开发/调试、数据 准备、性能调优、性能测试报告。       5、性能测试流程和性能瓶颈定位等知识讲解。

    174732 人正在学习 去看看 陈槐

测试用例设计:考察测试人员在用例设计方面考虑是否全面,以及对测试需求的分析能力;
最常被问到的,现在软件有一个登录模块,有用户名和密码,以及登录按钮,请你来设计测试用例;

首先说一下我的经历:
目前参加了5场面试,没有收到一个offer, 几乎每一场面试都会被问到这个问题,第一次我的回答是这样子的:
(面试官说给我两分钟,让我写一个登录功能的测试用例,登录界面只有用户名,密码和登录按钮,面试官还说,2分钟够吗?我肯定的回答,够了)
然后我在纸上写下了我的答案:
我的回答1:
测试步骤:
输入用户名和密码,点击登录按钮;
输入数据:
用户名和密码均为空
用户名或者密码为空
用户名不存在;
密码错误;
用户名或者密码输入最大长度;
用户名或者密码输入特殊字符;
用户名和密码输入正确;
然后我给面试官说我写好了,他说你这就考虑了功能方面,其他方面都不用考虑吗?…后来回来想了以下,好像确实考虑的不够,又去百度了以下,用例设计应该从哪些方面去考虑,我查到的是一般从,用户界面,功能,安全,性能,兼容性方面去考虑;
然后我用在了下一次被问到的这个问题中。

我的回答2:
一般从以下几个方面考虑:

  1. UI界面上:查看风格是否合理,输入框以及按钮设计是否好用;

  2. 功能上:针对用户名和密码,以及验证码,考虑多种无效输入和有效输入的情况下,系统是否能正确处理;

  3. 安全性方面:①考虑用户权限,使用不同的用户登录进去,查看能访问的功能是否符合要求;②页面超时是否有处理;③用户A登陆后,在当前标签退出后,立马再不同标签中等录B用户,再去操作上一个标签中用户A操作的界面,看系统是否做出正确的处理;

  4. 接口测试方面:如果在接口测试中有涉及登录的,可以在请求中对参数做出缺省测试,或者修改参数名称以及修改参数的值等进行验证;

  5. 性能测试方面:如果在性能测试需求中有涉及登陆的话,就按照性能的需求去设计用例;

    说完了之后,我说“嗯,用例设计的话大致可以从这几个方面去考虑”,面试官感觉听得有点找不着头脑,莫名的尬笑了一下。我自己心里想,我说了这么多,应该考虑得算比较全面了吧…看到这里你有什么想法呢?

    回到家我仔细回想了一下我的回答,第一,我所描述的给人的感觉不是我在设计测试用例,而是我在告诉别人怎么写测试用例,且不说我说的是否正确;
    仔细想想,我所说的这些测试类型在测试过程之中确实是需要考虑的,但是针对面试官的问题,针对登录功能设计测试用例,我说了很对没用的,例如接口测试和性能测试,还要安全性方面的,特别是我在网上看到的,关于安全性方面的(主要是考虑session),用户退出后在其他界面用不同的用户登录,再去操作用户A的信息,系统是否做出正确处理,首先我说的完全有漏洞,(虽然面试关没有继续追问,可能他觉得我已经跑题了),例如用户A退出登录后,界面怎么会还显示用户A相关的信息呢,描述应该是这样的,在一个页面访问了用户A的信息,再新的假面退出登录,再用B用户登录,然后去操作用户A访问过的信息,这也是测试过的一种方法,但是显然,跟现在对登录模块用例设计没有半毛钱关系了…作为一个有3年测试经验的我,你、给出这样的回答,我真是要醉了。
    回来后,我针对登录模块的用例设计去百度了以下,得到的结果是这样的:

此题的考察目的:
1、了解需求(测什么都是从了解需求开始);
2、是否有设计Test Case的能力
3、是否熟悉各种测试方法;
4、是否有丰富的Web测试经验;
5、是否了解Web开发;
了解需求
测试需求分析过程,可以从质量要求出发,来展开测试需求分析,如从功能、性能、安全性、兼容性等各个质量要求出发,不断细化其内容,挖掘其对应的测试需求,覆盖质量要求。也可以从开发需求(如产品功能特性点、敏捷开发的用户故事)出发,针对每一条开发需求形成已分解的测试项,结合质量要求,这些测试项再扩展为测试任务,这些测试任务包括了具体的功能性测试任务和非功能性测试任务。在整理测试需求时,需要分类、细化、合并并按照优先级进行排序,形成测试需求列表。
1、登录界面应该是弹出窗口式的,还是直接在网页里面;
2、账号长度和密码的强度(比如需要多少位、大小写敏感、特殊字符混搭等);
3、界面美观是否有特殊要求?(即是否要进行UI测试);
4、····
用例设计:
测试需求分析完成后,开始用例设计,主要可以从以下几个方面考虑:

功能测试(Function Test)
1、输入正确的账号和密码,点击提交按钮,验证是否能正确登录。(正常输入)
2、输入错误的账号或者密码, 验证登录会失败,并且提示相应的错误信息。(错误校验)
3、登录成功后能否跳转到正确的页面(低)
4、账号和密码,如果太短或者太长,应该怎么处理(安全性,密码太短时是否有提示)
5、账号和密码,中有特殊字符(比如空格),和其他非英文的情况(是否做了过滤)
6、记住账号的功能
7、登录失败后,不能记录密码的功能
8、账号和密码前后有空格的处理
9、密码是否加密显示(星号圆点等)
10、牵扯到验证码的,还要考虑文字是否扭曲过度导致辨认难度大,考虑颜色(色盲使用者),刷新或换一个按钮是否好用
11、登录页面中的注册、忘记密码,登出用另一帐号登录等链接是否正确
12、输入密码的时候,大写键盘开启的时候要有提示信息。
13、什么都不输入,点击提交按钮,看提示信息。(非空检查)

      就从功能测试这一块,我用蓝色标记的地方,我现在一看,这些我也做过测试,但是为什么我在面试的时候完全忽略掉了这些基本的功能呢?我想一方面是我在用例设计时,压根没有吧这些考虑进去,没有形成用例,自然没有印象,就是在测试的时候,会想到就测试一下。

界面测试(UI Test)
1、布局是否合理,2个Testbox 和一个按钮是否对齐
2、Testbox和按钮的长度,高度是否复合要求
3、界面的设计风格是否与UI的设计风格统一
4、界面中的文字简洁易懂,没有错别字。
5、不同的浏览器窗口大小,下面,界面和功能是否正常

 UI测试我也回答了,考虑界面设计风格是否良好等,但是没有具体进行描述,按照我的描述,测试的时候是完全无法进行测试的,比如怎样才算良好,怎样才算不良好呢?以上蓝色标记的地方,我一看,我平时也是这么测的呀,要是没对齐,或者有错别字,我一看就知道这是bug呀,但是我在设计用例的时候,单纯的写了,界面风格良好,便于用户使用。所以这就是我为什么不能当着面试官的面有条有理的回答出来。

性能测试(Performance Test)
1、打开登录页面,需要几秒
2 、输入正确的账号和密码后,登录成功跳转到新页面,不超过5秒

性能测试,我脑海里,第一浮现的就是用户并发测试,并且总想往这上面靠,然而我说的,确实跟这个登录的功能的性能不搭嘎。这些标蓝的地方,如果测试时遇到了,我肯定知道有问题,例如打开登录页面时,页面一直加载等,但是我说不出来,也是我在平时写用例时没有写到测试用例里面,这里我想到了第二家面试的时候,面试官问我,一般一个测试一个软件,你设计的用例大概有多少,我说一个功能多点的软件的话,大概三四百个吧,前面还问了我一个软件能提多少个bug,我说刚开始测试时候可能两百多个吧........我确实是根据我曾经写过的测试用例去描述的,不过bug数,实际上,可能不到100个....经过几轮测试的可能也不到200个,现在看来一个登陆模块用例设计可能都有几十条了,显然我所说的功能多点的三四百条用例,设计出来肯定很多地方没有具体到用例里面去,就靠测试人员的细心程度和经验了......

安全性测试(Security Test)
1、登录成功后生成的Cookie是否有HttpOnly(降低脚本盗取风险)
2、账号和密码是否通过加密的方式,发送给Web服务器
3、账号和密码的验证,应该是用服务器端验证,而不能单单是在客户端用javaScript验证
4、账号和密码的输入框,应该屏蔽SQL注入攻击
5、账号和密码的的输入框,应该禁止输入脚本(防止XSS攻击)
6、错误登录的次数限制(防止暴力破解)
7、考虑是否支持多用户在同一机器上登录;
8、考虑一用户在多台机器上登录

  我所说的安全性测试也是测试的方法之一,但是呢,跟这个登录模块就有点连不上去了,第4点和第5点,在某些回答中,我也提到过,但是没有实际测过,也没有深入去了解,所以说出来很怕面试官会继续追问,在安全测试方面我确实没什么经验,自己做过较多的就是权限的验证,还有登陆过期这类的,不过个人感觉在面试中,就算安全测试技术层面没什么经验,至少6,7,8应该能说出来,因为在平时用过的软件,很多都会遇到这样的问题,也是属于安全方面的。

可用性测试(Usability Test)
1、是否可以全用键盘操作,是否有快捷键
2、输入账号,密码后按回车,是否可以登录
3、输入框是否可以以Tab键切换

    这个的话不是必要的,但是能说出来更好,因为其实不是所有的软件都支持回车可以登录,tab可以切换下一个输入框的,这些如果在设计说明说着软件需求上没写,也是可以作为用户体验方面去测试。

兼容性测试(Compatibility Test)
1、主流的浏览器下能否显示正常已经功能正常(IE6~11, FireFox, Chrome, Safari 等 )
2、不同的平台是否能正常工作,比如Windows, Mac
3、移动设备上是否正常工作,比如iPhone, Android
4、不同的分辨率

兼容性方面应该是比较容易想到的,但是我确实忽略了,后来面试官问我,还有别的吗,我说没有了,面试官说,你们平时用什么浏览器测试...我就立马补充道,噢,用例设计的话也需要考虑兼容性方面,比如不同的浏览器上功能是否正常等,不过这个要考虑软件开发设计所支持的浏览器和操作系统以及分辨率等。

本地化测试 (Localization Test)
1、不同语言环境下,页面的显示是否正确。
软件辅助性测试 (Accessibility Test)
软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
1、高对比度下能否显示正常(视力不好的人使用)

 最后两点的话,看软件设计的需求吧,很多软件基本没考虑。

综合以上面试经验,很重要的是,能说的有条理,能针对具体功能去设计用例,希望自己在下一次面试中针对这个问题,能给面试官一个较为满意的回答。

2019-01-12 14:27:49 jack0612 阅读数 2628
  • JMETER 性能测试入门到项目实战视频课程

    1、本课程针对JMETER软件性能测试八大组件:配置元件、前置处理器、定时器、sampler(采样器)、后 置处理器、断言、监听器以及逻辑控制器等内容全方位讲解。 2、参数化、badboy测试脚本开发以及录制方法,正则表达式之Regextester工具使用、JMETER 组件作 用域等知识点讲解。 3、本课程注重实践每一个知识点都有相对应的实例,本书覆盖的实例多达上百个,提高学员的动手能 力和解决问题能力。 4、区块链之币币交易所资管系统性能测试,登录、交易买入、交易卖出等测试场景设计、脚本开发/调试、数据 准备、性能调优、性能测试报告。       5、性能测试流程和性能瓶颈定位等知识讲解。

    174732 人正在学习 去看看 陈槐

1、登录的测试点

1.1输入框功能:

 

(1)输入合法的用户名和密码,登录成功

(2)输入合法的用户名和不合法的密码,登录失败,并给出合理提示

(3)输入不合法的用户名和合法的密码,登录失败,并给出合理提示

(4)输入不合法的用户名和不合法的密码,登录失败,并给出合理提示

 

1.2快捷键的使用是否正常

 

(1)Tab键的使用是否正确

(2)上下左右键的使用是否正确

(3)若界面支持ESC键,是否能正常工作

(4)Enter键的使用是否正确;切换时是否正常

 

1.3界面布局

 

(1)界面的布局是否符合人的审美标准

(2)是否与设计图一致

 

1.4其他测试点

 

(1)输入框是否支持:复制、粘贴和剪切

(2)密码框使用暗文显示字符

(3)验证用户名前有空格是否可登录

(4)验证用户名是否区分大小写

(5)验证必填项为空是否允许登录

(6)验证登录的次数是否有限制

(7)数据传输过程中密码加密

(8)有图文验证码的考虑辨识程度

(9)不同浏览器、系统下页面显示

(10)一台设备多个浏览器登录、多台设备登录

(11)主流浏览器下功能是否正常(IE9~11,FireFox, Chrome, Safari 等)

(12)记住账号、密码

(13)允许输入错误密码次数

2019-05-15 09:49:09 weixin_43291944 阅读数 100
  • JMETER 性能测试入门到项目实战视频课程

    1、本课程针对JMETER软件性能测试八大组件:配置元件、前置处理器、定时器、sampler(采样器)、后 置处理器、断言、监听器以及逻辑控制器等内容全方位讲解。 2、参数化、badboy测试脚本开发以及录制方法,正则表达式之Regextester工具使用、JMETER 组件作 用域等知识点讲解。 3、本课程注重实践每一个知识点都有相对应的实例,本书覆盖的实例多达上百个,提高学员的动手能 力和解决问题能力。 4、区块链之币币交易所资管系统性能测试,登录、交易买入、交易卖出等测试场景设计、脚本开发/调试、数据 准备、性能调优、性能测试报告。       5、性能测试流程和性能瓶颈定位等知识讲解。

    174732 人正在学习 去看看 陈槐

登录是我们测试工程师最常见却是最重要,也是最容易被忽视的测试场景,这里借鉴一些经验丰富的测试工程师总结的测试用例并结合Java Spring Security框架来简单说下登录的测试方向和部分原理(持续更新。。。)

  • 功能测试(基础)

    1. 输入已注册的用户名和正确的密码,验证是否登录成功;   
    2. 输入已注册的用户名和不正确的密码,验证是否登录失败,并且提示信息正确;
    3. 输入未注册的用户名和任意密码,验证是否登录失败,并且提示信息正确;
    4. 用户名和密码两者都为空,验证是否登录失败,并且提示信息正确;
    5. 用户名和密码两者之一为空,验证是否登录失败,并且提示信息正确;
    6. 如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入正确的验证码,验证是否登录成功;
    7. 如果登录功能启用了验证码功能,在用户名和密码正确的前提下,输入错误的验证码,验证是否登录失败,并且提示信息正确。
    
  • 功能测试(深入)

      1.用户名和密码是否大小写敏感;
      2.页面上的密码框是否加密显示;
      3.后台系统创建的用户第一次登录成功时,是否提示修改密码;
      4.忘记用户名和忘记密码的功能是否可用;
      5.前端页面是否根据设计要求限制用户名和密码长度;
      6.如果登录功能需要验证码,点击验证码图片是否可以更换验证码,更换后的验证码是否可用;
      7.刷新页面是否会刷新验证码;
      8.如果验证码具有时效性,需要分别验证时效内和时效外验证码的有效性;
      9.用户登录成功但是会话超时后,继续操作是否会重定向到用户登录界面;
      10.不同级别的用户,比如管理员用户和普通用户,登录系统后的权限是否正确;
      11.页面默认焦点是否定位在用户名的输入框中;
      12.快捷键 Tab 和 Enter 等,是否可以正常使用。
    
  • 安全测试

    1.用户密码后台存储是否加密;
    2.用户密码在网络传输过程中是否加密;
    3.密码是否具有有效期,密码有效期到期后,是否提示需要修改密码;
    4.不登录的情况下,在浏览器中直接输入登录后的 URL 地址,验证是否会重新定向到用户登录界面;
    5.密码输入框是否不支持复制和粘贴;
    6.密码输入框内输入的密码是否都可以在页面源码模式下被查看;
    7.用户名和密码的输入框中分别输入典型的“SQL 注入攻击”字符串,验证系统的返回页面;
    8.用户名和密码的输入框中分别输入典型的“XSS 跨站脚本攻击”字符串,验证系统行为是否被篡改;
    9.连续多次登录失败情况下,系统是否会阻止后续的尝试以应对暴力破解;
    10.同一用户在同一终端的多种浏览器上登录,验证登录功能的互斥性是否符合设计预期;
    11.同一用户先后在多台终端的浏览器上登录,验证登录是否具有互斥性。
    
  • 性能压力测试

    1.单用户登录的响应时间是否小于 3 秒;
    2.单用户登录时,后台请求数量是否过多;
    3.高并发场景下用户登录的响应时间是否小于 5 秒;
    4.高并发场景下服务端的监控指标是否符合预期;
    5.高集合点并发场景下,是否存在资源死锁和不合理的资源等待;
    6.长时间大量用户连续登录和登出,服务器端是否存在内存泄漏。
    
  • 兼容性测试

    1.不同浏览器下,验证登录页面的显示以及功能正确性;
    2.相同浏览器的不同版本下,验证登录页面的显示以及功能正确性;
    3.不同移动设备终端的不同浏览器下,验证登录页面的显示以及功能正确性;
    4.不同分辨率的界面下,验证登录页面的显示以及功能正确性。
    

Spring Security简介

Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。它提供了一组可以在Spring应用上下文中配置的Bean,充分利用了Spring IoC,DI(控制反转Inversion of Control ,DI:Dependency Injection 依赖注入)和AOP(面向切面编程)功能,为应用系统提供声明式的安全访问控制功能,减少了为企业系统安全控制编写大量重复代码的工作。

Java Web工程——登录

  • 配置文件

    1、在Maven工程的Pom.xml文件中添加Spring Security的依赖

       <dependency>
      	<groupId>org.springframework.security</groupId>
      	<artifactId>spring-security-web</artifactId>
      	<version>4.1.0.RELEASE</version>
      </dependency>
      <dependency>
      	<groupId>org.springframework.security</groupId>
      	<artifactId>spring-security-config</artifactId>
      	<version>4.1.0.RELEASE</version>
      </dependency>
    

    2、配置web.xml文件

    	 <context-param>
      	<param-name>contextConfigLocation</param-name>
      	<param-value>classpath:spring-security.xml</param-value>
       </context-param>
       <listener>
      	<listener-class>
      		org.springframework.web.context.ContextLoaderListener
      	</listener-class>
       </listener>	
       <filter>  
      	<filter-name>springSecurityFilterChain</filter-name>  		 
      	<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>  
       </filter>  
       <filter-mapping>  
      	<filter-name>springSecurityFilterChain</filter-name>  
      	<url-pattern>/*</url-pattern>  
       </filter-mapping>
    

3、创建index.html
4、创建spring 配置文件spring-security.xml

	<!-- 以下页面不被拦截 -->
	<http pattern="/login.html" security="none"></http>
	<http pattern="/css/**" security="none"></http>
	<http pattern="/img/**" security="none"></http>
	<http pattern="/js/**" security="none"></http>
	<http pattern="/plugins/**" security="none"></http>
	
	<!-- 页面拦截规则 -->
	<http use-expressions="false">
		<intercept-url pattern="/*" access="ROLE_ADMIN" />
		<form-login login-page="/login.html"  default-target-url="/admin/index.html" authentication-failure-url="/login.html" always-use-default-target="true"/>	
		<csrf disabled="true"/>
		<headers>
			<frame-options policy="SAMEORIGIN"/>
		</headers>
	</http>

	<beans:bean id="bcryptEncoder"  
    class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder" />

	<!-- 认证管理器 -->
<authentication-manager>
	<authentication-provider user-service-ref="userDetailService">			
	</authentication-provider>	
</authentication-manager>
<beans:bean id="userDetailService"
   class="com.pinyougou.service.UserDetailServiceImpl">
 </beans:bean> 	

测试点提取:

(1)
在这里插入图片描述

  • 这里设置了不被拦截的页面,就表示在所有这些页面的访问过程中使不需要携带登录信息的,直接输入URL即可;所以在测试的过程中要注意页面的区分,分别测试。

参考测试用例:不登录的情况下,在浏览器中直接输入登录后的 URL 地址,验证是否会重新定向到用户登录界面;

(2)
在这里插入图片描述

  • 这只设置了用户登录的权限拦截规则,规定了登录后跳转的页面

参考测试用例:不同级别的用户,比如管理员用户和普通用户,登录系统后的权限是否正确

(3)
在这里插入图片描述

  • 这里使用了Spring Security的一个认证类,使用认证类调用服务UserDetails,对登录的用户进行认证校验,判断用户是否为合法登录用户;结合后端代码来看:

      public class UserDetailsServiceImpl implements UserDetailsService {
      	@Override
      	public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
      		List<GrantedAuthority> grantedAuths = new ArrayList<GrantedAuthority>();  
              grantedAuths.add(new SimpleGrantedAuthority("ROLE_SELLER"));          
              return new User(username,"123456", grantedAuths);
      	}
      }
    
  • 如果按照上述的写法和配置,则用户在输入密码123456时就会通过,无论用户名为什么,在开发阶段可能为了某些功能的方便测试验证而使用这种写法,为防止测试环境或生产环境的代码忘记修改,此场景也需要测试。(具体的通用密码、账号或验证码之类的可咨询相关开发人员)

参考测试用例:参考上述功能测试用例

若后端代码和配置这样写:

/**
 * 认证类
 * @author Administrator
 *
 */
public class UserDetailsServiceImpl implements UserDetailsService {
	private SellerService sellerService;
	public void setSellerService(SellerService sellerService) {
		this.sellerService = sellerService;
	}
	@Override
	public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
		System.out.println("经过了UserDetailsServiceImpl");
		//构建角色列表
		List<GrantedAuthority> grantAuths=new ArrayList();
		grantAuths.add(new SimpleGrantedAuthority("ROLE_SELLER"));
		//得到商家对象
		TbSeller seller = sellerService.findOne(username);
		if(seller!=null){
			if(seller.getStatus().equals("1")){
				return new User(username,seller.getPassword(),grantAuths);
			}else{
				return null;
			}			
		}else{
			return null;
		}
	}
}

修改spring-security.xml ,添加如下配置

  <!-- 引用dubbo 服务 -->	
	<dubbo:application name="shop-web" />
	<dubbo:registry address="zookeeper://192.168.25.129:2181"/>
	<dubbo:reference id="sellerService"  interface="com.pinyougou.sellergoods.service.SellerService" >
	</dubbo:reference>
	<beans:bean id="userDetailService" class="com.pinyougou.service.UserDetailsServiceImpl">
		<beans:property name="sellerService" ref="sellerService"></bean:property>
	</beans:bean>
  • 经过上述修改后,在登陆页输入用户名和密码与数据库一致即可登陆

参考测试用例:参考上述功能测试用例

密码加密

用户表的密码通常使用MD5等不可逆算法加密后存储,为防止彩虹表破解更会先使用一个特定的字符串(如域名)加密,然后再使用一个随机的salt(盐值)加密。 特定字符串是程序代码中固定的,salt是每个密码单独随机,一般给用户表加一个字段单独存储,比较麻烦。 BCrypt算法将salt随机并混入最终加密后的密码,验证时也无需单独提供之前的salt,从而无需单独处理salt问题。

我们在日常测试中除了要关注功能外,还要关注软件的安全性,可能我们很多人并不是专业的安全测试工程师,但是一般的测试点还是要保证覆盖的

后端部分代码和配置文件:

    @RequestMapping("/add")
	public Result add(@RequestBody TbSeller seller){
		//密码加密
		BCryptPasswordEncoder passwordEncoder = new BCryptPasswordEncoder();
		String password = passwordEncoder.encode(seller.getPassword());
		seller.setPassword(password);

spring-security.xml ,添加如下配置

  <beans:bean id="bcryptEncoder"  
            class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder" />

修改认证管理器的配置

<!-- 认证管理器 -->
<authentication-manager alias="authenticationManager">  
    <authentication-provider user-service-ref='userDetailService'>   
      	<password-encoder ref="bcryptEncoder"></password-encoder>	   		
    </authentication-provider>  
</authentication-manager> 
  • 这里我们可以看一下密码在数据库的显示结果:
    在这里插入图片描述
    我们可以看到很明显的区别,未加密的密码直接暴露,会带来账户安全隐患;而使用MD5和BCrypt加密的密码要更为安全;理论上MD5也是不可逆的密码,无法被破解,但是因为MD5在相同的密码下生成的加密字符串是固定的,所以在大数据技术下可以建立数据库将常用密码进行一一对应存储的方法来进行破解;相对比BCrypt加盐的方式,BCrypt加密就更为安全的多了。

参考测试用例:参考上述安全测试

5、准备好登录界面login.html

写在最后:由于本人经验不足,资历不够,理解尚浅,所以主要用作自己的工作总结;有不对和不足的地方希望大佬们见谅;也希望同行的小伙伴一起沟通交流进步,有大佬能带带我就好了哈哈~

2019-12-25 10:31:48 weixin_43250197 阅读数 14
  • JMETER 性能测试入门到项目实战视频课程

    1、本课程针对JMETER软件性能测试八大组件:配置元件、前置处理器、定时器、sampler(采样器)、后 置处理器、断言、监听器以及逻辑控制器等内容全方位讲解。 2、参数化、badboy测试脚本开发以及录制方法,正则表达式之Regextester工具使用、JMETER 组件作 用域等知识点讲解。 3、本课程注重实践每一个知识点都有相对应的实例,本书覆盖的实例多达上百个,提高学员的动手能 力和解决问题能力。 4、区块链之币币交易所资管系统性能测试,登录、交易买入、交易卖出等测试场景设计、脚本开发/调试、数据 准备、性能调优、性能测试报告。       5、性能测试流程和性能瓶颈定位等知识讲解。

    174732 人正在学习 去看看 陈槐
**软件功能需求**
	1.用户注册功能
	2.用户登录功能
	3.用户账号后台管理
**测试需求**
	1.用户登录的功能
	2.用户登录的安全性
	3.用户登录的兼容性
	4.用户登录的性能
**测试用例**
	1.功能测试用例集
		1.显性功能验证
			1.登录的正确性
				1.用户名、密码正确
					1.账号在
				2.验证码功能
					1.输入正确的用户名、正确的密码、正确的验证码
						登录成功
			2.登录异常
				1.输入错误情况检测
					4.已注册的账户、错误的密码登录
					5.未注册的账户、正确的密码
					3.账号、密码都错误
				2.为空检测
					1.账号和密码都为空时验证
						登录失败,且提示信息正确;
					2.账号和密码两者之一为空时
						登录失败,且提示信息正确;
				3.其他功能无效检测
					1.找回密码功能是否有效
					2.记住密码是否有效
					3.自动登录
				4.验证码功能验证
					1.输入账号、密码正确,但验证码错误:
						登录失败,且提示信息正确
				同样的账号同时登录;
		2.隐性功能验证
			1.用户名和密码是否大小写敏感?
			2.页面上的密码框是否加密显示?
			3.后台系统创建的用户第一次登录成功时,是否提示修改密码?
			4.忘记用户名和忘记密码的功能是否可用?
			5.前端页面是否根据设计要求限制用户名和密码长度?
			6.如果登录功能需要验证码,点击验证码图片是否可以更换验证码,更换后的验证码是否可用?
			7.刷新页面是否会刷新验证码?
			8.如果验证码具有时效性,需要分别验证时效内和时效外的有效性;
			9.用户登录成功后但是会话超时后,继续操作是否会重定向到用户登录界面?
			10.不同级别的用户,比如管理员用户和普通用户,登录系统后的权限是否正确?
			11.页面默认焦点是否定位在用户名的输入框中;
			12.快捷键Tab和Enter等,是否可以正常使用?
			账号
				1.是否可以使用登录的API发送登录请求,并绕开验证码校验。
			密码
				1.密码是否支持特殊字符和中文等。
				2.密码强弱性校验,数据库和数据操作时候合理等。
				3.没劲是否有明文和暗文两种模式(有时候只有暗文显示真的不知道自己的密码是否输入正确。)
				4.更改密码后,是否还能用之前的密码登录?
				5.若支持手机号+验证码登录,验证码是否有时间限制?移动端设备是否可以直接获取验证码?
				6.输入账号密码时对键盘格式是否有要求比如数字键盘;
				7.密码一栏需要设置明暗切换?
				8.输入账号密码格式不规范时是否将按钮设置为不可点击;
				9.输入栏是否设置快速删除按钮?
			登录
				1.是否可以用抓包工具抓到请求包直接登录?
				2.截取到的token等信息,是否可以在其他终端上直接使用,绕开登录,token过期时校验。
				3.除了前端校验格式长度等,后端是否也校验?
				4.登录后输入登录URL,是否还能再次登录?如果能,原登录用户是否变得无效。
				5.登录错误后的提示是否有安全隐患。
				6.登录失败后第二次登录
					1.输入正确的用户名和错误的密码登录失败后,再次输入正确的密码登录并观察登录情况。
					2.输入正确的用户名和不输入密码登录失败后,再次输入正确的密码并观察登录情况。
					3.输入未注册的用户名和任意密码登录失败后,再次输入正确的用户名和密码,观察登录情况。
				7.修改密码后:
					1.修改密码后是否重定向登录到界面?
					2.修改密码后,分别使用原密码和新密码登录。
					3.在其他终端修改密码后,本终端是否自动下线?下线后,使用原密码能否继续登录?
				8.退出登录
					1.退出登录是否有记住账号或记住密码功能?
					2.退出登录后,再次输入密码登录。
				9.数据同步
					1.第一次登录时,数据的同步情况,如个人头像,好友列表等。
					2.本终端切换其他账号登录后,数据的同步情况,日志记录情况,如:用户文件夹是否自动创建?
				10.账号互踢
					1.不同页面下被踢,如:后台运行时被踢,进入前台查看反应;前台运行一级、二级页面下被踢能否提示正确并重定向到登录页面?
					2.本终端被踢下线后点击登录能否再次登录。
				11.密码错误限制次数
					1.密码输入错误是否有最大次数限制?分别测试最大值-1、最大值、最大值+1的输错密码情况。
					2.超过最大次数限制后,是否采取强制手段限制登录或对账号暂时冻结处理。
					3.超过最大次数限制后,分别输入正确的密码和错误的密码再次登录。
				12.不同状态的用户登录
					1.未激活的用户登录。
					2.被停用的用户登录。
					3.登录的操作日志记录是否准确?
					4.登录有效性是否控制正确?
				13.一个用户是否具备多种登录方式(用户名,手机号,邮箱...)
				14.用户名和密码是否对空格敏感。
			16.为空和输入空字符串时的校验是否一致?
			17.使用中文键盘输入字母时和使用英文键盘输入字母时传给后端的字符长度是否一致?
			18.登录成功后的Session时效设置。
			19.是否用到缓存?
	2.安全测试用例集
		1.用户密码后台存储是否加密?
		2.用户密码在网络传输过程中是否加密?
		3.密码是否具有有效期,密码有效期到期后,是否提示需要修改密码?
		4.不登录的情况下,在浏览器中直接输入登录后的URL地址,验证是否会新定向到用户登录界面;
		5.密码输入框是否不支持复制和粘贴?
		6.密码输入框输入的密码是否都可以在页面源码模式下被查看?
		7.用户名和密码的输入框中分别输入典型的“SQL注入攻击”字符串,验证系统的返回页面;
		8.用户名和密码的输入框中分别输入典型的“XSS跨站脚本攻击”字符串,验证系统行为是否被篡改?
		9.连续登录多次失败的情况下,系统是否会阻止后续的尝试以应对暴力破解?
		10.同一用户在同一终端的多种浏览器上登录,验证登录功能的互斥性是否符合设计预期?
		11.同一用户先后在多台终端的浏览器上登录,验证登录是否具有互斥性?
		12.网络延迟或者弱网切换网络或者断网时正常登录是否正常?
		13.是否可记住密码,记住的密码保存是否加密?
		14.用户登录后存储在数据库中的用户个人信息是否加密?
		15.用户登录过程中log中是否有个人信息明文打印。
		16.本终端用户已登录,在其他终端尝试登录本用户账号登录失败时、本终端是否有账号异常操作的安全提示?
		17.输入密码时是否有安全键盘模式?点击密码输入框是否能调起安全键盘?(参考各大手机银行APP)
		19.网络相关
			1.无网络模式下登录,是否给出“网络未连接”或 “网络异常”的提示及提示是否正确?
			2.第一次登录请求超时后(服务器出问题,随后恢复正常),再次请求是否能登录成功?
			3.第一次无网络情况下登录失败后,再次连接网络并登录。
			4.正在登录过程中,遇到网络切换,如(4G切换到WiFi环境时)能否正常登录。
		20.已登录的用户,杀死APP进程后,再次打开APP是否依然为已登录状态。
		21.异地登录校验、更换设备登录校验、登录信息异常是否考虑账号冻结停用;是否允许第三方工具平台存储密码?
		22.
	3.兼容性测试用例集
		1.不同浏览器下,验证登录页面的显示以及功能正确性?
		2.相同浏览器的不同版本下,验证登录页面的显示以及功能正确性?
		3.不同移动设备终端的不同浏览器下,验证登录页面的显示以及功能正确性。
		4.不同分辨率的界面下,验证登录页面的显示以及功能正确性。
	4.性能测试用例集
		1.单用户登录的响应时间是否小于3秒?
		2.单用户登录时,后台请求数量是否过多?
		3.高并发场景下用户登录的响应时间是否小于5秒?
		4.高并发场景下服务端的监控指标是否符合预期?
		5.高集合点并发场景下,是否存在资源死锁和不合理的资源等待?
		6.长时间大量用户连续登录和登出,服务器端是否存在内存泄漏?
		7.登录用户限制:同时支持10个用户登录,同时9个或者11个用户登录是否正常或者提示信息正确。

QQ登录页面测试

阅读数 17

QQ登录页面测试

博文 来自: weixin_45662626
没有更多推荐了,返回首页