测试用例设计

windows基础 软件定义 计算机=硬件加软件 软件=程序(program)+文档(document) 软件测试的对象：程序和文档都要测试 软件开发阶段划分 阶段一：需求分析阶段(由需求分析人员完成；产出物：《需求规格说明书》) 阶段二：设计阶段(由系统架构师/分析师完成；产出物：《概要设计说明书》和《详细设计说明书》) 阶段三：编码阶段(由开发人员完成/程序员完成；产出物：程序/代码) 不同的开发阶段引入的bug比例如何? 需求分析阶段引入的bug最多（大概占bug总数的55%左右） 其次是设计阶段（大概占缺陷总数的25%左右） 最少的是编码阶段（大概占缺陷总数的15%左右） 还有5%左右的缺陷是由系统兼容性或者配置原因造成的。 需求分析阶段引入的bug最多，其次是设计阶段，引入bug阶段最少的是编码阶段 因此：1）在测试中不能只测程序，文档也必须测 2）测试工作应尽早介入，并且贯穿整个开发周期始终(尽早测试原则，不断测试原则) 什么是软件缺陷 1.软件的缺陷–defect,bug 2.软件缺陷的定义：1）需求要求的功能没有实现 2）实现了需求没有的功能(画蛇添足) 3）软件出现了指明不应出现的错误 4）需求虽未明确指明，但是应该实现的功能没有实现 eg:法规； 说明：需求不是完美的，有可能有遗漏，但是测试人员应该专业，发现bug就要提交，即使需求中没有提及 5）软件不易使用

1.自我介绍 2.介绍下你实习主要负责的项目情况？你是如何测试的？ 3.如果某个查询结果为空，如何排查问题？ 3.bug如何跟踪？ 4.web测试会不会关注页面响应？举例？ 5.如何理解测试？ 6.测试流程？ 7.有没有写过测试设计？用例？ 8.测试设计方法有哪些？ 9.用excel写个登陆功能的用例？ 10.说下你写的sql注入要怎么做？想测什么？ 1.自我介绍 2.实习的项目介绍，有哪些模块？ 3.熟悉的语言是？写个代码：有效ip 4.了解ipv6的ip格式吗？ 5.聊聊做的笔试题吧？ 6.说下osi七层模型？数据链路层做了什么？ 7.知道二三层传输吗？ 8.说下tcp三次握手 9.网络编程socket知道吗？ 10.sql语句的执行顺序？ 11.聊下对测试的理解？ 12.有没有bug没测出来被用户提出来的？ 13.有没有接触到性能和安全方面的测试？ 14.医院真实数据你们拿不到，那么像比较大的患者数据你们如何进行测试呢？ 15.说下用例设计思路：atm机 16.用例情况很多，组合很多时怎么处理？如何保证最少的用例覆盖最多的测试点？ 17.因果图和正交法具体怎么使用？ 18.谈谈你对自动化测试的理解？ 来源： CSDN 作者： Apollo- 链接： https://blog.csdn.net/qq_39091292/article/details/104631277

软件测试的基本知识点 软件的分类 C/S与B/S架构 软件测试的定义 软件测试的目的 软件测试的分类 软件生命周期 生命周期模型 1.瀑布型生命周期模型 2.V模型 3.敏捷开发模型 软件测试的基本流程 测试设计用例设计方法 等价类划分法 边界值分析法 场景法 错误推测法 测试用例的编写与评审 软件的分类 软件分为两大类：系统软件、应用软件。 软件测试的对象是：程序、数据、文档。（主要为程序） C/S与B/S架构 C/S ：就是我们一定要安装安装一个客户端才能够使用的软件。 缺点：每次更新都要更新服务端和客户端。 B/S ：只需一个浏览器就可以访问服务。 优点：只需更新服务器不需要更新浏览器，用户主动性比较高。 软件测试的定义 使用人工和自动的手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。 软件测试的目的 1.软件测试是为了发现程序存在的代码或业务逻辑错误 2.软件测试是为了检验产品是否符合客户的需求 3.软件测试是为了提高用户的体验 软件测试的分类 按测试技术划分：白盒测试、黑盒测试、灰盒测试 对象是否运行划分：动态测试、静态测试 按不同测试手段划分：手工测试、自动化测试 按测试包含的内容划分：功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试 其他测试：冒烟测试、回归测试、探索性测试/自由测试 冒烟测试–>主干

