软件测试难点在哪方面？干货分享

V字型模型

既然不能这样干了,过了若干年,聪明的码农们又进一步改进了.上面那个流程, 这次改成了这样的一个V字型的流程,俗称V字型模型:

不过, W模型只是看起来很美,但它其实并不完美。因为不管是W模型也好, V模型也罢,它们都把整个研发过程视为需求、设计、编码、测试等一系列串行的活动 ,无法支持快速迭代的研发需求及变更调整。而恰好这也是我们现在互联 产品的常态, 996短平快,是国内互联 产品的主流旋律,市场竞争如此激烈,没有哪个用户会等着你慢慢研发出来。

举个例子,遇到需要根据市场及监管要求,快速调整项目需求时,比如今年这个疫情, ZF紧急要求上线全国人民都要使用的健康码监管系统,这种系统按照常规完整开发没个半年是搞不定的,但我们在短短一周内就上线使用,速度之快难以想象。这种时候如果按照W模型或V模型的串行做法,不仅无法快速响应,还会影响整个软件的质量,肯定是无法满足要求的。

迭代模型

终于到我们的迭代模型登场了,这过是现在主流的研发模型。所谓迭代,就是指将整个系统需求拆分成多个不同的小部分, -次只完成其中的一部分。这种开发方式的特点是小步快跑,增量实现,风险可控。所以,这种模式还有一个名称叫敏捷开发模式(Agile development)。PS :我觉得发明这些词的人真他娘的是个天才,太形象了。

在这种研发模式下,我们会将大型项目拆分为多个迭代,每个迭代本质上是一个小项目,每个项目都包含了需求分析、设计、编码、测试等系列项目活动。 由于它是增量的,所以它要求我们先完成部分系统功能或业务逻辑,然后依据客户反馈来进一步明确需求 ,最后通过一次次的迭代来给用户交付达标的产品。

比如,我们在实现- -个大产品时, 会先实现- -个最小可用版本( MVP , Minimum ViableProduct) , 然后等用户在使用过程中收集反馈,在后面的迭代中就能及时调整。

Devops

最近几年业界流行的所谓Devops (开发运维)其实就是开发、质量保证人员、运维三个角色的交集。Devops旨在通过自动化的“软件交付”和“架构变更”的流程,来解决不同角色之间合作的流畅度,以及把软件交付的构建、测试、发布变得更加快捷、频繁和可靠,充分适应现代互联 产品短频快的特点。

还有,相较于传统单体应用,微服务的测试也更加复杂。仅从代码打包部署这件事儿来说,在单体应用里,不太会出现使用错测试包的情况,但是在微服务里,这个情况可能会发生。

单体应用,一个版本就对应一一个代码分支;而使用微服务，每 个微服务通常对应不同的代码分支。这就意味着在测试微服务时,测试不仅要关注你测试的微服务是否版本部署正确,还要检查其依赖的其他微服务的部署分支,查看其他微服务的分支是不是也部署正确。

除此之外,微服务的采用,也让我们的技术栈更为繁多、复杂,比如:

以上”新”技术的引入,是为了不断应对软件开发演变中带来的各项需求和问题,解决了旧问题的同时,也为测试带来了新挑战,例如:

微服务独立部署、独立发布,那么微服务下的测试还能保持一-成不变吗 据库举例,分库分表怎么来的么测试r> 由于某些特殊情况(比如电商中的商品秒杀)而导致服务雪崩,微服务会引发熔断、降级、限流等一系列保护措施,要怎么保证这些措施被正确实施了r> 持续集成,持续部署流水线建立了，以往的测试框架如何最小成本嵌入变成流水线的一环r> 面对这些挑战,软件测试在快速演进的同时,也在裹挟前行,寻找破局之道。那么这个破局之道是什么呢p>

答案就是测试开发I程师。

正如前文所述,软件的发布动作变得越来越频繁,以往靠大手工功能测试+少主流程自动化测试+部分回归测试来保障质量的做法,变得越来越不现实。自动化测试,特别是不同层次的自动化测试在整个测试活动中的占比,正逐渐成为影响软件发布质量的关键。这也就是测试开发在近年来越来越受追捧的原因。

这么多的自动化测试用例,需不需要维护维护将自动化测试融入公司的持续集成流程中并自动触发运行都是测试开发首要关注的问题,可以预料的是,随着交付频率的加快,测试开发会变成软件测试人员的基本技能。

所以,为什么我们一开始就说现在传统的点点点工程师已经没有出路,测试开发I程师才有未来,就是这个原因。