软件测试建设原则,是一个永远说不完的话题,后续会以一个体系的形式更新。 ---Tynam 2021/01/08
软件测试行业经过快速的发展,至今已经沉淀了许多门类,各式的应用。如果要研发一款产品,那么测试是一项必不可少的工作。从最初的功能测试、到现在的自动化测试、性能测试、安全测试,以及近两年萌芽的大数据测试、机器测试,发展迅速,不同的团队应用的也各尽百色,其中的文档、人员管理方式方法也姿态万千。那么对于不同项目,不同管理的测试安排其中肯定是有必然的联系,遵循着某种原则,这种必然联系到底是什么呢,起止现在也没有一个人真正阐述过。在此,笔者暂且称之为 “whyTest”。何谓 “whyTest”,根据名称不难发现是为什么要这样进行测试。简单的对 “whyTest” 做以下几点解释:
在上面的几条解释中,不难发现,工程量最大的是在实现方式上,对于实现方式就需要讲究一些行为原则,核心是以最小的成本解决,那么就需要考虑建设、复用、维护等方面的内容。因此在提出解决方案时就需要考虑实现后的独立、拓展、依赖、复用、继承。在此将之称为”测试建设原则“。
为了便于管理,工作充分开展,把控,可以将测试工作分为横向、纵向进行,如下图。横向表示测试流程,根据时间进行安排。纵向表示横向中每一项具体工作的落实。给定具体任务、固定时间,不要强制怎么实现,最终达到预期结果即可。要充分调动测试人员的积极性,允许在有限的范围内进行自由发挥,每一位测试人员做自己擅长的事情。那么关于有限的范围,这个范围该怎么界定呢?
其实很简单,就是用户需求。笔者一直提倡,测试人员不是一个测试机器,是具有智慧的,具有思考的测试人员,测试人员做的工作不只是按照产品经理的要求来执行,更多的是考虑用户是怎么想的、怎么使用的。有经验的测试人员都会有这么一个认识,测试计划参照需求分析进行,设计方案参照测试计划,测试设计参照测试方案,测试执行参照测试设计,测试评估参照需求分析、计划、设计、执行。可以看到这样的流程是下一个阶段必然依赖上一个阶段的工作,并且依赖的程度还比较深,假如有一个环节出错,那么后续的工作都会有问题。那么我们返回最初的目的,需要做什么,来源自什么地方?毫无疑问,是用户需求。所以具有思想的测试人员不单是按照产品经理的要求去执行工作,更需要理解用户的需求。因此,测试人员应该是以用户为导向,需求为基础,开展测试工作,建立测试模型。
由此, 我们就需要对用户的需求的进行分解 ,请注意,在这所说的用户需求是用户最初的要求,想法,而不是产品经理提取出来的。因为产品经理提取出来的需求已经赋予了它一定的第三方想法,甚至参杂了设计方案。回到文章最初所说的WhyTest,将用户的需求进行分解。
我们可以将用户需求进行分解成解决的问题、在什么场景中适用、怎么解决、拥有什么优缺点。在测试中每一阶段的实现都依赖于需求,不依赖上一阶段的产出。由此各阶段的产物均是独立的,下一个阶段的实施参考上一阶段的产出,但绝对不能是依赖,唯一依赖的是原始需求。意思是上一阶段的产物修改后对下一阶段的内容没有影响,除非需求变更才会影响内容的变更。
简单的举个示例,计划阶段最主要的产出的计划说明书,计划说明书一般包含的内容有:项目概述、项目的组织形式、测试对象、测试通过和失败的标准、挂起和恢复的标准、测试任务安排、工作量、资源明细。使用 whyTest 对计划阶段进行说明:
参照测试建设原则对各项内容进行分析:
总结
在测试阶段中,每一阶段的实现都可以根据 “whyTest” 进行,目的、解决方案、实现方式、优缺点、注意事项。每一阶段中的内容实现,都可根据测试建设原则进行实施。测试建设原则是独立原则、依赖原则、复用原则、继承原则。实现过程中可以参考上一阶段的产物,但是不能依赖。如果需要依赖,依赖对象应该是不容易变更的对象。
文章最初发布在测试窝:测试建设原则 (testwo.com)