• 0
  • 0
分享
  • 【软件测试】如何梳理你测试的业务
  • 曼倩诙谐 2023-02-27 10:28:56 字数 1764 阅读 1093 收藏 0

  在日常的测试工作中,不知道大家是否会有梳理自己测试业务的习惯。我个人觉得这个事情是值得做的,最好还可以培养成一个习惯。

  一、为什么要梳理业务?

  因为在业务测试中,作为测试人员,熟悉负责的业务是非常重要的,而通过阶段性的梳理总结,可以让你的业务知识系统化的沉淀下来。

  当被问起这个业务系统的测试重点在哪里?难点如何克服?为什么要这样设计等等问题,可以有条不紊的进行输出。

  又或者,当你任务需要交接,或者需要别人支援你的业务,你可以自信的把文档丢过去,拍拍胸脯说:看一遍你就知道了。

  同样大家平时都在做业务,同样并没有多少别的技术层的产出,这也是为什么有人能拿A,有人却只能拿C的原因之一。

  另外,当你有了多种业务的沉淀之后,你甚至可以提炼出很多通用性的东西,姑且称为“方法论”吧。

  二、梳理框架

  优点这么多,如何进行梳理呢?这里我参照常规的服务系统,写一些思路(框架),仅供参考。

  1. 测试场景

  这部分可以整理出业务系统的测试场景。

  可以重点贴出核心的测试场景,附带上全量的测试用例。如果用例有后续迭代,也可以根据时间和内容进行分分类,放在这里。

  2. 业务

  这里就可以整理有关业务的更多细分领域。比如:

  1)各种配置

  业务涉及到的各种后台配置、后台地址、配置影响范围、必须非必须配置、配置顺序、特殊注意项等等。

  2)前端

  涉及到的产品前端功能是哪些、重要链接、主要的前端交互等等。

  3)核心流程

  梳理业务的核心流程,可以包含对用户的操作流程,以及对应交互的接口。

  另外,可以自己手动画一画核心业务流程图,一般产品会给出,但是有时间自己画一画,脑海里再过一过更加深刻,说不定还有意外发现来补充测试设计。

  还有一个重点就是业务数据的处理过程,如果涉及到其他像kafka、es、缓存等中间件,数据处理的细节也可以整理出来。

  4)问题排查

  在测试工作中一定会遇到杂七杂八的问题,抽出一些典型问题,记录下排查手段以及可能因素,方便自己以及其他人查看。

  3. 系统

  业务层梳理完,就应该关注应用服务层的了。

  1)应用站点

  可以从入口往下,整理出业务系统下各个站点,服务名称、作用等信息。

  2)接口与日志

  这里可以汇总下接口文档,根据不同情况进行分类,反正目的就是为了高效查看对应文档。

  在测试过程中如何查看关键性的日志也很重要,对理解接口交互,排查问题都很有帮助。这里可以记录不同流程,涉及到的站点,如果过滤日志等信息。

  3)MQ消息

  记录交互的 MQ 有哪些,topic、不同tag的作用是什么、消息体等等。

  4)异常机制

  记录下系统都有哪些异常的处理机制,常见的比如超时、重试、补偿、兜底等等。

  4. 数据

  到了数据层了,自是来不开 mysql 、缓存、mongoDB等等。

  梳理好各数据库名,用来处理什么,核心的表以及关键的字段,比如一些订单类型、状态等等。

  redis这些nosql数据库,梳理重要的 key、field、value等等。

  5. 安全

  比如接口的鉴权机制,一些涉及到更复杂加密处理的接口的细节。

  还有一些并发操作类的控制也可以整理出来。

  6. 性能

  通常是单接口和链路场景的性能。

  1)接口性能

  比如:前端用户体验最直观的接口、创单接口、详情接口、预处理接口等等。

  2)链路性能

  最核心的链路场景,串起来进行压测。

  3)限流

  如果涉及到限流的场景,可以进一步整理出考虑限流的因素,触发的机制,处理的手段等。

  7. 数据分析

  数据是多样的,比如日志数据、埋点数据、或者后台看板大屏的数据,列出需要关心的点,以及数据的正常趋势、不正常的趋势。

  8. 监控报警

  通常就是测试右移后关注的点,可以监控线上运行的服务,对核心业务接口的一些常规指标进行监控。另外对日志系统不同类型的日志数量监控也有必要。

  如果运维配套系统比较完备的话,我们测试自己就可以进行配置了,如果没有的话,积极的参与其中吧。

  9. 应急预案

  一些核心业务系统,可能还会针对极端情况有应急预案。比如机房切换、灾备预案等。


