《软件架构师修炼之道》

[TOC]


软件测试工程师的“三年之痒”

软件测试发展简史

1975年《软件数据选择的原理》:证明软件的工作是正确

1979年《软件测试艺术》:发现错误而执行的活动

1983年《软件测试完全指南》:测试是以评价一个程序或者系统属性为目标的任何一种活动,测试是对软件质量的度量

2002年《系统的软件测试》:测试是为了度量和提高被测软件的质量,对测试软件进行工程设计、实施和维护的整个生命周期过程

中国软件测试行业

  • 软件测试整体起点较高

  • 困境和迷局

    • 后备软件测试人员对软件测试不了解

    • 软件管理决策者对软件测试缺乏正确理解

    • 喜忧参半:软件测试外包

  • 迷茫的软件测试工程师

软件测试的优势和劣势

优势

  • 入门相对容易

  • 选择软件测试作为转型的切入点比较合适

  • 测试人员是产品研发团队中最理解产品全貌、最理解用户的人

  • 软件测试更注重广度,可以有更多的职业外延可供选择

  • 更能适应复杂多变的社会

劣势

  • 在软件研发领域的认可度低

  • 在软件研发领域的发展比软件开发人员有限得多


软件测试工程师的职业规划

软件测试的职业发展方向

  • 管理上的发展

    • 测试组长

    • 测试经理、测试代表、测试主管

    • 测试总监、测试部长

  • 技术上的发展

    • 软件测试架构师

    • 专项测试工程师

  • 质量领域的发展

    • 产品流程设计:负责产品开发、市场、交付等全流程体系建设

    • 企业质量管理者

      • 质量管理三部曲:

        • 质量策划:致力于指定质量目标并规定必要的运行过程和相关的资源以实现质量目标

        • 质量控制:致力于满足质量要求

        • 质量改进:致力于增强满足质量要求的能力

      • 质量管理体系方法可以概括如下:

        • 建立一个以过程方法为主题的质量管理体系

        • 明确体系内各过程的相互依赖关系,使其相互协调

        • 控制并协调质量管理体系各过程的运作,关注其中的关键过程,规定关键活动的运作方法或模式

        • 理解为实现共同目标所必需的作用和责任,减少因为职责不明导致的障碍

        • 在行动前确定所需资源的需求

        • 设定系统目标以及各个过程的分目标,通过分目标的实现,确保实现预期的总目标

        • 通过监控和评估,持续改进质量管理体系,不断提高组织的业绩

  • 客户满意度管理专家

    • 重点是要识别关键用户的满意要素和做好与用户接触点相关的质量保证

    • 关键用户满意度要素:通过对细分市场进行市场调查后,分析得出这类客户对特定的产品质量要求和服务属性,并把关键客户满意度要素作为企业产和服务战略的输入,使企业最大限度地保持产品竞争力

    • 用户接触点相关的质量保证:包含客户可以感知到的产品和服务,其中服务包括产品推广、投标达标、供货保障、工程交付、技术支持、备份支持和客户培训

软件测试工程师职业规划建议

  • 不要过早放弃技术,走所谓的纯管理线路,把自己陷入各种管理会议、沟通协调中

  • 对测试工作跳槽的建议:

    • 不要轻易跳槽学会“韬光养晦”

      • 遇到难于解决的问题:理性、慎重

      • 职业发展不能达到预期:如果跳槽可以获得更好的职业发展和更广阔的职业发展舞台,当然要跳槽,不建议做平级之间的跳动

    • 跳槽时除了考虑公司,还要考虑测试产品的持续性:做好软件测试,对测试产品的深入理解是一个重要的先决条件

  • 软件测试创业

    • 软件测试咨询

    • 软件测试高端外包

    • 测试工具开发


软件测试架构师应该做和不该做的事情

软件测试架构师需要关注和不需要关注的事情

测试活动可以概括为:测试需求分析、测试分析和设计、测试执行和测试质量评估

