我觉得这个问题有必要拿出来说一说，而且讨论这个问题的时候很容易从A变成B，这需要管理者警惕。 昨天讨论的问题，归结起来有三点： 为什么测试用例标题中要把测试点描述清楚？ 为什么写测试用例？...测试用例应该写成什么样的粒度？ 这几个问题，测试新手大都能说出个一二三来，不过据我了解，很多测试工作很多年的同行，在工作中仍会对此产生困惑。 为什么测试用例标题中要把测试点描述清楚？...我们公司用工具来管理测试用例，如果不在标题中写清楚测试用例，后期创建测试套件和安排测试都会受到影响，不好操作，必然会返工。...把更多的时间放在测试执行上岂不更好？反正这些东西都在心里面有？ 为什么写测试用例？ 在这个问题上产生疑惑，大都是在测试时间紧张的时候应不应该写测试用例。...（这其实就是测试点了） 测试用例应该写成什么样的粒度？
1、前端使用 Twemproxy 做代理，后端的 Redis 数据能基本上根据 key 来进行比较均衡的分布。后端一台 Redis 挂掉后，Twemproxy 能够自动摘除。...2、Redis 挂掉后，后端数据是否丢失依据 Redis 本身的策略配置，与 Twemproxy 基本无关。...5、如原来已经有 2 个节点 Redis，后续有增加 2 个 Redis，则数据分布计算与原来的 Redis 分布无关，现有数据如果需要分布均匀的话，需要人工单独处理。...6、如果 Twemproxy 的后端节点数量发生变化，Twemproxy 相同算法的前提下，原来的数据必须重新处理分布，否则会存在找不到key值的情况。...从数据可以看出，后端节点数量与 Twemproxy 的性能基本无关，最大性能也就是单个 Redis 的性能。
引言 自动化测试中，有一个验证点，当测试通过时，后面的测试脚本继续执行； 当出现异常时，你希望标记出来这个错误，但不影响后面的测试脚本执行，在Nightwatch中如何做？...代码如下： home.waitForElementVisible('@body', 3000, true, function(result) {if (result.value) {// 测试报告中会显示失败...// 中断执行 client.assert.equal(result.value, false); Q: 关于“自动化测试”，你还有哪些问题和想法？ 欢迎评论、转发。
测试用例设计、评审是每个测试人员进行的关键测试活动之一，如何做好测试用例设计？如何进行测试用例评审？如何评估测试用例的质量？是我们必须考虑的问题。 一. 如何做好测试用例设计？ ...做好测试用例设计，除了关注被测对象的功能外，也需要关注被测功能与其他功能模块之间的交互。...被测对象的逻辑组合和输入数据的组合是非常庞大的，而穷尽测试是不可能的。经典测试设计中的一些技术与方法，在保证测试覆盖率与质量的情况下，对减少测试用例的数目是非常有效的。...如何做好测试用例评审？ 测试用例是测试人员最重要的输出之一，也是后续开展测试执行与评估的基础。测试用例评审是保证测试用例质量的一个重要环节。如何做好测试用例的评审，以下是一些思考。...根据测试用例的形式评估其质量 主要包括以下几点： · 测试用例与需求条目的可追溯性。 · 测试用例有无明确的期望结果。 · 测试用例的形式是否满足内部定义的模板要求等。
4)表格整理：将复杂的信息以表格形式呈现，提高信息的可读性和易用性，增强信息的清晰度和用户的使用体验。 Kimi设计测试用例的 3 大优势： 1)支持图片格式的测试用例上传，功能点的理解和掌握直观。...1、提供用例模板 测试用例模板应该包含所有必要的测试信息，比如测试步骤、预期结果、输入数据、执行条件等。...精通功能测试、自动化测试、性能测试、接口测试、测试开发技能，具备超强的逻辑能力和语言表达能力。这是测试用例模板框架，以后生成测试用例，都是按照这些内容生成。你记住了吗？...6、迭代和维护用例 根据测试结果和反馈，不断迭代和完善AI模型，提高测试用例的准确性和相关性。 定期更新功能点和测试用例模板，以适应系统的变化和新的需求。...利用Kimi可以提高测试用例设计的质量和效率，确保测试工作的系统性和全面性，并为软件项目的成功提供坚实的测试基础。
一、边界值分析法定义 二、等价类划分法和边界值分析法的区别 三、内部边界值 四、设计测试用例的原则 五、边界值分析法实例（三角形问题） 软件测试用例设计之错误推测法 一、错误推测法定义 二、错误推测法基本思想...三、错误推测法实例 四、错误推测法的优势和不足 软件测试用例设计之判定表驱动法 一、判定表的定义 二、判定表的组成部分 三、判定表驱动法设计步骤 四、实例 五、因果图和判定表的区别 六、判定表驱动法的使用条件...五、边界值分析法实例（三角形问题） 假设规定输入a,b,c三条边的数值范围为[50,100] 则边界值分析法得出补充测试用例如下 软件测试用例设计之错误推测法 一、错误推测法定义 基于测试人员的直觉和经验推测程序中所有可能存在的各种错误...二、错误推测法基本思想 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据这些设计测试用例。 例如输入数据和输出数据为0的情况，输入空格的情况，输入只有1行的情况。可根据这些设计测试用例。...软件测试用例设计之因果图法 一、因果图法定义 因果图法是利用图解法分析多个输入条件组合情况，考虑输入条件之间的约束关系，从而设计测试用例的方法。
就是@pytest.mark.xfail()标记预期会失败的用例，即期望测试用例是失败的，但是不会影响测试用例的的执行。...「标记的用例运行后，断言失败，所以结果是xfailed，也没有像正常一样显示出错误用例及具体信息。」 #!...收集的测试用例:[] collected 1 item test_01.py::Test::test_login_01 执行用例test_login_01...========== Process finished with exit code 0 「标记的用例运行后，断言成功，所以结果是xfailed，也没有像正常一样显示出错误用例及具体信息」 #!...收集的测试用例:[] collected 1 item test_01.py::Test::test_login_02 执行用例test_login_02
而软件测试工作复杂度的直接体现，就是测试用例编写、维护、执行和管理，所以编写易读、易维护和易管理的测试用例可以有效的降低测试工作的复杂度。...然后对其进行测试分析，并完成整体测试用例的设计和编写，其中包括功能测试用例，E2E测试用例，异常测试用例等等。对于设计好的测试用例需要进行分类并管理，然后根据不同的分类进行分层测试。...当测试数量很大的时候，如果测试用例管理系统不易用，测试用例的复用性也不高，则会导致测试用例不易维护，从而会极大的增加了其管理成本。...本方法的优势是可以同时管理自动化测试用例和手动测试用例，并且更容易跟踪测试用例和测试数据的更改。而劣势是需要测试工程师有足够的工程技术能力来实现。...而右图是通过Jenkins生成的测试用例活文档（Test Case Living Document），通过它可以统一的展示出手动测试用例和自动化测试用例的测试结果。
最近的用例评审让我感受颇深，以下是我对于测试用例评审的一些感受，发出来供大家讨论学习。 听听大家对测试用例评审的吐槽？ “测试用例设计是测试的事情，为什么评审要我们参加？”...暴漏出开发在实现过程中代码逻辑考虑不充分的地方，提前预警，避免逻辑处理考虑不充分导致的缺陷。 开发可以从实现层面评审用例，补充测试用例中，由于测试人员不了解实现过程导致的测试用例缺失的情况。...项目经理： 通过用例评审不但可以评审测试用例是否足够覆盖所有需求逻辑，还可以通过评审的的手段来评估测试的工作量。如果100个用例可以用2个人1天进行，那么可以根据测试用例的数量可以安排测试的时间。...2、评审的流程 测试人员确定评审日期和参与评审人员 评审前2天，测试用例发给所有评审人员 评审人员记录测试用例问题 评审会议，测试用例编写人员讲解用例，参与人员提出评审 会议结束，修改用例，并邮件输出...3、评审的内容 1、描述是否清晰，是否存在二义性 2、内容是否完整,是否清楚包含输入条件和预期输出结果并无争议点 3、是否覆盖了所有场景、逻辑分支、限制条件等 4、是否哪些需求不可测：无法准备环境、可测试性达不到等等原因
所以，好的测试用例应该既能完美的评估商业需求并能达到最小成本消耗。 那么，怎么评价一个测试用例是好的测试用例呢？我告诉你十条准则，通过这十条准则设计的测试用例就会是好的测试用例。...第一准则：使用了测试用例设计方法 测试用例设计使用了一种科学的测试用例设计方法，例如边界值、等价类、因果图、场景法等方法。这能保障你的测试用例能够更好的接近于最少的测试用例条数达到更大的覆盖结果。...第六准则：没有自以为的前提条件 没有自以为的前提条件所指在编写测试用力的时候，要站在没有任何自我假设条件的基础之上撰写测试用例，我们不能假设我们被测系统已经有了什么功能或者能力，也不能假设最终用户使用者有了一些假设的知识积累和储备...第八准则：保持可追溯性 保持测试用例的每一条都是可追溯的，这样我们就可以通过建立测试用例和被测系统的功能之间的映射来查看测试系统的功能是不是都被测试覆盖了。...第九准则：覆盖非功能特性 保持测试用例覆盖被测系统的多个方面，这里既包含了功能正确性，可用性等还包含了性能测试用例、兼容性测试用例等等。
大家好，又见面了，我是你们的朋友全栈君。 前言 写用例之前，我们应该熟悉API的详细信息。建议使用抓包工具Charles或AnyProxy进行抓包。...将 HAR 格式的数据包转换为YAML/JSON格式的测试用例文件。...将HAR文件默认转换成pytest，强烈建议以pytest格式而不是以前的YAML / JSON格式编写和维护测试用例。...这里也是博主从pytest框架转换为httprunner框架的原因之一 运行命令将har文件转换成测试用例： (httprunner_env) ➜ har har2case baidu.har 2021...(YAML/JSON) 当然，你也可以生成YAML/JSON测试用例。
API的测试用例是基于产品的业务逻辑。...，其中最核心的一个点就是编写的每个测试用例都必须得有断言同时基于API的测试要基于产品的业务逻辑来进行，而单纯的测试API是没有多少意义的，比如一个登录的业务场景，登录接口好的就能够证明登录的业务场景是好的吗...，但是主要可以考虑这么几点，分别是创建书籍信息，查看创建的书籍信息，对创建的书籍信息进行修改，和最后删除创建的书籍信息，那么编写这样的API测试用例的编写，也可以从两个维度思考，第一个维度是基于业务场景...按照之前的设计思路，只能放在第二位，因为测试用例它是按顺序执行的，很显然它会打乱已经有的执行顺序，当然对链路很长的测试点来说，这样写也没什么错误。...下面再看另外一种思路，就是测试用例之间是没有顺序的，这样就可以很好的解决上面说的，批量增加，批量修改或者批量删除也好，测试点是无顺序的，所以增加或者建=减少测试点，也是无所谓的，修改后的测试点见如下：
测试用例设计是测试活动中非常重要的一个环节，它和测试思维是紧密相关的。如何回答这个问题，才会更好地体现你的测试能力呢？笔者在面试中高级测试人员的时候，这个问题也是必问题。...01 测试用例设计的层次可以简单的分为以下三个层次： 基于页面：一问起测试用例设计，你能想到的第一个大概率是等价类、边界值，再多一点的可能会是正交表、判定表等等。...这类的用例可以写多，但意义有限。 基于业务流：基于业务流程、数据流程来做测试用例的设计，一般会有场景法、状态机等方法，还有一些测试用例设计模型。...如果你能想到这些方法，那么至少你对被测系统的业务架构和全链路的数据流转有一定的了解，知道关键节点在哪里，可以从更多的用户场景去考虑测试用例的设计，往往通过这类方法设计出来的测试用例，实用价值会是最高的，...当然，这并不是说这类用例不重要，但是整体的占比不应该过多。 在很多次的面试过程中，候选人无法清晰地描述被测系统的业务流程是什么样子的，更别提技术架构，这样的测试思维很难匹配中高级测试的岗位要求。
常见的测试用例设计方法主要会涉及以下几种： 1、等价类 2、边界值 3、场景法 4、判定表 5、因果图 6、错误推断法 7、正交测试法（正交表） （今天主要解释前三种最为常用）...选择合适的测试用例方法，有助于你去更好的梳理出逻辑关联关系，让你的测试覆盖率更高，更高效率的覆盖到所有测试点。...一、等价类划分法 1）定义 依据需求输入划分为若干等价类，从等价类中选定一个测试用例，如果该测试用例通过，则表明整个等价类通过测试...如：微信发红包0.01–200 2）适用场景 一般适用于无限多种输入，我们不可能完成穷举测试，等价类可以使我们用较少的测试用例尽可能多的将功能覆盖。...2）主要基于: a.业务（需求）层面: 对所测软件的重要功能，业务逻辑（系统要干什么，怎么去实现，这个过程、）、行业背景深入理解 b
四、写测试用例 五、设计测试用例的方法 1.总的设计测试用例的方法——基于需求的设计方法 2.等价类 3.边界值 4.因果图 5.正交排列 6.场景设计法 7.错误猜测法 一、如果测试的时间有限，如何保证在有限的时间内让产品上线...（2）如果有限的时间所有的功能不能完全测完，可以和产品经理开发商量，把没有通过测试的，有风险的功能把用户的入口，屏蔽掉（让用户无法使用），产生错误风险就会降低。...具体的设计测试用例的方法 2.等价类 把测试的输入划分为若干个等价类，从每一个等价类当中选择一个或者几个测试用例进行测试，如果这些测试用例测试通过，那么我们就说这个测试用例所在的等价类测试通过。...实例分析 有效等价类：符合我们需求规格说明的数据集合 无效等价类：不符合需求规格说明的数据集合 有效等价类和无效等价类都要测 3.边界值 针对测试输入的边界来设计测试用例，进行测试...场景法设计测试用例，先找出组成场景的每一个功能点，分析每个功能点可能出现的各种正常或者异常的情况，根据这些不同的情况去设计不同场景下的测试用例 7.错误猜测法 根据测试人员的知识，经验，直觉，有针对性的设计测试用例
API的测试用例是基于产品的业务逻辑，关于这点在我出版的书《Python自动化测试实战》测试案例实战中都有丰富的代码案例，这里就不详细的再说明。...，其中最核心的一个点就是编写的每个测试用例都必须得有断言同时基于API的测试要基于产品的业务逻辑来进行，而单纯的测试API是没有多少意义的，比如一个登录的业务场景，登录接口好的就能够证明登录的业务场景是好的吗...，但是主要可以考虑这么几点，分别是创建书籍信息，查看创建的书籍信息，对创建的书籍信息进行修改，和最后删除创建的书籍信息，那么编写这样的API测试用例的编写，也可以从两个维度思考，第一个维度是基于业务场景...按照之前的设计思路，只能放在第二位，因为测试用例它是按顺序执行的，很显然它会打乱已经有的执行顺序，当然对链路很长的测试点来说，这样写也没什么错误。...下面再看另外一种思路，就是测试用例之间是没有顺序的，这样就可以很好的解决上面说的，批量增加，批量修改或者批量删除也好，测试点是无顺序的，所以增加或者建=减少测试点，也是无所谓的，修改后的测试点见如下：
将较长的测试用例分解为许多较小的用例 如果步骤太多，最好将测试用例分成一组较小的用例。如果测试脚本中的某个地方发生错误，对于开发人员来说，回溯并重复测试步骤将更加容易。...如果是某一长用例测试未通过或者发生错误，则开发人员很可能会花更长的时间发现和改正这个BUG，甚至错过该BUG。...有许多测试管理工具可用于在一个地方组织测试用例，这将提高团队的生产力。 停止假设 最好参考规范文档。关于功能或功能的假设可能导致客户端与开发人员之间的分歧。...满足客户要求 如果测试人员错过了一个错误或编写了与真实场景无关的测试用例，那么这只是浪费资源和时间。目的是满足客户的期望，只有测试人员从用户角度出发才能实现。...涵盖所有验证点 编写定义良好的测试用例验证步骤非常重要，该步骤应涵盖被测功能的所有验证点。为了确保测试用例涵盖了所有验证点，请确保您的测试用例步骤与为项目指定的工件相匹配。
具有所需详细细节的测试用例优点： 良好的测试用例可以减少对测试人员的依赖 想象一下这样的情况，编写测试用例的人在完整的测试执行阶段或部分测试执行阶段都不可用。...查看编写良好的测试用例要容易得多 在理想的测试环境中，所有测试用例都必须由利益相关者进行评审，以防止最终出现测试用例遗漏的情况。...详细的测试用例有助于开发重现缺陷 如果一个测试用例执行失败并引发缺陷，则将编写良好的测试用例与缺陷ID链接也可以帮助开发人员重现缺陷并了解问题所在。这将缩短解决BUG的时间，从而加快总体测试速度。...良好的测试用例中应包括的相关细节 精确的测试用例名称–测试用例名称不应太长，但应简要定义和说明测试用例的用途 测试ID –应该为测试用例分配唯一的测试ID 先决条件–如果在开始执行测试用例之前需要满足任何先决条件...最终结果–根据实际结果是否与预期结果相符，应将测试步骤标记为通过/失败 缺陷ID –如果测试步骤失败，则应针对该缺陷提出缺陷，并在测试步骤中注明缺陷ID。这对跟踪缺陷很有帮助。
API的测试用例是基于产品的业务逻辑，关于这点在我出版的书《Python自动化测试实战》测试案例实战中都有丰富的代码案例， 这里就不详细的再说明。...， 其中最核心的一个点就是编写的每个测试用例都必须得有断言同时基于API的测试要基于产品的业务逻辑来进行，而单纯的测试API是没有多少意义的，比如一个登录的业务场景，登录接口好的就能够证明登录的业务场景是好的吗...，但是主要可以考虑这么几点，分别是创建书籍信息，查看创建的书籍信息，对创建的书籍信息进行修改，和最后删除创建的书籍信息， 那么编写这样的API测试用例的编写，也可以从两个维度思考，第一个维度是基于业务场景...按照之前的设计思路，只能放在第二位，因为测试用例它是按顺序执行的，很显然它会打乱已经有的执行顺序，当然对链路很长的测试点来说，这样写也没什么错误。...下面再看另外一种思路，就是测试用例之间是没有顺序的，这样就可以很好的解决上面说的，批量增加，批量修改或者批量删除也好，测试点是无顺序的，所以增加或者建=减少测试点，也是无所谓的，修改后的测试点见如下:
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
云直播
