- 博客(54)
- 资源 (5)
- 收藏
- 关注
RSS订阅
转载 敏捷测试--开源电子书连载
版权说明本书为开源电子书，通过github维护。任何人都可以对该书进行投稿和修订。本参考书旨在帮助大家更好的学习敏捷测试，在尊重和注明来源的情况下，可以自由的使用和传播。 本参考书编写过程中，参考了大量的资料。文中尽可能的将所有参考的资料的来源做了标注。但是仍然可能存在一些遗漏的地方，如果对此有异议，可以及时联系我们进行更新。本文档处于持续更新中。为了便于维护和更新，最新的内容在Git...
2019-10-03 10:48:08
315
原创 学习ISTQB基础级的正确姿势
首先，在淘宝上购买TBOK录制的最强ISTQB基础级学习视频套件（https://item.taobao.com/item.htm?spm=a1z10.1-c.w4004-12986406116.3.465b46646igDk7&id=597627601376）这个史上内容最精炼、质量最高的ISTQB基础级视频。这个价格就是一顿饭的事情，但是可以节约你大量的宝贵时间，有了这个视频，就不需...
2019-08-15 14:15:00
3981
10
原创 ISTQB基础级考试资料汇总
ISTQB基础级中文大纲（2018版本）ISTQB基础级官方中文模拟题：目前官方一共有三套模拟题。ISTQB模拟题A卷ISTQB模拟题B卷ISTQB模拟题C卷ISTQB基础级电子书：这个电子书是放在github上的，可以免费阅读。如果你愿意，也可以成为贡献者，对该电子书进行修订。ISTQB 基础级全套视频（大纲讲解+难点解析+模拟题）：这个是TBOK录制的视频，价格太厚...
2019-08-15 14:14:33
4973
2
转载 ISTQB基础级认证参考书
以敏捷的方式编写针对ISTQB初级大纲（2018）版的参考书。有兴趣的朋友请加QQ群927659742。简单说一下编写参考书的情况：凡是获得ISTQB FL证书的人都可以报名参加；轻量级的工作量，以一个学习目标为最小编写单元，方便大家参与；最终的参考书将发布在网络上共所有人免费学习使用。...
2019-08-04 15:09:46
1106
转载 测试驱动开发、验收测试驱动开发和行为驱动开发
敏捷中出现各种”XX驱动开发“的实践。起源主要是来自Kent在极限编程中提出的测试优先编程（Test-First Programming）。现在出现了（除了行为驱动开发以为，相关的还有像实例驱动开发（EDD-Example Driven Development），特性驱动开发（FDD-Feature Driven Development）等。各种驱动开发之间的关系众说纷纭这里我们来聊一聊测试驱...
2019-11-11 13:28:17
1559
转载 ”假敏捷“和”真敏捷“--大家都在走向敏捷的路上！
很多团队在从传统开发模式向敏捷开发转型的过程中，都会遇到困惑：那就是现在我们做的算是“真”敏捷吗？当团队准备向敏捷转型的时候，大家都会先热情高涨的去学习各种敏捷知识，包括前面章节提到的原则、实践和工具等。兴奋的感觉找到了圣杯。但是一旦开始真的实施敏捷后，很快就要面对各种残酷的现实：哪里找到那么好的客户能够经常来互动？ 说好的持续构建和集成保证质量，怎么一跑测试程序就飞了？ 每个迭代都回...
2019-10-03 10:42:26
289
转载 保险行业大型数字业务转型项目案例
简要介绍如何根据项目的组织、交付模型和人员结构来设计适用的测试架构及流程项目背景：保险行业大型数字业务转型项目 使用SAFE模型，有8个敏捷小组（agile team）及其它shared service team。 测试团队定位为 share service team，敏捷小组中没有测试人员，使用业务分析师（BA）兼职测试，项目成员都没有测试相关背景及相关技能。 系统复杂性高，集...
2019-10-03 10:41:36
660
转载 这些年目睹之敏捷怪现象
敏捷中很多的实践都是来自于20世纪90年代，甚至更早。随着2001年敏捷宣言的提出，敏捷在IT领域的使用越来越广泛。这也说明了敏捷可以给大家带来很多非常好的帮助。这次要讲的内容并不是要来赞美敏捷的，而是希望从一些做的不好的方面来对敏捷在IT领域的应用做一些反思。希望能够触发大家对敏捷的一些思考。敏捷不仅是给原班人马换个称呼在团队刚开始准备向敏捷转型的时候，经常有人会问“原来的项目经理在...
2019-10-03 10:40:35
232
转载 敏捷中哪些测试可以自动化
你能想到的大多数测试类型都得益于自动化。手工的单元测试并不会阻止回归失败，因为每次在万事具备的情况下执行一套手工测试并不现实。你也无法通过手工的单元测试保证测试先行。一旦程序员不能通过单击按钮快速执行测试，他们就不想再执行测试了。我们可以通过手工的方式测试不同单元的代码以保证其正确运行，但自动化的组件测试是更有效的安全网。手工测试有助于发现功能上的缺陷，但如果没有足够多的自动化业务回归测试，我...
2019-10-03 10:39:35
507
转载 自动化测试的分类
本节以不同的视角重新审视测试象限。先来仔细看看象限图，如下图所示：我们将支持团队的两个象限（象限一和象限二）标记为使用自动化。在象限四中，从技术视角来看，用于评价产品的工具通常也需要自动化。采用自动化业务测试工具来支持团队。只有象限三----评价产品的业务测试----没有标记为使用自动化。工具对于某些测试来说还是有用的，比如，自动化可以创建好测试数据和用户场景对日志进行分析。...
2019-10-02 11:05:55
662
转载 将敏捷法则应用到测试自动化上
每个团队、每个项目以及每个企业都会遇到独有的自动化挑战。每个企业都有自己的文化、历史、资源、业务压力、产品和经验。无论你所在团队处于何种情况，你都可以使用敏捷法则和价值来寻找解决方案。勇气、反馈、简化、交流、持续开发和快速响应这些概念不仅仅属于敏捷，他们是所有成功团队所应具备的特质。1 保持简单保持测试设计简单、保持范围最小化，使用最简单的工具完成工作。简单是敏捷的核心价值。上手的最好...
2019-10-02 11:05:04
188
转载 探索性测试在敏捷中的应用
探索式测试（Exploratory Testing）是 Cem Kaner 在 1983 年提出的。它是一种软件测试风格，强调测试人员的自由与责任的测试方法，为了持续优化其工作的价值，将测试相关学习、测试设计、测试执行和测试结果分析作为相互支持的活动，在整个项目过程中并行地执行。探索性测试在敏捷中广泛使用的原因大家可能注意到探索性测试的概念提出来的时间非常早，上个世纪80年代就出现了。但是...
2019-10-02 11:03:22
590
转载 敏捷中的独立测试团队会消失吗
当敏捷的春风吹在世界大地上的时候，最恐慌的是谁呢？不管传统项目中的其他角色的心情是如何的，大部分测试人员肯定是惴惴不安的。为什么？大家学习了敏捷后，发现其实没有测试人员什么事啊！在敏捷中，测试这个活本身还是在的，但是执行的主体发生了重大变化，那就是很多测试的职责从原来的独立的测试人员身上转移到了开发人员身上了。就像什么测试驱动开发、验收测试驱动开发、持续构建、持续集成、持续交付等，这些活动中都需要...
2019-10-02 10:59:10
371
转载 敏捷测试的本质、核心价值观和角色变化
敏捷测试的本质测试遵循敏捷宣言进行，把开发作为顾客看待。项目的测试采用敏捷方法论。 敏捷测试的原则与上下文驱动测试的原则有交集，例如，上下文驱动测试的七大原则中的第三条：工作在一起的项目组成员是项目的上下文的最重要的组成部分。与敏捷宣言中的“个体和交互比过程和工具更有价值”一样强调人的作用。持续地对软件质量问题进行及时地反馈 。敏捷测试也意味着测试遵循敏捷的基本原则，接纳敏捷的核心价值...
2019-10-02 10:57:18
612
转载 看板
看板看板方法，一般认为是由大卫安德森（David J. Anderson)发明创造的，于2004年诞生在微软的XIT项目，并于06年至07年之间在Corbis公司得到大规模运用，紧接着在全球迅速推广。大卫在发明看板方法之初，便深受了大野耐一的丰田生产方法（TPS），高德拉特的约束理论（TOC），戴明的质量管理，以及敏捷开发的影响。因此，看板方法中的很多概念，都可以从上述理论中找到影子。看板...
2019-10-02 10:56:07
568
转载 Scrum
什么是Scrum Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是一至四周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是...
2019-10-02 10:54:51
1114
转载 极限编程
XP（Extreme Programming）的由来本部分关于XP的主要的内容参考的是Kent在2004年写的《解析极限编程-拥抱变化》，如果对比他在1999年出版的第一个 版本的话，你会发现其中无论是价值观、原则和实践都发生了一些变化，当然这个恰恰体现了敏捷的拥抱变化。XP中提到的价值观和各种原则很多都是思想层面和面对事物我们应该如何思考，他们不仅仅可以用在软件开发中，也可以用在我们生活...
2019-10-02 10:53:48
1576
1
转载 敏捷介绍
敏捷宣言和原则2001 年，一批专家在对一系列轻量级软件开发中广泛使用的方法进行讨论后，同意将一些具有共性的价值观和原则汇集成敏捷软件开发宣言，或称为敏捷宣言[Agilemanifesto]。敏捷宣言包含以下四条价值观：个体和互动高于流程和工具 工作的软件高于详尽的文档 客户合作高于合同谈判 响应变化高于遵循计划敏捷宣言认为，尽管右项是有价值的，但是更重视左项的价值。个体和互动...
2019-10-02 10:52:23
747
原创 什么是Phase containment？阶段遏制？阶段缺陷修复率？缺陷阶段移除率？
ISTQB新增加的术语中出现了一个术语，英文是“phase containment”，中文翻译成“阶段遏制”，大家理解起来感觉有些拗口。那么我们先来看看英文原文是什么。别怕，非常简单的一段英文。The percentage of defects that are removed in the same phase of the software lifecycle in which they ...
2019-04-14 11:28:18
957
1
原创 ISTQB中的概要测试用例和详细测试用例的区别？
类似于软件工程中把开发的设计分成概要设计和详细设计，ISTQB把测试用例也分成概要测试用例和详细测试用例。再详细讲解概念之前，我们先要知道这两个概念的等同说法：概要测试用例也称为逻辑测试用例或抽象测试用例详细测试用例也成为具体测试用例**概要测试用例：**没有具体的（实现级别）输入数据和预期结果的测试用例。实际值没有定义或是可变的，而用逻辑概念来代替。**详细测试用例：**具有具体的（实...
2019-04-14 11:18:03
620
原创 ISTQB中的测试条件是什么？和测试用例的前置条件有什么区别？
ISTQB中有个特别的概念叫“测试条件”。很多考生在第一次接触到这个概念的时候会有所困惑，实际工作中好像从来没听过这个概念。测试条件这个概念确实非常罕见，笔者工作了十几年，从来没见过有哪个公司的人编写测试条件的（也可能是孤陋寡闻了。。。）按照ISTQB的术语定义。所谓的测试条件就是能够被一个或多个测试用例验证的条目或事件。“测试条件“在ISTQB中就等同于另外一个概念“测试需求”。测试需求这个概...
2019-04-12 13:40:56
4774
1
原创 三角形的决策表优化问题
ISTQB初级模拟题中这道关于三角形决策表的问题经常有人问。这里稍微解释一下。这道题目的答案是B，就是优化后的决策表只有6条。首先我们看规则9到规则16，这个八条决策表是可以合并成一条的。就是当C1为N的时候，不管其他条件是什么，得到的都是A1：非三角形。这样决策表经过上面这个八合一的优化后就变成9条规则了。这个里面还需要去掉规则2、规则3和规则5这三条不符合逻辑的，因为这三条规则不符合逻...
2018-10-10 19:57:03
5874
翻译 7 参考资料
标准ISO/IEC/IEEE 29119-1 (2013) Software and systems engineering - Software testing - Part 1: Concepts and definitionsISO/IEC/IEEE 29119-2 (2013) Software and systems engineering - Software testing - ...
2018-10-09 11:54:13
336
1
翻译 6.2有效使用工具
6.2.1 工具选择的主要原则为组织选择工具的主要考虑因素包括：• 评估组织的成熟程度、优势和弱势• 识别通过工具支持下进行改进测试过程的机会• 了解测试对象使用的技术，以便选择与该技术兼容的工具• 组织内已经使用的构建和持续集成工具，以确保工具的兼容性和集成• 根据明确的需求和客观准则评价该工具• 考虑该工具是否可免费试用（以及使用多长时间）• 评价供应商(包括培训、支持和商业方...
2018-10-09 10:33:37
388
翻译 6.1 测试工具的考虑
测试工具可以用来支持一个或多个测试活动。这些工具包括：• 直接用于测试的工具，如测试执行工具和测试数据准备工具• 有助于管理需求、测试用例、测试规程、自动化测试脚本、测试结果、测试数据和缺陷的工具，以及用于报告和监视测试执行情况的工具• 用于调查和评价的工具• 任何有助于测试的工具（这个意义上电子表格也是测试工具）6.1.1 测试工具分类测试工具可以根据上下文有以下一个或多个目的：•...
2018-10-08 08:13:50
378
翻译 6工具支持的测试
关键词数据驱动的测试(data-driven testing), 关键字驱动的测试(keyword-driven testing), 性能测试工具(performance testing tool), 测试自动化(test automation), 测试执行工具(test execution tool), 测试管理工具(test management tool)测试工具的学习目标6.1测试工...
2018-10-08 08:13:17
192
翻译 5.6缺陷管理
因为发现缺陷是测试目的之一，所以应该记录测试过程中发现的缺陷。基于测试组件或系统的上下文、测试级别和软件开发生命周期模型的不同，记录缺陷的方式会有所不同。任何识别的缺陷都应该被调查，并跟踪从发现和分类到解决问题的过程（例如：修复缺陷和成功验证解决方案，推迟到后续的发布，接受为永久性产品限制等）。为了解决所有缺陷，组织应建立缺陷管理过程，其中包括工作流和分类规则。这个过程必须与参与缺陷管理的所有人达...
2018-10-08 08:12:56
581
翻译 5.5风险与测试
5.5.1 风险定义风险涉及将来发生具有负面后果的事件的可能性。风险级别由事件的可能性和该事件的影响（损害）决定。5.5.2 产品和项目风险产品风险涉及工作产品(例如规格说明、组件、系统或测试)可能无法满足其用户和/或利益相关者的合法要求。当产品风险与产品的特定质量特性（如功能适用性、可靠性、性能效率、易用性、安全性、兼容性、可维护性和可移植性）相关联时，产品风险也称为质量风险。产品风险的例...
2018-10-08 08:12:34
408
翻译 5.4配置管理
配置管理的目的是在项目产品生命周期内，建立和维护组件或系统、测试件及其彼此之间的关系的完整性。为了正确地支持测试，配置管理需要确保：• 所有测试项都是唯一的标识、版本控制、变更跟踪和相互关联• 测试件的所有条目都唯一的标识、版本控制、变更跟踪、相互关联并与测试项的版本关联，以便在整个测试过程中保持可追溯性• 所有识别的文档和软件项在测试文档中明确引用测试规划过程中，应识别和实施配置管理规...
2018-10-08 08:12:05
296
翻译 5.3测试监控
测试监视的目的是收集信息，，并为测试活动提供反馈和可见性。需要监视的信息可以通过手工或自动方式收集，并应用于评估测试进度，以及测量是否满足测试出口准则，或与敏捷项目的已完成定义相关的测试任务是否已完成，如达到产品风险、需要或验收准则的覆盖率要求。测试控制描述了根据收集和（可能）报告的信息和度量，所采取的任何指导或纠正行动。行动可能涵盖任何测试活动，并可能影响任何其他软件生命周期活动。测试控制行...
2018-10-08 08:11:41
418
翻译 5.2 测试规划与估算
5.2.1 测试计划的目的与内容测试计划罗列了开发和维护项目的测试活动。规划受组织的测试方针和测试策略、开发生命周期和使用的方法（见第2.1节）、测试范围、目标、风险、约束、重要性、可测试性和资源的可用性等因素的影响。随着项目和测试计划的进展，更多的信息变得可用，更多的细节可以包括在测试计划中。测试计划是一项持续的活动，贯穿于整个产品的生命周期。（请注意，产品的生命周期可能超出项目的范围以包括...
2018-10-08 08:11:15
664
翻译 5.1测试组织
5.1.1 测试的独立性测试任务可以由特定测试角色的人完成，也可以由其他角色的人（例如客户）完成。由于作者和测试人员之间存在认知偏差，一定程度的独立性往往使测试人员能更有效地发现缺陷（见第1.5节）。然而，独立性并不能代替熟悉性，开发人员可以高效地在自己的代码中发现许多缺陷。测试中的独立性程度包括（从独立程度低到高）：• 没有独立的测试人员；唯一可用的测试形式是开发人员测试自己的代码• 开...
2018-10-08 08:10:44
1475
翻译 5 测试管理
关键词配置管理(configuration management), 缺陷管理(defect management), 入口准则(entry criteria), 出口准则(exit criteria), 产品风险(product risk), 项目风险(project risk), 风险(risk), 风险级别(risk level), 基于风险的测试(risk-based testing),...
2018-10-08 08:10:28
319
翻译 ISTQB基础级大纲（2018）-中文翻译
截至2018年10月，中国地区考试并未使用2018版的新大纲，具体启用时间务必和考试机构确认。1 软件测试基础1.1 什么是测试1.2 为什么需要测试1.3七个测试原则1.4测试过程1.5测试心理学2. 贯穿软件开发生命周期的测试2.1 软件开发生命周期模型2.2测试级别2.3测试类型2.4维护测试3静态测试3.1静态测试基础3.2评审过程4测试技术4.1 测试技术...
2018-10-07 13:18:19
3223
2
翻译 4.4基于经验的测试技术
在应用基于经验的测试技术时，测试用例来自测试人员的技能和直觉，以及他们在类似应用和技术方面的经验。这些技术有助于识别其他更系统化的技术难以识别的测试。根据测试人员的方法和经验，该技术可以实现的覆盖率和有效性会截然不同。这些技术难以评估覆盖率，也难以度量。常用的基于经验的技术将在下个章节讨论。4.4.1 错误推测错误推测基于测试人员的知识，是用来预测错误、缺陷和失效发生的技术，包括：• 应用...
2018-10-07 13:03:25
2995
翻译 4.3白盒测试技术
白盒测试是基于测试对象的内部结构。白盒测试技术可以应用在所有测试级别，但本节讨论的两种与代码相关的技术最常用在组件测试级别上。有些更高级的技术会用于安全关键、任务关键，或高完整性环境以实现更彻底的覆盖，但这里不会讨论。有关此类技术的更多信息，请参见ISTQB高级技术测试分析师大纲。4.3.1 语句测试和覆盖语句测试使用代码中的可执行语句。覆盖率以测试执行的语句数除以测试对象中可执行语句的总数来...
2018-10-07 13:02:57
628
翻译 4.2黑盒测试技术
4.2.1 等价类划分等价类划分将数据划分为几类（也称为等价类），同一个分类中所有成员都以同样的方式处理（参见Kaner 2013和Jorgensen 2014）。等价类分为有效值和无效值。• 有效值指的是组件或系统应该接受的值。包含有效值的等价类称为“有效等价类”。• 无效值指的是组件或系统应该拒绝的值。包含无效值的等价类称为“无效等价分类”。• 可以为与测试对象有关的任何数据元素，包括...
2018-10-07 13:02:35
479
翻译 4.1 测试技术分类
本节讨论的这些测试技术的目的是帮助识别测试条件、测试用例和测试数据。4.1.1 选择测试技术选择使用何种测试技术取决于多种因素，包括：• 组件或系统的类型• 组件或系统的复杂性• 法规标准• 客户或合同需求• 风险级别• 风险类型• 测试目标• 文档可用性• 测试人员的知识和技能• 工具可用性• 时间和预算• 软件开发生命周期模型• 软件的预期使用• 被测组件或系统...
2018-10-07 13:02:03
1309
翻译 4测试技术
关键词黑盒测试技术(black-box test technique), 边界值分析(boundary value analysis), 基于检查表的测试(checklist-based testing), 覆盖(coverage), 判定覆盖(decision coverage), 决策表测试(decision table testing), 错误推测(error guessing), 等价类...
2018-10-07 13:01:27
423
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人