如何工作

一.前言
工作三年以来，越来越发现工作就是一件很琐碎的事情, 不是个人英雄主义单枪匹马就可以往前冲的单打独斗，也没有什么一击便可以成名的伟大壮举, 多的是被各种条件限制，努力向KPI,OKR 靠近的挣扎。总结了最近三年的工作经验，有很多不成熟的地方，也希望大家多多指正。
 
二. 基本前提
在职场里，收到指令要回复, 遇到困难要沟通, 项目进展要按节点通报, 安排要落实。这不是繁文缛节, 这是一个公司的基本规范。要尽心尽力, 说到做到，有始有终, 积极主动, 你才能成长, 公司也才能。不要玻璃心, 也不要有惰性, 更不要骄横, 有多少人，有才华，有远志，不约束自己，最终也不过暴殄天物
 
三. 如何汇报
1. 站在老板的角度来汇报，不要陷入到自己的细枝末节当中, 比如自己的代码是怎么实现的, 说老板关心的点，比如 xxx指标提升了多少。
 
2. 把每次汇报都当做一次面试，汇报之前，提前在脑子里面想好汇报的内容以及可能会被问到的问题，私下多练习几次。汇报要注意总分总的结构。先说结论，再说分论点，再结合分论点来说细节，这样容易显得条理清晰。
 
3. 用数据量化自己的工作，工作的意义是通过指标来体现的，指标变化的幅度可以很好的提现工作的深度。工作的时候，最好能背下自己的指标。好处至少有两点, 老板临时突击的时候，指标可以脱口而出，体现自己对工作的熟练。在汇报的时候也能够更加从容。
 
四. 如何提高工作效率
1. 完全理解老板的意图，如果还有疑问，就先把工作停下来，把所有疑问都梳理出来，和老板沟通清楚再开始做。结合老板的意图，想明白这个工作的意义在哪，如何做才能出彩, 定义指标来衡量工作的进展。
 
2. 不要返工, 不要推倒重来, 将所有的步骤都想明白了写下来，每做一步，验证一步, 不要全部做完再开始验证，不然的话很有可能就是另外一个悲剧了。
 
3. 做好脚本自动化，对于模型训练，数据处理这类的工作，在做的时候就应该考虑脚本自动化，好处有二，第一个最直接的好处是之后的训练可以直接复用以前的工作，第二个是将所有的业务逻辑抽象出来以后，方便验证，
 
4. 合理规划自己的工作，在每个周末的时候花一个小时想明白下周五要汇报的工作，合理分解每天的工作。当想明白下周的工作内容之后，学习的内容也可以提前为工作的内容做准备，毕竟机会是有限的，提前准备不仅可以提高自己的工作效率，当机会来的时候，你就已经准备好了
 
5. 熟记基本命令，比如awk, shell, git 这些命令, 记住常用用法，不要每次用到的时候都去查搜索引擎
 
五. 如何加深信任
1. 不要在小事上吃亏, 一开始工作的时候，老板对你不了解是很难信任你的，给的都是小活，不要因为是小活就懈怠了，尽心尽力，按时交付。
 
2. 做事超出预期, 工作三年, 深感好的机会是有限的，每次老板交付的事情, 其实都一次信任加深的契机，把每一件小活做的都要做的超出预期，这样才有机会独立承接项目，每次小事都做的敷敷衍衍，第一是让人觉得你态度很不好，第二也让人怀疑你的能力是不是连小事也做不好。
 
3. 学会示弱，需求帮助，合理的寻求老板的帮助，比如在一些关键的场景如:晋升答辩，需求老板的建议与帮助会让老板觉得你也是信任他的，信任从来都是相互的。
 
六. 总结
工作就是一件很磨人的事情, 充满着方方面面的限制，在这种有限的条件做出厉害的事情真的是一件很难的事情也是一件让人很有成就感的事情。
 
 

测试流程

 

主要流程概述

