测试人员为什么要深入到项目实现中去?

(“马蜂窝技术”公众号原创内容,ID: mfwtech)

一个项目从需求确定到最后上线,通常来说流程是这样的:

「测试」作为一个项目质量保证角色,在上面的整个流程中均有参与。而用例设计、项目测试环节更像测试的主场,PRD 的评审测试人员也会发表很多自己的观点,对项目的技术评审虽然测试人员也有参与,但也不如前两个环节的参与程度深。

其实,一个优秀的测试人员应该深入到项目的每一个环节中去发现问题,提出自己的观点,保证项目质量。那么要真正深入到项目实现中,测试应该怎么做呢?

一、Review 接口定义结构

接口定义文档在测试过程是测试人员接触比较多的设计文档,尤其是与最外层面向用户的接口设计相关的部分。在参加接口文档评审、编写接口用例这些场景下,测试人员都会仔细阅读接口设计文档。

通过接口文档,可以帮助测试人员清晰了解到前端与后断是怎么交互的,每个页面哪些操作与后端存在交互,不同的接口之间是否存在关联,清楚这些可以帮助测试人员在测试过程中对出现的问题进行精准判断,确定导致问题出现的范围。

在阅读接口文档可以关注以下几个方面:

  • 接口中定义字段是否考虑了扩展性;
  • 字段是否必须有明确的说明;如果是代码实现需要清晰定义 NotNull/NotBlank;
  • 字段含义是否存在歧义,字段的含义要有明确的解释;
  • 接口是否覆盖到了所有业务场景;
  • 返回值结构、内容是否正确;通常返回值都有固定格式规范,返回值结构要规范统一,并且接口请求失败有明确的失败原因;
  • 字段类型是否正确;
  • 入参风格统一;比如日期格式如果是 yyyy-mm-dd 格式,每个接口最好都统一。

除了上面提到这些,在接口文档还要关注数据库表结构,确保表结构能满足接口需求;接口返回数据量要控制在一个合理的范围,返回数据量太大会有传输压力从而产生性能问题;接口之间要注意低耦

二、关注架构设计方案

对于测试工程师来说学习项目架构或者说系统架构是一个不小挑战,因为基本上所有的架构知识、开发框架都是基于开发人员进行设计的,而这些内容对于开发人员也是一个不小的挑战。

那测试人员为什么还要去了解学习?有测试同行曾经开玩笑说「了解项目的架构设计是为了在开会的时候听懂开发在说什么」。虽然是一句玩笑话,但也说明测试人员需要了解这方面的内容重要性。了解项目的架构设计可以在以下几方帮助到测试人员:

1. 培养测试人员的架构思维

因为测试环节不应该仅仅发生在提测后,在前期项目设计阶段也同样需要进行测试,只有通过对业务代码、架构设计、用到的技术有了解,才能够在设计阶段发现缺陷。

2. 帮助测试更全面、更有针对性地进行

比如性能测试,如果不清楚整个系统的架构,没办法对压测结果进行分析,甚至设计的压测方案可能都是存在问题的。还有就是在压测时候尤其互联网的系统架构压测时经常需要「预热」,需要预热的原因我们清楚吗?因为服务端会对数据进行缓冲。

比如在项目架构迁移时如何做到不漏测,拿火车票电子票从 PHP 迁移到 Java 的乘车人模块为例,迁移前和迁移后访问乘车人模块流程如下图所示。

1)迁移前电子票和抢票访问乘车人模块方式:

2)迁移后如下(黄色部分是这次迁移改动部分)

从流程图中可以看出,乘车人模块是抢票和电子票两个业务的公共模块,而此次迁移只有电子票的 App 调用 Java 接口访问乘车人,其他还是调用旧接口,所以乘车人模块重构后要保证电子票和抢票的两个端(App 和小程序)不管从旧接口还是从新接口访问功能都正常,就要弄清楚电子票和抢票这个两个业务哪部分做了迁移,哪部分没有迁移,技术方案设计是怎么样的,这样才能保证不漏测。

