一、即便是测试，也要当优秀的那位

　　测试作为项目最后一个环节，新的测试技术、手段、理念不断出现，但是保证项目质量的目标没有变。而深入到项目中，了解项目代码、了解项目设计对于一个优秀测试人员是必须具备的技能。

　　下面分别从如下几个方面去介绍，测试人员，如何更为系统性的去深入了解一个项目。

　　二、了解项目流程

　　大部分项目，从需求确定到最后上线的大概流程：

　　测试人员从需求评审阶段参与进来，在技术方案设计与评审时一定要参与，目的是要了解开发的设计实现思路，在过程中也可以找出思路的不足或漏洞。这阶段参与进去，能帮助测试人员更好地设计测试方案。（注意点是不要被开发的设计思路主导，这样会影响用例设计的思路）

　　三、关注架构设计方案

　　关注项目的架构设计，对测试人员有什么帮助？

　　1、能够提前进行测试工作，更早发现缺陷

　　这一点和上面建议在技术方案设计和评审时，测试人员也参与进去的目的类似。只不过在架构设计阶段，绝大部分测试人员是不具备“对架构设计评审发现问题”这一能力，但是参与进来了解，也可以逐步提升这方面的思维能力。

　　2、能够帮助测试人员更全面、更有针对性地进行测试

　　了解架构设计，能够让测试人员了解到项目各个服务之间的关系，业务交互，数据存储，数据流动等情况，从而能够让测试人员更有针对性地进行测试用例的设计。

　　如果需要进行性能测试，甚至全链路压测，更需要对架构非常熟悉以及开发框架的熟悉。否则如果不清楚整个系统的架构设计，可能设计出的压测方案都有问题，更没办法对压测结果进行分析和问题定位。

　　测试人员该如何了解一个项目的架构设计？

　　1. 从系统架构图入手

　　首先从系统架构图中，了解到有哪些服务，这些服务在每一层的分布情况；还有数据存储、缓存，不同层之间进行交互的协议。这样能帮助我们快速对项目架构有个大概的框架了解。

　　2. 了解业务交互和数据流转

　　接着可以通过阅读流程图、泳道图、时序图等，来帮助我们了解服务之间的业务交互关系，业务数据之间的流转。

　　ps. 团队中如果没有这些，甚至开发人员没时间写，那么测试人员可以通过询问开发来自己完成这些。

　　技术架构图示例：

图片来源百度

　　多业务架构图示例：

　　四、关注数据库设计

　　从哪些方面去熟悉项目的数据库情况:

　　了解不同数据分别存储在哪些数据库中。因为一些数据量大的项目，往往会根据业务实际情况，来把不同类型的数据存储到不同的数据库中。比如说经常查询的，会存在es/redis/clickhouse等数据库；需要持久保留的数据，会存在mysql之类，等情况。

　　了解不同服务的数据存在哪个库中，然后每个表都存哪些内容，以及其中字段的意思和关联。（可以通过查询数据库设计文档来了解）

　　了解表之间的关联性，比如说外键。

　　了解数据库设计时的一些测试点。（数据库设计规则）

　　例如：

　　字段类型是否符合实际情况。比如说一些数据量大的整数类型设置成了int，其实使用bigint更加合理。

　　字段长度设置是否合理。比如说一些字段在需求设计、前端、接口都进行了50长度限制，但是在数据库中却设计了1000的长度，明显不合理。

　　字段是否为空的设置是否和实际情况相符。比如说需求和接口设计中，字段A可以为空，但是表设计中却设置了NOT NULL，这样接口传递空数据到数据库时，会报错。

　　是否需要进行分库分表。在数据量激增时，是否需要进行分库分表修改。

　　是否存在冗余字段。一些用不上的字段是否需要进行删除。

　　表之间的关联是否合理。

　　读写分离设计是否合理。

　　...

　　五、关注接口文档

　　1. 大部分时候，哪些情况需要去关注接口文档

　　了解项目具体实现时：

　　· 接口测试

　　· 性能测试

　　2. 在阅读接口文档时，需要注意以下几个方面（如果没有，则可以推动改进）

　　字段定义：字段类型、长度、是否是必填字段等字段属性的定义。

　　字段说明：每个字段是否都有字段的作用说明解释，并且无歧义。

　　请求示例：是否有正确和异常的请求内容例子。

　　请求规范：入参风格要统一，比如说日期格式如果是yyyy-mm-dd，那么所有接口都要这样。

　　响应示例：是否有正确和异常的响应示例。

　　响应规范：响应内容是否正确；响应值是否有固定的格式规范，通常响应结构要规范统一，并且失败情况要有字段说明失败原因，以及统一的一套自定义状态码来对应成功或各种失败情况。

　　六、关注服务的部署情况

　　如果项目有多个服务，并且是进行分布式部署时，也需要了解这方面的情况。因为在进行性能测试在监控和排查问题时，需要知道这些情况。

　　七、阅读开发代码

　　1.阅读代码对测试人员的好处

　　· 结合代码和需求，可以更加熟悉系统和业务

　　· 可以发现测试用例的遗漏点

　　· 结合代码和需求，可以发现一些增量的bug（意思是本次的迭代会影响到哪些其它的功能模块）

　　2.如何review开发代码？

　　· 和开发了解基本信息

　　首先和开发请教了解下代码的结构，比如哪些包对应哪些服务的代码，哪些是业务逻辑实现代码，哪些是和数据库进行交互的，哪些是配置文件，哪些是接口定义文件等，这些有助于我们快速了解代码结构。

　　· 针对增量代码进行review

　　大部分情况是没有足够的时间阅读所有的代码。那么我们可以选择增量代码进行Review。检查是否存在功能遗漏，逻辑错误，是否对原有的功能造成了影响之类。

　　· 带着需求任务去看代码

　　意思就是首先弄清楚本次迭代有哪些需求，熟悉了需求，编写了测试用例后，带着这些功能的实现是否存在问题的心理，去看开发代码。主要关注业务逻辑的实现以及接口参数定义的部分。不要关注配置以及其他和业务逻辑无关的地方，避免陷入到和业务逻辑实现无关的细节中。

　　· review知识沉淀

　　在review完成后，需要对发现的问题进行整理归类。这样既可以在后面的测试过程中做为测试用例的补充，也可以形成自己的一套知识沉淀。在review完成后，可以尝试着去画出服务的流程图、项目架构图，可以帮助自己对项目理解更深入。

　　八、熟悉项目配置文件

　　在review配置文件内容时，应该关注的点：

　　不同环境的配置文件需要区分开，以防止将测试环境的配置同步到生产环境上；

　　一些功能可以进行配置话，比如说灰度测试的流量限流，降级服务的开关，外部依赖的开关（比如说供应商的上下线）；

　　业务参数的配置，一些业务参数可能需要灵活配置，比如说活动的规则、抽奖的概率、临时的消息通知等；

　　中间件的配置，比如说tomcat、redis、mq、mysql之类的配置，这些对环境、性能、任务调度等有关；

　　数据库需要注意时区的问题，如果es需注意时间字段存储的值类型和查询语句对应的时间字段值的类型需一致。

　　九、总结

　　上面的这些注意事项，在实际工作中很少能一次性全部做得到的，这篇文章主要是希望能够起到个指导方向的作用，抛砖引玉，如果有写的不对的地方，或有不同的见解，欢迎指出来一起讨论。

作者：狂师   

来源：http://www.51testing.com/html/22/n-4477922.html