Teamo_mc的博客

功能测试人员的核心竞争力在这儿

作为测试，给我们一个关键词“登录”，我们可能想到的用例设计更多的是什么用户名、密码校验是否合法、是否为空、是否正确等等之类的场景，但在如今信息化的时代，“登录安全”已经是一个很热门且普遍的的话题了，今天给大家简单分享一下个人了解到的关于「登录安全」基础知识。在了解登录安全之前，给大家普及两个基础概念：“撞库”和“防撞库”；百度到的原文介绍是：“撞库是黑客通过收集互联网已泄露的用户和密码信息，生成对应的字典表，尝试批量登陆其他网站后，得到一系列可以登录的用户。并且很多用户在不同网站使用的是相同的帐号密码，因此

从测试的角度，开展哪些方面测试？ui检测对比ui效果图，进行ui细节校验字段规则校验校验字段的必填、非必填、输入合法、输入不合法等校验；相关提示的文案内容业务逻辑校验正向逻辑：正向业务流程逆向逻辑：反向业务流程前后台交互：多个入口的情况下对同一条数据进行操作，数据是否保持同步；场景： 前后台交互场景，例如支付的支持用户前端和财务后台操作同一笔收款单，则进行前后台数据操作结果同步。例如：财务后台是否支持修改/取消app端新建的收款单，反之财务后台新建的收款...

http/https在哪层？http/https在应用层、tcp在传输层、ip在网络层接口请求有哪几种：http/https：get、post、put、deletepost请求参数由几种类型：主要有四种方式： application/x-www-form-urlencoded（数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL 转码） multipart/form-data：二进制编码，数据一般以文件...

第一步：先判断是前端还是后端的问题，如果是接口请求响应数据是正常的，则进一步定位前端问题第二部：后端接口请求异常，则可通过状态码进行判断400--请求语法错误，也就是前后端语法定义不一致401--未授权403--服务端拒绝访问404--资源不存在500--服务器内部错误如果遇到磁盘满了，就需要看应用程序是否活着，如果活着则返回500（服务器处理异常），若是应用程序已经死了，则返回400资源不存在了...

测试用例阶段场景用例覆盖--增加开发对需求的全局理解深度 已确认优化需求重点提醒--确保开发和测试对需求的信息同步 提供开发自测用例--增加开发自测的认知 在测试用例评审阶段，也就是程序开发阶段，用例覆盖率尽可能的全面，能进一步提高开发设计方法或对业务逻辑的理解，减少不必要的缺陷产生测试阶段代码扫描/错误监测：sonar声呐代码扫描工具，检测开发代码一些常规的语法规则错误；bugly检测app端运行过程中的产生的奔溃、空指针等错误；或者其他的工具 开发自测用例：跟进开发自测用例完...

在工作过程中相信很多人都或多或少的知道甚至使用过postman或jmeter等工具做接口测试，那么postman/jmeter这个工具是怎么来的呢？今天我就带大家初步实践写一个简单的类似postman的接口测试工具。本文主要利用pyside2+python设计一个简单的接口测试工具，并打包成exe文件，通过这一系列实践，既能将自己写好的工具以图形界面的形式提供给他人使用，又能防止源代码泄漏。了解常用的GUI库在开始进行实战前，可简单了解一下几种常见的图形化界面设计...

在学习测试理论基础时，相信大家都曾看到这个问题“请说说软件测试分类”，其中一个答案就是：按测试阶段，软件测试可分为：单元测试、集成测试、系统测试、验收测试。那么，单元测试？单元测试？什么是单元测试呢？最初作为一个对单元测试毫无概念，对单元测试的了解仅限于官方简介说明，且只会if else基础语法的初学小白而言。觉得单元测试肯定是需要强大的代码能力，是那种能写上千万个字符代码的资深码农才会的技能。后面学习了测试开发课程后发现，其实单元测试从某种层面上可以简单的说就是测试某个单元函数方法是否满足设计的测

