2021-12-30点击量：119

产品出了问题，谁都不想担这个责任，那么锅由谁来背呢？1测试人员在以往的工作中发现，只要线上有bug，或者有哪个功能没测到，都被认为就是测试的问题。之前做过一个项目，在项目验收阶段，客户对下单的流程提出了一些优化性的建议，但是在开发人员开发完这个需求之后，并没有通知我进行测试，就导致在下一次给客户演示的时候，下单流程根本不通，让客户非常失望。就这样甩锅之路又开始了，开发说是功能已经做好了，但是是测试没有测出问题来，测试又说并没有被通知到这个已经改好了需要测试，那么到底是谁的问题呢？其实严格说起来开发和测试都有责任的。开发人员在功能完成之后应该及时的通知到测试人员进行测试，留出足够的时间改bug；测试人员应该严格按照需求的时间节点去确认开发人员是否完成了需求开发，不要一味的等开发人员通知，因为有时候开发人员有可能会遗漏掉。当然这不是最奇葩的，遇到的最奇葩的一次是，由于运维人员数据维护错误，导致客户的订单错误被投诉，打眼一看，这应该没测试什么事儿了吧？不要太早的下定论哦。领导给出的结论是为什么数据维护完了不测一下？我当时都震惊了，测试只能保证功能没有问题，不可能每维护一条数据都测试一下，数据维护错了把锅甩在测试人员头上，这就有点过分了吧？还有就是项目或需求延迟的情况，只要项目有延迟，就是质问测试人员，为什么没有测完？为什么不催着点开发赶紧做完？怎么还有bug没有改完？工作时间越久就越来越发现，测试人员都成全能的了，什么也得干，什么都得会干。2新人记得我刚入职一家新公司的时候，由于对业务还不太熟悉，所以刚开始的工作都是了解业务和需求，并没有实际的分给某个功能做测试，有一次一个新需求，其他测试人员测试通过之后，第二天需要将这个新功能更新到生产环境上让客户使用。因为是新人嘛，所以领导就让我和他一起来做版本的更新测试，正好可以熟悉一下公司的工作模式和系统的业务流程，但是第二天那个测试人员来晚了，所以就只有我来做了线上的基本流程测试，他并没有这个新功能进行测试。但是在版本更新完成后，客户在使用这个新功能的过程中，发现在编辑数据的时候，并没有在原来的数据上进行修改，而是新生成了一条数据，导致数据混乱。等追究责任的时候，负责这个功能的测试人员就说是我做的线上测试，在线上没有测试这个bug，不是他的问题是我的问题，当时其实是很憋屈的，明明不是自己负责的功能，就因为自己做了线上的回归测试，问题就被甩在我身上。但是由于是新人，不能一入职就和老员工硬刚，所以就忍了，当时也是很无奈的（这只是举个例子，当然这种情况也会出现在开发或者运维等岗位上）。更奇葩的是，新入职一家公司后，接手了辞职人员的工作，当这部分工作线上出问题时，责任也是你的，因为你现在负责这部分工作，没有理由，也不能申辩，接着就行了，作为一个新人，好憋屈哦！3特殊情况不能离职的人这里的特殊情况包含但不仅限于怀孕、通勤时间等等。当线上出问题被客户投诉的时候，总要找一个人来背锅，孕妈当然首当其冲的成为了最佳选择，为什么呢？因为孕妈不能轻易离职啊，离职之后就要做好在家养胎的准备，一般的企业都不会招聘孕妈的，因为还没为公司创造价值呢，就要休产假了。当然孕妈们也都深有体会，所以在这个前提下，孕妈总会被推出来背锅，因为她不敢轻易离职，有委屈只能受着（这个小编自己都深有体会）。当然还有通勤时间的影响，如果住处比较偏僻，而当前公司又是仅有的离家近的公司，那么也会成为背锅的靶子。遇到职场甩锅，我们应该怎么办呢？1顶头上司甩锅那么就得看你能不能忍了，如果能忍了，那就忍着吧，毕竟还要在他手下工作，不然你以后的日子就不大好过了，有被穿小鞋的风险。虽然忍了，但是也可以在跟他沟通的过程中表达一种我非常乐意承担这个责任的态度，既然结果不能改变，那么也要表明自己的态度，这样领导心里也会觉得愧疚，有可能你会得到更好的资源或者更好的待遇。如果你觉得忍不了，或者这个公司可有可无，那么畅所欲言吧，把事情说明白，尽量的证明自己的清白，既然不打算在这呆了，也就不怕得罪领导了。2同事之间甩锅两个测试人员之间，那么我的建议是，明确这个功能到底是谁负责的，由主要负责人负责。如果是开发和测试之间，那么我建议是共同承担责任，因为两人都有问题，开发没有考虑全面，测试没有测出问题。3新人老人之间甩锅如果新人遇到老员工甩锅，不要急着撇清关系，首先要表达出自己刚来，对系统还不熟悉，有可能漏测并愿意承担责任的态度来，其次是委婉的表达自己没有负责这个需求，并没有对这个需求进行过多的了解。当然作为一个老人，不能仗着自己是老人就将责任推到新人身上，是自己的就是自己的，要有一个勇于承担责任的心，因为所有人都是从新人到老人一步步过渡的。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：126

软件测试从业者需要掌握哪些技术？在这里具体谈谈软件测试从业者要从哪些方面，具体要掌握哪些技术。1.要全面了解软件测试技术方面最佳实践，例如关键字驱动，数据驱动等框架设计演进历史，这个可以参考我在公众号发布的自动化测试框架基础指南pdf2.熟练掌握一门编程语言，这里不仅仅指掌握语法，需要掌握到可以干开发的能力，主体需要掌握以下几个方面:2.1熟练掌握编程语言特性2.2熟练掌握标准库2.3熟练掌握常用的数据结合和算法，例如数组，列表，字符串，链表，map等的操作，以及各种排序，查找等基本算法，例如冒泡，快速，选择等算法2.4熟练掌握常用的第三方库，例如web开发flask,django,http库requests库，web自动化webdriver库，数据库操作orm库例如sqlalchemy等等2.5熟练理解代码组织管理封装等3.广泛的了解，理解当下开源解决方案和商业工具的特点及应用场景，例如RobotFramework,qtp,cypress,appium等等4.对于接口测试，除了从编程角度可以解决，也需要具备应用工具解决的能力，因为，不是所有人都能快速或坚持学习掌握编程的，这个时候需要掌握一些工具，例如jmeter，postman,soapui这类的工具5.对于性能测试，推荐以jmeter为主，但也要去学习，了解loadrunner,locust,gatling这些工具6.对于数据测试则需要熟练掌握orm库，例如sqlalchemy,pymysql等库，同时需要掌握与unittest,pytest相结合，在应对大数据时，则还需要掌握numpy,pandas这些大数据处理的库，当然也可以去掌握datatest这类专门针对数据测试的第三方集成库，省事很多7.对于基础测试，则需要去掌握unittest,pytest这类的库，我推荐深入学习unittest以便深入理解基础测试库的原理，机制，在企业实践中，则以企业级的pytest库来实践。最后，不管是哪个方面，编程是内功，内功不足，其他的在实践起来，总会碰到各种各样的的问题。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：135

做软件测试要想保质保量，就要做到测试充分，什么是测试充分，就是把所需要覆盖的场景都要覆盖到。如何做到场景全面覆盖，特别是在时间紧任务重的时候？我把我这些年来工作的一点经验总结一下分享给大家，希望对大家有点帮助：No.1提前介入测试那么什么时候测试介入比较好？在需求明确下来进入开发之前，测试就可以介入了解需求的相关内容了。这块一般有两个阶段：第一个阶段是需求澄清阶段，这个阶段就是需求接口人向开发讲解需求的详细要求及实现功能，这个时候测试就可以参与进来一起听，听过之后我们就对这个需求有了一个大概的了解，知道了这个功能的是要做什么，输入输出是什么，为后期了解详细的实现方案做准备。第二个阶段是开发实现方案澄清阶段，这个阶段一般是相关的开发人员把需求的功能实现方案和详细逻辑跟需求提出人和接口人确认，我们这个时候参与进来，就可以根据开发讲的实现方案和逻辑了解相关的的内容：比如算法判断逻辑是啥，取值是啥，输入值的类型是啥，取的哪个表哪个字段的值，或者调取那个接口服务，异常输入又是如何处理的，结果体现在哪里等等。当然有些小公司是没有给这些阶段的时间的，拿到需求就可能是口头说一下开发就直接实现，不会再次的澄清，这个时候我们怎么办，只有自己主动找开发沟通，遇到与开发理解不一致的时候，还要找产品经理或需求拉口人再次确认，来避免需求不清晰导致的一些不必要的问题，也为我们后期的测试用例编写找到明确的答案。No.2测试分析，测试用例设计根据前期的了解，接下来我们就是要把这些存在于我们脑海中的信息转化为文字形式列出来，并分析出我们的测试场景。为啥要把这些信息转化文字，不根据所想直接列测试场景，因为这些信息存在我们脑海中的很容易忘记，而且不是很清晰，只有通过有章法的梳理信息后，才能形成对我们有用的信息。不知道大家有没有这样的情景，一个需求你看文档或者听需求接口人和开发都讲过了，你也知道是啥了，感觉没啥问题了，可是当你下去写测试用例的时候，你还是会有些地方模糊不清楚。那么把我们了解的信息形成文字，就能很好的帮助我们解决这个问题。如何梳理这些信息呢，我一般是按照这样的顺序来的：1）先分析需求的背景，业务要求。把之前了解的需求背景都写出来，遇到不明确的及时询问相关人员，直到明确。比如一个需求的背景是这样的：业务人员在一线作业的时候发现某个模块在一些国家是需要特殊型号的，而在系统订单中默认配置的是另外一个型号，他们希望配置这个国家订单的时候，系统能自动识别出来并把这个模块替换成指定的型号。那我们在写需求背景的时候不仅仅是写上面那段话了，就要把“一些国家”中的国家给明确写出来，就是这些国家是哪几个国家，国家名称是啥，代码是啥，同时模块型号也要明确写出来，替换前的模块是哪个？型号是啥？替换后的模块是啥，型号又是啥？2)分析需求实现方案和逻辑这里就是把我们前期了解到的开发实现方案和逻辑一一罗列出来，有必要的可以用图画出来如开发的实现流程，逻辑判断流程，数据走向等等。就比如上面那个需求，开发的实现方案是应该包括这个国家是从订单哪个信息里面取出来的，需要更换模块型号的国家又是放在哪里的，是怎么取模块型号的，更换后的结果在哪里体现等等那我们在这个分析模块就要把这些都列出来，并一一明确。3）分析测试要点，测试要素根据前面两项的分析，我们应该很快的就理出我们的测试要点，重点关注项等内容就说上面这个模块型号更换吧，我们知道了：国家，指定模块型号，更换后的模块型号体现在哪里，都是我们的关注对象，同时我们还应知道这个更换型号对于没有不在指定国家的范围内的，型号是不受影响的。那么这些就是我们的测试要点和要素了。4）列出测试场景根据上面的分析，我们可以把我们所需要测试的场景以表格的形式写出来了5）把测试场景转化为测试用例到此，我们就可以输出测试用例了，那我们这个用例到底充分与否，结果输出是否正确，我们的理解是否到位呢？接下来我们就要请相关的人员对我们的文档和用例进行一个评审了。No.3测试用例评审测试用例评审不仅仅评审的是测试用例，还有我们对这个需求的理解和我们的思路，所以在评审的时候我们应该先把我们的测试分析文档讲一下，然后再把我们的测试用例拿出来给大家讲一下，重点讲测试的输入和输出结果。这样下来在开发和系统设计人员的帮助下，我们就可以及早发现用例的不足以及我们忽略的测试点，及时补充测试用例，完善测试用例。这个在以前的公司测试用例评审是要求很严的，每个参于评审的人都必须要提出问题点，就是为了避免有些参于评审的人员只参于不评审，导致一些问题遗留到最后。No.4严格按照测试用例执行测试这一点很重要，为什么这么说呢？因为你测试用例设计的再好，你不按照它来执行，你的测试就不可能做到充分。还记得有一次我做好了一个需求的测试用例，评审完去测试的时候，我觉得自己记得差不多了就按自己记的开始测试没有按测试用例一个个的执行，前面测试的很快，问题也不多。等后面回归测试的时候，我就突然发现多出好几个问题，原因就是我没按测试好的测试用例全面覆盖漏测了两个关联点，打此以后，我再也不敢脱离测试用例，自己凭记忆测试了。No.5分解需求有些需求接到的晚或着手测试的晚，功能又复杂，又要求按时上线，这个时候怎么办？把需求测试用例完成后，按功能分成几个小功能点，分配给多个组员测试（当然这个在给参与测试的人员之前要把需求功能详细的讲解一下），在测试的过程中要保持经常沟通，做到宁可交叉重复测试也不脱节测试。我记得当时有一个web系统的功能，前期的时候因为忙着应对其他紧急的需求，就把它放在一边了，后面提上日程的时候发现留给我的时间不多了，我一个人测试肯定测试不全，这时我就主动找主管沟通，多调两个同事来和我一起测试，然后在两个同事的协助下，才顺利完成了这个功能的测试。No.6交叉测试对于大的需求或都功能复杂的需求要做到多人交叉测试，这种测试在系统测试的时候就可以进行，以前我所在公司的项目每到系统测试都会进行这样的安排，这样就可以避免到后期回归测试出现更多的问题。No.7重点功能要及时跟踪进行测试充分性分析对于那些功能复杂，风险性高的项目，我们要在每进行完一轮测试，进行一次测试充分性分析以便及时做出调整。有一次我们有一个比较大的改动，而这个改动涉及到了我们这个软件流程中的一个核心点，也就是涉及到的内容比较多，然而留给测试的时间却不是很多只有两周，怎么办呢？组长首先把这个改动按影响到的功能点细化分了一下，分给了三个人进行测试，每天她都跟进统计测试进度，分析问题分布点，跟进问题修改情况，然后再根据这些及时调整测试策略，经过两周紧张的有序的测试，这个功能最终稳当的上线。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：139