说明：项目整体owner作为项目经理

          QA这边的owner建议由改动比较大的或者提出需求方作为owner

 

1、需求评审

  •     产品对项目内容进行讲解，并说明prd中的内容；
  •     测试人员主要是对需求的理解提出疑问，以便才能根据需求写用例；
  •     开发人员根据需求功能点进行排期，然后将开计划转交给测试人员；
  •     测试负责人根据测试用例数目以及功能点评估测试时间；
  •     项目的开发与测试计划及时钉钉给相关人员。

2、编写测试用例

  •    阅读项目prd，与钻展测试负责人即本次项目的owner明确项目的需求和主要功能点；
  •    编写测试用例。

3、测试用例评审

            重点大项目： 建议可以先在小组内进行评审

  •  对于XX项目的重点功能进行修改时进行；
  •   在测试用例完成后，上传Bug管理平台
  • 以邮件形式将用例发送给组内人员，以便他们事先了解用例对哪些功能进行验证以及验证的细节；
  •  对用例进行评审，补充遗漏的测试功能点。

4、提测

  •  开发对测试相关人员在管理平台上备注
  •  测试人员需要明确开发完成的内容，如果与prd不符，需要及时与产品沟通确认；
  •  与开发明确项目是否影响其他功能，如果有需要进行相应的回归测试；
  •  部署测试环境，准备开始测试

5、测试

  •   根据测试用例进行测试；
  •   发现问题后，记录到Bug 平台，并设置提醒进行高效跟进
  •   BUG修改后，进行验证；
  •   对于前端项目，线下测试完成后，需要部署预发环境进行测试，需要修改domain的配置

 

6、测试日报&报告

         重点项目需要测试日报体现，日常项目钉钉同步进度

  •  冒烟测试打回：在平台上记上
  • 测试日报邮件内容：

a)    题目：【测试进度】-【XX】- 日期；

b)   测试进度；

c)    测试内容；

d)    存在的BUG；

e)    需要明确的问题。

7、线上回测

  •  项目上线后，一定要第一时间回测；
  •  接口层上线，观察是否有errorlog

8、项目资料积累

  •  项目测试完，资料的积累
​
​

测试日报模板

Hi all:

【项目名称】- 2019.04.09-测试日报-XX

 

一、测试进度：

     测试排期：xx侧：2019-3-4~2019-3-12（第一轮测试进度90%，见具体）；

                     引擎侧：2019-3-5~2019-3-8（测试进度：50%）；

                     算法侧：已开完完成，等待联调

      重点关注：暂无（如果有，要描述关注啥，谁关注）

     

     BP侧第一轮测试进度：90 %，case执行如下：

​
 
 

测试轮次

待执行case

阻塞case

已执行case

第一轮(100)

40

10

50

第二轮

 

 

 
 
 
 
​

case的统计，目前需要将case导入aone中，统计成本需要考虑

 

 

二、项目bug以及风险

 

风险：1、项目周期长，主要耗时在，定向中心-bug修复；

          2、定向中心-reopen-bug较多，bug修复后引发更严重的bug。

               以上两个原因导致项目上线时间有风险。

 

bug列表：xxxxxxxx  ​@​XX，请关注

​
 
 

Active

Resolved

Closed

Total

1（P1）

 0

17（3P2+14P）

 18
 
 
 
​

 

三、测试内容：

 

  1. 新增定向功能：DB数据check、算法数据产出、引擎召回  100%
  2. 新增过滤功能：DB数据check、算法数据产出、引擎召回    80%
  3. 联调测试：  10%

 

四：测试环境

    140.205.173.181 zuanshi.taobao.com

    indexbp1：daily/0.0.316；indexbp2：daily/0.0.22

​
​

 

​
​

测试报告

【定向二期】本次提测已经完成100%

 

 

一、测试结果：测试通过


       遗留问题：暂无，如果有，描述问题+解决时间+跟进人

 

