多则惑少则明
让天下没有难测试的项目。专注于测试开发领域,近9+年的工作实战经验,主攻方向包括:
0-1/中期/成熟类大型/复杂系统的业务测试
自动化测试平台&框架开发;
打造质量体系及沉淀质量方法论
个人邮箱zpphnkjxy@126.com
文章周末定时更新,其余时间不定时更新
展开
-
测试工程师与研发工程师之间的差别
对于测试工程师,研发工程师二者之间的差别,可能大家会有不同的想法:看法一:二者是隶属于不同的团队。 测试工程师是专门做测试的,研发工程师是专门做开发的,二者工作内容的关联性不大。看法二:有些测试工程师也写代码,比如测试代码,开发工具等等,研发工程师自己也做测试,冒烟等,所以二者有部分少量工作重叠交叉。看法三:有些职位title上是研发工程师,但其开发出来的产品是给测试工程师使用的。所以二者是甲方乙方关系。原创 2023-08-03 16:30:50 · 313 阅读 · 0 评论 -
质量指标——增量覆盖率是高好,还是低好?
增量覆盖率,应作为可选指标,对测试准出有帮助就用,无用甚至有妨碍时,不用即可原创 2023-03-07 21:50:08 · 311 阅读 · 0 评论 -
长链路+跨部门业务——稳定性保障讨论
长链路 + 跨部门业务下,如何保障链路稳定性原创 2023-01-04 22:58:55 · 564 阅读 · 0 评论 -
测试创新——QA能像研发一样改动业务代码吗?
QA能像研发一样改动业务代码吗?如果改动代码, 风险如何控制?原创 2022-12-29 20:48:32 · 615 阅读 · 1 评论 -
《软件开发本质论》笔记——软件开发的本质目标:「给最终用户/客户」尽早提供价值,经常提供价值
软件开发的本质目标: 「给最终用户/客户」尽早提供价值,经常提供价值;原创 2022-12-19 22:36:32 · 352 阅读 · 0 评论 -
测试人员的价值是什么——你好刀用在刀刃上了吗?
测试人员的价值是什么——你好刀用在刀刃上了吗?原创 2022-10-13 22:53:22 · 186 阅读 · 0 评论 -
定时任务保障
定时任务通常因为执行周期长、逻辑复杂、业务限制、涉及第三方等导致测试麻烦且效率低下,想知道联盟是如何通过链路解耦来实现业务线内[随时测试]、[快速测试]、[多次测试]吗?来一起看下广告联盟的实践与经验。 大家有更多保障手段与经验,也欢迎一起讨论与交流。原创 2022-10-10 20:38:50 · 550 阅读 · 0 评论 -
《QA离业务代码能有多近?》探索研发自测上线模式
没有因为自测需求引发的线上问题纳入自测的需求,业务风险及改动量、涉及自测场景 少且简单QA根据需求改动,对自测需求进行不同程度的介入: 100%自测、研发自测+QA CR代码 、研发自测+ QA准备用例、研发自测+ QA回归测试。原创 2022-08-23 22:31:09 · 263 阅读 · 0 评论 -
《QA离业务代码能有多近?》轻量级单元测试方案
业内常见的单元测试做的很重,导致编写&维护成本很大,整体落地ROI不高,最终导致团队成员落地意愿不高。 比如,需求一改,对应的单元测试的代码也得改,容易导致最后写单元测试的工作量比开发的工作量还要大。 那么能不能对单元测试进行“瘦身”,让单测的ROI高起来呢? ...原创 2022-08-10 20:17:23 · 259 阅读 · 0 评论 -
《QA离业务代码能有多近?》QA对业务代码进行可测性改造
一、可测性改造的目的项目测试过程中,不同的测试深度、测试广度,会面临不同程度的“不便”。比如,联盟有不少作为kafka的consumer消费方,由于线下上游业务线没有丰富的流量,或者压根没有流量,多数情况下,上游业务线不涉及改动。由于各个业务线的业务复杂度不同,技术实现不同,历史包袱也不同,那么在保持"原生态实现",不进行任何改造的情况下,面临的测试难点和痛点也会非常不同。2)上下文代码逻辑(上面逻辑,下面逻辑),涉及全量数据的加工处理,离线在线数据的diff等等,十分耗时,但本身未涉及改动。...原创 2022-07-27 22:22:56 · 234 阅读 · 0 评论 -
测试创新——QA CR代码收益
引言流程平台——从测试角度看code review_多则惑少则明的博客-CSDN博客直接bug;异常处理问题;可测性改造(CR后,评估使用哪种改造方式,改造的整体方案; );技术设计: 写死的逻辑;出问题时无法验证;打点监控;核心日志(如链路与第三方交互;出现问题时方便排查;)...原创 2022-05-16 12:46:04 · 407 阅读 · 0 评论 -
测试创新——大数据技术方案评审
目录原则1: T-1范围内的统计指标统计,提前规避潜在的性能问题原则2: 严重依赖第三方数据源的核心预估收入类数据,需要快速止血原则3: 考虑存量数据量级,提前规避潜在边界/性能/处理速度/数据倾斜问题原则4:评估数据质量检测,提前检测到异常数据并做异常处理原则5:评估技术实现与业务需求的匹配度原则6:评估技术实现可扩展性实现原则7: 评估当前技术实现下是否存在可测性问题大数据技术方案评审,提前规避问题:原则1: T-1范围内的统计指标统计,提前规避潜在的性能问题原创 2022-05-09 22:44:51 · 493 阅读 · 0 评论 -
测试创新——大数据链路
目录基建-环境1、链路特别长,且由不同团队负责2、线下数据流: 第三方上游无数据流3、链路加工的复杂4、数据正确性校验(数据加工、数据报表)5、可测性改造与易测性改造6、 线上质量卡点7、监控体系8、数据质量衡量基建-环境1)数据目前共有两套环境:staging 和预上线环境: 用于测试联调和自测(与线上隔离)2)稳定性维护: 随时可自测/联调/集成测试3) 数据量级: 存量数据尽可能同线上(如,风险允许下,可直接读取线上数据)1、链路特别长原创 2022-05-05 22:37:57 · 289 阅读 · 0 评论 -
《Google软件测试之道》三、好的经验沉淀
那些心有戚戚焉的经验: 诊断工具 调试用户问题效率,弥补开发人员所需的技术数据, 和普通用户反馈问题直接的鸿沟: 收集特定信息--》分析用户操作--》用户授权同意后(保护用户隐私信息)--》分析数据发送给合适的开发人员(客户支持团队)加速问题解决。 打上beta后,快速对外发布 一个产品的基本核心功能实现后,立刻对外发布使用,从用户那里得到真实反馈。单元测试测试开发工程师,一个开发角色,编写需求mock和fake工具,同时在开发人员不知道哪些地方需要单元测试的时候可以明确指出原创 2022-05-02 16:02:24 · 1673 阅读 · 0 评论 -
《Google软件测试之道》二、Google软件测试介绍
不久前,公司邀请外企大厂经验的大佬,分享Google的经验,本人特意问了一个问题:日常需求项目中,功能测试(测试用例的准备、执行)、性能测试等等,QA人员会参与执行吗?大佬回答:不会。是开发人员的工作几点自己的思考:Google能把这个质量是研发活动的一部分,彻底贯彻执行下去,需要从上到下的强大执行力。 国内的大小厂,据本人有限的所见所闻来说, 没有全部由开发人员编写用例、执行用例的实践 其实国内,开发和测试很大程度是2个团队负责,隔离开的。测试时 开发活动的下一个节点,...原创 2022-05-02 15:25:19 · 708 阅读 · 0 评论 -
《Google软件测试之道》一、弄清被测系统核心关注点在哪里
这点自己比较认同,无论是团队何种角色(产品同学、研发同学、QA同学、UI同学等等), 对于一个尚未熟悉的新系统,首先需要弄清楚什么是最重要的业务点,关注点最需要放在哪里:原创 2022-05-01 22:12:06 · 364 阅读 · 0 评论 -
怎样才能让需求无法如期顺利上线(六)上线阶段
一、背景伟大的数学家雅迪也经常说一句话:反过来想,总是反过来想。 1986年6月,查理·芒格在哈佛学校的毕业典礼上做了一场演讲,虽然内容短小,但是所用的修辞手法却让人振聋发聩。在毕业典礼上,芒格没有告诉即将毕业的同学如何得到幸福,而是告诉他们如何保证过上痛苦的生活。如果知道这些方法会带来痛苦,那么我们就可以最大程度上的去避免它。 同样地,这里按照逆向思维的思考方式,在互联网软件行业中,探探自己对”怎样才能让需求无法如期顺利上线“ 的一些感悟和思考。...原创 2021-10-12 13:06:26 · 194 阅读 · 0 评论 -
怎样才能让需求无法如期顺利上线(五)业务验收阶段
一、背景伟大的数学家雅迪也经常说一句话:反过来想,总是反过来想。 1986年6月,查理·芒格在哈佛学校的毕业典礼上做了一场演讲,虽然内容短小,但是所用的修辞手法却让人振聋发聩。在毕业典礼上,芒格没有告诉即将毕业的同学如何得到幸福,而是告诉他们如何保证过上痛苦的生活。如果知道这些方法会带来痛苦,那么我们就可以最大程度上的去避免它。 同样地,这里按照逆向思维的思考方式,在互联网软件行业中,探探自己对”怎样才能让需求无法如期顺利上线“ 的一些感悟和思考。...原创 2021-10-12 13:01:27 · 174 阅读 · 0 评论 -
怎样才能让需求无法如期顺利上线(四)集成测试阶段
一、背景 伟大的数学家雅迪也经常说一句话:反过来想,总是反过来想。 1986年6月,查理·芒格在哈佛学校的毕业典礼上做了一场演讲,虽然内容短小,但是所用的修辞手法却让人振聋发聩。在毕业典礼上,芒格没有告诉即将毕业的同学如何得到幸福,而是告诉他们如何保证过上痛苦的生活。如果知道这些方法会带来痛苦,那么我们就可以最大程度上的去避免它。 同样地,这里按照逆向思维的思考方式,在互联网软件行业中,探探自己对”怎样才能让需求无法如期顺利上线“ 的一些感悟和思考。...原创 2021-09-23 23:50:22 · 166 阅读 · 0 评论 -
怎样才能让需求无法如期顺利上线(三)开发阶段
目录一、背景二、开发阶段能做的事情1、以下情况,也千万别写技术方案2、技术实现方案千万别和 下游业务线同学、本业务线QA沟通3、API接口文档有修改时,千万别和 前端同学说4、在不熟悉现有代码实现的情况下,请直接接动手改5、代码编写完,千万别做什么单测,自测,上下游业务线联调测试6、影响团队其他角色时,请不要提前周知到人7、影响需求实现的点,不要提前通知QA,产品 给他们来个措手不及8、和其他业务线有交互逻辑时,千万不能让对方100%了解自己的技术实现及交互逻辑9原创 2021-09-15 13:08:01 · 217 阅读 · 0 评论 -
怎样才能让需求无法如期顺利上线(二)需求阶段
目录一、背景二、需求阶段能做的事情1、需求文档描述要尽可能粗2、不要考虑需求完整度,如不用考虑下游业务线3、不用考虑需求的可行性4、需求评审一定要快5、需求评审后要尽可能多需求变动6、将可以放到一个需求中实现的改动,尽可能多做拆分,增加改动频繁度和并发度三、写在最后一、背景伟大的数学家雅迪也经常说一句话:反过来想,总是反过来想。 1986年6月,查理·芒格在哈佛学校的毕业典礼上做了一场演讲,虽然内容短小,但是所用的修辞手法却让...原创 2021-09-14 13:22:59 · 168 阅读 · 0 评论 -
怎样才能让需求无法如期顺利上线(一)整体策略
目录一、背景二、让需求无法如期上线的整体策略一、背景伟大的数学家雅迪也经常说一句话:反过来想,总是反过来想。1986年6月,查理·芒格在哈佛学校的毕业典礼上做了一场演讲,虽然内容短小,但是所用的修辞手法却让人振聋发聩。在毕业典礼上,芒格没有告诉即将毕业的同学如何得到幸福,而是告诉他们如何保证过上痛苦的生活。如果知道这些方法会带来痛苦,那么我们就可以最大程度上的去避免它。 同样地,这里按照逆向思维的思考方式,在互联网软件行业中,探探自己对”...原创 2021-09-14 13:00:53 · 225 阅读 · 0 评论 -
测试创新——用户体验测试(UAT)
目录一、什么是用户体验测试(UAT)二、UAT进行的时机三、参与UAT的成员四、UAT的目标五、测试人员能否找到用户体验方面的bug?六、用户体验问题的几种典型形式一、什么是用户体验测试(UAT)在将产品交付客户之前处于用户角度进行的一系列体验使用,如:界面是否友好、操作是否流畅、功能是否达到用户使用要求等二、UAT进行的时机实际项目中,一般来说,UAT是在 测试人员完成测试之后,产品正式发布线上之前。 当然,个别特殊情况,可能在测试尾声的时候。三、参与UAT的.原创 2021-02-19 16:14:49 · 3645 阅读 · 0 评论 -
流程平台——从测试角度看code review
从维基百科的定义也不难看出 CR 目的:找出缺陷,提升代码质量,降低修复成本团队协作,知识共享,提升开发者技术希望尽早的code review,尽量降低“返工”的代价谷歌在Code Review方面执行的很好,尽管谷歌的工程师的平均研发水平都很高,但你会发现,只要是提交Review的代码,照样会有很多comment(修改意见)。即便自己觉得足够牛逼的代码,只要经过不停的推敲,都是有持续改进的空间的。只要对技术有追求的团队,就不能把开发当成外包:只要代码可以运行就提交,黑盒狠命测一把,验出b原创 2021-02-02 11:40:17 · 499 阅读 · 2 评论 -
产品迭代——敏捷模式的一点感悟
目录一、什么是敏捷二、敏捷团队项目举例感受到的优点三、敏捷的误区1、 与 质量的关系2、 缺陷的处理3、 项目过程文档4、 团队成员合作方式5、 敏捷适用范围6、 质量意识方面7、 安全生产方面四、个人经验:敏捷最让人满意的点五、是不是只有实行敏捷,才能高效呢一、什么是敏捷理论派角度看,敏捷宣言强调的敏捷软件开发的四个核心价值是:个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划个人理解:1)敏原创 2021-01-28 17:12:30 · 458 阅读 · 0 评论 -
缺陷/bug的价值探讨
目录前言一、代码实现类bug的危害1、 对于项目而言2、对于产品而言3、对于项目成员而言二、代码实现类bug隐藏的价值三、可以带着缺陷上线吗?四、 缺陷与质量关系前言缺陷的根本的原因很多,代码实现、需求原因、体验问题、环境问题、脏数据、测试人员操作问题、外部第三方系统报错... 在一个大型项目中,通常代码实现类bug会比较多,上线后直接导致线上故障的,大概率也是 代码实现问题。 所以这里以【代码实现类bug】为例, 一起探讨下bug的价值。bug给项目本身带来的.原创 2021-01-28 11:43:59 · 714 阅读 · 0 评论 -
流程平台——如何严卡提测质量
背景 要说QA同学经常比较苦恼的一件事,莫过于提测质量了。 因为提测质量的好坏,大大影响了测试质量、以及需要的测试时间、风险控制等。举个例子:业务A提测质量极差,主流程都不通。这个时候,QA通常的做法是执行提测打回流程,让开发同学继续自测; 硬着头皮不打回,边催促开发同学修复bug,边继续测试。 但无论QA同学怎么做,提测质量差已经成为事实了,这是任...原创 2021-01-26 20:29:01 · 666 阅读 · 0 评论 -
技术重构——其实是对自动化实现方案的大考
全量技术重构背景质量保障方案历史包袱原创 2020-12-09 21:13:05 · 423 阅读 · 0 评论 -
测试产品创新——服务端测试演变之路
目录1、原始阶段: 服务端单接口测试2、配置化阶段: web配置化自动化接口测试平台3、专项测试阶段:专项业务痛点4、测试服务化阶段:测试工具服务化5、测试大集成平台:测试大集成平台[纵向业务域]自动化实现优劣评价——以ROI为导向下的自动化评价指标[横向平台]平台价值评价1、原始阶段: 服务端单接口测试普遍采用的是Maven+Java+TestNg框架。 运行方式:testng执行方式 ...原创 2020-12-09 12:24:36 · 532 阅读 · 0 评论 -
资损防控浅谈——资损防控执行
https://zhoupeipei.blog.csdn.net/article/details/102884431如何识别资损风险从经验中学习——往年资损问题归类总结1. 发货错误:--监控单据拦截失败,上游拦截成功上游取消订单,仓做了出库;重复出库;商品数量不准确商品SN数量不准确2. 库存不一致--对账正品残品不准确上下游库存不一致仓内部3级账不平3、 未按时发货--监控预处理异常汇波卡点功能降级后xxx功能无法使用落表...原创 2020-12-07 19:23:38 · 2118 阅读 · 0 评论 -
测试创新——引流测试的边界在哪里
目录一、引流测试的优点二、边界三、天生缺陷四、核心问题五、业务适用性分析写在最后一、引流测试的优点线上海量的用户真实数据的特点:海量丰富多样二、边界1、 不常用的用户场景, 无法保证100%覆盖到,甚至极有可能无法覆盖到。 比如, TOB类产品, 某个操作不是必需的2、重复的流量,无疑增大了很多“冗余”量3、用户数据, 可能存在一些噪声数据,需要去噪;4、完全随机的取线上用户场景, 很大概率会造成场景的侧重, 需要有针对性的筛选、过滤三、天生缺原创 2020-12-01 20:53:29 · 491 阅读 · 0 评论 -
高可用架构——打造高稳定性产品
目录一、数学上表示数据的波动大小二、标准差的例子三、标准差的思路理解产品的稳定性四、产品长期稳定性的干扰因素五、保持产品的长期稳定性的几点思考一、数学上表示数据的波动大小数学上,要描述一组数据的波动大小, 通常用标准差。标准差就是为了描述数据集的波动大小而发明的比如一个班男生的平均身高是170cm,标准差是10cm,那么方差就是100cm^2。可以进行的比较简便的描述是本班男生身高分布是170±10cm,方差就无法做到这点。即: 标准差 = 波动性大小例子, 数据集x原创 2020-11-25 20:35:12 · 639 阅读 · 0 评论 -
测试创新——业务巡检平台心得
https://km.sankuai.com/page/32971846原创 2020-11-10 15:06:42 · 758 阅读 · 0 评论 -
系统高可用——高可用设计方法论浅析
目录一、系统高可用目标二、高可用设计的挑战三、高可用设计的方法论1、冗余设计避免单点故障2、应用的高可用性3、分布式架构下的可伸缩设计4、风险控制-自动化运维管控5、高可用评测一、系统高可用目标减少系统不能提供正常服务的时间,即系统可稳定&持续地正常提供服务。判断一个系统是不是实现了高可用目标,只要看下几点就可以了:线上是不是动不动就出现问题,甚至重大故障。因而,实现了高可用目标的系统,必须做到:1、 线上稳定可靠,尽可能少出现问题,即便在高压下.原创 2020-11-09 10:26:07 · 401 阅读 · 0 评论 -
仓储智能调度算法——质量保障方案
一、智能调度1、含义智能调度,目标是解决资源最优使用问题。将需求和可用资源进行最优匹配,以求达到资源利用的最优化。常见例子:外卖骑手接单、抢单;滴滴司机接单、抢单。以滴滴司机接单、抢单为例,目标是解决的是司机和乘客的匹配:1)司机侧: 达到资源利用最优化。 比如,离乘客距离,交通阻塞情况2)乘客侧:达到资源利用最优化。 比如,满足呼叫车型前提下尽可能减少等待时间3)平台侧: 达到资源利用最优化。 (个人猜想)比如, 司机经验,已接单数,好评等等。不能让司机一直接不到单;平台.原创 2020-10-23 13:33:12 · 1994 阅读 · 0 评论 -
测试创新——仓储质量问题解法
https://www.atatech.org/articles/128284原创 2020-10-19 12:15:26 · 229 阅读 · 0 评论 -
测试创新——自动化数据清理方案
目录一、面临的数据问题二、自动化数据清理方案规划1、自动化定时清理2、人工清理三、数据清理闭环思考四、实战-仓储数据清理方案1、清理方案概述2、清理方案实现一、面临的数据问题根本原因:未完结的数据量过多,直接阻塞或影响正常的业务测试。问题描述:操作timeout或根本无法操作二、自动化数据清理方案规划数据日常清理需要满足如下需求:1、自动化定时清理针对日常新增的未完结数据, 需要定时清理;但清理时,需要重点考虑如下问题:1)数据清理...原创 2020-10-19 10:57:32 · 1601 阅读 · 0 评论 -
打造强大的质量团队——典型测试用例集
一、前言测试用例,可以说是质量的保障中最关键的一环。 测试用例中没有的内容,可以说99%的情况下后续测试执行的时候,不会覆盖。当然不排除某些情况下,突发灵感,想起某些测试场景, 并将其加入测试用例中。但这是概率事件,非必然事件。测试用例——广发意义上的,无论谁执行;典型测试用例的用途: 无论谁在编写测试用例(新手、老手、哪怕是开发同学),保障测试用例的场景覆盖二、测试用例准备的难点说起难点, 不妨看下以下测试用例的套路:需求上x1需求点——对应几条测试用例;需求上x2需求点——.原创 2020-10-10 13:28:18 · 403 阅读 · 0 评论 -
测试创新——面临的跨多团队业务下项目的难点与痛点
目录一、背景二、项目痛点和难点1、 巨大的沟通成本2、巨大的全链路联调成本3、整体加大 研发难度4、整体加大测试难度5、技术重构、架构升级、融合时业务场景梳理难度大6、整体项目时间跨度大,引入不可控风险巨多一、背景之前写过测试创新——长链路+复杂业务下的自动化测试痛点与难点, 接下来,将介绍下在长链路+复杂业务下, 需要跨多个团队协作的业务在的自动化测试痛点与难点。跨多个团队协作项目的整体特点:1、通常涉及若干个(>=2)域一起协同作业。例如,长链...原创 2020-09-17 21:36:59 · 832 阅读 · 0 评论 -
故障治理思考——稳定性因素分析
目录一、引言二、稳定性因素分析1、技术实现技术实现-DB依赖技术实现-RPC接口技术实现-缓存技术实现-消息技术实现-定时任务技术实现-开关技术实现-监控技术实现-灰度2、暴露手段暴露手段-测试广度&深度暴露手段-提升效率暴露手段-质量闭环暴露手段-提升质量思维3、应急响应4、流程机制三、系统自检一、引言确保系统的稳定性,可以说是所有高质量产品都应该保证的。换句话说, 一个经常由于产品本身不稳定,而影响用户体验.原创 2020-09-16 20:51:27 · 385 阅读 · 0 评论