软件测试初级学习1

本文详细介绍软件测试的目的、原则与分类,覆盖从需求分析到维护的软件生命周期中的测试流程。探讨了测试用例的设计方法与重要性,以及bug的生命周期管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.什么是软件测试?

软件测试定义:使用人工和自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。或者:为了发现程序中的错误而执行程序的过程。

软件测试存在的意义:

①程序测试为了发现程序存在的代码或业务逻辑错误;

②软件测试为了检验产品是否符合用户需求(充分站在用户的角度)

③软件测试为了提高用户的体验

2.软件测试的原则

1、测试应该尽早介入。

2、所有的测试都应追溯到用户需求。

3、程序员应该避免检查自己的程序。除了单元测试。因为程序员对于自己的作品,思维具有局限性。无法保证测试质量。交给第三方或者专业测试,运用各种测试技术,利用丰富的测试经验和对BUG的敏感,去提高软件的质量。

4、设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件,特殊情况下还要制造极端状态和意外状态。

5、二八原则,测试发现的错误中80%很可能起源于20%的模块中。

6、对错误结果要进行一个确认过程(分清必现偶然)。

7、制定严格的测试计划。

8、完全测试时不可能的,测试需要终止。

9、妥善保存测试过程中所有文档。

3.软件测试的分类

按测试阶段划分:单元测试(开发的自测行为)、集成测试(多个模块共同测试)、系统测试(完整的、全面的测试)、验收测试(正式验收测试、Alpha测试开发和测试都不能参与,由用户进行测试,前期,非真实环境)、Bate测试(开发和测试都不能参与测试,由用户进行测试,后期,真实环境下测试)

按测试技术划分:白盒测试、黑盒测试(主流)、灰盒测试

按测试对象是否运行划分:动态测试、静态测试(文档检查、代码走查、界面检查)

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

按测试包含的内容划分:功能测试(等同于黑盒测试,点点点)、界面测试(不会专门做,做功能测试时会同时做这个)、安全测试、兼容性测试(ios、安卓)、易用性测试(不会专门做,做功能测试时会同时做这个)、性能测试、压力测试、负载测试、恢复测试(灾备,若出现奔溃,需要多久自我修复)

其他测试:冒烟测试(在真正测试之前,会先进行主干测试,若主干测试都无法通过,则不再进行测试)、回归测试(首先看bug是否真的修复,再次看bug修复后是否影响到与其有关的本来正常的功能)、探索性测试(测试思维)(随机测试)

4.软件生命周期(十分重要)

        软件生命周期(SDLC,System Development Life Cycle)是软件开始研制到最终被废弃不用这整个过程叫做软件生命周期,整个生命周期包括问题定义及规划、需求分析、系统设计、软件编程、软件测试、软件维护等阶段。
一、问题定义及规划(参与人员:老板、产品经理(主导)、研发经理、项目经理、需求分析师)
       主要确定软件的开发目的及其可行性。制定开发计划(软件需求说明书、原型图)。
二、需求分析/评审原型图/软件需求说明书、主持—>产品经理 其他参与:研发 设计 测试)
        在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析,明确客户的需求,输出需求规格说明书(原型图)。(关注一个问题:测试参与这个需求分析的目的是什么?产品用途,功能如何实现)
三、软件设计(属于开发的工作)
       把需求分析得到的结果转换为软件结构和数据结构,形成系统架构。
       概要设计:主要是架构的实现,指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。(数据库、表等框架性的东西)
       详细设计:对概要设计中表述(伪代码的级别)
四、软件编码(开发编码,与测试无关)

五、软件测试

       在软件设计完成后要经过严密的测试,以及发现软件在整个设计过程中存在的问题并加以纠正。测试的方法主要有白盒测试和黑盒测试两种。

   其中,开发:单元测试开发or测试:集成测试、接口测试测试人员:系统测试客户or产品经理:验收测试(α测试、β测试)

   单元测试:主要测试程序代码,为的是确保各单元模块被正确的编译,比如有具体到模块的测试,也有具体到类、函数的测试等。----一般是开发来完成。

   集成测试:单元测试后,将各单元组合成完整的体系,测试软件单位之间的接口是否正确、数据能否正常传递。----比如说注册和充值这两个功能是否能够连通。

   系统测试:把软件系统搭建起来,按照软件规格说明书所要求,测试软件其性能功能等是否和用户需求符合,在系统中运行是否存在漏洞等。-----根据测试用例,进行完整的系统测试。