那测试人员应该怎么了解一个项目的架构呢?测试人员学习架构或者说了解架构设计应该有测试的独特视角,通常能做到清楚基本原理、了解被测系统部署架构、用到了哪些技术,从测试的角度调用到哪些接口就够了,当然如果能学习的深入更好。

首先,不管是已经上线的项目还是在正在进行中的项目,都有系统架构图,先从系统架构图入手,了解服务都有哪些,这些服务分布在哪一层,比如有面向用户接入层,中间处理不同业务的业务层服务,还有从外部服务获取数据外部接入层服务,还有数据存储、缓冲,不同层之间进行交互的协议、中间件都可以从架构图中看到,能帮助我们快速的对整个项目建立一个框架。

其次,查看服务之间的业务交互关系,明确业务数据流转。通过阅读流程图、泳道图、时序图都能帮助测试人员理清楚各个微服务之间的交互关系。下图是根据我自己对马蜂窝大交通抢票业务的理解,梳理的业务架构图:

另外,清楚业务状态机也很重要。熟悉状态机能帮助测试人员更加清晰的理解业务,需求文档是对业务功能的概括,状态机是对业务功能不同情况的分解。

最后,了解一些架构设计知识,比如为什么要用消息队列,好处是什么,在项目中不断积累架构相关的知识,架构相关的知识不断的丰满在进行项目设计方案评审时就可从测试角度提出问题,发现问题,对项目质量起到帮助,因为越早发现问题,损失越小。

三、关注数据库设计

数据库的重要性不言而喻,任何一条业务线都离不开。数据库表设计是否合理、是否考虑了业务扩展、是否考虑了读写分离等,都是需要测试人员在参加数据库设计评审,甚至在数据库设计时考虑的。下面分享一些在 Review 数据库设计表时的参考检查项:

1)不同表,相同含义的字段命名是否统一;

2)字段类型是否符合要求,比如数据量大的字段类型设计成 int,应该用 bigint 更合理;

3)字段长度设计是否合理;举例,曾经测试过一个功能,每 10 分钟查询 Redis 中 key 的值存到 MySQL 中,统计值和查询 key 分两列存储,字段长度设计是 60,实际情况是 key 的长度远远大于 60,对 key 进行截断存储,导致查询不到不结果。

4)字段是否为空;接口设计字段可以空,但是表结构设计字段 NOT NULL,与接口数据结构设计不一致,提交的时候显然回报错;

5)是否存在冗余字段;当然有些情况为了效率会允许冗余字段的存在;

6)是否需要分库分表。

除了以上提到的点,在数据库设计方面需要 Review 的内容还有很多,比如是否需要考虑读写分离、表之间的关联是否合理等等。建议大家去了解一些与数据库设计规则相关的知识,来帮助我们在 Review 或者参与数据库设计时发现更多问题。

四、阅读开发的代码

说到 Code Review 大家并不陌生,上线前分支合并 Master 要进行 Code Review,开发人员相互交叉进行 Review,研发同学常会听到这样的对话「飞哥帮我 review 下代码」。

Code Review 对于开发人员是很重要的 Check 步骤,对于测试人员也是一样,一个发现缺陷、理解项目的重要手段。阅读代码可以从以下几个方面帮助到我们:

1. 检查测试用例的遗漏点

我们都知道测试做不到穷尽测试,不管是做单元测试还是功能用例都不容易做到全部覆盖,尤其是有多个条件的情况下越不容易做到,Code Review 可以帮助我们再次检查是否测试中遗漏功能点。

2. 帮助测试人员更加熟悉系统,深入理解业务

黑盒测试的被测对象是已经成型的系统,不能清楚看到业务功能是在系统架构哪部分上实现的。比如现在流行的微服务架构,一个业务功能可能是多个微服务相互协作完成,通过阅读代码,能够清晰的知道业务实现的入口在哪里,调用了哪些服务,一个业务场景从开始到结束经过哪些环节都可以清楚地看到。