作者:佚名    

来源:http://www.51testing.com/html/28/n-7793428.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   对于没有代码功底的测试人员来说,Postman和Jmeter以及RobotFramework算是“半”自动化测试工具。所谓的半就是介于功能测试和测试开发中间的阶段。  作为一个经验较为丰富的功能测试来说,想努力发展技术,选择一个合适自己的工具是成功的开始。  本文通过“请求新闻资讯”案例示范常见的两种接口工具实现接口自动化测试。让大家一目了然的对接口测试工具以及基础自动化测试有个基础的了解。  项目:请求新闻资讯  工具:Jmeter、Postman  一个完整的基本接口自动化测试,需要包含三个部分:  1.发起请求  2.验证结果(断言)  3.测试报告  Jmeter实现接口请求+JS...
            3 4 2254
            分享
          • 目前用于兼容性测试的云测平台如雨后春笋般涌现。他们一般主打各种机型的兼容性测试,附加提供指定机型的真机测试,除了现在市场上的主流ios,android系统,现在甚至还出现了各种Harmony系统,以及各种不同的分辨率等,可以说给我们测试人员提供了很大便捷,再也不用为了申请什么测试机或者复现问题头疼了。当前常见的云测平台有:AWS Device Farm平台,Android机型只支持国外的机型,没有华为小米vivo等国产机(有点可惜),覆盖率低,费用为免费。阿里云MQC平台,Android机型比较丰富新颖,可以检测出app的崩溃、内存泄漏、异常等问题,日志log比较详细,可以帮助研发人员排查问题...
            1 0 4499
            分享
          •   单元测试是一个伟大的发明,同时也是一个操蛋的发明。只要团队碰它,几乎很难全身而退。  如果是我们自己写的代码,那么,写写单元测试也无伤大雅。但我们绝大多数人,都是跟在别人后面打扫狗屎,或者是留给别人一堆狗屎。这时候,单元测试写起来,就有一种不情不愿的味道。  没错,就是不想写!  为了应付所谓的指标,我们要给那些遗留代码,将要发臭的代码上一剂良药:那就是自动化。假如这些糟心的代码,大部分交给机器去写,我想很多人是非常乐意的。  squaretest  有很多这样的工具,比如IDEA自带的。但是它只能生成一些表面功夫的东西,也就是生成一个骨架而已。  说实话,并没有什么鸟用。根本就没减少我多...
            0 0 1010
            分享
          • 在我们测试接口提供的数据,支持的业务功能之前,我们非常有必要再提一下接口本身的规则,即便我们在前面的章节已经隐隐约约的提到过。1. 接口文档如果让我给接口文档下个定义,文档是使用接口的人对于接口的约束口头协定(对,你没看错,这是我最经常见的)word/Excel/txt 文件api管理平台(rap2/yapi等等)文档应该出现且不限于以下几点内容:接口访问的地址接口参数必须传的参数非必须传的参数指定数据类型参数请求方式GET请求POST请求返回字段的含义至于为什么是上面几条,不赘述,大家可以想一哈2. 遵循接口文档对于测试人员来讲,遵循接口文档,就是按照文档进行测试。测试也可以分为两种风格:懒...
            0 0 1363
            分享
          • 数据分析是从数据中提取有价值信息的过程,过程中需要对数据进行各种处理和归类,只有掌握了正确的数据分类方法和数据处理模式,才能起到事半功倍的效果,以下是数据分析员必备的9种数据分析思维模式:1. 分类分类是一种基本的数据分析方式,数据根据其特点,可将数据对象划分为不同的部分和类型,再进一步分析,能够进一步挖掘事物的本质。2. 回归回归是一种运用广泛的统计分析方法,可以通过规定因变量和自变量来确定变量之间的因果关系,建立回归模型,并根据实测数据来求解模型的各参数,然后评价回归模型是否能够很好的拟合实测数据,如果能够很好的拟合,则可以根据自变量作进一步预测。3. 聚类聚类是根据数据的内在性质将数据分...
            12 12 1223
            分享
      • 51testing软件测试圈微信