精华内容
下载资源
问答
  • 产品使用过程中对环境的影响
    万次阅读
    2021-10-14 16:28:38

    前言:不知道大家有没有遇到下面两个场景,我是遇到了,还为此召开了RCA会议——复盘会议!

    一、熟悉的场景

    • 生产环境出现问题-定位问题-解决问题-原因复盘-问题定级-划分责任人(每次都希望不会是自己的问题)
    • 无休止的测试-回归-再测试-再回归测试-已经投入了很大精力,但仍对项目质量不信心(每次都在祈祷上线顺利)

    我相信很多人都会遇到上面两种情况吧,如果自己所负责或参与的项目经常遇到上面的两种情况,不妨从项目测试流程角度,去思考原因以及破开瓶颈的方法,从根本上去解决问题,或者减伤出现问题的频率。

    二、测试流程拆解分析

    在这里插入图片描述

    1、需求评审

    需求评审流程:
    需求背景–>需求价值–>需求带来的收益–>用户场景与需求–>功能模块及操作–>流程讲解–>原型演示–>迭代计划及项目排期–>与各方确认是否有疑义

    人人都是产品经理,需求评审对于测试来说就是项目最初的“产品测试”,在理解的基础上发现产品设计缺陷,其中包括逻辑错误,功能缺失,细节问题等等,这样就会有效的在前期规避很多后期开发中产生的bug,减少了很多后期返工的成本。可偏偏需求评审往往是最不重视的一环,甚至可以说是没有这个环节,追其原因无非因为项目时间紧迫或者觉得没有必要,其实这是本末倒置和得不偿失的。

    产品需求作为程序的源头,只有控制好最开始部分,才不会到最后去亡羊补牢。我有过很多血的教训,所以才深深的体会到需求评审的重要性。举个栗子

    记得有一次由于项目时间比较紧迫,没有对需求进行评审,当开始测试的时候发现需求的优惠券计算逻辑有一个重大的错误,经过和产品经理讨论后发现是需求设计有缺陷,需要重新设计一套优惠券计算逻辑。于是改完需求后反馈到开发这里的时候,开发原来的代码不能处理这种逻辑,只能把代码逻辑重新写一遍,最后又花了好几天重构代码,项目就延迟了一周上线。

    后来回头想想如果当时在需求评审的时候把这个问题抛出来,开发就不需要编写错误的代码,测试也不需要再多测试一遍,项目也不会延迟那么久才能上线。类似的教训还有很多,都是由于不重视需求评审造成的,虽然大多数问题还是可以通过后期的测试来弥补的,但这样反正折腾真的是累人累己,如果可以有好的方法来优化,为什么不用呢?

    说了需求评审的重要性,接着就来谈谈如何进行需求评审,总的来说分3步走:

    • 第一步就是要完全读懂产品需求,这个过程只需要理解而不是去挑刺,因为要明白这个需求的目的是什么,为什么这样做,怎么做等等,只有在理解的基础上才能去发现问题,而不是一知半解的去挑毛病,有些需求设计的是不合理,但也许有其特殊的用意,或者只是没有更好的方案,不能为了挑毛病而去挑刺。
    • 第二步就是分析和找问题,这就有点类似写测试用例的时候设计测试方案了,把逻辑梳理出来,看看有没有不对或者遗漏的点,整理出来反馈给产品经理。除了考虑有问题的地方,没问题的地方也是需要分析的,比如有些设计非常合理,但会增加代码的复杂度或者不利于后续的扩展和修改,同时也可能会给测试带来成倍的工作量,这些也是需要指出的,因为测试要考虑的东西一定要比产品经理多,用户使用习惯,程序复杂度,与线上系统的兼容性等等,不然直接让产品经理做测试不就好了吗?
    • 第三步就是细节问题的纠正,可以是界面,可以是文字,开发一般都是复制黏贴或者照着样子画葫芦,这些小问题后期其实也可以测试出来的,但其锅不在于开发,早点发现问题早点解决也是好事一件,至少不用提bug走一套bug处理流程了,也算给大家省点工作量,积少成多也是极好的。

    当然需求评审能解决的问题也是有限的,一方面计划往往赶不上变化,中间会有部分需求的改动,另外一方面有些深层次的问题只有在测试之后才会发现。但无论如何对于测试来说还是非常有必要的,大家一定要积极的参与进去,而不是像听故事一样啥问题都没有,如果能重视起来不仅仅对项目的效率提高不少,而且也能让后期测试压力减小,何乐而不为呢?

    2、技术设计评审

    **通过参与技术设计评审,可以为测试方案提供依据。**例如:核心业务是否需要接口测试、新老数据兼容问题、测试场景的数据构造以及测试所需的工具等,都可以在这个阶段进行思考和产出。另外,可以有效的评估需求影响范围和风险点,避免遗漏。

    此阶段是质量的基石,通过测试左移,尽早发现需求设计缺陷、技术方案风险、关联方依赖影响等方面,了解测试关注点,需求可测试性以及预留排期等问题。

    例如:

    • 接口测试:会员权益核销&&优惠券核销&&退款,接口都需要对前端传入的参数进行校验
    • 新老数据兼容,比如说小程序的发版,一般会滞后于接口发布,一定要测试旧版本的兼容性

    3、测试方案设计

    1. 测试用例设计
      需要从整体入手,而不仅仅局限于待测功能本身的业务逻辑。 好的测试用例,是质量保证的核心
    2. 测试用例评审
      避免三方需求不一致,减少测试执行阶段做无效工作,如执行无效用例、提交无效BUG等
    3. 测试数据准备

    此阶段是质量的骨架,通过测试设计,覆盖更多的测试点、模拟更多的场景、做好更充分的测试准备,为质量保驾护航,为测试赢得更多宝贵的时间。

    测试用例这一步不能忽略,即使改动很小,排期很紧,也建议要画出思维导图;要想提高测试用例设计能力,就需要平时就要多积累,对常见的缺陷模式、典型的错误类型以及遇到过的缺陷,要不断地总结、归纳,才能逐渐形成体系化的用例设计思维。

    同时,对于高质量的测试活动,用例设计不仅需要考虑明确的显式功能性需求,还要涉及兼容性、安全性和性能等一系列的非功能性需求。

    那好的测试用例是如何定义的呢?我在这里说说个人的见解:

    • 不应该从是否能发现BUG的维度去定义,而是应该从集合的完备性角度去思考,也就是测试用例是否能够覆盖所有等价类以及各种边界值为维度去衡量。

    • 如果把被测系统看作一个池塘,BUG是池塘中的鱼,设计测试用例集的过程就像是在编织一张捕渔网。好的用例集就是一张能够覆盖整个池塘的大渔网,只要池塘里有鱼,这个大渔网就一定能把鱼给捞上来。如果渔网本身是完整的且合格的,那么捞不到鱼,就证明池塘中没有鱼,而渔网的好坏与池塘中是否有鱼无关。渔网眼就是测试用例的粒度,粒度越大,意味着网眼越大,这就只能捕捞大鱼,一些小鱼就会漏网。这也是一些项目通用的现状,测试活动由于受限于时间成本和经济成本,只能采用基于风险驱动的模式,选择合适的测试粒度,即有所侧重地选择测试范围和设计测试用例,以寻求缺陷风险和研发成本之间的平衡。

    我个人从下面3个维度出发:

    • 整体完备性: “好的”测试用例一定是一个完备的整体,是有效测试用例组成的集合,能够完全覆盖测试需求
    • 等价类划分的准确性: 指的是对于每个等价类都能保证只要其中一个输入测试通过,同子集下其他输入也一定测试通过
    • 等价类集合的完备性: 需要保证所有可能的边界值和边界条件都已经正确识别。做到了以上三点,就可以肯定测试是充分且完备的,即做到了完整的测试需求覆盖

    4、线下测试(含灰度)

    1. 横向覆盖:
      对于一个场景,从开始到结束涉及到的关键节点,都要进行检查点覆盖,包括功能实现、数据读取、数据计算、数据写入等的正确性
    2. 纵向覆盖:
      正常场景、异常场景、补偿场景都要覆盖
    3. 探索性测试:
      凭个人经验进行探索性测试
    4. 回归测试:拉取回归测试集,手动测试和自动化测试相结合,在测试环境验证新功能对原有功能是否产生影响;

    此阶段是质量的成型,通过测试设计的充分准备、线下测试的严格、立体的执行,发现和解决绝大部分问题。

    在这里我把探索性测试单独拉出来讲一讲:
    根据需求描述来设计最初的测试用例,然后执行测试;在执行过程中,如果得到的输出和预期输出不完全一致,于是会猜测这种不一致是否可能是软件的缺陷造成的;为了验证想法,你会根据错误输出,设计新的测试用例,然后采用不同的输入再次检查软输出。经过几轮这样的猜测和验证,进行反复“探索”,最终确定了一个软件的缺陷。

    但是识别缺陷的思路和测试用例的设计,并没有出现在最初的测试设计和测试用例文档中。探索性测试是一种测试风格,并且强调依据当前项目上下文选择最适合的测试技术。同样的测试风格,由不同的人来具体执行,得到的结果可能会差别巨大,一直强调测试分析能力是最重要的技能。

    5、线上测试

    1. 回归测试:
      拉取线上回归测试集,并结合自动化测试,保证核心流程测试通过
    2. 新功能测试:
      拉取新功能快速验证测试集,并确保覆盖新功能核心测试点

    此阶段是版本质量终态,线上测试主要是为了确保代码部署、生产配置、生产环境对质量的影响。

    6、测试复盘

    在发布上线后,对测试过程进行复盘,总结遇到的问题,对当时的解决方案进行探讨。通过复盘,从而达到指导后续工作,减少重复踩坑。并在可以在个人复盘完成后,在部门内进行信息共享。每个人负责的项目虽然不同,但是测试思想确有共通之处。通过复盘分享,可以有效提升团队整体测试经验。

    此阶段是测试经验累积阶段,也是容易被忽略的阶段。通过信息共享,大大降低重复踩坑的概率。

    7、线上监控

    通过选取业务流程中优先级高的测试用例,作为心跳测试用例定时运行,并持续进行补充完善。

    接口测试用例的开发进度落后于新功能的发布节点。自动化不是跟着新需求走,而是测变化的东西对不变东西的影响。

    此阶段是测试活动右移,质量补偿,快速响应和解决,降低生产事故造成的损失。

    三、总结

    1. 通过规范测试流程,全覆盖产品生命周期,量化测试产出,在有限测试资源下的提升产出
    2. 推动力是衡量测试角色能力的重要指标,特别是一些需求不明确的项目,在各个阶段都要保证信息在团队成员间的一致性

    目前的不足之处:

    • 测试用例评审流程:邮件or会议, 需要产研给出积极响应;
    • 测试各阶段的准入准出条件模糊:进入开发、进入测试,要有基本的要求,一环连着一环,在某些阶段确实可以加入一些提交基线,比如进入测试阶段之前增加提测基线(类似冒烟)
    • 技术沉淀不足,异常场景模拟依赖开发人员

    我觉得作为一个测试,一定要多学、多问、多思考,只有这样,你才能快速成长,拥有全局思维,做到比产品更了解产品!

    在这里插入图片描述

    更多相关内容
  • 本讲主要向我们介绍项目运行的环境,项目所处的环境可能项目的开展产生有利或不利的影响。这些影响的两大主要来源为事业环境因素(EEF) 和组织过程资产(OPA)。项目经理需要基于当前的事业环境因素和组织过程资产的...

    本讲主要向我们介绍项目运行的环境,项目所处的环境可能对项目的开展产生有利或不利的影响。这些影响的两大主要来源为事业环境因素 (EEF) 和组织过程资产 (OPA)。项目经理需要基于当前的事业环境因素和组织过程资产的前提去进行相应的裁剪,制定项目管理计划。

    一、事业环境因素(EEFs)

    是指项目团队不能控制的,将对项目产生影响、限制或指令作用的各种条件。这些条件可能来自于组织的内部和(或)外部。事业环境因素是很多项目管理过程,尤其是大多数规划过程的输入。

     

    组织内部的事业环境因素:

    01

    组织文化、结构和治理。例如包括愿景、使命、价值观、信念、文化规范、领导风格、等级制度和职权关系、组织风格、道德和行为规范。

    02

    设施和资源的地理分布。例如包括工厂位置、虚拟团队、共享系统和云计算。

    03

    基础设施。例如包括现有设施、设备、组织通讯渠道、信息技术硬件、可用性和功能。

    04

    信息技术软件。例如包括进度计划软件工具、配置管理系统、进入其他在线自动化系统的网络界面和工作授权系统。

    05

    资源可用性。例如包括合同和采购制约因素、获得批准的供应商和分包商以及合作协议。

    06

    员工能力。例如包括现有人力资源的专业知识、技能、能力和特定知识。

     

    组织外部的事业环境因素:

    01

    市场条件。例如包括竞争对手、市场份额、品牌认知度和商标。

    02

    社会和文化影响与问题。例如包括政治氛围、行为规范、道德和观念。

    03

    法律限制。例如包括与安全、数据保护、商业行为、雇佣和采购有关的国家或地方法律法规。

    04

    商业数据库。例如包括标杆对照成果、标准化的成本估算数据、行业风险研究资料和风险数据库。

    05

    学术研究。例如包括行业研究、出版物和标杆对照成果。

    06

    政府或行业标准。例如包括与产品、生产、环境、质量和工艺有关的监管机构条例和标准。

    07

    财务考虑因素。例如包括货币汇率、利率、通货膨胀率、关税和地理位置。

    08

    物理环境要素。例如包括工作环境、天气和制约因素。

     

    二、组织过程资产

    组织过程资产是执行组织所特有并使用的计划、过程、政策、程序和知识库,会影响对具体项目的管理。

     

    组织过程资产包括来自任何(或所有)项目执行组织的,可用于执行或治理项目的任何工件、实践或知识,还包括来自组织以往项目的经验教训和历史信息。

     

    组织过程资产可能还包括完成的进度计划、风险数据和挣值数据。组织过程资产是许多项目管理过程的输入。由于组织过程资产存在于组织内部,在整个项目期间,项目团队成员可对组织过程资产进行必要的更新和增补。

    组织过程资产分类

    第1类:过程、政策和程序

    资产的更新通常不是项目工作的一部分,而是由项目管理办公室 (PMO) 或项目以外的其他职能部门完成。更新工作仅须遵循与过程、政策和程序更新相关的组织政策。有些组织鼓励团队裁剪项目的模板、生命周期和核对单。在这种情况下,项目管理团队应根据项目需求裁剪这些资产。

     

    第2类:组织知识库

    资产是在整个项目期间结合项目信息而更新的。例如,整个项目期间会持续更新与财务绩效、经验教训、绩效指标和问题以及缺陷相关的信息。

     

    三、组织系统

    运行项目时需要应对组织结构和治理框架带来的制约因素。为有效且高效地开展项目,项目经理需要了解组织内的职责、终责和职权的分配情况。这有助于项目经理有效地利用其权力、影响力、能力、领导力和政治能力成功完成项目。

    单个组织内多种因素的交互影响创造出一个独特的系统,会对在该系统内运行的项目造成影响。这种组织系统决定了组织系统内部人员的权力、影响力、利益、能力和政治能力。


    系统因素包括(但不限于):
    1.管理要素;管理要素指组织内部关键职能部门或一般管理原则的组成部分。
    2.治理框架;
    3.组织结构类型。

    四、组织结构对项目的影响

    (点击图片可放大查看,指南P47可见上图)

    五、项目管理过程组&项目管理知识领域

    项目管理过程组

    项目管理知识领域

    项目管理过程组指对项目管理过程进行逻辑分组,以达成项目的特定目标。过程组不同于项目阶段。

    知识领域指按所需知识内容来定义的项目管理领域,并用其所含过程、实践、输入、输出、工具和技术进行描述。

    项目管理过程组分为启动过程组、规划过程组、执行过程组、监控过程组、

    收尾过程组。

    项目管理知识领域分为项目整合管理、项目范围管理、项目进度管理、项目成本管理、项目质量管理、项目资源管理、项目沟通管理、项目风险管理、项目采购管理、项目相关方管理。

    展开全文
  • 产品经理的私房菜 - 腾讯产品能力模型(序章)

    万次阅读 多人点赞 2021-04-16 18:41:49
    希望大家从梳理过程中,找到提升的方向! ❞ 「初稿|木深、木小深」 「编辑|牟深、Sam、Ella」 一、开场白 金三银四,自然而然地就和腾讯的同事,聊到了求职这个话题。我就问她:“面试社招的同学时,会喜欢「务虚...

    产品经理的私房菜 - 腾讯产品能力模型(序章)

    编辑导语:为了解决”产品经理“职业成长中,不自信的问题。本系列就围绕”腾讯产品的能力模型“,一起从头梳理,每一个能力项的提升思路。希望大家从梳理过程中,找到提升的方向!

    「初稿|木深、木小深」

    「编辑|牟深、Sam、Ella」

    一、开场白

    金三银四,自然而然地就和腾讯的同事,聊到了求职这个话题。我就问她:“面试社招的同学时,会喜欢「务虚」的人,还是「务实」的人呢?”

    她想了想说道:“感觉「务实比较好」。但是实在不等于保守、封闭、唯唯诺诺,还是要体现自己「胆大」「心细」、敢于挑战「创新」”。还说,“务实能体现自己做实事的作风;胆大能体现自己挑战自我的作风;创新能体现自己有想法。她作为面试官,会喜欢这三者合一的人。”

    综上,在务实的大方向下。咱们计划,根据腾讯的能力模型逐一梳理,相信走完这轮复习,你会有所收获。

    【★本章节是序章(不涉及高P相关能力说明),目的是提供“模型”和“释义”,帮助大家设定合适自己的对标模型,作为小目标】

    二、能力模型

    2.1 能力模型表格

    能力项中标红的部分,属于最先拉满的技能,正好对应组里同事提到的“胆大、心细和创新”。所以本系列的最后一篇,有计划分享如何在简历中,凸现这三个重点。

    2.2 雷达图(对标职级T2-1)

    这是对标T2.1级别,梳理的雷达图。之后的系列,会陆续以此为目标,阐述相关能力项所需要具备的能力。

    2.3 对标职级背景

    腾讯去年宣布调整职级,取消了原有的 6 级 18 等(1.1-6.3 级)的职级体系设计,将专业职级体系优化为 14 级 (4-17 级)。与之相对应的是,统一置换为“专业职级+职位称谓”。

    • 「岗位职级」一般来讲,5年内的产品经理,大概对应“能力模型”中,1-3级。也就是T1-1 ~ T3-3这个区间内。

    • 「晋升条件」腾讯的晋升指标主要就有两部分。一方面是硬性指标:根据年限、绩效、贡献等等决定;另一方面是答辩(专业通道面试):原则上2.2之前对硬性指标的要求不高,从T2-3开始对硬性指标要求较高并有严格面试。

    三、简要说明(初级产品岗能力释义及标准)

    3.1通用能力

    1、学习能力(基本素质)

    通用释义:

    • 有学习愿望,能够在指导或者要求下进行学习
    • 能够通过示范式、教练式学习或者指定的学习资源掌握做好自身岗位工作所需要的知识、技能、工具和信息等。

    行为标准:

    • 提交参加基础业务培训或 「自学内容的」资料 「证明」、学习体会或用之于工作的证明
    • 完成要求的培训并通过对应的考核

    2、执行力(基本素质)

    通用释义:

    • 能制定简单的工作计划,保证按时完成工作任务,基本保证工作的质量

    行为标准:

    • 提交过往1年中本人负责的至少2个小型项目的 「工作计划」「执行跟踪表」「执行结果」

    3、沟通能力(基本素质)

    通用释义:

    • 有主动沟通意愿,但沟通技巧和理解能力不足
    • 能够主动跟对方沟通,完成一般的目标单一、内容简单的沟通任务

    行为标准:

    • 举证过往1年中组织的部门内的 「沟通会议的纪要」「解决的主要问题」

    5、心态和情商(关键素质)

    通用释义:

    • 乐观、积极,勤于思考,能够快速融入陌生的环境

    行为标准:

    • 举证在过往1年工作中团队融入、 「工作创新的例证」或直接上级、项目负责人的 「评价」

    3.2 专业知识

    6、技术知识(关联知识)

    通用释义:

    • 知道互联网开发过程中涉及到的主要技术名词等理论概念

    行为标准:

    • 列举自己所了解或掌握的 「技术名词」、实现 「原理」及其 「表现形式」

    7、项目管理(关联知识)

    通用释义:

    • 熟悉项目管理基础知识和和核心管理控制点。能够进行简单项目的计划跟踪和监控

    行为标准:

    • 列举并提交已完成的 「项目计划」「过程跟踪」纪要

    8、其他知识:财务、心理学、美学、办公技能等(关联知识)

    通用释义:

    • 听说过一些和本职位相关的零星的财务、法律知识
    • 能够在指导下完成一些跨BU合作项目的比较具体的工作

    行为标准:

    • 提交过往1年内参加 「跨BU合作项目」的具体工作证明和负责人的工作评价
    • 列举过往工作过程中学习或使用相关财务、法律知识的内容和对应的工作内容

    3.3 专业技能

    9、产品规划:版本计划/节奏(产品能力)

    通用释义:

    • 知道产品规划的工作流程和成果输出,能清晰描述出客户的原始需求,但需要在指导下完成功能特性的设计抽象工作

    行为标准:

    • 列举并提交过往1年中完成的 「功能特性设计」任务的过程和结果证明

    10、专业设计能力(产品能力)

    通用释义:

    • 具备一定的专业知识和技能,擅长某些方面的产品设计和策划技巧,能在别人指导下完成产品局部功能或者小型产品的设计,能使用文档清晰的向他人表述相关设计思想和内容

    行为标准:

    • 列举并提交过往1年中完成的具体 「策划设计案」的文档和研发 「结果证明」

    11、市场分析能力/前瞻性(市场能力)

    通用释义:

    • 具备基本的调研常识,能够在指导下完成调研的任务

    行为标准:

    • 列举并提交过往1年中完成的调研任务过程中的资料和 「最终的分析报告」

    12、对外商务沟通(BD/P3以上)(市场能力)

    通用释义:

    • 事先进行 「谈判策划」,能作为商务主要参与人进行谈判,掌握多种谈判技巧

    行为标准:

    • 作为主要成员 「参与过商务谈判」,并提交谈判负责人的对过程中的 「表现」得评价

    13、运营数据分析(运营能力)

    通用释义:

    • 了解运营涉及的核心数据及指标的含义,能在指导下对运营数据进行最基础的分析并给出报告

    行为标准:

    • 列举并提交过往1年中完成的运营 「数据分析报告」

    14、市场营销:品牌/公关/推广(运营能力)

    15、渠道管理(运营能力)

    通用释义:

    • 熟悉相关产品渠道管理的一般知识
    • 能够理解并掌握各项渠道政策和流程,对客户/代理商进行正确的政策引导,提供合格的渠道服务

    行为标准:

    • 列举自己过往工作过程中主要使用或掌握的 「渠道管理流程」或规范等
    • 列举并提交开展渠道服务和伙伴引导的工作成果证明

    16、市场/用户调研与分析(客户导向)

    通用释义:

    • 熟悉并掌握收集用户需求的理论、方法和基本技巧
    • 能够独立完成有明确目标的客户需求收集的任务

    行为标准:

    • 列举并提交过往1年独立完成的用户 「需求收集及分析」的过程和成果证明

    3.4 组织影响力

    17、方法论建设(领导力)

    18、知识传承(领导力)

    通用释义:

    • 在工作过程中注意积累和总结,并主动分享给其他同事,使优秀实践和成功经验得以传承和快速复制

    行为标准:

    • 提交过往1年中培训课件开发和 「经验总结」
    • 举证知识分享取得的成果,重点展示成果的 「传承和复用」

    19、人才培养(领导力)

    通用释义:

    • 有培养后备人才的意识,时刻保持对后备人选的识别、指引和关注
    • 主动引导团队其他成员一起进行知识分享,能够营造学习、分享和共同进步的团队氛围

    行为标准:

    • 举证在 「后备培养」方面所做的努力和成果,如参加通道建设工作等
    • 举证在 「营造团队学习分享氛围」方面的努力和成果

    四、结束语

    《腾讯产品能力模型 - 序章篇》就到这里啦,希望序章部分能帮助大家找到方向,积跬步以致千里。加油鸭,下期正式开始拆解具体能力模块,期待你的加入~

    本系列交流群,近期会面向读者开放一阵子,特此感谢勤劳的小助手Ella❤️。记得备注 “进群”。

    如果你有任何问题,请在留言区告诉我们。也请记得订阅「公众号木小深」和我们的专栏,欢迎分享给其它有需要的人。我们这期分享就到这里了,再见❤️。

    展开全文
  • 在开发的过程中,不可避免会接触到至少三个环境的程序部署:开发、测试和生产环境。 可能在每个环境使用一套数据库配置,路径配置等,如果每次都人工的干预每一个配置文件,工作会比较繁杂,且容易遗漏并且出错。...

    在开发的过程中,不可避免会接触到至少三个环境的程序部署:开发、测试和生产环境。
    可能在每个环境都使用一套数据库配置,路径配置等,如果每次都人工的干预每一个配置文件,工作会比较繁杂,且容易遗漏并且出错。这是其一。

    在开发时,有一些代码仅在开发时运行,发版时不能运行。比如:测试用的mock数据、自动登录以方便调试应用、在本次上线时不上线的功能等。这是其二。

    测试人员需要在测试服务器和线上服务器间来回切换,原来经常需要为连接测试服务器和线上服务器打不同的包,测试人员和开发人员都很麻烦。这是其三。
    这里写图片描述
    如何让麻烦解决,其实只需通过eoLinker的环境管理,实现开发环境、测试环境、生产环境配置自动切换。
    这里写图片描述
    在讲到环境管理的切换之前,我们必须知道开发环境、测试环境、生产环境分别是什么?切换的目的是什么?方便切换环境能带来什么开发便捷?

    开发环境:开发环境是程序猿们专门用于开发的服务器,配置可以比较随意, 为了开发调试方便,一般打开全部错误报告。

    测试环境:一般是克隆一份生产环境的配置,一个程序在测试环境工作不正常,那么肯定不能把它发布到生产机上。

    生产环境:是指正式提供对外服务的,一般会关掉错误报告,打开错误日志。

    三个环境也可以说是系统开发的三个阶段:开发->测试->上线,其中生产环境也就是通常说的真实环境。是线上用户直接接触的产品环境,其性能级别是最终的,直接影响用户的体验感。所以,生产环境要考虑性能,开发环境不能直接应用为生产环境,我们需要对环境可以优化的部分进行优化。

    这里写图片描述

    接下来是环境管理的实操部分。

    环境管理(注意:专业版和免费版功能一致,免费版能使用环境管理的所有功能)

    eoLinker AMS 提供了目前最强大的 项目环境管理 功能,您可以通过它实现:

    • 一键修改所有API接口的请求前缀(Base URL/根路径)
    • 加上统一Header
    • 加上统一请求参数
    • 通过全局变量动态改变所有接口中的请求参数值等

    统一加上Base URL,方便测试,不用每个接口测试的时候都要填Base URL,类比header、请求参数、全局变量也是一样的道理,其实额外参数和全局变量是同一个意思,全局变量通过{{userID}}赋值,而额外参数是自动加上的。

    如何创建新的环境?需要修改和删除环境呢?

    • 创建环境

    进入环境管理页面,点击添加环境按钮,输入相关的环境名称(如测试环境、生成环境等):

    这里写图片描述

    点击 保存 即可创建一个新的 项目环境。

    • 修改环境

    鼠标点击需要修改的 环境,在右侧直接修改相关的内容,点击保存即可:

    这里写图片描述

    点击之后选择 删除 按钮,即可删除该环境:

    这里写图片描述

    一键修改所有根路径(Base Url)

    eoLinker AMS 提供了目前最强大的 项目环境管理 功能,您可以通过它实现一键修改所有API接口的请求前缀(Base URL/根路径):
    创建环境之后,填写 前置URL 后保存设置:

    这里写图片描述

    在 接口列表页面 或 接口详情页 点击页面右上角 切换环境菜单,选择想要切换的 环境,会发现API的路径已经自动加上环境的前置URL了:

    这里写图片描述

    添加统一Header

    eoLinker AMS 提供了目前最强大的 项目环境管理 功能,您可以通过它实现一键为所有接口添加统一的请求头部(Header):
    创建环境之后,填写 请求Header头部 后保存设置:

    这里写图片描述

    在 接口列表页面 或 接口详情页 点击页面右上角 切换环境菜单,选择想要切换的 环境,会发现API的路径已经自动加上环境的请求头部了:

    这里写图片描述

    添加额外请求参数

    eoLinker AMS 提供了目前最强大的 项目环境管理 功能,您可以通过它实现一键为所有接口添加统一的额外请求参数。

    创建环境之后,填写 额外请求参数 后保存设置:

    这里写图片描述

    在 接口列表页面 或 接口详情页 点击页面右上角 切换环境菜单,选择想要切换的 环境,会发现API的路径已经自动加上环境的额外请求参数了。

    注意:额外请求参数并不会显示在接口文档的详情中,只会在测试中出现!

    这里写图片描述

    使用全局变量

    eoLinker AMS 提供了目前最强大的 项目环境管理 功能,您可以通过 全局变量 动态改变所有接口中的请求参数或。者参数值等:
    创建环境之后,填写 全局变量 后保存设置:

    这里写图片描述

    在接口详情或者测试页面中,将全局变量填入请求参数或值中,在发送请求时会自动替换为相应的值。

    用两个大括号将参数名包裹起来,即可引用全局变量,如 {{key}},全局变量可用于:

    API URL中的局部地址,如 www.eolinker.com/{{key}}
    请求头部的参数名和参数值
    请求参数的参数值和参数值

    如下图中的userToken的参数值为全局变量{{token}},在发送请求时会自动将{{token}}替换为设置的1234567890:

    这里写图片描述

    eoLinker是目前全球领先、国内最大的在线API接口管理平台,提供自动生成API文档、API自动化测试、Mock测试、团队协作等功能,旨在解决由于前后端分离导致的开发效率低下问题。
    目前eoLinker为Google、IBM、腾讯、中国联通、海尔、神州优车、国美、江苏网进、广联达、成思科技、捞月狗等数千家企业提供快速、专业、稳定的API管理服务。
    同时eoLinker还是Google谷歌开发者联盟的合作产品与企业,不定期举办线下交流分享活动促进国内API管理领域的发展。

    中文官方网站:https://www.eolinker.com
    github源码:https://github.com/eolinker

    这里写图片描述

    展开全文
  • 会出问题,insert语句不指定列名,如: insert into table_name values(xxx, xxx, xxx); 你现在表加了一个字段,不就出错了。
  • 人(Man):操作者质量的认识、技术熟练程度、身体状况等; 机器(Machine):机器设备、测量仪器的精度和维护保养状况等; 材料(Material):材料的成分、物理性能和化学性能等; 方法(Method):这里包括生产...
  • 产品经理的私房菜 - 腾讯产品模型 - 学习能力篇

    万次阅读 多人点赞 2021-05-23 23:35:39
    希望大家从梳理过程中,找到提升的方向! 初稿|木深、木小深 编辑|牟深、Sam、Ella 一、开场白 说来惭愧,周一帮朋友递了简历,没有通过。特意问了下原因,蛮寒心的。节选一部分,大家感受下。 “这份简历,...
  • 产品的源头是需求。一切伟大产品的实现都是从需求管理开始的。敏捷开发的需求管理大致分为三个阶段:需求调研,需求分析和需求确认。 需求调研阶段 ...从产品定位出发指的是,产品经理应当自己的产品...
  •  规定软件产品的运行和用户的操作支持的各种活动,涉及到用户环境产品运行环境的测试、部署、操作和支持。 3) 维护过程:修改、变更  保持系统操作完整性的前提下,系统进行变更、移植与升级,包括...
  • 职业生涯环境分析-职业环境分析.doc

    千次阅读 2021-06-22 19:39:57
    职业生涯环境分析-职业环境分析.doc职业生涯环境分析-职业环境分析环境分析与职业认知环境分析与职业认知本章要点:帮助当代大学生认清所选职业在社会大环境中的发展状况、技术含量、社会地位、未来发展趋势等。...
  • 现代数据环境下,如何做数据集成?这11个靠谱实践收藏了
  • 软件过程

    千次阅读 2018-06-18 20:51:08
    1、定义 软件过程也称为软件生存周期过程,是指软件生存周期的一...工件:软件过程的工作产品,分输入与输出工件; 角色:定义了软件过程中的个人或小组的行为与职责; 资源:最佳实践、工具、技术、机器、场地...
  • 产品开发的完整环节

    万次阅读 2019-02-12 08:47:36
    要么不切实际,实际开发过程中困难重重; 要么扩展性不好,导致后期增加、修改功能时必须得全部重做; 要么用户体验不好,被用户吐槽 难以使用。 下面描述了完整的产品环节(具体细节并不完整): 1、需求收集...
  • 在学习信息高项的时候,对于10大管理要把握这样一个规律: ...这边十大管理的前两个问题,进行整理。 十大管理: 项目整体管理 项目范围管理 项目进度管理 项目成本管理 项目质量管理 项目人力资源管理 ...
  • 1 B 端产品经理 如何理解B端产品? B端产品主要分为两大类: 为公司的管理服务,如:HR系统、OA系统; 为公司的运营服务,如:供应链系统、ERP系统的。 B端产品即要符合商业组织的战略要求,能够满足商业用户...
  • 软件开发项目中影响进度的因素很多,如人为因素、技术因素、资金因素、环境因素等等。在软件开项目的实施,人的因素是最重要的因素,技术的因素归根到底也是人的因素。软件开发项目进度控制常见问题主要是体现在
  • ADS1292R 使用 过程 心电图 高精度ADC模块

    万次阅读 多人点赞 2020-09-21 12:24:19
    这两个噪声源是不相关的,因此可以使用平方根法来确定模数转换器的总噪声: 量化噪声是模数(或数模)转换过程的副产品,与量化噪声不同,热噪声是所有电气元件固有的现象,是电导体内部电荷物理运动的结果。...
  • 超硬核!操作系统学霸笔记,考试复习面试全靠它

    万次阅读 多人点赞 2021-03-22 18:43:49
    1)将被阻塞的进程从等待该事件的阻塞队列移除 2)将PCB的现行状态由阻塞改为就绪 3)然后再将该PCB插入就绪队列 4)转进程调度或者返回 block原语和wakeup原语是一对作用刚好相反的原语,必须成对使用。...
  • 软件测试-环境搭建思路/测试流程

    万次阅读 多人点赞 2020-04-02 19:54:05
    1.软件测试环境搭建 思考: 在什么条件下做软件测试? 怎么做软件测试? 1.1 搭建测试环境前 确定测试目的 功能测试(验证软件是否满足用户的需求),稳定性测试,还是性能测试(软件的效率),测试目的不同,搭建...
  • (开发环境就是每个开发人员电脑上的开发环境,只有开发人员可以配置和开发,写数据测试放在测试环境) 2.测试环境:新开发和配置通过系统传输到测试环境,进行功能测试,可以创建数据。(开发人员开发完上传到SV
  • 5G技术我们生活的影响

    千次阅读 2019-06-06 17:05:17
    网上找了好一会儿5G相关说明,太专业了好么,什么毫米波公式一大堆,虽然我本科是学通信的,但是查了半天都没完全理解不了,我觉得作为普通大众不关心你这个具体通信过程使用了哪些纳米毫米波技术,这频段那频段,...
  • 为了计划测试活动和工作产品来实现测试目标,必须一个系统的测试需求进行分析 实用可追溯性来检查与测试目标、测试策略和测试计划相关的已定义测试条件的完整性和一致性 解释可能影响所规定测试条件详细程度的...
  • 测试前的准备:搭建测试环境

    万次阅读 2017-11-20 21:24:31
    测试环境大体可分为硬件环境和软件环境,硬件环境包括测试必须的PC机,服务器,设备,网线,分配器等硬件设备;软件环境包括数据库,操作系统,被测试软件,共存软件等;特殊条件下还要考虑网络环境,比如网络带宽,...
  • PMP 项目管理过程组与知识领域梳理

    千次阅读 2019-12-08 10:32:05
    考试口诀:三长一短选短,三短一长选长 两长两短... 启动过程组 输入:商业文件、协议; 输出:项目章程、相关方登记册;假设日志; 项目启动会议Initiating Meeting:分发项目章程,宣布立项,项目经理...
  • 为了使软件系统适应这种变化,需 要软件进行相应的修改,这种维护活动称为适应性维护 (3)完善性维护 在软件的使用过程中,用户往往会软件提出新的功能与性能要求,为了满足这些 要求,需要修改或再开发软件,以扩充...
  • 详细SpringBoot教程之入门(一)

    万次阅读 多人点赞 2020-02-21 16:04:29
    Spring Boot来简化Spring应用开发,约定大于配置,去繁从简,just run就能创建一个独立的,产品级别的应用 随着Spring全家桶时代的到来,SpringBoot带来的J2EE一站式解决方案,SpringCloud带来的分布式整体解决方案...
  • 互联网产品灰度发布

    万次阅读 2016-05-30 14:37:39
    互联网产品灰度发布   关于2016年5月15日,DevOps成都站|架构与运维峰会活动总结 1. 前言 2 2. 灰度发布定义 5 3. 灰度发布作用 5 4. 灰度发布步骤 5 5. 灰度发布测试方法 6 6. 灰度发布引擎 6 7. 灰度...
  • 如何高效完成产品生命周期管理

    千次阅读 2018-08-15 20:41:54
    作者介绍: ...产品研发流程的发展经过了很多阶段的变化,不同企业使用的研发模型一般不一样,有些大企业注重规范会引入CMMI研发模型,有些企业可能因为传统项目的因素,还在使用瀑布式开发模型,而互联...
  • 软件测试管理——测试的风险分析

    千次阅读 2016-07-14 13:43:54
    1.软件需求的风险主要表现在以下的几个方面:■需求变更风险,在项目的后期用户总是不停的提出需求变更从而影响设计、代码,并且最终反映到测试来。需求变更后测试用例没有及时更新;更重要的是在项目的后期频繁的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 308,749
精华内容 123,499
关键字:

产品使用过程中对环境的影响