3. 发现增量功能 Bug 和设计缺陷

业务线的功能是不断迭代的,因提升体验而进行的功能优化和增加新功能都在迭代的范围内。测试人员面对是整个业务线,每次的迭代需要准确判断本次迭代影响的范围来确定测试范围。通过业务代码清楚具体的实现细节、实现方式,在业务功能迭代时,测试人员能准确的判断出代码增量是哪部分,关联受影响的代码是哪部分,确定测试范围,做到精准的测试,在设计评审时反馈可会产生影响的功能给开发人员,与开发形成良好的互动。

说了阅读代码的好处,测试人员如何去 Review 开发人员代码?从哪几个方面入手?

1. 带着任务看代码

带着任务去看代码就是清楚本次迭代有哪些功能,最好在 Review 之前在熟悉一下测试用例,带着功能实现是否存在问题心态去看,关注业务逻辑实现、接口参数定义部分,一些配置的 config 实现可以不用关注,避免陷入到与功能无关的细节中。

2. 关注代码条件判断

实现业务逻辑各类条件的判断是必不可少的,也是容易出问题的地方,条件判断错误功能表现可能就是「失之毫厘,差之千里」。条件的判断需要结合业务实际情况,如:

(1)检查 if 语句中每个条件表达式是否正确。比如:变量取值 isNotBlank 和 isNotEmpty 就会导致不同结果,涉及与、或、非的表达式尤其要注意;

(2)检查条件表达式是否涵盖所有关联的变量。举个例子:一个订单状态流转和 a、b 两个变量的取值有关系,其中 b 变量在某些特情况下影响订单状态。如果在条件中只考虑对 a 的判断而忽略 b,就导致功能不完整。

在进行火车票的改签测试有这样一个 bug,同一个乘客成功购票后——>将票改签到其他日期——>再退票,然后这个乘客在买同样日期相同车次的票提示行程冲突,预期结果是:用户已经改签到其他日期并且退票,可以再次购买。下图是一个简化的流程图,判断是否行程冲突(黄色部分是导致bug的原因):

从流程图可以看出如果乘客有已出票的订单需要先判断是否出行或退票,如果否的话说明还是在出票状态,那需要继续判断是否进行了改签,如果已经改签允许用户继续创单,导致 Bug 的原因就是少判断了是否改签这个条件。

(3)检查对条件不同值给出的处理结果是否正确。举一个简单的例子:学生成绩不同区间对应 a、b、c 三个不同档有如下伪码:

If (s>=90):

Print「a」

Elseif (s>=80 && s<90):

Print「b」

Else:

Print「c」

上面的这段代码没有考虑s取异常值的情况,学生成绩取值是大于等于0的,还有就是成绩大于100时,在c档是否合理,也需要考虑实际需求。

3. 关注循环语句

所有的循环是否都有结束条件即所有的循环都能正常的结束;进入循环的入口条件是否正确即能进入到循环中;循环的条件是否存在越界的错误等。

4. 检查代码中接口定义与接口文档的定义是否一致

5. 针对增量代码进行 Review

通常由于时间有限,没有足够的时间阅读所有的代码,可以选择仅对对增量代码进行 Review,检查是否存在功能遗漏、改动代码对是否原有功能产生影响。

6. Review 后知识沉底

前面的几点都是再说如何去做,在阅读代码的过程中进行知识沉淀也很重要。在 Review 完成后,可以对发现的问题进行整理归类,在后面的测试过程中可以做为测试用例进行补充。Review 完成可以尝试画服务的流程图,项目架构图,帮助的自己对项目理解更深入。

7. 测试人员进行代码的反讲

阅读完代码后,测试人员反讲对代码的理解,可以邀请开发人员一起参加。

