测试小小的博客

1、bug的2 8 原则指的是80%的bug分布在20% 的模块中 针对这种情况我们怎么指导我们测试工作呢： 1、第一轮测试完成之后，分析bug主要分布在哪些模块， bug发现多的模块意味着还有更多的bug 没有发现， 这个可以再次换一个人测试这个模块，促使这些bug多的模块的bug尽可能早，尽可能多的被发现，提升我们的测试质量。...

 参考答案：1、防火墙挡住了ping请求2、ip地址弄错了3、网线没有接好4、交换机坏了5、ping服务被禁止掉了6、网络配置不对，比如ip、网关、子网掩码

这个问题要分两种情况讨论1、测试用例质量较高，覆盖了需求设计中的测试点，并且测试人员认真负责，没有发现bug ，说明程序质量很好， 这种测试的价值就很大，能够去评判软件的质量2、测试用例质量不高，测试人员的责任心不强，没有发现bug，这种测试的价值就比较低，不能用这个测试结果去评判软件的质量另外我们在实际工作过程中，大部分情况测试都是能发现bug的，如果没有发现bug，思考你还有那些场景没有测试到...

不一定需要解决所有的bug，第一完全的测试是不可能的，也就说明没有bug的软件是不可能的，只要满足客户要求的就是好软件， 第二：版本上线是有时间截点的，在规定的时间内优先解决对客户影响大的bug。 bug遗留一般是下面几种情况： 1、bug没有好的解决方案，且影响可控的 2、优化类的bug 、转成需求来修改， 3、时间太紧张，对客户影响小遗漏到不紧张的版本修复...

举个例子来说明WEB页面上数据显示错误，本来应该显示38, 结果显示35，这个时候你怎么去定位这个问题出在哪里？ 1、通过fiddler抓包工具（或者其他抓包工具）， 分析接口返回的数据是35还是38， 如果返回的是正确的，那就是前端的问题， 如果返回就是错误的， 你还得看看我们请求的参数是否正确，如果不正确，那肯定是前端的问题，如果正确，那就是后端的问题，接着以下步骤看 ...

测试用例好坏的评判标准首先纠正一个误区，测试用例不是越多越好？相反如果测试用例中冗余用例太多，这样在执行测试用例会浪费大量测试人力，而且不会产生测试效果。另外我们测试的目的是去保证我们软件质量符合客户的要求，不要走偏了，所以有以下标准    标准如下：     1、测试用例书写格式正确、描述清晰， 其他测试人员拿到测试用例可以在不询问写作人的情况下正常执行下去，（简单来说， 其他人能看懂，能执行）...

1、为什么会有COOKIE这种机制  首先一种场景， 在一个网站上面， 我发起一次请求，那服务器怎么知道我是谁？是谁发起的这次请求呢，  HTTP协议是无状态的协议， 浏览器的每一次请求，服务器都当做一次新请求， 但是在实际应用中我们需要知道这个请求来自于谁，需要查找哪些信息返回给访问者，这个时候就引入了COOKIE机制， COOKIE机制是什么呢？ 其实就是服务器给客户端返回数据的时候，中间加了...

首先你对软件测试是否足够了解， 软件测试是目前的热门行业，薪资也比一般的行业高，工资的增长幅度也比较快，这些都是光鲜得有里面，但是软件测试的工作压力还是比较大的， 技术更新也比较快， 软件测试是一分付出一分收获，薪资就是对你最好的肯定。如果你做好了选择，决定从事软件测试，那就接着往下看自学优势：金钱成本较低，能够按照自己设定的学习计划进行学习，时间安排也比较自由。劣势：自学消耗的时间比较长，如...

要做判断的原因：1、判断这个bug是前端还是后台的，如果判断准确了，方便我们找对应的人沟通，减少沟通成本， 2、提升测试人员自己定位问题的能力 在分析这个之前，我们先讲一讲前台和后台的区别 前端“主要是负责页面的展示， 以及一些校验，比如字符串的长度格式校验 ，当然这些后台接口也需要做对应的校验的， 后端接口：主要是负责业务相关的功能 现在来分析bug可能是前台还是...

第一种情况：正常执行测试1、如果测试的人只有你一个，看看测试的软件版本是开发中的还是已经上线的，如果是开发中未上线的版本，发现不了bug要引起注意， 毕竟绝大部分情况下应该是能发现bug的2、如果测试的人不止你一个的时候，看看其他人是否可以找到bug，分两种场景讨论：场景1、如果测试的bug不多，那说明软件质量应该还不错， 你测试不出来bug 也不要着急，场景2、其他人能够发现bug，但是你发现不...