其实，写代码就像建房子，一砖一瓦大家都知道，难点是在你如何盖的更高级。写代码也是一样，基础语法无非就那几个很多人都会，关键是如何将代码写的健壮、写的条理清楚。在学习自动化开发语言过程中，很多人都会有一种感觉，就是感觉自己好像什么都会一些，但是会的都是基础知识点，还不够”深“，不够高级，面试时不敢大胆的说：我会！我懂！特别是看别人写好的代码时发现，有好多个文件，好多个方法，调来调去的，跳来跳去的。贼崇拜，大佬呀，大神级别的存在呀，但是看看自己只会写单个接口，单个方法，看起来很low，很low！完全没自信出

常用的测试模块作为一个测试人员，如何有效的保证测试质量？如果只是回答按照测试用例进行详细测试，那是错误的。从可从两种不同的维度来保证测试质量。在测试周期内，按照测试范围可划分为以下4种：独立模块测试 集成测试 自由探索测试 交叉测试从测试计划来划分，可分为以下3种：测试环境测试 预生产环境测试 正式环境验收测试浅谈自由探索+交叉测试在日常测试过程中，除了按部就班的按照需求文档、用例文档、UI效果文档来进行业务功能基础测试之外，个人开展测试过程种无形中会进行一个叫名为“自由探

网上的面试教程相对零散未集中，所以个人针对liunx、SQL、Jmeter三部分，稍微总结了下常见的面试问答~欢迎留言补充相关常见问答~Linux篇cd ：进入文件夹 cd..：返回上一级文件夹 ls：列出当前目录下的所有文件夹 cp：复制文件夹 mv：移动文件夹 rm：删除文件 rm –rf：强制删除 rmkdir:删除空目录 mkdir：创建文件夹 touch：创建空文本文件 grep：关键字过滤 find：查找文件 ps：查看进程 vi:文件进入编辑模式，q表示退出.

作为一个合格的测试工程师，必须掌握测试的日常工作流程。那么在一个产品周期里面，测试工程师是什么时候介入工作的呢？具体承担了哪些工作呢？这两问题，也是在日常面试中经常遇到的，这里我用一张思维导图进行简单的概括（如下图）今天我们就来说说“测试用例设计”和“测试用例评审”。测试用例设计常见的测试用例方法大家都在网上和日常测试过程中都有用到过。这里给大家讲解一些特殊的测试点该如何进行用例设计。详情页字段校验方法：场景组合设计用例实现：同一个详情页不同字段，通过场景组合用例设计，可实现在

概述不想干掉leader的测试，不是一个积极的好测试。每一个测试小白，都是从基层做起，成为leader之前要先成为一个优秀的测试工程师，优秀的测试能够在日常工作中年不断累积经验，及时反思总结，为自己将来能够成为一个合格的Leader打下基础。Leader需要具备的潜质很多，其中之一就是：如何提高团队配合默契度？在开始如何提高团队的配合默契度之前，先了解下测试工程师在日常测试过程的活动范围。在日常测试工作中测试工程师需要贯穿整个团队，上对产品，下对开发。除了给开发提代码缺陷外，也需要给产品提需

你还只知道BUG六要素么？常见的软件测试面试题：一条软件缺陷（或者叫bug）记录包含了哪些内容？标准答案是：【标题、严重等级、前置条件、步骤（bug描述）、期望结果、实际结果】实际上在我们日常软件测试过程中，提交一个bug，不仅仅是这6要素这么简单的事情。以下是个人总结了日常测试工作中常见的一些问题：需求未设计？需求不明确？ 服务端/前端的数据错误？ 开发无法重现？能帮开发模拟下数据吗？ 同类型bug合并？ UI设计错误/数据展示错误？个人总结了一个健全的缺陷，应该尽可能的

如何尽最大的努力避免成为背锅侠？本文主要讲述自己从一个测试菜鸟，逐步成长到现在过程中累积的一些经验。在日常测试工作中，经常听到开发说：这个bug是产品设计缺陷？这个细节产品设计文档没有？这个bug是前端的？这个bug是app端的？等等诸如此类的推脱，不愿意承认这个bug是他代码漏洞造成的。最后苦逼的测试就陷入两难的地步，提交一个bug吧，开发小哥哥不乐意了，不提吧万一出了问题就要我们测试小虾米来背锅了。凡是遇到线上故障，都是测试负主要责任，开发负次要责任。可怜的测试人员在背锅到道路上越走越远…以下