产品测试规范（三）

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

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

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章 产品测试规范

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