干货技术，第一时间送达！
大家好，我是林宗霖，是一位测试工程师，也是全栈测开训练营中的一名学员。学习完全栈测开训练营的课程，让自己更加意识到：基础不牢，地动山摇的道理。近两年，行业的很多小伙伴都热衷于自动化、测试开发等方面的技术，而忽略了测试基本功的修炼！
而即便你掌握了高超的技术，却忽略了测试本质，也很难让你掌握的技术去服务于业务，服务于质量。因此测试基本功对于测试人员的重要性不言而喻，所以在这里借花献佛，在老师（狂师）指导下，对全栈测开训练营中前面针对测试人员基础功修炼课程板块中的一部分内容做一个总结学习分享。
测试作为项目最后一个环节，新的测试技术、手段、理念不断出现，但是保证项目质量的目标没有变。而深入到项目中，了解项目代码、了解项目设计对于一个优秀测试人员是必须具备的技能。
下面分别从如下几个方面去介绍，测试人员，如何更为系统性的去深入了解一个项目。
大部分项目，从需求确定到最后上线的大概流程：
测试人员从需求评审阶段参与进来，在技术方案设计与评审时一定要参与，目的是要了解开发的设计实现思路，在过程中也可以找出思路的不足或漏洞。这阶段参与进去，能帮助测试人员更好地设计测试方案（注意点是不要被开发的设计思路主导，这样会影响用例设计的思路）
关注项目的架构设计，对测试人员有什么帮助？
1、能够提前进行测试工作，更早发现缺陷
这一点和上面建议在技术方案设计和评审时，测试人员也参与进去的目的类似。只不过在架构设计阶段，绝大部分测试人员是不具备“对架构设计评审发现问题”这一能力，但是参与进来了解，也可以逐步提升这方面的思维能力。
2、能够帮助测试人员更全面、更有针对性地进行测试
测试人员该如何了解一个项目的架构设计？
1. 从系统架构图入手
首先从系统架构图中，了解到有哪些服务，这些服务在每一层的分布情况；还有数据存储、缓存，不同层之间进行交互的协议。这样能帮助我们快速对项目架构有个大概的框架了解
2. 了解业务交互和数据流转
接着可以通过阅读流程图、泳道图、时序图等，来帮助我们了解服务之间的业务交互关系，业务数据之间的流转
ps. 团队中如果没有这些，甚至开发人员没时间写，那么测试人员可以通过询问开发来自己完成这些
图片来源百度
多业务架构图示例
从哪些方面去熟悉项目的数据库情况:
了解不同数据分别存储在哪些数据库中。因为一些数据量大的项目，往往会根据业务实际情况，来把不同类型的数据存储到不同的数据库中。比如说经常查询的，会存在es/redis/clickhouse等数据库；需要持久保留的数据，会存在mysql之类，等情况
了解不同服务的数据存在哪个库中，然后每个表都存哪些内容，以及其中字段的意思和关联（可以通过查询数据库设计文档来了解）
了解表之间的关联性，比如说外键
了解数据库设计时的一些测试点（数据库设计规则）
例如：
1. 大部分时候，哪些情况需要去关注接口文档
2. 在阅读接口文档时，需要注意以下几个方面（如果没有，则可以推动改进）
如果项目有多个服务，并且是进行分布式部署时，也需要了解这方面的情况。因为在进行性能测试在监控和排查问题时，需要知道这些情况
首先和开发请教了解下代码的结构，比如哪些包对应哪些服务的代码，哪些是业务逻辑实现代码，哪些是和数据库进行交互的，哪些是配置文件，哪些是接口定义文件等，这些有助于我们快速了解代码结构
大部分情况是没有足够的时间阅读所有的代码。那么我们可以选择增量代码进行Review。检查是否存在功能遗漏，逻辑错误，是否对原有的功能造成了影响之类
意思就是首先弄清楚本次迭代有哪些需求，熟悉了需求，编写了测试用例后，带着这些功能的实现是否存在问题的心理，去看开发代码。主要关注业务逻辑的实现以及接口参数定义的部分。不要关注配置以及其他和业务逻辑无关的地方，避免陷入到和业务逻辑实现无关的细节中。
在review完成后，需要对发现的问题进行整理归类。这样既可以在后面的测试过程中做为测试用例的补充，也可以形成自己的一套知识沉淀。在review完成后，可以尝试着去画出服务的流程图、项目架构图，可以帮助自己对项目理解更深入
1. 在review配置文件内容时，应该关注的点：
tomcat、redis、mq、mysql之类的配置，这些对环境、性能、任务调度等有关上面的这些注意事项，在实际工作中很少能一次性全部做得到的，这篇文章主要是希望能够起到个指导方向的作用，抛砖引玉，如果有写的不对的地方，或有不同的见解，欢迎指出来一起讨论。
如果你觉得文章还不错，帮忙 点赞、转发、关注、留言 ，因为这将是公号持续输出更多优质文章的最强动力！
联系客服
