为什么软件明明通过了各种级别的测试，在交付给用户之后仍然会出现问题，令用户不满？这可能是我们的测试依据出现了问题。通常测试的依据是系统设计师加工过的需求，而这个需求并没有反映用户的使用环境、使用场景和使用习惯，简而言之，就是所以，在需求分析过程中运行方案和场景的分析有助于完善软件需求，获得用户的真实需求。作为测试人员，则应实施基于客户视角的测试才能确保通过测试的软件顺利交付。在测试设计时，通常依据的是需求规格说明、设计说明，有些还会参考合同。

德鲁克说：“你如果无法度量它，就无法管理它。

扫码登录本质是解决将APP端的用户登录信息（通常是Token）通过扫码的形式安全稳定地同步给Web端。测试点包括哪些：1、页面基础功能；2、ticket的过期时间；3、ticket的唯一性，以及生成和加密方式；手机端已经进行过了登录，在访问手机端的服务器的时候，参数中都会携带一个用户的token， 服务器可以从中解析到用户信息这里从token中取值而不是手机端直接传userid是为了安全，直接传userid可能会被截获和修改， token是加密的，被修改的风险会小很多。

测试接触不到第一手需求，了解到的需求都是分解过的需求，该怎么做才能保证不漏测？这个问题还是挺普遍的。因为随着分工越来越精细，每个人可能只能接触到全局的一部分，再加上信息传递过程中的信息丢失，就很容易造成如下场景。看完是不是觉得，这不就是我们项目的写照吗？今天我们先来看看如何避免这类问题：1、使用文档承载 客户原始需求。不管是什么文档，我们必须要有一个记录客户最原始需求的地方。确保沟通过程中的信息不丢失。2、如果产品没有，测试就要积极主动找项目经理去沟通，或者找销售/售后去积极了解这个需求。

新业务的学习，是一个不断积累的过程，只有在经过不停地学习、实践、问题排查，这样的重复过程后，才会加深我们对业务的理解。随着业务知识、系统架构等方面的提升，也会反哺我们对业务的了解，从而达到陌生到熟悉的变化。最后，再送大家一句话：好记性不如烂笔头，随时记录，思考，梳理，重构，会有惊喜噢！

有测试员抱怨开发很糟糕，但我们没办法要求开发在会写代码的同时还要把代码写好，没有过多的bug，因为这就是我们的工作；测试员吐槽自己的老板很较真，但我们没办法拒绝领导们的批评指责，因为批评代表我们还有继续提升的价值……除了批评外，我想每个测试员都怕被无时无刻的刨根究底，无止无休的问长问短。作为一名软件测试员，工作有时候挺苦逼的，有时候想说：我太难了……如果你问我做测试做了这么久最怕被问什么，我想一定是这句：测得怎么样了？除此之外还有：还有问题吗？什么时候能测试结束啊？如何对测试人员进行考核啊？

最近有小伙伴问了一个问题：他所在的测试团队规模比较大，有 50 多个人，分成了 4 ~ 5 个小组。这位同学觉得自己的技术能力在团队里应该属于比较不错的，但疑惑的是在几次组织架构调整中，直属领导一直没有让他来管理一个小组，而总是把机会给了别人。为此他感到十分苦恼，觉得是因为平时没有亲近领导的关系。走上管理岗位是很多人的追求，但大部分人未能如愿以偿。在我的职业生涯中，还遇到过很多类似上面的例子。所以今天我就以自己的经历，结合近十年的管理视角，给大家做个分享，希望能给有这方面困惑的读者带来一些帮助。

测试工作中，经常会遇到一些低概率出现的问题，如果再是个严重问题，那测试人员的压力无疑是很大的，一方面是因为低概率难以复现，另一面则是来自项目组的压力。很多测试新人，发现个bug兴奋的直拍大腿，然后啪一下甩给研发，很快哈，研发接住一看，问：日志呢？此时你两眼蒙圈，表示大意了，没有抓。只能重新搭建下环境，开始复现~~ （还有一种情况，是接了日志，但是没开启时间记录，也不是正确出招的方式。出现问题时，第一反应是看下当前日期，记录住问题出现的时间节点，做了什么操作；

