进入一个新项目，测试往往做这些-优快云博客

1.需求文档

1.1.寻找与这个系统相关的需求文档。心里大概做个分类。

全量的需求文档
历史需求文档
最新需求文档
有些需求文档没有写到一个文档里，需要收集零星的需求，汇总一起才是一个系统的所有需求。此时需要做一个收集和汇总。

1.2.阅读需求文档

不要求详细阅读，就搞懂简单的几点。

a.为什么做这个系统，解决什么问题。
b.哪些人用这个系统。
c.系统大概有哪几类大功能，自己心里有个大概分类。
d.用最简单的语言（一句话）描述以上问题。

1.3.了解需求文档的编写风格

详细还是大概？
以当前的编写风格，可能有哪些没说清楚的地方。

1.4.原型图

1.4.1.原型图网址，账号，密码。

1.4.2.大概看一眼原型，确保自己能找到全量原型。

1.4.3.了解原型图是否及时更新。

2.规格说明书

2.1.寻找与这个系统相关的规格说明书。心里大概做个分类。

全量的规格说明书。
历史的规格说明书。
最新的规格说明书。
有些规格说明书没有在一篇文档里，此时可以收集零星的规格说明书，整理一起，方便查询。

2.2.阅读规格说明书

不要求详细阅读，就搞清楚几个问题。

a.规格说明书如何编排的，遇到某个特定功能的问题能到规格说明书里找到对应内容。
b.了解规格说明书编写风格、格式。

3.功能分类

3.1.业务上的分类

a.业务流程类、报表类、定时任务类、角色权限相关、数据计算类

3.2.技术上的分类

a.同步请求、异步请求
b.消息队列、http请求

3.3.测试上的分类

a.同步请求、异步请求
b.消息队列、http请求

3.4.还有更多分类，按自己的工作目标和系统特点来。

4.系统组织架构

4.1.账号、角色、部门等。

a.了解系统有哪些角色
只了解主要角色，不用了解次要的角色。所谓主要角色就是对测试有影响的，角色对应功能和菜单有区别的。
b.了解角色如何创建、修改、删除、关联功能菜单。
c.了解账号
- 是否有系统预设账号。
- 是否所有账号都是手动新建的。
- 账号的新增、删除、修改。
- 账号密码设置、重置、初始密码。
- 账号是否需要UK登录。

4.2.整理自己的账号角色，尽量和同组其他测试做到分离。

好处：

和其他同事的测试数据分离。
可以在自己测试账号基础上再完善账号，方便自己测试。
便于自己统一管理。
便于对自己测试的功能所用到的账号的汇总。

5.自己负责的功能----分类（按业务类型分类、按技术实现分类、按测试策略分类）

分类可以见第3点。
分类的目的是为了安排测试工作。汇总同类功能的同类问题。对同类功能增加用例做深度测试。对同类功能做业务分析，对比差异点和相同点。设计同类用例深度覆盖，设计不同用例分别覆盖。便于深度挖掘业务内涵。

6.自己负责的功能—流程图

画流程图，便于自己理解业务。
为后续回忆功能提供参考。
为功能迭代修改提供参考。

7.自己负责的功能—数据库，增，删，改，查

7.1.了解所用数据库

a.很多系统不止用Oracle 、mysql数据库，可能用其他数据库，所以要提前了解，提前熟悉数据库的使用
b.了解是否单个数据库实例下有多个数据库Database，每个Database相互独立，下面又有各自的数据库表。
提前把数据库结构搞清楚，哪些业务数据在哪些库查询。此处并不是指在哪个表查询。
c.功能层面，了解每个功能全流程涉及到的数据库表，主要是insert操作的表，update操作的表，查询相关的表其次。
例如：新增一个订单功能，先获取新增订单日志后，就可以从日志里整理出insert的几个表（比如订单表、订单和XX关系表、用户操作日志表、订单日志表），就算新增订单只有一个接口，也会涉及到insert一个表后，再update这个表，此时我们只需要记录insert相关的表即可。
删除一个订单功能，先获取删除一个订单的日志，从日志里整理出select的表，只找主要的表（从新增订单的表我们就得知了订单主要的表），边缘的表不要（例如订单涉及到的要素，比如企业，部门信息相关的表就不要）。
用的什么数据库，如何查询和使用数据库。业务数据在单个库还是多个库。

8.自己负责的功能—后台逻辑梳理—逐行读代码

8.1.项目几个关键配置文件阅读

application.properties(有些使用的是 application.yml)、logback-spring.xml、pom.xml、README.md

logback-spring.xml https://blog.youkuaiyun.com/sfdssdf123/article/details/151579787?spm=1011.2124.3001.6209
application.yml https://blog.youkuaiyun.com/sfdssdf123/article/details/151582634?spm=1011.2124.3001.6209
pom.xml https://blog.youkuaiyun.com/sfdssdf123/article/details/151580121?spm=1011.2124.3001.6209
读以上文件可以了解项目架构、项目使用到的技术（框架、数据库等）、

