产品测试规范（八）

文章转载来源：微信公众号-光荣之路，也欢迎大家关注我自己的公众号，虽然很少发东西吧，，，

为了更方便的转载于大家查看，我对内容作了下排版。。。

1.10 Bug预防体系

1.10.1 web常见产品问题及预防

1.   多个ie同时访问

用户可能打开不同的IE使用相同的用户登录后进行操作，程序处理的时候要考虑到数据的一致性和同步问题。

多个IE使用不同用户，则cookie操作不会出现用户信息混乱的问题

预防方法：

开发：提前考虑到多个IE操作和多用户操作的使用场景，在使用cookie本地信息时需要做好针对性的程序处理，依据以往出现的问题设计开发规范

测试：按照多浏览器和多用户的使用情况，进行更多场景的测试

2.   安全考虑

在URL中不要带有明文的用户信息写代码的时候，不要把密码等敏感的用户信息明文的显示在url中。

即使要传递密码参数也不要使用pwd、 passpord这样的参数名称来进行传递，防止被截获。

要在传递参数的操作中使用NoCache参数，防止将url参数进行缓存。

预防方法：

开发： 建立数据传输技术规范和参数命名规范标准，严格参照执行，防止信息被拦截，造成应用系统的信息泄露。

测试：在缓存目录验证缓存信息是否有敏感信息，通过抓包方式验证是否暴露了敏感信息。

3.   直接URL链接检查

在Web系统中，匿名在地址栏直接输入各个功能页面的URL地址，检查系统是否处理了权限控制。

预防方法：

开发：代码走查的方式确认所有页面的具有权限验证逻辑。

         测试：获取所有系统url，在非登录情况下进行遍历截图，或关键字判断，验证非登录状态下无法访问具有访问权限限定的。

4.   防止sql注入和跨站攻击

不要把数据库或者程序的任何报错信息显示在页面上。

数据库中设计到操作权限的表名和字段名不要使用过于通俗易懂的命名，尤其是用户和密码之类的信息，禁止使用明文存储密码。

页面回显的inputtext, input hidden中的文本内容需过滤 “ <、 >、 ”、 ’等字符（半角转换为全角或者删除掉），防止 Javascript 的跨站攻击。

预防方法：

开发：出错的时候使用错误处理页面，建立标准的过滤关键字程序，统一数据库设计命名规范将敏感的表名做特殊命名处理，密码使用Md5或其他加密方式保存。

测试：验证所有页面不会暴露系统的任何出错信息使用安全工具appscan 或其他工具扫描系统的sql注入漏洞和跨站攻击漏洞。

5.   关于cookie

Cookie没有设定过期时间IE不支持Cookie的时候没有任何提示信息Cookie中的敏感信息没有进行加密。

预防方法：

开发：明确cookie生存期，并对生成的cookie进行检查，建立标准的检查浏览器对cookie支持的程序函数

测试：检查cookie的生存周期，以及是否存在敏感内容

6.   各种资源链接的释放

有的时候，系统莫名访问不了，有可能是数据库连接没有释放压力测试的时候，连接释放如果效率不高，则有可能出现大量连接超时失败内存泄露，长时间工作内存被占满了。

预防方法：

开发：系统资源的释放过程，最好通过代码review的方式来互相监督

测试：进行稳定性测试，验证长时间工作情况下的资源是否可以释放

关于keepalive的设置：

如果需要在一个连接同时获取多个资源，则需要打开apache或者resin的Keepalive参数为On，来提高系统的处理能力，减少多次建立连接所消耗的资源。如果大量的处理只是一次性连接，则不要打开Keepalive设置。在实际工作中，需要将keepalive分别设置On或者Off来验证哪个设置的性能更好。

7.   系统上线的log配置

上线以后，要关闭无用大量调试log信息不要打开过多的log

预防方法：

运维和开发：系统管理员对所有打开log级别进行确认，并群发相关人确认

8.   用户易用性

用户删除某个数据前，要明确提示用户是否要删除，默认把焦点选择为“否”。

预防方法：

