知方号

知方号

软件测试<软件测试报告500字>

软件测试

一、测试理论基础 1.软件的定义

软件:是计算机程序、程序所用的数据以及有关文档资料的集合 软件分为 系统软件 和 应用软件 系统软件:是生成、准备和执行其他程序所需要的一组文件和程序,比如:操作系统 应用软件:计算机用户为解决某些具体问题而购买的、开发或研制的各种程序或软件包,比如APP

2.应用架构

C/S架构:必须安装一个客户端才能使用的软件(client-server)       缺点:每次更新,必须更新服务端和客户端B/S架构:只需要一个浏览器,就可以访问的服务(browser-server)

3.什么是软件测试

软件测试: 使用人工和自动手段来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别;

测试目的:         (1).发现程序(软件)存在的代码或者业务逻辑错误 (2).检验产品是否符合用户需求 (3).提高用户体验

以最小的人力、物力和时间,找到软件中潜在的错误和缺陷。

4. 测试的分类 *

 (1).按测试技术划分:黑盒测试、白盒测试、灰盒测试

黑盒测试 黑盒测试:也称功能测试或数据驱动测试,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。黑盒测试方法:等价类划分法;边界值分析法;因果图法;场景法;正交实验设计法;判定表驱动分析法;错误推测法;功能图分析法。白盒测试 白盒测试:也称为结构测试或逻辑驱动测试,白盒测试法检查程序内部逻辑结构,对所有的逻辑路径进行测试,是一种穷举路径的测试方法。白盒测试原则: (1)保证一个模块中的所有独立路径至少被测试一次;(2)所有逻辑值均需要测试真(true)和 假(false)两种情况;(3)检查程序的内部数据结构,保证其结构的有效性;(4)在上下边界及可操作范围内运行所有循环。白盒测试方法: 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。灰盒测试 大概知道代码逻辑实现,不需要看懂所有的代码

(2).按测试对象是否运行划分:动态测试、静态测试

静态测试 不用运行程序的测试,包括代码检查、静态结构分析、代码质量度量、文档测试等等,它可以由人工进行,充分发挥人的逻辑思维优势,也可以借助软件工具(Fxcop)自动进行。动态测试 需要执行代码,通过运行程序找到问题,包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。

(3).按不同的测试手段划分:手工测试、自动化测试

手工测试 点工自动化测试 工具+代码

(4).按测试包含内容划分:功能测试、界面测试、安全测试、兼容性测试、易用性测试、性能测试

功能测试 测试软件的功能是否符合需求,通常采用黑盒测试方法,一般由测试人员独立执行。界面测试 也称UI测试,测试用户界面布局是否合理,整体风格是否一致,界面文字是否正确,命名是否统一,页面是否美观,文字、图片组合是否完美等。安全性测试 验证应用程序的安全等级和识别潜在安全缺陷的过程。目的是为了查找软件自身程序设计中存在的安全隐患,并检查应用程序对非法侵入的防范能力(登录、防攻击、sql注入)兼容性测试 兼容性测试是指检查被测软件在不同的硬件平台上、不同的应用软件之间、不同的操作系统中、不同的网络环境中是否可以正常运行的一种测试。易用性测试 这种测试方法,不是去测试软件能不能用,而是去测试软件好不好用,用户学习成本高,所以主观性比较强烈。一般要根据多个用户的测试反馈信息,才能评价易用性到底好不好。(人性化、舒适、是否符合用户使用习惯、比较主观)性能测试 一般性能测试:相应速度,对资源(CPU/内存)的利用压力测试:高负载的情况下进行的,目的不是为了获取性能指标,而是想要了解系统是否稳定。负载测试:通过不断调试并发数获取性能瓶颈。(极限)强度测试:为了确定系统在最差工作环境的工作能力,或用于验证在标准工作压力下的各种资源的最下限指标。

(5).按测试阶段划分:单元测试、集成测试、系统测试、验收测试(α测试、β测)