产品测试不应该是产品研发末端的活动,而应该是“端到端”的,在产品研发的开始阶段,测试就需要投入。

测试的意义,不仅在于测试发现bug,为产品发布提供信心,还在于缺陷预防,切实提升产品质量

  • 测试架构师在需求分析中

    • 理解需求

      • 理解产品的商业目标

      • 梳理用户的使用场景

    • 制定一份总体测试策略,来明确测试范围、测试目标、测试重点和难点、测试深度和广度

      • 测试重点:由产品价值、质量目标、产品实现和历史测试情况等多项因素综合决定的

      • 测试难点:从测试技术的角度来说的,是对产品测试验证难易程度的分析

      • 测试深度:从测试方法(单运行测试、多运行测试、边界值或者错误输入)来对测试行为进行描述

      • 测试广度:从覆盖的角度来对产品测试进行描述

      • 对每个特性确定了测试重点和测试难点、测试深度和测试广度之后,测试的总体思路也就随之明确了。后面的自动化策略、探索测试策略、测试分析和设计的策略也变得明确了

      • 测试分层

  • 测试架构师在测试分析和设计中

    • 制定阶段测试策略:按照测试分层来确定每个测试层次的测试策略,出入口准则是确定这一阶段的质量目标和验收标准

    • 落实测试设计策略,保证测试设计的质量

  • 测试架构师在测试执行中

    • 制定版本测试策略

    • 跟踪测试执行

    • 版本质量评估和建立版本质量档案

  • 测试架构师在测试质量评估中:此时的质量评估是指阶段质量评估或者发布时的质量评估,需要给出“能否进入下一阶段的测试”或者“发布”的结论


软件测试架构师的知识能力模型

软件测试架构师需具备的能力:

  • 测试技术

    • 软件产品质量模型:帮助我们理解和确定用户需求,评估质量

    • 测试类型:各个角度对被测对象进行测试,又称为“测试视角”

    • 测试方法

    • 测试设计

    • 探索式测试:一种强调测试人员同时开展测试学习、测试设计、测试执行、并根据测试结果反馈及时优化的测试方法

    • 自动化测试

  • 产品知识

  • 沟通协调

  • 书面表达

软件产品质量模型

软件产品质量六属性

  • 功能性:满足明确和隐含要求的功能的能力

    • 适合性

    • 准确性

    • 互操作性

    • 安全性

    • 功能顺从性

  • 可靠性:软件产品维持规定的性能级别的能力

    • 成熟性

    • 容错性

    • 可恢复性

    • 可靠性顺从性

  • 易用性:产品被用户理解、学习、使用和吸引用户的能力

    • 易理解性

    • 易学性

    • 易操作性

    • 吸引性

    • 易用性的依从性

  • 效率:相对于所用资源数量,可提供适当的性能的能力

    • 时间特性

    • 资源利用率

    • 效率依从性

  • 可维护性:产品可被修改的能力

    • 可分析性

    • 可修改性

    • 稳定性

    • 可测试性

    • 可维护性的依从性

  • 可移植性:软件产品从一个环境迁移到另一个环境的能力

    • 适应性

    • 可安装性

    • 共存性

    • 易替换性

    • 可移植性依从性

测试类型

  • 功能测试

  • 安全性测试

  • 兼容性测试

  • 配置测试

  • 可靠性测试

  • 易用性测试

  • 性能测试

  • 安全测试

测试方法

  • 产品测试车轮图:一个软件测试工程师要从哪些方面(测试类型)用哪些方法(测试方法)去测试产品(质量属性)的关系图

    • 如何保证测试验证的全面性:能够覆盖六大质量属性,就不会出现大方向性的遗漏

    • 如何确定测试深度问题:测试方法越多,对产品就测试得越深

  • 功能测试方法

    • 单运行正常值输入法

    • 单运行边界值输入法

    • 多运行顺序执行法

    • 多运行相互作用法

  • 可靠性测试方法

    • 异常值输入法

    • 故障植入法

    • 稳定性测试法

      • 多:增加用户对功能的操作数量

      • 并:让多个用户同时操作这个功能

      • 复:让一个或多个用户,反复操作部分功能

      • 异:让一个或多个用户,反复进行异常操作

    • 压力测试法:在一段时间内持续使用超过系统规格的负载进行测试(突发形态的负载模型)

    • 恢复测试法

  • 性能测试方法

    • 测出系统最好的性能值

      • 能够正常处理新业务的最大能力

      • 能够同时正确处理的最大业务能力

    • 分析会影响性能值得各种因素,测试它们对性能的影响

    • 以场景为单位来测试性能

  • 易用性测试法

    • 一致性测试法

    • 可用性测试法

