PMP ,专注于WEB功能测试、性能测试、安全测试的研究,从事全面质量管理工作。曾任多家公司测试经理、测试主管。在电子政务、银行、电商、跨境电商、直播电商领域工作多年,曾获得某龙头集团公司公测一等奖,曾任职某头部直播电商公司测试团队负责人,具有业务敏感性,擅长从0到1搭建测试团队,具有海外工作经历,以及质量管理体系搭建。邮箱:89233502@qq.com
发布新日志
-
2008-12-03 16:27:55
敏捷宣言:个体和交互比过程和工具更有价值;能工作的软件比全面的文档更有价值;顾客的协作比合同谈判更有价值;及时响应变更比遵循计划更有价值。- www.agilemanifesto.org
什么是敏捷测试?
测试遵循敏捷宣言进行,把开发作为顾客看待。项目的测试采用敏捷方法论。
敏捷测试的原则与上下文驱动测试(Context-Driven Testing:www.context-driven-testing.com)的原则有交集,例如,上下文驱动测试的七大原则中的第三条:工作在一起的项目组成员是项目的上下文的最重要的组成部分。就与敏捷宣言中的“个体和交互比过程和工具更有价值”一样强调人的作用。
敏捷测试中测试人员扮演的角色
1、 测试是项目的“车头灯”,它告诉大家现在到哪了,正在往哪个方向走。
2、 测试为项目组提供信息,使得项目组基于可靠的信息作出正确的决定。
3、 “BUG”是让用户感觉烦恼的东西,测试人员不作出发布的决定。
4、 测试员不保证质量,整个项目组对质量负责。
5、 测试不是抓虫子的游戏,它的目的不是纠缠在错误中,而是帮助找到目标。
单元测试和可接受性测试
测试驱动开发,开发人员在写代码之前要先写单元测试,用于激发代码的编写、改进设计(降低耦合度,增加内聚)、支持重构。很多开源的测试工具支持单元测试(xUnit)。
用户故事是需要编码实现的功能特性的简短的描述。可接受性测试验证用户故事的完整性。理想的情况下,用户故事是在代码编写前就写完。
测试人员是否应该拥抱敏捷开发?
有些人说XP会导致差的质量并且是偷懒的借口。我认为XP是令人激动的,并将在行业中改进测试的实践。
参见《Testers Should Embrace Agile Programming 》
(http://www.io.com/~wazmo/papers/embrace_agile_programming.html)
敏捷测试实践
通过对话产生测试,谁来测试?客户往往太忙了,不可能参与测试。定义测试是很关键的活动,应该把开发人员和顾客代表包括进来,不要只是测试员自己做。
把用户故事转换成测试。测试提供的是目标和指南、及时的反馈、进度度量。测试应该用指定的格式出现,以便让用户或顾客能清楚明白,还要足够的明确,以便能被执行。
开发人员负责提供支持自动化测试的特性。大部分情况下,为产品添加测试接口,而尽量不用外部测试工具。
计划在每个迭代中探索产品,寻找bug、遗漏的特性和改进的机会。
查看(522)
评论(1)
收藏
分享
管理
-
2008-12-03 16:26:14
把敏捷开发中的测试分为7种类型:
(1)自动化回归测试(Automated regression test)
运行自动化测试代码来验证当前的修改没有破坏已有的功能。
(2)单元测试(Unit test)
验证单元级别的代码工作是否正常。
(3)公共API测试(Public API test)
验证被第三方开发人员调用的API可正常工作,并且得以文档化。
(4)私有API测试(Private API test)
验证内部使用的API工作是否正常。
(5)命令行测试(Command-line test)
验证在命令行输入的命令工作正常。
(6)用户界面测试(User interface test)
验证界面层的功能是否正常。
(7)“狗粮”测试(Dog-food test)
这里用了一个有趣的名字“Dog-food test”,自己的“狗粮”自己先尝尝!在企业内部使用自己开发的产品,通过这种实际地使用来确保功能正确,满足使用要求。
查看(753)
评论(0)
收藏
分享
管理
-
2008-12-03 16:22:05
在敏捷开发中,测试管理者不可能像传统的项目测试一样制定详细的测试计划,那怎样执行测试呢?以下是我总结的一些琐碎经验: 在敏捷开发中整个团队都是测试人员,一起需要对产品质量负责,测试管理人员需要指引大家共同测试,需要发动起大家一起执行测试,而不仅仅是测试人员的事情,这同时也要求整个团队中每个成员对自己的产品了如指掌,测试人员需要共同参与产品的设计和需求分析,在敏捷开发中需求在不断变化,你不可能等着完整的需求文档进行测试需求分析,当产品定义和需求不断的细化时,测试分析也要不断的细化,我很喜欢让测试人员去绘制业务流程图,以及整理功能列表进行测试分析,因为在绘制业务流程图中你可以发现很多的逻辑问题,和产品定义问题,可以即时的和产品定义人员、需求人员进行沟通,立马改进产品设计,敏捷测试中,根据业务流程图或测试分析图书写主要测试用例就行了,你根本就没有时间能面面俱到去维护那么的测试用例,更何况需求和产品定义一直在变化一定要自动化测试,自动化测试脚本中要写好注释,这是测试用例的体现,也便于读取在测试之前制定好测试方案,但测试执行的时间很难控制,一定要熟知数据库。
查看(781)
评论(0)
收藏
分享
管理