产品测试规范（七）

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

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

1.9 上线测试跟踪   

1.9.1 跟踪测试

系统上线后，可以做接口自动化的快速轮询测试，保证系统常用接口功能正常；对于版本迭代的功能要进行局部功能重点验证，看功能是否正常；常规的测试可以按照探索式测试+传统测试用例测试来进行，更全面的检查系统功能点；在跟踪测试过程中应该做好bug的记录工作，对于严重性bug需要开发修改后进行在一轮的验证测试，对于业务影响不大，如界面某个友好性提示问题，需做好问题记录，务必在下一次版本中优化掉，提高用户体验度的同时兼顾项目的实际情况。

可能用到的脚本都应提前准备好，避免测试时手忙脚乱，影响效率。

1.   Bug预防体系

测试人员在每次版本迭代中，会对项目的整体质量有一个把控，对于项目常见的问题，开发经常犯的错误都会有所了解，为了避免或者减少这样的错误或不规范的事情在发生，测试人员可以整理构建属于产品的bug预防体系，总结项目经常出现bug的种类、位置、以及可以提出针对性的规避措施，提高产品质量。

2.   分辨率兼容性

产品的网页通常保证在1024*768的分辨率下显示正常，但是常常忽略800*600分辨率下的显示情况，还有其他特殊要求的分辨率

如果页面设计明确只考虑1024*768的需求，则只在1024*768下验证各个产品页面的显示正确无误。

预防方法：

产品：需要明确产品需要兼容的常见屏幕分辨率。

开发：网页页面的设计需要针对多种屏幕分辨率制定设计规范，并依据设计规范进行开发

测试：在不同分辨率下验证页面显示的兼容正确性

3.   浏览器兼容性

目前市场上的主流浏览器如下：

a. IE 6.0-11
b. 360 浏览器
c. 猎豹浏览器
d. QQ 浏览器
e. Chrome 浏览器
f. FireFox 浏览器

通常情况下要保证IE 6-11和360 浏览器下的兼容性，需要保证页面不变型，Js执行均正确
预防方法：

产品：依据主流的浏览器市场占比，评估你需要兼容的浏览器

开发：针对需要兼容的浏览器类型和版本，指定浏览器兼容设计开发规（ CSS和Js 为主），并不断总结兼容性的经验教训

测试：在产品要求兼容的浏览器类型和版本下，进行兼容性测试

4.   Link问题

所有链接是否按指示那样确实链接到了该链接的页面

a.所链接的页面是否存在

b.保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面

c.链接的打开方式是否合理（在当前窗口中打开、打开新窗口）

d.是否有死链

预防方法：

产品：提供的需求中明确是否需要链接以及链接的位置以及链接的打开方式

测试：死链测试可以采用工具自动进行

5.   快捷键和焦点

Tab键和焦点的切换：在测试的页面中使用Tab键可以在全页面的所有元素进行焦点切换、并且要将相邻元素的 tab键切换顺序做到关联。

如：

a. 用户打开登录首页，则焦点应该默认显示在用户名输入框中

b. 在用户名输入框输入用户名之后，按下tab 键后，焦点应该切换到密码输入框中，而不是切换到其他元素上。

c. 输入密码后，按下tab键可将焦点切换到“保存密码”的复选框或者登录按钮以上操作，均对偏好使用快捷键的用户给于更友好的支持。

预防方法：

产品：考虑页面的默认焦点设定位置，设定tab键在界面上切换焦点的顺序

开发：依据产品人员的要求实现默认焦点位置，和tab 键的切换顺序

测试：验证默认焦点位置和tab切换的顺序

6.   前进、后退和刷新

IE 有一个特性：就是允许前进、后退到某一个页面或在当前页面刷新，在某些特殊业务场景的要求下，用户进行前进、后退和刷新当前页面的操作，会造成数据不完整、校验失败或者重复提交的情况。

预防方法：

产品：明确哪些敏感页面不允许前进、后退和刷新，一般情况下充值和支付等相关的页面或者其他数据提交页面禁止后退和刷新后提交。

开发：从技术层面考虑后退和前进操作是否会造成系统漏洞，让用户重复充值或者支付。如果用户尝试后退，则让页面强制失效或者禁止后退。

测试：和产品确认禁止后退的操作限制页面，进行针对性测试

7.   页面/JS/程序提示语言

通常情况下，产品人员并不会将产品需求细化到某句话应该如何提示用户，所以不同的程序员会根据自己的语言特点来提示用户，这就造成了不同程序员提示的语言风格完全不一样，造成产品友好度下降。

预防方法：

产品：产品人员和开发人员一起制定尽可能大而全的产品提示语言规范，并且作为规范说明提供给开发人员进行使用。

开发：遵守语言说明规范，并且针对各种系统的要求不断补充和规范提示

测试：测试过程中，验证语言是否符合指定的语言规范

语言文字提示：

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

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

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

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

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

f. 在语言中，永远不要用“你”这个字，要做一些操作步骤描述的时候，要多用“请”字

8.   文字缩略和折行

输入框提交很长的纯英文字母或者数字（不带任何全角字符和中文），并且不换行，则提交数据后，页面可能被此相关字符拉伸的特别长。

预防方法：

开发：提交公共处理字符的程序，解决上述问题，在所有输入框中增加相关处理

测试：所有输入框需要进行此输入测试，保证页面不会被用户的恶意输入拉长

9.   图片的显示和链接

图片是否增加链接通常会被开发人员忽略掉图片的显示位置通常会显示不同像素大小和比例的图，所以需要明确定义大图片如何缩减成为小图片的策略，以及小图片如何拉伸显示为大的图片。

预防方法：

产品：提供的需求中明确图片是否需要链接以及链接的url地址以及点击后实在当前页打开，还是弹出新页面打开。明确用户上传图片的显示方法，采用等比缩放，还是原大小显示，还是自适应显示 

开发：按照产品要求进行开发，针对图像的显示开发统一显示模块

测试：点击图片链接，验证图片链接的正确性和打开方式是否符合产品设计要求。传不同格式的图片（长方形图、正方形的图、原型图、超大图和超小图)，验证图片显示策略符合产品

10.         重复提交

用户提交数据页面，用户有可能连续多次点击提交按钮，造成数据的重复提交。黑客或者不良用户通过抓包可以获取提交的url ，进行尝试重复提交。

预防方法：

开发：点击“提交”后，将按钮变为Disable状态，禁止用户再次点击。针对每条提交的数据需要增加校验参数，方式不良用户通过其他工具恶意提交。

测试：通过页面验证按钮点击后的状态，通过工具发送重复提交的请求，验证系统是否可以处理重复提交的问题（金融系统需重点测试）

11.         输入判断问题

所有键盘输入的特殊字符，均可以正常保存

需要特别处理英文单引号、英文双引号等引起程序错误的问题

需要处理“ <”、“ /”和“ \”等容易保存出错的字符

数字框只能输入数字的内容

日期框需要判断日期是否合法

文本框需要判断字段长是否限制了

对于空格的处理，如果系统想trim掉字符串最开头和最后的空格，则需要整个儿系统都使用此策略，否则会造成数据传递不一致的问题

需要前台页面使用js来判断输入的合法性，同时后台逻辑也要添加判断输入合

预防方法：

开发：开发公共处理特殊字符的模块，在系统中进行规范应用

测试：对所有输入字段，进行输入判断测试，超长、空、特殊字符、 utf8字符等，并验证其他页面输入有效性，验证前台和后台均加有输入判断逻辑

产品测试规范纲要

目  录

第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级别定义