软件测试52讲
茹炳晟
eBay中国研发中心,测试基础架构技术主管
立即订阅
13425 人已学习
课程目录
已完结 63 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从“小工”到“专家”,我的软件测试修炼之道
免费
测试基础知识篇 (11讲)
01 | 你真的懂测试吗?从“用户登录”测试谈起
02 | 如何设计一个“好的”测试用例?
03 | 什么是单元测试?如何做好单元测试?
04 | 为什么要做自动化测试?什么样的项目适合做自动化测试?
05 | 你知道软件开发各阶段都有哪些自动化测试技术吗?
06 | 你真的懂测试覆盖率吗?
07 | 如何高效填写软件缺陷报告?
08 | 以终为始,如何才能做好测试计划?
09 | 软件测试工程师的核心竞争力是什么?
10 | 软件测试工程师需要掌握的非测试知识有哪些?
11 | 互联网产品的测试策略应该如何设计?
GUI自动化测试篇 (10讲)
12 | 从0到1:你的第一个GUI自动化测试
13 | 效率为王:脚本与数据的解耦 + Page Object模型
14 | 更接近业务的抽象:让自动化测试脚本更好地描述业务
15 | 过不了的坎:聊聊GUI自动化过程中的测试数据
16 | 脑洞大开:GUI测试还能这么玩(Page Code Gen + Data Gen + Headless)?
17 | 精益求精:聊聊提高GUI测试稳定性的关键技术
18 | 眼前一亮:带你玩转GUI自动化的测试报告
19 | 真实的战场:如何在大型项目中设计GUI自动化测试策略
20 | 与时俱进:浅谈移动应用测试方法与思路
21 | 移动测试神器:带你玩转Appium
API自动化测试篇 (3讲)
22 | 从0到1:API测试怎么做?常用API测试工具简介
23 | 知其然知其所以然:聊聊API自动化测试框架的前世今生
24 | 紧跟时代步伐:微服务模式下API测试要怎么做?
代码测试篇 (3讲)
25 | 不破不立:掌握代码级测试的基本理念与方法
26 | 深入浅出之静态测试方法
27 | 深入浅出之动态测试方法
性能测试篇 (7讲)
28 | 带你一起解读不同视角的软件性能与性能指标
29 | 聊聊性能测试的基本方法与应用领域
30 | 工欲善其事必先利其器:后端性能测试工具原理与行业常用工具简介
31 | 工欲善其事必先利其器:前端性能测试工具原理与行业常用工具简介
32 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(上)
33 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(下)
34 | 站在巨人的肩膀:企业级实际性能测试案例与经验分享
测试数据准备篇 (4讲)
35 | 如何准备测试数据?
36 | 浅谈测试数据的痛点
37 | 测试数据的“银弹”- 统一测试数据平台(上)
38 | 测试数据的“银弹”- 统一测试数据平台(下)
测试基础架构篇 (4讲)
39 | 从小作坊到工厂:什么是Selenium Grid?如何搭建Selenium Grid?
40 | 从小工到专家:聊聊测试执行环境的架构设计(上)
41 | 从小工到专家:聊聊测试执行环境的架构设计(下)
42 | 实战:大型全球化电商的测试基础架构设计
测试新技术篇 (5讲)
43 | 发挥人的潜能:探索式测试
44 | 测试先行:测试驱动开发(TDD)
45 | 打蛇打七寸:精准测试
46 | 安全第一:渗透测试
47 | 用机器设计测试用例:基于模型的测试
测试人员的互联网架构核心知识篇 (5讲)
48 | 优秀的测试工程师为什么要懂大型网站的架构设计?
49 | 深入浅出网站高性能架构设计
50 | 深入浅出网站高可用架构设计
51 | 深入浅出网站伸缩性架构设计
52 | 深入浅出网站可扩展性架构设计
特别放送篇 (8讲)
测试专栏特别放送 | 答疑解惑第一期
测试专栏特别放送 | 答疑解惑第二期
测试专栏特别放送 | 答疑解惑第三期
测试专栏特别放送 | 答疑解惑第四期
测试专栏特别放送 | 答疑解惑第五期
测试专栏特别放送 | 答疑解惑第六期
测试专栏特别放送 | 答疑解惑第七期
测试专栏特别放送 | 浅谈全链路压测
测一测 (1讲)
测一测 | 这些软件测试题目,你都掌握了吗?
结束语 (1讲)
结束语 | 不是结束,而是开始
软件测试52讲
登录|注册