谈起软件测试，就不得不说一下接口测试，凡是有功能的软件都离不开接口，没有接口的软件只是一个模具或页面，不具备任何功能。什么是接口接口说白了就是实现软件功能的方法，而这些方法的最终目的就是传递信息，实现软件功能。接口测试是什么接口测试就是验证这些信息能否正确传递，验证这个方法是否正确，有没有存在潜在的安全，性能问题。所以总结一下接口测试的测试点就有三个：接口功能测试、接口安全测试、接口性能测试。那么接下来我就给大家讲讲我所遇到过的一些接口和测试吧！查询本地数据库数据的查询接口这个接口的功能是这样的：查询条件订单编号、产品名称、产品型号、订单日期，可单独一个条件查询也可多个条件联合查询，多个条件查询的时候查询出来的结果取并集。结果展示根据查询条件查出来所有产品的配置信息展示给有权限的用户看，展示的字段有订单编号、产品名称、产品版本号、产品型号、配件编号、配件描述、订单日期。对这个接口的功能进行进一步的了解我们知道了如下信息：这些数据都是存在于本系统后台数据库中，涉及两张表：订单表、产品配置表。开发通过获取页面输入的查询条件，去数据库查询这两张表里面的页面需要的相关信息并展示出来。订单表中订单编号是主键，产品配置表中产品名称+产品版本号是主键，两张表通过产品名称+产品版本号进行关联。产品名称存在特殊字符的现象。通过以上的了解，对这接口测试点进行分析：这是一个结果可见性的查询接口，可以通过页面功能直接来测试，可以不借用工具，另外它也不涉及外部系统数据，不用考虑联测。因为字段表中查询条件相关的字段有特殊字符，所以在测试输入条件查询的时候要关注特殊字符查询条件的查询。所以综合以上分析，输入这块的测试场景有：输入特殊字符输入超长字符输入空字符SQL注入安全测试从查询条件分析，这个查询条件是单独或多个联合使用的，且多个条件联合时取的并集。所以从查询条件的组合来看，测试场景有以下四种情况：输入一个查询条件输入两个查询条件输入3个查询条件输入4个查询条件根据组合，我们罗列出查询条件的测试场景，为防止有重复，我用了一个表格来画如下对后台两个表中的数据进行分析,发现由于历史原因，存在版本号为空的数据，而且存在数据量比较大的查询数据，所以在测试的时候还需要关注版本号为空的场景，大数据查询结果的场景。另外出于性能考虑，我们还要关注多人并发查询的场景和一人频繁查询的场景，及异常场景：数据库宕机的场景。所有测试的场景分析完了，接下来就是把这些场景转化为具体的测试用例，执行测试了。传递数据信息的通道中间接口这是一种常见的且最简单的接口，没有任何逻辑，也不做任何处理，只是把A系统传过来的数据再转手传给B系统，功能比较单一，这种接口功能大致流程如下：我记得当时测试有这样一个接口，系统B想要获取系统A产品的版本号信息，但系统B又没有直接跟系统A交互，只能通过我们这个中间系统进行交互。所以系统B就把存在他们系统的产品名称和产品型号传到我们系统，我们系统再把这个信息推给系统A，系统A返回一个版本信息到我们系统，我们系统就直接把这个信息传给了系统B。记得当时story测试时，直接用的soapui工具，自己手动构造的系统B的产品信息传给了系统A，这样虽然验证了本系统接口功能的正确性和性能，但它的测试充分性却是不足的，为啥呢？因为我们对系统A产品的特殊参数了解的不多，只能测试普通的共同性问题，不能测试到个性问题，所以必须进行联测来完善测试，让对方系统的测试人员根据他们的测试场景去构造测试数据进行测试。涉及到外部系统的查询接口这种接口的流程一般如下：像这种接口的测试输入，输出都在本系统但有一个中间结果在页面是不可见的，我们虽然可以在页面上看到输入、输出，但却不能判断输出结果的正确性，这个时候我们就要通过接口测试工具和页面功能相结合的方式来验证了。有这样一个页面查询功能就是这样的，那个页面查询功能是：当登录人A，所在公司下有子公司时，他可查询到总公司及其所有分公司的订单，当所在公司下没有分公司时，只能查看当前公司的订单。而这登录人所在公司下是否有分公司只能通过查询系统B才能知道，而系统B返回的结果在页面上并没有展示，而是直接拿他作为查询条件进行了查询，所以要测试这个查询接口查询结果是否正确，就要结合B系统返回给我们的结果进行测试。通过接口工具先查看系统B返回的结果，然后再对比页面上的查询结果看是否与我们预期的一致。这里用接口测试工具查看返回结果还有一个好处就是可以看到对方系统返回给我们的参数格式，便于我们根据他们的返回结果格式去构造适合的测试场景来验证我们的查询结果，使我们的测试更充分。输入在本系统，输出在外系统的接口这类接口的测试一般我们采用接口工具和页面功能相结合的方法进行测试，就是在我们的系统页面触发调用这个接口的功能，通过接口工具查看监控此接口的信息来验证信息的传递情况以及查看相关的输出结果。当然这种接口也可以直接用测试工具进行测试，但是我一般是不这样的，为啥呢？因为数据构造太麻烦，而且构造的数据没有直接在页面调用接口形成的数据的可靠性高。同样的这种接口还是少不得联测的，联测就是检测我们系统存在的各种场景的数据传递过去后是不是都能被对方系统正常接收到。我碰到过的这样的接口是这样的一个功能：我们系统订单生成的产品价格要传给系统C，他们要做记录进行预算。这个接口前期的各种参数输入都在我们的系统页面上可以完成，只是后期生成订单后的价格和对应的产品信息要传到对方系统后的结果我们是看不到的。在这个时候，前面的测试就是根据我们系统各种参数场景组合测试，那这个参数到底传没有传过去，因为两个系统的开发并不同步，无法直接联测，前期只能通过接口工具调用日志查看参数是否传过去及各个参数的值与我们系统页面上是否一致，后期两边系统功能都实现了就要进行一个联测了。在这个联测的过程中你不单要把自己系统的各种数据场景覆盖到，还要了解对方系统有什么特殊的地方，根据他们的特殊要求构造特殊的数据传给数据进行更深一步的验证。好了，我碰到的接口类型大概就是这些了，希望我的这些测试对你有所帮助。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：169

