qq_34078572的博客

当你来到一个项目不规范的技术团队，你会怎么处理呢？**问题**流程不规范没有需求评审和设计评审，需求经常是业务或者项目经理直接跟开发提，有时候开发自己都不明白需求，糊里糊涂地就要开发，也没有设计评审，开发想怎么设计就怎么设计，代码质量差。有时候下游或者上游开发并没有接到需求，然后这边开发完给到测试，测试也一脸懵逼。没有计划上线时间不是根据开发和测试同学排期和评估来定，而是业务和项目经理说了算。开发完了就跟测试同学说一声，有这么个需求，这个需求今晚/这周上线，你测一下，好像测试是个很随意的工作，

我们测试中发现或提交的bug时常出现被开发同学“怼的现象出现,所以我会先自身找问题,为什么会被怼”,怎么才能不被“怼”,然后怎么才能让他认清沉默“嗯~ ,确实,这是个bug”1、Bug描述缺少辅助截图:2、用词不准确到位:3、

在软件开发过程当中，一旦软件代码做了修改，就有可能引入新的问题，所以这个时候就需要把已经完成了的验证用例重新跑一下，以确保代码的修改没有对已经验证过的功能造成影响。我们把这一个过程叫做回归测试。 一般的软件测试流程是后期快速迭代的，bug在后期是快速收敛的，debug和测试的周期也是越来越短，频率是越来越高，譬如说第一轮测试需要花上10天跑用例，那么到后期就没那么长的时间，可能就是1~2天的测试时间，在后期有时候一天就有一个新版本，这时候就要求测试人员能快速的进行一轮回归测试。 一般来...

一般出现这种情况的时候我们就会告诉开发刚才我操作到XXX步骤时候奔溃了，这时候开发就会按照我们说的步骤去复现，遇见能复现的崩溃还好，开发就能看见奔溃的日志，然后根据日志的说明进行更改。如果这个操作是不能复现，偶现的呢？这时候告诉开发开发也不能重现这个崩溃，所以说测试人员如果能够在测试的时候实时监控APP的日志，那么一发生奔溃就可以提供安卓APP崩溃日志给开发来定位问题的原因。。因为之前也遇见过这样的问题，所以去网上找了很多种获取日志的方法，对比之下选择了其中一种，现拿来做分享，希望对测试同学能有小小的帮助

小程序的测试也可以主要分为4个方面，即功能测试，兼容性测试，性能测试，后台接口测试。对于安全性测试由于小程序集成在微信客户端内，相比于传统的网页来说安全性能够更有保障。只要在后台接口测试上保证数据的安全性，客户端的安全性由微信的应用程序来替我们保证。1、功能测试功能测试跟传统的网络端的功能测试类似，这里不再赘述。用例设计方法等跟需求相关性较大。我们的小程序和APP端紧密相关，数据同步，所以在测试的过程中需要核对APP端和小程序中的数据同步功能。2、兼容性测试包括操作系统兼容性、屏幕兼容性、微信兼容性

任何不能赋于伙伴力量的 Review 都是耍流氓~Review得有三大原则：1．必须以对方为主，其中保持三分提问，七分倾听，以支持协助为初心。2．简单来说就是进门有准备，出门有力量，过程有苦痛，每次有期待。3．敢于棒喝，乐于赞美，丑话当先，立场坚定，信息明确。...

H2在v8.3.0.0迭代新增了手机号一键登录功能，除了单卡常规测试外，还有双卡测试时发现的问题留个记录。前提：xr手机，是iphone手机双卡双待或者iphone全面屏手机，手机只插1张联通卡步骤：首次安装APP，进入app以后，在欢迎页面点击“立即开始”。结果：进入的页面，没有显示一键登录期望：有一键登录功能，进入手机号一键登录页面。原因：联通卡在双卡的返回的code有变更以及在双卡或者全面屏iphone XR 明明是单卡，但系统返回的系统是双卡信息，整体开发设计判断存在问题经

在线生成格式大小图片在线生成.jpg .png .gif .webp 不同格式的大小的图片 ，平时测试工作中有测试图片上传等模块，就可以用该工具进行生成不同类型的测试图片，遍历测试点，方便！地址：https://www.bejson.com/ui/imagehandler/OCR文字识别支持图片转文字 图片转Word 截屏提取文字 局部提取文字 证件文字提取 票据文字提取（作为测试平时用于图片或/PDF文件文字识别，直接生成word格式）地址：http://suo.im/5MN3QnLICEc

QA用例的Review有一段时间了，开会前都会问自己：“什么样的用例是一个好的用例？”，再左移一点，“什么样的Bug是一个好的bug？”，那既然有好的，那肯定就有不好的。虽场景不一，但特征方法总是聚合的。突然想，这算不算是QA的灵魂拷问，那就再来几问，后发散一下有感，脑图记录。如意金箍棒猥琐发育，别浪。...

