新增和修改页面的用例设计和Bug提交

问题:

新增页面和修改页面,基本上输入框都一样,那比如同一个输入框的用例设计:

1. 写了新增页面的用例,修改页面对该输入框还有再写一遍用例的必要吗?

2. 执行用例时,新增页面验证了必填项,长度,数据类型,修改页面还要再验证一遍吗?

3. 提交Bug时,新增和修改页面的同一个输入框都出现了Bug,是只提交一个还是新增和修改各提一个。

参考答案:

我们写用例最容易落入一个误区,就是为了写用例而写用例。实际上写用例最主要目的是分析系统,如果系统业务复杂,用例分析与设计就很重要,如果很简单的功能不写用例也能够搞定执行。就好像我们做数学题1+2基本上不用思考就知道等于3,如果是546+788,我们甚至可能要列竖式认真算,这也是如果我们遇到简单功能,不用过多写用例就能测好,那么何必写?
    想必说到这里,我们的答案已经清晰了,新增的用例写完后,我们完全可以参考新增的用例去执行修改功能,不需要重复写用例了。
    当然第二个问题,我就不太能确定了。新能功能和修改功能是否共用一个程序?如果是,那么可以不用测试,如果不是,那么需要测试,要不要测试取决于系统的实现方式。
    第三个问题,同样我们需要思考我们提交缺陷的目的所在,我们是要开发能够修改所有的缺陷即可,那么不在乎到底是写在一起还是分开写,只要清晰体现即可。我一般做法是写在一起,说明同样的缺陷在其他具体哪些功能同样存在。

原文地址:https://www.cnblogs.com/laoluoits/p/9845774.html

时间: 2024-11-08 21:25:00

新增和修改页面的用例设计和Bug提交的相关文章

用例设计

1.支付用例: 金额框填写校验:只能是数字/小数点两位/金额为空/边界值校验:大于小于等于负数 支付方式:余额(余额不足)/第三方支付:密码填写错误/未安装第三方支付app→跳转或者提示/转账汇款:填写银行卡,信用卡的校验/支付方式空时提交 其他:部分支付/补缴支付/重复支付(避免:未返回前不能再次点击支付loading) 安全:修改支付金额或者支付方式后(charles),后台和第三方的需要校验并且返回/重要的参数传参时需要加密/取消支付/重复支付/支付时订单已取消 网速:限速测试→订单支付状

用例设计面试题

对登录进行用例设计 一.基本功能测试点: 输入正确的用户名和密码登录成功 输入错误的用户名密码登录失败 用户名正确,密码错误,是否提示输入密码错误? 用户名错误,密码正常,是否提示输入用户名错误? 用户名和密码都错误,是否有相应提示? 用户名密码为空时,是否有相应提示? 如果用户未注册,提示请先注册,然后进行登录 已经注销的用户登录失败,提示信息友好? 密码框是否加密显示? 用户名是否支持中文.特殊字符? 用户名是否有长度限制? 密码是否支持中文,特殊字符? 密码是否有长度限制? 密码是否区分大

不得不说--自动化测试元素定位与用例设计

关于自动化测试,经常被问到元素的定位 与 如何设计用例. 很多时间我也帮不了你解决实际的问题,只能从个人脚本谈谈如何看待这些问题. 不得不说之元素定位 虽然,本章写了十几篇文章来讲元素的定位与操作,对于碰到的一些常见功能,如何通过技巧来定位它们,但是在实际的自动化脚本开发中,不管是新手还是具有一定经验的老手,我们面临最多的问题仍然是元素的定位问题. 有时间元素定位非常简单,例如,我们只要知道这个元素有的id和name 就可以轻松的来定位到它:有时间元素的定位却非常的令人非常头疼,尽管我们用尽了所

页面自动生成工具设计

页面自动生成工具设计 1功能概述 1.1使用术语 页面自动生成工具:自定义查询条件以及数据显示的一种页面生成工具 1.2功能说明 页面自动生成工具是按照工程人员的需求定义查询条件以及数据显示方式的一种工具,数据显示可以用表格和图表的方式:查询统计以表格的方式显示数据,趋势页面以图表方式显示页面. 1.2.1查询统计页面 查询统计页面的设置如下图: "设置数据集":整个查询统计显示数据的完整sql语句. "查询条件设置":写完sql语句后点击"设置查询条件&

软件测试 —— 用例设计3(其他)

错误推测方法: 一.    方法简介 1.         定义:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 2.         错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 1)        例如, 输入数据和输出数据为0的情况:输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例. 2)        例如,前面例子中成绩报告的程序,采用错误推

基于需求文档(PRD)的功能用例设计

上一篇我讲了在项目运行过程中,用例是需要动态更新的.接下来我将结合实例(移动app)讲解在不同的阶段如何设计用例. 需求文档(PRD)主要讲述app的某个模块有什么功能,每一项功能的页面展示.页面操作有哪些,不同操作之间的关系是什么.基于PRD的用例设计是使用黑盒测试方法,而我平时主要使用了等价类划分.边界值分析法.状态转换测试.场景测试,操作实践时偏好于将模块分成页面展现.页面操作.接口.异常流,在每一个子项里运用黑盒测试方法进行设计. 以移动app的登录为例,大致需求如下图: 一.验证登录弹

angularJS修改 品优购修改品牌(新增和修改用同一个方法)

前端代码 brand.html <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <title>品牌管理</title> <meta content="width=device-widt

结对测试算法性能优化(用例设计层面)

在<结对测试算法性能优化(代码层面)>一文中, 对原来算法代码进行了一些优化, 对于笛卡尔积后千条数据,是能满足使用需要的. 但在实际业务中,会碰到百万数据. 比如某接口共18个参数,每个参数均可为空,其中8个只需要单个值,10个为多选项,需要多个值. 对于多选项,我的设计是,全选+随机n个多选(1<=n<=len-1)+空. 按照这个策略,笛卡尔积的结果就是3^8*2^10=6718464. 671万数据! parewise根本处理不动. 该怎么处理? 调整用例设计. 1.为空的

vue中的父子组件之间的通信--新增、修改弹框

在一个vue页面中有时候内容会很多,为了方便编写查看,可以分为多个子组件,最后在父组件中引入对应的子组件即可. 下面这个是父子组件通信中的一个具体实例:新增.修改弹框. 子组件中主要写了关于新增.修改的弹框, 子组件: 1.弹框: <div class="newDocuments"> <div class="newDocuments_center"> <div class="center_header"> &l