[测试用例设计]

目录

登录界面测试

微信红包测试

微信朋友圈测试用例

测试一个输入框(计数)

测试百度搜索

BUG描述、评级

一条bug记录的组成

---

登录界面测试

以用户登录为例，一般的小白可能只能够想到一些功能性测试（如下）。

现在，针对“用户登录”功能，基于等价类划分和边界值分析方法，我们设计的测试用例包括：

• 输入已注册的用户名和正确的密码，验证是否登录成功；
• 输入已注册的用户名和不正确的密码，验证是否登录失败，并且提示信息正确；
• 输入未注册的用户名和任意密码，验证是否登录失败，并且提示信息正确；
• 用户名和密码两者都为空，验证是否登录失败，并且提示信息正确；
• 用户名和密码两者之一为空，验证是否登录失败，并且提示信息正确；
• 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入正确的验证码，验证是否登录成功；
• 如果登录功能启用了验证码功能，在用户名和密码正确的前提下，输入错误的验证码，验证是否登录失败，并且提示信息正确。

乍一看，感觉测试案例已经够多了，不过对于一个稍微有点经验的工程师，可能会加上下面部分

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

上述还仅仅只是功能测试，你还可以从其他的角度比如安全性、性能以及兼容性三大方面。 在上面所有的测试用例设计中，我们完全没有考虑对非功能性需求的测试，但这些往往是决定软件质量的关键因素。>

安全性测试用例包括

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

性能压力测试用例包括:

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

兼容性测试用例包括：

• 不同浏览器下，验证登录页面的显示以及功能正确性；
• 相同浏览器的不同版本下，验证登录页面的显示以及功能正确性；
• 不同移动设备终端的不同浏览器下，验证登录页面的显示以及功能正确性；
• 不同分辨率的界面下，验证登录页面的显示以及功能正确性。

微信红包测试

单个红包：

• 红包金额为空、0、0.01、200.00、200.01、199.99、200
• 留言输入数字、字母、汉字、特殊字符
• 留言长度
• 留言复制粘贴
• 表情选择、收藏表情、其他表情
• 删除表情、重新选择表情
• 选择支付方式零钱、银行卡、添加新卡支付。其中钱数<红包钱数、其中钱数=红包钱数、其中钱数>红包钱数
• 使用指纹确认付款（正确的、错误的指纹）
• 使用密码确认付款（正确的、错误的密码）
• 红包成功发送后 相应支付方式中钱数减少（减少金额与红包金额一致）
• 接受者能看到红包具体信息，红包金额、留言、表情均能正确显示
• 红包被拆开后显示已领取，领取者零钱中增加正确金额，再次领取只能查看红包信息
• 发红包者自己领红包
• 红包24小时未被领取提示红包被退回，相应支付方式中钱数增加（增加金额与红包金额一致），对方不能领红包

群发红包-普通红包： （只写了与单个红包不同的地方）

• 红包个数 为空、0、001、100、99、101
• 红包拆开每个金额一样 均为发红包时设置的单个金额对应的钱数
• 红包被拆时，有相应提示
• 发红包者自己领红包
• 红包24小时内未被拆完，剩余钱被退回，相应支付方式中钱数增加

群发红包-拼手气红包：

• 红包每个人拆开金额不同，总金额与发红包设置的总额一致
• 红包24小时内拆完后显示最佳手气
• 红包24小时内未被拆完不显示最佳手气

兼容性测试

兼容性： 安卓、苹果 不同型号版本手机

UI测试： 界面无错别字，风格统一

中断测试： 不同应用之间切换、断网、来电、短信、低电量、手机没电

网络测试： 2g/3g/4g WiFi 移动联通电信 弱网 无网

微信朋友圈测试用例

朋友圈发送功能

• 只发送文本

​ a、考虑文本长度：1-1500字符（该数据为百度数据）、超出最大字符长度

​ b、文本是否支持复制粘贴

​ c、为空验证

• 只发送图片

​ a、本地相册选择/拍摄

​ b、图片数量验证：1-9张图片、超出9张

​ c、为空验证

• 只发送视频

​ a、本地相册选择/拍摄

​ b、视频秒数验证：1-10s，超出10s

​ c、视频个数验证：1个，超出1个

​ d、视频格式验证：支持的视频格式，例mp4、不支持的视频格式

​ e、视频大小验证：苹果400kb以内、Android200-300kb（此为百度数据）、超出规定大小

​ f、视频预览增删改操作

​ g、为空验证

• 发送文本+图片：输入满足要求的文本、图片进行一次验证
• 发送图片+视频：不支持发送
• 朋友圈发送内容是否有限制，例如涉及黄赌毒等敏感字
• 所在位置

​ a、不显示位置：发送到朋友圈动态不显示位置