你把时间浇灌在哪里，哪里就会开花结果。大三在考研与工作的纠结中，我最终选择了工作，据学长学姐的推荐下就这样开始了我的测试学习之路。因为从未接触过，在图书馆借了几本书，越看越发现和学长学姐口中说的简单相差甚远，没有任何学习思路，黑白盒，测评，工具，软件工程，网络，数据库。。。完全无从下手，但我有一颗不服输的心。于是，做了一个考研的作息时间，奔上了艰苦的学习历程。不知道哪一本书应该先看，哪本书后看，相同的关键词每本书有不胜相同的称谓和解释，每一本书都从头看起，生怕漏任一个解释，每一天脑子都昏天暗地，到晚上回忆发现想不起任何东西。第二天起来重复，不知道哪本书看过了，哪本书没看过。无意间在网上看到一个软测招聘信息，看了下要求，眼前一亮，接下来找了好多软测的招聘要求，工整的抄在本子上，知道企业最关注什么，衡量了轻重，这才开始了思路学习计划。大四第一学期选修课竟然是软件测试，毫无悬念的帮自己和同学拿到了高分。最难就业季的冷风把所有人的心都吹得颤抖，家里安排好工作的孩子们也露出了放肆的笑容，整个系不管身手如何都开始流行撒大网---人手两份简历，男生一份开发一份销售，女生一份测试一份行政，而我固执的拿着一份软测隐忍固执的穿梭在招聘会里，最终成为系里第一批拿到offer的且第一个拿到软测的人。不在乎工作是否简单只在乎工作是否不可代替。后来因为三方的事情没能去到北京实习，最后在西安找了一家公司实习，我只知道概念，对即将开始的工作满怀期待和激情，但是在这个并不重视的软测的公司里，我被稀里糊涂的告知研发位置不够坐不下了，你先在技术支持坐几天吧。在技术支持的哥们儿们出差回来之前，我和另一个实习生坐在空荡荡的办公室里，每天都在复习各种测试知识，等待坐到研发那边后大展拳脚，只是没有想到这种期待是如此的漫长，以至于到最后消磨了我所有的信心毫无意外的颓废了。突如其来的改变，是同事电脑坏了打电话到技术支持部门求助，好动的心性让我忍不住过去看了下，查了很多百度最后莫名其妙的弄好了，接下来就越来越多的同事找到我，就这样被大家潜意识里变成了技术部门的人。终于见到技术老大和哥们儿的真面目了，分配给我们俩一个项目又出差了，后来才知道这是公司最大项目之一。客户千奇百怪的问题，在我苦思冥想中，基本都解决了，后来有很多客户都指明要我接电话，这让我在公司备受宠爱。接下来一切都顺风顺水，出外支持，客户培训等等。期间还对整个公司的项目文档进行了分类整理。记住，我给你一个唯一特权。六个月实习期已经过了三个月了，研发部经理突然找到我说那边有位置了问我愿不愿意调回去，当时我犹豫了一秒答应了。在研发部的日子很沉闷，测试总共有一个老员工和三个实习生。老员工轻描淡写了我们目前进行的项目和即将要做的事情，我抓住了她无意中提到的测试用例，我从没真正写过，于是去上了人生中第一个夜机写了一整晚第二周发给她，她没回应，后来我看到svn上面放的是我的测试用例写的是她的名字，但是我还是很高兴，每天努力地提Bug,看各种文档。因为我有技术支持比较熟，研发部经理让我写报价单和验收报告，二次打回让我忍不住跑去问他到底需要什么样的，他说我一直在等你来。第三次完美收官。又来了一个新经理顶替他，说是要对研发部门彻底的改革，给所有的实习生开了会，问我们实习的感受，我说很感谢公司让我体验到了真正的测试流程。后来他对我们各种压迫，逼迫我们通宵加班，一段苦日子之后，他说很遗憾没有人通过他的考验，但如果我们想留，他自己承担我们每月的1200元毫无压力。我想了一晚上，第二天找到他，和他聊了一个整个上午，他说他很欣赏我，但是不欣赏我现在的能力，然后亲自给我做了一个测试面试作为离别馈赠，他说你看吧，在这几个月里你学到的东西和你几个月之前知道的没有多大区别，那留在这里还有意义么？然后我才知道自己已经闭门造车了多久，自己到底有多差劲。他还告诉我说技术支持和培训学员那边都给他打招呼想把我调过去，部门任我选，我拒绝了。我起身告辞时，他叫了我的名字，说，记住，我给你一个特权，等你有了足够的能力的时候如果想回来，我随时为你敞开大门，只为你。从一开始，就没有“我是新手”的权利。经理的话深深地影响着我，于是一拿到毕业证我立马到了东莞，早上下火车，下午去跑去另一镇面试了，没有经验的应届毕业生，没有任何的优势拿到稍微平衡的工资，我现在都还不知道当老大sunnychen给我offer是看中我的信心还是对工资的谦逊态度，总之他说需要让我完全支撑测试流程的时候，我犹豫了3秒然后坚定的告诉他我可以。其实后来一直很心虚，因为我不太能听懂他讲的普通话，里面隐约的几个关键词我想我是从来都没听过的。第一天上班，他说他给我一个周的时间让我熟悉业务并找好用的测试管理工具搭一个测试环境，我才开始查什么叫测试环境，测试管理工具哪个最好用，无数次试验，重装，查错，星期四搭了bugfree,并能顺利发邮件。我想现在我应该还不能完整顺利地搭出来，因为当时错一个改一个完全没有章法，搭好可能真的是老天在帮我。我们是小公司的一个独立的小部门，自主研发客户管理系统，会员管理系统，仓库管理系统等等共10几个项目，目前主在做核心的五个系统，即同时测5个项目，后来老大在外面接私活儿来做，很忙但乐不思蜀，白天疯狂的测试，晚上学习，公司，宿舍，饭堂三点一线。我根据我们的项目修改了bugfree里的状态，为项目做了各种文档的专用膜版。老大说给私活儿测测性能吧，然后我花了一个周的时间下载了lr并安装，终于接触到了对我来说神一样级别的东西。不在失败时退出，要退出就站在巅峰再退出。花了很多时间和客户交流沟通，培训，经常弄到半夜一两点，最终在部门被撤除之前完成了私活儿和客户管理系统。星期四早上被告知要撤除，下午我投了简历，星期五中午散伙儿，下午我去面试。安静的周末让我更加低落，西安的朋友都说快过年了回去吧，过完年在西安找工作，一切都会好起来的。我哭了，不是我不想回去，而是不想这么狼狈的回去，我不甘心。星期一人事打电话通知我面试通过问我什么时候能去上班，我说明天。精益求精做自己喜欢做的事情。不得不事先吐槽一下，我掉进一个狼窝了，上家公司虽然比较忙但时间自由，只要完成任务可自行安排上班时间，那时程序猿们经常12点才来上班晚上上到很晚。这里886的工作制度，我没有额外的时间和精力学习了，每天无穷无尽的测试，第一天早上办完入职手续，给我说了下用的什么系统，要测什么项目。下午就正式提交bug了。没有需求分析，没有任何文档，只有一堆效果图，对业务的理解就要看对效果图的理解程度了，这是经理给我说的除面试外的第一句话。公司自主研发的5个web项目，给我两个，另一老员工负责三个。我没做过web项目的测试，又算新的邻域！我信誓旦旦的觉得自己测得很全面的时候。一个偷懒的美工找了几个微妙的样式bug给我，两个页面的淡蓝底色宽度不同，还放在一起截图给我，那1mm的差距真的让我傻眼了，原来测试还可以这么细致。我的强迫症就此变得更加严重了。每天上班第一件事测试外网有没有问题，下班前最后一件事测试外网有没有问题。在不久后那个老员工因疏忽把一个bug放到了外网在群里被批评，我庆幸自己有这样的先见之明。很牛的人都有一段很苦逼的经历。当这个项目接近尾声时，生活开始异常无聊了。幸而不久后公司开始全面推广老员工手上负责的一个项目，我也加入了战列，但真的不知是福是祸。对项目的不熟悉，而项目紧急，没办法停下一分钟，客户的反馈接踵而来，让我们应接不暇。就这样第一次推广失败。接下来的一个月便是魔鬼般的日子，每个人都顶着巨大的压力，可仍超出经理承诺给boss的时间的两周，然后，毫无意外，这样的紧迫下必须以失败告终。终于boss仁慈再给了2个月时间。为了凸现隆重，第三次推广新加了10个有奖活动。交由我负责，就是这持续一个月的活动让我体会到了测试生涯中最苦逼的日子。每天卡着时间点和用户抢大奖，费尽心思制造各种真实数据，还得不停地测试我所负责的模块。最后由于客服在微博上和用户起了争执，于是微博交给我管理，还要顺带解答用户所有的问题和疑问。做活动关系到拿奖提现，只有我最清楚每天哪些是真实用户和真实的中奖记录，顺其自然的又落到了我的头上。在巨大的心理压力和身体压力下，很荣幸的长出了人生第一批痘痘，来势汹汹让我措手不及。我想我可能坚持不下去了。在活动结束的最后一天，boss拍拍我肩说，这下你轻松了。顿时心里的石头哐哐结实的落地。手上却还是停不下来，谁叫测试是无穷无尽的呢？本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：81

分析测试需求测试人员在制定测试计划之前需要先对软件需求进行分析，以便对要开发的软件产品有一个清晰的认识，从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据，作为测试计划的基本依据，为后续的测试打好基础。此外，分析测试需求也是对软件需求进行测试，以发现软件需求中不合理的地方。被确定的测试需求必须是可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。制定测试计划测试计划一般要做好以下工作安排。①确定测试范围：明确哪些对象是需要测试的，哪些对象不是需要测试的。②制定测试策略：测试策略是测试计划中最重要的部分，它将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型（如功能测试、性能测试）选定测试环境和测试方法（如人工测试、自动化测试）。③安排测试资源：通过对测试难度、时间、工作量等因素对测试资源合理安排，包括人员分配、工具配置等。④安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。在安排工作进度时，最好在各项测试工作之间预留一个缓冲时间以应对计划变更。⑤预估测试风险：罗列出测试工作过程中可能会出现的不确定因素，并制定应对策略。设计测试用例①测试用例（TestCase）指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板，虽然它们在风格和样式上有所不同，但本质上是一样的，都包括了测试用例的基本要素。②测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。执行测试①测试执行就是按照测试用例执行测试的过程，这是测试人员最主要的活动阶段。②在执行测试时要根据测试用例的优先级进行。③在执行测试过程中，测试人员要密切跟踪测试过程，记录缺陷、形成报告等，这一阶段是测试人员最重要的工作阶段。编写测试报告一份完整的测试报告必须要包含以下几个要点。①引言：测试报告编写目的、报告中出现的专业术语解释及参考资料等。②测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。③测试内容及执行情况：描述本次测试模块的版本、测试类型，使用的测试用例设计方法及测试通过覆盖率，依据测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动借鉴参考。④缺陷统计与分析：统计本次测试所发现的缺陷数目、类型等，分析缺陷产生的原因给出规避措施等建议，同时还要记录残留缺陷与未解决问题。⑤测试结论与建议：从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体明确的结论。总结测试报告的数据是真实的，每一条结论的得出都要有评价依据，不能是主观臆断的。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：182

