测试用例库的积累

测试用例的积累主要涉及如何编写测试用例,测试用例的重点以及测试方式的划分以及测试用例如何积累三个问题,下面我主要从这三个方式进行说明:

 一、如何编写测试用例

许多测试类书籍中都有大幅的篇章介绍用例的设计方法,如等价类划分,边界值,错误推断,因果图等。但实际应用中这些理论却不能给我们很明确的行为指导,在我们编写测试用例的时候也不会特别的花时间去研究因果图法等复杂的方法来进行用例编写。针对不同的产品用例在实际设计的过程中会有很大的不同,以下我主要讲我主要讲嵌入式产品的测试用例设计的大体思路。编写测试用例主要考虑以下五点:

1、基本功能模块有哪些,每个功能模块的基本测试点是什么?

2、若整个产品遵循某个协议,协议对于该功能点的限定是什么?

3、特殊情况对该功能模块的影响是什么?

4、各个功能模块之间的联系在哪里?

5、需求对于该功能点有什么特殊的要求,与协议不一样的或者是协议中没有提及的?

点1和点2测试用例的编写模式非常简单,无非是特定的数据格式或者特定的用法,用通用的等价类划分法以及边界值法就可以编写完成,这是测试的基本点该部分非常的适合通过编写自动化测试脚本实现,适合应用于项目的初期的冒烟测试以及后期的项目维护测试。点3和点4需要在不断的测试过程中不断的完善,这是一个长期积累的过程点5需要你不断的熟读需求,由于测试的需求全部都是英文,我们在每一轮全功能测试的过程中都会走一遍需求,这就是所谓的精读需求。在这个过程中经常会发现有一些需求在之前没有看到,那么这个时候就需要不断的补充测试用例了。

 二、测试用例的重点以及测试方式的划分

   点1和点2可以说是测试用例的基本点,是必须要遵循的规则,如果不遵循可能就会存在交互性问题。点3和点4部分测试的过程中不可能全部覆盖但是应该尽可能的全部覆盖。在很多的情况下,手工测试的工程师会吧测试的重点放在点1和点2,但其实更加重点的部分应该是点3和点4。造成这种现象的原因是由于测试人员的能力限制,加之人的趋利避害性,自然而然的就只是执行自己 比较熟悉的部分。那么如何解决这样一个问题呢?点1和点2部分实际上是非常的适合用自动化测试的方式实现的,尤其是进行项目前期的冒烟测试以及项目后期的维护。若该部分的自动化完成可以将手工测试的重点从基本的功能测试转移到更加符合使用者环境的场景测试中,这样就可以大大的提高测试效率。点5测试的重中之重,这是做为一名测试人员都应该知道的,需求是客户对我们提出的要求,只有实现了才能提高客户的满意度,争取更大的订单。

 三、测试用例如何积累

   测试用例如何积累,以什么样的方式积累呢?我惯用的软件是Xmind,没测试一个项目,相同的功能的实现方式,每个功能的差异点都会标注清楚,同时根据发现的不同的bug也会补充相应的测试用例。总之,只有不断的积累才可能获得自己的更加完善的测试用例库。

原文地址:https://www.cnblogs.com/xiaoyun9123/p/9148141.html

时间: 2024-10-12 21:59:02

测试用例库的积累的相关文章

用例写到想吐之感悟——通用测试用例库

连续几天都在写用例,回头看看,除了业务以外,基本上都是增删改查.分页控件校验.必填校验.格式校验.最大长度校验.特殊字符校验.唯一性校验,既然这样,为什么不专门建立一个通用测试用例库来存放这些通用的用例呢?这样就不必每个项目的每个查看页面都校验什么可不可以编辑,每个列表页都校验分页是否生效这些了. 通过这次写用例,还有一个感悟:自己写用例的时候先按照需求文档的来写,导致花在写业务相关上的用例很少,这样子很不好,写出的用例覆盖率相当不高...

JS(JavaScript)脚本库的积累

在现在互联网盛行的时代,使得B/S架构飞速发展.曾经在大学的时候我一直都梦想着毕业后要找一个像腾讯这样大企业做C/S方面的开发工作(其实现在腾讯也有很多B/S软件),因为C/S体验度非常高,感觉非常好.但是此时此刻,我却没有这样的想法了.这是为什么呢?对于有经验的软件工程师都很清楚,B/S的程序部署在服务器,客户端只需要浏览器即可使用,而C/S需要客户在终端安装客户端程序,所以B/S在维护和升级方面的简易性上,无疑有独有优势,而且对客户端的硬件要求相对于C/S软件一般都要低.B/S当然它也有它的

