用例设计面试题

对登录进行用例设计

一、基本功能测试点:

  1. 输入正确的用户名和密码登录成功
  2. 输入错误的用户名密码登录失败
  3. 用户名正确,密码错误,是否提示输入密码错误?
  4. 用户名错误,密码正常,是否提示输入用户名错误?
  5. 用户名和密码都错误,是否有相应提示?
  6. 用户名密码为空时,是否有相应提示?
  7. 如果用户未注册,提示请先注册,然后进行登录
  8. 已经注销的用户登录失败,提示信息友好?
  9. 密码框是否加密显示?
  10. 用户名是否支持中文、特殊字符?
  11. 用户名是否有长度限制?
  12. 密码是否支持中文,特殊字符?
  13. 密码是否有长度限制?
  14. 密码是否区分大小写?
  15. 密码为一些简单常用字符串时,是否提示修改?如:123456
  16. 密码存储方式?是否加密?
  17. 登录功能是否需要输入验证码?
    1. 验证码有效时间?
    2. 验证码输入错误,登录失败,提示信息是否友好?
    3. 输入过期的验证能否登录成功?
    4. 验证码是否容易识别?
    5. 验证码换一张功能是否可用?点击验证码图片是否可以更换验证码?
  18. 用户体系:比如系统分普通用户、高级用户,不同用户登录系统后可的权限不同。
  19. 如果使用第三方账号(QQ,微博账号)登录,那么第三方账号与本系统的账号体系对应关系如何保存?首次登录需要极权等

二、页面测试:

  1. 登录页面显示是否正常?文字和图片能否正常显示,相应的提示信息是否正确,按钮的设置和排列是否正常,页面是否简洁壮观等。
  2. 页面默认焦点是否定位在用户名的输入框中
  3. 首次登录时相应的输入框是否为空?或者如果有默认文案,当点击输入框时默认方案是否消失?
  4. 相应的按钮如登录、重置等,是否可用;页面的前进、后退、刷新按钮是否可用?
  5. 快捷键Tab,Esc,Enter 等,能否控制使用
  6. 兼容性测试:不同浏览器,不同操作系统,不同分辨率下界面是否正常

 、安全测试:

  1. 不登录:浏览器中直接输入登录后的地址,看是否可以直接进入
  2. 登录成功后生成的Cookie,是否是httponly (否则容易被脚本盗取)
  3. 用户名和密码是否通过加密的方式,发送给Web服务器
  4. 用户名和密码的验证,应该是用服务器端验证, 而不能单单是在客户端用javascript验证
  5. 用户名和密码的输入框,应该屏蔽SQL 注入攻击
  6. 用户名和密码的的输入框,应该禁止输入脚本 (防止XSS攻击)
  7. 错误登陆的次数限制(防止暴力破解)
  8. 考虑是否支持多用户在同一机器上登录;
  9. 考虑一用户在多台机器上登录

、性能测试:

  1. 单用户登录系统的响应时间是否符合"3-5-8"原则
  2. 用户数在临界点时并发登录是否还能符合"3-5-8"原则
  3. 压力:大量并发用户登录,系统的响应时间是多少?系统会出现宕机、内存泄露、cpu饱和、无法登录吗?
  4. 稳定性: 系统能否处理并发用户数在临界点以内连续登录N个时的场景?

、其它测试:

  1. 连续输入3次或以上错误密码,用记是否被锁一定时间(如:15分钟)?时间内不允许登录,超出时间点是否可以继续登录。
  2. 用户session过期后,重新登录是否还能重新返回这前session过期的页面?
  3. 用户名和密码输入框是事支持键盘快捷键?如:撤销、复制、粘贴等等
  4. 是否允许同名用户同时登录进行操作?考虑web和app同时登录
  5. 手机登录时,是否先判断网络可用?
  6. 手机登录时,是否先判断app存在新版本?
  7. 是否支持单点登录?
  8. 是否有埋点接口

上传用例设计

1.功能测试

(1)选择符合要求的文件,上传--------上传成功;

