产品测试规范

文章转载来自光荣之路公众号：https://mp.weixin.qq.com/s/4gSsZv2tHvTQ3XJ7x3QwUA?

 产品测试规范

1.1产品测试流程

1.1.1 测试流程图

1.1.2 测试流程说明

1.  需求阶段

测试人员了解项目需求及需求变更，包括需求规格说明书、功能结构及模块划分，根据需求梳理测试点。

2.  测试计划阶段

测试计划环节需要考虑测试工具选取，考虑需要测试的业务点，涉及到多业务量测试团队测试，需考虑人员分配问题，如：哪些人准备测试执行，哪些人准备测试过程中数据的收集与整理为后面统一分析做准备。

测试环境梳理为测试需要部署哪些应用，应用是单节点部署还是分布式部署，每个应用分配几台机器进行部署，以及测试工具及监控工具的部署等。

测试数据梳理为测试过程中需要考虑可能用到哪些数据如同时登陆的场景需要不同的用户，测试翻页功能需要的数据量，通过测试数据梳理能够理清可能需要编写哪些辅助脚本来进行测试。

测试场景梳理为根据选取的测试业务点来设计需要测试的场景。

3.  测试准备阶段

代码管理为分为开发代码、测试基线、正式基线等，测试代码应在测试基线中进行即与开发的代码管理库分离，测试合格的代码才可以分支到正式基线中。

测试环境的搭建工作也需要进行管理，哪些服务器用来搭建哪些应用应当有对应的部署文档以及部署架构图，即测试环境需心中有数且有文档记录，让人一目了然。

测试用例编写可以根据功能测试框架来进行，覆盖到所需测试的模块以及需求中指出的测试点。

测试数据准备为在系统正式测试前就准备好测试时需要的数据，如移动查单需提前准备好手机号码用来测试查询。

测试脚本准备为测试过程中通过手工无法进行或者效率很低可以通过代码来实现的环节，如：登录用户的准备，千万条用户性能测试同时登录系统，需要编写sql脚本来批量生成用户账号数据，又如：接口测试根据接口测试文档预先编写好所有的接口测试脚本。

4.  测试执行阶段

功能测试可以通过传统测试用例测试+探索式测试一起执行，提高测试产品的质量，性能测试将测试准备阶段准备好的脚本和数据以及部署好的工具，按照写好的测试方案来进行测试，接口测试按照接口测试方案来运行已编写好的脚本。即让所有的测试有条不紊的运行，不是想到哪是哪，而且所有的测试不是一蹴而就的，测试过程中需要进行bug的跟踪，指派给对应的负责人，把握项目的测试进度。

5.  测试结果分析阶段

根据测试的结果、日志收集结果、资源收集结果、异常跟踪结果等汇总分析生成测试分析报告并给出可行性的建议，如果涉及到调优工作，还需对调优结果进行验证，需要对上线的风险进行评估。

6.  上线准备阶段

测试人员需要准备线上测试需要用到的数据，需结合生产环境进行，如系统生成订单测试环境是不需要uim卡号的，但是真实的线上环境需要用到uim卡号，这就需要提前准备好线上测试的数据。

上线准备需要提供测试合格的发布资料(包括：发布包、数据库脚本、用户手册、部署文档、维护手册等)、还需要考虑好回滚方案。

7.  上线后测试跟踪阶段

可以持续构建接口自动化，快速进行一轮接口测试，保证常规接口正常运行，功能测试可以根据测试用例+探索式测试来进行，如果是更新补丁等，需要重点对上线更新的功能进行验证测试，当然测试过程中必不可少要进行bug的跟踪。

8.  项目总结阶段

对于项目整体的质量做总结分析，给出总结报告，测试人员需要根据每次的测试、上线等积累符合项目的bug预防体系，总结项目经常出现bug的种类、位置、以及可以提出针对性的规避措施，提高产品质量。

1.2需求梳理

根据需求文档、需求规格说明书来对需要测试的功能点进行梳理，而且通过需求文档能够更加了解项目的业务场景，一般情况下，在项目中需求文档有3种现状：

1.2.1 有详细的需求文档

比较严谨负责的团队项目的实施是有详细的需求文档的，我们就可以详阅需求文档来进行测试点的梳理工作，对于需求中你认为不明确的地方可以找项目领导人进行沟通，做到对需求整体把握和理解，利于测试更好的进行。

1.2.2  需求文档不明确即有文档但是文档很粗糙

