文章介绍性能测试工具 gatling 的新手入门介绍，环境搭建，如何将官方 demo 跑起来

文章介绍 postman 替换工具 Bruno 的新手入门介绍，如何迁移 postman 脚本到 Bruno

什么是二八法则 二八法则，也被称为帕累托法则（Pareto principle），是一种经济学原理和管理学理论，描述了一种观察结果：80% 的结果往往来自于 20% 的原因。这个法则最初由意大利经济学家维尔弗雷多·帕累托（Vilfredo Pareto）提出。 二八法则可以应用于各个领域，包括经济、生产、销售、时间管理等。具体来说，它意味着一个系统或者群体中，少数重要的因素往往对于大部分结果产生了主要的影响，而其余的因素只起到了次要的作用。换句话说，大部分的产出、收益或者结果来自于少数关键的因素或者部分。 举个例子，二八法则可以应用于销售领域。80% 的销售额往往来自于 20% 的顾客，或者说 80% 的问题往往来自于 20% 的产品。这意味着经营者可以通过专注于那些最重要的 20% 顾客或产品，获得最大的收益。 二八法则的应用还可以帮助人们更有效地管理时间。根据这个原理，80% 的成果往往来自于 20% 的时间和精力投入。因此，人们可以通过识别那些最重要的任务和活动，并优先处理它们，来提高工作效率和成果。 需要注意的是，二八法则的具体数字并不一定是严格的 80-20 比例，这只是一个常见的例子。在实际应用中，比例可能会有所不同，但基本思想保持一致：少数重要的因素或者部分对于整体结果起到了关键作用。 软件研发过程中的二八法则 在软件研发中，二八法则可以应用于多个方面，包括功能开发、缺陷修复、需求管理和团队效率等。以下是一些常见的应用场景： 功能开发：根据二八法则，80% 的用户使用率通常来自于 20% 的核心功能。在软件开发过程中，团队可以优先开发和完善这些核心功能，以满足大部分用户的需求。这有助于提高产品的可用性和用户体验。 缺陷修复：类似地，80% 的软件缺陷往往由 20% 的核心功能引起。因此，在缺陷修复过程中，团队应该重点关注那些最常见、最严重或者影响最广泛的缺陷。这有助于快速改善软件的质量和稳定性。 需求管理：根据二八法则，80% 的用户需求通常来自于 20% 的关键需求。在需求管理过程中，团队应该专注于梳理和管理那些最重要、最紧急的需求，确保其优先级得到合理的安排。这有助于提高项目的交付价值和满足用户期望。 团队效率：二八法则也可以应用于团队效率的管理。根据这个原则，80% 的工作成果往往来自于 20% 的高效工作时间。团队可以通过优化工作流程、减少低价值的任务和降低工作负荷，来提高团队的整体效率和生产力。 需要注意的是，二八法则在软件研发中的具体应用可能会因项目的特点、复杂性和业务需求而有所不同。团队应该根据具体情况灵活运用这个原则，以达到最佳的开发效果和资源利用。同时，综合考虑其他因素，如用户反馈、市场需求和团队能力等，以实现整体的项目成功。 软件研发质量中的二八法则 在软件质量管理中，二八法则可以应用于缺陷管理、测试策略和持续改进等方面。以下是一些常见的应用场景： 缺陷管理：根据二八法则，80% 的缺陷通常来自于 20% 的功能模块或者代码区域。在软件质量管理过程中，团队应该重点关注那些最容易引发缺陷的核心功能或者代码部分。这有助于提高缺陷发现和修复的效率，确保关键功能的质量和稳定性。 测试策略：根据二八法则，80% 的软件缺陷往往由 20% 的核心功能或者测试用例引起。在测试策略制定过程中，团队可以优先选择那些最关键、最具代表性的功能进行测试。同时，重点关注那些最有可能引发缺陷的测试用例，以提高测试覆盖和效果。 持续改进：二八法则也可以应用于持续改进的过程中。根据这个原则，80% 的改进效果通常来自于 20% 的关键改进措施。团队应该重点关注那些最重要、最有影响力的改进项目，以最大程度地提升软件质量和用户体验。 用户反馈和需求：根据二八法则，80% 的用户满意度通常来自于 20% 的关键功能或者需求。在软件质量管理中，团队应该重点关注那些对用户最重要、最有价值的功能和需求。通过积极收集用户反馈和需求，团队可以针对性地改进和优化这些关键领域，提升软件的质量和用户满意度。 需要注意的是，二八法则在软件质量管理中的具体应用可能会因项目的特点、复杂性和业务需求而有所不同。团队应该根据具体情况灵活运用这个原则，并结合其他质量管理方法和工具，以实现最佳的软件质量和用户体验。 软件测试中的二八法则 在软件测试中，二八法则可以被应用于缺陷定位和优先级管理。根据这个原则，大约 80% 的缺陷通常来自于 20% 的功能模块或测试用例。这意味着测试团队可以通过重点关注那些最有可能引发缺陷的关键功能，以及那些覆盖最广泛、最重要的测试用例，来获得最佳的测试覆盖和缺陷发现效果。 具体应用二八法则的方法包括： ...

文章介绍接口测试的简介，类型和工具