什么是底层逻辑？按照刘润老师的解释就是：“事物间的共同点，就是底层逻辑。只有不同之中的相同之处、变化背后不变的东西，才是底层逻辑。......底层逻辑+环境变量=方法论”他还说：“只有底层逻辑，才是有生命力的。”所以我们要来探讨一下：软件测试的底层逻辑是什么？对软件测试的基本认知对软件测试的基本认知，使我们达成共识，从而基于这个共识，更容易去讨论软件测试的底层逻辑。对软件测试的基本认知，需要精简到一句话来描述，即抓住软件测试的本质，以简洁的方式描述正确的软件测试价值观，但不是某个人的软件测试价值观，而是能被大多数人接受的软件测试价值观。根据这些对软件测试的认知，用一句话来说明软件测试的基本认知，那就是：基于对用户真实需求的理解，通过各种手段获得软件产品真实的、全方位的质量信息。无论是验证软件功能特性是否满足需求、评估产品的质量还是揭示产品的质量风险，都是基于获得的有关产品的真实的质量信息做出判断的，而缺陷可以看做是这个活动过程中的副产品。这里强调对用户真实需求的理解，一方面体现“没有用户就没有质量，质量相对用户而存在”，我们必须从用户角度出发来完成测试，另方面是用户的真实需求，而不是虚假的、错误的需求，业务的需求最终要分解成用户角色的需求，而系统的功能/非功能性需求也是为了满足用户的需求。这里提到的“软件产品”不局限于程序，还包括数据、需求文档、设计文档、代码、用户手册、技术手册等。了解了“什么是软件测试”之后，下面就可以讨论软件测试的底层逻辑。测试流程的底层逻辑测试流程符合一般工程项目流程，经过分析、计划、设计、实施和评估的过程，任何一个环节不可缺失，每一个环节都重要，但前面的环节会影响后面的环节，所以越在前面的环节越重要。测试分析是基础，依次是设计、实施和评估，构成一个金字塔模型。测试流程的另一个底层逻辑：形成闭环。如果经过评估，发现测试过程有问题，需要重新分析、修改计划、修改设计......再经过一个完整的过程，构成一个新的闭环。从测试流程改进来看，也需要构成PDCA那样的闭环。从今天DevOps的角度看，测试是为了让用户更满意，但同时要进行用户调查，收集用户反馈，构成闭环，如我16年前所画的闭环。从缺陷带来的成本来看，测试进行的越早越好，因为劣质成本是指数级增长。概括起来：测试是贯穿整个研发周期，形成闭环，并持续改进。测试分析的底层逻辑测试分析的底层逻辑是基于系统思维、结构化思维去思考，需要从项目背景、产品结构、质量要求等各个方面进行系统地思考，不容忽视一些蛛丝马迹，顺藤摸瓜，完整地呈现测试范围，识别出各种测试风险，最终明确测试项及其优先级。系统思维可以让我们看清楚被测对象的输入/输出、前置条件和后置条件、周围环境和面临的各种场景。结构化思维帮助我们制定更有效的测试方案和测试策略，如分层测试、面向接口的测试等。同时，测试总是有风险的，所以测试分析时一定要采用基于风险的测试策略，并应用80/20原则，确定20%最严重的风险集中在什么地方、哪些功能是用户最常用的20%功能、哪些测试项是属于重点测试的20%等。测试分析的底层逻辑之一：测试分析是层层剥离、逐步深入的系统分析过程。从业务需求、用户行为、系统功能、应用场景等不同维度对被测对象进行系统的分析，最终确定测什么。测试分析的底层逻辑之二：测试分析也是一个博弈、选择直至平衡的过程，需要定力和洞察力，做出取舍，如运用80/20原则，抓主要风险，有时需要舍弃一些次要风险。测试分析的底层逻辑之三：以终为始，从测试目标出发最终回到测试目标，如从考虑如何衡量测试充分性的要求出发，最终分析的结果——各测试项完成是能够满足测试充分性的要求的。测试设计的底层逻辑测试设计是基于测试分析的结果，运用合适的方法完成测试数据、测试场景或测试用例的设计。按照工程思维的方式，解决方案不只一个，要设计多个方案，从中选出更优或最优的方案。测试设计的本质是以更有效的方式覆盖测试需求，从场景覆盖、逻辑覆盖、路径覆盖和数据覆盖等不同覆盖策略中选择一种或几种。测试设计也是一个循序渐进的过程，不断完善的过程。测试设计是辩证统一的思维过程，既有严密的逻辑思维，也有跳跃式、发散性的创造性思维；既是黑盒测试方法和白盒测试方法的对立统一、静态测试和动态测试的融合，也是主动测试和被动测试的融合......只有这样才能更彻底地满足设计要求，更快地完成测试以实现测试目标。测试设计的底层逻辑：测试设计是艺术，更要创新、融合。测试自动化的底层逻辑测试自动化就是要充分发挥工具的作用或价值，例如工具能百分之百地执行命令、任劳任怨，所以自动化测试适合机械、单调的测试工作，如回归测试、性能负载测试、压力测试、兼容性测试、BVT（版本构建验证测试）等。测试自动化的脚本开发和执行是建立在测试分析和设计之上，如果测试分析和设计存在问题，依靠工具是无法解决这类问题的。有更好的测试分析和设计，才有更好的自动化测试，所以我们清楚测试分析/设计与自动化测试的关系显得非常重要。工具的开发和使用、脚本的开发和使用都是由人完成的，所以人还是第一位的，工具是第二位的。测试自动化还受到文化、流程的影响，测试自动化能否成功不是一个技术问题，今天来看，技术上已经没有障碍了，障碍往往出现在企业的文化、研发流程和开发质量（如软件实现的规范性、可测试性等）等方面。测试人员的底层逻辑最后谈谈测试人员的底层逻辑。测试人员是否有价值，不取决于他/她目前的工作态度、知识与技能，而是取决于态度、知识与技能的进步速度，因为我们无法改变过去，但可以改变未来。只要持续学习、持续反思，就能快速完成自己的进化，快速成长起来，就没有人能挡得住你的壮丽前程。如果我们掌握了软件测试的底层逻辑，只有探寻到万变中的不变，才能动态地、持续地看清软件测试的本质。看清软件测试的底牌，我们就能始终如鱼得水。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：148

转眼间，2021即将结束，在短短的一年中，测试行业经过不断的发展和完善，也有了焕然一新的变化。从前，很多人对软件测试的刻板印象都是，“可有可无”、“不如开发”、“工作简单机械”等等，而如今随着测试在企业中的比重不断增重，网上的这些负面评论出现的概率也随之减少了。随着测试岗位的逐渐成熟化，企业对于测试人员的要求也在不断提升，从一开始的只需要学会功能性测试转变为如今更高级的自动化测试了。我们都知道，IT行业是一个发展很快的领域，需要不断的精进自己的技能，才能在这条路上走的更远更好，本期，借着年末的机会，也给大家总结一下如今测试行业都有哪些必会的方法和技术知识点，主要针对新手，小伙伴们也可以根据文章的内容查漏补缺。一、设计方法分类黑盒测试黑盒测试是进行软件配置项测试、系统测试、验收测试的主要技术手段。我们可以这样理解，黑盒测试把产品软件看作是一个黑盒子，只需要关注入口和出口，即我们测试过程中，不需要去理解软件的具体构成和原理，只是往里面输入了什么，又出来了什么结果就可以了，和用户的视觉是一样的。黑盒测试注重于测试软件的功能性需求，主要有三种测试技术，分别是等价类划分、边界值分析和决策表。但很多时候，仅仅进行黑盒测试容易产生一定的风险性，因此黑盒测试大多数用于辅助白盒测试发现其他类型的错误。白盒测试白盒测试是一种以理解软件内部结构和程序运行方式为基础的软件测试技术。通常需要跟踪一个输入在程序中经过了哪些函数的处理，这些处理方式是否正确。白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。白盒测试常用的测试方法有两大类，静态测试方法和动态测试方法。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试，同时包含六种覆盖标准：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖，发现错误的能力呈由弱至强的变化。灰盒测试灰盒测试是介于黑盒和白盒之间的一种综合测试方法，它综合了黑盒与白盒方法的优势，并有效地避开了两者各自的缺陷。灰盒方法通过涵盖被测软件的所有层面，以增加技术的覆盖范围。如果说黑盒测试人员需要确保界面和功能方面的正常;白盒测试人员通过深入研究软件的内部结构，以修复源代码级别的错误，那么灰盒测试则是以非干扰的方式(non-intrusive)同时处理两方面的测试。灰盒测试非常适合于集成测试，包括：缺乏源代码和二进制文件的Web应用，以及某些业务领域的需求规范性测试。对这三种设计方法，不同的方法有着不同的适用场景和想实现目标，应当合理使用来确保软件满足各项最终的要求。二、手动测试和自动化测试分类手动测试手动测试是手动测试软件以查找缺陷的过程。测试人员应该具有最终用户的观点，并确保所有功能都按需求文档中所述运行，期间无需使用任何的自动化工具，其中手动测试的类型包括：黑盒测试、白盒测试、单元测试、系统测试、整合测试、验收测试。自动化测试自动化测试是使用自动化工具来发现缺陷的软件测试过程。在此过程中，自动化工具会自动执行测试脚本并生成结果。目前比较流行的自动化工具有：HPQTP（专业快速测试）/UFT（统一功能测试）、Selenium、LoadRunner、IBMRationalFunctionalTester、WinRunner。我们通常在以下领域会进行自动化测试：回归测试、负载测试、性能测试。有很多人认为手动测试是很简单的一件事，而自动化测试则很难，其实这两者方式都需要集合使用的，互相都不可代替，自动化测试是对手动测试的一种补充，主要应用在回归测试，自动化测试的优势是可以借助计算机的力量，重复的进行测试，可以用于大批量的比较，但对于数据的正确性、业务逻辑等的满意程度，还是需要手动测试来做的。所有一个优秀的软件测试工程师，需要能够掌握两种测试方式，有机结合，才能使工作效率更高。三、按测试目的分类功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。功能测试经常会也被称为黑盒测试，只需要考虑测试各个功能是否能够实现。通常，我们把功能测试分成如下几个步骤：1.制定测试计划；2.设计测试用例：包含测试什么东西，在什么场景什么环境下测试；3.执行测试及产生测试报告；功能测试是比较测试人员比较基础的技能点，之后需要往自动化测试、安全测试等方向耕深。四、按阶段分类1、单元测试在单元测试中，在开发阶段将测试软件应用程序的各个组件。单元测试通常由开发人员而不是测试人员完成。测试一段代码形式的功能以验证准确性。简单来说单元测试就是确认单个模块能否正常工作2、集成测试从测试类别来说，集成测试的主要测试内容包括功能性、可靠性、易用性、效率、可维护性和可移植性等，集成测试主要是确认多个模块能否协同工作。3、系统测试将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。4、验收测试正式验收测试是一项管理严格的过程，它通常是系统测试的延续。验收测试的常用策略有三种，它们分别是：正式验收、非正式验收或Alpha测试、Beta测试。五、其他测试类型1、回归测试回归测试（Regressiontesting）指在发生修改之后重新测试先前的测试以保证修改的正确性。2、冒烟测试冒烟测试是指开发人员修复了先前测试中发现的bug后，想知道这个bug的修复是否会影响到其他功能模块，需要做的就是冒烟测试。需要保证覆盖待测产品的绝大部分功能；且被修复了的bug所属的功能和系统其他骨干功能都是可用的。3、随机测试随机测试是没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：295

