- 作为一名测试人员,当需求不断变化时,应该采取什么方法?
当需求不断变化时,持续敏捷测试人员应该采取以下方法
- 编写通用的测试计划和测试用例,重点放在需求的意图上,而不是它的确切细节上
- 要了解更改范围,与产品所有者或业务分析师密切合作
- 确保团队理解变更需求所涉及的风险,尤其是在冲刺的末尾
- 在要素稳定并最终确定要求之前,如果要自动执行要素,最好等待
- 通过协商或在下一次冲刺中实现更改,可以将更改保持在最低限度
- 列出探索性测试(在敏捷中使用)和脚本化测试的优缺点?
测试 | 专业人士 | 缺点 |
---|---|---|
探索性测试 | -它需要较少的准备工作-在需求更改时易于修改-在缺少文档的情况下工作良好 | -向项目管理提出进展和覆盖面是困难的 |
脚本化测试 | -在违反法律或法规要求的情况下进行测试,这是非常有用的 | -测试准备通常很耗时-反复测试相同的步骤-当需求更改时,很难修改 |
- 解释极限编程和Scrum的区别?
Scrum | 极限编程(XP) |
---|---|
-Scrum团队通常必须在称为冲刺的迭代中工作,该迭代通常持续两周到一个月 | -XP团队在持续一到两周的迭代中工作 |
-Scrum团队不允许更改他们的短跑项目 | -XP团队更加灵活,可以更改其迭代 |
-在Scrum中,产品负责人确定产品待办事项的优先顺序,但团队决定开发待办事项的顺序 | -XP团队按照严格的优先级顺序工作,开发的功能由客户确定优先顺序 |
-Scrum没有规定任何工程实践 | -XP确实规定了工程实践 |
- 什么是EPIC,什么是用户故事和任务?
EPIC: 产品待办事项中详细列出的客户描述的软件特性称为EPIC。EPIC又细分为故事。
用户故事: 从客户的角度出发,准备定义项目或业务功能的用户故事,并按照预期在特定的冲刺中交付。
任务: 进一步向下将用户情景分解为不同的任务
- 解释什么是重构?
为了提高性能,修改了现有代码;在重构过程中,代码功能保持不变
- 解释如何在团队能力不同的情况下测量冲刺 的速度?
通常在规划冲刺时,冲刺的速度是基于历史数据的专业判断来测量的。然而,用来测量短跑速度的数学公式是,
- 第一个完成的故事点X团队能力:如果以每周40小时的百分比来衡量能力
- 第二个完成的故事点/团队能力:如果以工时衡量能力
对于我们的场景,第二种方法是适用的。
- 冲刺待办事项和产品待办事项之间的主要区别?
产品待办事项:它包含所有所需特性的列表,归产品所有者所有。
冲刺待办事项:它是开发团队拥有的产品待办事项的子集,并承诺在Sprint中交付。它是在Sprint Planning会议中创建的
- 在敏捷中提到增量开发和迭代开发有什么不同?
迭代:迭代方法是软件开发的连续过程,其中重复软件开发周期(Sprint&Releases),直到最终产品。
版本1:Sprint 1,2…n
版本n:Sprint 1,2….N
增量:增量开发将系统功能分成增量或部分。在每个增量中,从需求到部署,每一段功能都是通过跨学科工作交付的。
- 解释什么是敏捷中的Spike和Zero Sprint?它的目的是什么?
Sprint Zero: 引入它是为了在启动第一个Sprint之前执行一些研究。通常,该冲刺在项目开始时用于设置开发环境、准备产品待办事项等活动。
冲刺: 冲刺是用于研究、探索、设计甚至原型制作等活动的故事类型。尖冲刺两种类型:技术冲刺和功能冲刺。
- 什么是测试驱动开发?
测试驱动开发或TDD也称为测试驱动设计。在此方法中,开发人员首先编写描述新功能或改进的自动化测试用例,然后创建小代码以通过测试,然后重构新代码以满足可接受的标准。
- 原型和线框被广泛用作?
原型和线框是被广泛用作经验设计一部分的原型。
- 解释什么是应用程序二进制接口?
在不同的系统平台和环境中,定义二进制形式的应用程序可移植性要求的规范称为应用程序二进制接口。
- 在敏捷、消耗和消耗图表中解释?
为了跟踪项目进度、耗尽和耗尽,可以使用图表。
燃尽图:它显示了随着时间的推移故事的进展情况。
工作倦怠图表:它显示了有多少工作需要加类。
- 解释什么是Scrum BAN?
Scrum BAN是一个基于Scrum和看板的软件开发模型。它是专门为需要频繁使用这些方法项目设计的,团队的工作流以允许每个用户情景或编程错误的最短完成时间的方式进行指导。
- 什么是故事点/困难/规模?
它被用来讨论故事的难度,而不指定实际的时间。最常用的标度是斐波那契序列(1,2,3,5,8,13,….100)尽管有些团队使用线性刻度(1,2,3,4….),2的幂(1,2,4,8……)和布料尺寸(XS、S、M、L、XL)。
- 解释什么是示跟踪?
跟踪项目符号是当前体系结构、当前的一组最佳实践、当前的技术集的一个峰值,这些都会产生产品质量代码。它不是丢弃的代码,而可能只是该功能的狭义实现。
- 什么是测试存根?
测试存根是替换正在测试的系统中未开发或完全开发的组件的小代码。测试存根是这样设计的,它通过生成特定的已知输出来模拟实际组件,而替身生成实际组件。
- RUP(Rational Unified Process)和Scrum方法之间有什么不同?
RUP | Scrum |
---|---|
-正式周期跨四个阶段定义,但某些工作流可以是并发的 | -每一次冲刺都是一个完整的周期 |
-使用正式的项目计划,关联多次迭代。 | -没有端到端项目计划。每个下一次迭代计划在当前迭代结束时确定 |
-范围在项目开始之前预先定义,并记录在范围文档中。在项目期间,范围可以修改。 | -它使用项目积压而不是范围Scrum |
-工件包括范围文档、正式功能需求包、系统架构文档、开发计划、测试脚本等。 | -操作软件是唯一正式的人工制品 |
-建议用于复杂程度从中到高的长期、大型、企业级项目 | -建议用于不受截止日期限制的快速增强和组织 |
- 为什么持续集成对敏捷很重要?
持续集成对于敏捷来说非常重要,原因如下。
- 它通过检测错误或集成错误来帮助按时维护发布计划
- 由于频繁的敏捷代码交付(通常是每2-3周的冲刺),稳定的构建质量是必须的,并且持续集成确保
- In有助于保持代码库的质量和无错误状态
- 如果开发工作在使用自动构建和合并功能的分支上进行,持续集成有助于检查工作对到主干的分支的影响
- 在敏捷过程中进行哪些测试?
敏捷期间的主要测试活动是自动化单元测试和探索性测试。 但是,根据项目要求,测试人员可以对被测应用程序(AUT)执行功能性和非功能性测试。
- 解释什么是敏捷中的速度?
速度是一个度量,它是通过将迭代中完成的与用户故事相关的所有工作量估计相加而计算出来的。它计算出敏捷在一次冲刺中可以完成多少工作,以及完成一个项目需要多少时间。
- 优秀的敏捷测试人员应该具备哪些素质?
一名优秀的敏捷测试人员应该具备以下素质
- 它应该能够快速理解需求
- 敏捷测试人员应该非常了解敏捷的原则和概念
- 随着需求的不断变化,测试人员应该了解其中涉及的风险
- 基于需求,敏捷测试人员应该能够对工作进行优先级排序
- 必须保持业务伙伴、开发人员和测试人员之间的沟通
- 谁参与了敏捷团队?
在Agile中,两个主要线索是
-
Scrum教练:它协调敏捷程序所需的大部分输入和输出
-
开发经理 :他们雇佣合适的人,并与团队一起培养他们
- 详细提到Scrum教练的角色是什么?
Scrum教练职责包括
- 了解需求并将其转化为工作软件
- 监控和跟踪
- 报告和沟通
- 进程检查主进程
- 质量大师
- 解决障碍
- 解决冲突
- 保护团队和绩效反馈
- 主持所有会议并解决障碍
- 提到什么是敏捷质量策略?
敏捷质量策略有
- 重构
- 非单独开发
- 静态与动态代码分析
- 审查和检查
- 迭代/冲刺演示
- 全体人员演示
- 轻量级里程碑回顾
- 短反馈周期
- 标准和准则
- 提到在处理敏捷项目时有哪些工具可以用于截图?
在处理敏捷项目时,可以使用如下工具
- BugDigger
- BugShooting
- qTrace
- Snagit
- Bonfire
- Usersnap
- 在整个项目中保持一致迭代周期的优势是什么?
优点是
- 它帮助团队客观地衡量进度
- 它提供了测量团队速度的一致方法。
- 它有助于建立一致的交付模式
- 如果时间计划需要重新排序,谁应该重新排序?
如果时间计划需要重新划分优先级,它应该包括整个团队、产品所有者和开发人员。
- 燃尽表应该突出哪些内容?
燃尽图显示了在时间周期(迭代)结束之前要完成的剩余工作。
- Scrum和敏捷之间的区别是什么?
-
Scrum :在Scrum中,Sprint是开发的基本单位。每次冲刺之后都会召开一次计划会议,在每次冲刺期间,团队会创建产品的成品部分
-
敏捷 :在敏捷中,每次迭代都涉及一个团队在整个软件开发周期中工作,包括计划、设计、编码、需求分析、单元测试,以及向涉众演示产品时的验收测试
简而言之,敏捷就是实践,Scrum就是遵循这个实践的过程。
- 敏捷软件开发中涉及的挑战是什么?
敏捷软件开发中涉及的挑战包括
- 需要更多的测试和客户参与
- 对管理的影响比对开发人员的影响更大
- 每个功能都需要完成,然后才能继续下一个功能
- 所有代码都必须正常工作,以确保应用程序处于工作状态
- 需要更多的规划
- 什么时候不使用敏捷?
在使用敏捷方法之前,必须问以下问题
- 功能是否可拆分
- 客户是否可用
- 需求是否灵活
- 时间真的很紧吗?
- 团队技术是否足够
- 解释如何以一种简单的方式在项目中实现Scrum?
这些技巧可以帮助在项目中实现Scrum。
- 整理积压工作
- 了解产品待办事项的大小
- 澄清Sprint需求和持续时间以完成Sprint Backlog
- 计算团队冲刺预算,然后将需求分解为任务
- 协作工作区-所有团队讨论的中心,包括计划、路线图、关键日期、功能草图、问题、日志、状态报告等。
- 冲刺–在进入下一个功能之前,确保一次完成一个功能。除非没有其他选项,否则不应中止冲刺
- 参加每日的站立会议:在会议中,需要提到,自上次会议以来取得了什么成就,他们在下次会议之前将取得什么成就,有什么阻碍了他们的进展
- 使用燃尽表跟踪每日进度。从燃尽表中,可以估计是在正轨上,还是在落后。
- 先完成每个要素,然后再转到下一个要素
- 在冲刺结束时-召开冲刺评审会议,提及冲刺中取得的成就或交付的成果。
- 解释产品路线图意味着什么?
产品路线图是指创建产品愿景的产品功能的整体视图。