测试设计技术

测试点=测试用例 ?

测试用例实在测试点“加工”的基础上得到的。首先把测试点去重,合并、细化,然后再确定各个测试点的测试条件、测试数据和输出结果

使用各种测试方法对被测对象进行分析得出测试点(测试分析:发现性的过程),把测试点加工为测试用例,叫测试设计

场景测试设计方法:路径分析法、判定表、正交分析法、等价类、边界值

四步测试设计法

  • 建模:

    • 流程类:流程图

    • 参数类:输入输出表

    • 数据类:等价类分析表

    • 组合类:因子表

  • 设计基础测试用例

  • 补充测试数据

  • 扩展

对测试点进行分类

流程类测试点特征:拥有流程方面的特征

参数类测试点特征:

  • 参数值 个数是有限的

  • 系统会对不同的参数值作出不同的处理或响应

数据类测试点特征:

  • 数据的取值是一个范围

  • 系统对运行输入的数据作出的处理或响应往往是一样的

组合类测试点特征:测试点可以组合

流程类测试设计:路径分析法

路径分析法:对能够覆盖流程的各个路径进行分析,得到一个路径的集合

常见的覆盖策略:

  • 语句覆盖

  • 分支覆盖

  • 全覆盖

  • 最小线性无关覆盖:保证流程图中每个路径片段能够被至少执行一次

参数类测试设计:输入输出表分析法

输入输出表示一张分析测试点在某种条件下,特定的输入会有怎么输出的表

数据类测试设计:等价类和边界值分析法

等价类:指对输入值按照测试效果进行划分,将测试效果相同的测试数据归为一类,然后在测试时只需要在每类中选择一些测试样本进行测试,而无须测试所有的值

边界值:是参数在输入边界上的取值

组合类测试设计:正交分析法

  • 使用因子表建模:因子表是一张分析测试点需要考虑哪些方面,并且这些方面需要包括哪些内容的表

  • 使用PICT工具来生成测试用例:针对pairwise testing实现的测试用例设计工具

控制用例粒度:测试点的组合和拆分

  • 控制用例粒度

    • 希望整个团队的测试用例总数维持在一个比较合理的范围内,同时很好的达到测试验证产品的效果:控制测试用例源头:测试点

    • 不同的用例粒度,可能会发现产品不同层次的问题,所以需要在不同的测试阶段,对测试点进行一些拆分和组合,以求可以从不同的层次去测试产品,发现问题

  • 策略覆盖

    • 将一些因子或者数据的取值,分配到其他测试用例中

    • 内容重要性:根据内容的重要性来改变粒度

    • 测试执行便利性:将和这个测试用例有关的因子或数据分配到一起

错误推断法

错误推断法:测试者根据经验来判断产品在那些地方容易出问题,针对这些地方来设计测试用例的方法

探索式测试

一种强调测试人员同时开展测试学习、测试设计、测试执行,并根据测试结果反馈及时优化的测试方法

探索性测试的基本思想:CPIE

  • Collection:收集所有关于测试对象的信息并去理解这些信息

  • Prioritization:对所有需要测试的任务进行优先级的划分

  • Investigation:对测试的任务进行仔细分析,预测可能输出的结果

  • Experimentation:进行测试实验,确认测试结果和预期是否符合

探索性测试方法

坚持原创技术分享,您的支持将鼓励我继续创作!.