pytester的博客

一个新系统，需要写用户操作手册，该从何下笔？本篇是一篇教你编写用户帮助/操作手册的指南～

背景2021 过去了，该来个年终总结了，借鉴了测试专家：老徐的年终总结模板，梳理出了我的 2021 测试年终总结 。总结大纲：对今年的整体复盘在今年，有哪些没做好的。明年，我计划怎么做？我在公司的价值是什么？对公司/团队想说的话一、2021年整体复盘：1、C产品 接手：● 2021年2月，接手 C产品 ，三天内接手产品并快速上手编写 Case，很快融入到 C产品 团队 ，同时做好 S产品 的交接工作 。2、C产品 测试建设：● 自动化建设： 2021 团队 KPI 中 的 C产品

#百字千日计划 昨天因为太忙，居然忘记写了，今儿补上。昨天上午新增紧急需求，在需求评审开始前，已将该需求安排给 ：W ，但我 跟 H 还是去听了这个需求评审。需求评审后，还是会有一些疑问点，我在群里提出了我的疑问点，产品回复 。但 H 对产品回复不解，拉着我讨论了很久，然后说要去问产品 。我对 H 说：这个需求既然之前给 W 负责了，那就交给 W 去问吧，你看，这个是 W 负责的，我们 2 个讨论的这么火热 。这也是 1 个成长锻炼的机会 ，如果需求里的疑问 都是 H 和 我 找出来并找产品确认好

今天上午因为一个错误提示文案的问题，讨论了很久，估摸着有1H 。一直是开发跟我在讨论，产品没在群里说几句话。最后去了开发那里，讨论好最终结果，然后把结果告知产品。我提出最大的问题就是：产品需求阶段没有定下来，一般都是开发自己想一个合理的文案即可。可开发想的文案就不合理…每次都是一些很细碎的事讨论很久。下午新来没多久的产品发现了一个小问题，跑到我们的工位跟我们叙述一遍后，我们测试环境、生产环境都无法复现，跑过来什么素材也没给到我们，又是半小时无用功。琐碎的事最近有点多了，应该想想怎么样才可以让这样的琐事

#百日千字计划# 跟着业内测试大佬开始：百字千日打卡 ，每天输出 100 字，连续坚持 1000 天，我看看我可以坚持多久 。前一阵时间，我们公司CEO给我们员工一人发了一本实体书《终身成长》。里面谈到：成长型思维模式者 与 固定型思维模式者 ，可以试着对号入座 。什么是固定型思维？就是认为自己的能力是固定不变的。拥有这种思维的人会急于证明自己有能力，需要被证明。一旦失败，就会认为自己是一个没有能力的人，从而放弃努力。什么是成长型思维？就是认为自己的能力是可以通过努力来改变的。拥有这种思维的人遇

测试圈内老徐发表了一篇公众号文章：标题：很闲，有点废了，略心慌；文章的第一句话：作为老员工，或者Leader，想让自己闲着，其实很简单；看到前几行时，我心想 ： 莫不是 给我装了监控 。 看到后文，发现我和老徐描述的还是有些差别。 有很大差别 。

前一阵子我们产品一直缺人，Leader打算招个实习生。在四月底，Leader和我说，已经招到了一位实习生，就叫她小白吧，是一个漂亮妹子，99年的，从来没有过测试经验；Leader说让我来做带教人，于是这也是我第一次带教测试实习生，我也解锁一个新的身份：带教人。

前言：不知道大家在测试流程中把 “用例评审”放在了什么样的“地位”。在我看来，用例评审是测试流程中不可或缺的一环。于是打算把 我司的用例评审写下来，我们的用例评审是怎么做的，也希望汲取一些其他公司优秀的经验，相互学习下~用例评审是什么自我理解：用例写完了之后，不代表这份用例写的都是正确的，场景覆盖是全的，需要在多方人员进行查漏补缺，所以我的理解是：用例评审是产品、开发、测试一起对写好的用例进行一个review的过程。如果用例都没有评审，直接去执行，可能会存在一些问题。用例评审参会人员产品、开发、测

