软件测试:测试用例的设计思想

一,登陆页面的测试:

下面以一个登陆窗口为例,说说我设计登陆界面的思路和方法。我把这个测试用例分为三层结构,表单测试、逻辑判断、业务流程。

第一层,表单测试为最底层(最基础的)。这部分的测试用例是对登陆窗口这个界面的输入框、按钮功能、界面等最基本功能的测试。一般来说登陆用户名和登陆用户密码是输入框的形式体现,那么,我们需要的是针对这两个输入框进行功能的测试。这时,我们只要考虑这个输入框的功能,而不需要考虑业务方面的内容。这样,我们考虑就是这个输入框的长度限制是多少?能否输入特殊字符?能否输入全角字符?当然,登陆窗口还有其他按钮,例如登陆按钮、退出按钮、界面设计等,这一层的测试用例只对他们最简单的功能的测试。我觉得这一层的测试用例对新开发项目很重要,也必须执行,因为这些是最基本的功能保证,当项目进入维护阶段后,如果没有修改就不需要执行这部分的测试了或者说把这层的用例优先级置为最低,时间不充足的情况就不用去执行。

第二层,逻辑判断层。根据需求的设计,各功能之间的简单逻辑联系。以登陆窗口为例,账号登录,账号和密码必须对应才能登录,否则登录失败。根据这一点,我们就可以从这个要求设计这一层测试用例。例如,账号和密码不一致时;账号为空时;密码为空时;账号密码对应时等等情况。输入这些情况时,程序是作怎么样的逻辑控制的?控制是否正确?是否有相应的提示信息?平时使用软件经常碰到的一些情况,在常规测试或修改这部分的功能之后,这一部分的测试用例也必须执行。

第三层,业务流程层。这部分不关心软件的本身的基本功能,而是关心这个软件的业务有没有实现,不同的需求就有不同的业务需求。以登陆窗口为例,就可能有不同的需求,可能用户要求停用的账号能够登录系统(可能要求登录后不允许进行其他操作),也可能用户直接要求停用的用户账号不准登录系统。根据不同的业务需求,就有不同的业务流程。这样这层的测试用例,我们就只要考虑业务需求,仍然以登录窗口为例,我们就只要考虑删除的用户能否登录?停用的用户能否登录?超级用户是如何登录的?普通用户是何种方式登录的?简单的说,这层的用例只描述业务流程,不关心具体这个业务是怎么实现的,执行这部分用例时,不要考虑哪个输入框控制了多少长度,能否输入空格等其他功能,因为这部分的测试需要基于上面两层的测试用例都已经测试通过了,所以在项目维护阶段或者说时间很紧迫的阶段,我们只需要执行这部分的用例,保证业务能够通畅的完成。其实个人觉得在执行这部分用例时,对包含了对基本功能的测试,一些明显的问题应该能被发现,虽然严格来说测试覆盖率很低,但是基本能达到要求。

这三层的组合起来才是一个完整的测试用例。这是我个人对测试用例设计的一个思路和方法。真正设计这个测试用例的时候,可能会使用到黑盒测试用例的方法,例如等价类划分、边界值分析、错误猜测法(主要是个人经验)、正交分解等方法针对具体情况设计测试用例。分层测试用例的思路主要来自对自动测试实现的考虑。因为我觉得,如果需要实现自动化测试就必须对测试用例进行细分,划分得越细就越有利于自动化的实现。以上三层的划分也并不是很全面,需要在实践中不断完善,例如可以增加对数据库的部分功能的数据校验的分析。总之,测试用例写的细致、全面、步骤清晰,那么无论是用手工测试的方法还是用自动化测试的方法实现,只要能完整的跑完整个测试用例,就达到了测试的目标了。

时间: 2024-10-06 02:36:08

软件测试:测试用例的设计思想的相关文章

在国外,资深的软件测试人员大多是手动测试,他们厉害之处在于测试用例的设计,但在国内,很多测试人员都把自动化测试当成很厉害的资本,为什么?