8.2.功能代码阅读

如果是http接口，则通过接口url找到对应的controller，依次读controller、service、serviceimple
如果是消息队列，则直接根据报文名字找对应的报文处理程序。也可以咨询开发报文名字和对应处理程序的名字命名规则，再去找处理程序。

8.3.驱动包

数据库驱动一般也会放在项目里。
其他驱动也依次找一下。

8.4.账号密码

开发环境、测试环境、灰度环境的账号密码也可以通过8.1中的配置文件得到。

9.自己负责的功能–主流程日志阅读和记录

先执行一遍流程，再拷贝出日志，存放在本地，同步阅读代码时进行日志的逐行阅读。操作举例：比如一个订单程序，先是新建订单，再修改订单，接着付款，接着是退款，最后是审批通过退款完毕，订单关闭。此处选的流程是能涵盖大多数场景的流程。日志文件这样获得：

a.操作新建订单，不用太复杂，就选择最少的商品。 ----记录接口，找到后台日志，拷贝日志到本地文件，注明是新建订单。
b.用上一步的订单，进行修改操作，选择最简单的修改。----记录修改接口，找到后台日志，拷贝日志到本地文件，注明是修改订单。
c.用上一步的订单，点击付款。------记录付款接口，找到后台日志，拷贝日志到本地文件，注明是付款。
d.用上一步的订单，点击退款。------记录退款接口，找到后台日志，拷贝日志到本地文件，注明退款。
e.用上一步的订单，点击审批通过------记录审批接口，找到后台日志，拷贝日志到本地文件，注明审批。

把以上日志都合并到一个文件里，每个接口的日志都进行标注。对比着这块接口的代码进行阅读。通过如此操作可以得到以下好处：

a.以上操作没有覆盖所有分支，在同步阅读代码时，可以提醒到自己，此接口还有其他分支。例如审批时可以审批通过，拒绝，超时不审批自动审批通过等分支。
b.走一遍流程后，获得数据库表，阅读代码可以完善其他分支的数据库表。—解决了没有任何信息，也能了解这个功能涉及哪些表的问题。
c.测试完几轮，基本没有bug后，再留一遍最新的日志，方便未来有程序修改时，或者线上报bug时，可以不做手工操作，也能从日志中找到蛛丝马迹。
d.留作测试资产给后来加入的同事使用。

10.自己负责的功能—相关数据库设计梳理

10.1.第一种形式的梳理，按功能流程来，梳理成数据库设计文档。

类似步骤9中的整理，把一个功能全流程的数据库做一个梳理，主要通过一个两个关联字段，把select语句写出来。例如订单就可以通过订单编号把所有涉及到的库表串起来，有些可能还需要订单的uuid，所以不仅一个字段。
串起来的好处是测试这块功能的人可以一目了然了解这个功能流程涉及多少个表，每个表如何相互关联起来。方便在测试时信手拈来，提高测试效率。

10.2.第二种形式的梳理，梳理成数据库表结构。

这个本来是开发给的，但是一般大的项目，开发没有给到这么准确和具体。所以需要测试自己在测的过程中进行整理，整理的目的是为了自己测试使用，后续也可以作为测试资产。数据库表结构基本就涵盖库表的所有字段，字段含义、字段类型、长度、字段的枚举值、默认值。
数据库的字段中文名、字段类型、长度、字段枚举值、默认值都可以直接从数据库导出来，但是这些枚举值什么时候取则需要测试过程中总结出来，枚举值的中文含义需要从代码里获取（具体可以问开发如何从项目代码里找）。

11.自己负责的功能，每个业务词的含义

为什么要做这个？
我们总是说测试最重要是要了解业务，如何了解业务？看着产品经理，客户拿来的业务说明书、需求文档，各种业务文档，看得晕晕欲睡。最后看了半天得到的结论是，我大概懂了，但是又不是很懂。别人问起某个业务知识，自己貌似知道，但是也说不准确。那怎么办？以下给出简单粗暴的办法，让自己整理每个业务词汇，并注明词汇的含义，以词汇为维度去收集业务知识，以点带面去把业务串起来。避免拿到一篇业务文档，文章太庞大，信息也多而且全，其实啃不下来。所以我给的是笨办法，这个事情不需要一时间全部做完，而是陆续去做，测试中去做，遇到一个词汇收集一个词汇，整理一个词汇，测试过程中，不断去完善词汇的业务含义，使用场景，相近词汇做对比、甄别。
比如银行系统里经常用到的词汇，征收机关、会计账户、国库、核算主体。那么整理征收机关这个词汇的时候就可以问自己。