六:运行维护阶段(版本上线,产品上线;版本升级;bug修复)

5.软件测试的工作流程:

接触人员:开发产品经理客服(用户反馈问题)实施/技术支持/现场实施设计师;

测试工作流程:

①需求分析:1.阅读需求/理解需求 2.整理需求 3.有疑问的地方需要讨论,弄明白为止;

②软件测试计划:一个文档,测试负责人/小组长制定计划

文档包含内容:

目的:完成测试,何时终止,达成什么样的目标;

参与人员:谁参与,成为测试小组;

任务划分:谁负责哪个功能模块的测试/用例的编写;

时间规划:什么时候写用例,什么时候测试,什么时候解释,什么时候上线

出具的文档:用例bug表单 软件测试报告;

资源的申请/准备:申请一台服务器?我要做什么类型的测试?需要准备什么样的工具? 

③测试设计阶段:写测试用例

评审(相互检查)修改:理解错误:改正;需求变更:修改,

④软件测试的执行阶段

1.测试前,进行冒烟测试,通过继续测试,不通过,打回

2.根据测试用例执行测试:发现bug提交bug管理系统;修复后,检验,再进行回归测试。

⑤评估阶段

测试完毕,出具测试报告:1.测试通过,上线; 2.测试不通过,打回,修改

6.软件生命周期模型

作为测试工程师,我们最关心的三件事:

1.测什么?(最关注的问题)2.怎么测?3.什么时候测?

测试的计划是跟开发的计划走的

学习目标:

1.什么是软件测试需求?

2.软件测试需求的必要性

3.如何对软件测试需求进行分析(重点)

功能、易用、界面、权限

4.需求分析对开发和测试的影响



3.软件测试流程
设计、执行、总结

4.常见面试笔试题

测试结束的标准是什么:系统测试缺陷报告跟踪完毕,系统测试报告通过审批。测试用例执行完毕、用例通过率>98%。不存在严重bug。

执行测试用例的时间:一般为3-6个月,起码3个月,但留给测试的可能只有7天。


软件测试用例的设计方法——四大金刚

1.等价类划分法

  1.等价类划分法的概念

       等价类划分法是一种典型的、重要的黑盒测试方法,是指某个输入域的子集合。在该子集合中,所有的输入数据对于揭露软件中的错误是等效的。

       等价划分分为有效等价类无效等价类,有效和无效是根据条件划分的。

  2.错误推测法

      输入错误的信息进行检测,看测试程序对错误情况的处理能力。

  3.边界值分析法

 1.定义:边界值分析法是对等价类划分法的一个补充,边界值一般都是从等价类的边缘值去寻找。边界值分析的基本思想:正好等于、刚刚大于、刚刚小于边界的值做为测试数据。

注意:0和负数是一个特殊值,我们在考虑边界值的时候同时也要考虑特殊值。

4.场景法(功能做好了才用)(xmind)

整个流程的描述,例如ATM取款流程

7.什么是测试用例

   测试用例(TestCast)是为项目需求而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序是否满足客户需求。

   可以总结为:每个测试点的数据设计和步骤设计。

7.1测试用例的重要性

  1.测试用例是软件测试的核心

        软件测试的重要性是毋庸置疑的,测试用例是测试工作的指导,是软件测试质量稳定的保障。影响软件测试的因素很多,如软件本身的复杂程度,开发质量,测试方法和技术的使用。但有些因素是客观存在,不可避免的,如IT团队的流动、环境、情绪等。

  2.评估测试结果的基准

       测试用例的通过率以及错误率,是测试结束的一个重要依据,用来判断该软件测试结果是否通过,能否达到上线的标准。

  3.保证测试的时候不遗漏测试功能点。可以在测试人员疲累的时候起到引导作用。

  4.在编写测试用例过程,可以熟悉需求,对系统架构或者业务流程有一个整体的、深入地了解。

  5.好的测试用例不仅方便自己和他人查看,而且能帮助设计的时候考虑的更周全,因此测试用例的写作和设计一样,很重要。指导性。