最近在带新人了解项目，这已经不是第一次带新人，由此引发了我关于新进项目的测试人员如何能够快速介入一个新项目的思考。这里我特指的是项目已经运行一段周期，新进员工或其他项目测试人员中途进入该项目的情况。对于项目一启动，测试人员就加入的情况不在讨论范围之内。同时，我提到的项目也是一般意义上的BS架构项目或者App项目，对于完全硬件类项目或做编译器等的项目也不在讨论范围之内，我没有做过这些，就没有发言权。我觉得介入一个已启动的项目，就相当于画一个人物一样。

一般来说，当 Bug 跟踪系统上所有的 bug 都被关闭了以后，你会感到如释重负，终于可以松一口气了。当项目成功交付后，你是否感到大脑进入了疲惫期，上网，聊天，写自己感兴趣的小程序，项目已经结束，对于上个项目你已不愿去想它。既然距离下一个项目中间还有点时间，就找点轻松的活干吧，免得老板给你找些更受罪的事让你充分体会生活。“温故而知新”，这句古训总是不会错的，也可以帮你对项目的进行过程作个分析，总结，最好再将结果做个汇总或图标。老板一目了然，觉得你能够想到这点也实属难得，而且自己也能有些收获。

这篇文章只是蜻蜓点水似的描述了一下「精准测试」，其实真正的精准测试业远远不止这些，有很多奇技淫巧帮助我们提高测试质量。在很多公司，测试团队对于系统上线前，最核心的做法就是「执行全量的回归测试」。似乎回归测试已经包打一切了，我还需要精准测试吗？答案是肯定的。我们的资源不一定足够、我们所处的环境充满着不确定性，如何更高效的利用资源、如何让更多要素变成确定的，是整个行业对测试工程师更高的要求。

互联网测试少，测试研发比大概在1:5，再加上产品再使足了劲上需求，导致了测试需求量大，测试准备时间短，从而降低了上线质量。那么如何解决呢？测试是质量负责人，要对平台质量负责，于是就需要做一些取舍，挑重点测。因此，在时间不充裕的前提下，质量负责人要有能力评估需求的风险等级，给出一个令人信服的不测理由。具体来说要做两件事情，。互联网测试少可太常见了，测试研发比大概在1:5，再加上产品再使足了劲上需求，导致每天晚上都有测试唉声叹气，今天加班测呗，但加班真的能保证质量吗？我看未必！

工作中经常会遇到测试时间不够充分的情况，当测试时间不足的情况下，如何做到不延误测试进度，又能保证测试质量？1、根据测试目标和需求，确定测试的优先级，首先测试最重要和核心的功能和场景。确保关键功能的正确和稳定，而非关键的功能可以延后测试或者通过简化测试流程来加速测试进度。2、使用自动化测试工具和框架，可以快速执行大量的测试用例，并减少人工测试的工作量。选择关键功能、常规功能和重复性的测试用例进行自动化，以提高测试效率和覆盖率。

首先是原来这种模式下的需求文档，包括该需求的历史性的一些梳理文档，以及该需求的迭代性需求文档，还可以参考UI图。

春节匆匆而过，打工人陆续回到了工作岗位又开始卷了起来。小酋也一样，已经返岗几天，今天趁着节后综合症消去大半又该聊点什么了。最近在做一个视频AI分析项目的测试验收，今天就围绕“如何做好外包项目的测试验收”为题，谈谈个人的看法吧。这年头，甲方与乙方没有绝对强弱之分，如经历过甲方做成孙子，乙方当大爷的，通常强弱之分都取决于前期商务合同条款。如果前期商务合同没约定好，可能身为“孙子”的乙方拿到合同和首款后，就成了大爷。