Google Bard Google Bard 进入公开测试版。测试申请中~~~ 申请链接：https://bard.google.com/ 谷歌发布 Bard，这是其在创建人工智能竞赛中的竞争对手推出 ChatGPT 之后的放的大招。 经过多年的谨慎开发，这家互联网巨头将授予用户访问聊天机器人的权限，以追逐竞争对手 OpenAI 和微软的引人注目的首次亮相之后的惊艳表现。 百度文心一言 百度于 3 月 16 日正式公布大语言模型“文心一言”，这是一款基于人工智能技术的智能对话系统，可进行语义理解、智能问答和情感交流等多种形式的对话。 3 月 16 日起，首批用户即可通过邀请测试码在文心一言官网体验产品，后续将陆续开放给更多用户。 此外，百度智能云即将面向企业客户开放文心一言 API 接口调用服务。 3 月 16 日起正式开放预约，搜索“百度智能云”进入官网，可申请加入文心一言云服务测试。 申请链接：https://yiyan.baidu.com/welcome 合作申请链接：https://cloud.baidu.com/survey_summit/wenxin.html?track=C856571 欢迎关注软件测试同学的公众号“软件测试同学”，原创 QA 技术文章第一时间推送。

打开 edge 浏览器 在地址栏输入命令 edge://flags/ 在 flags 的页面输入 11 进行搜索 在搜索结果下选择“Show Windows 11 visual effects in title bar and toolbar”将状态变更为启用 重启浏览器，即可看到新的 edge 浏览器 UI 欢迎关注软件测试同学的公众号“软件测试同学”，原创 QA 技术文章第一时间推送。

如果你的项目是采用敏捷测试，那么欢迎加入很棒的 30 天敏捷测试挑战。 以下是 30 个挑战的列表，每月每天一个，打印下面的列表，把它保存在某个地方。打印出来。把它贴在墙上。让我们这样做吧！ 规则是什么？ 目标是尽可能多地的完成挑战。您可以在自己的时间范围和能力范围内做到这一点。 您可能有图像可以分享，博客文章，视频，状态更新，无论它是什么！来参加吧！ 以下是分享进度的方法： 在微博和朋友圈上 - 使用**#30DaysOfTesting**标签 30 天敏捷测试列表 Day 1 Buy an agile testing related book and share something you’ve learnt by day 30 买一本敏捷测试相关的书，并在第 30 天结束时分享你的所学 Day 2 Create a mindmap, document, diagram or sketchnote about what you think agile testing is 用图表或文档的方式列出你理解的敏捷测试 Day 3 Find a video on YouTuBe about agile testing, then watch it! 看一个敏捷测试的视频 Day 4 Read the agile manifesto and reflect on the implications for your role 读敏捷宣言，并反思对你角色的影响 Day 5 Pair with a developer on a feature 跟 Dev pair Day 6 Map out what your exploratory testing looks like, compare it to what other testers do 列出你理解的探索式测试，并与其他人员的进行比较 Day 7 Find a visual way of representing your tests - e.g. A mind map, diagram, model, etc 找一个可视化的方式展示你的测试 Day 8 Speak to a developer about a bug you found instead of loging it in the tracking system 跟 dev 直接说你发现的 bug，而不是在 bug 管理系统里记录 Day 9 Pair whth a developer on a code review. Can you identify any risks? 参加 dev 的 code review。你能定位任何的风险吗？ Day 10 Learn where the application logs are and how to read them. 了解应用程序的 log 记录在哪里，并学习看 log。 Day 11 Find out what customers are saying about your product. What did you learn? 了解客户对你的产品的评价。从中学到了什么？ Day 12 What test documentation does your team have? How can you improve it? 你的团队有什么样的测试文档？你觉得可以怎么改进一下？ Day 13 Learn to use a tool that your developers use - e.g. an IDE 学习使用 Dev 在用的工具 Day 14 How can you deliver greater value to your customer? 如何能够交付更多的价值给客户？ Day 15 How can you make your testing processes (more) lean? 如何能让你的测试流程更加精益？ Day 16 What barriers do you feel exist in testing in agile? 你感觉敏捷测试中存在什么障碍？ Day 17 Map out your current team structure. How does it compare to other teams? 绘制出您当前的团队结构。它与其他团队相比如何？ Day 18 How can you make testing jobs easier? 如何让测试工作变得更轻松？ Day 19 How can you make jobs for your team easier? 如何让你的团队工作更轻松？ Day 20 Investigate what is in your and your team’s tool kit 调查你和你团队使用的工具有哪些 Day 21 How are you managing your testing, is it really agile? 你如何管理你的测试，真的敏捷吗？ Day 22 Find out what testing is being done by other team members. 了解其他团队成员正在进行的测试 Day 23 What agile strategies are there for managing tests? 有哪些管理测试的敏捷策略？ Day 24 Look for a task that can be automated. 找一个可以自动化的 task. Day 25 What can’t you automate? Communicate that to your team 什么是你不能自动化的？跟团队沟通一下 Day 26 What does your Test Plan look like, what format do you use? 你的测试计划什么样的，使用的什么格式？ Day 27 Look into zero bug tolerance, is this something your team could do? 了解 bug 零容忍，这是你的团队可以做的吗？ Day 28 What learning culture exist in your company? How can you contribute to it? 公司的学习文化是什么样的？你如何为此贡献？ Day 29 What columns do you have on your work tracker or kanban board? 你们的看板上有哪些 column？ Day 30 What action does your team take on a red build? build 红了团队会采取什么 action？ Day 31 BONUS: Debrief your whole team on your last session of testing 跟整个团队汇报你的测试 欢迎关注软件测试同学的公众号“软件测试同学”，原创 QA 技术文章第一时间推送。 ...