小型web产品的功能测试要点或测试大纲
本文参考配置啦：-- Web类产品功能测试大纲，黑盒测试参考测试范围
【官网】：无
应用场景
黑盒测试，功能测试中常常需要考虑很多问题，这里根据本人的工作经验遇到的进行了系列总结。给出了一个常用的测试范围和测试大纲。
基础资源
产品具体业务
使用须知
具体参考本行业的实际情况进行调整
配置步骤
| 问题分类 | 子问题 | 备注 |
| 测试环境 | 测试环境的搭建. | 1.为了正式环境的稳定性，需要有测试环境作为支撑. 2.涉及调整比较多时， 先在测试域名下测试，没问题了再覆盖正式。 |
| 发布与升级 | OEM方案 | 1.根据域名判断 |
| 上线监测与运维辅助 | 1.需要增加类似友盟统计这样的崩溃统计，用户行为，分布统计的组件..方便后续调整，跟进. | |
| 服务器操作系统相关 | 1.涉及php等跨平台的语言，如果在windows上开发测试的，那么上线到linux之前需要注意linux上相关的兼容性. 1.1)linux上严格区分大小写，涉及php的包名，类名必须严格一致... 这也导致一些框架类似thinkphp中$this->fetch()可能需要改成$this->fetch("控制器名/Action名"); 1.2)一些php语法,类似header("Location:http://www.baidu.com");后面需要增加exit. 否则无法执行. |
|
| 发布之前的代码审查 | 1.白盒或项目经理应该在发布之前查阅开发人员待发布版本修改的具体内容. 1.1部分开发人员会删除旧代码重新写，解决老问题引入新问题..可能考虑不周. 1.2部分开发人员在时间紧迫且代码没有封装的情况下，会将修复代码到处放，放多了，放错了，放到位置不全等都有可能. |
|
| 发布之前的配置检查 | 1.服务器地址，接口域名(正式，测试), 应用ID，秘钥等.//正式和测试可能有区别. | |
| 发布之后的功能测试 | 1.每次涉及后台代码的发布，都需要进行一次涉及范围的测试(注册，登录，支付，导出等). | |
| 服务器调整 | 服务器迁移 | 1.需要紧急测试首页，注册，开通，导入文件，导出文件等.(对应测试的是脚本执行，写入权限等) |
| 域名解析变更指向 | 1.涉及服务器迁移后解析域名变更时，先确保新的服务器上本地能运行或用其它临时域名能测试他通，之后才进行域名解析，否则将乱成一团。 | |
| 业务流程 | 关联后台的各角色测试 | 1.平台各类员工(角色)都需要进行相关的测试. |
| 后台，第三方，app联调. | 1.开发之初可能是用假数据测试的，需要进行真实环境真实数据的测试.(后台，app，第三方监测，交易记录等的明细对比，余额对账等). | |
| 业务主分支覆盖测试 | 1.有些时候为了省事，或因为陷于细节导致进度问题下，多数仅仅覆盖了一个或部分分支. | |
| API相关 | 1.同版本：尽量以兼容方式升级 | 1.)比如App通过json与服务端交互，假设新版APPjson中增加一个字段，老版本没有..那么服务端如果没有判断则会导致老用户上传的内容json无法反序列化进而失败. |
| 运营相关 | 查阅第三方监控数据 | 1.崩溃问题及趋势:快速直观的锁定问题. 2.新增用户等. |
| 用户手册 | 1.每个重大版本都要撰写（或更新）用户手册，用户手册需要从新用户的角度开始出发，从0开始引导，介绍. | |
| 格式与容量 | 文字长度控制 | 多了会样式拥挤，或者导致程序错误. |
| 数据项的个数太多无法显示全 | 有些容器下，下拉选数据项太多会无法显示出来，因为没有滚动条. | |
| 自定类的数据添加条数限制 | 有些样式设计时考虑最多多少个，多了就错乱了. | |
| 破坏json，xml格式的特殊字符. | 1.)对xml如果包含&,<>等，以及json里的",\r\n等都会导致格式错误.对该类问题需要进行编码处理，比如base64等，之后收到了之后再单个进行处理. | |
| UI交互 | 进度条等 | 类似登录等地方如果网速慢，如果没有转圈或进度条之类的，用户会误以为点击失败或程序出错 |
| 无数据记录时 | 1.)有时无记录时，部分页面中如果初始化页面没有判空等处理，则会崩溃. | |
| 默认值与空值问题 | 1.因为某种原因，某些值为null或者没有初始化时间..会显示出null,0001-01-01等格式..应该对其 进行相关判断处理，以友好的"空白"，"无修改"，"无内容"等代替. |
|
| 分页(下拉) | 下拉是否可用，下拉(分页)与实际数目的总页数，总数据数是否和实际数据条数是否能对应上. | |
| 适当的数据聚合. | 尽量相关的信息在一个手机页面看到，不要来回点击跳转. | |
| 支持中断后再操作 | 1.比如用户操作一批数据，中间打断去做别的(或来电话，或没电关机，或其它操作)，之后再进入，需要能够处理好起点，避免重复无效的操作. | |
| 排序问题 | 一般用户关心或对比都是关注最近发生的事情，所以一般来说都应该是按时间倒序. | |
| 虚拟键问题 | 华为手机有虚拟键，有些手机没有，这导致有些app页面的底部特别宽，或者索性遮挡住了虚拟键影响正常使用. | |
| 是否有业务操作提示 | 1.对于一些重要按钮或其它触发操作，需要增加响应的悬浮提示或下方的提示，防止用户看不懂导致沟通成本加大. | |
| 如果手机号绑定错误 | 1.)对于没有卡或手机号绑定错误的情况，会不会丢失数据. | |
| 空格问题 | 有些时候输入的内容前或后方会有空格，如果带过去存储了，会导致用户下次登录时无法登录或无法使用. | |
| 错误提示 | 1.程序出错时，尽量给用户看到用户能理解并知道怎么做的提示..如果方便开发者定位问题，则还可以加上错误码. | |
| 账户相关 | 登录交互提示 | 1.验证码，用户名或密码错误，账号禁用等用户需要理解或指导的原因要提示出来.尽量在每个 提示中能够告诉用户出现什么问题并需要如何解决. |
| 账号状态关联行为 | 1.如果账号禁用了，则无法登录，并无法参与一些正常的业务处理，比如分配，审核等. | |
| 账户授权与到期控制 | 1.账户授权是否生效. 2.账户授权到期是否能够有相关响应. |
|
| 用户在多个不同设备浏览问题 | 1.类似QQ会有挤下线的处理及提示. 为了防止出现数据分配，同步数据等实时行为出现紊乱，应该避免一个账户在多个设备上登录的情况:可以通过设备号与账户关联，心跳挤下线等方案实现. 2.如果使用了设备号账号关联的方案，则应该在后台有配套的解绑或重置的方案. |
|
| 新账户测试 | 1.有时老账户随着开发一路测试过来，小问题可能有特殊办法解决了，甚至脚本..那么在后期需要通过新账户从零开始走一遍，暴露一些潜在问题. | |
| 一致性 | 产品名的一致性 | 1.产品名在app，后台，文档，官网等地方都应该保持一致，否则将增加沟通成本. |
| 列名 | 1.添加，编辑，查询条件，列表页字段名保持一致. | |
| 数据一致性 | 1.app上操作后，web后台，第三方的交易记录等需要保持一致.//包括数据记录，状态，金额. 2.避免避免app获取后在处理了，服务端却将数据删除了.//可以让app端发起删除. |
|
| 安全性 | Api的防sql注入 | |
| 密码等以*出现 | 类似密码等以*呈现. | |
| 重复提交问题 | 1.订单，请求重复提交，是否会造成相关的问题或错误.一般需要接口方进行协助处理. | |
| 删除，覆盖等操作有确认提示. | 重要数据的删除，覆盖等操作有一个确认提示，防止用户误操作. | |
| 代码，文档, 签名文件安全性 | 团队代码，文档应该都有一个服务器端存储备份. | |
| 测试数据 | 发布前：需要清理不相关的测试数据，避免遗留那些高权限弱密码|高余额弱密码等风险. | |
| 探针测试 | 比如webshell等可以将一个文件放入到上传目录是否能执行 | |
| 关于调试信息 | 不管是原生代码还是基于开源框架，都需要了解如何关闭调试，防止sql等出现在前端. | |
| 项目人员管理 | 1.由于项目中人员有进有出，所获得的SVN，FTP，云，第三方平台等的访问口令，权限都需要进行禁用，关闭等处理. 2.管理云产品（服务器，OSS，数据库等). |
|
| 业务场景 | 数据场景/来源 | 1.)密文来自营销魔盒, 明文的业务也需要进行正规测试. |
| 不按正常流程走，漏掉一些环节 | 1.)比如有些客户没有设置标签分类，就开始分配线索，打电话，这个过程没问题，但是通话记录中标签分类列表集合没有判空，进而导致出错 | |
| 供应商及第三方 | 关注供应商产品升级 | 1.)AI产品中遇到供应商在3.14日升级，导致这边接口有些时候会返回异常甚至返回sql语句了. 后面让供应商给还原到之前最近的版本才解决 |