软件性能测试的目标是识别应用程序中的所有性能瓶颈。一个软件系统的性能不仅取决于系统本身的设计和编码，而且取决于系统所依赖的运行环境。系统的运行环境会依赖于一些关键因素，例如：系统架构、硬件配置、网络带宽、配套的软件如数据库和中间件等、以及外部的负载大小。系统性能的改善是测试、调整、再测试、再调整……的一个持续改进的过程，即性能调优，根据性能测试的结果对软件的设计，代码，系统的配置进行调整。性能测试的类型性能测试主要包含6种类型，如下表所示。类型说明负载测试确定软件在给定时间内随着工作负载增加的运行方式，工作负载可以是并发用户、事务数、软件行为等。在被测系统上不断增加压力，直到性能指标（如响应时间）超过预期指标或者某种资源使用已经达到饱和状态。可以找到系统的处理极限，为系统调优提供数据。压力测试测量超出正常工作参数、更高的流量负载（更多用户、事务等）下的软件稳定性，即系统在一定饱和状态下，例如CPU、内存、磁盘空间等硬件资源饱和的情况下，系统能够处理的会话能力，以及系统是否会出现错误。稳定性测试评估软件在一个固定的常规工作负载下的长期性能。换句话说，它决定了软件能够承受恒定的工作负载多长时间以提供长期的可持续性。在测试期间，测试团队监控KPI，如内存泄漏、内存使用、内存不足等。稳定性测试还分析长时间使用后的响应时间和吞吐量，以观察这些指标是否一致。尖峰测试尖峰测试是一种压力测试，它测量软件在显著的、突然的工作负载增加（如用户并发数量）情况下的性能。软件是否能够反复快速地处理突然增加的工作负载。容量测试测试软件在处理大量数据时的效率，用于检查数据丢失、系统响应时间、数据存储可靠性等。可伸缩性测试测量软件在处理不断增加的工作量方面的有效性。可以通过在监视软件性能的同时逐渐添加数据量或用户来执行可伸缩性测试。如今，随着DevOps的发展，性能测试已经上升为软件系统全生命周期性能工程。本文从五个方面介绍性能测试的工具和解决方案：客户端性能测试、服务端性能测试、分布式系统的应用性能监控、分布式系统的全链路压测。客户端性能测试工具1）GoogleLighthouseLighthouse是Google开发的一款分析Web应用和页面性能的开源工具。Lighthouse分析Web应用程序和Web页面，收集关于开发人员最佳实践的现代性能指标和见解，让开发人员根据生成的评估页面，来进行网站优化和完善，提高用户体验。Lighthouse是直接集成到chrome开发者工具中的，位于‘Audits’面板下。2)PerfDogPerfDog性能狗是移动全平台iOS\Android性能测试工具平台，快速定位分析性能问题，提升APP应用及游戏性能和品质，手机无需ROOT/越狱，手机硬件、游戏及应用无需做任何更改，极简化即插即用。官网地址：https://wetest.qq.com/product/perfdog3)MonkeyMonkey是AndroidSDK提供的一个命令行工具，使用简单、方便地运行在任何版本的Android模拟器和实体设备上。Monkey会发送伪随机的用户事件流，适合对app做压力测试。4)MonkeyrunnerMonkeyRunner工具提供了多个API，通过monkeyrunnerAPI可以写一个Python的程序来模拟操作控制AndroidAPP，测试其稳定性并通过截屏可以方便地记录出现的问题。5)mobileperf天猫团队开源的PCAndroid性能稳定性测试工具，可以收集Android性能数据:cpu内存流畅度fpslogcat日志流量进程线程数进程启动日志，mobileperf也支持原生monkeytest。下载地址：https://github.com/alibaba/mobileperf6)PyroscopePyroscope是一个开源的连续分析平台。能够帮你发现代码中的性能问题和瓶颈、CPU利用率高的原因。并且帮你了解应用程序的调用树，提供丰富的图表和调用树展示。官网地址：https://pyroscope.io7)MemoryLeakDetectorMemoryLeakDetector是由西瓜视频android团队开发的本地内存泄漏监视工具，它具有访问简单，监视范围广，性能优良和稳定性好的优点。它被广泛用于ByteDance的主要应用程序的本机内存泄漏管理中。官网地址：https://github.com/bytedance/memory-leak-detector服务端性能测试工具8)JMeterJMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java小服务程序、CGI脚本、Java对象、数据库、FTP服务器等等。JMeter可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。官网地址：https://jmeter.apache.org/9)LoadRunnerLoadRunner是一种预测系统行为和性能的负载测试工具。通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。官网地址：https://www.microfocus.com/zh-cn/portfolio/performance-engineering/overview10)WebLOADWebLOAD是一款针对Web应用程序的企业级负载和性能测试工具，提供性能、完整性和可伸缩性测试等功能，能够同时模拟数千个用户，因此您可以测试重流量负载，并报告应用程序中的弱点、约束和性能瓶颈。使用WebLOAD进行网站负载测试、连续测试、云负载测试等。该工具可以从云端或本地机器生成负载，并提供一个集成开发环境（IDE），用于可视化地记录、编辑和调试测试脚本。官网地址：https://www.radview.com/11)GatlingGatling是一款基于Scala开发的高性能服务器性能测试开源工具，同时也是一款功能强大的负载测试工具，开箱即用。Gatling主要用于测量基于HTTP的服务器，比如Web应用程序，RESTful服务等。Gatling是针对任何HTTP服务器进行负载测试的首选工具。官网地址：https://gatling.io/12)k6k6是高性能的负载测试工具，也是一种高性能工具，旨在在预生产和QA环境中以高负载运行测试，可使用JavaScript编写脚本。它是一个以开发人员为中心（当然，测试人员亦可以使用，因为真的很方便），免费和开源的负载测试工具，旨在使性能测试具有生产力和令人愉悦的体验，可最大程度地减少系统资源的消耗。官网地址：https://k6.io/13)VegataVegeta是一个用Go语言编写的多功能的HTTP负载测试工具,提供命令行工具和一个开发包。官网地址：https://github.com/tsenart/vegeta14)LocustLocust是使用Python开发的支持分布式的一款开源压力测试工具，可以通过写python脚本的方式来对web接口进行负载测试。Locust在单台机器上能够支持几千并发用户访问，并且由于其对分布式运行的支持，理论上来说，Locust能在使用较少压力机的前提下支持极高并发数的测试。官网地址：https://locust.io/分布式系统的性能监控工具在微服务架构的分布式系统中，当客户端发起一个请求时，往往会调用多个服务，涉及多个中间件，加上系统又分布在多台服务器上，因此，当系统出现性能瓶颈时，故障诊断就变得非常复杂。分布式系统的应用性能监控（APM）工具通过服务调用链追踪分析来定位链路上的性能瓶颈。在线性能监控是指借助监控工具，监控系统性能的实际数据，因为是真实数据，比研发环境中通过工具产生负载得到的测试结果更客观，更有分析价值。15)SkyWalkingSkyWalking是一款国内开源的优秀的APM工具，提供了一个分布式系统的直观的观测平台，用于从服务和云原生基础设施收集、处理及可视化数据，通过监控、告警、可视化和分布式追踪等功能为微服务、分布式，以及容器化的系统架构提供了可观测性（observability）。它可以观测横跨不同云的分布式系统，而且从SkyWalking6开始支持下一代的分布式架构ServiceMesh。官网地址：http://skywalking.apache.org/16）PinpointPinpoint是一个用于大规模分布式系统的APM（应用程序性能管理）工具，用Java/PHP编写。Pinpoint提供了一个解决方案，帮助分析系统的总体结构，以及通过跟踪分布式应用程序中的事务，分析系统中的组件如何相互连接，用于大型分布式系统的全链路监控，可以获取不同服务之间，服务与数据库，以及服务内部的方法的调用关系，还可以监控方法调用时长、可用率和内存等。下载地址：https://pinpoint-apm.github.io/pinpoint/分布式系统的全链路压测平台全链路压测是指模拟真实业务场景中的海量用户请求和数据访问生产环境，对整个业务链路进行全方位的、真实的压力测试，提前找到分布式系统的性能瓶颈点并持续调优的实践。目前企业大多采用的是基于开源工具Gatling、JMeter搭建压测集群进行全链路压测。同时，国内也有商用的全链路压测解决方案，如Perfma全链路压测解决方案、京东ForceBot平台、美团的Quake、高德的TestPG、字节跳动的Rhino、阿里妈妈的MagicOTP和性能测试平台ACP，以及阿里的AMAZON、PTS和JVM-SANDBOX平台。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：166