分几种情况来讨论： 1、由于客户端的电脑配置引起的系统慢，如果客户也使用相同配置的电脑，这个慢需要提单解决 2、由于客户端网络慢导致的系统反应慢，这个不用解决 3、由于系统架构导致的系统慢（数据库设计不合理、程序运行流程不合理、计算方法不合理等），这个测试工程是可以通过分析系统日志，使用性能测试工具测试对应功能的响应时间（RT），提交bug单解决 在我们提交bug单前，需...

其实如何判断是否是一个优秀的bug，最重要的一个标准： 开发不用询问测试就知道怎么重现这个bug， 或者能够理解这个bug， 而不是看不懂这个bug字段如下，每个字段的要求如下一个bug单包含哪些要素：1、所属的系统2、发现的版本3、发现bug所属的模块4、bug提交人5、bug的错误类型：代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题等6、bug的重现概率： 必现 大概率重...

一个系统上线之后经常会有线上问题，这个时候要求测试去复现网上问题，一般我们怎么样去入手分析呢？一个系统上线之后经常会有线上问题，这个时候要求测试去复现网上问题，一般我们怎么样去入手分析呢？ 一、收集网上问题发生时的记录，一般包括如下几个方面1、抓取出现问题的日志，还原操作过程2、询问当时操作员执行了哪些操作，尽可能多的了解事发经过3、了解当时的网络情况 二、分析发生问题的原因？通过查看日志，分析发...

首先确认三个实现的细节：1、日期计算时，时间是按照服务器时间、数据库时间还是用户本机时间或者其他的计算的？2、免登录是怎么实现的？是Cookie还是Session？3、计算是按照时分秒计算还是按照整天计算的？测试点：以7天为例1、选择7天内免登录，登录后退出再次登录，是否免登录2、选择7天内免登录，登录后，第七天登录，是否免登录2、选择7天内免登录，登录后，第八天登录，是否免登录4、考虑跨周的测试...

1、现在软件系统越来越复杂，一个软件系统可能由几个几十个人一起开发的，单个开发可能只熟悉他所有编写的模块，对于其他有影响的模块不熟悉，容易产生错误 2、开发自己写的代码自己不容易检查出错误，开发也有可能遗漏需求功能或者缺失异常处理，需要测试来帮助他们检查软件是否有bug ，是否符合产品设计，是否符合用户习惯，异常是否都已经处理， 3 、现在市场竞争激烈，对软件开发的周期和质量...

1、主动了解做这个功能的背景，意图，要去解决一个什么样的问题， 这个可以找产品或者开发要，或者谁要求做这个功能的人要，知道这些后，测试的时候才心中有数，知道功能实现对不对2、尽量让熟悉这块的业务的人去测试，这样功能的一些业务问题就可以测试出来3、 因为没有需求说明书，测试这边只有在功能做好了，转测试了，才知道功能是什么样子，所以这个时候写测试用例来不及，就采取这样思路操作 ，测试的时候边测试边记录...

bug也要分情况： 1、需求里面有明确说明或者测试应该测试到的点，如果还有bug，那就是测试的责任 2、如果还有优化类的bug不能算测试的责任 3、如果还有不符合用户要求但是需求设计就错了的，不算测试的bug 为了测试不背锅， 所有关于bug沟通的记录都要有记录，方便以后不背黑锅 1、测试发现这个问题，但是不修改的， 这个也要有问题单记录 ...

第一种情况：正常执行测试1、如果测试的人只有你一个，看看测试的软件版本是开发中的还是已经上线的，如果是开发中未上线的版本，发现不了bug要引起注意， 毕竟绝大部分情况下应该是能发现bug的2、如果测试的人不止你一个的时候，看看其他人是否可以找到bug，分两种场景讨论：场景1、如果测试的bug不多，那说明软件质量应该还不错， 你测试不出来bug 也不要着急，场景2、其他人能够发现bug，但是你发现不...

我们发现了一个bug牵扯到A、B两个模块，想找A模块的开发确认下这个是不是bug，但是A模块的开发说，这块是别人负责的，我负责的部分没有问题， 这个时候你怎么办？    场景1、如果可以确认是bug，不需要找开发再确认了，直接提交bug给开发主管，    场景2、不能够确认是否是bug，害怕是测试环境部署不正确引起的bug，先排查是否是环境部署不正确，然后分析这个bug 的业务流程，分析流程中每一...