导语:”在国外,资深的软件测试人员大多是手动测试,他们厉害之处在于测试用例的设计,但在国内,很多测试人员都把自动化测试当成很厉害的资本,为什么?” 偶然在知乎上看到一篇关注度很高的话题,标题如上. 作为一名从业8年有余的软件测试工程师,并且一直在外企做测试的我, 忍不住想发表一些自己的看法和见解. 我觉得在国内,很多公司或者个人把自动化测试当成一个了不起的资本,根本是源于国内大家对代码的无上崇拜,这也造就了国内现在IT互联网行业内一个鄙视链: 开发---> 测试开发--->自动化测试---&g

测试用例的设计方法

测试用例的设计方法有: 等价类划分方法,边界值分析方法,错误推理方法,因果图方法,判定表驱动分析方法,正交实验设计方法,功能图分析方法,场景设计方法 等价类划分方法: 基本概念: 一.方法简介 1.定义 是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 2.划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等

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

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

软件测试用例的设计和编写

一.为什么要写测试用例 写测试用例可以让测试的需求覆盖更加全面,让测试工作进行得条理有序,且方便移交和交流 好的测试用例要做到:结构设置和理,case覆盖全面,且具有可执行性,可重复等特点. 二.软件测试文档 1.测试范围列表:需求编号.模块名称.功能名称.复杂度.复用性.自测充分性.是否公用模块.使用频率.优先级 2.测试用例一般包含的要素:用例编号.测试项目.用例标题.优先级(致命.严重.一般.微小.建议).预置条件.输入参数.执行步骤.预期结果 3. 缺陷报告要素:缺陷编号.缺陷标题.严重

从“系统登陆”测试用例案例来分析测试用例的设计

编写测试用例是软件测试工程师最基本的工作.但是如何要编写出好的测试用例,这还真是需要我么对平时的工作认真的进行总结一下. 下面我以"系统登陆"黑盒测试用例设计来分析一下测试用例到底如何来写? 一.案例描述 测试对象:是一个以B/S结构系统的登陆功能点. 功能描述:1.用户在地址栏输入相应的地址,要求限时登陆界面 2.输入用户名.密码和验证码,登陆,系统自动校验,并给出相应提示信息. 3.如果用户名.密码.验证码任一信息未输入,登陆后系统给出相应提示信息. 4.连续3次未通过验证时,自动

单元测试中测试用例的设计方法

单元测试中测试用例的设计方法 1. 用于语句覆盖的基路径法 基路径法保证设计出的测试用例,使程序的每一个可执行语句至少执行一次,即实现语句覆盖.基路径法是理论与应用脱节的典型,基本上没有应用价值,读者稍作了解即可,不必理解和掌握. 基路径法步骤如下: 1)画出程序的控制流图 控制流图是描述程序控制流的一种图示方法,主要由结点和边构成,边代表控制流的方向,节点代表控制流的汇聚处,边和结点圈定的空间叫做区域,下面是控制流图的基本元素: 以下代码: void Sort(int iRecordNum,

011-黑盒测试的测试用例常见设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用

黑盒测试的测试用例常见设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用. 1)等价类划分 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 2)边界值分析法 边界值分析方法是

中文翻译为"具象状态传输"的RESTful的架构风格和设计思想

本文标签:  具象状态传输 RESTful架构 RESTful理解 REST   服务器 REST 定义了一组体系架构原则,您可以根据这些,包括使用不同语言编写的客户端如何通过 HTTP 处理和传输资源状态.所以在事实上,REST 对 Web的影响非常大,由于其使用相当方便,已经普遍地取代了基于 SOAP 和 WSDL 的接口设计.在多年以后的今天,REST的主要框架已经开始雨后春笋般的出现. REST(Representational State Transfer ),有中文翻译为"具象状态传

作业01的设计思想、程序流程图、源代码、结果截图

一.设计思想: 1.读入类型为String的参数,并且进行显示: 2.然后进行强制类型转化,将String类型转化为int类型: 3.然后各个参数相加: 4.输出最后的结果: 二.流程图: 三.源代码: package demo; public class sum { /** * @param args */ public static void main(String[] args) { // TODO Auto-generated method stub System.out.println