在汽车行业对软件开发重视的当下，不少从其他行业加入的，那熟悉ECU软件测试流程就是必要的了，另外对于一直在行业深耕的开发或测试人员，梳理一下测试流程也是有必要的。接下来我们以常用的V模型开发流程为线索，列举实例来说明。01.需求编写假如现在我写了一个系统需求，也就是图1中的“TechnicalSafetyConcept”:(PS：所有的TechincalSafetyConcept都是系统级需求，不是软件需求)系统需求：自适应巡航功能只能在30公里到120公里每小时之间激活.[ACC-SysReq001]；并且一旦退出后不可再自动激活[ACC-SysReq002]。简单起见，我们先看第一条需求，并把这条系统需求写成软件需求：软件需求：当以下条件满足时，ACC功能状态设置为READY[ACC-Req001]:车速大于或等于30kphAND车速小于或等于120kph.当满足以下条件时，ACC功能状态设置为SUPPRESSED[ACC-Req002]:车速小于30kphOR车速大于120kph.在软件设计文档中，也就是图1V模型中的ArchitectualDesign里可以写：DesignRequirementAcc_ActStshallequaltoREADYif:SafeVehSpdisgreaterorequalto30kphANDSafeVehSpdislessthanorequalto120kph.Acc_ActStshallequaltoSUPPRESSEDif:SafeVehSpdislessthan30kphORSafeVehSpdisgreaterthan120kph.到这里，以上就是一个最简单的需求demo。根据这个需求，你通过几行代码来实现。假设使用C来写，在原有的C文件acc.c中加入了：if((SafeVehSpd>=30)&&(SafeVehSpd...

2021-12-30点击量：103

1，当你是一个项目的的测试负责人的时候，你有没有过质问过项目成员为什么没测试出某个具体的bug，或者因为某人没有测出bug而直接责备他？2，当你提升了测试覆盖率的时候你有没有发现产品的bug数量其实没有发生变化？3，你有没有在发布之前花费了大量的时间去进行测试却最终发现一无所获，而发布之后bug却不期而至？4，开发可以测试他们自己的代码吗？5，bug真的是发现的越晚修复成本就越高吗？6，你有没有过以不按套路出牌的方式来进行软件的测试，并称之为“探索性测试”？7，你是否需要通过QA活动来提升产品质量？真相1：测试并不能找出所有的bug很不幸这是真的，没有任何一种测试方式可以保证找出所有的bug。一些测试活动跟直接上手点点点相比确实效率要低一些，所以我们可以不用那么关注测试的类型，相反我们要做的是选择合适的测试类型并综合使用，从而以最少的工作量打到较好的效果。（比如ui的自动化测试如果要做到非常复杂那么将花费相当大的开发和维护成本，但没有ui的自动化，每轮测试都靠人肉点来点去也不现实，所以比较合适的做法是一些稳定的核心路径可以用ui自动化去实现，平衡投入产出比，用较少的工作量达到效率最大化）当有人抱怨为什么测试没有发现某些问题的时候麻烦提醒他们：测试确实没有办法保证一定会发现某些特定的缺陷。我们会经常复盘测试的漏测情况，很不幸，这是落后的想法，这就像是在魔术揭秘了之后再马后炮的说其实这个戏法很简单，很容易被识破一样。事后做漏测复盘并不是一个有效的分析手段。永远不要责备测试工程师，他们并没有写出bug，相反，他们一直在努力找出开发过程中引入的缺陷。没有什么是完美的，测试同学在接受现实的同时也需要记住千万别立flag，因为测试不可能发现所有的bug。真相2：测试覆盖率与测试的效果几乎没有相关性是的，你没有看错。我们已经有足够的科学证据表明，增加单元测试覆盖率不一定会提高我们测试套件发现bug的效率！也许是时候关注与测试相关的内容而不是正在测试的代码量了。（这里作者的原话是Wealreadyhaveenoughscientificevidencetosaythatincreasingunittestcoveragemaynotnecessarilyincreaseyourtestsuiteeffectivenessinfindingdefects!直译过来就是单元覆盖率的提升并不会提升测试套件发现缺陷的效率，说实话，我觉得单元测试覆盖率跟测试中发现bug的效率本来就没有什么关系，覆盖率代表的是代码被测试的程度，而发现bug的效率指的是时间和产出的关系，发现bug的效率高并不代表着产品的质量就好，反之亦然。不过看下文引用资料时的描述，我们可以看到作者的举证基本上都透露了一个信息，那就是单元测试覆盖率与bug的数量之前没有太多的关联，换句话说就是并不是单元测试覆盖率越高，产品的质量就越好，因为产品的质量好一般意味着可被观察到的bug相对少，而bug又跟单元测试覆盖率无关。这里为了严谨，作者的引用我就不做翻译了。）1.*A.Mockus,N.Nagappan,andT.T.Dinh-Trong,“TestCoverageandPost-verificationDefects:AMultipleCaseStudy,”Proc.3rdInt’lSymp.EmpiricalSoftwareEng.andMeasurement(ESEM09),2009,pp.291–301.*Thecorrelationbetweencoverageanddefectswas**noneorveryweak**.Moreover,theeffortrequiredtoincreasethecoveragefromacertainlevelto100%increasedexponentially.2.*M.R.Lyu,J.Horgan,andS.London,“ACoverageAnalysisToolfortheEffectivenessofSoftwareTesting,”IEEETrans.Reliability,vol.43,no.4,1994,pp.527–535.*Qualitativeanalysisfound**noassociation**betweenthedefectsandcoverage.3.*B.SmithandL.A.Williams,ASurveyonCodeCoverageasaStoppingCriterionforUnitTesting,tech.reportTR-200822,Dept.ofComputerScience,NorthCarolinaStateUniv.,2008,pp.16.*Theresults**didnotsupportthehypothesisofacausaldependency**betweentestcoverageandthenumberofdefectswhentestingintensitywascontrolledfor.4.*L.BriandandD.Pfahl,“UsingSimulationforAssessingtheRealImpactofTestCoverageonDefectCoverage,”Proc.10thInt’lSymp.SoftwareReliabilityEng.,1999,pp.148157.*Theresults**didnotsupportthehypothesisofacausaldependency**betweentestcoverageandthenumberofdefectswhentestingintensitywascontrolledfor.5.*P.S.Kochhar,F.Thung,andD.Lo,“CodeCoverageandTestSuiteEffectiveness:EmpiricalStudywithRealBugsinLargeSystems,”Proc.IEEE22ndInt’lConf.SoftwareAnalysis,Evolution,andReengineering(SANER15),2015,pp.560-564.*A**moderatetostrongcorrelationwasfound**betweencoverageanddefects.However,the**coveragewasmanipulatedandcalculatedmanually**.6.*L.InozemtsevaandR.Holmes,“CoverageIsNotStronglyCorrelatedwithTestSuiteEffectiveness,”Proc.36thInt’lConf.SoftwareEng.(ICSE14),2014,pp.435445.*A**weaktomoderatecorrelation**wasfoundbetweencoverageanddefects.Thetypeofcoveragedidnothaveanimpactontheresults.7.*X.CaiandM.R.Lyu,“TheEffectofCodeCoverageonFaultDetectionunderDifferentTestingProfiles,”ACMSIGSOFTSoftwareEng.Notes,vol.30,no.4,2005,pp.1–7.*A**moderatecorrelation**wasfoundbetweencoverageanddefects,butthe**defectswereartificiallyintroduced**.Thecorrelationwasdifferentfordifferenttestingprofiles.8.*G.Gayetal.,“TheRisksofCoverage-DirectedTestCaseGeneration,”IEEETrans.SoftwareEng.,vol.41,no.8,2015,pp.803–819.*Coveragemeasureswere**weakindicatorsfortestsuiteadequacy**.**Highcoveragedidnotnecessarilymeaneffectivetesting**.真相3：测试工作量呈指数增加许多消息来源指出，测试人员会在测试活动开始时发现更多缺陷，而在结束时发现缺陷则更少。有迹象表明，为了找到下一个缺陷，增加覆盖率和执行测试的工作量呈指数增长。在论文“TestCoverageandPost-verificationDefects:AMultipleCaseStudy,”(A.Mockus,N.Nagappan,andT.T.Dinh-Trong,Proc.3rdInt’lSymp.EmpiricalSoftwareEng.andMeasurement(ESEM09),2009,pp.291–301.)中透露：将覆盖率从某个水平增加到100%所需的努力呈指数增长。根据“Implementingautomatedsoftwaretesting:Howtosavetimeandlowercostswhileraisingquality.”(Dustin,E.,Garrett,T.,&Gauf,B.(2009).PearsonEducation.),的阐述：软件可靠性模型表明，随着在测试中投入更多时间，每单位时间发现的缺陷数量呈指数减少。真相4：开发者偏差如果开发人员在开发阶段直接把一个需求理解错了，那么他写出来的代码就是错的，对于测试人员来说情况也一样。如果开发同学直接忘记在代码中处理某些情况，比如特定的条件验证，那么他也很可能不会记得对这种场景进行测试。为了避免这种情况，开发人员可以互相测试彼此的代码，但他们最好不要测试自己的代码，这就是所谓的交叉测试。在没有设计任何测试用例的情况下，开发同学还是可以测试自己的代码的，这样就可以尽可能的避免一些先入为主的偏差。测试驱动开发可能会降低开发忘记做某事概率，但不会减少误解某些需求的概率。真相5：晚期发现的缺陷可能不会花费更多来修复这上面的数字可能是有水分的，LaurentBossavit是巴黎软件咨询公司CodeWorks的敏捷方法论专家和技术顾问，他在github上的文章“Degreesofintellectualdishonesty”就透露了这些信息可能是被捏造出来的。在一篇名为“Aredelayedissueshardertoresolve?Revisitingcost-to-fixofdefectsthroughoutthelifecycle”(Menzies,T.,Nichols,W.,Shull,F.etal.EmpirSoftwareEng22,1903–1935(2017)https://doi.org/10.1007/s10664-016-9469-x)的论文指出：没有发现任何证据表明在代码投入生产后进行缺陷的修复需要花费更长的时间。论文“WhatWeHaveLearnedAboutFightingDefects”(ForrestShull,VicBasili,BarryBoehm,etal.,Proceedingsofthe8thInternationalSymposiumonSoftwareMetrics(METRICS‘02).IEEEComputerSociety,USA,249.2002.)中，作者指出：修复某些非关键bug的成本在整个生命周期阶段几乎保持不变（项目早期平均1.2小时，项目后期平均1.5小时）。不过很多的研究都在度量定位错误和修复bug的工作量，那么他们忽略了什么？回归测试：在发布之前我们要进行频繁的回归，为了验证某些重要的bug已经被修复了，我们就需要一次又一次的对主流程甚至是大部分的逻辑进行回归测试，这显然是很巨大的工作量；机会成本：在项目的晚期发现问题的时候，很多人往往会将bug排到下一个版本或项目，这很可能导致项目延期交付；企业商誉成本：企业可能会被罚款，客户可能会亏钱，用户体验自然也就不好。2020年12月，游戏《赛博朋克2077》因发售时出现诸多技术问题而从索尼商店下架。索尼提供全额退款。随后，开发商CDProjektRed宣布对PS4和Xbox玩家进行退款。在投资者电话会议上，CDProjektRed表示“与恢复公司声誉相比，《赛博朋克2077》修复的成本“无关紧要”。该公司的股票已从2020年12月的每股31美元跌至2021年6月的每股10美元。bug并不是在代码中引入的。比如在项目的初期做技术设计的时候就存在缺陷，或者需求本身就是个bug，那么越晚发现灾难就越大。因此，虽然发布后修复代码错误的工作量可能不会增加那么多，但早期修复bug可以节省大量精力、金钱和麻烦。真相6：探索性测试需要流程和文档很多人认为如果他们对产品做一些无法预料结果的操作，比如在表单胡乱输入并且提交，那么他们就是在做探索性测试。其实探索性测试并不意味着你要对系统或者产品做一些特别的事情，它往往意味着我们需要了解系统是如何真正工作的，并且与普通的功能测试同时进行。换句话说探索性测试可以（并且最好应该）得到现有文档的支持，例如需求文档和设计文档。这里的区别在于探索性测试的测试用例不是预先编写好的。探索性测试可以脚本化，一旦发现问题就可以把bug记录在案，然后可重复执行的脚本又可以在后面的测试过程中反复使用。（比如探索测试时可以使用浏览器自带的录制功能，发现bug之后就把录制好的脚本保存下来，给后面的回归测试使用，chrome现在已经自带了录制能力了）。测试用例仍然应该使用边界值分析、等价类划分等技术来设计。我们没有理由设计一些随机的测试用例，因为它们在检测缺陷方面可能不具有成本优势或有效性。真相7：改进流程中的非质量保证活动可以提高产品质量（这里原文的论述我实在是没弄明白并且找不到合适的数据支持，所以就简单的粘贴英文版本了）A2009studyinBrazil(inPortuguese)involving135softwaredevelopmentorganizationshadtheircapacitytoidentifyandfixdefectsincreasedbyimprovingtheirprocesses.ThesecompanieswerepartofaBraziliansoftwareprocessimprovementprogramcalled“MPS.Br,”wheretheyshouldadheretoasoftwareprocessimprovementmodel(theMPSModel).Thismodelhasstages,and58ofthesecompanieswereinthefirststage,wheretheywererequiredtoimprovetheirProjectManagementandRequirementsManagementprocesses.Whileit’sunclearwhythishappened,wecanreasonablyexpectthatprojectsthatidentifytherightpeopletoparticipateintheteam,trainingneeds,andproperbudgetandschedulewilllikelyhavethepeople,thetime,andotherresourcestoimprovequality.奖励关（有趣的事实）：百慕大计划好吧，这是一个有趣的，但没有解释的事实，它可能真的不起作用。百慕大计划是更快完成项目的战略名称。将团队的一部分派往百慕大（即，将他们从项目中移除），项目会更快完成。它被认为是对布鲁克斯定律（Brooks’slaw）的回应（对软件项目管理的一种观察，根据该定律，“在延期的软件项目中增加人力会让项目交付的更慢一些”）。那么，如果您移除人员，项目是否应该进行的更加迅速？根据我的经验，加入团队的每个新人都会占用一个老人工作时间的1/3左右，直到新人们逐渐提高生产力。因此，踢走最近加入的人可能真的会提高工作效率。如果团队中有太多冲突，它可以起作用的其他原因是：移除与团队目标不一致的人可能会对团队有所帮助。如果团队中有太多人，那么沟通开销可能会大到足以阻碍生产力。在这种情况下，拆分团队可能效果很好（这在技术上与从项目中移除人员不同）。否则，移除人员只会降低团队在短期内的输出。无论如何，我只是在分享百慕大计划，因为谈论它总是很有趣。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：128

1前言本文介绍了一些测试工具，它们可以帮助我们快速、有效地交付。Tricentis主导的一项全球调查为我们提供了几个有关测试趋势的重要观察。趋势表明，团队倾向于使用功能测试，这可以理解，但是手动测试也将保留下来。怎么选择测试框架？这有一些标准：相对快速和方便设置（或开箱即用的解决方案）支持社区或开发者自己可以为其框架提供支持有清晰而全面的文档与其他工具充分集成有一些很酷的功能，例如代码可重用性支持在多个平台和环境进行测试2Selenium（功能测试）Selenium诞生于2004年，它已经逐渐成为QA工程师的必备测试工具。它在GitHub上有近20000Star，是市场上最受欢迎的功能测试工具之一。一般来说，Selenium是一个涵盖几种工具的生态系统：SeleniumWebDriver、SeleniumIDE和SeleniumGrid。Selenium核心特性跨浏览器和跨平台测试多种测试语言（Python、Java、C＃等）高度可调整的开源代码并行运行测试Selenium亮点特性具有详细文档和庞大支持者社区的开源工具最新更新Selenium4（拦截网络流量、Chrome浏览器调试协议等）3Ranorex（功能测试）Ranorex是一款端到端的功能测试工具，具有自动超时处理、动态网页元素识别和内嵌页面对象映射。Ranorex核心特性跨浏览器和跨平台测试具有回归、数据驱动、关键字驱动测试选项扩展的、详细的报告可用于真实及模拟iOS和Android设备的自动化测试Ranorex亮点特性GUI对象识别，非常适合黑盒测试最新更新对于失败的测试进行智能修复4PractiTest（探索性测试）PractiTest本来被定位为应用生命周期管理方案的一体化工具，即该工具提供了手动和测试自动化管理选项。但是，最令人感兴趣的部分是探索性测试功能。PractiTest核心特性测试用例管理问题状态管理可定制的仪表板，并附有详细报告可重用的测试数据结构从运行中可自动提交bug与其他工具集成：Jira（云、数据中心、服务器）PractiTest亮点特性直观的探索性测试的趋势跟踪最新更新数据项目演示导入导出的可追溯性5LoadNinja（负载测试）LoadNinja是一个性能和负载测试框架，用于诊断API和UI性能问题。LoadNinja具有内置的TrueLoad技术，与传统的按协议进行的性能测试相比，该技术可使测试终端用户体验的速度提高60％。LoadNinja核心特性数以千计的在真实浏览器上的用法测试脚本的录制和回放问题实时诊断LoadNinja亮点特性使用RESTAPI和自定义CI/CD插件进行自动化负载测试最新更新对于手动停止的测试可下载CSV报告可以对录制页面与回放页面进行比较6Optimizely（UI/UX）Optimizely是一个强大的UI/UX测试工具，可以对网站或者应用中重新设计或实现的新特性进行演练测试。该工具主要用于在推出新特性前验证变更，以减少失败的风险。Optimizely核心特性A/B测试构建及运行顺序测试新功能FDR错误控制借助snippets轻松集成到代码中Optimizely亮点特性使用API控制实验，并可随时监控统计信息和实验结果最新更新OptimizelyAgent将框架部署到所选的基础设施提供者7SonarQube（安全性测试）SonarQube是一个安全性测试工具，可在代码审查期间提供代码库漏洞检测和协助。SonarQube核心特性多语言覆盖（27种编程语言）可疑代码段检测与GitHub、GitLab、AzureDevOps、Bitbucket集成SonarQube亮点特性对代码热修复有详细漏洞描述最新更新JavaScriptSAST分析和AzureDevOpsServer集成对于C++的支持更强8Cucumber（验收测试）Cucumber是一个行为驱动的开发测试工具，用于增强终端用户的体验。Cucumber涵盖几个产品：CucumberOpen（可执行的规范验证）、CucumberStudio（BDD协作平台）和CucumberSchool（培训和教程）。Cucumber核心特性与源代码控制系统集成对不喜欢编码的人来说，这是一个非常合适的框架对客户来说容易理解，是一种语法简单的Gherkin语言大量面向业务的文档兼容多种语言，包括Java和PythonCucumber亮点特性使用行为驱动开发最新更新CucumberStudio：BDD的协作平台9SoapUI（API功能测试）一种功能模拟测试工具，主要使用数据驱动方法，提高了测试覆盖率。SoapUI核心特性用于公共或第三方API的安全性测试脚本化测试创建使用“虚拟用户测试”工具进行API性能测试详细全面的报告SoapUI亮点特性虚拟化模拟和API预发布测试最新更新APIExplorer，一种API响应的即时调试器10TestNG（单元测试）TestNG是基于Java的单元测试工具，受非常流行的工具NUnit和JUnit启发。与NUnit和JUnit相比，TestNG具有更加强大的功能，使其成为集成和端到端测试的多功能工具。但是，它还是最适合于单元测试。TestNG核心特性多线程测试执行数据驱动的测试支持使用JDK方式提供日志和运行借助IDE插件或使用了build.xml的ApacheAnt，从而得以灵活执行TestNG亮点特性并行测试：具有多种可用方法和策略的大线程池最新更新通过回调支持测试重试可以禁用通过SPI加载的强制侦听11MantisBT（手工测试）MantisBT是一个开源的缺陷记录工具，专门为QA工程师和测试人员而设计。它提供本地和托管的安装环境，并支持所有运行PHP的平台（Windows、Linux、Mac）。MantisBT核心特性内置报告选项从时间跟踪工具到聊天工具的多样化集成适用于台式机和移动设备与您选择的插件兼容多DBMS和多语言库支持MantisBT亮点特性具有可跟踪进度的路线图工具，可用于发布计划最新更新完全兼容PHP8.012QA工程师可能用到的其他工具Jenkins这是一款领先的CI工具，可以成功地运用于实时测试代码库变更。它还是一个可以整合到测试过程中并使某些关键过程自动化的好工具。GitHubGitHub是成百上千万开发人员使用的版本控制存储库。许多QA工具可以链接到GitHub帐户，以便自动记录报告缺陷。例如，当使用GitHub进行缺陷跟踪时，您可以在其他测试工具上运行手动测试。TextShortcodeTmux是一种流行的虚拟终端复用器，用来管理一个终端窗口中运行的多个终端会话。您可以将它们与一个终端分离，然后将这些会话附加到另一个终端上，并使用命令行界面，而不必将它们从一个会话中转储并启动另一个会话。它类似于GNUScreen，但不同之处在于它经伯克利软件发行（BSD）授权许可。https://www.gnu.org/software/screen/?fileGuid=gRrcHdyDyVX6TVGX13结论每个月都会出现新框架，而且现有框架也在不断地演进。希望这份清单可以帮你选出合适的测试工具。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：168

功能测试的自动化工具，除了之前介绍的单元测试工具、接口测试工具，还有一大类工具——就是今天要介绍的基于UI的功能测试工具，它主要是通过操控UI元素（如菜单、按钮、图标、文本框、列表、对话框等）来驱动系统事件发生，并查看系统的表现（主要是UI表现，如屏幕验证、新的GUI元素的显示、UI元素大小和位置的改变、文字及其排列、可用性条件和数据完整性等）作为验证点来完成。基于UI的功能测试工具常常有录制和回放功能，能够录制UI的操作过程，即捕获到键盘&鼠标操作并记录下来，然后在之后回归测试中再通过回放之前录制的过程来验证原有功能是否正常。但人们更希望写结构化的自动化脚本，再演化为关键字驱动脚本和数据驱动脚本，这样有利于脚本的复用和维护。再继续演化，不是简单的“自动录制操作过程”，而是依赖于基于模型的测试（MBT）和AI技术来构建测试模型生成测试脚本，或录制操作过程生成操作路径，这样就形成一类新的UI测试工具——无代码的功能测试工具，可以参考之前发表的文章：2020年软件测试趋势报道：无代码化的测试自动化。基于UI的功能测试工具很多，由于篇幅所限，不能一一介绍，像大家特别熟悉的Appium、AutoIT、Selenium/Watir、TestComplete等工具就不介绍了，有些工具在接口测试、嵌入式软件工具中介绍过的，这里也不重复介绍，如KatalonStudio、Squish等，而我们把重点放在比较流行、有特点的工具上，也会倾向于成熟的开源工具等。像RobotFramework、Cucumber等属于BDD测试框架，也不在UI功能测试工具范围内，所以最终选择下列十大工具：1.CypressCypress是面向web的、端到端的、开源的自动化测试工具，在github的star数目前已经是35.2k+，可见深受广大测试人员的欢迎。Cypress能够随意调整页面访问窗口的尺寸、自动重新加载测试、自动等待等，可以实时看到有多少个测试通过或是没通过，并且具有良好的可调试性，像chrome的DevTools一样直接调试，可以快速的追踪到出错栈，可以在测试运行中自动存储视频以及出错时候截屏存储，鼠标滑过命令行时可以看到这个命令行执行时的动画。官方站点：https://www.cypress.io/开源代码：https://github.com/cypress-io/cypress2.LambdaTestLambdaTest是领先的跨平台、跨浏览器测试自动化工具之一，可在基于云的Selenium网格上针对桌面、Android和iOS移动浏览器进行Selenium自动化测试。它还集成了开发者工具，有助于在实时测试中调试问题，LambdaTest与JIRA，Asana，Github，Trello，Slack等项目管理工具集成在一起，从而轻松地与CI/CD流水线集成。官方站点：https://www.lambdatest.com/3.MaveryxMaveryx是一种具有开拓性的功能自动化UI工具，为广泛的桌面和Web技术提供了功能UI、数据驱动和关键字驱动测试能力。Maveryx获取正在运行的应用程序用户界面的快照，并借助内置强大的智能对象识别引擎以标识要自动测试的UI元素，所以测试人员不需要创建/维护对象库、UI地图等；也可以使用关键字驱动的框架，以EXCEL格式创建复杂的测试。Maveryx是一个Java和C#库的集合，可以从Eclipse和VisualStudio等IDE中导入项目，而且Maveryx测试可以从命令行运行，这样任何CI服务器（如Jenkins）更容易集成/触发Maveryx构建的回归测试，支持CI/CD。官方站点：http://www.maveryx.com/4.KobitonKobiton也是一种面向移动应用的、低代码或无脚本技术的测试工具，可以在各种移动设备、针对不同技术的应用来验证UI和用户体验，甚至可以实现自动自我修复测试脚本，并完全支持Appium,Selenium,XCUI,Espresso，集成到所有的CI/CD平台上，最终确保获得良好的深度和广度的测试覆盖。官方站点：https://kobiton.com/5.RanorexStudioRanorexStudio是一个商业化的WindowsGUI测试自动化工具，全球有4000多家公司使用它来测试桌面、web和移动应用程序。对于初学者，它的使用也简单，可以使用无代码的点击式界面和有用的向导，但它也适合资深的自动化测试专家，有很强的功能，如可靠的对象标识（即使对于具有动态id的web元素）、可共享的对象存储库和可重用的代码模块、可定制的测试报告、并行运行测试（支持seleniumGrid）等，能与Jira、Jenkins、TestRail、Git、TravisCI等工具集成。官方站点：https://www.ranorex.com/6.SahiProSahiPro可以说是唯一的低代码测试自动化平台（其实不是），以简单而稳定的方式识别跨技术的元素，执行鼠标、键盘和触摸操作，支持Web、桌面、移动、Webserivce等。SahiPro的技术消除了对语句的等待，甚至对不一致的页面加载也不需要，从而使测试很稳定。SahiPro。SahiPro甚至可以在具有动态ID的应用程序上工作。能够使用内置的业务驱动测试自动化（BDTA）框架，支持并行执行和在不同的机器上分发测试。官方站点：https://www.sahipro.com/7.SikuliXSikuliX是一个基于图像识别的、开源的UI测试框架，可以针对Windows、Mac或一些Linux/Unix的桌面计算机屏幕上能看到的任何东西实现自动化测试，因为它使用由OpenCV驱动的图像识别来识别GUI组件，而无需了解隐藏着GUI下面的程序内部信息。除了在屏幕上定位图像外，SikuliX还可以运行鼠标和键盘，与确定的GUI元素进行互动，并带有基本的文本识别（OCR），可用于搜索图像中的文本。官方站点：http://sikulix.com/8.Subject7Subject7涵盖Web、移动应用、桌面、数据库、WebService（REST/SOAP）、负载测试（有负载生成引擎）、安全测试（主动或被动安全检查）等测试，它利用AI-enabledXPath生成引擎和NextGenRecorder和无代码网络界面实现了真正的无代码自动化，加速了测试的编写和维护，并通过并行的云端执行进行能力的扩展，Subject7平台通过一系列命令提供了端到端的测试自动化功能。这些命令可通过易于使用的Web界面使用，隐藏了诸如Selenium、Appium、SikuliX、JMeter、ZAP等行业标准软件包的复杂性，但也可以在UniversalRunner中直接使用现有的Selenium、Appium、SikuliX、JMeter、ZAP脚本。它也容易集成到JIRA，Jenkins，GitHub或任何DevOps平台中，以实时持续测试。官方站点：https://www.subject-7.com/9.TelerikTestStudioTelerikTestStudio是基于Windows的商业软件测试工具，带有VisualStudio插件，将无代码和基于代码的自动化功能融合在一个直观的用户界面中，使任何人都可以使用它进行自动化测试。它有直观的测试记录器，支持跨浏览器和智能混合元素检测，可以实现Headless浏览器测试（可用于ChromeHeadless，并能以完全无代码的方式加以利用），大大减少测试执行和提高测试的稳定性，并支持支持OCR的PDF验证、数据驱动的测试、集成调度和远程测试执行和CI/CD集成，支持JavaScript、HTML、ASP.NET、Ajax、Silverlight等各种技术。官方站点：https://www.telerik.com/teststudio10.TestsigmaTestsigma是一款基于云端的、支持测试左移的、以AI驱动测试的自动化平台，为Web、移动应用以及RESTful服务等各种应用的测试服务。功能测试人员可以轻松地使用自然语言编写出简化的测试脚本，并通过可重用的步骤组合和集中对象存储库，从而最大限度地提高了测试代码的重用性。Testsigma能够与各种开源的或第三方工具相集成，为持续测试提供所有必需的功能，如数据驱动测试、跨浏览器测试、可重用性测试套件、测试计划与数据管理、电子邮件与Slack通知、并行测试执行、集中对象/元素存储库、综合报告、与CI工具的集成、以及自动化Bug报告等。官方站点：https://testsigma.com/本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-30点击量：169

岁月是把杀猪刀悄咪咪地架在我们的脖子上我们这些别人眼中的“老司机”一直行走在IT行业的测试老鸟已经/正在/即将踏上35岁的尴尬年龄面临前有强敌，后有追兵的复杂境况所以你身边35岁以上的测试员，现在都在干嘛？面对这样的灵魂拷问总是有人欢喜有人忧……来看看他们的答案，找到自己要走的路！@享受现在“25和35有区别吗？反正你都得拼了命的找bug，除了赚钱请别跟我谈别的”@曾经的王者，现在的青铜“作为高考精英进入了测试这一行，让我有了很强的优越感。然而IT行业日趋迅猛，长江后浪推前浪，35岁的测试员如果想凭学历和经验站稳脚跟不太现实，技术更新迭代太快了，终会被年轻人碾压。”@趁年轻，一定要足够优秀“不拼搏，枉少年！在20来岁的黄金年纪，瞄准目标，奋力一搏。一定要优秀过，才配得上自己最初选择的职业。我这不是心灵鸡汤，纯粹经历感悟，加倍努力才能毫不费力。不然到35岁后，就只能做做浑水摸鱼的差事。”@35岁想转行了“没想到也会有今天，中年危机来的猝不及防，上有老下有小，35岁的老IT人的确很尴尬，想混上高管，无奈能力不够，继续当小兵，又心有不甘，想转行了，来得及吗？”@家有余粮，心里不慌“有资源、有客户、有管理经验、技术又好，莫慌！”@看见“蛋蛋”后，心慌慌“老胳膊老腿了，还要跟00后抢饭碗，我太难了！”@穷忙穷忙，越穷越忙，越忙越穷“刚过完35岁生日，生日愿望是想出去看看外面的世界，但一天天吭哧吭哧穷忙穷忙，连抽根烟的时间都没有，没办法，谁叫我穷呢！”@10年没更新过简历，危机感满满“不光是我，我周围大部分人，都十几年没碰过简历了，安于现状是挺好的，但总是莫名的慌张。于是我总结出：没空更新简历，但要不断更新技术！”看着上面小伙伴们的留言，我也惭愧的低下了头。没错，35岁对于IT人而言确实是一条明晃晃的分割线，对线里的人而言是中年危机，而对线外的人来说就是养老保险。35岁以上的软件测试员，都去干嘛了？01技术不够，中年危机做了测试这么多年，你应该会发现一个现象：一个初出茅庐、毫无经验的“测试小白”，要比一个35岁以上、经验丰富的“测试老鸟”更容易拿到offer。很多人不解，却也只能认命，其实企业也有自己的考量，除了选择人才，用人成本的把控同样重要。你会疑惑，刚毕业的学生、零基础的转行者的优势究竟在哪里呢？没错，他们技术不够，经验不足，但他们有测试功底，坚持学习，加班加点无怨言，最重要的对薪资待遇的要求不高，很多企业会选择他们作为第一录用对象。也正是因为这样，35岁以上的测试员要面临尴尬的处境。还记得前段时间看到的那条新闻：一名35岁的成年人遭遇互联网公司的无情裁员，找工作太难，面试屡屡碰壁，面对巨大的房贷车贷等生活压力，独自在天桥哭泣，照片中的他孤独、无奈，让人心疼。对于这个年龄的测试员来说，除了工作压力，生活压力更大，年纪越大，身体愈发力不从心，曾经的进取心也会被消耗殆尽，中年危机随之而来。这也给我们敲响了警钟：成年人的生活，太不容易了！如果你想在测试这个行业一直做下去，35岁之后，凭什么让一家企业继续任用你？你的经验和功能测试技术是远远不够的，你需要进阶，你需要丰富你的技术栈！02技术过硬，“铁饭碗”当你能力过硬，持续学习，持续思考，经常总结经验，选对职业发展路径，那软件测试就是养老保险。作为测试从业者，你的发展方向：①深入技术方面（熟悉开发架构、开发语言、网络结构、DB体系、Linux等）你的职业发展如下：测试开发工程师（薪资高，发展好，但技术要求较高，赋能于整个测试部门）自动化测试工程师（主要职责：规划方案策略）性能测试工程师测试架构师（主要职责：了解行业趋势，技术方向发展，会开发框架）高级测试工程师（或资深测试工程师）测试专家安全测试工程师②管理层（需要机遇，能力加持）测试组长、主管、经理（主要职责：部门内部人员管理、部门资源争取、KPI考核）项目测试负责人（研发、产品等）测试总监CTO、CEO③培训老师④其他方向产品经理项目经理（以项目交付为原则、以整体时间把控为原则）运营售后咨询顾问技术支持创业销售（需要具备一定的技术功底）35岁本该是职业发展的巅峰时期不料对于IT人而言却恰恰是一道坎！“优胜劣汰，适者生存”是自然法则只有不断学习新技术，才能避免“中年危机”选择了软件测试这一行，何不继续“死磕到底”！本文由培训无忧网长沙牛耳教育课程顾问老师整理发布，希望能够对想参加长沙软件测试培训的学生有所帮助。更多软件测试培训课程信息可关注培训无忧网电脑IT培训或添加老师微信：15033336050...

2021-12-27点击量：141

你为什么要写自动化测试？为什么该选择用人工测试而不是自动化？什么时候该做这样的选择呢？事实上，几乎所有的测试工程师早晚都要面对的问题就是是否选择自动化以及自动化测试的程度。如果你只打算执行一次测试，根本没有必要自动化。可是，如果你打算测试两次呢？这也不意味着你应该使用自动化。有些软件在发布之前或者在维护阶段，可能需要执行上百次，上千次，甚至百万次的测试。有些因素有助于在具体环境下准确地评估自动化的益处。如下是其中几个需要考量的因素：1、投入确定创建自动化测试的投资回报率（ROI--ReturnOnInvestment）的第一步是确定要花费的投入和成本。有些种类的产品或功能的自动化很简单，而其他的自动化却不可避免得很麻烦。例如，应用程序编程接口（API--ApplicationProgrammingInterface）测试，以及别的通过编程对象的方式展现给用户的功能测试，对其自动化往往都能够直截了当。而在另一方面，用户界面（UI--UserInterface）的自动化测试常会遇到问题而需要花费更多的精力。2、测试的生命期一个自动化测试在变得无用之前将会运行多少次？对测试的长期价值的评估是决定是否对某个特定的场景或者测试用例实现自动化的考量的一部分。要考虑被测试的产品本身的使用寿命和产品开发周期长度。对于短期内就要发布而且将来不打算更新的产品，和对于两年后要发布将来也会有多次更新发布的产品，自动化的选择必须是不一样的。3、价值要考虑自动化测试在其生命周期内的价值。有些测试人员说测试用例的价值是找到缺陷，但是很多自动化测试所找到的缺陷是在测试第一次运行时或者在写自动化测试时发现的。当缺陷被修复以后，这些测试成为了回归测试——确认最近的改动不会导致以前能够正常运行的功能停止工作。很多自动化测试技术通过改变测试用的数据，或者改变每次测试运行路径的方法，从而在测试的生命期中继续找到缺陷。对一个生命周期很长的产品来说，不断增长的回归测试套件有很大的优势：随着底层软件功能越来越复杂，存在大量的能确认以前工作的功能能够继续工作的测试是极为有用的。4、切入点我目睹的许多成功的测试自动化项目都是测试团队从最开始的时候就参与了。代码写到尾声或者完成之后才开始想到加入自动化测试的项目通常都是失败的。----注---测试团队什么时候能参与项目的自动化测试过程中、项目时间安排是否允许加入自动化实施过程、测试人员的工作负载是否允许、人力资源的投入多少等都可能影响测试人员的自动化实施工作及效果。5、准确性好的自动化测试在每次运行后会报告准确结果。企业管理层对自动化测试最大的抱怨之一是自动化测试中误报的数量。误报是指测试报告中的测试失败是由测试本身的某些问题造成的，与产品无关。项目的有些领域（例如经常变化的用户界面组件）难以用自动化测试分析，且较容易产生误报。本文由培训无忧网千锋教育专属课程顾问整理发布，希望能够对想学习软件测试培训的同学有所帮助。更多软件测试培训课程欢迎关注培训无忧网软件测试培训培训频道或添加老师微信：15033336050...