开发人员和测试人员来来回回沟通bug，非常影响研发的进度， 不仅开发修改bug慢， 测试测试进度也慢， 那我们有没有办法去降低这种内耗呢如何降低和开发人员的bug沟通成本？ 1、 每一个bug描述要清楚， bug标题指明是什么bug， bug内容的步骤清晰可操作，根据步骤可以重现bug， bug的实际结果和预期结果要明确， 另外如果文字说明不清楚的，尽量截图说明、或者录制视频说明，或者附上错...

何为交叉测试     1、交叉测试按字面意思理解就是把测试人员所测试的模块交换测试。比如A本轮执行的M模块，B执行的N模块， 在下一次测试时 A执行N模块， B执行M模块。 交叉测试有哪些意义     1、每一个测试人员有自己思维的局限性，一种思维测试过之后，软件会对这种测试思维产生抗性，很难再发现新的问题，通过交叉测试，可以把新的测试思维带进来，测试出未发现的bug。     2、防止测试人员工...

1、保证产品的质量，证明产品是满足客户要求的2、优化研发过程，提升团队能力针对第二点举例： 比如版本打回次数过多（说明开发自测不到位，或者转测试质量要求不到位，打开发板子）， 比如问题单过多（可能模块太复杂，分给技能不熟练的人了，可能是这个人就没有认真干活）， 比如问题单回归不通过数量多（修改问题单不认真，导致延长测试周期）， 比如 版本上线后线上问题多 （测试不到位，测试点覆盖不全，测试设计...

1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础2、如果以前有类似的需求，可以参考类似需求的测试用例， 然后还需要看类似需求的bug情况， 站在巨人的肩上总能看的更远嘛3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑， 通过等价类、边界值、场景法等方法找出大部分用例4、 找到需求相关的一些特性，补充测试用例5、根据自己的经验分析遗漏的测试场景6、...

1、首先明确开发说不是bug的理由，2、如果是需求变更， 那就找产品经理确认是否是需求变更 3、如果开发说测试环境问题， 让他说明清楚测试环境问题是什么，我按照他说的验证一遍， 如果确实如他所说， 那就非问题打回，但是不是他说的那样，不能让他打回4、如果开发说用户不存在这种使用场景， 但是我们不认可他说的，把这个bug 知会到测试经理，让测试经理去判定，...

不能开发说不稳定，我们就不管了，我们要去尝试找到产生这个不稳定的原因， 首先看看开发环境是否也会有这个问题，如果开发环境没有，测试环境有， 那就比较两个环境的差异性（配置、系统、软硬件的差异性），排除差异后，看看是否还会不稳定，如果测试环境和开发环境都不稳定，这个时候提交一个偶现的bug，让开发找到可能的原因， 总之一句话，遇到不稳定出现的bug，一定不要轻易放过，要寻根问底，找到原因， 不然项目...

1、深刻理解需求，需求澄清的时候就不要在会议上面玩手机或者干其他事情了，因为如果需求理解不深刻，后面测试相关的工作就很难开展，2、找到需求中设计不合理或者很难理解的地方3、思考需求中的测试点，影响我们做测试的地方让产品经理给出说明？比如说这种异常情况怎么处理？有多少种状态？状态之间如何转化什么的，反正就是影响我们测试的地方都要让产品给出说明，这样给我们后面写测试设计和测试用例扫清障碍...

测试工程师发现了软件的缺陷(bug)，那修复bug的整个流程是怎么样的呢？1、发现bug2、和开发确认是否是bug3、如果是bug则提bug单到测试经理，如果不是则放过4、测试经理把bug单走到开发经理5、开发经理分问题单到开发工程师手中定位6、测试工程师定位完成后，把定位结论写到bug单中，然后走到开发经理处，让其审核定位7、开发经理审核完成后把bug单走到开发工程师

1

测试工程师在工作过程中，经常会遇到紧急的测试需求，  快下班了， 研发经理过来拍着肩膀说， XXX又出了一个线上问题，需要紧急给客户修复，我们开发这边已经修改好了，你安排测试人员测试一下吧？等会我们要给客户上线。遇到这种情况我们应该怎么办？1、端正态度， 这种紧急上线版本，肯定是用户抱怨比较厉害的地方，作为测试工程师不能因为快下班、非计划内的事情就拒绝测试， 我们应该积极组织人员测