开发：按照上述要求进行焦点设定

         测试：进行测试确认

9.   文档

程序实现和接口文档描述不一致

预防方法：

开发：团队中专人定期对接口文档进行审核和更新，保证文档、需求变更和程序实现保持一致

测试：仅参照文档进行测试

10.         多表操作

详细设计文档缺失，接口对多表进行操作时候，经常会发生有些表的数据没有被更新的情况

预防方法：

开发：审核设计文档是否覆盖必要的逻辑，加强代码审查

测试：通过查询接口判断所有插入接口的数据库操作是否正确等等，这些我们完全可以在不断测试过程中进行总结和积累，可以给开发进行培训，让他们了解这些常见的问题，在自测时注意这些问题，提高送测产品的质量。

1.10.2 app常见产品问题及预防

1.   界面适配

a：手机分辨率为1920x1080的高分辨率手机，在调整手机字体大小时，会导致页面显示出现变形；

b：因用户设置的特殊字体导致列表的字母条不显示；

c：某些 banner 图片在部分机型只能显示一半。

预防方法：

a：文字或者图片需要适配不同分辨率的机型时，建议使用dp方式进行开发，即使是使用dp,也需要考虑特殊分辨率的机型显示；

b：适应宽度/适应高度/高宽均适应的；

c：针对程序需求，设定合适的。

2.   系统适配

a：调用高版本API，导致某些机型进入主页显示空白页面。

预防方法：

a：调用高版本API，需要考虑兼容性，开发团队需要制定程序API调用规范。

3.   交互适配（1）

a：在输入框操作时，调出系统输入法软键盘后，没有有效启用键盘上的 “下一项”、“确定”、“搜索”等按键；

b：系统软键盘，在关闭当前页面时没有及时收起软键盘。

预防方法：

a：需求设计过程中需要考虑输入法操作键的使用细节，确保所有软键盘的输入键可使用；

b：设计规范：程序/页面设计针对输入法操作键的使用制定规范

4.   交互适配（2）

a：APP界面的“返回”操作与手机系统的“返回”按键操作效果不一致；或界面未提供“返回”，在无系统“返回”按键的手机上，无法返回。

预防方法：

a：设计规范：程序设计针对手机返回键制定使用规范；

b：在设计中要综合界面需求设定是否提供 “返回”操作。

5.   界面风格

a：对话框标点、英文字符出现全角、半角的不统一；

b：对话框、提示浮动框提示语风格不同，显示位置均不同，产品友好度下降；

c：字体和字号要在app中是不同的风格。

预防方法：-语言文字提示规范

a：全角字符和半角字符都要使用一个空格分开；

b：英文和数字之间要有空格分开；

c：汉字和英文、数字要有空格分开；

d：带有汉字的话要使用全角字符；

e：语言中不要混用全角和半角标点；

f：字体和字号要保持统一的风格。

6.   性能优化(1)

a：进入一些列表，若数量较多则会出现卡死:；

b：界面显示对象数量较多，某些会导致页面操作卡顿，用户体验很差；

c：处理大量数据时，用户等待时间过长，无进度条提示进度。

预防方法： 

a：程序对耗时较多的操作逻辑、判断逻辑，不放入UI主线程；

b：对数据库记录较多的操作，可以改成数据库批量操作，或者调用批量接口；c：程序在后台处理用户的输入，则提供进度条或对话框。

7.   性能优化(2)

a：后台播放内存泄露；

b：程序后台运行的时候，手机一直处于占用CPU的运行状态；

c：页面中的动态效果（如：马灯滚动）次数无限制，导致界面不断刷新消耗资源。

预防方法： 

a：使用静态分析工具或代码检查方式检查内容的分配和释放；

b：WakeLock机制是防回收技术，当没有播放、下载等操作时，应该主动关闭后台的唤醒锁，减少耗电。当再次需要使用播放、下载功能时才去开启唤醒；

c：对刷新消耗资源类操作，要有次数限制。

8.   多服务、多进程

a：某些功能操作后， app 无法连接网络；

