软件测试技术经典教程笔记(修)

第一章 基础知识1.1、软件1)、软件=程序+文档2)、分类功能：系统+应用架构：单机+C/S+B/S用户：产品+项目规模：小型+中型+大型1.2、Bug1)、类型一(广义上，软件生命周期，与用户需求不符的问题)：完全没有实现的功能基本实现功能，但有功能上或性能上的问题实现了用户不需要的功能2)、类型二(测试执行阶段的问题)Defect-Requirements&DesignError-DevelopmentBug-TestingFailure-Post production1.3、测试1)、概念：测试是为了检验实际的软件是否符合用户需求，所以不能为了发现错误而发现错误。使用人工或自动手段，来运行或测试某个系统的过程。2)、测试环境：硬件+软件+网络 要求：真实(项目、产品)+干净+无毒+独立(测试与开发)1.4、测试用例测试用例=输入+输出+测试环境便于团队交流，便于重复测试，便于跟踪统计，比纳与用户自测开发生命周期需求分析 概要设计 详细设计 编码 维护测试生命周期测试计划 测试设计 测试执行 测试评估需求分析和测试计划完成后，根据系统需求规格说明书和软件原型(DEMO)写测试用例1.5 其他1)、测试人员素质要求：细心、耐心、信心、服务意识、团队合作意识、沟通能力2)、如何成为优秀的测试工程师：1、不断学习充电 2、阅读原版书籍 3、阅读缺陷管理系统中的缺陷报告 4、阅读高手写的测试用例 5、学习产品相关的业务知识1.6 软件测试的基本规则1) Zero Bug 与 Good EnoughGood Enough原则：不充分测试是不负责任，过分的测试是一种资源浪费。参考：*遗留bug不超过10个，严重的不超过5个 *测试用例执行率为100%，通过率为95% *单元测试，关键模块语句覆盖率达到100%，分支覆盖率达到85%2) 不要视图穷举法3) 开发人员不能既是运动员又是裁判员4) 软件测试要尽早执行5) 软件测试应该追溯需求原始需求需求分析正确的规格说明错误的规格说明设计正确的设计 错误的设计对错误说明的设计编码正确编码错误的编码对错误设计编码对错误说明设计的编码测试正确功能可改正的错误不可改正的错误潜伏的错误不完善的软件产品6) 缺陷的二八定理 一般情况下，软件80%的缺陷集中在20%的模块中。7) 缺陷具有免疫性 缺陷具有免疫性，需要根据新版本修改维护测试用例，另外，有一个值得注意的经验：没修复3-4个bug，可能会产生一个新bug。第二章 测试分类2.1、是否运行程序Static Testing-代码规范、界面、文档Dynamic Testing-运行程序2.2、根据阶段分类Unit Testing(单元测试)-10%最小模块，依据源程序和详细设计白盒测试人员|开发人员编译代码静态测试动态测试桩模块(Stub)、驱动模块(Driver)Integration Testing(集成测试)-20%模块间的接口，依据单元测试的模块和概要设计白盒测试人员|开发人员一般单元和集成同步进行System Testing(系统测试)-40%整个系统(功能、性能、软硬件环境)，依据需求规格说明书黑盒测试工程师Acceptance Testing(验收测试)-20%整个系统(功能、性能、软硬件环境)，依据需求规格说明书和验收标准用户，可配合黑盒测试工程师测试：内侧测试：公测2.3、是否查看代码1)、White-Box Testing-源代码的测试2)、Black-Box Testing-功能测试、性能测试Function Testing(功能测试)Logic Function Testing(逻辑功能测试)UI Testing(界面测试)：窗口、下拉式菜单和鼠标操作Usability Tseting(易用性测试)Installation Testing(安装测试)Compatibility Testing(兼容性测试)其他：恢复测试、裸机测试、确认测试、接口测试、数据库测试、安全测试、配置测试Performance Testing(性能测试) 时间性能：主要指一个事务的具体响应时间(Respind Time)。 空间性能：主要指软件运行时所消耗的系统资源(CPU、内存、硬盘)。分类：一般性能测试、稳定性测试、负载测试、压力测试a、一般性能测试：让被测系统在正常的软硬件环境下运行，不向其施加任何压力 b、稳定性测试(也叫Reliability Testing 可靠性测试)：指连续运行被测系统，检查系统运行时的稳定程度。通常用MTBF(Mean Time Between Failure) c、负载测试(Load Testing)：让被测系统在其能忍受的压力极限范围内连续运行，检测系统的稳定性。 d、压力测试(Stress Testing)：持续不断的给被测系统增加压力，知道被测系统压垮为止，用来测试系统能承受最大压力。2.4、回归测试、冒烟测试、随机测试Regression Testing(回归测试)：软件新版本测试时，重新执行上一个版本测试用例。可以在任何阶段进行（单元测试、集成测试、系统测试、验收测试等），既有黑盒测试的回归，也有白盒测试的回归。Smoke Testing(冒烟测试)：对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。Random Testing(随机测试)：指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。第三章 测试技术黑盒测试技术3.1、等价类技术(Equivalence Class Testing)等价类：某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。有效等价类：符合需求规则说明书，合理地输入数据集合无效等价类：不符合需求规则说明书，无意义的输入数据集合等价类划分步骤： 1)先考虑输入数据的类型(合法和非法)2)再考虑数据范围3)画出示意图，区分等价类4)为每个等价类编号5)从等价类中选择测试数据构造用例3.2、边界值技术(Boundary Value Testing)3.3、因果图法(Cause-Effect Graphs)因果图法步骤 1)找出所有的输入条件和输出，并编号2)分析输入条件之间的关系，是互斥还是可以同时满足3)画出输入条件的排列组合情况4)编写测试用例因果图试用于输入条件过多3.4、流程图法(Workflow Method)流程图法步骤1)详细了解需求2)根据需求说明或界面原型，找出业务流程的各个页面及各页面之间的流转关系3)画出业务流图4)写用例，覆盖所有路径分支流程图法是针对整个系统，而非某个页面或模块还有其他如：判定表、错误推测、场景法等，例：ATM机取钱-场景法(不全)场景密码帐号输入金额账面金额ATM现金预想结果场景1：成功提款11111提款场景2：ATM内无现金11110不可提款场景3：ATM内现金不足11110提示，返回开始场景4：密码错误，可再次输入01null11警告，返回开始场景5：密码错误，不可再次输入01null11警告，卡预保留白盒测试技术3.5 白盒测试检查点*对程序模块的所有独立的执行路径至少测试一次*对所有的逻辑判定，取真与假都至少测试一次*在循环的边界和运行界限内执行循环体*测试内部数据结构的有效性等步骤：1)根据分析画出流程图 2)计算圈复杂度 = 判定节点数 + 1 3)写出独立路径 4)根据独立路径设计测试用例第四章 缺陷管理4.1、Bug的分类1)严重程度(Severity)：系统崩溃、严重、一般、次要、建议2)优先级(Priority)：高(High)、中(Middle)、低(Low)严重程度高，优先级不一定高，严重程度低，优先级不一定低3)按测试种类：逻辑功能类(Fcuntion)、性能类(Performance)、界面类(UI)、易用性类(Usability)、兼容性类(Compatibility)4)按功能模块5)按生命周期：新建(New)、确认(Confirmed)、解决(Fixed)、关闭(Closed)、重新打开(Reopen)4.2 缺陷报告注意点：1)确保重现Bug2)用最少且必要步骤描述Bug3)简洁、准确、完整4)一个Bug一个报告4.3 缺陷管理工具TrackRecord、Clearquest、Bugzilla(免费)、Mantis(免费)、JIRA(免费)Bugzilla：Terry Weissman研制，perl编写，后台数据库是MySQL，最初是用来在Netscape内部跟踪Bug的，可以在多种平台运行第五章 常用测试工具分类：黑盒测试工具、白盒测试工具、测试管理工具MI公司产品：1、LoadRunner：性能测试工具2、WinRunner：功能测试工具(QTP：MI的QTP代替占有市场)3、TestDirector：测试管理工具(QC：HP收购MI公司后退出的一款TD升级产品)性能学习LoadRunner，功能学些QTP，管理学习TDIBM Rational公司的产品：Rational Testmanager(测试管理工具)Rational ClearQuest(缺陷管理工具)Rational Robot(功能/性能工具)Rational Purify(白盒测试工具)Compuware公司产品QACenter(测试管理)TrackRecord(缺陷管理)QARun(功能)QAload(性能)DevPartner(白盒测试)Telelogic公司产品Telelogic Doors(需求管理)、Logiscope(白盒测试工具)其他公司产品微软-WAS(性能测试)Radview公司-WebLoad(性能测试)，TestView Manager(测试管理)Parasoft公司-JTest(白盒测试)，C+ Test(白盒测试)另外，很多缺陷管理工具是开源的，如：Bugzilla、Mantis、Jira第六章 测试管理6.1、测试与质量软件质量：软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准，以及所有专业开发的软件都应具有的隐含特征的程度(需求一致、符合准则、隐含特征)SQA(Software Quality Assurance)：软件质量保证，为确保软件开发过程和结果符合预期要求而建立的一系列规程，以及一照规程和计划采取的一系列活动及其结果评价。SQA需要做的工作：*建立软件质量保证活动的实体 *制定软件质量保证计划 *坚持各阶段的评审、审计、跟踪 *监控软件产品的质量 *采集软件质量保证活动的数据 *度量软件质量保证活动SQA需要达到目标： *通过监控软件开发过程来保证产品质量 *保证开发出来的软件和软件开发过程符合相应标准与规程(ISO90000 或 CMM) *保证软件产品、软件过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者*确保项目组指定的计划、标准和规程适合项目组需要，同时满足评审和审计需要。SQA工作人员：QA，QC工作人员：主要是TESTERQA与QC：QA-预防问题(Prevention)，贯穿于整个软件生命周期中，预防错误的成因，重点是对软件开发过程进行监督、管 理、控制 QC-发现问题(Detection)，主要是测试人员，关注于最后的产品的质量活动，重点是对开发出的产品进行检查6.2、常用模型CMM：能力成熟度模型1)初始级(Initial)：软件过程的特征是无序的，有时甚至是混乱的。 几乎没有过程定义，成功完全取决于个人的能力。2)可重复级(Repeatable)：建立了基本的项目管理过程，能够追踪费用、进度和功能。有适当的必要的过程规范，使得可以重现以前类似项目的成功。3)已定义级(Defined)：用于管理和工程活动的软件过程己经文档化、标准化，并与整个组织的软件过程相集成。所有项目都使用文档化的、 组织认可的过程来开发和维护软件。4)已管理级(Managed)：软件过程和产品质量的详细度量数据被收集，通过这些度量数据，软件过程和产品能够被定暈地理解和控制。5)优化级(Optimizing)：通过定量的反馈，进行不断的过程改进，这些反馈来自于过程或通过测试新的想法和技术而得到。CMM ISO质量模型 质量标准评估 审查给你改进建议 结果有通过和不通过KPA(Key Process Area)：除第一级外，CMM的每一级是按完全相同的结构组成的。每一级包含了实现这一级目标的若干关键过程域，指出了企业需要集中力量改进的软件过程。 CMM2:可重复阶段需求管理：requrement management软件项目计划：software project planning软件项目跟踪和监督：software project tracking oversight软件子合同管理：software subcontract management软件质量保证：software quality assurance软件配置管理：software configuratione managementCMM3:已定义阶段组织过程焦点：organization process focus组织过程定义：organization process definition培训大纲：training program集成软件管理：intergrated software management软件产品工程：software product engineering组间协调：intergroup coordination同行评审：peer reviewCMM4:已管理阶段定量管理过程：quantitative process management软件质量管理：software quality managementCMM5:优化阶段缺陷预防：defect prevention技术改革管理：technology change management过程更改管理：process change management成熟度 初始级 可重复级 已定义级 已管理级 优化级风险常见的质量模型：*ISO90000族标准：国际标准(ISO/TC176)，适合所有行业，其中9000-3针对软件开发*CMM标准：行业标准(卡耐基-梅隆大学)，针对软件开发行业，分5等级，推出CMMI*TICKIT标准：行业标准(英国软件行业协会)，针对软件开发行业，不太流行*ISO15504标准：国际标准(试图结合1、2与软件工程概念)，适用所有行业，有待实践其他模型：TMM：软件测试成熟度模型*初始级*阶段定义级*集成级*管理和度量级*优化、预防缺陷和质量控制级McCall模型：【产品运行】正确性、健壮性、效率、完整性、可用性、风险 【产品修改】可理解性、可维护性、灵活性、可测试性 【产品转移】可移植性、可再用性、互运行性6.3、软件的生命周期软件：可行性研究、需求分析设计、编码、测试软件发布维护淘汰软件开发：需求分析概要设计详细设计编码维护软件测试：测试计划测试设计 测试执行测试评估软件生命周期模型：1、Waterfall Model(瀑布模型)：计划-需求-设计-编码-测试-维护开发的各个阶段比较清晰 依赖早起需求调查，不适应需求变化强调早期计划及需求调查 单一流程，不可逆适合需求稳定的产品开发 风险往往迟至后期才发现，失去及早纠正机会2、Spiral Model(螺旋模型)：重复执行多个瀑布模型适合需求经常变化的软件项目，但开发过程复杂，控制不好，容易混乱3、V模型 用户需求 验收测试 规格定义 系统测试 概要设计 集成测试 详细设计 单元测试 编码 详细表示了测试的各个阶段及参考依据，但没有说明在项目前期测试需要做哪些工作，且流程也是单项，不可逆4、W模型需求分析 需求测试 系统安装 验收测试概要设计 概要设计 系统构建 系统测试 测试详细设计 详细设计 模块集成 集成测试 测试编码实现 单元测试 强调测试伴随整个软件开发生命周期，对象也不仅是程序，有利于尽早发现问题，但是需求设计编码等活动也被视为串行，测试和开发也保持一种线性的前后关系。W模型、H模型、X模型通常可以在W模型的框架下，运用H模型的思想进行独立的测试，当有变更发生时，按X模型和前置模型的思想进行处理。(百度另几种模型)6.4 软件测试计划撰写测试计划时，应注意一下四点：*增强测试计划实用性注意体现项目的测试特点*坚持”5W1H”规则，明确内容与过程5W1H：”WHAT”,”WHY”,”WHEN”,”WHERE”,”WHO”,”HOW”what：明确测试范围和内容why：测试目的when：确定测试开始和结束日期where：给出测试文档和软件的存放位置who：测试人员的分配how：指出测试的方法和工具*采用评审和更新机制，保证测试计划满足实际需求*分别创建测试计划与测试策略其他RUP： rational unified process 统一软件开发过程它定义了在整个软件开发过程中：在什么时候，应该有谁，进行什么样的开发活动，产生什么样的结果，来确保按时提交筒质量的产品。RUP总体结构每个角色完成指定的活动每个活动产出合格的产品每个产品拥有相关的指南，模板等RUP主要特点迭代化软件开发以架构为核心的软件开发用例驱动的软件开发风险驱动的软件开发最佳经验迭代化开发需求管理基于构件的软件架构可视化建模持续的质量验证配置管理RUP适合任何项目RUP在实施之前必须进行裁剪RUP是个丰富的知识库，需要你不断的去查阅，选择实践RUP是个持续的过程国际化与本地化Globalization testing注意的是它与翻译是没什么太大关系的。国际化测试关注产品是否达到了不同的时区、时间日期、货币格式和不同的文化习 惯等，当然还有政治规定方面的要求。Localization testing对一个软件进行本地化测试就需要关注文本显示的空间，因为不同语言的 长度不一样，所以在设计界面的时候就要小心了！验证软件被翻译完毕后，是否有什么错误，是否能够正常工作。