当然,我们在看到代码会碰到很多问题,可以向开发同学请教,了解代码结构,比如哪部分是业务实现代码,哪些是和数据库交互设计、哪些配置文件、哪些是接口定义文件,这些都可以帮助我们快速了解项目代码结构。

五、熟悉项目配置文件

为了灵活应对一些由于突发状况或频繁上线对业务带来的影响,在项目的实现过程中研发人员会把一些功能通过配置文件的方式去实现,比如流控配置、对不同业务场景的需求配置、为进行灰度测试的配置等,除此之外还有静态的环境配置。在配置文件内容的 Review 中应该关注的重点包括:

  • 不同环境的配置文件不同,以防止将测试环境的配置同步到生产环境产生损失
  • 功能配置开关,比如限流、降级服务开关、外部依赖如供应商的上下线
  • 业务参数配置,业务功能的一些参数需要随时灵活配置,比如一些活动规则、临时性的通知信息
  • 除了业务相关配置还有中间件的配置也需要关注,比如 tomcat、dubbo、mq 的参数设置很重要,对服务性能的影响非常明显。

测试人员深入到一个项目中,需要了解熟悉的远远不止我在上面提到这几个方面,还有很多,比如缓冲设计、缓冲失效时间设置,存储方式等,服务日志记录,随着对业务、系统架构的熟悉,这些都需要去了解,从而在测试中帮助到我们。

总结

上面是我对测试人员为什么要深入到一个项目实现中的,以及如何去深入的一些看法。测试作为项目最后一个环节,新的测试技术、手段、理念不断出现,但是保证项目质量的目标没有变。而深入到项目中,了解项目代码、了解项目设计对于一个优秀测试人员是必须具备的技能。当然,文中的内容也存在一些局限,欢迎其他测试小伙伴一起交流。

最后,马蜂窝大交通团队也在持续招聘中,测试、前端、Java 开发多个坑位,欢迎有意向的小伙伴来勾搭,简历请发送至邮箱:[email protected]

本文作者:董敏,大交通研发团队测试工程师。

原文地址:https://www.cnblogs.com/mfwtech/p/11411695.html

时间: 2024-10-29 05:00:32

测试人员为什么要深入到项目实现中去?的相关文章

测试人员遇到不断变化的项目需求该如何应对?

需求频繁变更这个产生的主要原因是: 1.前期需求调研工作没有做到位,在需求调研时没有真正深入了解用户需要什么东西?用户做这个东西的目的是什么?为什么要这么做? 2.项目经理对项目掌控力度够,在项目的需求一定情况下,没有采用集中变更或者分阶段变更: 3.客户在最开始时自己也没搞清楚要做出什么样子?随着系统的成型上线,提出一些新想法等导致需求变更. 4.客户就是上帝,所以有些变更是必须的. 测试人员如何面对变更? 1. 协调制定变更规范,比如说每次需求人员都会发出变更邮件,这样可以作为开发人员和测试

测试人员内功心法

转眼间2017已过了十天,中国传统的新年也马上来临.目前大家的状态应该是人在曹营心在汉,早想着回家过年的事情了吧?抢票,参加年会,中奖的高兴请客,没有中奖的替同事高兴,反正是不亦乐乎!由于最近一段时间比较忙,也没有写太多的东西出来分享给大家.不过在这新年即将到来之际,还是感觉应该写点儿东西的. 往期我分享的博文一般以技术偏多,要么就是一些儿个人心得,具有指导性的文章:不过这些都是比较具体的套路,就像武学上的刀法,剑法,棍法什么的,其实最重要的心法,我一直没有涉及过.原因是什么呢?中国人每个人都有

如何避免测试人员提交重复的Bug

