软件测试之测试策略

文章讨论了测试策略在敏捷开发环境中的重要性和变化。测试策略关注衡量标准和测试方法,但在敏捷迭代中,由于时间限制和需求的明确化,某些传统策略变得不再必要。然而,识别测试难点和风险仍然是核心。在敏捷测试中,仍需要针对关键特性和基础能力迭代制定简化的测试策略,目标导向,识别风险,并解决测试难点。
摘要由CSDN通过智能技术生成

 

转载文章链接:百度安全验证

转载文章正文:

您有多久没有听说过测试策略这个词了? 这就像一个迷路的孩子,在敏捷趋势的快速迭代中慢慢迷失。 曾几何时,测试策略是测试活动的重要组成部分,它指导着整个测试活动的发展,是高级测试人员必备的技能。 今天,让我们来谈谈这个被忽视的测试技能。

  一.什么是测试策略

  维基百科有很大一部分是关于测试策略的定义,所以我不会在这里发布它们。 总之,测试策略主要关注两个问题:

  衡量什么:衡量什么是指质量需求是什么,质量需要关注哪些方面,比如应用程序的功能范围、性能、安全性、易用性等非功能性需求。

  如何测试:如何测试是用方法来帮助系统达到质量要求,不仅是手动和自动化的测试方法,还包括所有为质量保证服务的过程、环境、基础设施和人员。

  设计测试策略的目标是“减少缺陷的发生和释放”。 其中,“减少缺陷的出现”可以通过测试转发等方法解决,在软件需求分析和架构设计过程中发现缺陷; “减少缺陷发布”可以使用各种测试方法和技术来验证和测试编码功能的完成情况。

  二. 传统测试活动中的测试策略设计

  在传统的测试活动中,测试策略一般是在项目目标明确之后设计的。 整个测试策略将包括但不限于以下几个方面:

  测试的对象和范围是什么(测试什么,不测试什么)

  · 测试目标是什么(为了使产品完全符合商业化标准,或者小范围应用等)

  · 测试的重点和难点是什么(测试难点在哪里,需要什么样的支持)

  如何安排各种测试活动(先测试什么、测试什么、什么时候集成测试等)

  · 资源投入(测试持续时间、人员配备、环境等)

  三、为什么逐渐被忽视

  看完上面的介绍,大概能猜到为什么会逐渐忽略测试策略。 我个人的看法如下:

  - 没有时间了

  在敏捷开发的环境下,每次迭代的测试时间都比传统版本少,我们没有时间写这么重的文档,这似乎与敏捷哲学背道而驰。

  - 测试内容清晰

  在一个迭代周期中,通过需求的实例化,让每次迭代测试的内容更加清晰,更加集中,所以很多原来的内容都不再需要了。 如下:

  测试的对象和范围是什么(测试什么,不测试什么)

  · 测试目标是什么(为了使产品完全符合商业化标准,或者小范围应用等)

  · 测试的重点和难点是什么(测试难点在哪里,需要什么样的支持)

  如何安排各种测试活动(先测试什么、测试什么、什么时候集成测试等)

  · 资源投入(测试持续时间、人员配备、环境等)

  - 测试惯性效应

  与传统测试不同,敏捷测试始终在进行,并不断得到反馈。 所以不需要像传统测试那样在项目开始的时候就初始化一个环境(它会一直存在),不需要关心测试持续时间(每次迭代相对固定),对各种测试不再敏感 活动(基本上总是在做集成测试)。 所以由于敏捷测试的连贯性,部分测试策略不再需要关注,如下:

  测试的对象和范围是什么(测试什么,不测试什么)

  · 测试目标是什么(为了使产品完全符合商业化标准,或者小范围应用等)

  · 测试的重点和难点是什么(测试难点在哪里,需要什么样的支持)

  如何安排各种测试活动(先测试什么、测试什么、什么时候集成测试等)

  · 资源投入(测试持续时间、人员配备、环境等)

  那么,还剩下什么? 个人觉得剩下的才是测试策略的核心:测试的难点在哪里? 如何识别并给出解决方案。

  四. 敏捷测试中是否需要测试策略?

  要先下结论,我们还是要下结论。 但并非每次迭代都是必需的。 在一些核心特性的迭代和一些基础能力的迭代中,我们仍然需要停下来思考如何开发出更有效的测试方法。 我们需要提前为这次迭代做准备。 测试活动做什么。 同时,这个测试策略不能太长,最好在一页以内,以保证所有团队成员随时都能看到这个策略,并得到团队的整体认可。

  个人经验总结如下,(希望得到更多建议)

  目标导向:本次迭代的内容是否完全推送给用户? 用户会在哪些场景下使用这些功能? 客户最关心的指标是什么? 可用性,还是稳定性? 这些都需要在迭代计划开始之前进行沟通和沟通。 确认清楚。 除了对卡片的明确要求外,是否有任何隐含的要求,例如合规性、安全性、性能、可靠性等。

  识别风险:测试过程中可能存在哪些风险? 在需求端,风险主要来自需求的优先级排序,以及团队对需求的理解是否到位。 在研发设计阶段,有几个共同的风险:是否在研发中引入新技术? 前后端人员能不能配合到位? 有外部依赖吗? 对旧功能会有什么影响等。测试团队本身的风险,比如人员变动、测试能力不足等都是常见的。

  如何应对这些风险? 常见的思路有四种:规避风险、转移风险、降低风险和接受风险。 具体内容不做赘述。 需要结合项目和团队的具体情况。 风险缓解是最常见的解决方案。

  测试难点:测试当前迭代或项目的难点是什么? 需要提前准备一些相关数据吗? 是不是需要自己搭建一个项目来验证(我带的团队经常需要测试一些低级项目,比如SDK,比如网关组件),比如一些数据统计项目等)? 当测试团队遇到问题时,如何帮助他们解决这些问题。

  五.总结

  在继续之前三思而后行。 在敏捷环境中,虽然我们不再需要庞大而全面的测试策略文档,但我们仍然需要在迭代开始之前仔细思考如何开发出更有效的测试方法。 我们需要提前为这次迭代做准备。 测试活动怎么做,将指导我们更好地开展测试活动。 与其在接到测试任务后开始测试,而是在遇到问题后,开始思考如何处理。

 

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值