测试策略实践之分类漫谈

对于软件测试策略的分类,有多种类型的分类,比如根据软件系统的类型进行分类(比如基于 Web 软件系统,B/C软件系统,移动软件系统,嵌入式软件系统等);或者根据测试类型进行分类(比如端到端测试,性能测试,安全测试,模糊测试、兼容性测试、功能性测试等);或者是根据软件的架构进行分类(比如基于 SOA 架构的传统企业系统,基于 MicroService 架构的互联网系统,基于 Severless 架构的物联网系统等)等。而我将从组织架构和交付方式的角度来对测试策略来进行分类,并一共把测试策略分为四种类型,手工作坊式低质量要求的轻量测试类型,集团式高质量要求的全测试型,特战队式内建质量要求的敏捷(精益)测试类型和流水线式持续交付的全自动化测试类型。

更多学习资料:Jmeter+ant+jenkins接口层性能与自动化测试--软件测试视频教程-研发管理-CSDN程序员研修院


更多学习资料:JMETER 性能测试入门到项目实战视频课程--软件测试视频教程-研发管理-CSDN程序员研修院


linux 从入门到项目实战课程--Linux视频教程-系统运维-CSDN程序员研修院

第一种:手工作坊式低质量要求的轻量测试类型

对于很多创业团队或者小型软件公司,他们的第一目标就是快速交付产品给客户或者用户,所以其核心就是快速开发。但他们在测试方面的投入往往都很少,比如一个 10 人的团队或许只有 1 个测试人员进行测试,或许没有,所以测试工作会由开发或者管理人员分担一部分。对于这样的团队,测试资源少或者缺乏专业测试人员,其测试策略主要包括:

在这样资源有限的团队中,这样的测试策略能最大可能的在持续开发和交付流程中保证其主要功能不会有大的问题。

第二种:集团式高质量要求的全测试型

大部分的成功的传统软件公司都在使用这样测试类型,比如以前的微软(大家是不是已经发现了 Win10 的问题比 Win7 多了不少?因为微软在 2015 年进行转型而裁掉了大量的测试人员),Intel,国内几个通信软件厂商,各大银行以及 NASA 等。由于这些大型软件厂商所开发的软件是需要部署到客户方进行使用或者是服务于核心金融类以及航天类等特种行业,其对于质量的要求十分苛刻。一旦出现问题,对于客户方部署的系统进行问题调查或者进行升级都需要大量的成本,甚至有些产品不能升级。而如果金融或者航天等这些特种行业的软件系统出了问题,那么直接带来的就是金钱的损失或者是不可扭转的错误。所以它们追求的是无缺陷的全测试,其测试策略主要包括:

更多学习资料:Jmeter+ant+jenkins接口层性能与自动化测试--软件测试视频教程-研发管理-CSDN程序员研修院


更多学习资料:JMETER 性能测试入门到项目实战视频课程--软件测试视频教程-研发管理-CSDN程序员研修院


linux 从入门到项目实战课程--Linux视频教程-系统运维-CSDN程序员研修院

由于这样的测试策略带来的测试成本十分巨大,所以一般只有资源十分丰富的公司才能实施。

第三种:特战队式内建质量要求的敏捷(精益)测试类型

当前其实大部分中型软件企业既不满足于轻量测试,也无法投入足够的资源来进行全测试,所以一般都会自己定义介于这两者之间的测试。由于敏捷(精益)开发方式的出现和普及,敏捷(精益)测试也自然的出现了。它只是介于第一种和第二种之间的众多定制化测试策略的一种,但是它充分使用到敏捷(精益)的价值观和方法论,使得其得到很多互联网公司的青睐,比如 Google,Atlassian 以及 AWS 等,都是敏捷(精益)测试实施非常好的公司。因为他们的测试开发比都很低,产品规模大了以后依然保持这较高的发布速度和较好的产品质量。虽然上线之后产品会出现一定的问题,但是也能在短时间修复之后并重新部署(这个是因为他们的主要产品都是基于服务器,能自己完全控制升级的时机和方法),所以对于风险是可控的,并且对于测试的投资回报比是相对最高的。其中《Google 软件测试之道》

第四种:流水线式持续交付的全自动化测试类型

梦想中的持续交付和全自动化测试是当软件工程师提交一个代码修改之后,在不需要人工介入或者很少介入的情况下完成自动编译,自动测试并自动部署到产品环境。这个是当前许多软件开发者和管理层的梦想。但是由于各种限制,自动化测试系统不够稳定,测试数据无法自动获得和产生(我在多个项目上都遇到过这个问题,而且由于各种原因导致最终都没有解决),自动化测试开发成本高等,导致全自动持续交付成为绝大部分企业几乎是一个无法企及的目标(只有少量的国外企业号称自己做到了全自动化持续交付),最终导致当前所谓的持续交付也需要大量的人工介入。所以为了向梦想中未来的持续交付和全自动化测试迈进,必须对于当前的测试策略进行调整

对于这四种类型的测试策略,对于某个团队来讲并不是谁一定比谁更好,因为每个团队开发软件的目标不一样,所以只有谁更适合。如果团队的目的是快速交付一个产品,那么第一种和第三种更适合,或者自定义一种介于第一种和第二种之间的测试策略;而如果产品已经十分成功,而且软件的质量对于团队重于泰山,那么第二种类型更适合;或者产品不仅已经十分成功,而且团队对于软件交付速度和质量都有着更高的追求,那么团队就需要向着持续交付式的全自动化测试类型不断前进。

更多学习资料:Jmeter+ant+jenkins接口层性能与自动化测试--软件测试视频教程-研发管理-CSDN程序员研修院


更多学习资料:JMETER 性能测试入门到项目实战视频课程--软件测试视频教程-研发管理-CSDN程序员研修院


linux 从入门到项目实战课程--Linux视频教程-系统运维-CSDN程序员研修院

  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

传说三哥

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值