7.2测试用例的八大要素

   1.用例编号:产品名-测试阶段-测试项-xxx

   2.测试项目:对应一个功能模块(细分功能)

  3.测试标题:直接对测试点进行细化得出,输入内容+结果,同一功能模块标题不能重复(一句话说清楚测试点是什么)

  4.重要级别:高/中/低

  5.预置条件需要满足一些前提条件,否则用例无法执行(用例可写也可不写)

  6.测试输入:需要加工的输入信息,根据具体情况来设计(跟步骤结合起来一定要具有指导性意义)

  7.操作步骤:明确给出每个步骤的描述,执行人员可以根据该步骤完成执行工作。

  8.预期结果:根据与其输出比对实际记过,来判断被测对象是否符合需求。(预期结果唯一)

  9.实际结果:

7.3测试用例使用工具

excel和xmind(都要会用)


8.bug的生命周期(重点)

   8.1 bug的定义

      软件的Bug,狭义概念是指软件程序的漏洞或缺陷,广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。

       测试工程师的职责是:发现BUG,并提交给开发,让开发去修改。

  8.2 bug的类型

      要确定一个bug的类型,需要对项目(或产品)有比较深的理解。这个划分对于开发定位问题影响很小,但对问题类型的统计就比较重要了。

      常见bug类型划分(禅道系统为例,可自定义):

       代码错误 

       设计缺陷

       界面优化

       性能问题

       配置相关

       安装部署

       安全相关

       标准规范

       测试脚本

       其他

8.3bug的等级

      1,2,3,4级,1级最严重的bug;3属于正常bug。

(1)致命错误:

     1.常规操作引起的系统崩溃、死机、死循环,比如对话框输入信息造成程序崩溃;

     2.造成数据泄露的安全性问题,比如恶意攻击造成的账户私密信息的泄露;

     3.涉及金钱的方面,例如:用户余额为零,却能消费

(2)严重错误:

      1.重要功能不能实现;(比如用户无法注册)

      2.错误的波及面广,影响到其他重要功能正常实现:功能交互

      3.非常规操作导致程序的崩溃、死机、死循环等;

      4.外观难以接受的缺陷;

      5.密码明文显示(界面+数据库)。

(3)一般错误:

       不影响产品的运行、不会成为故障起因,但对产品外观和下道工序影响较大的缺陷。

        1.次要功能不能正常实现;

        2.操作界面错误(包括数据窗口内列名定义,含义不一致);

        3.查询错误,数据错误显示;(张冠李戴)

        4.简单的输入限制未放在前段进行控制;(格式限制)

        5.删除操作未给出提示;

(4)可忽略错误

       例如错别字,或测试人员觉得软件设计不美观等。

8.4bug的生命周期

     测试(发现并提交bug至管理系统中)——>指派给对应开发人员

——>开发人员先确认是否是自己的bug,若是,确认;不是,打回测试;不是bug,不予解决,因为不是bug;或延期解决。设计如此无法重现。——>对于打回的bug,测试再次确定需求,若的确是bug,则再次激活发给开发。——>对于修复后的bug,测试进行回归测试或验证测试,若已经解决,就直接关闭。若还未解决,再次打回给开发

     客服(客户反馈的问题)——>发给测试,若是bug,提交,若不是就告诉客服是客户的操作问题。

    测试需求的确定,需求的变更,和开发扯不清楚)——>产品经理





