如此Tricky的测试场景，你应该怎么办？

什么是Tricky的测试场景？

Tricky的测试场景

测试场景

Scenario testing is a software testing activity that uses scenarios: hypothetical stories to help the tester work through a complex problem or test system. The ideal scenario test is a credible, complex, compelling or motivating story the outcome of which is easy to evaluate.

Tricky的测试场景

作为一名专业或非专业的IT研发人员，你一定遇到过几个步骤：

• �发现BUG
• 重现BUG中：方法A、方法B、方法C....方法N
• 没有重现BUG，先提交到缺陷管理工具吧
• 过了N久之后
• 回归BUG时，这里怎么有一个BUG，重现不了，算了先关了吧，等后面出现再重新开启

一个BUG就这样被关闭了，他可能还隐藏在系统中的某个位置，等待机会爆发

隐藏在深处的一个不定时炸弹

为什么会这样

• 重现步骤太复杂
• 重现前提要求很多
• 经常的真相在这里：没有Get到真正的重现步骤

举几个栗子

客户投诉

测试验证码，收到客户投诉

• Scenario

• 作为普通用户,在用户注册时，可通过获取短信码使用手机号进行注册

• 功能

• 用户注册时，需要测试手机号码与获取的短信码是否能正常收到且匹配。
• 短信验证码由本项目生成,但由第三方来发送
• 验证码发送是由第三方提供的，无法完全Mock
• 数据库中会记录收到的短信验证码.

• 测试策略

• 测试验证码能否匹配时,用了自己的手机号码来测试.
• 后面再测试是否匹配时,发现没有手机号码可用,就 随机 输入了手机号码进行测试,通过查询数据库来获取验证码

• Tricky

• 如上进行了一阵子测试,由于是国内某银行项目,后面就收到了客户投诉: 客户没有进行任何的操作,便收到了短信验证码

• 分析

• 是否每次测试时,都需要通过第三方来发送短信验证码.
• 仅Mock第三方收到请求,不需要每次都真实的发送短信功能

• TIPS

• 测试中,一定要确保 普通用户 不会收到短信验证码

显示真的不一样

同样返回内容,在不同的浏览器中显示不同

• Scenario

• 作为普通用户,在浏览页面时,可查看到Title显示的内容

• 功能

• 需要从第三方系统中获取指定的内容,返回给浏览器,并显示到Title

• 测试策略

• 为确保兼容性,使用不同的浏览器进行查看
• 涉及浏览器: Chrome,FireFox,IE

• Tricky

• 仅Chrome查看正常显示,FireFox/IE查看均会显示 部分 乱码

• 分析

• 返回的内容中有 Unicode 值为15的内容,这个返回值引起的显示乱码

• TIPS

• 在对第三方集成时,一定要先针对所有输入/输出内容均进行字符集处理.确保所用的字符集均一致

同样的样式，在同一类浏览器中显示不同

• Scenario

• 作为普通用户，在浏览页面时，可查看到正确的页面显示与布局

• 功能

• 在页面布局测试时，需要查看页面的显示与布局的正确性

• 测试策略

• 使用浏览器查看页面的显示与布局

• Tricky

• 在测试电脑中，发现页面的布局中的样式有问题（按钮被换行）
• 在DEV的电脑中完全是好的（使用的同一发布版本进行测试）

• 分析

• 浏览器的版本是完全一致
• 浏览器的 缩放比例 不同，测试电脑的页面被设置为 缩放90%

• TIPS

• 在测试页面的显示和样式时，一定要确保页面 浏览器版本、页面缩放 完全一致

时间都去哪了？

PaaS平台部署后，时间出现偏差

• Scenario

• 作为普通用户，在注册新用户时，需要使用获取的验证码在5分钟内进行验证，否则验证码失效

• 功能

• 页面前端点击 获取验证码 后，需要在生成验证码5分钟内，进行注册
• 生成的验证码会存储在 数据库 中
• 生成验证码是由程序代码生成，有效期的验证是由生成验证码时生成的Createtime和当前时间比较

• 测试策略

• 在点击 获取验证码 后，从数据库中查询生成的 验证码
• 通过查询的验证码，进行用户注册

• Tricky

• 在点击 获取验证码 后，直接去数据库中查询验证码
• 使用查询获取的验证码，在进行用户注册时，提示验证码已过期(查询与注册的时间操作差，绝对在5分钟内)

• 分析