在测试过程中发现的所有问题，异常情况，发现程序开发人员易犯，常犯的错误，各种有价值的经验教训，使用系统和操作数据库时发现或者学到的技巧，使用测试工具时的心得等等，都可以随手记录下来。这些都将是今后工作中可以参照的珍贵资料，同时也会成为自己的宝贵经验。

知名公司的混沌工程实践有：谷歌的DiRT计划（灾难恢复测试，已经进行了数千次），Slack的灾难剧场，微软云平台混沌工程等。很多公司把混沌工程实验做成“Game Day”，用游戏比赛的有趣竞争状态来进行混沌实验，而不是制造如临大敌的气氛。混沌工程的系统方法、原则和步骤，不止应用于分布式大型软件，也应用于软硬件一体的互联系统，如汽车自动驾驶系统。混沌工程也应用到了网络安全领域。本文详细介绍各大企业实践混沌工程的优秀流程，经验教训，人为阻力，人和组织的能力提升，我们能从中学习到一些宝贵的洞见。

对于BUG分析，测试人员再熟悉不过了。但如果是面对大量的BUG，要如何有效的分析呢？有什么好的方案和行动项？今天聊聊这个话题。和。总结分析bug和测试过程问题，形成的质量报告不仅能准确评估过去产品质量，还能为未来产品提出改进建议，持续推进产品质量的不断提高和完善。众所周知，早期发现并修复bug所需的资源更少。因此，我们应该尽早预防和发现bug，而不仅仅是修复它们。适当借鉴过去的经验是一种较好的预防bug方法。这，是我们进行BUG分析的原始动力，也是让我们不迷失在茫茫BUG之海中的锚点。

几乎每一位测试员，都会因为自己发现了一个bug而沾沾自喜，然后迫不及待地报bug。此时，恨不得有个喇叭，在整个办公室广而告之一下，实际上这样的行为并不可取，因为软件开发人员最怕的就是思路被打断，他们进入心流状态（心理学术语，指一种人们在专注进行某行为时所表现的心理状态）是需要时间的，这样会严重影响他们的工作效率。下面列出，测试人员在报bug方面最常见的10条错误。Bug描述题不对意，说的是A，而真正的bug是B，让开发人员看了一头雾水。

最近几年，随着大数据、人工智能等领域的快速发展，算法受到前所未有的重视，算法测试也随之兴起。为了让大家能对算法测试有个初步的了解，这篇文章将对“如何做算法测试”进行梳理，大纲如下：1、算法测试测什么？2、算法测试如何做？3、算法测试的一个真实案例4、答疑解惑先来看几个大家耳熟能详的算法应用成功的例子：1、阿尔法围棋机器人，打败了人类棋手，其实就是运用了复杂的人工智能算法；2、今日头条、抖音等APP，使用了兴趣算法推荐，推送的都是你感兴趣的内容；

在测试过程中发现的所有问题，异常情况，发现程序开发人员易犯，常犯的错误，各种有价值的经验教训，使用系统和操作数据库时发现或者学到的技巧，使用测试工具时的心得等等，都可以随手记录下来。这些都将是今后工作中可以参照的珍贵资料，同时也会成为自己的宝贵经验。

除了考虑新系统的规则变化，还要考虑旧数据迁移后需要进行规则适配，例如旧系统没有，新系统有的字段，验证是否给到正确的默认值。保证旧系统数据迁移后业务的可用性与连续性，避免迁移后需重新回滚测试。接下来，我们将详细介绍数据迁移的测试策略及测试实施，话不多说，上干货~

最近公司的新产品经历了几个版本的开发，终于初具模型，测试团队决定近期做一次回归测试。公司一直是敏捷开发模式，以需求卡进行一次次迭代，几百张需求卡如何界定回归测试范围也是伤透了脑筋，经过一番讨论，确定了以下方案。需要确定本次需求变更直接影响到的功能模块和代码，这些部分必须纳入回归测试范围。此外，也需要考虑一级或二级跨模块和接口的影响。一些业务关键、涉及金融等安全性要求高的功能模块，即使未直接涉及需求变更，也需要高频回归。这些模块的回归测试范围需要不断扩大。