单元测试 完成最小的软件设计单元(模块、类、函数、方法)的验证工作,目标是确保模块被正确的编码,使用过程设计描述作为指南,对重要的控制路径进行测试以发现模块内的错误,通常情况下是白盒测试,对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试,及早的发现和解决不易显现的错误。集成测试 通过测试发现与模块接口有关的问题(模块与模块之间的调用)。目标是把通过了单元测试的模块拿来,构造一个在设计中所描述的程序结构,应当避免一次性的集成,而采用增量集成。(接口测试)系统测试 是基于系统整体需求说明书的黑盒类测试,应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试,目的是验证系统是否满足了需求规格的定义,找出与需求规格不相符合或与之矛盾的地方。验收测试 是一项确定产品是否能够满足合同或用户所规定需求的测试。验收测试包括α测试、β测试、γ测试。α测试 是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品进行测试,试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。(内测版本,bug多)β测试 是由软件的多个用户在实际使用环境下进行的测试,这些用户返回有关错误信息给开发者。一般只提供给特定的用户群来测试使用。(公测版本)γ测试 此时产品已经相当成熟,只需在个别地方再做进一步的优化处理即可上市发行。(候选发布版本)

其他测试:回归测试、冒烟测试、探索性测试/自由测试

回归测试 回归测试是指在代码发生修改之后重新测试先前的测试用例以保证修改的正确性。冒烟测试 指针对最基本的功能或最主要的业务流程(核心功能)进行测试。比如电商购物流程:注册、登录、选商品、加入购物车、支付、订单管理。探索性测试 是敏捷世界里的一种重要测试方法,作为一个研究性的工具,它是用户故事测试和自动化回归集的重要补充。(靠经验、积累、测试思维) 5.测试的原则 1.证明软件中存在缺陷2.不能穷尽测试3.测试应用尽早介入4.28原则5.不存在缺陷谬论6妥善保存一切文档 6.测试的流程 (1).需求分析 阅读需求文档,熟悉项目;参与需求评审(2).制定测试计划和测试方案 测试计划:测试整个项目的总体规划,比如:测试范围,进度安排,人力物力安排,整体的测试策略,风险评估,风险规避..测试方案:被测目标,测试工具选取,测试方法,测试重点 遵循 5W 1H 原则:why when who what where how(3).设计测试用例 常用测试方法:等价类,边界值,场景法...(4).测试用例评审 参与人员一般有:产品经理,开发,测试(5).执行测试用例

开发完成后,开始执行测试用例,发现Bug,提交给开发人员,开发人员修复完成后,重新指派给测试人员,测试人员开始回归测试,通过就关闭,没有通过就继续修复Bug;

(6).编写测试报告

对测试情况做个总结(发现了多少bug,修复了多少bug,还有哪些没修复...)

软件测试的生成周期:需求分析 --> 制定测试计划 --> 设计测试用例 --> 测试用例评审 --> 执行测试用例 --> 编写测试报告

软件的生命周期:是软件开始研制到最终被废弃不用所经历的各个阶段。

计划阶段 --> 需求分析 --> 设计阶段 --> 编码 --> 测试 --> 运行与维护

7.软件开发模型

       开发模型(软件生命周期模型):是指软件从开始研制到最终被废弃所经历的各个阶段。在不同的阶段里, 由不同的组织和人员执行不同的任务。 软件测试与软件的开发模式有着紧密的联系,作为一名测试人员,应该充分理解软件的开发模型,以便找 准自己在其中的位置,从而发挥自身的价值。

7.1 瀑布模型 *

特点: 线性模型,在所有的开发模型中占有重要地位,是其他模型的基础 以文档驱动,每个              阶段执行一次,按线性顺序进行软件开发。优点:开发的各个阶段比较清晰 当前阶段完成后,只关注后续阶段缺点:依赖于在其的需求分析,不适应需求的变化,风险往往在后期显露,失去及早纠错的               机会;典型应用场景:需求清晰的大型项目,如:银行、保险、建筑等;

7.2 增量模型

       把瀑布模型的顺序特征与快速原型法的迭代特征相结合,将软件看作一系列相互联系的增量,在开发过程的各次迭代中,每次完成其中的一个增量。

7.3 快速模型

        

特点:快速模型是快速建立起来的可以在计算机上运行的程序;

7.4 螺旋开发模型

7.5 迭代开发模型

7.6 敏捷开发模型

  8.软件测试模型

       在软件测试的实施中,针对于测试过程出现的问题,通过经验总结得到测试过程模型,旨在提高软件开发测试 过程中的效率与效果。

8.1 V模型

优点: 展示测试由底层(代码)到高层(用户业务)按阶段测试的实现过程缺点: 不适用于需求变化,灵活性差

8.2 W模型 

      W模型,简称“双V”模型,即以开发主导的一个“V”,和以测试主导的另一个“V” - 为了克服V模型的缺点,引入了W模型。

