《软件测试的艺术》笔记 09 - 敏捷开发模式下的测试

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/engrossment/article/details/91410777

敏捷软件开发宣言

  • 我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观
    • 个体和互动高于流程和工具。
    • 工作的软件高于详尽的文档。
    • 客户合作高于合同谈判。
    • 响应变化高于遵循计划。
  • 也就是说,尽管右项有其价值,我们更重视左项的价值。

敏捷开发的特征

  • 依赖客户的参与。
  • 测试驱动。
  • 紧凑的迭代开发周期。

敏捷测试

  • 本质上,敏捷测试是协同测试的一种形式,它要求每一个人都参与到测试计划的设计、实现以及执行中去。他们的任务是通过持续的测试反馈推动项目进行,帮助开发者修复缺陷。

极限编程与测试

  • 极限编程(XP)的关注点是:
    • 实现简单的设计。
    • 开发人员与客户的沟通协作。
    • 不断地测试代码库。
    • 重构以适应规格说明的变更。
    • 寻求用户的反馈。
  • XP 更倾向于适合中小规模的软件开发,这些软件的规格说明变更非常频繁,而且它们还可以进行接近实时的沟通。
  • 单元测试是极限测试中采用的主要测试方法,它具有两条简单规则:所有代码模块在编码开始之前必须设计好单元测试用例,在产品发布之前必须通过单元测试。

廖杰良 - 2019-6-11

展开阅读全文

敏捷开发模式下的测试思考

11-05

一,拿到BI,首先做四件事情rn 1.这个BI产出的业务背景是什么?rn 2.这个BI要帮助什么业务场景实现哪些功能?或者要帮助对应相关的业务处理什么事情?rn 3.这个BI关联到其他哪些模块?这些功能模块如何被设计实现?数据流动是怎样的?rn 4.要准备哪些测试数据去覆盖业务场景?rn rn例如:有个BI卡片写着:“PJK0130-定损平台:导入功能优化:导入失败规则”rn 如果是我去测这个BI,那么就要去了解:rn 首先了解定损平台的业务背景,通过问SA,问业务同事,我们知道,原来定损平台是处理车险客户案件的车辆定损,配件定损,修理厂等等的相关业务;rn 其次,导入功能在做定损业务时,具体实现一个怎样的功能作用?通俗的说就是:导入在这儿干嘛用的?rn 导入功能优化:导入失败规则,和其他哪些模块有关联影响呢?这里我们应该会想到也许会跟规则有关联,那么导入的这些数据从何而来,到哪而去?rn 了解完以上三点之后,我们就开始构想该怎么去测了,这时问题又来了,我该造什么样的数据,在导入的场景中去测呢?rn二,关于测试的思路rn 1. 切记不要偏离业务实际情况,而一头钻进需求文档中,为测系统而测系统。这一点在做性能测试时也尤为重要!在一切事情没有明确之前,测试要敢于rn 质疑需求,BI有时未必是合理的,设计也未必是合理的,要联系实际业务场景去测试系统功能的实现,联系系统上下构造去理解功能模块的设计。rn 谨记:做出来的系统,主要是为业务的一切场景而服务的。rn 测试的宗旨就是:保证系统(产品)质量,让一个拥有高质量高效能的系统去更好的为业务提供服务;rn rn 2. 使用系统时,站在用户的角度思考:用户群体是哪些人?ta们最关心的是什么?rn 分析系统时,站在开发的角度思考:某个功能的实现,如何去设计代码?各个功能模块采用什么机制关联起来?数据库表设计是否严谨?...rn 测试系统时,站在业务的角度思考:我执行这个案例的目的是什么?我操作的业务场景,业务流程正确吗?我准备的测试数据覆盖到业务场景了吗?rn 这些数据的实际输入与预期输出符合业务需求吗?发现的问题跟踪到底了吗?这个BUG产生的原因是什么?最终rn 是如何被解决的?上线前的回归测试覆盖度如何?...rn 3.养成画流程图的习惯:业务流程,前后台交互流程,数据流向图等,画完这些流程图,要了解流程的每一个节点的作用是什么?很多BUG往往就是出现在rn 某一个节点上,因为某个节点运作失败,或者节点作用失效而造成的。知道这些,有助于测试更好的设计测试案例,甚至提前通过rn 后台测试(接口测试,单元测试等)尽早的发现问题;rn 例如:车险理赔系统的任务平台,操作一个查勘任务时,按业务要求完成查勘数据的输入后,点击“发送”,系统正常情况下是返回发送成功的提示。rn 那么问题来了,我在查勘任务页面输入的数据发送到哪里去了?如果系统设置的自动提调规则在查勘这一环节被触发,后台是通过什么机制触发的?rn 触发之后生成的提调任务,是由哪个后台模块处理的?...这一系列的疑问,通过画“业务流程,前后台交互流程,数据流向图” 可以很清晰的理解rn 并在测试时,造准确的数据,设计有效的业务场景;rn rn 4.针对每个需求覆盖的功能点,关联模块,工作流程,有针对性的设计测试案例,评估案例粒度。比如页面元素验证(输入框,字段展示等),功能实现逻辑,rn 工作流程控制及影响点,异常操作(系统容错性)的相应机制; rn rn 5.学会跳出开发的角度评审开发设计文档,以及学会利用后台运行日志定位系统问题; rn三,关于团队沟通rn 1.一个BI,一定要是测试,开发,BA/SA三方理解达成一致的前提下,才启动开发-测试-验收工作。从而避免后期修正的时间成本;rn 2.测试与开发的沟通,主要以暴露问题为主,问题越确切,越有助于开发有效并快速定位问题并解决。暴露的问题不一定都是BUG,rn 也可以是代码逻辑上的疑问。不要抛出类似“某某模块出现BUG了,你看看是什么回事?”,“这里为什么报错了?”,“你的BIrn 大概什么时候可以showcase?”等等类似增加沟通时间成本的问题,我们发现BUG了,第一时间记录下来,重现场景给开发。我们rn 想知道开发什么时候可以showcase,可以直接问他:“这个BI6月10号可以showcase吗?”rn 3.测试有必要第一时间知道系统的任何变动,无论是需求上,设计上的,环境部署的等等变动,测试必须第一时间收到通知。rn 4.对于自己负责的需求一定要多问为什么,背景,目标,设计,实现等,合理设计功能测试案例rn 5.了解需求对生产业务的影响度,性能,效率rn 6.版本发布计划评审以及各需求的首移时间确定:版本计划和版本各BI的首移时间,测试人员是可以提要求的,如果评估移交时间有风险可以提出异议rn 7.版本测试案例设计和评审:及时完成需求和开发设计的理解,并完成测试案例,此环节一定要主动思考,与开发积极互动,不能只做开发的测试执行 论坛

没有更多推荐了,返回首页