软件测试英语专业词汇 NLV：Nation Language Version 本地化版本 FVT：Functional Verification Testing 功能验证测试 TVT：Translation Verification Testing 翻译验证测试 SVT：System Verification Testing 系统验证测试 fault－－故障 在软件中一个错误的表现。 feasible path－－可达路径 可以通过一组输入值和条件执行到的一条路径。 feature testing－－特性测试 参考功能测试（Functional Testing） FMEA－－失效模型效果分析（Failure Modes and Effects Analysis） 可靠性分析中的一种方法，用于在基本组件级别上确认对系统性能有重大影响的失效 FMECA－－失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis) FMEA的一个扩展，它分析了失效结果的严重性。 FTA－－故障树分析(Fault Tree Analysis) 引起一个不需要事件产生的条件和因素的确认和分析，通常是严重影响系统性能、经济性、安全性或其它需要特性。 functional decomposition－－功能分解 参考模块分解（modular

出场人物： 08：10 小H，是巨杉数据库引擎研发的一名工程师。7：20 天还蒙蒙亮，小H就起床了，点亮了心爱的光剑，开始了新的一天。 在08:10时候，他已经洗漱完，锻炼好身体，倒好了咖啡。 整个春节由于疫情防控，他为国家做出了贡献，基本都宅在家里了。但是他觉得，宅在家里，也是一个挺好的春节。 小H查看了手机，发现一封未读邮件，显示是公司 Jenkins 系统发出。 小H打开邮箱，查看了未读邮件，是昨天新提交的优化代码 PR，导致了昨晚自动化测试系统中一个测试用例没有通过。 09:15 在平时，大家 9 点上班回到公司，各个小组都会在09:15自发地开一个简短的站立会，组内成员分别大致介绍一下昨天完成的工作内容还有今天的工作计划，然后大家开始了一天的工作。 现在，只是面对面的站立会，变成了“线上站立会“，大家依然按时登入小鱼易联的会议号。 小H在会上介绍了一下昨天提交引擎里 analyze 优化的代码，以及发现新代码会导致一些测试用例失败的情况。他打算今天将这个问题解决。 09：25 小N，是巨杉数据库的测试工程师。 早上刚刚拿出“小黄鸭“准备开始工作，她也收到了昨晚自动化测试系统用例失败的邮件。昨晚失败的测试用例，是她负责的。在刚才的站立会上，她计划今天和小H一起跟进这个失败用例。 开完了早上站立会，她通过 *** 远程连接公司内部的云桌面。

基础篇——在学习中思考！ 在大概了解了 UML 之后就该系统的学习 UML 的主要建模元素了，一个个实例帮助我们更好的理解这些元素的重要性并运用相关知识解决实际问题。 在 UML 里有一个概念叫版型，有些书里也称为类型、构造型。版型只是 UML 的一种扩展手段，本身并不涉及太多的思想和方法，而是在建模的不同阶段，为了区分视图之间的不同观点，会采用不同的图示来表示。 以人为本是当代的流行词汇， UML 建模也是以人为本的。参与者在建模过程中是处于核心地位的， actor 是在系统之外与子同交互的某人或某事。系统之外的定义说明在参与者和系统之间有一个明确的边界，赞誉这只可能存在于边界之外，边界之内的人和事物都不是参与者。在查找参与者的过程中，可以询问以下问题以帮助确定参与者： （1）谁是负责提供、使用或删除信息？ （2）谁将使用此功能？ （3）谁对某个特定的功能感兴趣？ （4）在组织的什么地方使用系统？ （5）谁负责支持和维护系统？ （6）系统有哪些外部资源？ （7）其他还有那些系统需要与该系统交互？ 查找参与者时请注意，参与者一定是直接并且主动的向系统发出动作并获得反馈的，否则就不是参与者。此时可以理解刚开始举的例子“小王到银行去开户，向大厅经历询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。”在这个场景中，小王是参与者，而经理和柜台职员及其他事物都在系统边界以内

