• 测试建设原则


    软件测试建设原则,是一个永远说不完的话题,后续会以一个体系的形式更新。     ---Tynam 2021/01/08

    软件测试行业经过快速的发展,至今已经沉淀了许多门类,各式的应用。如果要研发一款产品,那么测试是一项必不可少的工作。从最初的功能测试、到现在的自动化测试、性能测试、安全测试,以及近两年萌芽的大数据测试、机器测试,发展迅速,不同的团队应用的也各尽百色,其中的文档、人员管理方式方法也姿态万千。那么对于不同项目,不同管理的测试安排其中肯定是有必然的联系,遵循着某种原则,这种必然联系到底是什么呢,起止现在也没有一个人真正阐述过。在此,笔者暂且称之为 “whyTest”。何谓 “whyTest”,根据名称不难发现是为什么要这样进行测试。简单的对 “whyTest” 做以下几点解释:

    • 目的:这样进行测试的目的是什么,遇到了什么问题。
    • 解决方案:使用怎么的方案进行解决。
    • 适用场景:在什么情况下适用。
    • 实现方式:以什么样的方式,借助什么工具来实现。
    • 优缺点:这样的实现方式有什么好处,会带来那么影响。
    • 注意事项:需要注意那些内容,是否有依赖存在。

    在上面的几条解释中,不难发现,工程量最大的是在实现方式上,对于实现方式就需要讲究一些行为原则,核心是以最小的成本解决,那么就需要考虑建设、复用、维护等方面的内容。因此在提出解决方案时就需要考虑实现后的独立、拓展、依赖、复用、继承。在此将之称为”测试建设原则“。

    • 独立:指进行的每一项工作看起来都是独立存在的,每一项工作中的细节也都是独立的。例如测试计划,就是单纯的工作安排,不会涉及具体的实现方案。
    • 拓展:易于拓展,扩充。扩充的内容又必须和旧有的内容之前存在弱依赖或零依赖,对原有的或者后来的不造成影响,拥有自己独立的位置。
    • 依赖:弱依赖或零依赖可以使每一项内容都可以独立展开。例如在执行测试用例时候的发现一个Bug,此bug需要和测试用例进行关联,这两者之间便产生了依赖关系。
    • 复用:既有每项工作内部的复用,又有每项工作与每项工作之间的复用。
    • 继承:继承指实现某项工作时先构思出抽象的结构,例如些测试用例,先约定测试用例使用什么工具、有那些组成部分,在实现时必须遵守这些约定,由此生成的测试用例才会整体划一,便于阅读。

    为了便于管理,工作充分开展,把控,可以将测试工作分为横向、纵向进行,如下图。横向表示测试流程,根据时间进行安排。纵向表示横向中每一项具体工作的落实。给定具体任务、固定时间,不要强制怎么实现,最终达到预期结果即可。要充分调动测试人员的积极性,允许在有限的范围内进行自由发挥,每一位测试人员做自己擅长的事情。那么关于有限的范围,这个范围该怎么界定呢?


    其实很简单,就是用户需求。笔者一直提倡,测试人员不是一个测试机器,是具有智慧的,具有思考的测试人员,测试人员做的工作不只是按照产品经理的要求来执行,更多的是考虑用户是怎么想的、怎么使用的。有经验的测试人员都会有这么一个认识,测试计划参照需求分析进行,设计方案参照测试计划,测试设计参照测试方案,测试执行参照测试设计,测试评估参照需求分析、计划、设计、执行。可以看到这样的流程是下一个阶段必然依赖上一个阶段的工作,并且依赖的程度还比较深,假如有一个环节出错,那么后续的工作都会有问题。那么我们返回最初的目的,需要做什么,来源自什么地方?毫无疑问,是用户需求。所以具有思想的测试人员不单是按照产品经理的要求去执行工作,更需要理解用户的需求。因此,测试人员应该是以用户为导向,需求为基础,开展测试工作,建立测试模型。
    由此, 我们就需要对用户的需求的进行分解 ,请注意,在这所说的用户需求是用户最初的要求,想法,而不是产品经理提取出来的。因为产品经理提取出来的需求已经赋予了它一定的第三方想法,甚至参杂了设计方案。回到文章最初所说的WhyTest,将用户的需求进行分解。

    我们可以将用户需求进行分解成解决的问题、在什么场景中适用、怎么解决、拥有什么优缺点。在测试中每一阶段的实现都依赖于需求,不依赖上一阶段的产出。由此各阶段的产物均是独立的,下一个阶段的实施参考上一阶段的产出,但绝对不能是依赖,唯一依赖的是原始需求。意思是上一阶段的产物修改后对下一阶段的内容没有影响,除非需求变更才会影响内容的变更。

    简单的举个示例,计划阶段最主要的产出的计划说明书,计划说明书一般包含的内容有:项目概述、项目的组织形式、测试对象、测试通过和失败的标准、挂起和恢复的标准、测试任务安排、工作量、资源明细。使用 whyTest 对计划阶段进行说明:

    • 目的:从宏观上规划测试活动的范围、方法和资源配置。
    • 解决方案:用文字描述、表格等样式对项目测试进行宏观说明。
    • 适用场景:开发新需求时使用。
    • 实现方式:使用 word工具实现。
    • 优点:word 中编写方便,样式(文字、表格、图片等)可多样展示。
    • 缺点:无版本追踪,团队成员不能同时编辑,成员拿到的版本不能确保是最新的版本。
    • 注意事项:无。 

    参照测试建设原则对各项内容进行分析:

    • 独立原则:计划中的各项内容(项目概述、项目的组织形式、测试对象、测试通过和失败的标准、挂起和恢复的标准、测试任务安排、工作量、资源明细)互不干扰,独立存在。
    • 拓展原则:易于扩展,例如添加测试类型(功能测试、性能测试、API测试),则对其他的内容没有任何影响,只需要在内容中再添加一项测试类型。
    • 依赖原则:计划说明书中的内容互相依赖性低,甚至零依赖。但也存在强依赖,例如测试对象强依赖需求,项目的组织形式强依赖公司项目的组织架构,要知道,拥有强依赖的,一般都是不会变动的。
    • 继承原则:先定义好测试计划书的实现内容,例如本次需要实现项目概述、项目的组织形式、测试对象、测试通过和失败的标准、挂起和恢复的标准、测试任务安排、工作量、资源明细的内容。那么以后每次需求开发,都需要实现这些内容。在此可以简单的理解为模板。

    总结
    在测试阶段中,每一阶段的实现都可以根据 “whyTest” 进行,目的、解决方案、实现方式、优缺点、注意事项。每一阶段中的内容实现,都可根据测试建设原则进行实施。测试建设原则是独立原则、依赖原则、复用原则、继承原则。实现过程中可以参考上一阶段的产物,但是不能依赖。如果需要依赖,依赖对象应该是不容易变更的对象。

    文章最初发布在测试窝:测试建设原则 (testwo.com)

  • 相关阅读:
    <Ajax> 四. get请求(验证用户名是否存在)
    <Ajax> 三. 前端和后端通过表单数据交互
    <Ajax> 一. PHP基本使用和基本数据类型
    <Ajax> 二. PHP选择语句和循环语句
    <Bootstrap> 学习笔记八. 导航栏和颁
    <Bootstrap> 学习笔记七. 下拉菜单和标签页
    <Bootstrap> 学习笔记六. 栅格系统使用案例
    <Bootstrap> 学习笔记五. 按钮组的使用
    <Bootstrap> 学习笔记三. 浮动的使用
    <Bootstrap> 学习笔记四. 表单组和输入框组的使用
  • 原文地址:https://www.cnblogs.com/tynam/p/14251497.html
Copyright © 2020-2023  润新知