需求评审&SPEC评审&用例评审&归档用例

本文部分内容借鉴于博客需求评审的关注点

需求评审、SPEC评审

1、评审前期准备

评审是要在写代码前发现问题,不要吝啬将时间花在前期上,因为这会大大减少我们中后期的意外,避免做很多的无用功。在评审之前,我们要仔细阅读相关的评审资料,了解每个点是干什么的。

2、评审中需要关注的点

(1)文笔

描述是否存在错别字,特别是界面上的文案。例如,登陆->登录

描述是否清楚,是否存在歧义

没有统一术语,多处地方用不同词语来表示同一概念

是否杂乱无章,不便于阅读和查找信息

(2)逻辑性

流程的出入口:是否明确,是否过多(连用户都会昏头转向)

条件与规则说明是否清晰明了

缺少说明数据的来源、类型、精度、取值范围、默认值、显示格式、计算处理方式

是否考虑其它功能或需求的关联影响

用户体验如何

(3)实现

人力、时间等资源是否存在困难

实现难度较大

遗留的坑会导致出严重bug的概率大,风险高

性能不佳,会造成用户体验差

是否有比产品经理想到的更好的方案

能否复用已有的逻辑或使用业界更通用的有开源实现的做法

后续的迭代考虑,是否在设计上预留可扩展性

不重要的部分(例如后台系统)由开发自行决定界面和交互

3.其他

在评审前我们阅读完相关资料后,就可以走整理我们想要提出的问题或是建议了

在评审的过程中,我们要站在用户的角度去思考,站在用户的角度去提出问题

对于新需求来讲,若出现开发和设计人员争执的情况,这时试人员就需要作为第三方站在用户的角度去剖析问题。否则,有些需求实现之后,在进行FUT测试的时候,才发现不合适,那之前做的工作都白做了,这就是资源的一种浪费

用例评审、归档用例

一个测试人员设计出的测试用例,可能会存在考虑不周的问题,如果没有及时的发现这些问题,就可能会出现用户发现问题导致对产品产生不好的影响。所以测试用例设计出来后,如何保证它的质量呢?这时我们将多位测试人员聚集在一起,集思广益,就有了用例评审。用例评审又分为正式评审和非正式评审。

1、评审方式

  • 同行评审

测试用例的评审有很多种,但是最敏捷应当是临时的同行评审。同行评审,尤其是临时的同行评审,应当演变成类似结对编程的一种方式。从而体现出敏捷的“个体和交互比过程和工具更有价值。”要体现出测试用例设计者之间的思想碰撞,可以通过讨论、协作完成测试用例的设计。原因很简单,编写的测试用例需要尽可能的覆盖全部需求,而测试人员的思维总会存在缺陷,一个人的思维总是存在局限性,所以需要大家一起来设计。

结对编程:一种敏捷开发的方式,指两个程序员在一台计算机上共同工作。一个人输入代码,另一个人审查他输入的每一行代码。输入代码的人叫做驾驶员,审查代码的人叫做观察员(或导航员),两个程序员经常互换角色。

  • 用户检查

除了同行评审,还应该尽量引入用户参与到测试用例的设计中来,让用户参与评审,从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛,关键在于如何定义测试,如果测试是对产品的批判,则顾客应该指最终用户或顾客代表(在内部可以是市场人员或领域专家);如果测试是被定义为对开发提供帮助和支持,那么顾客显然就是程序。

  • 项目组评审

由测试负责人组织开展会议,用例编写人对用例就行讲解,参会人员有异议的当场提出。

2、用例评审内容

在进行用例评审的时候,我们要准备的材料除了测试用例之外,还有测试方案。一般我们都用xmind工具来编写测试方案,

3、归档用例

归档用例就是在用例评审结束之后,将评审中的意见建议修改之后的用例提交到对应的平台上,这就叫做用例的归档。最迟的用例归档时间是在项目版本集成之前。归档用例主要是给其他的测试人员看的。

©️2020 CSDN 皮肤主题: 像素格子 设计师:CSDN官方博客 返回首页