昨天看到群里有一个小伙伴问出这样的问题：公司签署项目合同死亡日期线是10月1号（平台正式上线）项目上存在以下的几个问题:1，项目任务工作量太大，开发排期9月中旬才能完成开发(在不修改需求的情况)2…简而言之，就是 时间紧，工作量太大，该怎么办？整理了一下群里大家的回复：匿名K同学：需要制定明确的测试计划（分轻重缓急），并且拿出数据，以文档的形式邮件告知领导（最好开会讨论）；如强制上线，测试报告告知有哪些问题（不然测试背锅）。最重要的就是沟通：1.让大家知道这个项目的困难（时间不够，

自己目前是有这方面的困惑，将自己的这个问题问了组内的伙伴们，得到了不一样的解答。整理如下：HXT：了解deadline，在提测之前就和和开发沟通困难点和进度每天和产品经理反馈进度，注明开发提测delay协调产品和他相关Leader，给他相关的帮助 （a.分一些任务给其他人 b.解决技术难点）LM：如果开发进度缓慢，而你的任务被block，可以把自动化先搭起来，或者做一部分（帮助你 节省后面的测试执行时间）HMM：首先去了解一下为什么延迟有没有遇到什么困难，能不能帮助他一下他大

曾听过一段话：人的知识就好比一个圆圈，圆圈里面是已知的，圆圈外面是未知的。你知道的越多，圆圈也就越大。借此引出今天主题：如果“定位BUG”有等级的话，你是什么段位？刚开始测试时，我以为 能够定位前后端BUG就是定位BUG的天花板了 。当我可以准确定位前后端BUG后，发现 还有一个级别：那就是定位到前端/后端问题后，明确知道根本问题是什么导致的，截图给开发，让开发改~到达这个级别后，又发现还有更高的级别：定位到前端/后端问题后，明确知道根本问题是什么导致的，并且知道要改成什么，才是正确的。我目前

前一阵子。我和团队里的一个同事针对我们产品，建设了一个公共用例库 。建设公共用例库的目的：减少重复编写工作用例风格统一，减少遗漏目标提高管理端 用例编写 的效率这个公共用例库比较适用于我们产品“ 新增页面编写的用例的大部分用例”公共用例 ：单个页面可能涉及到的用例其中涉及模块：DB、权限、页面UI、列表、新建、编辑含用例条数：90+目前用例覆盖控件：列表涉及控件有：筛选器、搜索框、分页翻页、排序控件、日期控件、CheckBox等浮层表单涉及控件有：文本框（支持：字符串、正整数、数

2020.1.4是上班族 2021 年的第一个工作日。感觉 2020 年过去很快 。反思了一下自己的OKR：2020 年的OKR 有一些未完成的项，但在Q4 OKR有了一些实质性的进展 。原因是Q4的 OKR 根据季度划分，这样的 OKR 更有导向作用 。在回想自己的Q4 的OKR进度的时候，感觉自己是做了一些东西的，但好像最后完成的百分比却不是很高。所以打算今后记录一下自己每日的复盘，以及OKR的完成情况，更加督促自己提前完成自己的OKR。在2021年，OKR也都是会根据季度来划分。20

前一阵子，参与到一个新的产品做测试工作。记录一下进入到一个新的产品，如何开展测试工作。

大家好呀 ，请教大家一个问题哈，你们可以看看你们是否遇到过相似的场景呢 ？背景后天就要发布了 ，这时候开发告诉你一件事，在修复BUG的时候，发现了另外一个问题；并且自己直接已经修复了 ，希望你回归一下 。在开发看来，他修复的不过是顺手的事情并且这个问题很小，但我们是需要回归很多地方的，在离发布如此近的时间，回归验证这块改动点时间是比较紧张的 。开发的观点：1、 顺手改了2、我可以告诉你要回归哪些点3、这个就是一个小问题，你们测试测试下就OK了测试的观点：1、这个并不是这个迭代中的测试项，开发