一般有两种办法，如果开发团队很配合，可以要求开发或者需求分析人员完善需求文档，如果因为各种原因比如时间紧张或者开发就是不愿意，那么就需要自己去沟通对于文档中不明确的点问清楚，切记不要含糊不清的测试，于人于己都没有好处。

1.2.3  没有需求文档

如果你运气很不好遇到了，虽然我很同情你，但是貌似同情没啥用，我们知道做测试很重要的一点是：我有一个预期，我要把软件运行的实际值跟我的预期去比对，如果达到了预期，那么就没问题，如果跟预期不一致那就是有问题。那么如果没有需求，我们该怎么办：

第一种靠嘴去问，大家去协调，协商沟通，然后大家都回答没问题了，我会自己写一个概要的需求描述，然后让他去确认，他说可以，那咱们就这样测，有问题就不断的口头沟通；

第二种要基于用户使用的场景和行业的经验来去做判断它是不是合理的。

1.3 测试计划

1.3.1 测试工具选取

测试工具说明：

以上列出了自己在测试过程中所用过的一些工具，每种都有自己的利弊和自适应的测试场景，可以进行参考和根据实际需求来进行分析选取。

1.3.2 测试人员分配

测试场景敲定以后，对于大业务量的测试工作或者团队合作测试的任务需要分配好各自的任务，让大家各司其职，如：测试环境梳理和搭建人员、测试数据准备人员、测试脚本编写人员、测试执行人员、测试日志收集人员、测试结果汇总分析人员，每个人可以负责一个模块或者多个模块，更甚者有的项目任务量不多，一个人搞定这么多部分也是大有人在，即一个人搭建环境、一个人准备数据写测试用例准备测试、收集日志进行分析，这对测试人员的要求比较高才能更好保证产品的输出质量。

1.3.3 测试业务场景选取

根据需求说明文档，梳理需要测试的业务点和场景，比如应用系统的性能测试，需测试nginx负载节点的性能情况，是否可支撑1000/s的业务能力，极限环境下支撑2万/s并发，节点接收报文常规为几byte，大报文可达到8k，节点支持分布式部署。则我们根据这些信息可以梳理我们需要测试的场景有：直接压测一台节点观察性能峰值、nginx负载一台节点的性能、nginx负载两台节点的性能、nginx负载三台节点的性能、报文场景为500字节、1KB、8KB、并发数为依次递增至1500并发(保证1000/s并发是否可以)，看是否满足常规业务处理能力，极限测试下并发数为2万，测试7*24小时，观察极限处理能力。

1.3.4 测试环境梳理

根据测试场景以及梳理的被测系统、压力系统、压力机情况、给定的服务器数量，绘制测试环境搭建图谱即每个应用系统搭建数量、各节点所在机器，如下图梳理了整个系统部署的流程及每个应用、监控工具、测试工具应该部署的机器情况，让人一目了然。

1.3.5 测试数据梳理

这里的测试数据内容很广，可包括测试准备和测试执行阶段所需要的一切数据来源，如：测试脚本、测试参数化文件、测试账号、辅助性测试程序等，即让测试工作更加有条不紊的进行，而不是等到测试时才发现这个东西要去找，那个东西又没有弄得自己手忙脚乱，降低测试效率。比如，下面是一段造数据的存储过程脚本：

1.4 测试准备

1.4.1 代码管理

所有的产品代码应该统一管理起来，开发人员提交代码应与测试代码地址进行分离，做到高效管理代码，当开发人员提交代码到开发的代码库中，需要进行测试时，测试人员可去开发的代码中进行提取代码到测试基线库中，每提取一次就建立一个测试基线，直到此次版本测试合格，在把合格的测试基线提取到正式基线中用于版本发布，这样每个版本都有清晰的界限和记录，使得产品代码清晰一目了然，可以借助代码管理工具，如svn创建基线来帮助管理产品代码：

1.4.2 测试环境搭建

这个需要配合1.3测试计划的1.3.4测试环境梳理文档和部署文档来进行，根据事先规划好的服务器部署应用策略来搭建测试环境，能让你搭建思路更加清晰，以后维护环境也更加方便。

