最近的用例评审让我感受颇深，以下是我对于测试用例评审的一些感受，发出来供大家讨论学习。 听听大家对测试用例评审的吐槽？ “测试用例设计是测试的事情，为什么评审要我们参加？”...“测试用例已经很多了，不知道需要评审什么，我能提供什么？” “用例评审太枯燥了，200个用例case用一条一条评吗？” “这个是别人的开发的功能，跟我没关系。”...开发可以从实现层面评审用例，补充测试用例中，由于测试人员不了解实现过程导致的测试用例缺失的情况。...2、评审的流程 测试人员确定评审日期和参与评审人员 评审前2天，测试用例发给所有评审人员 评审人员记录测试用例问题 评审会议，测试用例编写人员讲解用例，参与人员提出评审 会议结束，修改用例，并邮件输出...3、评审的内容 1、描述是否清晰，是否存在二义性 2、内容是否完整,是否清楚包含输入条件和预期输出结果并无争议点 3、是否覆盖了所有场景、逻辑分支、限制条件等 4、是否哪些需求不可测：无法准备环境、可测试性达不到等等原因
我见过同事埋冤甚至咒骂写单元测试这件事情，我其实很能理解他们的心情而且我也清楚症结在哪里（浪费太多精力在创造完成断言的前置条件上），其实就差这一层窗户纸，只要能理解“隔离”这两个字在单元测试中的意义就能捅破它...其实但凡是测试其基本原理都是一样的：你给测试用例一种输入，然后断言其结果，最后执行并观察断言是否正确；以此类推，你写 N 个测试用例，每一个都覆盖某种可能的输入（边界条件）并断言可能的结果（结果可能是返回值...之后就是运行代码看它失败，接着写代码让它成功，此时你有了可靠的测试用例于是可以立即着手优化或重构代码，直到最终交付。 所有的测试都是如此，不是么？...2、测试产生的失败分为两种，一种是代码抛出的异常（比如说类或方法不存在，某处写错了名字等等），另一种是断言的条件没有满足（其中也可能包括对于异常处理的断言哦，要注意区别）。...严格来说，只有第二种才叫测试失败，第一种应该算是语言本身的正常反应（你写错了嘛），所以一定要注意区分二者。绝大部分情况下这两种情形的输出都是有显著差异的，所以应该不难辨别。
之前开发的接口测试平台https://github.com/liwanlei/FXTest，今天的时候，想开发一个将测试用例转化成Jmeter压测脚本的功能。想着还是在原来的框架下做开发。...那么我是怎么构思的呢。 目的： 1.将现有的接口测试用例，直接转化成压测脚本，远程一键化执行。减少测试编写脚本的时间。...方法： 基于现有的测试平台做改造。精确到每个测试用例都可以转化。利用参数的入参和断言，转化成Jmeter压测脚本，一键复制到执行机上进行执行。...压测过程，压测数据要进行收集，展示。测试报告的数据要进行汇总存储。存储的时候要和对应的测试用例，测试环境，测试数据做关联的。...这里呢，我选择利用我已经开源的平台做的功能的设计，整个的开发过程呢，我会用java实现，验证完毕后，后期会开源到python的平台中去，整体的思路没有太多的差异。
1、单元测试概述 1.1 什么是单元&单元测试 1.2 为什么进行单元测试 1.3 单元测试用例编写的原则 1.4 单测用例规定 2、golang 常用的单测框架 2.1 testing 2.1.1...：在单测中直接给出具体接口的使用方法，是最好的实例代码 1.3 单元测试用例编写的原则 单一原则：一个测试用例只负责一个场景 原子性：结果只有两种情况：Pass、Fail 优先要核心组件和逻辑的测试用例...return a + b } func Mul(a, b int) int { return a * b } func Div(a, b int) int { return a / b } 准备测试用例...这样写的好处有 新增用例非常简单，只需给cases新增一条测试数据即可 测试代码可读性好，直观地能够看到每个子测试的参数和期待的返回值 用例失败时，报错信息的格式比较统一，测试报告易于阅读 如果数据量较大...s.MathScore if score == 0 { return 0, fmt.Errorf("全都是0分") } return score / 3, nil } 参考官方示例，准备测试用例
10、参加测试技术沙龙到底收益在哪里？ 以上是最近大家问我的问题的。在这里我统一整理一下。 1.关于如何转行做测试？...自动化测试，特别是UI层面的自动化测试，环境配置是特别发愁的，自动化测试入门第一步，搭建自动化测试环境，第二步，学习将手工测试用例转化成自动化测试用例。设计测试用例。...功能测试用例设计方式，同样适用于自动化测试。做自动化测试不是学一两天，写一两个脚本就算会做自动化了。功能转自动化，但是不要丢掉功能测试。 3、测试开发的出路在哪里？...6、开发如何转做测试开发？ 这是最近一个开发问我的问题，我问他为啥做测开，他说做不好开发，我说测开你能做好吗？他说看着能做好。我问，那开发呢，他说也能。...我呵呵，你看着能做好的事情都做不好。你对这个职业没有清晰认识，对自己没有一个全盘的思考。而是因为开发干不成，干测开，我感觉你真正不是转，而是对自己的否定，开发做不好，也不一定做得好测开。
这里说的基础，不仅仅是什么是软件测试、软件测试的目的，而是测试用例的设计能力。 因工作的原因，近来接触不少毕业3、4年，甚至7、8年的测试同学，对用例设计还是停留在理论阶段，这让人不免有些无力吐槽。...问题：软件测试用例的测试方法有哪些？ 回答：等价类、边界值、因果图等等。 问题：结合实际的业务场景，来说说常用到的测试用例设计的方法。 回答：不少回复都是以登录来做说明的。...其实日常工作中，常用到的用例设计也就那么几种，如果我们能把理论好好应用到实际工作中，那么涨薪其实也很容易。 那么，怎么样才能设计出好的测试用例呢？业务、业务、业务，重要的事情说三遍。...，一方面领导可以看到你的计划写的多详细，另一方面大纲可以很好的成为编写用例的依据 怎么测试要说明白，如只做系统测试，那就要写清楚不做集成测试，如果需要集成测试，就需要写明白集成顺序。...：这个文档，主要描述具体的测试步骤 但实际应用中，至少目前我的项目里，由于时间的原因，很少有写的，就算写了的，也基本没有用到测试里，在这边的很多项目大都是直接来测，全凭我个人的经验来检查。
你好，我是测试小牛。 金三银四来了，不少小伙伴都在准备面试跳槽了，分享一位我这边带的高薪就业训练营学生年前找工作，面试阿里高德高级测试开发岗位一面面经记录。...每条用例的前置条件怎么处理的？比如说某个接口在测的时候，会依赖其他的一些接口，那你这个场景化用例是怎么做的呢？ 4. 试算、核保都需要一些前置条件，前置条件怎么在excel里面实现的？...所有的测试用例，前置和后置是怎么做的？ 6. excel里面有哪些字段？ 7. 自动化测试用例覆盖率是多少？你们是怎么评估的？整个自动化提升的效果是怎么样的？ 8....在支付过程中，网络出问题了，或者有一些兼容性问题，调微信失败了，怎么处理？有模拟失败的这种场景吗？ 10. 支付流程的测试用例异常设计有哪些点？ 11. 怎么模拟微信那边没有扣钱？ 12....就是说有什么除了你之外，其他人做不了的 20. 开发自测有哪些效益呢？ 21. 他测不测你怎么衡量？ 22. 冒烟测试不通过，打回之后，对开发本人有什么影响？ 23.
将其他测试用例跑一下确认是否可以通过，通不过说明是有问题的。「因此，单元测试是保证重构正确性最有力的手段，有足够的的单测，才能放手大胆的进行代码重构。」...有一百个测试用例，那么这一百个都应该是独立的，其中九十九个成功了，一个失败就只影响它这一个测试用例，不应该有测试依赖。...「因此利用这个可以做数据驱动，QA 和 QE都可以在 XML 文件中提供自己的数据进行测试，我们可以使用不同数据集跑同一个测试用例，获得不同测试结果」。...参数化还有一个好处就是，对于n个不同参数组合的测试，JUnit 4 要写 n 个测试用例。每个测试用例完成的任务基本是相同的，只是受测方法的参数有所改变。...TestNG 可以针对失败用例回归测试，增加测试针对性和效率，而 Junit 需要将所有测试用例重新执行； 在自动化测试流程里面，如果测试用例跑失败，一般有个按钮，可以一键重跑失败案例，不需要跑成功案例可节约时间
作为技术人员，我们每天都要写大量的代码，新功能产品计划书出了以后就要阅读、编写测试用例。对于一个大神级别的测试工程师而言，能写一手熟练的代码，覆盖率高的测试用例，这些都是拿到高工资的必要条件。...前两轮都挺顺利的，面试官也很和蔼，问的问题不是很难，而且回答完以后如果有欠缺，面试官也会给你做一下补充。最后一轮是测试经理。...测试经理：你看，你这两个邮箱写的不一样，都是163邮箱 我：……我有一个写错了 测试经理：咱们做测试的最重要的就是认真呀…… 我：是的是的，我马虎了 测试经理：这样我得在你预期工资上减两千了 我：？？？...用户发现了问题，反馈回来，技术主管要在会上问，谁测的？测试经理会再问，谁测的？——对你的两次暴击……然后你勇敢的站出来，说是我测的。 主管：为什么会漏测？ 你：？？？...为啥漏测，就是漏测了呗…… 说到底，其实就是不认真，据我的工作经验，如果在工作中出现两次严重漏测，那你且不说很没面子，连包住这份工作都危险了。
我觉得搞学问的有个毛病，喜欢把一个简单的东西讲得很复杂然后就是不告诉你到底是什么。...三、测试用例 3.1 测试用例类别 随机数据这个词用得有点宽泛得不负责任，随机数据那是不是我从0到无穷大每个数都要测一下，总得有些指导性的测试用例类别吧。 缓冲区溢出类测试用例：超长字符串。...随机数测试用例：很多系统支持的配置值是固定的，比如屏幕只支持1080p我们故意设1081p系统就可能把错了。负数，浮点数，超大数等分别来个测试用率就行了。...web扫描器其实本质也是通过使用测试用例去发现问题，不过web扫描器使用的是漏洞针对性的测试用例，比如测sql就用sql注入的测试用例、测xss就用xss的测试用例。...我对本地http服务器执行了bed -s http -t 192.168.220.1大概花了一下午的时间。
某互联网大厂测试开发，虽然入行才2年多一点，但由于经常参加各种技术沙龙，观察就业形势，已经摸清了测试行业的玩法 日常工作当中，小B需要经常跟外包人员一起合作，他们就是纯粹的"点工"，主要的工作内容为写测试用例...，然后按照测试用例执行测试，有的时候在小B的帮助下，会再使用一下Charles或者Fiddler抓包工具看HTTP请求的返回数据 小B时常也会想，资本家也太聪明了，为了省钱，把纯功能测试岗位完全外包化...、性能测试，却变得和开发一样，也要去追求代码能力，架构设计能力 小B感慨，现在的测试行业真卷呀，互联网红利褪去，测试人也开始裸泳，测开的核心竞争力又在哪里，他不禁陷入了深思，是能够Code Review...拥抱变化，提升自己 丰富自己的技能（懂业务、懂技术、懂架构），多读书，同时注重提升综合素质（英语、情商等） 深耕某一个领域，熟悉该领域下的业务，成为该领域业务专家 根据业务线被测对象的不同，做业务测试也要掌握对应的背景知识...，每天都有新人来提问，问题大多都是我想转行软件测试，但是我不知道怎么办，软件测试好不好就业等等 大部分的回答都被培训机构霸占了，想要转行做软件测试的同学真的还是很多，我想可能大家对比了其他行业，还是觉得互联网高薪
我见过模拟 Web 框架 (flask) 一半的测试，只是为了测试为端点注册函数是否有效。这是测试一小部分功能的大量工作。如果你弄错了，那就很明显了。一旦你做对了，它在未来不太可能改变。...— Martin Fowler，重构 特别是某个代码逻辑导致的线上bug，或者其它同学发现的问题，都可以编写成测试用例，防止此类错误的再次出现。...这种问题被称为误报，看似无懈可击的测试用例，其实没什么用处，为了防止这种情况，请考虑是什么导致您的测试失败。更好的是，从失败的测试开始，然后编写代码直到它通过。在不知不觉中，您正在进行测试驱动开发。...如果您的测试或被测代码以不确定的方式运行，您将对测试失去信心。每次失败时，你都会问：我的测试失败了，还是会通过重新运行？重新修改运行都会给你的测试用例带来修改的麻烦，你甚至想要放弃单元测试用例。...对于单元测试不是那么有用，通常而言，使用硬编码的单元测试用例最可靠。
我们希望一组测试用例不仅能够“触发被测代码的各种分支”，还能够做好结果校验。 当业务代码出现问题的时候，测试用例可以发现这个问题，我们就认为这一组测试用例是有效的。...我们认为： 一组Success的测试用例，在其被测对象发生变化后（注入变异后），应该至少有一个失败。 如果这组测试用例仍然全部Success，则这组测试用例的有效性不足。...为了全自动的进行测试有效性评估，我们做了一个变异机器人，其主要运作是： 往被测代码中写入一个BUG（即：变异） 执行测试 把测试结果和无变异时的测试结果做比对，判断是否有新的用例失败 重复1-3若干次，...变异机器人的使用门槛： 测试成功率：只会选择通过率100%的测试用例，所对应的业务代码做变异注入。 测试覆盖率：只会注入被测试代码覆盖的业务代码，测试覆盖率越高，评估越准确。...热部署：基于字节码做更新，减少变异和部署的过程。
，导致测试的时候只关心了提测文档 总之，工作肯定会遇到各种各样你无法预料到的事情 那么 我们应该怎么做才能防止锅从天上来呢？...和我无关 2、考虑场景覆盖 这个关键在于我们的测试用例的覆盖率，能不能考虑更多的场景。...这个跟实际的项目熟悉程度及工作经验也有部分关系，但是，我们需要在写测试用例的时候，要抓住prd文档的每个字每句话，确保每个场景都覆盖。所以，一般的用例评审是非常有必要的。...4、总结 最后，实在是推不了的锅，看看是不是自己哪里漏测了呢？ 那下次再测试的时候，要多考虑下当时漏测的场景。 明确漏测的场景是什么原因没有考虑到呢？为什么测试环境没有测试出来呢？...再遇到这种情况，我该如何去测试呢？再每一次的问题中不断总结，防止漏测。 最后 祝大家永远不背锅，上线不出bug！！！
4.3 创建用例与执行 在添加完应用程序的前提下，我们先点击New test按钮来创建一个测试用例来试试，从下面的界面可以看出目前mabl支持做Web产品的UI界面测试、接口测试与性能测试。...页面上的check web login every hour就是我自己创建的计划，用来每个小时检查一遍用户是否可以成功登录至被测系统。...接下来我就来为大家介绍一下mabl这个平台的亮点功能 —— 测试用例的自愈功能。self-healing这个字眼相信做过测开的同学应该都不陌生，代码自愈也一直是大家比较关注的话题。...那么在mabl自动化测试平台中，也有这么一个自愈的概念，其核心的主旨就在于当被测对象的某些特性或属性发生改变的时候我们的测试用例就会失效，这个无论是手工测试用例还是自动化测试用例都会遇到，同时随着被测系统的功能迭代与规模增加...这里我们做一下整理，如果你的测试用例因为某些页面或元素属性的变更然导致执行失败，那是非常常见的情况，无论是日常的需求变更还是功能与页面迭代，只要断言的那个元素依然正确，那AI就自动辨认发生变更的一些页面元素
3、如果想单独验证失败的两条用例应该怎么做？例如上图中的最后两条失败的用例。 4、上面的测试代码中，有多少是真正用在测试操作的，至少一半都在读写csv文件，是否需要做封装，想想怎么封装更简单？...那么我们借助单元测试框架来做自动化就爽多了，因为它解决了测试中的几问题。 如何定义一条测试用例，我们知道编程的世界里并没“用例”的概念。它只有目录、文件、类、方法、函数......测试结果统计，当执行了一系列的用例之后，总共运行了多少条用例，成功了多少条，失败了多少条，失败的用例错误在哪里？单元测试框架会帮我们统计和展示。 被测功能还是上文的功能。 ?...我以为这么规范的编写测试用例，要啥自行车。 其实，我已经尽量的把登录操作做了封装，每条用例里面只关心登录的数据和结果的断言。谁告诉你“数据驱动”就必须要“读取数据文件”的？...这个话题，本来到此就结束了，我其实是很鄙视读取数据文件的操作的，因为真get不到它的“方便”之处，做自动化测试写代码就老老实实的写代码，就你测试用的这点数据，真没必要读取文件，数据库就更谈不上了。
3、测试需求分析和测试用例编写 在这个阶段质量测试工程师们从需求文档（功能规格说明书或测试案例）提取业务场景（大多数情况下都需要跟开发反复沟通），我习惯把业务场景整理到excel中，以此保证需求覆盖。...请求从哪里开始，到哪里结束？ 每个请求中传输哪些数据？ 我们怎么测试，或者说保证这些请求在成功、失败时都得到了正确处理？ 这种方式可以说借助了白盒测试的思想，也可以说是一种灰盒测试。...在评审方面，我遇到的情况都是在测试计划和测试用例都完成以后，由测试经理牵头，召集项目经理、其他项目的测试经理、测试环境维护专员、测试执行人进行评审。...《联调测试用例》：每个系统的开发人员都需要编写，并且在提测前自测通过。自测通过以后还需要把测试通过的截图附加到excel中。 《联调测试报告》：类似于常规的系统测试报告。...《影响性分析》：在文档中告诉我们，这次需求改动了哪些地方，如何修改的，这次修改影响到了哪里。这个文档可以帮助我们明确测试范围，减少漏测。
1、项目经验 2、介绍下什么是索引 3、京东登录页面怎么测？ 4、如果一个普通用户，他的百度首页打不开，问题怎么定位？写出定位流程。 5、问简历上的第一个项目的详细情况，包括测试用例怎么写？...9、针对发朋友圈这个功能设计你的测试用例，请给出用例分类与典型用例场景 10、Java 中的容器有哪些？它们的区别和特性？...是怎么测的？用的什么工具？为什么用 HTTPClient 类库，觉得它有什么缺点？用 Fiddler 主要做什么？ 27、请问你们公司是如何做性能测试的？请讲诉性能测试的相关指标？...30、性能测试用过吗？什么情况下用的？主要测哪些方面？ 31、性能测试关注哪些指标？...38、UI 测试的过程 39、自动化测试用例怎么来？ 40、你项目中有多少case，通过率怎么样？ 41、报告哪里来，主要统计什么？ 42、做自动化测试的目的？ 43、如何看待自动化和手动测试？
前言 哈喽，大家好，我是海怪。 相信很多前端开发在写单测的时候，最大的问题就是：“我应该测什么东西？” 没错，解决问题不是最难的，发现问题才是！知道要测哪个远比怎么测重要很多！...正片开始 知道如何做测试很好，也很重要的。我之前就教过很多人测试的基础知识、如何配置工具、如何针对不用情况写好测试，等等。但是知道如何测试只是成功的一半，知道要测什么才是更重要的另一半。...所以，当你看着这份覆盖率报告时，你不要总想着那些 if/else、循环或者生命周期，而是要问问自己： 这几行代码实现对应的是哪些使用用例？我应该要加哪些测试用例来覆盖它们？...或者换个问法： 应用崩了，最糟糕的地方在哪里？ 我会建议你按这个标准来列出你应用支持功能的优先级。 你可以和你的团队以及 Leader 一起来做这件事，这将会是一次很好的尝试。...一旦有了几个 E2E 测试用例之后，你就可以给一些没在 E2E 范围内的边界情况做集成测试，然后再给用到的功能里更复杂的业务逻辑做单元测试。从现在开始，剩下的事情就是不断加测试就好了。
与 Before 对应，还有一个 @After 注解，可以标注一个方法，用来在每个用例执行完毕后做一些清理操作，如果不需要的话 ，也可以省略不写。 ...根据前面的例子，很容易就可以联想到还可以增加 search 失败的时候调用 view.showError()，以及 search 结果为空时，调用 view.showEmpty() 的测试用例，小菜一叠是不是...前面写的这些测试用例都是验证被测试对象依赖的模块的某些方法可以被正确调用，所以可以归为一类叫做行为验证，也就是 Mockito 通常被用来做的事情。 ...结果显示我们的测试用例覆盖了 100% 的类和方法和 88% 的行数。 ? 点击打开具体类还能看到每一行代码有没有执行到，非常好用，为我们对测试用例的调整和完善提供了很好的参考价值。...这句话不是我说的，而是 Kent Beck 说的，他是 TDD 和 XP 的发起者，也是敏捷开发的奠基人。
领取专属 10元无门槛券
手把手带您无忧上云