01 | 你真的懂测试吗?从“用户登录”测试谈起

茹炳晟 2018-06-29
作为专栏的第一篇文章,我选择了一个你耳熟能详的“用户登录”功能作为测试对象,希望通过这样一个简单直白的功能帮助你理解如何做好测试,以及现阶段你需要加强和提高的测试技能。
可能你会说,“用户登录”这个测试对象也有点太简单了吧,我只要找一个用户,让他在界面上输入用户名和密码,然后点击“确认”按钮,验证一下是否登录成功就可以了。的确,这构成了一个最基本、最典型的测试用例,这也是终端用户在使用系统时最典型的 Happy Path 场景。
但是作为测试工程师,你的目标是要保证系统在各种应用场景下的功能是符合设计要求的,所以你需要考虑的测试用例就需要更多、更全面,于是你可能会根据“用户登录”功能的需求描述,结合等价类划分和边界值分析方法来设计一系列的测试用例。
那什么是等价类划分和边界值分析方法呢?首先,这二者都隶属于最常用、最典型、也是最重要的黑盒测试方法。
等价类划分方法,是将所有可能的输入数据划分成若干个子集,在每个子集中,如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果,那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试,就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
边界值分析方法,是选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上,所以需要对边界值进行重点测试,通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件测试52讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(145)

  • 夸夸狗
    1.网络延迟或者弱网或者切换网络或者断网时正常登录是否正常
    2.是否支持第三方登录
    3.是否可记住密码,记住的密码保存是否加密
    记住密码是否有有效期,有有效期,过期之后是否会清空密码

    作者回复: 很棒的补充,对于网络延迟和弱网络场景下的测试,我们通常会用工具来模拟网络延迟和故意引入固定百分比的网络丢包。这也从另一个侧面反映出了测试的不可穷尽性,当面对大量测试点,但是测试时间资源和人力资源都有限的情况下,我们就必须根据具体风险来决定测试的范围和优先级,很多情况下不得不在质量和成本之间找到平衡点。

    2018-06-29
    103
  • 文大头
    关于登录,想到几点:
    1.常规用例中,用户名密码是否支持特殊字符和中文等
    2.是否可以使用登录的API发送登录请求,并绕开验证码校验
    3.是否可以用抓包工具抓到的请求包直接登录
    4. 截取到的token等信息,是否可以在其他终端上直接使用,绕开登录。token过期时间校验
    5.除了前端校验格式长度等,后端是否也校验?
    6. 登录后输入登录URL,是否还能再次登录?如果能,原登录用户是否变得无效
    7. 登录错误后的提示是否有安全隐患
    暂时想到这些,另外,可能还会有些系统特别的登录相关功能,看需求来定了。

    作者回复: 太棒了,能想到这么多有技术含量的测试点,大家可以参考学习。感谢你的分享

    2018-06-29
    61
  • 何大小姐
    看完这个,再也不怕面试的时候问“一个登陆页面,你给我设计一些用例吧”😂😂

    作者回复: 能够有收获就好,感谢你的支持

    2018-06-29
    54
  • 小叮当csh
    以下是我根据自己在测试过程中所遇到的问题及发挥了一些自己的想象所做的补充(主要针对APP登录测试):
    1、登录失败后二次登录
    (1)输入正确的用户名,不输入密码,点击登录;登录失败后,再次输入正确的密码登录并观察登录情况
    (2)输入正确的用户名和错误的密码登录失败后,再次输入正确的密码登录并观察登录情况
    (3)输入未注册的用户和任意密码登录失败后,再次输入正确的用户名和密码,观察登录情况
    2、修改密码后
    (1)修改完密码后是否重定向到登录界面
    (2)修改完密码后,分别使用原密码和新密码登录
    (3)在其他终端修改密码后,本终端是否自动下线?下线后,使用原密码能否继续登录?
    3、退出登录
    (1)退出登录是否有记住账号或记住密码功能
    (2)退出登录后,再次输入密码登录
    4、数据同步
    (1)第一次登录时,数据的同步情况,如个人头像,好友列表等
    (2)本终端切换其他账号登录后,数据的同步情况,日志记录情况,如:用户文件夹是否自动创建
    5、账号互踢
    (1)不同页面下被踢,如:后台运行时被踢,进入前台查看反应;前台运行时一级、二级页面下被踢能否提示正确并重 定向到登录界面
    (2)本终端被踢下线后点击登录能否再次登录
    6、密码错误限制次数
    (1)密码输入错误是否有最大次数限制?分别测试最大值-1、最大值、最大值+1时的输错密码情况
    (2)超过最大次数限制后,是否采取强制手段限制登录或对账号暂时冻结处理
    (3)超过最大次数限制后,分别输入正确的密码和错误的密码再次登录
    7、安全性
    (1)本终端用户已登录,在其他终端尝试登录本用户账号登录失败时、本终端是否有账号异常操作的安全提示
    (2)输入密码时是否有安全键盘模式?点击密码输入框是否能调起安全键盘?(参考各大手机银行APP)
    8、网络相关
    (1)无网络模式下登录,是否给出“网络未连接”或“网络异常”的提示及提示是否正确
    (2)第一次登录请求超时后(服务器出问题,随后恢复正常),再次请求登录能否登录成功
    (3)第一次无网络情况下登录失败后,再次连接网络并登录
    (4)正在登录过程中,遇到网络切换,如(4G切换到WiFi环境时)能否正常登录
    9、其他
    (1)已登录的用户,杀死APP进程后,再次打开APP是否依然为已登录状态
    2018-07-02
    1
    49
  • 小叶榕
    1、GDPR相关的测试偏少,比如用户登录后存储在数据库中的用户个人信息是否加密;用户登录过程中log中是否有个人信息明文打印;
    2、登录用户限制:比如同时支持10个用户登录,同时9个或者11个用户登录是否正常或者提示信息正确

    作者回复: 非常好的补充,一看就知道你对测试用例的设计很有经验!这也从另一个侧面反映出了测试的不可穷尽性,当面对大量测试点,但是测试时间资源和人力资源都有限的情况下,我们就必须根据具体风险来决定测试的范围和优先级,很多情况下不得不在质量和成本之间找到平衡点。

    2018-06-29
    1
    29
  • Mr.Z
    我补充一些思路:密码强弱性校验,数据库设计和数据操时候合理等。

    作者回复: 很棒的补充,这也从另一个侧面反映出了测试的不可穷尽性,当面对大量测试点,但是测试时间资源和人力资源都有限的情况下,我们就必须根据具体风险来决定测试的范围和优先级,很多情况下不得不在质量和成本之间找到平衡点。

    2018-06-29
    23
  • 阿莲
    还应该包括:
    1、未激活的用户登录
    2、被停用的用户登录
    3、登录的操作日志记录是否准确
    4、登录有实效性是否控制正确

    作者回复: 很棒的补充,这也从另一个侧面反映出了测试的不可穷尽性,当面对大量测试点,但是测试时间资源和人力资源都有限的情况下,我们就必须根据具体风险来决定测试的范围和优先级,很多情况下不得不在质量和成本之间找到平衡点。

    2018-06-29
    22
  • Tomandy
    虽然是一个看似简单的“用户登录”功能,却蕴含大学问。用例设计考验的是Tester的思维能力,而测试思维方式的培养是一个持续的过程。本人很认可《你的灯亮着吗》里的一段话:每一个解决方案都是下一个问题的来源,要真正理解问题,那至少对自己的解决方案提出三个可能出错的地方。

    作者回复: 非常棒的见解,测试用例设计的思维模式培养才是最核心,也是最有价值的部分,同时这个过程中还可以利用用例设计的设计模式来协助你做出更全面系统的用例集合。

    2018-06-29
    20
  • Geek_f340df
    感觉不是在基于等价类,边界值的分析,而是场景的组合;等价类边界值就像类似于公式的一种科学工具,谁都可以直接套用;而在使用场景方法时需要的是对业务以及实现该业务的过程和技术的掌握深度和广度,是属于一种经验的积累达成的测试手段。评论区中的补充,对我们而言都是一种经验的copy,至于这种经验copy能否扎根到心里去产生实际效果,也许需要因人而异。
    2018-07-04
    19
  • 双子
    补充几条测试过程中遇到过的印象比较深刻的细节:
    1、为空和输入空字符串时的校验是否一致;
    2、使用中文键盘输入字母时和使用英文键盘输入字母时传给后端的字符长度是否一致;
    3、登录成功后的session时效设置;
    4、安全性方面异地登录校验、更换设备登录校验、登录信息异常是否考虑账号冻结停用;是否允许第三方工具平台存储密码。

    作者回复: 非常棒的补充,从补充的内容就可以看出你有过非常丰富的实际功能测试经验。值得借鉴!

    2018-06-29
    14
  • luosj
    涉及资产风险的,对登录设备和地区检测

    作者回复: 某种意义上说,这是一个功能性需求,非常棒哦

    2018-06-29
    14
  • 寧靜致遠
    把评论爬了一遍,瞬间觉得自己太low了,从大家的评论看都是牛人啊,高手无处不在,受教了。
    2018-08-07
    12
  • 白天黑夜
    还有是是否用到缓存

    作者回复: 对的,这是一个很好的测试点,尤其是浏览器启用了缓存的场景,这里可以具体这个点引出一大堆测试用例。很棒!

    2018-06-29
    12
  • 小琼😁
    测试时间都有限,如何能去覆盖全面

    作者回复: 其实测试真正目标不是保证全面覆盖,而是追求在有限的时间资源以及人力成本资源的情况下,寻找质量风险和测试成本之间的平衡点。后面的文章会谈测试计划的制定,那里会对这个问题做进一步详细的解读。

    2018-06-29
    10
  • 双子
    分享用户体验方面的几个细节
    1、输入账号密码时对键盘格式是否有要求比如数字键盘;
    2、密码一栏是否需要设置明暗码切换按钮;
    3、输入账号密码格式不规范时是否将按钮设置为不可点击;
    4、输入栏是否设置快速删除按钮

    作者回复: 很棒的补充,这也从另一个侧面反映出了测试的不可穷尽性,当面对大量测试点,但是测试时间资源和人力资源都有限的情况下,我们就必须根据具体风险来决定测试的范围和优先级,很多情况下不得不在质量和成本之间找到平衡点。

    2018-06-29
    9
  • hyeebeen
    设备互斥时的登录情况,是否有强制退出另外一个登录;
    同样的账号同时登录;

    作者回复: 对于第一条,其实文中已有类似的测试用例。对于第二条,思想方法很在点子上,但是实际操作中,是很难达到完全严格意义上的“同时”,即使你使用了集合点并发技术,但是由于网络延迟的存在,当login请求到达后端是也是很难达到严格意义上的“同时”,所以第二个用例可以退化为相同用户的两个登陆的互斥性测试。另外根据你的思路,我们还可以考虑同一用户移动端登录,PC端登录,以及Native App端登录的互斥性测试。非常棒的思考!

    2018-06-29
    8
  • dj
    有种茅塞顿开的感觉

    作者回复: 感谢支持,这就是这个专栏想要达到的目的,希望后续的文章能给你带来更多的帮助

    2018-06-29
    7
  • itsgoodtobebad
    谈一个非技术的问题:很多时候你的测试用例详尽到什么程度,是和公司整体对质量的态度决定的。所以在一家不太重视质量的公司长期工作,很可能会平庸自己的能力。仅供参考。
    2018-12-03
    6
  • bubblehead
    1)用户名和密码是否对空格敏感
    2)密码是否有明文和暗文显示两种模式(有时候只有暗文显示真的不知道自己的密码是否输入正确)
    3)更改密码后是否还能用之前的密码登录
    4)一个用户是否具备多种登录方式(用户名,手机号,邮箱...)
    5)若支持手机号+验证码登录,验证码是否有时间限制?移动端设备是否可以直接获取验证码?

    作者回复: 很棒的补充,这也从另一个侧面反映出了测试的不可穷尽性,当面对大量测试点,但是测试时间资源和人力资源都有限的情况下,我们就必须根据具体风险来决定测试的范围和优先级,很多情况下不得不在质量和成本之间找到平衡点。

    2018-06-29
    6
  • Maggie 💋
    学习了,刚好在测登录这块,一对比就有了差距,自己测试点这块思考太少了

    作者回复: 希望读完文章后能够有效帮助你增加更多的测试点

    2018-06-29
    6
收起评论
99+
返回
顶部