接触很多公司的测试关于环境这块的梳理工作，有的是有专门的服务器管理人员来管理这些环境，有的是由测试人员自己管理，但需要保证的是测试环境应当与开发环境分离开，让测试更加规范减少不必要的麻烦，遇到一些事情如：开发人员很懒，功能开发完成后让他在服务器上验证一下是不是对的，因为开发环境没人去管理部署上去弄得不好应用就报错无法进行调试，所以有的开发就会为方便起见把自己的验证测试直接弄到测试环境上进行，这样带来一个后果就是，你也来部署一个应用，他也来部署一个应用，久而久之测试环境就会特别乱，对测试人员梳理该环境增加不必要的负担，所以建议测试环境的账号应当只有dba或者测试人员自己知道，与开发环境进行分离。

1.4.3 测试数据脚本编写

功能性测试数据脚本一般为辅助性测试脚本，如：为了验证分页功能，写一个造数据的脚本让界面出现分页效果，帮助自己测试，减少手动一条一条增加数据的时间。

接口测试需要编写接口测试脚本，目前接口测试比较受欢迎的几款工具有：postman、loadrunner、jmeter、soupui、自定义框架，postman工具可以模拟发送http请求，用来做一些简单的接口验证测试比较方便，测试结果需要人眼去核查是否正确；loadrunner和jmeter工具更加智能化，接口测试支持断言/检查点设置，工具自己校验测试结果，支持参数化以及请求间参数关联，可以做一些复杂的场景流程测试；自定义框架可以结合项目适合进行扩展，比工具要灵活，但是需要测试人员有一定的代码基础才能开发出适合项目的接口自动化框架，如：unittest、testng技术等。

性能测试需要编写性能测试脚本，如loadrunner脚本、jmeter脚本等，脚本涉及参数化的地方也需提前构建好，如果系统并发登录需要大量的登录账户，则需要提前造好数据，可以让用户按规则进行，这样脚本中用户就可以用正则编写一定吻合的规则即可，省去大数据参数化的性能损耗。

测试工具层出不穷，在学习各种测试工具、测试技术的同时，不要忘记基本功，编程能力的提升才是重中之重。

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

测试用例的编写需要按照一定的思路进行，而不是想到哪写到哪，一般测试机制成熟的公司都会有公司自己自定义的测试用例模板，以及一整套的测试流程关注点，当然我们自己在测试生涯中也应当积累一套自己的测试框架，所有功能性的测试都可以依据框架的思路来进行，达到事半功倍的效果。

功能测试框架可以包括：界面友好性测试、功能测试、链接测试、容错测试、稳定性测试、常规性能测试、配置测试、算法测试等等。

1.5.1 界面友好性测试

1. 风格、样式、颜色是否协调

2. 界面布局是否整齐、协调（保证全部显示出来的，尽量不要使用滚动条

3. 界面操作、标题描述是否恰当（描述有歧义、注意是否有错别字）

4. 操作是否符合人们的常规习惯（有没有把相似的功能的控件放在一起，方便操作）

5. 提示界面是否符合规范（不应该显示英文的cancel、ok，应该显示中文的确定等）

6. 界面中各个控件是否对齐

7. 日期控件是否可编辑

8. 日期控件的长度是否合理，以修改时可以把时间全部显示出来为准

9. 查询结果列表列宽是否合理、标签描述是否合理

10. 查询结果列表太宽没有横向滚动提示

11. 对于信息比较长的文本，文本框有没有提供自动竖直滚动条

12. 数据录入控件是否方便

13. 有没有支持Tab键，键的顺序要有条理，不乱跳

14. 有没有提供相关的热键

15. 控件的提示语描述是否正确

16. 模块调用是否统一，相同的模块是否调用同一个界面

17. 用滚动条移动页面时，页面的控件是否显示正常

18. 日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX

19. 页面是否有多余按钮或标签

20. 窗口标题或图标是否与菜单栏的统一

21. 窗口的最大化、最小化是否能正确切换

22. 对于正常的功能，用户可以不必阅读用户手册就能使用

23. 执行风险操作时，有确认、删除等提示吗

24. 操作顺序是否合理

25. 正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。

26. 系统应该在用户执行错误的操作之前提出警告，提示信息.

27. 页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。

28. 合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。

29. 检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。

30. 背景灰度冻结

1.5.2 功能测试

1. 使用所有默认值进行测试

2. 根据所有产品文档、帮助文档中描述的内容要进行遍历测试

3. 输入判断

4. 所有界面出现是和否的逻辑，要测试

5. 异常处理

6. 敏感词

7. 根据需求文档的流程图遍历所有流程图路径

8. 根据程序内容，遍历if elif else switch的逻辑点要遍历

9. 界面各种控件测试

如对于输入框测试：

字符型输入框：

