【测试面试必问题】测试工作流程

引言:你的流程是啥样的?阿里的流程是啥样?

 

以下是绝大多数公司的流程或者是面试的答案,不会有很大区别:

一般工作流程如下:

1.参与prd设计评审

2.确定业务后拟定测试case,保证场景覆盖

3.组织case评审,保证后期的测试执行一致性

4.提测后,测试执行,bug提出,跟进,解决

5.有延期上线的风险第一时间和各团队沟通

6.上线交付,风险抛出

7.项目新迭代跟进,历史问题跟进,线上问题答疑

maybe:在过程中组织部门间沟通,给业务方培训

但你会发现这样的问题问的很多,但又千篇一律,以下我根据阿里同学的情况做一下总结思考:

阿里工作流程上:

1.参与KO,确认项目必要参与的人员,增、删、改

2.参与mrd业务价值评审,不合理的业务会被cut

3.mrd确认后,prd评审,确认ptm,根据评审后各部门之间的前后依赖制定测试计划,测试计划要伴随过程中的变动实时变化、并通过prd拟定大方向case

通过以上部分,测试同学可以相对充分理解业务价值和背景,业务背景也是很多同学的薄弱环节,不清楚这部分内容,很难连贯的理解业务场景;

 

4.提测后测试执行,根据过程里的测试难点思考如何抽象出可重复利用的测试提效工具。在有必要的情况下与开发人员共建工具。工具产出后有可能的情况下将工具作为产品去推广

5.bug的提出与定位,这个过程是依赖前期规约开发人员要有非常详尽的日志,并提供文档,保证高效。及时提出及时解决,尽快发布尽快验证

6.中小型项目口头告知测试通过可上线。上线后,大项目做灰度发布做线上监控,业务监控,服务监控,小项目直接发布并做监控。在工作群里通知每一个干系人,上线后的项目所有人都会关注。

7.关注后期的业务价值反馈。业务人员必须让大家看到做的项目产出了多大的价值

8.自驱动做效能工具:自动化、监控、监控治理

相对于传统测试流程,后期我们更强调测试技术的沉淀,以及对线上问题的归纳总结。

还有一种问题就是,我隐隐约约觉得你说的阿里有些内容我们公司似乎也有,但执行的好像不充分,这就涉及到公司文化以及团队执行定力,很多事情只有充分执行和长期执行才能显现出效果。

更多技术交流关注公众号:猿桌派

原文地址:https://www.cnblogs.com/techfix/p/12290109.html

时间: 2024-08-06 21:06:31

【测试面试必问题】测试工作流程的相关文章

软件测试面试必问--bug交互流程

目前市场主要用的bug管理工具:禅道.jira.QC.bugfree等,当然也有自己公司开发的. 不过不管哪一种工具,核心交互流程都是差不多的,只是字段的名称不一样而已,参考如下两张示意图: 这是前几天做的一个项目,由于项目组开发成员对交互不是太明白,所以花了点时间画的一个简单交互示意流程图: K12-禅道项目bug交互流程图 下图是bug核心交互流程图(无论目前市场用的哪一款交互工具,都可以说成如下的流程),面试的时候说哪一个都可以: 原文地址:https://blog.51cto.com/d

OSG 中 相交测试 模块 工作流程及原理

主要涉及三个类: 1. osgUtil::PolytopeIntersector // 具体不同算法实现类 2. osgUtil::IntersectionVisitor //用来遍历节点树的每个节点 3.osg::Node * mNode;  //  你要做相交测试的根节点 先看用法: osg::ref_ptr<osgUtil::PolytopeIntersector> intersector = new osgUtil::PolytopeIntersector(osgUtil::Inter

【软件生命周期&amp;&amp;测试工作流程】软件生命周期和测试工作流程

******软件生命周期:********* ******测试工作流程:******** 原文地址:https://www.cnblogs.com/l-pan/p/12177740.html

功能测试的测试工作流程