(2)上传成功的文件名称显示----------显示正常(根据需求)

(3)查看,下载上传成功的文件--------上传的文件可查看或下载

(4)删除上传成功的文件-------------可删除

(5)替换上传成功的文件-------------可替换

(6)上传文件是否支持中文名称--------根据需求而定

(7)文件路径是否可手动输入----------根据需求而定

(8)手动输入正确的文件路径,上传-----上传成功

(9)手动输入错误的文件路径,上传-----提示,不能上传

2.文件大小测试

(1)符合格式,总大小稍小于限制大小的文件------上传成功

(2)符合文件,总大小等于限制大小的文件--------上传成功

(3)符合文件总大小稍大于限制大小的文件--------在上传初提示附件过大

(4)小为0kb的txt文档-----------------------不能上传

3.文件名称测试

(1)文件名称过长。Win2000标准:255个字符(指在英文的字符下),如果是中文不超过127个汉字-----提示过长

(2)文件名称达到最大长度(中文,英文或混在一起)上传后名称显示,页面排版-----------页面显示正常

(3)文件名称中包含特殊字符-------------根据需求而定

(4)文件名全为中文--------------------根据需求而定

(5)文件名全为英文--------------------根据需求而定

(6)文件名为中、英混合-----------------根据需求而定

4.文件格式测试

(1)上传正确格式-----------------上传成功

(2)上传不允许的格式--------------提示不能上传

(3)上传rar,zip等打包文件(多文件压缩)---------根据需求而定

5.安全性测试

(1)上传可执行文件(exe文件)-----------------根据需求而定

(2)上传常见的木马文件------------------------提示不能上传

(3)上传时服务器空间已满----------------------有提示

6.性能测试

(1)上传时网速很慢(限速)-----------------当超过一定时间,提示

(2)上传过程断网--------------------------有提示是否上传成功

(3)上传过程服务器停止工资------------------有提示是否上传成功

(4)上传过程服务器的资源利用率---------------在正常范围

7.界面测试

(1)界面美观性、易用性(键盘和鼠标的操作、tab跳转的顺序是否正确)----------显示正常(根据需求)

(2)按钮文字是否正确--------------正确

(3)正确/错误提示的文字是否正确---------------正确

(4)说明性文字是否正确-----------------------正确

8.其他测试

(1)有多个上传框时,上传相同名称的文件---------------根据需求而定

(2)上传一个正在打开的文件-------------------------可以上传

(3)文件路径是手工输入的是否限制长度----------------限制一定的长度

(4)上传过程中是否有取消正在上传文件的功能-----------有

(5)保存时有没有已经选择好,但没有上传的文件-----------提示上传

()选择好但是未上传的文件是否可以取消选择------------可以取消选择

原文地址:https://www.cnblogs.com/zyblb/p/10945127.html

时间: 2024-10-06 23:16:15

用例设计面试题的相关文章

软件测试 —— 用例设计3(其他)

错误推测方法: 一.    方法简介 1.         定义:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 2.         错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 1)        例如, 输入数据和输出数据为0的情况:输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例. 2)        例如,前面例子中成绩报告的程序,采用错误推

Java设计模式中的单例设计