v713版本前，测试组内部谈及用例等级P0、P1、P2如何划分问题，各人视角不同看法不一：1种需求主流程跑通的是P0用例，其他都是P1和P2。1种需求文档明确说明的且不复杂场景的是P0用例，其他异常是P1和P2。在H2做个尝试，于是在我名下先试行2个迭代版本，看下有什么变化，很快，2个迭代过去了，数据如下图：蓝色区域：试行用例前；白色区域：试行用例后；常规情况下，需求的bug数量受两方面波动（需求规模大小、开发代码和测试人员用例）。如上图，在相对用例数情况下，自v713版本开始，我新发现的bug数量

安利一款好用的文字识别工具。这款绿色免安装的小工具仅2M，集成了各大网站的ORC识别接口。启动后，双击或按F4键，框选需要识别的区域，即可返回该区域内的文字识别结果。可针对图片，不可复制的网页，二维码、PDF文档等等。。。。设置里可以设定分行、快捷键，还有简单的文字编辑器。同时还有翻译模式，功能多多。不能使用原因：1、缺少.net框架，最低需要安装.net4.0。2、快捷键冲突更换快捷键。3、出现按下截图键，屏幕放大情况的请右键属性，禁用dpi的显示缩放。如下图所示：4、如遇到无法识别，可

测试用例设计是测试人员必须掌握的基本技能之一，也是个难点之一。那么写好的测试用例如何去评估有效性呢？最近一直在思考这个问题，本来想年前来一篇的，但是一直偷懒，直到现在，网上的资料很多，这里就结合自己的思考简单谈谈自己的看法吧。1、从测试用例的形式分析首先，每个公司有每个公司的测试用例模板，如包括模块、子模块、优先级、前置条件、操作步骤、操作数据、预期结果、用例状态、缺陷严重级、概率、实际测试结果、备注；字体格式以及字体大小；测试用例的设计是按照之前约定的按流程来设计还是按照模块设计；测试用例放置的位置以

其实大致过程就是，逐渐用UI或API自动化测试替换一些常规的测试，然后就挤出来一些时间，用这些时间去学习更高阶的方法，然后再逐渐替代，最后就完全高阶的方式。差不多就和开发一样，是一个逐步迭代的过程，然后因为是良性循环，其实时间会越来越多的~至于一开始怎么搞，像已经落地的TW工具来做我们自己的APP测试，对获取到的界面内容做元素匹配，来完成一些常规的功能性测试。然后再慢慢搞，这样子一开始可以省下5个、20个、100个小功能测试（如打开APP，账号登录退出，查看一个计划，收藏1个计划，播放一个课程，发

写在前面的话:测试人要用直观的数据，客观的阐述。1.按时。11.延期，延期多久，为什么延期，什么人，从哪个阶段开始延期，有没采取补救措施，风险预估工作有无到位，有无告知产品运营调整造成连锁问题。12.按时，开发测试各阶段是否如预期，有无阻塞。13.提前，提前多久，提前原因，什么人，阶段，有无提前告知产品运营调整步伐。2.质量。21.缺陷比较，（各端，上1-2个版本，百分比，包含发布后线上事故缺陷），p1以上。22.人员比较，包含测试人自身的not a bug（所有人的缺陷数量，修复时间，质量返

windows经常会推送一些更新补丁，很多童学都采用默认自动安装的方式来更新补丁，简单又方便，但有时也会出现更新失败的情况，最近，就有小伙伴的电脑开机后无法进入桌面，一直在启动页面循环。造成的原因大致三种：1.系统更新补丁包错误导致，概率小基本忽略。2.系统更新补丁包由于兼容问题，安装失败进入还原且还原失败。3.系统更新补丁包配置中，电脑意外重启或关机。一、win7解决方式如下：1.可以尝试按F8键进入安全模式。如能进去，那就再重启电脑，继续按F8键，此时可以选择使用【“最后一次正确的配置”启动

一、PICT简介 PICT工具就是在微软公司内部使用的一款成对组合的命令行生成工具，PICT全称(Pairwise Independent Combinatorial Testing tool)，它可以有效地按照两两测试的原理,进行测试用例设计.在使用PICT时,需要输入与测试用例相关的所有参数,以达到全面覆盖的效果。二、PICT安装 普通的安装过程，没有什么需要特别注意的地方。安装包已随附件发送。我的PICT安装目录是D:\Program Files (x86)\PICT。三、PICT使用

写在前面的话，自动化不能完全替代手工，且和QA一样是共同辅助(指导)咱们的RD进行开发。????之前:回想之前QA的状态:需求，模块测试，系统测试，仿真线上回归，发版遍历。新需求，新模块测试，系统测试，仿真线上回归，发新版遍历……大量的手工回归、高重复性的工作一次又一次拖着发版时间，消耗掉测试人员的热情和怼新功能的专注度，落地自动化迫在眉睫。现在:ui自动化已实施了5个版本，功能覆盖80%。接口自动化脚本前期完成127个，正进行返回值断言工作。测试人员有更多精力放在新内容和测试技能成长上。脚本的维护通