已有 3175 人访问
测试否 ID.15010
博客(8)
测试否的博客
在分享测试用例评审的内容之前，我们可以先思考下为什么要组织测试用例评审会议呢？一、评审目的一般来说，参加测试用例评审的人员包括对应项目的产品人员、设计人员、开发人员和测试人员。                【爱测角】图1-1测试用例评审相关人员测试用例评审会议的发起者一般是测试人员，既然我们是发起者，那我们发起这个会议的目的是什么呢？首先，在测试用例设计过程中，我们可能会对某些需求点存在
145°/1457 人阅读/131 人点赞/0 条评论
回顾校园生活中，我们参加每一场考试后都会对错题进行分析总结并补缺补漏，以便能更好地去应对更重要的考试。回到软件系统开发中，我们记录和跟踪缺陷的目的是什么，仅仅是为了在软件系统开发过程中跟踪Bug直至修复么？应该不止于此。我们也可以对项目缺陷进行分析，分析其共性进而分类，从而建立项目的“错题集”，为下一次“考试”提供宝贵的经验。 如图1-1所示，通常一条缺陷记录会包含缺陷编号、缺陷标题、状态、缺陷描
161°/1617 人阅读/131 人点赞/0 条评论
《漫谈测试成长之探索——测试文档》一文阐述了我们可以从项目维度去整理测试相关的文档来提升自己，本文将从测试排期方面探索成长方向。 我们知道，对于做一件事，我们要有计划，要知道目标，要记得看时间。这里的时间对应到软件测试中就是与测试相关的时间节点。如图1-1所示，在以往工作中，作为一线测试执行者，我们一般会关注开发计划提测时间、测试计划开始时间、测试计划完成时间和需求计划发布时间。但是，经验告诉我们
256°/2569 人阅读/139 人点赞/0 条评论
随着敏捷开发模式的流行，版本交付周期缩短，测试工期压缩，一线测试工程师不仅工作节奏加快，而且工作量也在加大。但是，我们的成长速度似乎越来越慢。这是为什么呢？大环境下，我们都陷入了一个非成长型的恶性循环，随着项目迭代频率加快，循环的回归测试和发布执行等工作不断地消耗着我们的精力和成长动力，我们都想跳出这个循环，却并没有那么顺利。              图1-1 敏捷下的测试循环那么，我们就这样躺
175°/1750 人阅读/131 人点赞/0 条评论
在《漫谈软件缺陷管理的实践》一文中，文章介绍了缺陷管理落地到实际工作中的一种形式。本文将分享其呈现效果的自动化实践方案。 一、自动化实践方案缺陷管理的自动化实践可以分为四个步骤：设计数据指标、规范数据源、数据处理自动化和程序部署。 1. 设计数据指标首先，我们需要设计缺陷相关的数据指标。这里，我们主要关注的指标有缺陷数量，缺陷处理进度和项目缺陷的多维度统计结果。同时，我们还可以设计缺陷相关指标的监
140°/1408 人阅读/131 人点赞/0 条评论
​在《漫谈软件缺陷管理的价值》一文中，文章分享了软件缺陷管理的过程价值和结果价值，并介绍了有哪些实践可以发挥这些价值。那么，这些实践落地到实际工作中可以是什么样子的呢？ 一、缺陷管理的实践如图1-1所示，图片展示的是钉钉App的消息机器人推送的缺陷过程数据。该信息展示的信息包括：当前时间、版本交付倒计时时间、版本Bug总数、待修复Bug数、已修复待验证Bug数和查看详情的链接入口。为什么设计要推送
145°/1454 人阅读/131 人点赞/0 条评论
在本文之前，笔者曾分享过一篇关于质量保障流程的文章《漫谈项目质量保障——协作流程》，文章简述了笔者参与的项目协作流程，同时对流程中一些不同寻常的协作节点进行阐述。由于多种原因限制，之前分享的流程存在一定的不完整性，所以本文将继续分享《漫谈项目质量保障——协作流程》优化后的版本。 初版的协作流程如图1-1所示，整个流程涉及了产品人员、UI设计人员、测试人员、开发人员和项目管理员五种角色，并设计了未开
195°/1944 人阅读/141 人点赞/1 条评论
  最近在论坛看到一些有关项目复盘的分享，有不少的收获，所以决定也把以往的项目总结分享出来，希望对同行能有所帮助，也期待能看到更多的分享。 一、项目简介  如图1-1，展示了笔者参与项目业务流程的简化模型，业务可以简化为两个流程：用户信息认证流程和额度评估流程。在用户信息认证流程里，用户在App端进行信息认证项的认证，传递用户信息数据到额度评估系统，在额度评估流程里，额度评估系统对用户提交的数据进
220°/2200 人阅读/131 人点赞/0 条评论