上海正规网站建设耗材,做网站每天任务及实训过程,廊坊seo排名优化,有关网站建设的参考文献测试常见知识点汇总 一、什么是测试1.1 测试和调试的区别1.2 什么是需求1.2.1 用户需求1.2.2 软件需求 1.3 测试用例要素1.4 软件的生命周期及各阶段概述1.5 开发模型和测试模型#xff08;记住特点和适用场景#xff09;1.5.1 开发模型1.5.1.1 瀑布模型#xff08;自上而下… 测试常见知识点汇总 一、什么是测试1.1 测试和调试的区别1.2 什么是需求1.2.1 用户需求1.2.2 软件需求 1.3 测试用例要素1.4 软件的生命周期及各阶段概述1.5 开发模型和测试模型记住特点和适用场景1.5.1 开发模型1.5.1.1 瀑布模型自上而下、相互衔接的固定顺序1.5.1.2 螺旋模型1.5.1.3 增量模型和迭代模型1.5.1.4 敏捷模型 1.5.2 测试模型1.5.2.1 V模型1.5.2.2 W模型 / 双V模型 二、测试基础部分2.1 什么是Bug2.2 Bug描述2.3 Bug等级2.4 Bug的生命周期 三、测试用例3.1 测试用例的基本要素3.2 设计测试用例的万能思路3.3 基于需求设计测试用例3.4 具体的设计方法3.5 测试分类3.5.1 按照测试对象划分3.5.2 是否查看代码3.5.3 开发阶段3.5.4 实施组织3.5.5 是否运行代码3.5.6 是否手工3.5.7 跨地域 这里目录的内容看起来有点多但其实只是作为一个思维导图的作用文内内容比较精简但基本是按照理解分析的各位读者可以作为借鉴参考一下文内若有理解错误的地方欢迎指出。 一、什么是测试
测试是测试人员验证软件特性是否符合需求的过程
1.1 测试和调试的区别
1、目的测试的目的是找问题调试的目的是找到并解决问题。2、人员测试由专门的测试人员完成调试由开发人员完成。3、结果测试从已知条件开始使用预定义的过程并且有预期结果而调试条件未知结果不可 预知。4、过程测试可以预先计划可以制订测试用例和计划进度可以度量调试没有计划进度也不可以度量。5、阶段测试贯穿于软件生命周期的整个阶段调试只在编码阶段进行
1.2 什么是需求
1.2.1 用户需求
可以简单理解为甲方提出的需求如果没有甲方那么就是终端用户使用产品时必须要完成的任务。
1.2.2 软件需求
详细描述开发人员必须实现的软件功能软件需求是测试人员进行测试工作的基本依据。
1.3 测试用例要素
通用测试用例八要素 1、用例编号 一般是数字和字符组合成的字符串可以包括下划线、单词缩写、数字等等但是需要注意的是尽量不要写汉语拼音因为拼音的意义可能有好几种有可能会导致乱码用例编号具有唯一性和易识别性。 2、测试项目 测试项目对应的就是测试用例中的子项名。 1系统测试用例对应一个功能点功能测试、性能指标性能测试、界面中控件GUI测试等等。 2集成测试用例对应集成后的模块功能或者接口功能。 3单元测试用例对应函数名。 3、测试标题 测试标题考虑的是如何来完成测试项目或者说从哪个角度来对测试项目进行测试有的公司也取名为测试目的。测试标题一定要简单、概要体现测试的出发点和关注点。 4、重要级别 用例的重要级别一般分成三个级别高、中、低。高级别对应保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例中级别对应重要程度介于高和低之间的测试用例低级别对应实际使用频率不高对系统业务功能影响比较大的模块或功能的测试用例。 5、预置条件 测试用例在执行前需要满足一些前提条件否则测试用例是无法执行的这些前提条件就是预置条件。 6、测试输入 用例执行过程中需要加工的外部信息根据软件测试用例的具体情况有手工输入、文件、数据库记录等。禁止过多描述性语言若为文件会有提示选择路径最好写具体让别人易懂易操作。 7、操作步骤 明确描述测试执行过程中具体的操作步骤以方便测试执行人员可以根据该操作步骤完成测试用例执行。 8、预期输出 预期输出是测试用例中非常重要的一部分预期输出可以检验被测对象是否正常工作如果我们的预期输出写的不完整不全面整个测试用例就会受到影响。 具体可参考 https://blog.csdn.net/weixin_44015669/article/details/121082810
1.4 软件的生命周期及各阶段概述
需求 — 计划 — 编码 — 测试 — 上线 — 维护 需求确定软件要做成什么样 计划确定软件什么时候开发什么时候开始测试什么时候结束开发什么时候结束测试 编码通过软件需求实现软件特性 测试测试人员测试软件是否有缺陷 上线将项目推上上线环境让用户可以访问到 维护项目如果在线上出现问题此时测试人员、开发人员定位问题、解决问题项目还需要优化测试人员开发人员需要对项目不断地优化。 1.5 开发模型和测试模型记住特点和适用场景
1.5.1 开发模型
1.5.1.1 瀑布模型自上而下、相互衔接的固定顺序
特点 线性的测试参与时机太靠后不能尽早发现问题 适用项目 适用于小型项目项目迭代周期非常短比如项目周期1天或者0.5天 1.5.1.2 螺旋模型
特点 每个阶段开始之前都有一个风险分析可以避免一定的风险但是风险分析需要一定的投入如果分析错了会带来一定的损失同时不断地迭代有可能导致项目延期 适用场景 比较复杂风险比较大的项目 1.5.1.3 增量模型和迭代模型
增量模型一个模块开发完毕在开发下一个模块迭代模型所有模块一起开发先开发大的框架在开发细节
1.5.1.4 敏捷模型 Scrum三个重要角色和五个重要会议: 角色 产品经理PO收集需求来自客服反馈来自用户 项目经理SM需要进行需求优先级确定项目计划确定 研发团队 team不光包含开发还包含测试UI 会议 发布计划会议产品经理PO负责讲解user storySM项目经理对其进行估算和排序发布计划会议的产出就是制定出这一期送代要完成的story列表sprint backlog. 迭代计划会议项目团队对每一个story进行任务分解分解的标准是完成该story的所有任务每个任务都有明确的负责人并完成工时的初估计 每日站会每天scrum master召集站立会议团队成员回答昨天做了什么今天计划做什么有什么问题 演示会议迭代结束之后召开演示会议相关人员都受邀参加团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来由po整理形成新的story 回顾会议项目团队对本明迭代进行总结发现不足制定改进计划下一次迭代继续改进已达到持续改进的效果 特点 个体与交互重于过程和工月可用的软件重于完备的文档客户协作重于合同谈判响应变化重于遵循计划在每对比对中后者并非全无价值但我们更看重前者 1.5.2 测试模型
1.5.2.1 V模型
特点 左边是开发右边是测试测试介入太晚发现问题时机就会越晚测试和开发是串行的 1.5.2.2 W模型 / 双V模型
特点: 第一个是开发第二个V是测试测试在刚开始就介入了整个项目测试是对整个项目的每个阶段进行了测试但是测试开发还是串行的所以不能拥抱变化 二、测试基础部分
2.1 什么是Bug 1当且仅当规格说明是存在的并且正确程序与规格说明之间的不匹配才是错误。 2当需求规格说明书没有提到的功能判断标准以最终用户为准 当程序没有实现其最终用户合理预期的 功能要求时就是软件错误。 BUG可以理解为 1在软件开发的生命周期中可能导致软件产品出现问题的程序缺陷。 2产品说明书中规定要做的事情而软件没有实现。 3产品说明书中没有提到过的事情而软件确实现了。 4产品说明书中没有提到但是必须要做的事情软件却没有实现。 5软件很难理解很难使用速度超慢测试人员站在最终用户的角度看到的问题是平常的但不是正确的。 2.2 Bug描述 1.概 述用一句话简要描述Bug的现象。需要包括bug所在的模块及出错点 前置条件 产生bug需要的前提必要时填写 2.步 骤使用数字编号的形式相对详细阐述出现Bug的操作步骤需保证使用这样的叙述其他人便可重现bug必要时需要描述bug产生的前提和条件。 3.预 期填写上述操作过程应该输出的正确结果。 4.结 果用文字准确描述出Bug引起的结果及现象必要时需要有图形附件用拷屏方式将错误信息添加进来。 5.结果分析bug修改完毕后简要描述此Bug产生的原因。 2.3 Bug等级
大概有崩溃、严重、一般、次要 具体可参考https://zhuanlan.zhihu.com/p/103637796
2.4 Bug的生命周期 三、测试用例
3.1 测试用例的基本要素
如上文1.3所述
3.2 设计测试用例的万能思路 功能兼容界面易用性能安全网络安装测试卸载测试 参考如下登录页面的测试用例 3.3 基于需求设计测试用例
可参考水杯测试用例运用万能公式 3.4 具体的设计方法
等价类、边界值、判定表、正交法、场景法、错误猜测法等
3.5 测试分类
3.5.1 按照测试对象划分
界面容错可靠兼容文档易用安装卸载安全性能内存泄漏
3.5.2 是否查看代码 白盒测试白盒测试又称为结构测试或逻辑驱动测试它是把测试对象看成一个透明的盒子它允许测试人员利用程序内部的逻辑结构设计测试用例对程序所有逻辑路径进行测试。具体可参考https://blog.csdn.net/qq_42944594/article/details/121907540 黑盒测试在测试时把程序看作一个不能打开的黑盒子在完全不考虑程序内部结构和内部特性的情况下测试人员进行直接测试检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果等检查相应的文档是否采用了正确的模板、是否满足规范需求。具体可参考https://blog.csdn.net/yeuteyietir/article/details/93522978
3.5.3 开发阶段
单元测试、集成测试、系统测试、验收测试具体可参考https://blog.csdn.net/ty6693/article/details/89215677
3.5.4 实施组织
α测试和β测试区别它们都是验收测试 α测试是指把用户请到开发方的场所来测试 β测试是指在一个或多个用户的场所进行的测试。 α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。 β测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。 α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较长
3.5.5 是否运行代码
静态测试、动态测试 1、测试部分的不同 静态测试是指测试不运行的部分只是检查和审阅,如规范测试、软件模型测试、文档测试等。动态测试是通常意义上的测试也就是运行和使用软件。 2、测试方式不同 静态测试通过评审文档、阅读代码等方式测试软件称为静态测试通过运行程序测试软件称为动态测试。 3、测试方法不同 静态测试是指不用执行程序的测试它主要采取方案—代码走查、技术评审、代码审查的方法对软件产品进行测试。动态测试主要通过构造测试实例、执行程序、分析程序的输出结果这三种方法来对软件进行测试。 3.5.6 是否手工
手工测试 手工测试是一种软件测试的类型其中测试人员无需使用任何自动化工具即可手动执行测试用例。手工测试的目的是识别软件应用程序中的错误、问题和缺陷。手工软件测试是所有测试类型中最原始的技术它有助于发现软件应用程序中的关键缺陷。 任何新应用程序都必须先进行手工测试然后才能使其测试自动化。手工软件测试需要更多的精力但对于检查自动化的可行性是必需的。手工测试概念不需要任何测试工具的知识。软件测试基础之一是“不可能实现100自动化”。这使得手工测试势在必行。 自动化测试 使用一种自动化测试工具来验证各种软件测试的需求它包括测试活动的管理与实施、测试脚本的开发与执行。 自动化测试只是测试工作的一部分是对手工测试的一种补充; 自动化测试绝不能代替手工测试;多数情况下手工测试和自动化测试应该相结合以最有效的方法来完成测试任务。
3.5.7 跨地域
国际化测试本地测试国际化货币格式、语言、页面布局、时间、日期、流行的设备
