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

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

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 一、软件测试的目的1)软件测试是为了发现错误而执行程序的过程。2)测试是为了证明程序有错,而不是证明程序无错。(发现错误不是唯一目的)3)一个好的测试用例在于它发现至今未发现的错误。4)一个成功的测试是发现了至今未发现的错误的测试。注意:1、测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征。可以帮助项目管理者发现当前所采用的软件过程的缺陷,以便改进。同时,通过分析也能帮助我们设计出有针对性的检测方法,改善测试的有效性。2、没有发现错误的测试也是有价值的,完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如BevLittlewood发现一个经过测...
            0 0 3357
            分享
          •   这家公司是做证券项目的,约的9点钟,路程还是有点遥远,转了一趟公交两趟地铁,精力都花在了路上,感觉有点累,以下是今天得面试流程。  到公司前台给我了一张面试表,写完之后就是等待面试。一共面试了两轮,第一轮面试官是测试主管,第二轮测试经理(负责人)。  第一轮  自我介绍。  根据自己的情况扩展。  你是怎么理解软件测试的?  我觉得软件测试是很重要的岗位,如果一个系统开发完后不通过测试去产品质量把关,产品不能正常运行可能造成的后果,损失钱财、损失时间、损失客户等等,所以我个人觉得测试是不可缺少的一部分。  为什么转测试?  我觉得测试的发展空间很大, 而且薪资也比较可观,发展方向也会我想要...
            0 0 1150
            分享
          •   测试阶段  1、性能测试需求分析阶段  根据用户使用习惯和实际业务的性能需求,生成性能测试需求调查表  根据性能测试需求及系统重要业务调研,选取典型业务  了解业务模型及业务架构  2、性能测试设计阶段  编写性能测试用例  结合性能测试用例录制/修改/完善测试执行脚本  结合用户应用场景设计性能测试执行场景  3、性能测试执行阶段  利用LoadRunner性能测试工具中的Controller应用,按照并发用户数执行场景,并保存测试结果(Jmeter同理)  利用LoadRunner性能测试工具监控被测试环境下的服务器CPU,内存,磁盘等系统资源的使用情况  在需要的情况下利用第三方监控...
            0 0 856
            分享
          • 第4步:评估并选择最适合的测试工具工具选择可能非常棘手,因为市场上有数以千计的可用选项。许多团队仅根据其他人的成功来选择他们的工具。但是一种工具对其他人有效并不一定意味着它对您的团队也有效。考虑您团队的特定需求和资源。也就是说,这里有一些问题需要评估和选择最合适的解决方案:你想解决什么问题?确定您要应用自动化测试(Web、桌面或移动应用程序)的AUT以及您需要的功能(用于测试创建、执行、报告等)谁将使用该工具?如果他们是手动测试人员,那么低代码解决方案会更合适。它可以融入您团队现有的管道和工具链吗?寻找具有本机集成的自动化工具,以减少解决方法的时间。它是面向未来的吗?为避免从一种工具转移到另一...
            0 0 1971
            分享
          • 读者提问:什么是敏捷测试?阿常回答:这个问题我从三方面回答:1、什么是敏捷测试;2、几种应用形式;3、敏捷测试的核心。一、什么是敏捷测试敏捷测试又被称为 “ 小步快跑 ”、“ 快速迭代 ”。敏捷测试就是持续地对软件质量问题进行及时地反馈。敏捷测试与传统测试的区别:传统测试交付的是一整个庞大的需求,敏捷测试交付的则是这个庞大需求的 1/N :如果把测试活动比作吃蛋糕,传统测试一次要吃整个 16寸的大蛋糕,而敏捷测试则把这块大蛋糕切成 64份,每次迭代只吃 1/64。二、几种应用形式一)每日站会每日站会,就是每天早晨 10~30 分钟的会议时间,项目组成员(包括产品、设计、研发、测试)依...
            0 0 1676
            分享
      • 51testing软件测试圈微信