幽映每白日,清辉照衣裳。这篇文章主要讲述测试点先发散后收敛思考相关的知识,希望能为你提供帮助。
前言
测试是无穷无尽的,100%测试不可能的。众所周知,随着技术日新月异的发展,当前软件系统越来越庞大,越来越复杂。一个软件系统可能由各种各样中组件组成,这些组件可能分布在系统的各个地方,在系统中所处的地位也可能是有所不同的。与此同时,当前互联网好多公司的核心业务代码比较老旧,缺乏相关文档与架构去了解学习,即使核心业务代码有问题只要不影响核心业务,也不会做相关变动。开发在基于这样的系统,在后续不断的迭代,丢失文档化可能越来越严重,这就可能造成相关的系统架构设计及业务,可能只在相关人员的脑子中情况。一旦相关人员从当前岗位离职,那这些系统的可测试性就很差、测试难度及风险就很大。
对于系统庞大、可测试差的系统,要如何进行测试分析呢?面对这样的系统如何着手分析呢?
被测系统特点 每个被测项目都是独一无二的。因此基于同一流程去进行测试,虽然可能完成相关测试,但是测试效果、测试人员、测试开发人员的体验肯定是不一样的,因此基于项目的独特性,应该重新调整测试流程,改善流程来整合项目资源。
新开发系统
- 如果流程规范,会在开发相关阶段遗留对应文档,如产品规格书面书、系统详细设计、系统概要设计等,这些文档对于项目维护及后续介入人员了解项目是有很大的好处的。
- 如果缺乏过程文档,当相关人员了解产品业务、设计与实现,这也能帮助后续人员学习。但这种会有一种风险,一旦人员流失严重,该系统就会成为一个“雷区”。
基于上述两个原因,新开发系统会有以下特点: - 文档完备,便于后期维护、后续人员介入学习了解系统。
- 人员完备,文档有一定缺失,这种情况会有老带新,学习效率高,但会出现人员流失风险,不利于团队知识积累。但不影响当前人员对系统分析。
- 早期介入人员流失严重、文档缺失,这种情况测试学习成本高、风险比较大,系统不易维护。
- 定期维护,产品相关资料齐全。
- 年久失修,文档缺失或者文档描述和系统实现脱离严重。
- 重新梳理老系统设计实现并规范开发阶段,对关键流程文档化。
- 重新梳理老系统设计实现但在相关人员脑子里不留存,后续开发实现也不文档化,延用老系统恶习。
- 关键文档定期维护,项目知识保留完整
- 关键文档缺失或者年久失修,项目知识遗失严重。
基于对业务、系统的深层次了解之后,会发散出很多测试点。这些测试点可能包括安全测试、兼容性测试、性能测试、功能测试、易用性测试、UI测试等方面,这些测试点会很全面、也很多。关于测试点的发散,常用的发散方法有:等价类、边界值、错误推测、同类别功能类比、基于经验推测等方法。关于如何发散测试点,这里没法展开,因为不同人的测试思维是不一样的、每个人思维都是独特的,俗话说“众人拾柴火焰高”,所以整个团队在一起进行头脑风暴,效果是最好的,单个人会产生一定的思维壁垒,产生思维盲区,导致测试点的遗漏。因此测试点发散最好是整个项目全员参与,一起发现产品业务、系统设计、测试设计等各方面的缺陷。
由测试人员整合项目其他成员的测试点,汇总成一个大而全的测试点,安排相关方一起评审该测试点。评审该测试点的主要目的是:
- 确保测试点的全面性有无遗漏。
- 基于项目发布周期,确定本次发布周期要进行测试点,与相关方达成共识,实现风险均摊。
- 确定本期测试点之后,哪些测试点要划入下一期。
- 测试点影响大小。如果不测试该点,会产生什么影响,这些影响有多大,产生这种影响如何规避?
- 测试点优先级。不同的发布周期呢,对系统在不同周期内,测试侧重点不同,会删减不必要的测试点?
- 被测组件在系统架构中的地位。测试组件对系统架构的整体影响,会影响测试资源的倾斜及资源分配情况。如果被测组件影响整个系统,该组件的测试点会被要求全部执行。
测试点先发散后收敛,这个好处主要是“全面撒网、重点捕鱼、风险均摊、测试高效”。测试点先发散是为了确保思考的全面性,通过不同人员不同视角来获取对测试系统的不同方面的关注点,收集这些关注点,构化系统热点图。测试点收敛是为了针对性测试,针对系统测试热点,选取核心测试点,进行测试精准打击,缩小测试范围、重点突击容易出问题的功能,与相关人员就选取测试点,达成一致意见,风险均摊。
?
【测试点先发散后收敛思考】
推荐阅读
- PL/SQL字符串声明字符串函数和操作符实例源码说明
- Jmeter操作oracle简单示例
- Dockerpyresttest的dockerfile调整,增加时区
- u-boot启动流程详解-基于iTop4412开发板
- ORACLE 12的ORA-01033问题操作过程
- Keras 的深度学习模型中的 Dropout 正则化
- 论软件测试人员的自我修养
- Jmeter操作oracle
- String转map