b：进程被杀死后重启，通知栏中显示的信息不正确，没有显示正确的信息；

c：app未启动，通过其他第三方app的调用入口调用app ,无法正常使用某些功能；

d：服务停止后，无法被启动；

f：程序被手动退出后，进程仍然在后台存在。

预防方法： 

a：重新初始化时获取值时读取到空值，因此赋予一个默认值；

b：服务重启被回收重启时，初始化对象时要判断当前是否已存在，若存在则复用并更新内容

c：任务独立，需要创建不同的服务，生命周期不会互相影响，服务独立可以避免某个服务结束会影响到其他功能的正常使用。

总体，对有启用多服务、多进程的程序，有需要做好服务、进程的一致性管理。

9.   外部调用

a：某些机型启动app之后一直在调用某些外部服务（通过后台服务可以看到其他服务进程，退出app后，有些服务进程消失）

b：某些功能模块被扫描成存在木马病毒；

c：安全管家告警程序获取绝密权限（通讯录权限）。

预防方法： 

a：调用第三方功能作为统计或者监控作用时，需要考虑该sdk是否会一直唤醒app导致耗电或者程序无法真正关闭问题；

b：调用外部第三方SDK，要考虑被安全工具（上次有广告被扫描到病毒）扫描的设计需求；

c：及时关闭不需要的服务进程，在能满足需求的情况下，尽量减少使用敏感的系统权限。

10.         网络机制(1)

a：网络重试操作机制不统一，导致页面超时体验风格不统一；

b：某些应用页面，访问响应慢。 

预防方法： 

a：对底层网络重试机制做统一封装后，供上层调用；

b：固定好每次重试间隔（建议10s重试）和重试总次数（建议3次）；

c：为使页面提示可以区分网络层与业务解析层不同错误，需对不同错误类型做分类的异常处理，并提示用户原因或让用户重试；

d：对多个网络请求的界面，网络接口并行请求有利于提高响应速度。

11.         网络机制(2)

a：未加载完图片时切换到相似tab，切回不再加载图片；

b：进入一个tab，该页面已经加载完成，选择点击某个详细信息页面返回时，页面会闪一下。 

预防方法： 

a：一个页面有多个tab页时，用户切换tab可不轻易取消线程，取而代之使用暂停线程，退出页面时才回收清除；

b：启动负载分摊机制的请求，可先保存请求地址，供返回时判断避免重复加载。

12.网络机制(3)

a：iOS弱网络下获取不到配置，导致启动卡死；

b：sim卡未激活，无移动网络，某些功能卡死；

c：断网下启动，登录状态丢失，某些功能信息未正确显示。

预防方法： 

a：启动逻辑中的网络类请求不能阻塞UI主线程，即网络请求数据可不即时响应（可在下次启动时生效）；

b：按钮的点击事件不跟接口关联，做成异步处理不管是否有返回，都可以正常进行点击操作；

c：离线操作类，不因与当前网络状态有影响。

13.下载空间有效性判断

a：空间不足时，无法保存信息时，没有提示和提前判断；

b：本地存储空间不足时，保存文件时没有相应提示；

c：空间不足时，文件下载不成功，导致重复不停下载，浪费用户流量。

预防方法： 

a：对磁盘剩余空间的判断和自动清理逻辑可以做统一封装，提供各不同下载业务使用

b：可结合系统硬件配置的10%作为有效剩余空间阀值；

c：针对手机内外置SDCard，可以在空间不足情况下做分区切换机制。

14.下载文件完整性判断(1)

a：换肤图片未下载完，就触发换肤操作，导致换肤效果错误；

b：图片无法下载完全，导致图片展示不完整；

c：文件下载完成后，由于网络错误与源文件不符，导致下载后无法播放；

d：上传文件功能，目标物理文件不存在（界面缺显示存在），导致传送文件页面一直处于等待中。 

预防方法： 

a：通过判断下载前后文件的size或者文件内容签名，确保下载文件完整后再触发文件使用相关的逻辑；

b：文件传输时检查文件是否存在，若不存在则视为传输失败，不阻塞后续传输。