优点:测试伴随整个产品开发周期,测试对象不仅是程序还有需求、设计文档 测试介入较早,及早发现问题,降低修复成本缺点:实施起来比较复杂,难度大,对于需求阶段和设计阶段的测试设计要求较高(计算机技术、业务知 识、管理能力、测试素质等) 9.软件质量模型

9.1 软件质量

   软件质量, 就是软件与明确地和隐含地定义得需求相一致得程度。

9.2 质量模型标准

   对于测试作用:提供测试设计的不同角度和思路

ISO/IEC 25010

功能性:满足某种功能需求的一种属性或能力性能效率:在规定条件下,相对应所用资源的数量,软件产品提供适当性能的能力兼容性:在一定条件下兼容其他软硬件产品的能力易用性:在指定使用条件下,产品被理解、学习、使用和吸引用户的能力可靠性:产品在规定条件下,在规定的时间内完成规定功能的能力信息安全性:信息在传输或者存储过程的安全程度可维护性:(四规),在规定条件下,规定的时间内,使用规定的工具或方法修复规定功能的能力可移植性:从一种环境迁移到另一种环境的能力 10.测试用例

10.1 生活中的测试用例

      比如:购买一台电脑或者手机,如何验证其是否满足自己的需求?

      是否能够正常的开关机 、运行速度是否快、屏幕大小是否适合、存储空间是否满足要求 ......

      例如:购买手机是否满足其中两个目标  

10.2 测试用例的定义

测试用例又叫 test case,是为了某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定的需求。(验证产品功能实现是否满足用户需求)

10.3 测试用例的八大要素 *

用例编号:表示用例的唯一性,有时也叫用例ID,由字符和数字组合成的字符串用例标题:表示要测试或验证的目的,对测试用例的简单描述,用概括的语言描述该测试用例的测试点(如何测试+测试内容)测试项目:当前测试的功能所属范围用例级别:表示用例测试功能的重要程度或者影响力 高级别:保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例中级别:重要程度介于高和低之间的测试用例低级别:实际使用的频率不高,对系统业务功能影响不大的模块或功能的测试用例预置条件:验证该功能需要的前提条件输入数据:必要的输入数据执行步骤:验证该功能需要的先后操作步骤预期结果:希望得到的结果其他要素

用例的设计者

用例设计日期

对应的开发人员:出现Bug后能及时找到相应的开发人员进行修复

测试结果:执行测试用例后的实际结果,包括:pass、fail、block

测试类型

测试模板:

10.4 测试用例设计原则

明确性 测试人员要尽量避免测试用例存在含糊的因素,在测试过程中,测试用例的测试结果是唯一的。代表性 尽量将具有相似功能的测试用例抽象合并,功能相似的用例要合并。简洁性 测试用例简洁,可读性良好,测试过程目的明确,测试结果唯一。

10.5 测试用例的编写流程

需求分析 --> 提取测试点 --> 测试用例设计 --> 测试用例评审 --> 修改测试用例 二、测试用例设计方法 1.等价类划分法 * 定义 等价类划分法将所有可能输入的数据,即程序的输入域,划分为若干部分,然后从每一部分中选取少数有代表性的数据作为测试用例。使用等价类划分方法设计测试用例需要经历划分等价类和选取测试用例两步,他将不能穷举的测试过程进行合理分类,从而保证设计出来的测试用例具有完整性和代表性。作用 从穷举测试中解放出来,找到具有共同特性的测试输入子集。类型划分 有效等价类 对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。(满足需求)无效等价类 对于程序的规格说明来说是不合理的、无意义的输入数据构成的集合。(不满足需求)基本步骤 1.需求分析2.划分等价类 有效等价类无效等价类 规则(需求本身)长度类型是否为空(必填项)是否重复3.设计测试用例 尽可能多的覆盖尚未覆盖的有效等价类仅覆盖一个尚未覆盖的无效等价类 应用场景 针对需要数据量大,有测试数据输入的地方 典型代表:页面级的 输入框 类测试 案例 案例1:验证QQ账号的合法性案例2:验证某城市电话号码正确性

案例3:新浪邮箱登录

案例1:验证QQ账号的合法性,要求 6-10 位 自然数

案例2:验证某城市电话号码正确性

区号:非空或者是三位数字 前缀码:非“0”且非“1”开头的三位数字 后缀码:四位数字

案例3:新浪邮箱登录

要求输入(邮箱名)@sina.cn 和 (密码)

邮箱名:4-16 位 字符,支持英文、数字、下划线(不能全是数字或者下划线)