目前关于云文档的业务还是挺多的，相信出去面试的同学，大多会遇到这道高频软件测试面试题：文件上传下载测试点。今天向大家分享下，希望对大家有所启发。上传文件中断网，网络恢复后，看文件是否继续上传。下载后的文件，在本地能否正常打开，与上传的文件进行对比，是否保持一致。单击下载是提示下载还是在页面打开，如果直接打开，页面内容需要正常显示。后台设置了下载权限的文件需要进行控制，例如需要积分下载/登录下载/回复下载等等。一个文件重复下载到相同的目录，保存到本地是否会自动在文件名后面加后缀进行区别，例如1、2等数字。

先写一个简单的python函数，找chatgpt写单元测试：这个结果已经超出我预期了，一个普通的单元测试感觉已经成型了，而且它还理解了“坐标”和“平面”。不过有小问题，注释是不对的，两个点不可能不再同一个平面上。执行这个测试函数，最后一个assert是通不过的。虽然它说修正了，但是实际上是越改越错。我没说，参数的第一个值是行号，它居然能“理解”了。

常常在思考：同样背景，同样学历的人，为什么有的人路越走越宽，而有的人路越走越窄？不能简单归结于性格和运气，看似偶然实则必然。学习才能使我们内心强壮，充满自信。然而，不仅需要学习，还得善于学习，才能让我们自信常在。何为善于学习？这是一门大学问，简单来说就是有一套适合自己的高效学习方式方法，能去芜存菁，举一反三，并把知识转化为能力。在这十多年，我接触过几个从小学、初中就出来混社会，但做到公司副总裁，公司CEO，自主创业的同事和朋友。

这是一个基于Python语言的接口自动化测试框架。主要使用了pytest测试框架和allure测试报告框架，并结合log日志、yaml配置文件和mysql数据库断言来实现接口自动化测试。以下是该框架的主要特点：使用pytest测试框架进行测试用例的编写和执行，支持fixture、参数化等高级功能。使用allure测试报告框架生成美观的测试报告，包括测试结果统计、用例执行历史、测试用例详情等。使用log日志记录测试用例执行过程中的日志信息，便于后续调试。

根据我的经验，做单接口压测，用jmeter完全没问题；如果做页面压测，结果同样具有参考性，能反应大部分性能问题；如果要获得更准确的结果可以考虑其他工具，如熟知的loadrunner。

Monkey测试，是Android自动化测试的一种手段，Monkey测试本身非常简单，Android SDK 工具支持adb Shell命令，实现模拟用户的按键输入，触摸屏输入，手势输入等操作，去发现应用隐藏的严重问题。现在线上有很多云测真机平台，平台上基本都支持Monkey测试服务（多数平台收费），同时利用平台上不同的测试机型发现被测应用的稳定性和健壮性问题。

你见过的这里都有，开源Web性能测试工具集合：1、。这个也不用多介绍，基本属于做过Web性能测试都会接触的工具。Apache旗下的开源项目，属于一个Java桌面应用程序。优势是开源免费，扩展能力强。自身性能是硬伤。2、。Web性能测试的蝗药师，开源免费，并发能力强。特点：使用纯粹的Python编写脚本；单机可支持千级并发压力，且支持分布式；Web管理界面；可以测试任何系统；简单耐玩。3、。Grinder是Java开发的负载测试框架，开源免费。支持录制、修改、运行方式的性能测试。

阅读Faker的源码可以很容易发现，Faker实际是维护了一个“数据库”，这个“数据库”强大在做了很多Localized的处理和兼容。此外，