15.阻断连续操作

a：连续快速切换界面，或者频繁触发某些功能操作，导致程序卡死；

b：连续多次点击同一张图片，导致该图片下载错误。

预防方法： 

a：使用间隔响应、延迟响应的方式，达到多次相同操作只的触发一次有效逻辑。

b：操作一次后，可将按钮等元素设定为禁用状态，防止用户多次点击和请求。

16.有效统计逻辑

a：操作页面某些元素，也会导致发送页面使用的统计信息。

预防方法： 

a：为确保统计数据上传的有效性，只针对真正展示的界面做上报统计，对于展示不完整、非针对性展示不做统计上报。

17.程序健壮性判断(1)

a：分享到新浪微博（手机未装新浪微博客户端） ,app崩溃；

b：后台接口变更（返回值和类型发生变化），客户端不兼容新格式判断，抛出崩溃异常；

c：搜索默认操作崩溃；

d：使用外部第三方数据，出现空数据或者非标准格式，则app崩溃

e：输入框没有限制字符长度，保存时导致溢出崩溃。

预防方法： 

a：客户端针对接口返回需做容错处理，如返回为空、返回数据类型不一致；

b：任何文本框类型的需要限制输入长度。

18.程序健壮性判断(2)

a：某些功能的初始化逻辑没有加入启动逻辑，导致功能使用失败；

b：退出重启app，无法自动登录。

预防方法： 

a：制定启动加载逻辑规范；

b：对于重要的业务建议加入启动逻辑，并在业务实际使用时再根据状态多一层判断和加载；

c：产品人员需要考虑是否需要保存自动登录功能，并明确告之开发和测试人员。

19.安全机制

a：在URL中不要带有明文的用户信息写代码的时候，不要把密码等敏感的用户信息明文的显示在url中；

b：即使要传递密码参数也不要使用pwd、 passpord这样的参数名称来进行传递，防止被截获；

c：要在传递参数的操作中使用NoCache参数，防止将url参数进行缓存。

预防方法： 

a：建立标准的数据传输和命名规范，并制作一些网页开发模板或者规范供参考。

20.日志调试管理

a：上线以后，调试日志没有关闭，影响程序性能。

预防方法： 

a：日志统一开关，编译正式包需要关闭；

b：再程序界面有入口可以检查是否关闭，方便及时校验；

c：方便定位问题，可以做日志动态开启的隐藏开关；

d：方便收集问题，可以对问题类型做上报处理（典型如崩溃日志上报）。

产品测试规范纲要

目  录

第1章 产品测试规范

1.1 产品测试流程

1.1.1 测试流程图

1.1.2 测试流程说明

1.2 需求梳理

1.2.1 需求梳理

1.3 测试计划

1.3.1 测试工具选取

1.3.2 测试人员分配

1.3.3 测试业务场景选取

1.3.4 测试环境梳理

1.3.5 测试数据梳理

1.4 测试准备

1.4.1 代码管理

1.4.2 测试环境搭建

1.4.3 测试数据脚本编写

1.5 测试用例编写(功能测试框架)

1.5.1 界面友好性测试

1.5.2 功能测试

1.5.3 业务流程测试(主要功能测试)

1.5.4 链接测试

1.5.5 容错测试

1.5.6 稳定性测试

1.5.7 常规性能测试

1.5.8 易用性测试

1.5.9 兼容性测试

1.6 测试执行

1.6.1 接口自动化测试

1.6.2 探索式测试

1.6.3 传统测试用例测试

1.6.4 Bug跟踪

1.7 测试结果分析

1.7.1 结果收集

1.7.2 结果分析

1.7.3 测试分析报告

1.8 上线准备

1.8.1 版本发布

1.8.2 数据准备

1.9 上线测试跟踪

1.9.1 跟踪测试

1.10 BUG预防体系

1.10.1 web常见产品问题及预防

1.10.2 app常见产品问题及预防

1.11 BUG管理规范

1.11.1 bug提交规范

1.11.2 bug级别定义