定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一些列操作，这些操作生成特定主角 可以观测的值 。一个完整的用例定义由参与者、前置条件、场景、后置条件构成。 1、理解用例： 用例就是参与者希望通过系统达到的愿望。一个系统的功能性是由一些对系统有愿望的参与者要做的一些事构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能够通过用例来达到，那么这个系统就被确定下来了。捕捉功能性需求就是用例的作用。 2、特征： （1）用例是相对独立的； （2）用例的执行结果对参与者来说是可观测的和有意义的； （3）用例必须由参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例； （4）用例必然是以动宾短语形式出现的； （5）一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。 3、区分用例和功能： 第一，功能是脱离使用者的愿望存在的，而用例不是； 第二，功能是孤立的，给一个输入，通过计算机就有一个固定的输出，例如，按下开关灯就亮；而用例是系统性的，它需要描述谁在什么情况下通过什么方式开灯的结果是什么； 第三，非要从功能的角度解释的话，用例可以解释为一系列完成一个特定目标的“功能”的组合。 4、业务用例： 业务用例是用例版型中的一种，用于需求阶段的业务建模。严格的说，业务建模与计算机系统建模无关，它只是业务领域的一个模型

页面描述 web登录页面：有两个文本框，一个提交按钮(注册、忘记密码等按钮) 用例设计 【功能测试(Function test) 0.什么都不输入，点击提交按钮，看提示信息。（非空检查） 1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。（正常输入） 2.输入错误的用户名或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验） 3.登录成功后能否能否跳转到正确的页面（低） 4.用户名和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示） 5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤） 6.记住用户名的功能 7.登陆失败后，不能记录密码，用户名可以保存 8.用户名和密码前后有空格的处理 9.密码是否加密显示（星号圆点等） 10.登录需要验证码的，输入完用户名和密码后，验证码为必填项 11.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），"刷新"或"换一个"按钮是否好用 12.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确 13.输入密码的时候，大写键盘开启的时候要有提示信息。 14.输入错指定次数后，账号锁定，需要做解锁处理 15.登录失败的提示信息需要高亮处理 16.登录失败有次数限制的，每失败一次，提示剩余可以登录次数和处理建议 【界面测试(UI Test) 1

1.接口定义 接口：主要是子模块或者子系统间交互并相互作用的部分。如：客户端与后台服务间的协议，插件间通信的接口，模块间的接口，小到类提供的方法等。 接口测试：针对模块或系统间的接口测试。 2.接口测试发现的典型问题 传入参数处理不当，导致程序crash 类型溢出，导致数据读出和写入不一致 因对象权限未校验，可以访问其他用户敏感信息 状态处理不当，导致程序错乱 逻辑校验不完整，可利用漏洞获取非正当利益等 3.接口测试用例设计 针对输入设计 (1)数值型：如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。 例如检查权限的接口：TaskChecker.checkTask(int taskID) taskID的取值范围是1-35，那么设计时考虑： 　　●1-35范围内和范围外的值； 　　●1-35的边界：0，1,35,36； 　　●类型的特殊值：-1,0 　　●数据类型的边界值：int的最小值最大值； 　　●因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。 　　常见问题和风险： 　　●特殊值处理不当导致程序异常退出； 　　●类型边界溢出 　　●取值范围外未返回正确的错误信息等 (2)字符串型：字符串型的参数，主要考虑字符串的长度和内容 例如接口转换设置闹钟的接口DateUtil.getDayOfDDHH

csdn测试用例设计白皮书文档地址： https://blog.csdn.net/vincetest/article/details/1478552 用例编写步骤： 拿到测试需求 -> 分析需求（画思维导图） -> 编写用例 -> 划分用例优先级 用例编写特性： · 一致性：主要包括用例模板一致；各同事的编写手法一致；以及用例的细粒度一致。 · 覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产生影响的覆盖；对各种场景的覆盖等 。 ·可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。 ·执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素，导致部分用例未实际执行标为通过的情况。 ·持续更新：要及时不断的更新，要尽量减少用例库中失效的用例 。 ·复用性：主要用例可以被不断的复用，从而减少维护成本 用例设计方法： 1. 等价类与边界值 （重点方法） 等价类：等价类划分法是把所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入），即程序的输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。方法是一种重要的、常用的黑盒测试用例设计方法。 边界值：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法