按照产出的文档,介绍项目开发过程中的工作步骤 1. 测试计划:这个计划,我个人觉得应该在详细设计确定后,代码开始编写的时候进行制定,因为我是"提早开始测试工作"思路的忠实fans. a) 测试计划,主要是给后面的测试工作一些指南,不能写成领导看的计划,而是要写成由做事的人看的计划 b) 包含的内容可能有: i. 测试团队人员及分工(要确定当测试时出现缺陷界定.测试环境准备等问题时能找到指定的人员) ii. 测试开始结束时间(理想情况下,不要安排的太紧,赶工肯定会造成延期或测试不完整,可

大数据技术之_05_Hadoop学习_02_MapReduce_MapReduce框架原理+InputFormat数据输入+MapReduce工作流程(面试重点)+Shuffle机制(面试重点)

第3章 MapReduce框架原理3.1 InputFormat数据输入3.1.1 切片与MapTask并行度决定机制3.1.2 Job提交流程源码和切片源码详解3.1.3 FileInputFormat切片机制3.1.4 CombineTextInputFormat切片机制3.1.5 CombineTextInputFormat案例实操3.1.6 FileInputFormat实现类3.1.7 KeyValueTextInputFormat使用案例3.1.8 NLineInputFormat使

测试面试常见面试题汇总一

软件的生命周期(prdctrm) 计划阶段(planning)-〉需求分析(requirement)-〉设计阶段(design)-〉编码(coding)->测试(testing)->运行与维护(running maintrnacne) 测试用例 用例编号  测试项目  测试标题  重要级别  预置条件  输入数据  执行步骤  预期结果 1.问:你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决? 首先,将问题提交到缺陷管理库里面进行备案. 然后,要获取判断的依据和标

转帖子:测试专家10年软件测试工作总结

首先,谈谈测试职业规划,即做什么的问题.所谓方向比努力重要,这绝对是一句真理.如果能在刚走上测试工作岗位的时候明白这个道理,那么不出5年,你一定能成为某一测试领域的专家,那时不管是薪水.自信心都是顺其自然的事情.但是遗憾的是,我们获取的太多信息是,测试人员是一个通才,什么都要学,什么都要懂.结果这样的一个方向,导致了3脚猫功夫的测试人员一大把.那么什么都懂一点的测试人员难道就没有用武之地了吗?也不是,可以朝着测试管理岗位发展.说到这里,引出了测试职业规划的第一条路:测试管理.那么很容易想到职业规

测试浅谈(原则、简单流程)

1.测试的原则:·测试证明软件存在缺陷·不可能执行穷尽测试.·测试应尽早启动.尽早介入·缺陷存在群集现象(二八定律)·杀虫剂悖论·不同的测试活动依赖不同的测试背景·不存在缺陷的谬论 2.测试的流程·1.需求分析·2.测试计划[一般测试组长]·3.用例设计·4.执行用例(基础.基本)·5.缺陷跟踪·6.测试总结[一般测试组长] 测什么?·软件源代码·与软件源代码匹配的文档·支撑软件源代码运行的配置数据·需求阶段-----需求规格说明书·系统设计阶段-----概要设计说明书.详细设计说明书·系统测试

测试面试之如何设计登录页面(二)

在测试的岗位上差不多已经有了一年,最近有过一次面试遇到了这个登录面试的面试题(这是我第二次遇到.so 我就像好好的把这个问题弄通)设计用例如果弄懂了后其他的测试用例的测试多少在一定的程度上是互通的.看了其他的博文我对比了我两次的面试的不足和进步,最大的进步应该就是在测试之前一定要了解需求(对于需求真的是每个字眼都要扣清楚,一次的项目有一个圆盘收起的测试,产品的原型上描述的是点击后圆盘旋转收起,那时候我才刚接触测试,测试过程中检查圆盘收起就觉得是通过了,但后面的我的师傅检查后问我点击后你知道是要立