1. 字符型输入框：英文全角、英文半角、数字、空或者空格、特殊字符“~！@#￥%……&*？[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时，使用“粘贴、拷贝”功能尝试输入。

2. 长度检查：最小长度、最大长度、最小长度-1、最大长度+1、输入超工字符比如把整个文章拷贝过去。

3. 空格检查：输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格

4. 多行文本框输入：允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行，检查能否正确保存（若能，检查保存结果，若不能，查看是否有正常提示）、

5. 安全性检查：输入特殊字符串

（null,NULL, ,javascript,<script>,</script>,<title>,<html>,<td>）、输入脚本函数(<script>alert("abc")</script>)、doucment.write("abc")、<b>hello</b>）

数值型输入框：

1. 边界值：最大值、最小值、最大值+1、最小值-1

2. 位数：最小位数、最大位数、最小位数-1最大位数+1、输入超长值、输入整数

3.异常值、特殊字符：输入空白（NULL）、空格或"~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等可能导致系统错误的字符、禁止直接输入特殊字符时，尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能，通过剪贴板拷贝到输入框，分页符，分节符类似公式的上下标等、数值的特殊符号如∑，㏒，㏑，∏，+，-等、

输入负整数、负小数、分数、输入字母或汉字、小数（小数前0点舍去的情况，多个小数点的情况）、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制，8进制数值、货币型输入（允许小数点后面几位）、

4. 安全性检查：不能直接输入就copy

日期型输入框：

