作为一个测试如何快速熟悉新项目

作为一个测试如何快速熟悉新项目
(what)对于测试来说,从产品的角度去思考熟悉产品对于快速熟悉测试系统的业务流程是很有必要的。
why)在如今敏捷开发及迭代快速开发模式下。对测试的效率有着越来越高的要求,因此可以做以下操作:

  1. 工作第一天,一定要抽出一点时间,把自己当成感受公司的产品,这样可以快速了解产品的核心功能点。

  2. 了解公司的产品研发管理流程,产品测试的流程

  3. 如果有交接工作的测试同行,要全之前所有的功能需求文档、效果图、测试用例,测试报告、测试计划等,了解产品的历史版本,以及从测试用例的编写情况。这些文档如果在工作中,用到一个,要一个是非常不方便的。

  4. 测试工作中,可以写一份测试产品的业务流程图,思维导图,找产品经理看一下思路是否正确,哪些细节需要注意一下,这可以帮你迅速理清思路,投入到工作中。

  5. 了解公司的产品的实际应用场景,产品的面向群体,是普通人群使用还是专业人员进行操作,产品是处于功能实现阶段还是优化阶段,这样区分测试的重点,有利于开展工作及沟通。

  6. 了解测试工具和技术,了解公司当前使用的测试管理软件测试工具

新人入职一般会面临新项目的焦虑,
一般导师会扔过来一大堆资料,然后给几天时间,就自己上手,那该如何快速上手测试呢?

说到底是三个问题

  • 我负责的项目是什么
  • 我该如何去测试
  • 项目的流程

我负责的项目是什么?
导师会发一些资料去看,如果是拿到什么看什么,效率会很低。原因是资料一般是长期收集的,杂乱导致刚接触很容易看晕。
解决方法:
追溯产品的最初形态,思考为什么有这个项目,立项之初是什么,可以直接从官网入手,看产品的业务介绍,**重点关注是什么,为了解决什么样的痛点才立项的,优点是什么?**然后去公司的内部交流平台查看分享的技术文档,从内部逻辑入手,对整体和内部有一个特性认知,最后才看导师提供的资料。

我该如何去测试这个项目
入职前几天会开通权限,测试用例,Bug单,测试报告,看这些没必要,在理解别人思路之前,先要有自己的思路。在测试策略的制定上,先有自己的测试策略指定,大体上我该怎么去测试对应的项目,然后才去和已有的积累的用例做对比,这样效果更改。

项目的(测试)流程
项目迭代的周期不同,理解目前的流程,对以后工作提供的时间的规划,可以很好的规划未来的测试工作。

总结
是什么?即为什么有这个需求,解决的痛点是什么?
做什么,回到指定测试策略,怎么编写测试用例?
在后面的工作目标也规划出炉,

  • 理解业务,改进测试策略,执行效率优化(用例精简和用例自动化)
  • 学习一些测试评测的方法和思路
  • 完成对编程语言的基础学习(根据项目使用的语言),可以进行更好的测试demo,提高覆盖率,也是执行自动化的基础
  • 工具的使用总结,重点是对网络的测试方面

沟通
入职第一天,应该做什么-(找领导沟通)
沟通目标:
了解对自己短期,中期,长期的规划,期望
)当前团队的现状、需要解决的问题等
团队各个人员的职责、分工
4)产品负责产品规划和设计

入职第一天沟通二-找直属领导沟通
ps:直属领导是最开始发起招人的,最为清楚需要你来解决的问题
沟通目标:

  1. 现在在做什么事情,遇到了什么问题;
  2. 当前人员配备情况,各自负责什么
  3. 对于你短期、中期、长期的期望与安排
    入职第一天,沟通三-技术团队沟通
    沟通目标:
    技术体系的架构,整个技术研发的流程
    代码、接口、流程规范
    每个模块的负责人(有问题/出了事找谁,减少后续沟通成本)

入职第一天沟通4-找产品团队沟通

沟通目标:

  1. 产品当前使用情况。例如:多少人在用,用户的习惯,目标人群特征。
  2. 未来一段时间内产品发展规划

入职第一天,应该做什么-五整体清单
适用于一二线互联网公司

** 1测试相关工具**

  • 泳道环境。
  • 消息服务。
  • 数据同步工具
  • 埋点/打点测试工具
  • app mock平台
  • 兼容性测试平台(跑机型)
  • 压测平台
  • 云服务(个人机器申请)
  • 静态分析工具,如sonar接入
  • 覆盖率接入
  • Jenkins接入

2项目相关

  • 测试用例/bug管理
  • 需求管理
  • 团队现有流程/规范
  • 环境的使用
  • 本部门/业务线专用的平台、工具

3项目开发

  • 线下/线上数据库:权限申请、使用
  • 缓存:权限申请、使用
  • 后台服务治理平台:权限申请、使用
  • 发布平台:权限申请、使用
  • 代码仓库:权限申请、使用
  • 接口文档:接口范围,规范等
  • 技术评审:进行时间、规范等
  • 公司级别技术:搜索ESSerach、前端框架、后端服务等。

4监控相关

  • 服务监控
  • 机器性能监控
  • 业务方面核心监控

5公司级别工具/效率组

  • 针对研发过程及质量的一站式数据分析平台
  • 抓包平台
  • 研发写作平台

6、学习成长

  • 图书馆
  • 分享平台

总结
了解以上后,除了业务本身的各种事项需要时间慢慢熟悉和上手外,可以从零更快从一枚新人成长为团队中业务,技术各方面都非常精通的老鸟。

其他
如何问问题:
嗨!前辈,你这个程序和预期结果不一致,你过来帮我看看是不是我使用的方法有问题,还是数据搞错了。

需求沟通问题:

  • 把你的问题记下来,
  • 平常时间多问,再思考
  • 沟通的时候,提出重点,如不懂的需求点是什么
  • 格式
  • 如说这个要写数据到 A 系统,这个写的点怎么写的,我不清楚,老司机,来带我飞一下(幽默点)

仔细看文档

  • 一个一个字去看,第一遍不行,第二遍,第三遍不行,把还看不懂得地方记录下来,思考下,找合适的时间点去找老司机,记下来,集中一个点去问,切记不要每次遇到问题一个一个问
  • 提出测试点,重点,用例
  • 切记勿浪费时间,按照需求分析规定的时间,及时熟悉完需求做别的工作,前提是先熟悉业务流程

遇到问题咨询格式:

拿到需求先自己操作一遍,执行到哪一步卡住了,再去沟通。
我的电脑都都xxxx,而且xxx也配置了了,我检查了一遍,ip 配置对的,就是x’x’x,这个时候别就给你分析x’x’x’x’x,那么应该是 x’xx’x’x’x’x’x’x问题,他会告诉你问题出在哪一块

测试快速熟悉业务的方法:
常规方法:
1、熟悉系统架构图、自己整理系统功能模块图
2、整理测大纲,提取需求功能点。
3、看需求文档、产品说明书
4、参加各种会议:需求评审、设计评审、测试用例评审
5、看设计类文档:系统设计、概要设计、详细设计,数据库数据
6、学习同行业软件
沟通:找需求、开发沟通

  • 非常规方法:不懂就问:无论需求还是开发,把对方问晕
  • 协助需求、开发人员整理文档