软件测试理论
●1.软件生命周期
●有三种生命周期(记住任意一种!):
●1. 6个阶段:计划->需求分析->设计->编码->测试->运维
●2. 7个阶段:计划->需求分析->设计->编码->测试->运维-评价
●3. 8个阶段:问题定义->可行性分析->需求分析->概要设计->详细设计->编码和单元测试->系统测试->运维
●软件定义时期
●问题定义
●可行性分析 =(计划)
●考虑以下内容:
●1.开发的总目标;
●2.软件功能/性能/可靠性/接口等方面的设想;
●3.开发进度、投入成本、产出收益、所需资源等问题。
●输出结果为:立项
●软件开发时期
●需求分析
●产品经理(PRD)OR 需求工程师OR策划
●需求来源:市场调研(自主研发) 和用户 (客户定制)
●输出结果为:《需求规格说明书》=SRS
●概要设计
●设计是软件工程的核心,概要设计为HLD,把需求转化为具体可实现的架构。
●输出为:《概要设计说明书》
●详细设计
●详细设计是LLD,对具体实现的模块进行设计。
●输出为:《详细设计说明书》
●编码和单元测试
●使用不同的编程语言(JAVA、Python、C、C++、PHP等),实现软件具体功能。
●输出为:源代码
●系统测试
●测试软件是否符合需求,划分4个测试阶段:单元测试、集成测试、系统测试、验收测试。
●软件维护时期
●运行维护
●软件修复BUG、软件新增需求、软件优化性能、提升用户体验等情况所进行的更新和维护。
●(隐性,不希望)下线关闭
●2.开发模型(开发流程)
●瀑布模型
●就是生命周期模型,线性化,从上之下一次性执行。适用于需求明确的项目。(质量高、不支持需求变更)
●适用于:需求明确、二次开发的项目
●优点:自顶向下,顺序性通过,按阶段划分进行检查,软件质量较好。
●缺点:文档多,维护麻烦,缺乏灵活性,返回上一级开发代价大,不支持需求变更。
●
●原型模型
●也称为快速原型模型,在构建的基本框架之上进行二次开发。
●适用于:需求模糊、用户不清楚需求的项目
●优点:关注用户需求,减少需求不明确带来的开发风险。
●缺点:软件边做边改,可能质量低下,原型的开发语言不一定适应当前的开发环境。
●
●增量模型-渐增模型
●基于瀑布模型,增加了需求的变更迭代。
●适用于:需求不断变化的项目
●优点:人员分配灵活,可短时间内交付
●缺点:需开放式体系结构,后加入的构建不能破坏之前的结构。容易四不像。
●
●螺旋模型
●分为四个象限,加入了风险分析,保证软件质量及需求变更。(既支持需求变更也保证软件质量,但成本高)
●适用于:需求变化的大型且复杂的项目
●优点:1.制定计划 2.风险分析 3.实施工程 4.客户评估。 先设计评估再开发,并保证符合用户需求,提高开发效率和软件质量
●缺点:风险分析不到位时,项目风险较大。建设周期长,成本较高。
●
●敏捷开发模型
●以设计-开发-交付的方式,快速的迭代,输出高质量的软件。(时间短、周期快,频繁交付高质量软件)但是对技术人员要求高。
●适用于:所有项目
●优点:注重沟通,可及时响应需求变更,研发周期快,版本质量高、时间周期短。
●缺点:不注重文档的维护,对人员技术要求高,经验丰富,项目人员流动时,风险大。
●
●3.测试模型(测试流程)
●V模型
●内容: 需求分析—概要设计—详细设计—软件编码—单元测试—集成测试—系统测试—验收测试
●优点:自顶向下,顺序性对应,体现了设计与开发与测试之间的关系。
●缺点:把测试阶段置于开发之后的阶段,不利于尽早的发现BUG。
●
●W模型
●内容:需求分析—概要设计—详细设计—软件编码—单元测试—集成测试—系统测试—验收测试
● 需求测试—概要设计测试—详细设计测试— 集成 — 实施 —交付
●优点:尽可能早的执行测试,增加了针对前期文档的测试,发现前期阶段的问题。
●缺陷:不支持需求迭代,返回上一级代价高。
●
●X模型
●内容:单独的设计开发,频繁进行软件集成,再加上探索性测试。
●优点:支持需求不断变化,并且加入探索性测试,便于发现测试计划之外,更多的缺陷。
●
●H模型(敏捷测试的思想)
●强调软件测试活动是独立的!不依附任何流程,只要测试准备点就绪,就可开展测试。
●
●敏捷测试模型
●对测试人员要求高,重沟通表达(会议),对自动化测试有一定的要求,能独立负责测试流程(计划、方案、执行等)
●4.软件测试流程
●1.立项
●
●2.设计测试总计划,编写测试方案及测试用例
●
●3.单元测试阶段
●
●4.集成测试阶段
●
●5.系统测试阶段
●5.1功能测试
●
●5.2性能测试
●
●6.验收测试阶段
●
●7.运行维护
●5.在做项目时,工作流程如下:
●绿色表示为:会议 蓝色标识为:技术文档
●
●6.测试阶段
●单元测试
●概念:验证软件模块的源代码正确性。
●测试依据:《详细设计说明书》
●测试策略:白盒测试
●测试方法:语句覆盖/判定覆盖/条件覆盖/判定条件覆盖/路径覆盖
●测试人员:开发、研发自测
●集成测试
●概念:也称作:组装测试。验证软件模块之间的组装和调用,接口的测试。
●测试依据:《概要设计说明书》
●测试策略:灰盒测试
●测试方法:增式集成法(先1个模块的测,然后增加1个模块,N+1)、非增式集成法(先单独测试每个模块,然后直接组装测试)
●测试人员:测试工程师(接口和自动化测试)
●(确认测试)
●概念:验证集成的软件是否符合需求规格。
●测试依据:《需求规格说明书》
●测试策略:冒烟测试
●测试人员:测试工程师
●适用于软件各个阶段的每个版本。
●系统测试
●概念:验证软件本身及软件所运行的环境进行测试,包含功能测试、性能测试等。
●测试依据:《需求规格说明书》
●测试策略:黑盒测试
●测试方法:安装测试、配置测试、兼容性测试、界面测试、安全性测试、网络测试、异常测试、文档测试、备份测试等。(功能、性能测试方法+质量6大特性)
●测试人员:测试工程师
●验收测试
●概念:由客户方进行验收,抽查软件是否符合需求,验收通过则部署软件。
●测试依据:《需求规格说明书》+用户的实际需求
●测试策略:随机测试
●测试方法:alpha测试和beta测试
●alpha测试:又称实验室测试,内测,A测试。由测试人员和开发人员在场,受限的环境,邀请用户执行测试,并提交BUG。
●beta测试:又称为外场测试,公测,B测试。把软件直接放到网络环境中,未知的用户群体参与执行测试。
●测试人员:客户方,用户
●7.测试策略
●按照是否测试源代码角度:(重点+常用)
●黑盒测试
●白盒测试
●灰盒测试
●按照软件系统角度划分:(重点+常用)
●功能测试
●性能测试
●按照是否运行软件角度划分:
●静态测试
●动态测试
●按照是否使用工具角度划分:
●手动测试
●自动化测试
●按照测试活动角度划分:(重点+常用)
●冒烟测试
●全面测试
●回归测试
●随机测试
●8.测试用例
●根据测试方案中所设计的方法,编写项目的测试用例。
●编写用例的工具:禅道、CQ、TestLink。
●用例组成要素
●1.用例编号
●规则:项目名_测试阶段_模块名_子模块名_序号
●注意事项:由整体到局部,由大到小输出。使用英文或英文简写。
●2.测试项目(模块)
●指代:测试模块名或子模块名(测试子项)
●3.用例标题
●一句话概述测试点(测试步骤+预期结果)。
●建议输入方式为:测试点,预期结果。
●举例:当验证码超过60S时,注册失败。
●4.重要级别
●高、中、低
●可通过软件基本功能,或者使用频率来判定。
●回归测试时,会根据重要级别进行筛选用例。
●5.预置条件
●1.执行测试前,所需的测试环境。
●网络正常,测试样机A、B已到位。
●2.可预置其他用例,或者数据。
●如测试登录,可预置注册成功的用例。或者直接内置,已存在用户XX,密码XX。
●6.测试输入
●包含:输入的数据,文件、图片等。
●需构造具体输入的数据,如:用户名为:中国_1!
●7.操作步骤
●从主界面进入XX功能界面,再写到软件功能点。(路径)
●当前测试点,所必经的每一个步骤都单独输出。
●一个操作步骤,都对应一个预期结果。
●建议:先写如何进入XX模块的路径,在写XX模块的全部有效等价类覆盖。
●8.预期结果
●每个步骤应输出的结果为XX。给出结果,和后续的动作。
●举例:登录成功,跳转至网站首页。
●9.实测结果(执行测试时,很重要)
●PASS、FAIL、NG 也可写作:通过、未通过、阻塞
●10.测试人员(执行测试时,很重要)
●测试人员就是用例执行人员,不是写用例的人。任何人都可以执行写好的用例。
●11.测试日期(执行测试时,很重要)
●执行测试的当天日期
●12.用例作者
●用例编写人,需要负责所写用例的质量。
●13.创建日期
●写用例的日期时间
●14.修改日期
●维护用例的日期时间
●15.用例类型
●常见类型有:功能、性能、界面、安全、兼容性等等。
●16.是否自动化
●是否用于自动化。
●用例的分类
●1.可分为大粒度用例和小粒度用例
●大粒度用例,就是一条用例中,包含多种测试情况 。写出测试点,就输出测试结果。
●小粒度用例,就是一条用例中,只包含一种测试情况。写出详细操作步骤及结果。
●2.用例可分为:
●2.1 全功能用例库
●2.2 通用用例
●2.3 冒烟用例(筛选主要功能-高级别用例)
●2.4 专项用例
●用例设计方法
●等价类划分法
●概念:针对输入域,输入框进行设计,把无穷的测试划分为有限的测试。
●设计步骤:
●1.找到输入条件:如用户名、密码、确认密码等等
●2.划分等价类,划分有效等价类(符合需求的)和无效等价类(不符合需求的);
●3.建立等价类表 (包含:输入条件、有效等价类、无效等价类);
●4.给所有的等价类进行编号,编号是唯一的,目的是为了组合覆盖;
●5.进行组合覆盖等价类,覆盖原则:
●尽可能多的覆盖所有的有效等价类,(所有有效的先写为一条,再进行单个覆盖、两两组合覆盖、三三组合覆盖…)
●有且只覆盖一个无效等价类(每种错误情况,各自写一条无效的用例)
●6.构造测试输入,测试数据,转化为正式的测试用例。(包含:用例标题、操作步骤、预期结果…)
●边界值分析法
●概念:针对边界情况,进行划分,发现错误的能力最强,也最容易出错。也是等价类划分的补充。
●包含:软件的长度边界、内容边界、大小边界、高低边界、上下左右前后、温度、容量等等。
●一般边界值:(长度的有效类)5个值。(3个值)
●取值:最小值、最小值+1、中间值、最大值-1、最大值
●举例:用户名长度为:5-10,密码长度为10-20
●公式:4N+1 (N代表有几个条件)
●最坏情况所有用例的覆盖总数为:5^N次方
●健壮性边界值:(加上长度的两个无效等价类)7个值。(5个值,4个值)
●取值:最小值-1、最小值、最小值+1、中间值、最大值-1、最大值、最大值+1
●公式:6N+1 (N代表有几个条件)
●最坏情况所有用例的覆盖总数为:7^N次方
●补充:常用边界值取值为,健壮性取5个值:越界两个值、边界两个值、中间值。(最小值-1、最小值、中间值、最大值、最大值+1)
●等价类+边界值结合设计用例
●等价边界表=输入条件+有效等价类+一般边界值+无效等价类+健壮性边界值
●覆盖所有的有效等价类,及单个覆盖每条无效等价类。
●设计步骤:
●1.(先使用等价类划分法)找出所有的输入条件;
●2.针对每个条件,分别划分有效等价类和无效等价类;
●3.建立等价类表,把等价类进行唯一的编号;
●4.(再使用边界值分析法)找出等价类中,所有的边界(长度边界);
●5.在等价类表中,插入2列:一般边界值(在有效等价类旁)和健壮性边界值(无效等价类旁)的列;
●6.写出所有的长度边界并编号,一般边界值:最小值、中间值、最大值;健壮性边界值:最小值-1、最大值+1;
●7.(等价类+边界值组合覆盖)先覆盖所有条件的有效等价类,写一条成功的用例。
●8.在覆盖单个条件的有效等价类,(有效等价类=长度类和内容类)
●测试长度时,默认内容是有效的。测试内容时,默认长度是中间值。
●先覆盖单个的长度
●(如:用户名为1位时,注册成功 测试输入,用户名为:Q)
●用户名为2位时,注册成功 测试输入,用户名为:哈
●用户名为14位时,注册成功 测试输入,用户名为:wyeiuwqyeuaewpz
●用户名为7位中文时,注册成功 测试输入,用户名为:等价类可厉害了
●再覆盖单个的内容,
●用户名为纯英文时,注册成功 测试输入,用户名为:HelloWord
●纯中文、纯下划线、
●内容两两组合;
●用户名为:中英文、中文+数字、中文+下划线、英文+数字、英文+下划线。。。。。。
●内容三三组合:
●用户名为:中英数、中英_、英数_。。。。。。。
●然后写出单个条件的所有无效等价类
●写下一个输入条件的,有效和无效等价类,操作步骤如上
●最后,可补充健壮性等价类
●验证【任意】两个输入条件无效【为空、错误】的情况;
●验证三个输入条件无效的情况;
●验证四个输入条件无效的情况;
●验证所有输入条件无效的情况。
●状态迁移法
●又称:流程测试,功能图法
●设计步骤:
●1.根据功能图,找出所有的状态;
●2.写出单个状态,局部的测试用例;
●3.使用xmind或其他工具,构造条件状态树;
●4.覆盖每一条初始到结束的路径;
●5.转化为具体的测试用例。
●备注:最多只覆盖两个循环。
●场景法
●设计步骤:
●1.找出场景的基本流和所有的备选流【相当于,测试用例标题=测试点】;
●2.根据基本流和备选流,写出所需满足的条件(每个条件分别触发V、I 的情况)【添加必要的条件】
●3.根据写出的场景,往条件中赋值,V(满足/有效)、I(不满足/无效)、NA(挂起/不考虑)
●4.根据场景表,写出用例编号、测试结果;
●5.使用测试数据替换V、I的值;
●6.把场景表转化成正式的一条条的测试用例。
●备注: 备选流中,只有一个 I 条件,【每个条件均可设置为一次I,作为备选输出】
●错误推测法(补充用例)
●基于经验和直觉进行补充
●基于项目经验和发现过的BUG进行补充
●用例设计方法,选取策略【体现在测试方案中!】
●1.必须使用“边界值分析法”,发现错误的能力最强!
●2.针对输入框并且是客户端的操作,优先考虑“等价类划分法”,把无穷的测试,划分有限的不同类型的测试覆盖。
●3.建议使用等价类+边界值进行组合覆盖,尽可能多的覆盖所有的测试情况,保证测试覆盖率,并提高测试效率。
●4.针对有功能图的需求,优先考虑“状态迁移法”,按照功能图提取状态,然后输出局部的测试用例,覆盖初始到结束的路径。
●5.针对业务场景,也是所有软件都适用,需验证使用场景的。优先考虑“场景法”,找出基本流和备选流,覆盖所有的测试情况。
●6.建议使用状态迁移法+场景法进行组合覆盖,考虑所有的有效路径和各种备选场景。
●7.随时使用“错误推测法”,基于项目经验和直觉和已发现的bug,进行测试用例的补充。关注测试覆盖率,避免漏测。
●9.缺陷报告
●1.缺陷定义:
●1.未实现需求规格说明书指明要实现的功能;(显性需求)
●2.未实现需求规格说明书虽未指出但应实现的功能;(隐性需求)
●3.超出需求规格说明书指明的范围;(超出需求范围)
●4.出现了指明不会出现的错误。
●5.用户体验认为不好的,使用不佳的,不易操作的,运行缓慢的问题
●2.如何识别缺陷
●通过需求规格说明书
●通过与测试用例中的预期结果对比
●同行业成熟的商业产品
●与有经验的测试工程师沟通
●与开发人员沟通
●参考同行业的隐性需求
●3.缺陷的组成:
●包含:缺陷编号、缺陷标题、操作步骤(步骤、预期结果、实际结果、备注)、严重程度、优先级、缺陷类型、影响版本号、附件(截图、视频、日志)
●缺陷编号:1~+∞,顺序排列
●缺陷标题:一句话概述,在XX模块,做了XX操作,出现XX问题。(概率性要写出来)
●缺陷模块:软件的功能模块
●问题描述:操作步骤+预期结果+实测结果+备注 (概率性的问题,在备注中,要写出测试多少次,出现多少次)
●严重程度:致命、严重、一般、较小、改进建议
●优先级: 立即解决、高优先级、正常排队、低优先级
●缺陷状态:新建、打开、修复、拒绝、激活、延期、重复、关闭
●缺陷概率:必现、偶现、不可复现 OR 10%~100%
●软件版本:VXXXX
●操作系统:WinXP、Win7、Win8、Win10
●浏览器 :firefox、chrome、IE、opera、safari
●指派人 :开发
●提交人 :测试
●提交时间:当前日期
●修改时间:XXXX年XX月XX日 XX:XX:XX
●4.缺陷的生命周期:
●简单周期:发现-打开-修复-关闭
●复杂周期:发现-打开-拒绝-激活-修复-关闭
●发现-打开-修复-复现-修复-关闭
●发现-打开-延期-修复-关闭
●5.缺陷跟踪处理流程
●A、测试人员获取新版本,执行测试;
●B、发现缺陷,在缺陷管理工具提交BUG;
●C、开发人员修复缺陷;
●D、针对不宜修复、无法修复的问题,TOCCB(专家会诊)确定如何解决;
●E、开发check in并提交代码到代码服务器;
●F、bulid人员合并代码,编译新版本,上传至SVN服务器;
●G、测试人员在SVN服务器获取新版本,开启新一轮测试。
●6.缺陷跟踪的目的
●6.1 跟踪缺陷状态,直至修复关闭
●6.2 进行缺陷分析、进行软件度量
●7.缺陷管理工具
●缺陷工具:禅道、QC、TD、Bugfree、Jira
●免费开源:Bugfree 、禅道免费版、Bugzero
●付费软件:TD、CQ、Jira、禅道专业版
●10.需求规格
●输出:SRS需求规格说明书(技术文档) 、游戏行业称为:策划案
●需求=获取用户的需要 = 转化成技术可实现的功能 = 需提取的功能模块!
●需求的定义包含:产品功能+行业标准规范。 输出技术文档为:需求规格说明书、各行业规范。
●需求的分层:金字塔模型
●用户需求:顶级需求。
●系统特性:软件技术功能+性能特性。
●系统需求:硬件,软件开发技术及架构。
●需求的变化:
●合理的变化: 用户需求不明确导致的,市场技术竞争导致的。
●不合理的变化:需求文档质量差、需求在技术和管理上不规范。
●需求变化的原因:需求获取不准确、遗漏需求、低效的需求分析。
●需求规格说明书的类型
●包含:业务需求、用户需求、系统需求、功能需求、非功能性需求、行业规范限制、质量特性要求等。
●业务需求:市场前景文件或项目轮廓图,确定要做什么类型的项目,面向什么样的市场。
●用户需求:进行市场调研或根据客户方要求,收集用户对软件的具体要求有哪些。(收集用户需求,并筛选有用的,去掉无用的需求)
●系统需求:包含软件需求和软硬件结合的需求。需考虑当今的软件技术和硬件是否能实现用户需求。若技术原因无法实现,则去掉该用户需求。
●功能需求:在满足系统需求的情况下,所有需实现的用户需求,被确定为必须实现的功能需求。若未实现功能需求,则是bug。
●非功能性需求:除功能之外的需求,常见为性能需求,可靠性,安全性需求等。也称为软件应满足的其他特性。
●行规:不同类型的软件产品,需满足各个行业的标准规范,法律法规,合同要求。如:入网规范、信息安全、加密认证、3C认证。
●质量特性:软件的整体质量如何,对需求的吻合程度。
●需求工程
●需求两大过程域
●需求开发过程
●1.需求获取
●2.需求分析
●3.需求定义
●4.需求验证
●需求管理过程
●1.需求实现
●2.需求跟踪
●3.需求变更控制
●11.软件质量
●质量要关注:内部质量、外部质量、使用质量
●质量的6大特性: 功能性、可靠性、易用性、效率、维护性、可移植性。
●质量管理体系:ISO国标、CMM能力成熟度模型、CMMI能力成熟度模型的集成。
●测试部门的质量目标: 项目版本进度按时完成 +资源使用情况+ 缺陷检出率 。
●测试项目的质量目标: 测试覆盖率 + BUG评估
●12测试计划
●13.测试方案
●14.测试报告
●15.软件测试方法
●分为功能测试方法和性能测试方法
●功能测试方法:安装测试、卸载测试、升级测试、配置测试、兼容性测试、易用性测试、界面测试、安全性测试、异常测试、备份测试、文档测试、网络测试
●性能测试方法:压力测试、负载测试、容量测试、稳定性测试、并发测试等
●安装测试:
●应包含:安装测试、卸载测试、升级测试!要考虑正常及异常情况。
●安装测试:
●1.安装前测试:测试软件安装包,包含软件本身和说明文档等。
●2.安装中测试:安装成功、及安装失败的情况,不同的安装方法和路径测试。
●3.安装后测试:验证软件安装成功,生成桌面图标,并可成功运行。安装后卸载、卸载后重装、重复安装、软件升级等。
●常见的安装方式:顺序性安装、自定义安装、一键安装、完全安装、部分安装、必选项安装、第三方安装、绿色版软件 C/S
●A/S 手机自带应用市场下载并安装【授权】、第三方应用市场下载并安装、下载apk至手机点击安装、电脑端连手机下载并安装、更多考虑异常安装内存空间满时安装、无权限时安装、。。
●Web端后台的考虑:部署软件包至服务器的安装、在服务器端的升级、
●常见的升级方式:
●软件自动更新、软件手动更新【跨版本更新、卸载后重安装】、第三方软件更新。
●卸载测试:
●卸载的几种方式、完全卸载和保留数据卸载、卸载后重装
●升级/更新测试:
●强制更新版本OR 非强制更新,自动更新、手动更新,跨版本进行更新
●配置测试:
●包含:服务器的软硬件配置、客户端的软硬件配置、软件的系统参数配置(最低配置和初始化参数)
●服务器软硬件配置:所选服务端软件的最低版本,硬件所需的最低配置。公司现有的配置,直接使用。服务器的硬件、web服务器、数据库服务器的选择。
●客户端软硬件配合:最低硬件配置、操作系统、浏览器、屏幕分辨率、颜色色彩等配置。(如android5.0以上,最低支持的就是5.0版本)
●软件系统参数配置:软件设置的参数默认值。
●兼容性测试:
●包含:软件兼容性、硬件兼容性、浏览器兼容性、网络兼容性、数据兼容性等
●软件兼容性:操作系统win、linux、OS X,移动端android、ios的所有待验证版本。
●硬件兼容性:不同厂家的电脑品牌,不同公司的手机品牌等
●浏览器兼容性:基于浏览器不同的内核,重点验证:IE、Google、firefox、opera、360/UC等
●网络兼容性:有线网(不同带宽8M/20M/100M)、无线网(加密/不加密、2.4G/5.8G)、移动网络(2G/3G/4G/5G)
●数据兼容性:软件版本向前兼容,向后兼容。
●易用性测试:
●菜单级数<3级;导航栏;快捷键的组合使用。操作简便。
●UI界面测试:
●界面的展示和功能的实现。界面层,接口层,功能层。
●导航测试、图形测试、内容测试
●界面元素外观(大小、形状、色彩、文字属性等)、
●界面元素布局(位置、对齐方式、间隔、Tab顺序)、
●界面元素行为(缺省值、输入限制/提醒、操作路径等)
●安全性测试:
●包含:系统安全性、数据安全性、网络安全性、权限、产品本身的安全性质量等
●重点考虑:权限!=软件权限+角色权限
●异常测试:
●也称为容错性测试,健壮性测试。
●需要人为构造异常,断电、断网、崩溃死机、服务器机。
●备份测试:
●分为自动备份、手动备份、
●考虑备份数据格式、备份是否成功、导入导出功能
●结合异常测试一起测试。当异常时,是否自动备份。
●手动备份,考虑:备份的文件,导回数据的正确性。
●文档测试:
●文档的规范性和实用性
●文档是否模糊遗漏
●可使用工具进行检阅:格式、中英文等
●面向的用户群体:技术人员或客户方用户等
●当前文档面向技术人员,则使用专业术语。尽量避免口语化描述。
●当前文档面向用户手册,则使用通俗易懂的语言,尽量避免使用技术用语。
●禁忌:不允许出现源代码!
●网络测试:
●网络通信方式:有线网、无线网、移动网络
●网络协议:tcp、udp、协议实现一致性
●考虑:正常网络、异常网络、弱网、无网的情况。
●总结:
●1.安装测试【安装、卸载、升级=XX测试前、XX测试中、XX测试后】、
●2.配置测试【软硬件最低配置、软件设置的参数配置、服务器端现有的配置、客户端硬件、系统、浏览器、分辨率、颜色】、
●3.兼容性测试【操作系统兼容、硬件兼容、数据兼容、浏览器兼容、版本向前向后兼容】
●4.可用性测试【菜单级数小于3级、快捷键的使用、导航栏=过于复杂的、或过于简单的、不能理解的】又称易用性测试
●5.安全性测试【数据安全、系统安全、软件本身的安全性、网络安全=重点关注权限分配、绕过鉴权、是否检测、拦截、处理】
●6.界面测试【界面与设计的实现、界面与功能的实现=界面层、界面与功能的接口层、功能层】又称GUI测试,图形化界面测试
●界面元素:最小的不可拆分的界面原子、组成界面组合元素的菜单条、构成完整的界面窗口对话框。
●界面的外观、界面的布局、界面的行为
●7.异常测试【人工干预制造断电、断网、崩溃、死机、丢失等异常情况,验证软件的自动恢复与人工干预恢复】又称容错性、可恢复性测试
●8.备份测试【自动备份、手动备份、备份后的数据格式、备份数据与原数据是否一致、恢复还原后的数据是否正确】
●9.文档测试【操作说明、协议、帮助手册、说明书=也包含技术文档(SRS、LLD、HLD、测试计划、方案、报告)的测试】
●10.网络测试【有线网、无线网、弱网、无网络 = BS、CS、AS= 协议 = 软件与协议实现的一致性、规范标准】
●
●软测岗位:
●测试员、软件测试实习生:不考虑
●软件测试工程师:【技术】
●1.根据测试计划,搭建所需的测试环境。
●2.根据测试方案,编写部分测试用例。
●3.执行测试用例,执行测试,提交BUG。
●4.输出测试日报,汇报测试情况。
●5.根据需要编写测试报告。
●软件测试设计人员:【技术】
●1.根据需求规格说明书,进行需求分析,提取测试需求;
●2.设计测试,选择所需的测试技术、测试策略、测试方法、测试用例设计方法;
●3.编写测试方案,并跟进完成情况及质量
●4.设计测试脚本,选择所需的语言、框架及结构。
●软件测试开发人员:【技术】
●1.编写自动化脚本
●2.编写所需的测试工具
●3.编写所需的测试框架等
●软件测试组长:【管理】
●1.根据项目计划,制定软件版本的测试计划;
●2.分配测试任务,跟踪测试进度及协调资源。
●3.对测试的结果负责,保质保量完成测试任务。
●软件测试经理:【管理】
●1.负责部门的组建及维护,制定测试部工作流程及考核制度
●2.定制团队组织架构及相关技术构成,
●3.制定项目的测试总计划,并对质量负责。