密码:6-18 位 字符

2.边界值分析法 * 定义 边界值法是对输入或输出边界值进行测试,通常作为等价类划分法的补充。因为大量错误是发生在输入或输出范围的边界上,而不是输入范围的内部。基于边界值【有效等价类和无效等价类的分界点】设计测试用例的一种【黑盒】方法原则 确定边界:应该选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据两点法  三点法  四点法次边界值:IP地址(0-255)时间格式(0-23)...(常识)特殊边界值:0,负数,空值,空格边界值 上点:边界之上的点 内点:边界之内的点 离点:离边界最近的左右两点

    

 两位数加法器:

边界范围取值优化 

 

                         

结论: 7个点 优化为 5个点 上点:必选(不考虑区间开闭) 内点:必选(建议选择中间范围) 离点:开内闭外(考虑开闭区间, 开区间 选择 内部离点 , 闭区间 选择 外部离点 ) 设计测试用例步骤 需求分析 划分等价类 确定边界 上点 内点 离点 设计测试用例应用场景 存在边界  >  >=  b.txt 案例 案例1:字符属性设置程序 案例2:用户筛选按钮

案例1:字符属性设置程序

窗体中有多个控件(字体、字符样式、颜色、字号),每个控件有多个取值 字体:仿宋、楷体、华文彩云 字符样式:粗体、斜体、下划线 颜色:红色、绿色、蓝色 字号:20号、30号、40号

问题:共有 3^4=81 种 组合,此时不可能一一列举出来

解决方案:使用 正交表  或  allpairs 工具

第一种:使用 正交表

第二种:使用 allpairs 工具

第一步:将数据填到excel表格中

第二步:将表格中的内容(包括表头)粘贴到txt文本中(比如a.txt)

第三步:通过allpairs命令,生成测试用例

第四步:核对结果,生成的 b.txt 内容如下

案例2:用户筛选按钮

假设有一个用户筛选功能,有3个输入分别是体型、年龄段、性别, 体型有3个取值:胖、适中、瘦; 年龄段有3个取值:老人、青年、儿童; 性别有2个取值:男,女;

6.场景法 * 定义 通过场景描述的业务流程(业务逻辑),也包括代码的实现逻辑,设计用例来遍历场景(路径),验证软件系统功能的正确性。主要用于冒烟测试。 场景法就是模拟 用户操作软件 时的场景,主要用于测试 多个功能之间的组合使用情况 。 场景法,也可以叫流程图法,是用流程图描述用户的使用场景,然后通过覆盖流程路径来设计测试用例。 意义 用户使用角度:用户平时使用的不是单个功能,而是多个功能组合起来进行使用 测试人员角度:平时测试的都是单个功能点进行测试,容易忽略多个功能的组合测试

使用阶段

集成测试 系统测试 验收测试使用场景 对于多个功能之间的组合逻辑测试,可以使用场景法。基本步骤 1.需求分析 2.绘制流程图 矩形:表示步骤,比如操作、输入、输出结果菱形:表示判断条件箭头:表示流向 3.遍历场景,提取测试用例(一条流程路径就是一条测试用例) 覆盖正常的路径覆盖分支路径 流程图常用符号                 绘制流程图 第1步:确认场景中关键业务步骤 第2步:确定业务之间的先后顺序 第3步:用箭头连接即可 绘制工具 Microsoft Visio Visio的安装 以管理员身份运行 Visio2003_SP3.exe 默认安装即可,中间不需要修改或填写任何内容 案例 案例1:ATM 取款 案例2:电商购物流程 案例1:ATM 取款

7.错误推断法 定义 基于经验和直觉推测程序中所有可能存在的各种错误从而有针对性的设计测试用例的 方法。(比较主观) 设计思想 凭人们对过去所作测试结果的分析,列举出可能出现问题清单,根据清单测试来发现缺陷 适用场景 重要功能 使用同类型产品 任务急、时间紧、资源少

测试用例方法设计总结

具有输入功能,但输入之间没有组合关系     【等价类】 输入有边界 如长度、类型                             【边界值】 多输入、多输出、输入与输入之间存在组合关系、输入与输出之间存在依赖或制约关系                                                                     【判定表、因果图】 用最少的测试用例获得最大测试覆盖率时    【正交法】 多个功能的组合测试                                    【场景法、流程图】 最后推荐使用【错误推测法】来进一步补充测试用例

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至lizi9903@foxmail.com举报,一经查实,本站将立刻删除。