卡盾方面病毒库的积累

考虑要做一款杀毒是累的,我只能做一款文件检查引擎吧. 目前已经积累了61482个病毒特征码,这远远不够的. Win32:Evo-gen PUA.Win.Packer.Upx-29 W32/Felix:CO:Delphi!Eldorado Trojan.Generic.cbyt W32/Felix:EX:001!Eldorado W32/Behav-Heuristic-CorruptFile-EP Win32/Trojan.97a PUA.Win.Packer.PECompact-2 PUA.Wi

测试基础知识(白盒测试,黑盒测试,测试用例,功能测试等等)

测试基础知识 找实习工作的过程中总结了下测试基础知识,编程能力重要,测试基础同样重要,希望对大家有帮助 软件测试方法:静态测试和动态测试                     白盒测试和黑盒测试                     传统测试与面向对象测试 软件测试过程:单元测试,集成测试,系统测试,验收测试 按测试类型:功能.性能.界面.易用性测试.兼容性测试.安全性测试.安装测试 (单元测试:在编码过程中,对每个小程序单元测试) (集成测试:将单元集成在一起后,可称为组件) 回归测试.冒

论测试用例的有效更新及杀虫剂悖论

论测试用例的有效更新及杀虫剂悖论 在2014年,我们团队试图推动一件事情--把产品后端(客户.客服.生产制造等等)出现的问题,反向增补为测试用例,扩充到测试用例库中,避免后续重复的出现问题--早些年柳传志在创业类的节目问一个选手,作为老板,你每天第一件要处理什么事情.选手按照自己的优先级和重要性说了一堆.柳传志说:你应该优先处理反复出现的问题. 复盘论是联想的看家本领,这也仅借用一下这个意思. 尝试这么做了一段时间,把已经形成的反向增补测试用例,推广到相关测试用例库,然后在实际中执行和检查,一段

ones测试用例管理平台

https://ones.ai 团队信息: 公司信息,公司logo付费信息:绑定第三方账户: 成员信息: userid,user_email,激活状态,所属部门组织架构:所属部门: 新建组 团队权钱: 阿棉 概述数据中心: 工时日志报表,工时总览报表全局筛选器: 添加和管理我负责的任务,添加和管理我关注的任务个人中心: 修改自己的头像,用户名,职位,邮箱[提供可修改邮箱的链接],更改密码链接 ONES Project: 进行中的项目:未开始的项目:已经完成的项目ONES Wiki: ONES P

软件测试修炼之道(转载)

软件测试修炼之道 前言 软件测试发展到今天,已经逐渐形成一门学科,但是还不够系统. 初学者面对铺天盖地的资料应该如何选取?应该从哪里入手?如何迅速的掌握各种业务各项测试技能以便开展工作?在保证测试质量的前提下,一日内编写或执行1000个测试用例是不是梦想? 入行多年者面对复杂的业务逻辑,海量的测试需求,如何在最短的时间内进行测试?如何尽可能更早的开展测试?如何对系统架构进行测试?如何全面提高测试质量与测试效率?如何百尺竿头更进一步? 本文将针对这些问题进行初步解答,主要阐述解决这些问题应该具备哪

《软件测试管理公开课》2015.8.7~8 深圳 2015.8.11~12 北京 2015.8.18~19上海,欢迎报名!

课时:13小时(2天) 在软件开发流程中构筑软件质量 --软件测试管理     2015.8.7~8 深圳 2015.8.11~12 北京 2015.8.18~19上海   [课程背景] 据中国软件行业协会研究报告显示,2010年1-11月,我国软件业呈快速增长态势,同比增长30%,增速比去年同期提高8.6个百分点,软件产业已成为中国高科技发展重要支柱之一,但中国软件产品质量保证手段以及测试流程和管理的规范性,与国外同行(美国.印度等)存在较大的的差距.      在软件业较发达的国家, 软件测

如何做好系统测试

  目录 1       目的... 2 2       目标读者... 2 3       说明... 2 4       Part1 项目各阶段工作... 2 4.1        需求调研阶段... 2 4.2        项目启动阶段... 2 4.3        项目开发阶段... 3 4.4        集成和系统测试阶段... 3 4.5        项目上线... 4 4.6        运维阶段... 4 5       自我提升... 5 5.1        总结