测试用例的重要级别如何划分， 那些用例是高等级， 中等级，低等级    测试用例优先级的目的：测试用例优先级可以用来方便地基于测试策略来筛选用例。比如某块功能改动小，就只用测高或中高优先级的用例。 比如冒烟测试的时候我们只需要筛选优先级最高的用例执行即可。        根据我们测试用例优先级目的：那么优先级越高的测试用例覆盖的测试点应该是用户最关心的，  比如一个注册功能， 能够注册成功这个用例...

 软件测试交流群，欢迎测试的大虾，新人加入本群，一起探讨测试技术的学习，群里面也有很多资料，656721740何为交叉测试     1、交叉测试按字面意思理解就是把测试人员所测试的模块交换测试。比如A本轮执行的M模块，B执行的N模块， 在下一次测试时 A执行N模块， B执行M模块。 交叉测试有哪些意义     1、每一个测试人员有自己思维的局限性，一种思维测试过之后，软件会对这种测试思维产生抗性，...

测试小小第一期1.24号结课，目前除了一个大三的同学，其他都已经找到了满意的工作。感谢大家的支持杨同学，建筑专业，17年三本院校毕业，第一个找到工作，且只用了一次面试机， 就面试成功了， 后面没有再面试，且是做自动化测试 工作，重庆、薪资6500刘同学 ， 和杨同学是大学舍友， 建筑专业， 17年三本院校毕业， 第二个找到工作， 功能测试， 重庆 5000， 也是一次面试成功，考虑公司的前景不错，...

再讲这个事情之前，我先来讲两个例子： Case1： 国内某个通信巨头A的研发工程师为了快速解决一个客户的网上问题，私自拷贝了客户的数据， 最后圆满结局了客户的问题， 客户却投诉了这个工程师， 认为工程师偷取公司的运营核心数据， 最后结果是：通信巨头A给客户赔偿损失且开除了解决问题的工程师 case2： 某个软件开发商， 私自拉取了客户数据进行问题的定位， 客户没有开启自动退款， 但是...

问题：目前许多年轻人迫于生活的压力，觉得自己的工资入不敷出，看着身边搞IT的朋友收入都过万，即使觉得程序员是吃“青春饭”的，但也想去转行做软件测试,只是在犹豫徘徊是否选择正确，能否让生活品质真的会有一些提高？回答：对于这个问题，因人而异，不能看别人在做什么自己就盲目的“跟风”，需要从以下几方面来谈一下自己的想法：（1）首先对这个“青春饭”我觉得你必须认清楚，比如现在许多年轻小鲜肉演员不是靠吃青春饭...

1、让整个研发团队重视质量，质量不仅仅是测试的事，也是开发，产品的事，所有的人都对质量负责人产品：对需求说明要细致开发：1、 不要出现修改一个bug 引出另一个bug ， 修改bug不通过不完整的情况2、转测试前自测要细致，不要出现版本打回的情况， 打回一次，基本浪费测试团队半天的时间测试：1、测试要细致，不要把本该第N轮发现的bug，在第N+1轮发现， 就是测试的bug尽早发现2、测试的工作要做...

1、首先给开发说这个bug的会对客户产生的影响，如果开发认可，那就修改， 如果不认可， 进入第二步 2、找对应的产品，确认这个bug是否有修改的必要， 如果有，让他细化需求，然后把问题单走给产品，让他走给开发， 如果还是确定不下来，走步骤三 3、把这个bug报给测试领导，让领导去推动解决...

0基础软件测试培训出来的学员找工作需要“伪造简历”吗？问题:一个朋友之前从事土木专业的工作，工作环境以及收入感觉不尽人意，所以参加了0基础软件测试培训转行，为期四个月的培训，目前正在进行自动化的测试的学习，即将学成准备找工作，但是很多人都给他提到在做简历的过程中需要一些伪造，但是从他内心深处他很抵触这个做法，但是作为自身知道四个月培训出来所掌握的知识和专科出身的的行家相比相差甚远，但是也没有办法不...

探索式测试：强调测试人员的主观能动性，抛弃繁杂的测试用例设计过程，强调在碰到问题时及时改变测试策略。 那什么场景下会开展探索性测试呢？在这些场景下如何做好，有哪些套路 场景1：测试任务比较紧急，没有完整的需求设计文档，也没有充足的时间编写测试用例 1、挑选对被测试功能的业务熟悉的测试人员 2、让开发给我们讲设计的思路，程序运行流程，3、测试的过程中记录测试过的...

分析软件测试的质量是每一个测试人员的基本要求，那我们如何去分析软件测试的质量，结合自身的经验，给大家分享一下如何通过问题单分析测试质量。要通过问题单来分析测试质量， 那首先我们需要规定问题单的一些基本规范，比如说提交问题单必须要有的一些字段： 版本号、模块、 测试用例编号、严重级别、问题单提交人、提交问题单的时间、测试环境、重现问题步骤、预期结果、实际结果、必要的截图附件。版本号：通过这个字段我们...