2023年软件测试技术经典教程笔记修

第一章基础知识1.１、软件1）、软件=程序+文档2)、分类功能:系统+应用架构:单机＋C／S+B／S用户:产品＋项目规模：小型+中型+大型１．２、Bｕg１)、类型一(广义上，软件生命周期，与用户需求不符的问题）:完全没有实现的功能基本实现功能,但有功能上或性能上的问题实现了用户不需要的功能２)、类型二（测试执行阶段的问题）Defeｃt－－---－---Rｅｑｕiremenｔs&DeｓigｎEｒrｏｒ--－-－-－----DevelopmｅｎtBｕg－--－－－--－---TesｔｉngＦaiｌure－-－---－-－Pｏstproduction１.3、测试１)、概念:测试是为了检查实际的软件是否符合用户需求,所以不能为了发现错误而发现错误。使用人工或自动手段，来运营或测试某个系统的过程。2)、测试环境：硬件+软件+网络规定：真实(项目、产品)+干净+无毒+独立(测试与开发)1.4、测试用例测试用例=输入+输出+测试环境便于团队交流，便于反复测试，便于跟踪记录，比纳与用户自测开发生命周期需求分析→概要设计→具体设计→编码→维护测试生命周期测试计划→测试设计→测试执行→测试评估需求分析和测试计划完毕后,根据《系统需求规格说明书》和软件原型(ＤEＭO)写测试用例1．5其他１)、测试人员素质规定：细心、耐心、信心、服务意识、团队合作意识、沟通能力２)、如何成为优秀的测试工程师:1、不断学习充电２、阅读原版书籍3、阅读缺陷管理系统中的缺陷报告4、阅读高手写的测试用例5、学习产品相关的业务知识1.6软件测试的基本规则1）ZｅroBug与ＧooｄEnoughGoｏdEnough原则：不充足测试是不负责任,过度的测试是一种资源浪费。参考:*遗留bug不超过10个,严重的不超过5个*测试用例执行率为100％,通过率为９5%*单元测试，关键模块语句覆盖率达成１00%，分支覆盖率达成85%２)不要视图穷举法3）开发人员不能既是运动员又是裁判员4)软件测试要尽早执行5)软件测试应当追溯需求原始需求需求分析对的的规格说明错误的规格说明设计对的的设计错误的设计对错误说明的设计编码对的编码错误的编码对错误设计编码对错误说明设计的编码测试对的功能可改正的错误不可改正的错误潜伏的错误不完善的软件产品6)缺陷的二八定理一般情况下,软件８０％的缺陷集中在２0%的模块中。7)缺陷具有免疫性缺陷具有免疫性，需要根据新版本修改维护测试用例,此外,有一个值得注意的经验:没修复3-4个buｇ，也许会产生一个新bｕg。第二章测试分类2.1、是否运营程序 StaticTesting--－－－----－--代码规范、界面、文档ﻩDｙnａｍｉcTeｓｔiｎg--－----－运营程序2．2、根据阶段分类 ＵniｔＴｅstｉｎｇ(单元测试）－－--－--－－-１0%最小模块,依据源程序和《具体设计》白盒测试人员||开发人员编译代码→静态测试→动态测试 桩模块(Stub)、驱动模块(Drｉver）ﻩＩntegrａtｉonTeｓtinｇ（集成测试)--------－-20％模块间的接口，依据单元测试的模块和《概要设计》白盒测试人员|｜开发人员一般单元和集成同步进行ﻩＳｙsteｍTeｓting(系统测试）----－---－－40%ﻩﻩ整个系统(功能、性能、软硬件环境),依据《需求规格说明书》 ﻩ黑盒测试工程师ﻩAccｅptanceＴeｓting（验收测试)-－-－----－-２0% 整个系统（功能、性能、软硬件环境)，依据《需求规格说明书》和验收标准 用户,可配合黑盒测试工程师 ﻩα测试：内侧β测试:公测2．３、是否查看代码１)、Whｉte－BｏxＴeｓｔinｇ-－---源代码的测试2)、Bｌaｃk-BoxTeｓtinｇ---－-功能测试、性能测试 FunctionTesｔing(功能测试)ﻩ LogicFuｎctionTｅsｔiｎg（逻辑功能测试)ﻩ UＩTeｓｔinｇ(界面测试):窗口、下拉式菜单和鼠标操作 UsabｉlｉtyTsetiｎg(易用性测试)ﻩﻩIｎstallａｔｉonTeｓting（安装测试)ﻩﻩCompatｉbｉlｉtｙＴesting（兼容性测试)ﻩ其他：恢复测试、裸机测试、确认测试、接口测试、数据库测试、安全测试、配置测试PｅrfｏrｍａnceTｅstiｎｇ(性能测试）时间性能:重要指一个事务的具体响应时间(RｅspｉnｄTime)。空间性能:重要指软件运营时所消耗的系统资源(CＰU、内存、硬盘）。分类：一般性能测试、稳定性测试、负载测试、压力测试a、一般性能测试:让被测系统在正常的软硬件环境下运营，不向其施加任何压力b、稳定性测试(也叫ReliabilityTesｔiｎg可靠性测试）:指连续运营被测系统，检查系统运营时的稳定限度。通常用ＭTBF(ＭeanTiｍeBeｔｗｅenFailｕrｅ)ｃ、负载测试(ＬoadＴｅsｔinｇ）：让被测系统在其能忍受的压力极限范围内连续运营，检测系统的稳定性。d、压力测试（StressＴesｔｉng)：连续不断的给被测系统增长压力,知道被测系统压垮为止，用来测试系统能承受最大压力。２.4、回归测试、冒烟测试、随机测试RegressiｏnTestinｇ(回归测试):软件新版本测试时,重新执行上一个版本测试用例。可以在任何阶段进行(单元测试、集成测试、系统测试、验收测试等)，既有黑盒测试的回归，也有白盒测试的回归。SmokeTesting(冒烟测试)：对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具有可测性。RａnｄomＴｅｓtinｇ(随机测试):指测试中所有的输入数据都是随机生成的,其目的是模拟用户的真实操作，并发现一些边沿性的错误。第三章测试技术黑盒测试技术３.1、等价类技术(EquivａlenceClassTestｉｎg)等价类：某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。有效等价类:符合《需求规则说明书》，合理地输入数据集合无效等价类:不符合《需求规则说明书》，无意义的输入数据集合等价类划分环节:１)先考虑输入数据的类型（合法和非法)2)再考虑数据范围3)画出示意图,区分等价类４)为每个等价类编号５)从等价类中选择测试数据构造用例3.2、边界值技术(BｏｕｎdaryVａluｅＴesting）3.3、因果图法(Cａｕse-ＥfｆeｃtGraｐｈs)因果图法环节1）找出所有的输入条件和输出，并编号２)分析输入条件之间的关系,是互斥还是可以同时满足3)画出输入条件的排列组合情况４)编写测试用例因果图试用于输入条件过多3．4、流程图法(WorkflｏwＭethod)流程图法环节1)具体了解需求2)根据需求说明或界面原型,找出业务流程的各个页面及各页面之间的流转关系3)画出业务流图4)写用例，覆盖所有途径分支流程图法是针对整个系统,而非某个页面或模块尚有其他如：鉴定表、错误推测、场景法等，例：AＴM机取钱-场景法(不全）场景密码帐号输入金额账面金额AＴＭ钞票预想结果场景1:成功提款1１111提款场景２：ATM内无钞票11110不可提款场景３:ＡＴM内钞票局限性１1110提醒,返回开始场景4:密码错误，可再次输入0１null11警告，返回开始场景５：密码错误,不可再次输入01null1１警告，卡预保存白盒测试技术3．５白盒测试检查点＊对程序模块的所有独立的执行途径至少测试一次*对所有的逻辑鉴定，取’真’与’假’都至少测试一次*在循环的边界和运营界线内执行循环体＊测试内部数据结构的有效性等环节：1)根据分析画出流程图２）计算圈复杂度=鉴定节点数+13)写出独立途径4)根据独立途径设计测试用例第四章缺陷管理4．1、Ｂug的分类1)严重限度（Sｅｖｅrity):系统崩溃、严重、一般、次要、建议２)优先级（Priｏｒｉty):高(High)、中(Middle)、低(Low)严重限度高，优先级不一定高，严重限度低，优先级不一定低3）按测试种类:逻辑功能类(Fcuｎtion)、性能类(Pｅrｆormance)、界面类(UＩ)、易用性类(Usabiｌity)、兼容性类（Compatｉbilｉtｙ)4）按功能模块5)按生命周期：新建(New)、确认（Confirｍｅd)、解决(Fixｅd)、关闭（Closed)、重新打开（Rｅopｅn）4．2缺陷报告注意点:1)保证重现Ｂug2)用最少且必要环节描述Bug3)简洁、准确、完整４)一个Bug一个报告4.3缺陷管理工具ＴｒackRecord、Clｅaｒquest、Buｇzillａ(免费)、Mantｉs(免费）、JＩRA（免费)Bugziｌla：ＴeｒryWｅiｓｓmａｎ研制，pｅrl编写，后台数据库是MyＳQL，最初是用来在Neｔｓｃaｐe内部跟踪Bug的，可以在多种平台运营第五章常用测试工具分类：黑盒测试工具、白盒测试工具、测试管理工具MI公司产品:1、LｏaｄRｕnｎer:性能测试工具2、ＷｉｎRuｎner：功能测试工具（QＴＰ：MI的QTＰ代替占有市场）3、TestDireｃtor：测试管理工具（QC:HP收购MI公司后退出的一款TＤ升级产品）性能学习LoadRunner,功能学些QＴＰ，管理学习TDIBMRａｔｉonal公司的产品:RａtionalTestmanaｇer(测试管理工具）ＲationａｌＣlｅａrQｕｅst(缺陷管理工具)ＲａtioｎａlRobot(功能／性能工具)ＲationalPuｒiｆy(白盒测试工具)Compuwarｅ公司产品QACｅnter（测试管理)TraｃｋRecord(缺陷管理）QARun(功能)QAload(性能)ＤeｖPａｒtner(白盒测试）Tｅlｅｌogｉｃ公司产品TeｌｅlogｉcDoｏrs（需求管理)、Ｌoｇｉｓcope(白盒测试工具)其他公司产品微软-WAＳ（性能测试）Rａdview公司-ＷebLｏad(性能测试),ＴeｓｔＶieｗＭanaｇｅr（测试管理)Pａraｓofｔ公司-ＪＴeｓｔ(白盒测试),C++Tesｔ(白盒测试)此外,很多缺陷管理工具是开源的,如:Bugzｉｌlａ、Mantiｓ、Ｊiｒa第六章测试管理6.1、测试与质量软件质量:软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准，以及所有专业开发的软件都应具有的隐含特性的限度(需求一致、符合准则、隐含特性）SQA(SofｔwareQualitｙAssurancｅ)：软件质量保证,为保证软件开发过程和结果符合预期规定而建立的一系列规程,以及一照规程和计划采用的一系列活动及其结果评价。SQA需要做的工作：＊建立软件质量保证活动的实体*制定软件质量保证计划*坚持各阶段的评审、审计、跟踪*监控软件产品的质量＊采集软件质量保证活动的数据*度量软件质量保证活动SQA需要达成目的:*通过监控软件开发过程来保证产品质量*保证开发出来的软件和软件开发过程符合相应标准与规程（IＳＯ9０000或CMM)*保证软件产品、软件过程中存在的不符合问题得到解决，必要时将问题反映给高级管理者＊保证项目组指定的计划、标准和规程适合项目组需要，同时满足评审和审计需要。SＱA工作人员：QA，QC工作人员:重要是TＥSTEＲＱＡ与QC：QＡ－防止问题(Ｐreveｎｔion),贯穿于整个软件生命周期中，防止错误的成因,重点是对软件开发过程进行监督、管理、控制ＱC-发现问题(Dｅteｃtioｎ）,重要是测试人员，关注于最后的产品的质量活动，重点是对开发出的产品进行检查6.2、常用模型CＭM：能力成熟度模型1)初始级(Ｉnitial):软件过程的特性是无序的,有时甚至是混乱的。几乎没有过程定义,成功完全取决于个人的能力。2）可反复级（Ｒeｐeatablｅ)：建立了基本的项目管理过程,可以追踪费用、进度和功能。有适当的必要的过程规范，使得可以重现以前类似项目的成功。3）已定义级(Defined）:用于管理和工程活动的软件过程己经文档化、标准化,并与整个组织的软件过程相集成。所有项目都使用文档化的、组织认可的过程来开发和维护软件。４）已管理级(Mａｎaｇeｄ)：软件过程和产品质量的具体度量数据被收集,通过这些度量数据,软件过程和产品可以被定暈地理解和控制。5)优化级(Opｔimizing)：通过定量的反馈，进行不断的过程改善,这些反馈来自于过程或通过测试新的想法和技术而得到。CMMISOCMMISO•质量模型质量标准•评估审查•给你改善建议结果有通过和不通过KPＡ(KeyProceｓsＡrea):除第一级外，ＣMM的每一级是按完全相同的结构组成的。每一级包含了实现这一级目的的若干关键过程域，指出了公司需要集中力量改善的软件过程。ＣＭＭ2:可反复阶段需求管理：ｒequremenｔmａnagemｅnｔ软件项目计划：sofｔwarepｒojeｃtplanniｎg软件项目跟踪和监督：sofｔwarｅpｒｏjｅcｔtracｋｉngｏveｒsight软件子协议管理:softｗarｅsuｂcoｎtractmanaｇemｅｎt软件质量保证:softwａｒequaｌｉtyａssuraｎce软件配置管理：ｓofｔwａrecoｎｆiｇuｒatｉｏｎemaｎagｅmenｔＣＭM3：已定义阶段组织过程焦点:ｏｒgaｎizａtiｏnproceｓsfoｃｕs组织过程定义:oｒgaｎｉzationpｒocessdｅfiｎｉtｉon培训大纲：ｔraｉniｎgprｏgram集成软件管理:inｔerｇratｅdsoftｗaremanaｇｅｍｅｎt软件产品工程:sofｔwaｒeｐrｏductengｉｎｅering组间协调：inｔergroupcｏordinａｔion同行评审：peeｒrevｉｅｗCMＭ4:已管理阶段定量管理过程：ｑuantitatｉｖeprocessmanagemeｎｔ软件质量管理:ｓｏftwaｒｅｑｕalｉtyｍanagｅmentCMM5:优化阶段缺陷防止：defecｔｐreｖention技术改革管理：techｎologycｈａngemａnａgemenｔ过程更改管理：pｒocｅsｓｃhaｎgemａnagement成熟度成熟度初始级可反复级已定义级已管理级优化级风险常见的质量模型：*ＩSO90０0０族标准:国际标准(ISＯ/ＴC1７6),适合所有行业,其中9０0０-3针对软件开发*ＣMM标准:行业标准(卡耐基-梅隆大学)，针对软件开发行业，分5等级,推出CMMI*TICKIT标准:行业标准(英国软件行业协会）,针对软件开发行业，不太流行＊IＳO１5504标准:国际标准(试图结合1、2与软件工程概念)，合用所有行业,有待实践其他模型:TMM：软件测试成熟度模型*初始级*阶段定义级*集成级*管理和度量级*优化、防止缺陷和质量控制级McCall模型：【产品运营】对的性、健壮性、效率、完整性、可用性、风险【产品修改】可理解性、可维护性、灵活性、可测试性【产品转移】可移植性、可再用性、互运营性6.３、软件的生命周期软件：可行性研究、需求分析→设计、编码、测试→软件发布维护→淘汰软件开发:需求分析→概要设计→具体设计→编码→维护软件测试：测试计划→测试设计测试执行→测试评估软件生命周期模型：1、WaterfａllMoｄｅl(瀑布模型):计划－需求-设计-编码-测试－维护开发的各个阶段比较清楚依赖早起需求调查，不适应需求变化强调初期计划及需求调查单一流程，不可逆适合需求稳定的产品开发风险往往迟至后期才发现,失去及早纠正机会2、SpiｒalModel(螺旋模型)：反复执行多个’瀑布模型’适合需求经常变化的软件项目,但开发过程复杂,控制不好,容易混乱3、V模型用户需求验收测试规格定义系统测试概要设计集成测试具体设计单元测试编码具体表达了测试的各个阶段及参考依据,但没有说明在项目前期测试需要做哪些工作,且流程也是单项，不可逆４、W模型需求分析需求测试系统安装验收测试概要设计概要设计系统构建系统测试测试具体设计具体设计模块集成集成测试测试编码实现单元测试强调测试随着整个软件开发生命周期，对象也不仅是程序，有助于尽早发现问题，但是需求设计编码等活动也被视为串行，测试和开