/** * 单例设计模式 * 应用场合:只需要一个对象的 * 作用:保证整个应用程序中某个实例有且只有一个 * 类型有:饿汉模式.懒汉模式 * 下面的例子是一个饿汉模式的例子 */ class SingleDemo { // 1.将构造方法私有化,不允许外部直接创建使用 private SingleDemo() {} // 2.创建类的唯一实例,使用private static修饰 private static SingleDemo instance = new SingleDemo(); //

不得不说--自动化测试元素定位与用例设计

关于自动化测试,经常被问到元素的定位 与 如何设计用例. 很多时间我也帮不了你解决实际的问题,只能从个人脚本谈谈如何看待这些问题. 不得不说之元素定位 虽然,本章写了十几篇文章来讲元素的定位与操作,对于碰到的一些常见功能,如何通过技巧来定位它们,但是在实际的自动化脚本开发中,不管是新手还是具有一定经验的老手,我们面临最多的问题仍然是元素的定位问题. 有时间元素定位非常简单,例如,我们只要知道这个元素有的id和name 就可以轻松的来定位到它:有时间元素的定位却非常的令人非常头疼,尽管我们用尽了所

Spring容器-ApplicationContext的单例设计

Spring容器-ApplicationContext的单例设计 每次通过new创建一个ApplicationContext容器,都会执行refresh方法,看源代码了解到这个refresh方法会重新加载配置文件,并且这个创建的容器对象持有一个所有singleton类型bean的map集合,从而实现单例,而且这个map对象的生命周期和容器对象的生命周期是一样的 如果我们每次都通过new一个容器对象,那么每次都要重新加载配置文件,都要重新生成这个singleton bean的集合,这样所谓的单例就

接口测试原理、流程及用例设计

接口测试的原理是模拟客户端向服务器发送报文请求,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的一个过程. 接口测试流程: 模拟客户端连接服务器(服务器提供的端口是否可访问) ↓ 客户端发送报文请求 ↓ 服务器端接收请求并做处理 ↓ 检查返回的预期结果并与实际结果对比 ↓ 结束 接口测试用例设计: 接口测试的主要测试对象是接口,但随着系统复杂度越来越高,接口越来越多,完全覆盖所有接口是很难的一件事情,且实际过程中任意内部接口的变动都可能导致我们测试用例的不可用. 所以通

基于技术方案的用例设计

上一篇介绍了基于需求文档的用例设计,主要是运用了黑盒测试的用例设计方法.之前提到用例在整个项目过程中是动态更新,逐步完善的,经过了需求评审的用例编写后,项目会进行技术方案评审,评审结束后,需要基于技术方案对用例进行一次补充完善. 我仍然以登录为例,由于每个开发设计的方案不同,在此列一个大致的通用方案,基于该方案做用例设计,精髓会了,其他的融会贯通. 登录成功的时序图如下: 登录失败的时序图如下: 分析时序图,步骤比较清晰,客户端的主要工作分为几部分: 1.绘制登录界面(UILabel.UIBut

【小白的java成长系列】——构造方法私有化(单例设计)

有了解过spring框架的童鞋们就知道,spring的bean默认是什么形式呀?---单例形式的. 问:那什么叫做单例?单例其实就是Singleton,顾名思义就是只有单个的实例对象操作. 那为什么要使用单例呢? 至于这个问题,后面再做解释,我们先看代码: package me.javen.oop; public class SingletonDemo { public static void main(String[] args) { Singleton singleton1 = Single

基于需求文档(PRD)的功能用例设计

上一篇我讲了在项目运行过程中,用例是需要动态更新的.接下来我将结合实例(移动app)讲解在不同的阶段如何设计用例. 需求文档(PRD)主要讲述app的某个模块有什么功能,每一项功能的页面展示.页面操作有哪些,不同操作之间的关系是什么.基于PRD的用例设计是使用黑盒测试方法,而我平时主要使用了等价类划分.边界值分析法.状态转换测试.场景测试,操作实践时偏好于将模块分成页面展现.页面操作.接口.异常流,在每一个子项里运用黑盒测试方法进行设计. 以移动app的登录为例,大致需求如下图: 一.验证登录弹

新增和修改页面的用例设计和Bug提交

问题: 新增页面和修改页面,基本上输入框都一样,那比如同一个输入框的用例设计: 1. 写了新增页面的用例,修改页面对该输入框还有再写一遍用例的必要吗? 2. 执行用例时,新增页面验证了必填项,长度,数据类型,修改页面还要再验证一遍吗? 3. 提交Bug时,新增和修改页面的同一个输入框都出现了Bug,是只提交一个还是新增和修改各提一个. 参考答案: 我们写用例最容易落入一个误区,就是为了写用例而写用例.实际上写用例最主要目的是分析系统,如果系统业务复杂,用例分析与设计就很重要,如果很简单的功能不写