• 此功能在非PaaS平台时完全正常的
• 部署到Paas平台后，在PaaS平台时，程序代码是部署到一台机器、数据库部署在另外一台机器
• 验证码的生成时间是由数据库脚本生成，获取的数据库的当前插入时间
• 验证码有效期验证时，当前时间为从程序代码部署的机器获取当前系统时间
• 两台部署机器时区设置不一致(程序代码：Asia/Shanghai，数据库:Etc/Zulu)，两个时区相差8小时

• TIPS

• 部署环境时，一定要先确保时间的设置是否会对功能有影响
• 涉及到时间处理时，一定确保使用的是统一的参考时间

Mock不可靠

Mock的模块在集成后，Mock相关的功能出错

• Scenario

• 作为普通用户，在查看个人账户时，可查看到账户余额

• 功能

• 普通用户在查看个人账户时，需要通过系统去查询第三方系统数据
• 在开发环境中第三方系统无法直接连接进行调试开发，因此提前做了Mock进行开发

• 测试策略

• 测试时，正常使用个人账户查询结果

• Tricky

• 在到ST测试环境时，无法正常查询账户余额。数据解析报错

• 分析

• 使用Mock返回的数据时，在ST环境可正常查询
• 但使用第三方真实返回的数据查询时，在ST便会报错
• 对真实数据进行分析，发现数据结构已与之前Mock的不同

• TIPS

• 针对Mock系统，一定要有对应的测试，确保接口的正确性及数据正确性
• 针对需要Mock的功能，一定要定期与集成方沟通，确保开发功能、接口变同的同步

环境真的不一样

特定文件内容无法上传到生产环境，其它环境均正常

• Scenario

• 作为注册用户，在个人信息中，可上传文档

• 功能

• 注册用户，可使用上传文档功能，上传个人文档
• 针对上传的文件内容及类型均无限制（由于系统是特定人群使用，所以对文件类型均没有限制），文件大小此处不考虑

• 测试策略

• 针对上传文件类型进行测试：txt/exe/pdf/doc等

• Tricky

• 上传txt/html时，若文件以<开头时，上传功能在其它环境均可正常使用，但在生产环境则上传会失败

• 分析

• 生产环配制有网关，会对文件内容进行过滤
• 若文件html/js/txt文件中以<开头时，则会被判断为注入文件

• TIPS

• 作为测试人员，也要对安全测试常出现的问题进行考虑

以上的Scenario只是实际工作中的部分场景，仅用来�抛出问题

如何定位Tricky的定位操作

定位Tricky场景

• 数据源
  数据源是要定位问题的根源，确保数据源的完全正确性，才能保证后续流程。如：数据格式、编码格式、字段完整性、字段次序等。
• 出口数据
  出口数据与数据源类似，数据源为被分析软件的数据入口。相对于被分析软件本身，出口数据是需要展示给用户所需要的数据。出口数据是经被分析软件加工过的，只有被正确的加工，才能正确的展示给用户。
• 环境
  软件运行的环境包括：软件环境、硬件环境。软件环境包括：操作系统类型、操作系统版本、浏览器、容器、环境的部署架构等，硬件环境包括：网络环境、网速、硬件设备等。
• 日志
  日志的分析，需要从模块日志、系统日志及网络请求日志来进行。模块日志为出现问题的模块所生成的相关日志，系统日志主要为整个系统运行时生成的日志，网络请求日志主要涉及与网关相关的日志范围。建议排查次序：模块日志>关联模块日志>系统日志>网络请求日志
• 请求分析
  针对请求的内容进行分析，HTTP请求的各种方面均需要考虑。建议排查次序：请求地址>请求数据>请求编码方式，其它的方面也有可能引起Tricky的问题，但主要集中在这几个方面

参考资料

• Scenario Test
  https://en.wikipedia.org/wiki/Scenario_testing
• PAAS
  https://en.wikipedia.org/wiki/Platform_as_a_service
• 时区差
  https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
• Asia/Shanghai
  https://en.wikipedia.org/wiki/Asia/Shanghai
• Etc/Zulu
  http://www.prokerala.com/travel/timezones/Etc/Zulu
• Mock
  https://en.wikipedia.org/wiki/MockServer
• ST测试
  https://en.wikipedia.org/wiki/System_testing
• 安全测试
  http://www.ltesting.net/ceshi/ceshijishu/aqcs/2015/0104/207771.html