我们在软件测试过程中,由于不同人员测试同一个项目,所以往往会出现Bug重复提交情况,导致对整个项目和人员产生影响: 浪费测试人员时间和精力,从而影响测试进度 浪费开发人员重复看Bug时间 若开发人员由Bug数量算绩效,会影响开发人员和测试人员之间的关系 导致整个测试工作不规范.不严谨 对于测试人员来说避免重复提Bug和提一个精确有效的Bug一样重要.为了避免重复Bug,先分析下导致Bug重复的可能情况: 不同测试人员重复测试相同的模块 不同测试人员重复测试相交的模块 总结了下解决上述情况的办法(

15问答为专业测试人员揭开“精准测试”的面纱

 15问答为专业测试人员揭开"精准测试"的面纱 什么是精准测试?软件测试是否必要达到精准?精准的同时是否提高了测试成本?精准测试对于普通测试工程师乃至测试行业会有怎样的影响?让我们带着这一系列的问题来关注精准测试的15个问答,揭开精准测试的面纱. 1.到底什么是精准测试?它和传统测试的区别和联系 相对于普通测试,精准测试是在传统测试过程中,通过技术手段对被测程序进行360度全景测试,将测试过程可视化.数字化.标准化,从而达到被测程序上线稳定.无风险.维护成本低等优势. 和传统测试比起来

测试人员在团队中的定位

前言 接触了许多非测试和新入行的测试从业者,听到最多的问题就是:“测试是否被需要?“ 团队职能介绍 <暗黑者1>中有句台词,“专案组有五个职能角色构成,侦探.网警.痕迹侦查专家.法医还有心理学专家”. 软件项目开发也是个分工明确的系统工程,不同的人员扮演了不同的角色,可以分为:项目.产品.开发.测试.美工等等. 项目经理负责分配资源,确定优先级,协调与客户和用户之间的交往. 产品经理负责市场调查并根据产品.市场及用户等的需求,确定产品功能的定义.规划和设计. 开发包括开发经理.前端开发.后端开

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来

测试人员眼中的app版本迭代过程中的问题

测试人员眼中的app版本迭代过程的问题     --记一次app新版本的开发测试过程 1. 前言 自从8月初入职当前的公司以来,在这一期的版本迭代过程中,第一次独立承担app部分的全部测试设计及需求跟踪,从头至尾跟踪了需求分析到开发测试上线的整体过程,和曾经做过的各种测试类型相比,它没有想象的那么好,也没有想象的那么坏.应了那句老话,梨子好不好吃,自己尝了才知道. 经历完整个迭代之后,感慨良多.在这里梳理整个过程,以测试的角度来分析整个迭代过程,作为以后工作的参考. 2. 简介 2.1 项目及公

你问我答,及测试人员方向发展

大家好,我是TT,互联网测试行业多年,没有牛逼的背景,也没有什么可炫耀的,唯独比他人更努力,在职场打拼.遇到过的坑,走过的弯路,愿意与大家分享,分享自己的经验,少走弯路.首发于个人公众号[测试架构师] 原文如下: 做开发好还是测试好?如果做测试怎么入门? 既然还有人问这样的问题,我想应该还有部分人可能会有这样的疑问,我并不觉得这问题问的多么可笑,可能对于刚进入职场之前的我们也会有这样的疑问.我个人觉得,首先,应该去了解开发和测试需要做的事情,使用到的技能,在问这些问题之前有没有去主动的了解和学习

【转】测试思考——测试人员需要具备哪些素质?

之前写的文章,今天分享出来 测试人员需要具备哪些素质? 测试人员需要具备哪些技能? 软件测试知识:测试计划.测试方案.编写用例.提交bug.跟踪bug,编写测试报告 测试工具的使用 操作系统 编写代码的能力 数据库知识 业务知识.网络知识. 除了这些必备的技能,我们还需要什么样的素质呢? 一.主动沟通    过去我是做传统ERP软件的测试,因为ERP软件已经很成熟,所以他的需求文档一般也都很完善,很细致,需求变更也不会太多.所以我们完全可以按照需求文档进行测试,与开发电话沟通就OK,只要我们bu