TestNG是一个开源自动化测试工具，TestNG源于Junit，最初用来做单元测试，可支持异常测试，忽略测试，超时测试，参数化测试和依赖测试。除了单元测试，。随着企业内部自动化资产的持续积累以及持续集成的推进，对自动化测试的运行速度要求越来越高，某些应用的自动化测试用例可能多达几千条，如何加速这些自动化用例的运行速度，让自动化落实到每一次版本变更和持续集成当中，是一个需要解决的问题。TestNG通过对多线程的支持提供了加速代码运行的有效方式，

总的来说，开发者对于puppeteer的热情还是很高的，而且puppeteer的更新频率很快，整体生态环境是健康和谐的。对于大多数同学来说，只需要简单的理解，puppeteer可以实现。

Mock 是一项特殊的测试技巧，可以在没有依赖项的情况下进行单元测试。通常情况下，Mock 与其他方法的主要区别就是，用于取代代码依赖项的模拟对象允许设置期望值。简而言之，Mock 就是创建了一个对象，模拟真实对象的行为。

什么是断言？断言——就是结果中的特定属性或值与预期做对比，如果一致，则用例通过，如果不一致，断言失败，用例失败。断言，是一个完整测试用例所不可或缺的一部分，没有断言的测试用例仅仅是测试步骤。​在介绍Postman断言之前，我们先测试接口：接口地址：https://www.v2ex.com/api/nodes/show.json?name=python使用 GET 方法：那么这个接口我们如何用Postman来进行断言呢？也很简单，用到Postman tests 这个模块。要执行断言脚本以验证请求返回的数据，使

维基百科解释：The HTTP Archive format, or HAR, is a JSON-formatted archive file format for logging of a web browser’s interaction with a site。简单理解就是记录浏览器请求的日志的文件。怎么获取HAR文件呢？一是可以通过Chrome的开发者工具获取，二可以通过一些软件获取，比如fiddler、Charles proxy等。这里我们使用Chrome来获取。

部分安卓，ios系统不支持fiddler，在我使用fiddler抓包安卓、IOS应用接口失败怎么办？有什么好的解决方案呢？最好的方式就是换一个抓包工具，这里推荐工具：whistle当然它也是有缺点的就是要配置运行依赖环境，whistle需要依赖于node。下面开始介绍如何安装使用（我这里为 win10 x64 系统）

从接到需求到完成第一次测试结果输出，我花了大概一天半的时间。整个过程比较顺利，但在真正实践过程中，也遇到了一些需要思考的点。比如：1、造业务数据时，很难遍历到所有查询条件集合，那么这时候，至少需要保证主业务完全覆盖。2、如何高效输出差异对比结果，比如只有存在差异时才输出请求参数、响应和差异点，让结果更好地被分析。3、分析结果时需要首先将问题归类总结，同样类型的问题可能是一个原因导致的，将问题归类分析后能够更好地缩短和开发扯皮的时间。

项目设计之初或者是项目快要结束的时候，大佬就会问我们，这个服务性能测试的结果是什么，QPS 可以达到多少，RPS 又能达到多少？接口性能可以满足未来生产环境的实际情况吗？有没有自己测试过自己接口的吞吐量，等等。作为开发、测试人员，这些问题不仅仅是用来面试，还是实实在在的落地在实际工作中。很多项目上线初期用户量较小，表面上看是风平浪静，实则暗流涌动，慢慢的用户量上来之后，系统的瓶颈慢慢凸显。曾经挖的坑，最后还是要我们自己来填，若不能及时填上，可能整个产品就这么断送了。

测试用例这块知识、经验，小酋在前面陆续都讲完了。这章提供几种，作为这块知识的收尾。（主指功能测试用例模板）的内容通常包括测试目标（目的），需求标示（一般同需求文档中的需求编号对应），预置条件（如需要的网络配置、环境配置等），输入数据（如测试用到的账号等数据），测试步骤，预期结果，通过标准（什么情况下该用例执行成功）等。最初用例，都是用word文档进行编写的，内容细致、冗余较多但胜在可读性强，由他人执行也比较方便。如下图模板：PS：该用例模板也用于编写性能测试用例，用途非常广。