发布时间:2020-07-24
作为测试人员如果想提升测试用例的编写能力,首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么,客户不想要什么,也就是所谓的客户的使用场景,这样有利于我们更好的挖掘和思考隐含的需求。至于这个需求该不该做,那是需求人员的职责,这个需求做起来复不复杂那是开发人员的事情,作为测试人员需要考虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景,以及一些客户基本不会用到的场景有哪些。所以今天小编给大家总结了一下关于如何进行测试用例管理的要点,供大家参考!
1、测试需求分析,得到测试点
在测试需求分析阶段,我们只有需求文档,所以编写测试用例的唯一依据就是需求文档,因此在进行用例编写之前一定要进行需求分析,需求分析的主要工作就是:
了解需求的整个实现背景;分析需求的合理性;
明确需求的范围,挖掘需求文档中隐藏的需求;
在通过需求交底的过程,确定开发的初步实现思路和方法,随着测试需求分析的深入,列出需求的框架,包括测试范围即各个功能点,测试的场景等;
确定一些测试可以提前介入的工作等;需要说明的是对于需求中的问题一定要记录下来,找需求确认,需求漏掉的或者存在问题的地方,开发和测试更容易漏掉,而且遗漏的需求很有可能会使得项目整体业务逻辑发生变化,一定要及时提前确认。
2、分析得到用例优先级
得到了需求的各个测试点后,应该先将这些测试点简单的分配一下优等级,一般分为高中低三个优先级,我认为得到优先级后可以让需求用例的设计更有侧重和着重点。
3、细化测试点变成可执行case
根据测试需求分析得到的需求框架,梳理细化测试点,这里的测试点虽然粗,但是不应该有遗漏,这是进行测试点细化的前提。根据测试点,细化出具体的测试用例,要注意各个点的组合测试的情况,还要注意各个测试点的反向测试的情况。
在细化测试点的时候,我们可以要参考以前写好的公共测试用例,甚至可以直接引用,这样既可以避免一些不必要的时间浪费,但是参考不等于照搬,在引用的同时,也一定要思考本次需求自己特有的测试点。
另外需要考虑的就是测试点细化到什么程度的问题,也就是一个度的问题,我们要把握好测试点细化的一个度的问题,太粗的测试点没有指导意义,太细的测试点容易让我们纠的太细,忽略整体的测试,反而也起不到一个指导的效果,所以一定要把握好测试点细化的度。
4、及时更新测试用例
需求分析和用例编写阶段,是主要的细化用例时间,这段时间的目标是梳理出可指导执行测试的用例,但是需求会有变动,需求会有维护,用例也一样,所以用例是需要持续维护的, 所以在需求变动的同时,我们也要及时维护测试用例,否则的话,测试用例很可能成为一个错误的指导。
另外测试用例完成后就会进入一个用例评审的阶段,在用例评审阶段,会有用例评审人,针对你的用例作出的评审,主要检查你的用例是否有测试点遗漏,场景遗漏,测试case描述模糊,测试结果输出模糊等问题,针对用例评审人提出的问题,我们也要及时的更改我们的用例。
5、及时维护通用测试用例
什么是通用测试用例呢?项目中或者跨项目中很多的公用业务,固化模块,这些功能基本上是趋于稳定不变的,因此可以梳理出通用的比较全面的测试点,作为指导和规范业务和模块的规范,这些生成的规范即通用的测试用例。当我们针对某一模块或者业务持续维护时,就发现我们需要持续维护这的用例,就会发现有些用例业务类似、执行步骤一致、验证项属性一致等等,这个时候通过梳理业务的通用属性,通用用例梳理梳理成章。
所以说,通用的测试用例是一个对用例不断维护的产出,因此我们在测试软件维护的过程中一定要及时的更新通用测试用例,对后面的测试和用例维护有一个很大的指导作用。
推荐阅读:
您的信息已成功提交!
我们的客服人员稍后会与您联系