【业务测试】

业务测试疑问:

你觉得业务测试就是点点点吗?

你觉得业务测试就是依据需求设计case并全部执行通过就OK了吗?

你觉得业务测试就是功能测试+兼容测试+性能测试+接口测试+自动化吗?

你觉得业务测试中的“业务”就是一个个的需求吗?

你觉得业务测试中的“测试”就是对研发提测内容的质量保证吗?

现在行业里流行测试左移和右移的说法:

左移,业务流,成长方向:让执行的事情变少,并拿到等价甚至更好的成果;

右移,技术流,成长方向:通过技术的手段让事儿做得更快,支持更多并行,减少变更成本;

image.png

在我看来,左移和右移,不是互斥的。如果把一个项目的生命周期定义为:需求调研和整理、需求评审、技术设计、需求研发(测试分析)、需求测试、业务验收、上线跟进、工具沉淀。那么左移和右移的起点,是在何处?我的工作习惯里,这个起点在“需求评审”。左移,是为了尽我所能的确保需求的合理性、可行性、业务逻辑的严谨性、页面和交互设计的合理性、技术设计的正确性;右移,是为了确保测试内容的高覆盖度、测试手段的灵活、测试执行的高效率、测试工具的持续优化,测试平台的不断完善。两者的终极目的,都是为了质量和效率服务的,但侧重点却截然不同。左移,更多的是为质量服务,并且是将质量的含义从软件质量扩展到产品质量,将质量保证从测试执行提前至对产品方案和技术方案的审视,与此同时,少走弯路的结果也就间接的提高了效率。右移,更多的是为效率服务,通过创新的测试方法、灵活的测试手段,多样的测试工具、完善的测试平台,提高测试效率,当然,右移中的并发、性能、兼容、内存泄露等专项测试,又进一步加强了质量保证。

测试左移方向:

今天,我们重点说说“左移”。很多时候,上文提到的“需求的合理性、可行性、业务逻辑的严谨性、页面和交互设计的合理性、技术设计的正确性”会让人觉得是在喊口号,一个小小的qa怎么会有这样的判断能力呢?其实不然。

业务研发、业务测试都是为“业务”的迭代服务的,而“业务”的迭代必然指向一个目标,一个目标往往又指向一个背景,这个背景也许是一个用户痛点、痒点、爽点(C端、B端、平台自己人),然后业务方基于这些提出了诉求,接着产品设计了方案,然后拿到了技术这里,一次“业务迭代”里的一个需求就出现了。绝大多数情况,业务测试会在接下来的需求评审会与这个需求相遇、相知,然后相守。

基于对需求背景的了解、理解,我们可以初步判断,业务方所认为的用户痛点、痒点、爽点是否合理且正确?产品给出的解决方案,是否能满足业务方的诉求,是否立足于产品现状,是否会带来其他问题,是否还有更好的解决方案,ROI能否达到预期?这些就是“合理性”的判断;产品给出的解决方案,是否在规定的时间、既定人力、现有的技术储备资源下可实现?这些就是对“可行性”的判断;产品设计的细节,业务逻辑是否严谨、完整,页面和交互设计是否符合用户使用习惯、是否符合平台定位和风格?这些就是对“业务逻辑的严谨性、页面和交互设计的合理性”的判断;数据库设计、实现逻辑设计、接口设计是否满足需求,是否具有较好的扩展性,前后端交互的设计是否符考虑到用户体验和异常场景兼容?这些就是对“技术设计的正确性”的判断。以上这些判断能力,一个优秀的业务测试应该是要具备的。当然,这些能力不是凭空出现的,是行业经验、业务知识积累、产品现状了解、数据库知识、测试思维演化等等一系列的积累和成长后的产物。
为什么我们要测试左移呢?因为发现问题的时间越晚,修复的成本就越高。

image.png

图中橙色线条代表了传统测试发现缺陷的时间,大多数 bug 都是在功能测试和集成测试时发现的,最后导致的结果就是发布前加班加点,祈祷不要有 bug 漏到生产环境。
设想我们把测试活动向左移动,那就意味着修复成本大幅下降。

image.png

那么我们又该如何在具体的项目中,逐渐的了解业务、了解产品现状,快速且深入的左移到项目实施中呢?

整理了一些心得,与大家分享:

1、提前预习:

时间允许的情况下,应在需求评审前完成阅读需求,罗列好需要确认的问题

2、需求评审:

需求评审时,专心参与评审,积极思考在当前业务背景新需求的下可行性、合理性、逻辑严谨性,主动表达自己的疑问和建议,深度参与到评审+脑暴的环节里,对最终敲定良好的产品方案贡献力量,同时也可收获对产品方案的细致了解

3、需求分析:

评审后,如有必要(视需求的复杂度、规模、影响范围而定),进行需求分析和测试用例编写,在此环节,会加深对需求的进一步理解,可能会衍生出新的疑问和建议,积极与pm沟通,同时确保沟通结果同步相关人员、记录至需求文档

4、技术评审:

如果项目有技术评审,相关QA要参加,需要了解技术设计的思路,接口设计、表结构设计、数据流转关系,需要思考设计的合理性,是否满足需求等

5、上线保证:

基于对业务、技术设计等情况的了解,对于上线前准备工作有足够的认识,包括但不限于:DB侧新库新表的建立、表结构的调整、ES中索引的建立、业务基础数据的准备、各模块上线的依赖关系等

6、知识积累:

做好测试用例积累,分模块梳理业务知识并沉淀至wiki,整理sql语句等,测试leader组织周期性知识分享

测试左移的概念给整个测试角色带来了巨大的转变。软件测试不仅仅是 “发现 bug”,而是致力于 “尽可能早的检测和预防 ‘bug’ ”。


 

你可能感兴趣的:(单元测试)