​ b、选择对应位置：搜索支持、自动定位、手动编辑

​ C、点击取消，返回上一级页面

• 谁可以看

​ a、设置公开：所有朋友可见

​ b、设置私密（仅自己可见）：自己查看朋友圈-可见、好友查看朋友圈-不可见

​ c、设置部分可见（部分朋友可见）：选择的部分好友-可见、不被选择的好友-不可见、是否有人数上限

​ d、设置不给谁看（选中的朋友不可见）：不被选中的朋友-可见、被选中的朋友-不可见、是否有人数上限

​ e、点击取消，返回发送页面

• 提醒谁看

​ a、提醒单人/提醒多人：被提醒的朋友-收到消息提醒、未被提醒-未有消息提醒

​ b、是否有人数上限

​ c、点击取消，返回发送页面

• 同步QQ空间：默认不同步、同步到QQ空间

• 取消发送朋友圈操作

​ a、选择相机，点击取消，返回朋友圈页面

​ b、进入朋友圈发送页面，选择文本图片，点击取消

​ 13）朋友圈当天发送次数是否有上限限制

朋友圈浏览功能

• 文本查看：

​ a、过长文本内容是否隐藏，并支持查看全文

​ b、右键选择复制、收藏、翻译

​ c、url链接是否支持点击跳转网页

• 图片查看

​ a、小图右键支持收藏/编辑

​ b、点击支持大图浏览

​ c、选择发送给朋友、收藏、保存图片、编辑

​ d、多张图片支持左右滑动浏览

• 视频查看

​ a、右键视频支持静音播放/搜藏

​ b、点击视频播放按键支持播放视频

​ c、选择发送给朋友、收藏、保存视频、编辑

• 分享动态浏览：QQ空间/公众号文章/非腾讯产品分享后朋友圈是否正常显示

• 赞：点赞、取消点赞

• 评论

​ a、评论长度：评论字数合理长度、评论超过字数上限

​ b、评论类型：纯中文、纯数字、纯字母、纯字符、纯表情（微信表情/手机自带表情）、混合类型、包含url链接；

​ c、评论是否支持复制粘贴

​ d、为空验证

​ e、发表评论后删除

​ f、评论回复操作

• 删除朋友圈动态

• 更换相册封面

• 刷新是否正常获取新动态

• 上滑是否加载更多

界面/易用性测试

​ 1、技术人员角度：页面布局设计是否跟产品原型图/ui效果图一致

​ 2、但除了考虑1之外，我们同样要考虑到用户使用：功能操作是否简便，页面布局排版风格是否美观合理，提示语相关信息是否易于理解

中断测试

​ 1、主要考虑：a)核心功能 b)当前功能存在实时数据交换，例发朋友圈、浏览朋友圈进行中断，是否容易出现崩溃

​ 2、中断包括：前后台切换、锁屏解锁、断网重连、app切换、来电话/来短信中断、插拔耳机线/数据线

网络测试

​ 1、三大运营商不同网络制式测试

​ 2、网络切换测试：WIFI/4G/3G/2G

​ 3、无网测试：对于缓存在本地的数据，部分朋友圈信息是否支持浏览

​ 4、弱网测试：

​ a、延时：页面响应时间是否可接受、不同网络制式是否区分超时时长、出现请求超时，是否给予相应的提示

​ b、丢包：有无超时重连机制、如果未响应，是否给予相应提示

​ c、页面呈现的完整性验证

兼容性测试

​ 1、Android手机端、苹果手机端、pad版（主流）功能界面显示是否正常

​ 2、各平台朋友圈展示数据是否一致

安全测试

​ 发送朋友圈时，文本输入脚本代码，是否出现异常

性能测试

​ 1、服务器性能测试

​ 可通过loadrunner/jmeter工具实现，主要关注TPS、响应时间、吞吐量、CPU、内存等

​ 2、app客户端性能测试

​ 可通过GT工具实现，运行时关注cpu、内存、流量、电量等占用率

​ 3、app压力稳定性测试

​ 通过monkey工具实现，频繁发送朋友圈，浏览朋友圈请求，是否容易发生崩溃

测试一个输入框(计数)

通常说来，我们考虑一个测试对象的时候至少从以下六方面来考虑。

• 功能性
• 易用性
• 可靠性
• 性能
• 安全
• 兼容性

​ 如果你是一个测试菜鸟，从功能性出发，你可能会列出以下一个典型的列表：

