写点什么
创作场景
- 记录自己日常工作的实践、心得
- 发表对生活和职场的感悟
- 针对感兴趣的事件发表随笔或者杂谈
- 从 0 到 1 详细介绍你掌握的一门语言、一个技术,或者一个兴趣、爱好
- 或者,就直接把你的个人博客、公众号直接搬到这里
登录/注册
收录了 设计测试用例 频道下的 50 篇内容
在测试自动化中,测试代码中不仅仅包含测试逻辑,还包含许多其他代码,比如URL拼接、html/xml解析、访问UI控件,等等。若把测试逻辑与这些无关代码混在一起,测试逻辑将会很难理解, 也不容易维护。本文会介绍如何用分层结构来解决测试自动化中遇到的这些问题。
我们之前介绍过了等价类和边界值来设计我们的测试用例,等价类和边界值是我们最常用的测试用例设计方法之一,本文我们将向大家介绍场景法。
我们之前介绍了等价类边界值场景法来设计测试用例,本篇文章我们来介绍一下使用因果图来设计测试用例。

携程目前很多的框架和项目都在往 Java 技术栈上进行迁移。在这个过程中我们遇到很多的挑战和困难,为此我们在原有测试体系的基础上做了大量的工作,构建了一整套卓有成效的质量保障体系。
在上两篇文章《什么是敏捷软件测试》与《自动化测试-敏捷测试的基石》中,我们阐述了敏捷测试的概念,并简单介绍了敏捷测试中的自动化测试观点。在这篇文章中,我们将围绕“测试组如何在组织中组织敏捷测试”这个话题来展开讨论。
w3ctech 2011 JavaScript专题会议(上海站)最近在张江畅星大厦召开,参会者200多人,来自国内技术社区的四位知名专家高博、权一、杜欢、贺师俊分别做了精彩的演讲,涉及的内容包括测试驱动开发、ES5新特性、iOS上的Web应用、Javascript框架API设计思想等。InfoQ中文站整理了大会的精彩内容,供读者参考。
今天,很多软件并没有经过专门的安全测试便运行在互联网上,它们携带着各类安全漏洞直接暴露在公众面前,其中一些漏洞甚至直指软件所承载的核心敏感信息或业务逻辑。这些漏洞一旦被不怀好意者利用,很可能会给企业造成经济损失,带来负面声誉影响的同时,还可能被起诉遭到罚款等等,细思极恐。其中的一部分原因是企业本身安全意识不强,但是很多时候虽然软件企业已经开始意识到这些问题,却苦于缺少专业的安全测试人员,他们不得不冒着极大的风险先上线赌一把运气再说。

随着互联网技术的发展,产品的快速迭代且能适应市场需求已经成为各大公司的痛点。而传统的开发模式已经不再适用于快速迭代的产品,在这种情况下,敏捷开发模式因其高度迭代、频繁交付以及适应变化的特点,已经在各个领域得到广泛应用。
探索式测试(Exploratory Testing)是敏捷测试中的重要组成部分,其价值与一般性测试如用户故事测试或者自动化测试不同,它所关注的是“意料之外”的软件缺陷,探索式测试作为一个研究性、启发性和严肃性并存的测试方法,是一般性测试的重要补充。随着敏捷测试的推广,探索式测试逐渐受到大家的关注和重视。本文主要探讨了测试工程师在探索式测试方面的一些误区,并尝试纠正这些问题。


Wikipedia上对符号执行的解释:是一种程序分析技术,其可以通过分析程序来得到让特定代码区域执行的输入。

本文介绍知乎开发的实时收集代码覆盖率的工具 Timon。
测试用例可以用来衡量一个项目测试质量,因此在平时的测试流程中,编写测试用例就是测试过程中很重要的一步,每一个测试工程师都需要并且非常熟练的编写测试用例,能在编写测试用例中尽可能的覆盖任何异常的测试点。
TamanduaOATs 是测者开发并开源的生成正交计算的pyd(python库)程序(放到python下的dlls目录下)
我们之前介绍了等价类测试用例设计方法,但是等价类测试用例设计方法容易存在问题,即我们取的值不一定在我们程序设计的边界附近,但是在我们的测试实践中,问题往往都是出在输入定义域或输出值域的边界上,而不是在其内部。因此,针对各种边界情况设计测试用

自动化测试之所以难以真正铺开,很多时候并不是因为团队不重视,而是因为门槛太高: 业务人员不会写代码,测试脚本又难维护。Microsoft Edge QA 团队开源的 AutoGenesis,想解决的正是这个问题: 让测试人员只需要用自然语言描述场景,就能借助 AI 生成自动化代码,并由确定性的程序稳定执行。基于这一路径,团队在 Windows、macOS、iOS、Android 四个平台上验证了方案可行性。本文将拆解其基于 MCP 的架构设计、代码生成与执行机制,以及它如何帮助非技术背景成员真正参与自动化建设,并通过 200 万+ 月执行步骤、99% 通过率、700+ 用例规模等数据,展示这套方案在效率、稳定性和规模化落地上的实际价值。