1. 合法性检查：(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入[30][31]、输入非闰年，月输入[2]，日期输入[28、29]、输入闰年，月输入[2]、日期输入[29、30]、月输入[0、1、12、13]

考虑开始日期与结束日历的比较，特别是在查询的时候.

2. 异常值、特殊字符：输入空白或NULL、输入~！@#￥%……&*（）{}[]等可能导致系统错误的字符

3. 安全性检查：不能直接输入，就copy，是否数据检验出错？

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

业务流程，一般会涉及到多个模块的数据，所以在对业务流程测试时，首先要保证单个模块功能的正确性，其次就要对各个模块间传递的数据进行测试，这往往是容易出现问题的地方，测试时一定要设计不同的数据进行测试。

如某一功能模块具有最基本的增删改查功能，则需要进行以下测试：

1. 单项功能测试（增加、修改、查询、删除）

2. 增加——>增加——>增加 （连续增加测试）

3. 增加——>删除

4. 增加——>删除——>增加 （新增加的内容与删除内容一致）

5. 增加——>修改——>删除

6. 修改——>修改——>修改 （连续修改测试）

7. 修改——>增加（新增加的内容与修改前内容一致）

8. 修改——>删除

9. 修改——>删除——>增加 （新增加的内容与删除内容一致）

10. 删除——>删除——>删除 （连续删除测试）

1.5.4 链接测试

主要是保证链接的可用性和正确性，它也是网站测试中比较重要的一个方面。

可以使用特定的工具如XENU来进行链接测试。

1.5.5 容错测试

1. 输入系统不允许的数据作为输入

2. 把某个相关模块或者子系统停掉，验证对当前系统的影响

3. 配置文件删除或者配置错误

4. 数据库注入错误数据

1.5.6 稳定性测试

1. 系统不间断运行（7*24），验证是否内存泄露、系统其他资源是否存在泄露

2. 如果很紧急上线，可以跑一晚上或者周末跑两天。

一般压力很大的情况下，数据库连接数问题、内存泄露问题会曝露的比较快但是死锁可能不能体现，所以要看系统重要性，如12306稳定性则最好7*24小时

1.5.7 常规性能测试

1. 连接速度测试

用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。

另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

2. 负载测试

负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？

3. 压力测试

负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

压力测试的区域包括表单、登陆和其他信息传输页面等。

1.5.8 易用性测试

1. 系统界面的控件是否可以通过tab键遍历，并且顺序合理

2. 主要功能的入口和操作是否易于理解

3. 界面是否布局合理，功能是否易于查找和使用

4. 操作步骤

5. 操作习惯

6. 有足够的提示信息，且信息文字描述准确

1.5.9 兼容性测试

兼容性测试不只是指界面在不同操作系统或浏览器下的兼容，有些功能方面的测试，也要考虑到兼容性，包括操作系统兼容和应用软件兼容，可能还包括硬件兼容。

比如涉及到ajax、jquery、javascript等技术的，都要考虑到不同浏览器下的兼容性问题。

除了上面所说的这些测试以外，还有算法测试、配置测试、安全性测试等等，在工作中不断总结和分析，形成自己的功能测试框架，当你把这份工作做起来以后，对于你自己对于测试团队而言都是一份很有价值的事情，你的测试思路也会变得更全面。

1.6 测试执行

1.6.1 接口自动化测试

搭建好的接口自动化流程，可以方便快速构建一次接口测试，这样能很快定位版本接口是不是基本没有问题，提高版本质量。

目前接口自动化测试在测试工具选取中也谈到了，主要有：jmeter、robotframework、自定义框架等，自动化测试的执行可以版本上线后手动触发执行，也可以用定时任务自动触发，或者用工具来进行自动化构建，不变的初衷是用程序或者工具来替代掉一部分的人力操作，让节省出来的人力更好的投入到测试当中。

如：一套自定义的测试框架，java+testng+maven+jenkins，版本测试时，Jenkins自动构建运行java+testng+maven框架脚本，去运行事先编写好的接口脚本，生成测试报告，对于测试接口异常的点进行邮件或者短信告警等，这样运维人员能在第一时间知道版本的质量，异常的接口是哪些，减少人工去一个一个核查接口正确性的时间消耗，有更快或更多的时间去处理异常和维护接口。而且一般项目对于接口的变动不会太大，不会全盘重构一般都是新增某些接口，或者修改一些接口，这样接口脚本只需跟着稍微调整即可，复用性很强，在很多项目上的实验都证明接口自动化测试带来的收益很大。

1.6.2 探索式测试

探索性测试强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，没有很多实际的测试方法、技术和工具，强调在碰到问题时及时改变测试策略。 探索性测试强调测试设计和测试执行同时性，完全抛开测试用例，使用定义的比较笼统的测试用例，则称之为探索式测试。

测试人员可以根据收集到的信息，天马行空，自由发挥；测试结果、测试实例和测试文档在测试执行时创建；探索式测试适用于“敏捷开发过程”。

在用传统的测试用例执行测试的同时，可以使用探索性测试来让测试用例更加的丰富和富有变化，提高测试代码的覆盖率，发现产品更多的问题。  

1.6.3 传统测试用例测试

传统用例的设计方式有：等价类划分法、边界值、正交实验、因果图、功能图、场景法、错误推测、随机测试、对象属性分析测试等方法，根据这些方法可以选取一种或者多种适合系统的设计方法来编写和设计我们的测试用例，让自己的测试有条理，尽可能多的覆盖测试点，提高产品的质量。

这里给出一个等价类划分法结合边界值方法的测试用例设计例子：

某报表处理系统要求用户输入处理报表的日期，日期限制在2001年1月至2008年12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。系统日期规定由年、月的6位数字字符组成，前四位代表年，后两位代表月：

分析输入条件有：200101到200812；6位；数字

等价类表：

测试用例：

那么根据这些测试用例我们就能很好的测试这个“用户输入处理报表的日期”的功能，其他的功能点类推，我们根据1.4中准备好的功能测试框架进行套用，每个模块都按预期设计的方案来进行测试，这样就能保证一些常规部分的功能点更多的被覆盖到。

1.6.4 Bug跟踪

测试人员在测试过程中对于遇到的bug需要进行记录和跟踪，不要觉得不严重的bug口头上说一声或者其他形式表达一下就可以不用记录了，因为bug的记录有利于产品领导了解产品的质量情况，有很多bug管理工具，如：readmine、禅道等，从测试用例到bug生成，指派给开发，返工次数，每次解决的理由到最后关闭即整个的bug生命周期都能做到很好的管控，帮助产品经理或项目经理进行下一步的产品优化、以及对产品质量做一个把控。

1.7 测试结果分析

1.7.1 结果收集

包括测试脚本测试结果，测试用例执行结果、服务器操作系统资源监控结果、数据库资源监控、web服务器监控、中间件服务器监控等结果的收集，如：功能测试测试用例数目，成功失败数，性能测试结果，各服务器资源监控结果，磁盘，io，内存消耗进程图等。

这些收集的结果能帮助测试、产品进行测试结果的分析，哪些问题放到下一个版本中进行解决也可以通过这个来进行规划。

1.7.2 结果分析

根据收集的测试结果，分析系统的稳定性，健壮性，功能测试可以通过结果分析得到版本的bug率，严重bug数、bug返工率等，对于系统后续优化有很大帮助；性能测试通过结果分析知道系统的性能指标，来判断本次系统迭代性能是否有提高，或者对于一个从无到有的系统来说，能预估系统在未来的某段时间能否承受住那么大的业务量。

1.7.3 测试分析报告

根据分析的结果，生成测试分析报告，给定系统的稳定性指标，让系统相关人员知道该版本的质量情况，提供项目上线的风险评估，如果技术可以，还可以提供针对项目问题的改进计划，帮助提高产品质量。如果系统的性能不达标还需考虑后续系统的调优工作，可以找项目相关负责人，dba等相关专家，一起来做性能调优工作，因为性能调优是一项复杂的工作，仅靠测试人员自己之力一般很难做好调优工作，所以可以借助集体的力量共同完成，调优工作完成后，还需回环在进行一次测试工作，验证调优的效果。

1.8 上线准备

1.8.1 版本发布

测试合格的代码可以进行版本发布工作，版本发布需要给出：发布包、发布文档、数据库脚本等材料，发布文档包括：用户手册、管理员手册、版本发布说明、对于首次发布还需提供产品发布说明、部署手册、测试分析报告等相关文档，这样每次的版本迭代都有相应的文档等材料一一对应，为项目更长远的发展打下基础。

1.8.2 数据准备

上线测试跟踪需要做好测试的准备工作，如线上数据准备，版本回退方案准备等，所有测试可能用到的脚本都应提前准备好，避免测试时手忙脚乱，影响效率。

1.9 上线测试跟踪

 

1.9.1 跟踪测试

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

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

1.10 Bug预防体系

1.10.1 web常见产品问题及预防

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

1F分辨率兼容性

• 产品的网页通常保证在1024*768的分辨率下显示正常，但是常常忽略800*600分辨率下的显示情况，还有其他特殊要求的分辨率
• 如果页面设计明确只考虑1024*768的需求，则只在1024*768下验证各个产品页面的显示正确无误

预防方法：

• 产品：需要明确产品需要兼容的常见屏幕分辨率
• 开发：网页页面的设计需要针对多种屏幕分辨率制定设计规范，并依据设计规范进行开发
• 测试：在不同分辨率下验证页面显示的兼容正确性

2F浏览器兼容性

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

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

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

预防方法：

• 产品：依据主流的浏览器市场占比，评估你需要兼容的浏览器
• 开发：针对需要兼容的浏览器类型和版本，指定浏览器兼容设计开发规（ CSS和Js 为主），并不断总结兼容性的经验教训
• 测试：在产品要求兼容的浏览器类型和版本下，进行兼容性测试

3FLink问题

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

所链接的页面是否存在

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

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

有死链

预防方法：

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

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

4F快捷键和焦点

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

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

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

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

预防方法：

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

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

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

5F前进、后退和刷新

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

预防方法：

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

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

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

6F页面/JS/程序提示语言

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

预防方法：

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

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

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

语言文字提示：

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

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

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

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

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

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

7F文字缩略和折行

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

预防方法：

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

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

8F图片的显示和链接

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

预防方法：

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

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

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

9F重复提交

用户提交数据页面，用户有可能连续多次点击提交按钮，造成数据的重复提交。

黑客或者不良用户通过抓包可以获取提交的url ，进行尝试重复提交。

预防方法：

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

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

10F输入判断问题

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

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

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

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

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

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

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

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

预防方法：

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

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

11F多个ie同时访问

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

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

预防方法：

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

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

 

12F安全考虑

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

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

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

预防方法：

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

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

13F直接URL链接检查

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

预防方法：

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

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

14F防止sql注入和跨站攻击

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

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

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

预防方法：

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

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

15F关于cookie

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

预防方法：

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

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

16F各种资源链接的释放

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

预防方法：

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

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

关于keepalive的设置：

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

17F系统上线的log配置

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

预防方法：

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

18F用户易用性

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

预防方法：

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

 测试：进行测试确认

19F文档

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

预防方法：

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

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

20F多表操作

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

预防方法：

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

测试：通过查询接口判断所有插入接口的数据库操作是否正确

等等，这些我们完全可以在不断测试过程中进行总结和积累，可以给开发进行培训，让他们了解这些常见的问题，在自测时注意这些问题，提高送测产品的质量。

1.10.2 app常见产品问题及预防

01  界面适配

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

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

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

预防方法：

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

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

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

02  系统适配

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

预防方法：

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

03  交互适配（1）

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

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

预防方法：

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

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

04  交互适配（2）

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

预防方法：

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

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

05  界面风格

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

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

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

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

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

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

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

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

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

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

06  性能优化(1)

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

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

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

预防方法： 

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

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

07  性能优化(2)

a：后台播放内存泄露；

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

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

预防方法： 

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

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

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

08  多服务、多进程

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

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

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

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

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

预防方法： 

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

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

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

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

09  外部调用

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.11 Bug管理规范

1.11.1 bug提交规范

Bug的报告要求描述内容清晰、简介、易懂，让用根据简要描述就可以大致了解问题所在：

缺陷ID	BUG的唯一标识，由BUG管理工具自动生成。
项目名称	每个要测试的软件项目都有唯一的名称。
问题类型（严重程度）	BUG所属的类型（即严重程度），包括致命问题、严重问题、一般  问题、优化建议等。缺陷标题简明的对BUG进行概要描述。
缺陷标题	简明的对BUG进行概要描述。
优先级	BUG解决的优先级。
所属模块	项目的各个组成模块。
测试版本	提交BUG时，一定要正确填写产生BUG的软件版本号。
分派人	BUG需要指派处理的人员，如果不清楚统一给项目负责人。
报告人	报告BUG的人员。
测试环境	可根据实际描述当前测试的软硬件环境，以作为参考。
详细描述	在详细描述中，可对BUG产生的前提条件、操作的步骤、实际结 果、预期结果等进行描述。
文字注释与附图	在提交BUG时，可上传必要的附图，便于确认错误的表现形式和 错误位置等。

在提交BUG时，提交人可根据提交BUG的紧急程度，选择对应的“优先级”，同时建议开发人员在处理BUG的时候能够根据优先级进行处理，优先级别较高的可以最先进行处理。

在BUG详细描述中，可在从BUG产生的前提条件、操作的步骤、实际结果、预期结果等方面进行描述：

1. 前提条件：有些BUG的产生是需要在一定条件下才会出现，例如浏览器、分辨率、Office版本等，所以就要求在描述时描述清楚前提条件；

2. BUG的操作步骤：详细的、有次序的、每一步的操作步骤，包括输入的数据，尽可能的重新操作的步骤；

3. 实际结果：指的我按照以上的操作步骤，最后得出的结果是什么， 例如我点击“增加”按钮后出现白页，这就是实际结果；

4. 预期结果：指的我按照以上的操作步骤，我想要得到的结果是什么，例如我点击“增加”按钮想要得到的预期结果是提示我“增加成功”提示；

5. 图文描述：在必要的情况下可上传截图并注释文字，这样更便于确认错误的表现形式和错误位置等。

一般情况下，开发人员在提交BUG时，“分派人”可指定对应的处理人员，如果无法确定“分派人”，可分派给项目的负责人，然后由项目负责人进行二次分派给对应的开发人员进行处理。在分派时可以添加一些对应的批注信息。

1.11.2 bug级别定义

具体的优先级别有以下几种

1  致命问题(一级bug)

致命问题：不能完全满足系统正常的功能操作要求，系统停止运行，系统的重要部件无法运行，系统崩溃或挂起等导致系统不能继续运行。

1. 常规操作下因程序问题导致系统崩溃，迫使整个系统无法使用（其中非程序问题有：系统配置、数据结构变动、session超时、网络中断、人为变更数据库中的数据、系统缺少相应文件或目录等）。

2. 常规操作下因程序问题导致程序重启、死机或非法退出。

3. 常规操作下系统出现死循环。

4. 数据丢失或异常。

5. 模块间数据传递及取值错误（如：输入A，预期结果应该是B，但实际结果不是B等）。

6. 流程输出错误（包括业务流程和事件流程。如：输入流程A，但实际流程处理中未能按A流程处理数据；点击某按钮，应跳转增加页面，结果跳转成修改页面等）。

7. 按照需求文档，功能未在程序中体现出来，即系统无此功能（据项目经理及相关负责人确认此功能必须具备的）；功能不符合用户需求，功能实现不正确（由项目经理及相关负责人确认此功能必须具备的）。

2  严重问题(二级bug)

 严重问题：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安装或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免（不能用其他操作修复问题）的主要问题，系统无法满足主要的业务要求，性能、功能或可用性严重降低。

1. 数据计算错误。

2. 因程序问题迫使正在操作的流程无法继续且无其他操作可以修复问题的（其中非程序问题有：系统配置、数据结构变动、Session超时、网络中断、人为变更数据库中的数据、系统缺少相应文件或目录等）。

3. 常规操作下功能异常，如：结果与实际查询条件不一致、页面按钮点击没反应等。

4. 功能项的某些项目（可为所有控件）使用无效（对系统非致命的）。

5. 因程序问题迫使正在操作的流程无法继续且有其他操作可以修复问题的（其中非程序问题有：系统配置、数据结构变动、Session超时、网络中断、人为变更数据库中的数据、系统缺少相应文件或目录等）。

6. 多余功能，且该功能影响了程序的正常使用（需项目经理及相关负责人确认），如客户名称录入项需要录入汉字和英文，但程序限制了只能输入汉字等。

7. 常规操作下，程序打印、导出的内容错误。

8. 在程序安装配置无误的情况下相关功能js报错，且该功能影响业务流的正常进行。

9. 在1024*768分辨率下，页面严重变形，使数据无法浏览。

10. 在Session超时，无友情页面提示

3  中级问题（三级bug）

系统可以满足业务要求，系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题，另外，还包括系统健壮性方面的测试。

1. 对于一些重要数据的操作、重要环节的变动且相关的操作和变动不可挽回时，系统应给出相应的操作确认提示，防止误操作，如数据删除、审批等。

2. 常规操作下页面跳转至错误友情提示页面，且操作其他模块，程序可正常运行（其中非程序问题有：系统配置、数据结构变动、Session超时、网络中断、人为变更数据库中的数据、系统缺少相应文件或目录）。

3. 功能实现不完整，如删除时没有考虑数据关联。

4. 因错误操作且因程序问题导致系统崩溃，迫使整个系统无法使用（其中非程序问题有：系统配置、数据结构变动、Session超时、网络中断、人为变更数据库中的数据、系统缺少相应文件或目录等）。

5. 数据添加、修改、查看界面中控件没有一一对应或对应控件长度、格式、验证性提示信息内容等不一致，但又不影响程序功能的进一步的操作（最终以需求规格说明书中内容规定为准）。

6. 响应时间较慢。（不可超过1分钟）

7. 功能性建议。

8. 操作界面错误（包括数据窗口内列名定义、含义是否一致）。

9. 简单的输入限制未放在前台进行控制。

10. 虽然正确性不受影响，但系统性能和响应时间受到影响。

11. 常规操作下，程序显示、打印、导出的内容格式错误，如页面变形、金额类数据未加货币符号等。

12. 在程序安装配置无误的情况下相关功能js报错，且该功能不影响业务流的正常进行。

13. 页面验证提示信息位置或内容错误，如空值验证对应位置或内容错误、提示对话框内容错误等（最终以需求规格说明书中内容规定为准）。

14. 在1024*768分辨率下，页面变形，但不影响数据的浏览。

15.  输入超长数据或特殊字符导致程序报黄页或跳转到友情提示页面等影响程序进一步的操作（需跳转友情页面）。

16. 在Session超时（需友情页面）、网络中断时，出现浏览器卡死、报黄页等异常情况，且没有对应的错误捕获机制并给出友情提示。

17.  滚动条无效，但不影响数据的显示与浏览。

18. 界面不规范，页面表现形式、样式与其他类似功能模块不一致，且差异明显的。

19. 必填项与非必填项应加以区别。

4  轻微问题

 轻微问题：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题。

1. 页面表现建议。

2. 功能操作建议。

3. 非程序代码导致黄页（如：手动删除、修改、增加数据库中的数据；缺少相应的系统配置；项目缺少目录或文件、因不明操作导致数据库中数据不符合正常逻辑关系）。

4. 辅助说明字体大小、颜色明显与页面整体表现形式不协调或者文字描述不清楚。

5. 长时间操作未给用户提示（不可超过1分钟），但程序一直在正常运行的，没有出现卡死等情况，如给出旋转的loading图标或程序后台操作进度条或显示进度百分比等。

6. 提示窗口文字未采用行业术语。

7. 可输入区域和只读区域没有明显的区分标志，如只读区域置灰显示等。

8. 键盘支持不好，如在可输入多行的字段中不支持回车换行，输入查询条件后不支持回车触发查询。

9. 界面不能及时刷新，如需要重新执行查询或加载页面等（最终以需求规格说明书中内容为准）。

 

以上就是产品的测试规范，囊括了从需求到测试计划、测试准备、测试执行、结果分析、上线准备、跟踪测试到项目总结的整个流程，规范了产品测试流程。