二、提测质量：

提测质量： 提测次数2次；

测试质量： bug总数:1个，其中P1级1个，P2级0个，P3级0个。

 

三、测试环境：

    140.205.173.181 zuanshi.taobao.com

    indexbp1：daily/0.0.316；indexbp2：daily/0.0.22

 

四：代码分支

    zuanshi_service：26bd7fdc151ce688fc7444e3e1013a3f50dd69fd

 

五：测试时间

 

测试开始时间2019-3-4   测试结束时间：2019-3-12

测试所用时间：5天

非测试消耗时间：2天（等待bug修复）
测试执行轮次：2轮

 

五：测试内容

​
 
 

检查项

子项

指标

测试内容

测试结果

备注

基础功能

新功能

case通过率100%
  1. 新增定向功能：DB数据check、算法数据产出、引擎召回 
  2. 新增过滤功能：DB数据check、算法数据产出、引擎召回   
  3. 算法&引擎均联调通过

pass

  

影响功能

case通过率100%

核心功能

case通过率100%

全功能

case通过率100%

联调功能

     case通过率100%

兼容性

接口兼容

接口无bug，页面交互正常

无

不涉及

 

web兼容

交互正常，样式美观，无bug

第三方依赖

调用第三方服务返回错误（数据，顺序）

服务可用，有降级或重试方案，提示友好

无

不涉及

  

调用第三方服务超时

服务可用，有降级或重试方案，提示友好

调用第三方服务不可用

服务有损可用，有容灾或降级方案，提示友好

网络异常

服务有损可用，有容灾或降级方案，提示友好

上线步骤

上线和回滚方案

上线和回滚过程无损，用户感知小

正常上线。

pass

  

基础性能

吞吐量

不低于稳定环境性能

无

不涉及

  

响应时间

不低于稳定环境性能

错误率

不低于稳定环境性能
 
 

 

 PS 设计测试用例：

http://www.testclass.net/post/about_interview
 
 
重点：

有的候选人是这么回答的。

假如是一袋盐，那么要看看装盐的袋子是不是会漏？

这时候我一般会反问，那应该是要漏还是不要漏？很多候选人这时候会愣住，可能完全意识不到我为什么会这么问。

我这么问是因为我有个怪癖，那就是我希望测试用例都是可以执行的。可以执行的意思是，你要告诉我你究竟是希望袋子漏还是不漏。如果你希望袋子是不漏的，那么袋子漏的时候测试用例就是不通过的，反之也成立。如果你告诉我看看袋子漏不漏，那么因为我是很笨的，我不知道如何去执行这个用例，因为我不知道袋子究竟是需要漏呢还是不能漏。

与之类似的，在测试衣服的时候，有的候选人会回答要看衣服的尺码是不是合适。那么我会反问，对于L号，衣服多长是合适，多长又是不合适呢？这是因为合适不合适是没有执行标准的，对于一个身高不高的人——比如1米49家穷人丑的我——来说，L号是不合适的，太长了。而对于身材匀称的其他人来说，L应该是合适的。所以合不合适没法量化，加上又有模棱两可的是不是这样的词语推波助澜，这种用例执行起来是相当困难的。

所以写用例，要想可执行，首先的第一条原则是，不要包含一些似是而非的词语，比如是不是，要不要，有没有之类的。换句话说，就是用例里大概率要么包含是，要么包含不是这样的词。

比如

  • 装盐的袋子不能（不是）漏

  • 衣服的颜色是红的

  • 衣服的材料是80%的棉，20%的涤纶

像这样的是或者不是的句型，我们可以称之为断言。

上面是最基本的用例设计，主要考察的是思维的全面程度，以及设计用例的最基本要求——可以执行，没有歧义。另外我还喜欢根据候选人的经历去问一些稍微有技术深度的问题。

​

 

 
posted @ 2020-04-21 11:26  DrewBetter  阅读(141)  评论(0)    收藏  举报