目录 一 软件测试 从零开始 5 11 引言 5 1.2 测试准备工作 5 1.2.1 向有经验的测试人员学习 5 1.2.2 阅读软件测试的相关书籍 6 1.2.3 走读缺陷跟踪库中的问题报告单 6 1.2.4 走读相关产品的历史测试用例 6 1.2.5 学习产品相关的业务知识 6 1.3 识别测试需求 7 1.3.1 主动获取需求 7 1.3.2 确认需求的优先级 8 1.3.3 加入开发小组的邮件群组 8 1.3.4 与开发人员为邻 8 1.4 测试用例设计 8 1.4.1 测试用例的基本格式 8 1.4.2 重用同类型项目的测试用例 9 1.4.3 利用已有的软件 Checklist 9 1.4.4 加强测试用例的评审 10 1.4.5 定义测试用例的执行顺序 10 1.5 测试用例执行 10 1.5.1 搭建软件测试环境,执行测试用例 10 1.5.2 测试执行过程应注意的问题 11 1.5.3 及时更新测试用例 11 1.5.4 提交一份优秀的问题报告单 12 1.6 测试结果分析 12 1.7 总结 13 二 软件测试的常识 13 2.1 引言 13 2.2 软件测试常识 13 2.2.1 测试是不完全的(测试不完全) 13 2.2.2 测试具有免疫性(软件缺陷免疫性) 14 2.2.3 测试是 “ 泛型概念 ” (全程测试) 14 2.2.4 80-20 原则 14 2.2.5 为效益而测试 15 2.2.6 缺陷的必然性 15 2.2.7 软件测试必须有预期结果 15 2.2.8 软件测试的意义 - 事后分析 15 2.2.9 结论: 15 三 浅谈软件开发中的注意事项 16 3.1 项目设计 16 3.2 设计变化和需求变化 16 3.3 代码编写 17 3.3.1 源程序文件结构 17 3.3.2 界面设计风格的一致性 17 3.3.3 编辑风格 17 3.3.4 命名规范 18 3.4 BUG修补 18 3.5 开发人员的测试 18 四 软件测试的若干问题 19 4.1 前言 19 4.2 博弈的各方 19 4.3 测试的过程 20 4.4 测试所具备的素质 20 4.5 自动化测试 20 4.6 测试的误区 21 五 浅谈功能测试用例模板设计 21 5.1 Excel 模版 21 5.2 测试用例状态转换分析 23 六 如何提高软件质量 23 6.1 什么是质量 24 6.2 流程对质量的贡献 25 6.3 流程与技术 27 6.4 全面质量管理 28 6.5 关注测试 29 6.6 成功的铁三角 30 6.7 国际上流行的质量标准 30 6.8 如何起步 32 七 ISO和CMM,我们该选择谁 32 7.1 管理水平的适用性 33 7.2 复杂度的适用性 33 7.2.1何谓研发过程复杂度 34 7.2.2 何谓组织机构复杂度 34 7.3 量化管理的适用性上 35 7.4 结论 36 八 如何做好单元测试 36 8.1 前言 36 8.2 组织结构应该保证测试组参与单元测试 36 8.3 加强单元测试流程规范性 37 8.3.1 制订单元测试的过程定义 37 8.3.2 单元测试工作产品必须纳入配置管理 38 8.3.3 必须制订覆盖率指标和质量目标来指导和验收单元测试 38 8.3.4 加强详细设计文档评审 39 8.4 单元测试者技能的提高 39 8.4.1 加强对单元测试人员的技能培训 39 8.4.2 必须引入工具进行辅助 40 8.4.3 单元测试者加强对被测软件的全面了解 40 8.5 结尾 40 九 漫谈人机界面测试 41 9.1 一致性测试 41 9.2 信息反馈测试 42 9.3 界面简洁性测试 42 9.4 界面美观度测试 42 9.5 用户动作性测试 43 9.6 行业标准测试 43 9.7 小结 44 十 基于Web的系统测试方法 44 10.1 功能测试 45 10.11 链接测试 45 10.1.2 表单测试 45 10.1.3 Cookies测试 45 10.1.4 设计语言测试 45 10.1.5 数据库测试 46 10.2 性能测试 46 10.2.1 连接速度测试 46 10.2.2 负载测试 46 10.2.3 压力测试 46 10.3 可用性测试 47 10.3.1 导航测试 47 10.3.2 图形测试 47 10.3.3 内容测试 47 10.3.4 整体界面测试 47 10.4 客户端兼容性测试 48 10.4.1 平台测试 48 10.4.2 浏览器测试 48 10.5 安全性测试 48 10.6 总结 49 十一 为盈利而测试 49 111 引言 49 11.2 什么是软件测试 50 11.3 六个误区 50 11.3.1 误区一:忽视对正常输入的测试 50 11.3.2 误区二:忽视设计阶段的参与与评估 50 11.3.3 误区三:忽视测试计划与测试文档的建立及维护 51 11.3.4 误区四:忽视缺陷的分析,报告及跟踪 51 11.3.5 误区五:错误的测试目标及测试终止条件 51 11.3.6 误区六:不懂得合理调配使用测试人员的知识技能结构 51 11.4 软件质量与软件测试 52 11.5 软件测试的经济目的 54 11.5.1 满足用户需求,提高产品的竞争力,最终提高产品的销售量 54 11.5.2 尽早发现缺陷,降低后继质量成本 54 11.6 何时应当停止测试 56 十二 整体性能测试剖析 57 十三 性能测试工具之研究 62 13.1 性能测试的意义 62 13.2 性能测试工具综述 63 13.3 性能测试工具的体系架构 64 13.4 虚拟用户产生器 Vugen 65 13.5 Proxy 二次捕获的问题 67 13.6 关联的问题 68 13.7 脚本的问题 70 13.8 Conductor 和 Player 部分 71 13.9 Conductor 和 Player 的技术要点 72 13.10 数据分析工具 Analysis 72 13.11 结束语 72 十四 性能测试原理及性能测试实例分析 73 14.1 软件测试中的性能测试 73 14.11 性能测试的含义 73 14.1.2 性能测试的分解 73 14.2 一个性能测试实例 74 14.2.1 被测系统 74 14.2.2 对被测系统进行性能测试 75 14.5 总结 80 十五 软件GUI测试中的关注点 80 15.1 不能不说的二个问题 81 15.11 软件测试中的“二八”原则 81 15.1.2 软件黑盒测试解决的问题 81 15.2 软件黑盒测试常见错误类型及说明 81 15.2.1 用户界面错误 81 15.2.2 功能性 81 15.2.3 人机交互 82 15.3 命令结构和录入 87 15.3.1 不一致性 87 15.3.2 “最优化” 87 15.3.3 菜单 89 15.4 遗漏的命令 90 15.4.1 状态转换 90 15.4.2 危机预防 90 15.4.3 由用户进行的错误处理 91 15.4.4 其他问题 91 15.5 程序僵化 92 15.5.1 用户可调整性 92 15.5.2 控制方式 93 15.6 性能 94 15.6.1 降低程序速度 94 15.6.2 缓慢回应 94 15.6.3 如何减少用户吞吐量 94 15.6.4 反应拙劣 94 15.6.5 没有提前输入 95 15.6.6 没有给出某个操作会花很长时间的警告 95 15.6.7 程序太多提示和询问 95 15.6.8 尽量使用简单命令和提示 95 15.7 输出 95 15.7.1 不能输出某种数据 95 15.7.2 不能重定向输出 95 15.7.3 与一个后续过程不兼容的格式 96 15.7.4 必须输出的很少或很多 96 15.7.5 不能控制输出布局 96 15.7.6 荒谬的精度输出级别 96 15.7.7 不能控制表或图的标记 96 15.7.8 不能控制图形的缩放比例 96 15.8 错误处理 96 15.8.1 错误预防 96 15.8.2 错误检测 97 15.8.3 错误恢复 98 15.8.4 边界相关的错误 99 15.8.5 计算错误 100 15.9 小结 100 十六 软件测试技术 100 16.1 软件测试基础 101 16.1.1 测试目标 101 16.1.2 测试原则 101 16.1.3 可测试性 102 16.2 测试用例设计 104 16.3 白盒测试 104 16.4 基本路径测试 105 16.4.1 流图符号 105 16.4.2 环形复杂性 106 16.4.3 导出测试用例 106 16.4.4 图矩阵 108 16.5 控制结构测试 108 16.5.1 条件测试 108 16.5.2 数据流测试 110 16.5.3 循环测试 111 16.6 黑盒测试 112
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小白的程序空间

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值