• “banana”：3（一个合法的英文字）。
• “A” 和“a”：1（一个简单有正常结果的合法输入）。
• “”：0（一个简单的结果为0的合法输入）。
• Null：0（简单的错误输入）。
• “AA” 和“aa”：2（个数大于1并且所有字符都为a/A的输入）。
• “b”：0（一个简单的非空合法输入，结果为0）。
• “aba”：2（目标字符出现在开头和结尾，以寻找循环边界错误）。
• “bab”：1（目标字符出现在中间）。
• space/tabs：N（空白字符与N个a的混合）。
• 不包含a的长字符串：N（N大于0）。
• 包含a的长字符串：N（N是a的倍数，试试龙妈的名字）。

​ {java/C/HTML/JavaScript}：N是a出现的个数（可执行字符，或错误，或代码解释）。

更优秀的测试工程师，会开始考虑后面五个方面，设计以下用例。

• 质疑界面的外观、调色板和对比度（这与相关应用风格一致么？）
• 文本框太小了，建议加长以便显示更长的输入字符串
• 这个应用能否在同一台服务器上运行多个实例，多个用户同时使用是否会有问题。
• 是否会根据用户的输入自动匹配内容？
• 建议使用真实的数据，如从词典或书中选择输入内容。
• 提出疑问：“输入的数据是否会被保存”，输入字符串可能包含地址或其他身份信息。
• 输入HTML和JavaScrip，看是否会破坏页面渲染。
• 尝试复制/粘贴字符串。
• 提出疑问：“计算足够快么？在大并发下使用”。
• 提出疑问：“用户怎么找到该页面？”
• 提出疑问：“有快捷键的设置么？比如输完字符后敲入回车键而不是点击提交按钮”

​ 还有一些测试点，只有经验丰富的测试工程师才会想到。

• 意识到计算会通过URL-encodedHTTP GET请求传递到服务器，字符串可能会在网络传输时被截断，因此，无法保证支持多长的URL。
• 建议将此功能参数化，为什么只对字母a计算呢？
• 考虑计算其它语言中的a（α，Alpha）。
• 考虑到该应用是否应该国际化。
• 考虑到输入法全角输入和半角输入是否相同。
• 考虑编写脚本或者手工采样来探知字符串长度的上限，然后确保在此区间内功能正常。
• 考虑背后的实现和代码。也许已经有一个计数器遍历该字符串。
• 提出疑问：“HTTP POST方法和参数会被黑掉码？也许有安全漏洞？”

测试百度搜索

我们可以从以下几个角度进行测试。

功能测试：

输入搜索信息，点击搜索按钮是否能获取搜索结果，跳到结果界面； 搜索结果界面弹出的信息是不是符合我输入的信息 ， 没有输入信息，按搜索看会有什么结果 ，对输入框能输入的最大字符数进行边界测试，（假设限制是30个字符），那么分别输入20，30，31个字符的文本进行测试，测试超出输入限制会出现的结果

测试输入敏感词时的搜索结果，输入不同国家语言的搜索结果 ，查询不到搜索结果的情况显示的结果，从搜索结果界面返回的按钮能不能正常返回

点击百度的标签能不能跳到相关的热搜界面

测试百度的图片搜索能不能正常使用

图片拖曳和上传的功能是否均能实现，粘贴图片网址能不能用

如果粘贴的图片网址不存在是否能给出正确的提示反馈

输入特别大的图会发生什么现象

性能测试：

测试搜索时的响应时间能否符合需求

网速慢的条件下还能不能正常搜索

多用户同时访问，或者一个时间点访问量突然增大的情况，对这些特殊情况进行模拟，测试还能不能进行正常搜索

易用性测试：

使用操作是否简单，是不是输入查询信息之后点击搜索按钮就行了；

在输入框输入搜索词的过程中下拉框能否弹出相关的联想搜索（你可能要搜）

输入框有没有保存最近搜索的信息的记录

除了点击搜索按钮进行搜索，测试按回车进行检索的功能

兼容性测试：

多种系统下的多种不同的浏览器下是否能正常显示、正常使用；

在不同的手机浏览器中打开是否能正常显示、正常使用；

各种语言平台下是否都能正常使用

安全性测试：

能不能防止搜索时对数据库的恶意攻击的情况，如SQL注入

UI

界面设计是否简介，是否符合用户审美

图标能不能正常显示，界面有无错别字

BUG描述、评级

对bug的描述尽量简短但要求清晰，对bug出现的条件进行详细的描述，包括输入的测试用例、使用的环境、有没有和其他软件同时运行，以及需要写清bug出现的位置，帮助开发更好定位。

按照用户体验（bug是否很严重的影响用户体验）、影响系统的程度进行评级

一条bug记录的组成

• bug内容
• bug发现时间
• 测试条件（系统配置信息、环境、软件版本、浏览器版本…）
• 预期结果和实际结果的对比，相关的分析
• 如何重现这个bug的步骤
• 这个bug的严重性（会多大程度的影响系统或用户使用）
• bug发生的位置