小型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语句了.  后面让供应商给还原到以前最近的版本才解决