10 软件测试：系统测试

系统测试本章教学要点教学目标：通过本章学习，能针一个系统展开功能测试、简单的非功能测试。教学重点与难点：怎么样算一个好需求、如何对需求进行静态测试方法系统测试，不同的人有不一样的测试策略、方法、用例、过程，又如何保证测试的完备性回顾：各类测试层次层次对象目的测试依据测试方法单元测试模块内程序消除局部模块逻辑上的错误和代码缺陷详细设计函数说明白盒测试集成测试模块间的集成和调用关系找出与软件设计相关、模块调用关系，模块间接口等方面问题概要设计接口设计灰盒测试，采用较多黑盒系统测试整个系统，包括系统软硬件对整个系统进行一系列的功能、非功能测试系统需求系统规格说明黑盒测试验收系统整个系统及周边环境对整个系统按用户环境和用户使用场景进行一系列测试用户需求合同标准黑盒测试目录系统测试基本概念1功能测试5非功能测试3需求静态测试２4回归测试案例：手机测试 针对一款新生产的手机，你打算如何进行测试？华为上海研究所4G实验室案例：手机测试针对一款新手机，你打算怎么测试它？/notebook/slide_5_22298_40088.html#p=1系统测试的定义将整个系统看作一个黑盒，验证其是否满足需求。由若干测试组成。包括功能测试和非功能测试(质量属性)是否能完成正常功能？大量用户使用情况下，能否经得住考验？是否能长期稳定地运行下去？系统是否能经常出各种异常和特殊环境的考验？系统出错后能否快速恢复或故障转移出去？系统隐私信息是否安全？名词术语再看三角形的例子：OK吗？输入规格输入界面是怎样的？支持的语言？字体格式要求？边长允许的输入范围？输入会话是否有超时要求？输出规格对于无效输入输出信息如何提示？输出信息有无接口格式要求？例：对外提供接口？是否允许连续处理？结束后如何退出？输出结果是否允许保存？质量属性（非功能）性能方面：允许的时延？可服务性要求：是否需要安装？对日志支持？有没有可靠性和安全性方面的要求？一个完整的测试还包括：需求验证、非功能测试等目录系统测试基本概念1功能测试5非功能测试3需求静态测试２4回归测试看一个例子某需求描述用户登录，姓名长度最大为32Byte的任何字符。软件开发实现姓名长度限制为32Byte，GBK编码对于中文：长度为16，英文为32有一天:将字符编码从GBKUTF-832Byte是开发语言。用户语言：姓名最大输入长度为16带来问题：姓名长度最多只能输入10位了为什么要做需求静态测试50%以上BUG来源于需求本身用自然语言所描述的需求总是模糊不清的探索需求：表达出的和未表达出的；明确的与隐含的规格说明（预期）程序行为（观察）需求Venn图用户需求来源：西乔漫画《产品需求》表达出的与未表达出的用户需要的(Needs)－>

用户表达出来的(Demands)－>

软件需求规格表达出来的(Specification)->

代码实现的(Code)->

验证通过的(Test)->

系统发布的(Release)->

用户终于用上了的，但是他们不满意

->？什么是软件需求软件需求定义

（IEEE610.12-1990）用户为解决问题或达到目标所需条件或能力系统或系统部件为满足合同/标准/规范或其它正式规定文档所需具备的条件或能力。一组以上所描述的条件或能力的文档说明

软件需求分类业务需求和系统需求功能需求和非功能需求核心要点说清楚：为什么做、做什么、不做什么、长得什么样？用户需求范围＝系统需求范围名词术语

Atthismostbasic,asoftwarerequirementisapropertythatmustbeexhibitedbysomethinginordertosolvesomeproblemintherealworld.Itmayaimtoautomatepartofataskforsomeonetosupportthebusinessprocessesofanorganizationtocorrectshortcomingofexistingsoftware,ortocontroladevice.----《SWEBOKV3.0》1.1DefinitionofaSoftwareRequirement软件需求文档软件需求文档说明的各种形式用户需求: 合同要求Demand系统包需求OR：Feature，Capability系统设计需求DR：工作流(Given-When-Then)软件需求规格SRS:Specification用户故事： UserStory不同层次软件需求分析:不断细化、走向可实现过程层次愈多、信息愈容易损失ASXXXXX，IWantXXXXX,forthepurposeXXXXX用户角色系统特性业务场景用户需求系统需求软件需求规格问题域方案域软件需求示例作为用户，我想要手机提供更为便捷快速的输入功能，就象手写速记笔记一样。系统支持在线支付能力。作为网络规划人员，我想从管理系统下载媒体网关参数(Given-When-Then)系统支持Oracle和MySQL两种数据库所有交易在5s内完成业务中断时间不超过3分钟遇到的需求问题需求没有描述输入范围，用例怎么写啊？测试性能指标测试结果是多少才算通过？需求2边不一致，以哪个为准啊？这个需求不知道是哪个客户提的这个新需求会影响到哪些功能呢？这不是我想要的！(不明确)(无通过标准,不可验证)测试人员开发人员SE系统工程师(不一致)(不完整)(无跟踪)(不正确)客户好需求的标准属性维度属性要求关注度可跟踪性上下游双向跟踪★明确性简洁；无二义；场景要素(5W1H)明确；★★★★一致性统一风格；统一引用；一致描述★★完整性需求规格分解完整★★★可验证性量化、结果可判断；测试可达到★★☆正确性充分理解了客户需求；规范遵从度★★需求可跟踪性标准要求确认需求是否建立起上下游双向跟踪关系。需求唯一性，易于跟踪、不丢失。【案例】“用户可以终止查询类操作”，未实现。 经分析：在需求分解分配给A和B两个项目时,由于缺少跟踪导致实现遗漏。需求明确性标准要求确定系统要做什么、做成什么样子能理解需求在说什么。需求的意思表达清楚，对需求所涉及的名词、术语、引用等都可以理解。能理解需求要做什么。需求的要求表达明确。对需求所涉及的功能、属性、约束进行了明确的定义、且不需要做进一步的解释。（不明确带来的二义性后面单独讲）明确性的问题往往是文档说了，但说的不够，需要在阅读中反复地去追问；直至说够了、彼此对系统要做什么、做成什么样子达成了一致理解。标准要求

-需求之间描述不存在矛盾、不一致的地方。

-评审过程就是不断检查相关性，然后对有重合或相似的地方进行对照，以检查彼此是否一致【案例】有系统需求描述:A处：对任何列表形式界面提供信息保存功能。B处：对任何列表形式界面提供信息导出功能不同地方叫法不一致，它们功能本质是一致。需求一致性需求完整性标准要求需求所有应用条件是否被陈述，需求表达了完整的思想。完整性指的是需求发生了缺失（特别是需求分解）-需求遗漏。往往是场景上的缺失、非功能需求考虑不足；-需求部分内容残缺：需求描述不完整、结构上缺少内容【案例】所有的用户密码数据处理都需要进行加密。包括：输入、传输、存储、显示等”需求分解中有场景上的缺失。需求可测试性标准要求外部行为特征清楚；评价标准可衡量；通过测试可达到。【案例】需求描述：系统能处理所有的异常错误。需求绝对化导致的可验证问题。需求正确性标准要求对需求理解正确，代表了客户真正需要。检查正确性的过程，即是一个与需求参照标准作对比的过程，以确认它符合要求、遵从规范。在缺少标准的情况下，往往依据个人理解、经验或约定束成对正确性或合理性作出判断。通过与标准规范对比发现正确性。【案例】需求描述：遵从HTTP协议。抓包发现协议头和协议体之间的只有一个ASC为10字符，但协议要求为CRLF(13+10)需求最常见问题：二义性什么是二义性ambiguous?同样的句子可以以多种方式来解读。验证：如果某人写的代表一个意思，读它的人理解成另一个意思，那么它就是有歧义的Onehalfoftwoandtwo=??操作员标识由操作员姓名和密码组成，密码由6位数字构成。当操作员登录进系统时它被存放在注册文件中指代引用对象模糊二义性：模糊用语分类关键词示例指代对象模糊代词、参照、缩略语、多个对象该处理同上一版本可能性可能，也许，大约大约允许1000用户频度词通常，一般，正常，典型，经常、有时候对于操作员来说，有时候需要重新初始化该信息定性词非常，很，高，一定，基本，快速通用，灵活，友好非常稳定，可靠性很高，高可用性，符合基本要求，系统快速响应，用户界面友好，系统通用、灵活否定词不正常系统运行不正常设计用语过程，函数，类，对象二义性：逻辑结构空悬else条件缺失或不明确如果你开车闯红灯，你将会收到一张罚单动作缺失或不明确如果A为某俱乐部会员且code=1则打印消息1、更新该会员的记录;如果code=2则打印消息2二义性：逻辑-条件运算ORIfAorBThenC如果投入的硬币是5角或1元，则接收该硬币(XOR) ANDIfAandBThenC如果是会员且是高级会员，则享受XX%优惠(AandBtogether) 混合运算IfAorBandCThenD如果是在职员工或者二年内退休员工且没有享受过优惠if[AorB]andCthenDifAor[BandC]thenD？二义性：逻辑-条件运算NOTIfnotAorBthenC如果不是俱乐部成员或者code=2则采用规则1双重否定如果没有通过期末考试，则无法通过这个课程如果通过期末考试，则通过这个课程二义性：逻辑-规则间关系Rule1:ifeitherAorBgo,Hwillgo.Rule2:ifAdoesnotgowithC,Hwillgo.Rule3:ifBdoesnotgowithD,Hwillgo.ifBgoesandDgoes?Rule1:HwillgoRule3:Hwillnotgoif(eitherAorBgo)

and(AdoesnotgowithC)

and(BdoesnotgowithD)thenHwillgo.隐含的规则间关系：And二义性：逻辑-操作优先级如果我中了大奖、有足够的Money,则会买：

一辆10万元的汽车 一条100万元的房子 一套1000万元的游艇假如你中的是1000万元，你是买游艇、房子还是汽车？练习：识别二义性将输入的金额数与累计金额数相加，该数必须是正数。如果比赛时间定在周六或周日，我将会参加。如果下雨或下雪我们将打网球除非下大雨否则我们踢足球如果天太冷或雨下得太大，我们将不会打篮球如何处理二义性问题需求的形式化描述基于模型表示状态机、Petri网、因果图等形式化语言：Z语言、Prolog语言等需求的非形式化描述评审技术：review/walkthrough/Audit工程方法：操作场景分析/质量属性分析/功能交互分析如果你不能解决二义性的问题，那么就提出更多的问题。需求澄清-系统测试的起点建议质疑理解

对照需求属性产生质疑：1、不明确，可能造成多种解释2、相互之间描述矛盾、不一致3、对可能不符合要求的地方提出疑问

对需求提出深层次问题1、不正确、背离用户真实需要2、需求场景上的缺失3、对需求合理性提出探讨文档表述有助于需求理解：1、可读性好，表达陈述清楚，容易理解2、结构完整，没有章节缺失3、名词术语贴切解释需求澄清：需求用语检查要求从文档用语和语气入手，发现浅层次的问题。识别需求中有歧义用语，减少需求二义性表达。检查方法模糊用语检查。是否避免使用了一些代表可能、不确定、未量化的词。模糊语气检查。是否避免采用否定和疑问句式来阐述需求。设计用语检查。是否采用了一些与内部实现相关的用语。

分类关键词示例指代对象模糊代词、参照、缩略语、多个对象该处理同上一版本可能性可能，也许，大约大约允许1000用户频度词通常，一般，正常，典型，经常、有时候对于操作员来说，有时候需要重新初始化该信息定性词非常，很，高，一定，基本，快速通用，灵活，友好非常稳定，可靠性很高，高可用性，符合基本要求，系统快速响应，用户界面友好，系统通用、灵活否定词不正常系统运行不正常设计用语过程，函数，类，对象需求澄清:5W1H分析法需求场景原因（何因Why）、对象（何事What）、地点（何地Where）、时间（何时When）、人员（何人Who）、方法（何法How）反复应用Whatif需求澄清：示例【需求描述】

对于处理1，则输出姓名、地址、实际YTD值对于处理2，则显示要求的YTD值Why：该处理的上下文？What:处理1/处理2、YTD的含义？Who:谁负责输出和打印When:何时满足什么条件输出？Where:打印和输出在哪儿？HOW:输出格式?如果非1或非2则如何处理？微软面试题： 针对一次性杯子来进行测试设计案例：一次性杯子功能非功能质量属性规格(1)杯子的容量(2)杯子的型状(3)杯子的材料(4)杯子的抗摔能力(5)杯子的耐温性(1)装水/倒水/喝水功能(2)检查与报警功能

(3)加热与降温功能…(1)性能

(2)安全性

(3)易用性(4)移植性(5)兼容性

(6)可靠性界面测试:查看杯子外观功能测试：-用水杯装水看漏不漏；水能不能被喝到；水能不能倒掉

-当水超温时会不会告警；

-用水杯装不同升水（空/半/满），会不会能看出它当前量

-用水杯装不同温度水，是否会启动相应的加温或降温功能；

-当水温/容量超限时，是否会告警；安全性：装入不同液体，是否会有化学反应；装入热水杯子是不是会变型和异味可靠性：-杯子从不同高度落下的损坏程度

-反复触摸外形图案是否会掉色；长时间使用图案是否容易剥落可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等易用性：杯子是否烫手、是否有防滑措施、是否方便饮用用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述疲劳测试：

-将杯子盛上水放24小时检查泄漏时间和情况；

-盛上汽油放24小时检查泄漏时间和情况等压力测试：用根针担在上面并在针上面不断加重量，看压强多大时会穿透跌落测试：杯子加包装(有填充物)，在多高的情况摔下不破损震动测试：杯子加包装(有填充物)，六面震动，检查产品是否能应对恶劣的铁路\公路\航空运输练习：需求澄清有某《指纹学生签到系统》的需求描述：假如你想钻系统的空子，看看能不能逃了课还能签到？某《指纹学生签到系统》需求描述：8点钟开始上课八点之前签到同学会在系统记录八点到八点十分，和八点十分到八点五十签到的同学，系统会记录其签到时间，并做迟到和旷课的记录。系统对有迟到，旷课一节和未签到的同学按照班级进行分组，生成有学号，姓名，签到时间，以及作何处理的信息，在九点之前将每个上课班级的信息反馈到辅导员处。第二节课9点开始上课对八点五十之前未签到的同学进行记录八点五十到九点签到系统记录为旷课一节到九点十分之前签到的系统记录其为旷课一节，迟到一次，九点十分到九点五十签到和未签到的系统会记录其旷课两节，对九点五十还未签到的同学系统记录其旷课两节.系统对之前的系统内的存储的信息进行更新并生成记录单反馈到班级相应辅导员处目录系统测试基本概念1功能测试5非功能测试3需求静态测试２4回归测试功能真的OK吗？各种配置、各种数据、各种分支下均OK才算完全OK。微博功能正常吗？淘宝网购物功能正常吗？

在任何网络环境、用任何终端、进行任何操作、发送任何信息（任意内容、任意长度、任意类别媒体数据）都可以正常吗？在任何网络环境、用任何终端、进行任何操作、购买任意商品、任意买家、任意金额、采用任何购买方式都可以正常吗？系统功能测试的定义定义：根据系统规格说明书的功能需求，检验被测系统是否满足其使用要求。功能：一组输入、行为及输出的组合来表示，它会列出特定的结果。而非功能则表示设计/实现的限制条件，体现为系统一些整体特性

(来源wiki百科功能)测试对象：系统测试依据：系统规格说明书发现的缺陷：除了单个功能缺陷外，还可以发现由于功能间相互作用、系统环境等方面所引发的问题。名词术语功能测试内容可以归为界面、数据、逻辑、操作、接口几个方面。程序安装、启动正常，有相应提示框、错误提示每项功能符合实际要求系统的界面清晰、美观菜单、按钮操作正常、灵活，能处理异常操作能接受正确数据输入、对异常输入有提示、容错处理数据输出结果准确、格式清晰、可以保存和读取功能逻辑清楚，符合使用者习惯系统各种状态按业务流程而变化支持各种应用环境、配套周件硬件设备软件升级后，能继续支持旧版本的数据。与外部应用系统的接口有效。（来源：书上P131页）案例：继承性功能不见了【案例】导入导出功能丢失导致用户数据升级受阻。

某产品新版本发布后，发现原有版本配套工具的导入导出功能不见了。该工具在版本升级时，可以辅助用户将数据进行迁移。 经分析，新版本是合入用户的一个新功能，在合入版本时，不小心合漏了。由于原有配套工具没有作修改，故测试也没有纳入测试范围。原有功能需求也要纳入测试范围。案例：测试观察遗漏【案例】由于数据库标志位未更新损失若干。 某系统在节假日高峰期首次发送消息失败，后定时重发成功，但却忘了更新数据库中相应标志位。后来计费任务定时启动，根据数据库中标志位，导致这一类消息均没有收费。

测试后除了观察到界面即时成功外，还需要对数据库等作进一步验证。功能测试设计整合测试DNA应当具有：系统范围内思考问题的本能、分解问题的技能、对提高产品质量充满热情、喜欢研究事物是如何工作、又怎样能被搞坏。----windows测试主管GrantGeorge （来源：《微软的软件测试之道》)ModelsCreatebasetestcasesSuppementwithtestdataAdvancedtesting测试对象建模模型覆盖填充数据Model外的测试对象分析测试用例设计测试需求分析测试点分析观察点分析测试需求完整功能测试设计过程Step1：测试需求分析。确定测试范围。Step2：测试对象分析。测试建模的过程，弄清楚测试对象的业务处理过程、涉及关键数据。Step3：测试点分析。从哪些地方开展测试，测试覆盖在此体现。Step4：观察点分析。从哪些地方对测试结果观察。Step5：测试用例设计。包括逻辑用例、物理用例。测试对象分析测试用例设计测试需求分析测试点分析观察点分析Step1:测试需求分析“测什么”收集测试需求，它是多来源的，包括：新需求、协议规范、原来版本老需求如果有输入需求，则首先对需求进行澄清如果没有输入需求，则通过逆反工程整理出需求清单需求形式也可以多样的，包括：正式需求文档（SRS/UserStory)、邮件、会议纪要等。测试需求分析确立测试范围新需求文档协议规范原有需求现有系统需求澄清继承性分析逆向/遗产工程测试依据开发是增量的测试是全量的发布一条纯文本微博，允许含超链接、@某人微博内容字数不超过140字相同内容10分钟内不允许重发微博发布范围：公开/按分组/仅自己可见；对于分组可见允许分组成员数最多不超过200个微博发布信息体现微博来源：各类终端客户端/PC微博应用/第三方应用等，-对于各类终端显示终端型号，例：iPhone客户端,iPad客户端-对于PC微博客户端显示微博类型，例：专业版微博、媒体版微博、普通微博页面-对于第三方应用显示应用名称。例：人民日报微博。微博发布信息体现发布时间，精确到秒微博发布后，初始的评论/转发/赞数均为0微博发布后，如果粉丝在线没有屏蔽该人的微博，则首页新微博提醒计数器累加。微博发布后，如果@某人打开了@提醒设置，则获得@我通知，相应计数器累加。暂不考虑话题（##视为普通字符）暂不考虑内容审查暂不考虑长微博暂不考虑好友圈微博暂不考虑定时发布暂不考虑图片/视频/语音/投票/表情等暂不考虑访问频率限制暂不考虑防盗链等安全性考虑（假设发布人已通过了权限安全认证）Step2：测试对象分析描述功能是如何实现的。功能流程分支如何、涉及到的接口数据。往往采用IPO分析。由此了解：输入是如何转化为输出的微博内容解析Step3：测试点分析从证实的角实，分析：测试覆盖及数据取值。根据对象分析，从输入/处理/输出逐点提取测试点。可以分层分步骤进行。按功能流程，覆盖到每条路径、每个路径的可能条件及取值说明。从证伪的角度，分析：XX功能有没有可能产生错误？根据上面的测试对象分析，有哪些测试点？

·微博来源获取：每种来源的枚举 对于终端客户端：覆盖典型机型(iPhone/iPad/Android)

对于微博桌面：覆盖普通/专业版等典型应用版本 对于第三方应用：选取1～2个典型应用不同来源之间的交叉，例：某个第三方应用通过手机客户端发布，此时微博来源如何显示

·探索要点： 有没有可能微博来源获取不到信息？ 存不存在某条微博有多个来源信息？Step4：观察点分析观察测试结果的地方，以确认测试是否通过、是否存在BUG。该功能操作可能会影响到的地方；观察点除了最终结果外，还可以设在包含中间操作步骤结果的地方。可以观察到的输出包括：界面、数据库、接口、文件。观察点愈全面愈好。发布微博有哪些观察点？发布微博是否成功、发布成功提醒框是否自动消除发布微博内容是否与输入信息一致（内容、来源、时间等），所含链接是否有效此人的微博数变化是否正确所发布微博可见范围是否如设置、粉丝的新微博提醒计数器是否正确所发布微博@人是否通知到、@通知的计数器是否正确Step5：测试用例设计测试用例包括逻辑测试用例、物理测试用例。逻辑测试用例代表一批逻辑用例，一次参数取值就是一个物理用例测试用例主要属性：用例标题：点明测试目的预置条件：被测对象需要达到的状态测试步骤：测试行为预期结果：由测试观察点而来，往往有多条测试用例包括人工测试用例自动化测试用例用例标题、预期结果是主要属性。操作步骤：手工测试用例往往与自动化测试用例合一通过测试设计得到的是手工测试，往往只是逻辑用例，通过自动化用例中数据不同衍化成不同物理用例用例标题…预置条件…测试步骤预期结果步骤1…

步骤2…

……

Given-when-Then三段式测试用例示例用例标题照相机单张拍照预置条件闪光强制关闭，电池充足测试步骤·镜头对着拍摄对象，按下“快门”键·按向下翻页键，浏览刚拍的照片预期结果可见刚拍下的照片，照片正常照相机单张拍照闪光强制关闭，电池充足·用相机镜头瞄准拍摄对象，对焦框对准焦点，准备好,按下快门键·注意听按下快门键的咔嚓声·检查拍照过程中，观察指标灯的状态变化·照片保存过程中，观察相机屏幕显示的变化·检查照片保存的正确性·按下快门键后，1秒内听到两次连续“咔嚓”声·拍照过程中，拍照指标灯连续以绿灯闪烁3次·照片保存过程中，相机屏幕为黑色，并伴随出现一个沙漏型光标在屏幕中间运动。约3秒后屏幕恢复为照相模式(来源：《软件测试之魂》肖利琼)练习：测试设计用例标题输入9，点击下一位输入99，点击下一位输入999，点击下一位输入9999，点击下一位输入99999，点击下一位输入999999，点击下一位输入9999999，点击下一位输入99999999，点击下一位输入999999999，点击下一位输入9999999999，点击下一位某自动叫号系统，编号范围默认从1开始，最大为10位数字；可以手动输入从指定编号开始，点击“下一位”时编号自动加1并取号；当达最大值后，自动回到1。用例标题相同位数递增：1位相同位数递增：多位不同位数递增：2位跳到3位不同位数递增：3位跳到2位刚好小于最大编号刚好等于最大编号默认值缺陷报告描述一个缺陷产生的过程或现象，报告给开发人员。名词术语当输入的年份是闰年、输入2月28号时，输出的却是3月1号。发生条件产生结果如何写好缺陷报告缺陷标题：简明扼要、描述清楚条件和结果，突显缺陷价值示例：大呼叫量访问下，所有业务中断，无法恢复，只能重启系统缺陷内容：环境配置：在XX组网XX配置XX状态下操作步骤：做了XX操作问题现象：在XX地方观察到了XX现象现场证据：收集到了XX数据（可附件）象讲故事一样去描述一个缺陷What:缺陷是什么？When:什么时候，多长时间，频率如何？Where：在哪儿发现的？How:缺陷如何发生的?Who:影响用户群及用户数量？Why:为什么是问题？(5W1H要素)缺陷报告里的附件信息界面信息：输入、输出日志打印消息：内部处理流程、数据和状态变更数据库：表的数据、状态接口消息：发送和接收消息内存信息：缓存数据、内存数据从哪里可以发现缺陷证据信息？这些信息怎么获取？图片：现场截屏日志文件数据库导出抓包。抓包工具内存Dump附件包括：环境数据（组网、配置文件等） 证据数据（界面截图、日志文件、DB、接口等）缺陷处理方式A改变感知：B改变产品:即修改BUGC改变期望：D忽略感觉有问题的人；有人说，缺陷是个人对产品的一种感知。消除缺陷方式有：【示例】日本地震后引起国人核辐射问题的恐慌：中国政府对该问题的处理方式：

A中国各地辅射环境监测、及时发布监控结果，让国人明白自己感知不真实

B积极督促日本进行核泄漏问题的处理

C专家说：即使放射性物质真向中国转移，经过1000多公里，浓度会降低修改BUG非唯一处理方式缺陷生命周期ReOpen修复缺陷需要走回归测试流程目录系统测试基本概念1功能测试5非功能测试3需求静态测试２4回归测试引子缺陷修改案例某系统的权限管理缺少对某功能A的权限字支持，修改后，发现功能A权限字可以设置、但设置后的权限并没有真正生效。用户发现某个超长文本框不能输入换行，要求增加支持。修改后，发现还有类似的很多超长文本都无法输入换行。某系统在输入某参数X后界面不显示，修改后，发现参数X界面可以显示了，但值超出范围后会引起界面错误。理论基础缺陷集群论缺陷屏蔽缺陷修复后是否真的就OK了？回归测试的目的

所做的修改达到了预定的目的，如错误得到了改正，新功能得到了实现，能够适应新的运行环境等；不影响软件原有功能的正确性。回归测试的定义指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。只测试修改部分的用例行不行?修改影响！回归测试的策略!

测试全部的用例行不行?成本太高！名词术语回归测试策略：冒烟测试来源源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试应用到软件测试，源自微软。《微软项目求生法则》一书第14章“构建过程”关于冒烟测试就是：开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障测试策略对新版本基本功能确认的测试，以确认是否可以进行后续的正式测试工作。又叫版本健康检查(BuildSanityCheck)。往往用在开发人员自测试。最低的质量要求快速经济，“仅用一袋烟功夫足够了回归测试策略：修改影响分析了解修改/BUG的前世今生了解更改原因：特别是新需求合入了解设计修改方案了解代码实现。可以用工具进行代码比较、分析差异性。例BeyondCompare了解相关依赖。该修改涉及到的相关/相似功能点、影响路径分析。从业务流和数据流分析。在回归测试文档或问题单里,开发往往也会作出这样说明：修改清单、影响路径、测试建议等回归测试策略确立(结构)(行为)(风险)有没有更精准的自动化回归测试策略？66ReducingCostofRegressionTesting(©2012ProfessorW.EricWong,TheUniversityofTexasatDallas)6666基于修改的自动化回归测试策略67ReducingCostofRegressionTesting(©2012ProfessorW.EricWong,TheUniversityofTexasatDallas)6767基于修改的自动化回归测试策略686868基于修改的回归测试策略最小用例集高优先级用例集修改影响用例集代码与用例关联回归测试的完整过程(1)识别出软件中被修改的部分；(2)从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。(3)依据一定的策略从T0中选择测试用例测试被修改的软件。(4)如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。(5)用T1执行修改后的软件。 第(2)和第(3)步测试验证修改是否破坏了现有的功能， 第(4)和第(5)步测试验证修改工作本身。TIPS:回归测试可能涉及测试用例的变更：新增、修改、删除练习：回归测试假如Flight的航班预订功能增加对往返机票的新需求支持，你觉得需要作哪些部分的回归测试?Round目录系统测试基本概念1功能测试5非功能测试3需求静态测试２4回归测试曾经发现在我们身上的这些个案例北京奥运票务中心刚启动就因为购票者太多而被迫暂停空调故障后12306订票系统无法使用CSDN的上百万用户数据被窃取。迪斯尼游戏光盘只能在少数PC机上运行锤子手机设计了左右两侧双按键，适合左右手不同习惯的用户使用可靠性测试兼容性测试可用性测试安全测试性能测试非功能测试非功能性：软件系统“做得怎么样”非功能测试依据质量属性展开测试，描述了整体系统能力特征。质量要求转化为有指标的质量特性，质量才可以度量非功能测试是对功能好坏的测试，针对不同测试从不同剖面应用不同测试技术；非功能测试可以应用在任何测试级别上，主要在系统测试级展开较为全面。引子：试试这个游戏站点的承受力怎么测？怎么衡量？性能测试概念和目的性能测试的概念通过测试来确定系统运行时在一定负载（正常/峰值/非常规）下的性能表现，包括：处理能力、响应时间、系统资源占用率等方面的数据。性能测试的目的验证系统的性能指标发现系统的性能问题、存在的性能瓶颈系统性能调优性能测试的理论基础排队理论：请求服务的对象数量>响应服务的容量名词术语系统负载在线用户：访问登录系统的用户数并发用户：在同一时刻做同样的操作与系统进行交互。例：同时提交订单。事务数：事务由一系列请求构成，代表一个完整的用户业务过程。吞吐量：单位时间内成功传输的数据量。数据量取决于数据单元。包括：Bit/字节/分组/请求/页面等。例：WEB服务可以定义为HTTP请求数/秒或页面数/秒系统负载一般往往体现为并发用户数性能测试的分类指标测试在规定的条件下，相对于所用资源的数量，软件产品可提供适当性能的能力（ISO9126的效率性） ——狭义的性能测试往往指的此。压力测试又称强度测试、负载测试。模拟实际应用的软硬件环境及用户使用过程中的负载，长时间超负荷运行。容量测试在满足性能指标的情况下，确定系统最大承受量。例如：系统最大用户数，最大存储量、最大同时在线用户数等。它往往体现为数据管理能力,消耗存储或内存等资源，对（数据库）数据处理能力有要求。指标测试/压力测试/容量测试设法破坏它!一定负载、一定数据量下持续运行一段时间测试目不同，但一定程度上测试手段和方法比较相似，即：使用特定测试工具，模拟一定的负载、数据量，持续运行一段时间，观察系统反应、性能状况。系统性能百度百科对产品性能的定义：指产品具有适合用户要求的物理、化学或技术特性ISO9126对性能定义：在既定条件下相对于所提供的资源数量来说，系统对于及时性目标的符合程度。既定条件包括：环境配置（硬件、操作系统、数据库、网络、应用服务器等）约束、数据规模约束、处理复杂度约束等。资源：CPU/内存/IO/网络带宽等及时性：时间相关特性。系统性能通过量化指标来体现性能测试基准性能指标的定义业务执行的平均响应时间：<5s交易量>=100TPS同时在线用户数：1000万管理用户数：1亿正常处理情况下，CPU的利用率<50%，内存占用小于80%通话接通率：95%

服务提供能力服务提供质量资源占用率容量同时在线用户数单位时间内处理能力(吞吐量)每秒事务数(TPS)并发用户数响应时间响应率成功率时延性能指标如何定义？性能指标值的估计基于实际业务量来确定处理能力某系统年事务数：1400000日平均访问量：1400000/365日=3835/日每工作日8小时，折合每分钟完成事务数： 3835/8*60分钟=7.98/分钟，约为8次/分钟基于80/20法则来确定访问量高峰：80%量集中在20%时间高峰日访问量：1400000*80%/(365日*20%)=15340/日日访问量高峰：15340*80%/(1.6*60分钟)=127.8/分钟，约为128次/分钟并发用户峰值数：128*80%=102，约为100个并发用户并发用户平均数：7.98*80%=6.38，约为6个并发用户性能负荷模型Load也称“呼叫模型”，即：采用什么样的方式、以怎样的速度和用户分布来确定系统的负荷。不同应用的用户数量和比例不同应用的平均并发数和峰值并发数不同时间内用户分布（均匀／线性／正态／泊松）和到达速率不同的请求间隔、请求时长示例：性能测试设计性能测试执行要点测试环境准备：应尽量与产品运行环境、指标定义要求保持一致测试场景（流程模型/负荷模型/数据模型）尽量模拟用户行为、真实使用场景。测试工具和脚本:需要测试人员事先编制和调测完成。例：测试基础数据的生成和导入的工具和方法累积效应。压力测试在运行完毕后有可能申请占用内存没有完全释放。所以不要每次重启系统，让问题再累积、放大，最终崩溃。工具接口模拟能力负荷模拟能力统计分析能力

性能测试执行跑起来后，重点在于：前面数据收集与后期数据分析。性能测试数据收集资源占用：操作系统/数据库/应用进程的CPU/内存/IO/网络等资源占用情况的定期采用，一般1S采集一次。软件的业务性能表现：响应时间、事务数TPS、吞吐量等。性能计数器：根据阀值、趋势、总量等信息来分析判断vmstat：虚拟内存的统计(cpu/io)iostat：设备的IO统计netstat：网络活动信息统计top： 内存统计cat/proc/meninfo：系统总men大小cat/proc/cpuinfo：系统总CPU大小df

–k： 系统硬盘大小Linux资源收集命令性能测试数据分析

负载-性能关系图：出现响应时间显著延长的位置即为“拐点”。可以确定是否需要增加资源以支持额外的用户。性能指标值完整性能测试过程性能测试(指标)需求分析性能测试对象分析性能测试方案确定性能测试执行性能测试评估测试分析设计系统行为分析系统结构分析测试流程数据模型负荷模型测试观察点示例:性能测试瓶颈分析

以下系统架构将会遇到什么样的性能问题？可靠性的概念

可靠性（Reliability）定义：产品在规定的条件下和规定的时间内完成规定功能的能力，它的概率度量称为可靠度。软件可靠性是软件系统的固有特性之一，它表明了一个软件系统按照用户的要求和设计的目标，执行其功能的可靠程度。软件可靠性与软件缺陷有关，也与系统输入和系统使用有关。理论上说，可靠的软件系统应该是正确、完整、一致和健壮的。要么不发生问题，要么出了问题尽快恢复名词术语可靠性测试的切入点缺陷（人为）错误故障（第三方）故障失效引入激活（人为）错误引入引入缺乏容错……故障缺乏容错最后一道防线：预防错误->发现错误->容忍错误可靠性测试可靠性测试是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。如当系统出错时，能否在指定时间间隔内恢复系统业务正常。包括两个方面：异常测试：输入异常数据或进行异常操作，以检验系统的异常保护性。如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。例：有意输入不符合规定的数据(配置文件为空、接口数据不符合协议等)故障测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能尽快恢复。故障测试Failover测试:故障切换(Failover)和故障恢复(Failback).服务器的Failover测试的目的:检查系统是否具备某种灾难性恢复的手段.当系统局部或全部出错时,能否在指定时间内修正错误.具有良好故障恢复的系统,当遇到软件原因或无法克服的自然原因时,能够进行故障的转移与恢复.使用户最低限度的感受到故障的发生.在服务器的Failover测试中,将包括多种情况,如:客户机或服务器掉电;客户机与服务器网络中断;服务器相关的程序CRASH;系统中全部或部分CORESERVER出现掉电/网络中断情况.故障发生后，检验到故障并记录日志故障发生后，重要故障上报告警故障发生后，故障检测及上报告警时间满足要求，不出现故障发生后迟迟不能被发现（例：大于3分钟）故障发生后，上报信息(告警/日志)反映故障现象本身(例:名称/简述/附加信息)故障发生后，故障定位对象与发生位置相符,可以指标到故障具体可操作单位(以交付客户对象清单为准)故障发生后，相同故障不重复上报,造成信息泛滥故障发生后，故障容错措施（放通/切换/重启/流控等）生效,保证业务部分或全部可恢复可用故障发生后，业务恢复时长满足要求，不出现业务长时间中断故障发生后，周边网元运行状态正常,不出现莫名core、重启或无响应假死等现象故障发生后，业务/配置数据容错保护，不出现错乱、丢失、不一致等。故障消除后，检验到故障恢复并记录日志故障消除后，上报告警被清除，不出现相关告警清除不完全或误清除的现象故障消除后，故障检测及上报清除告警时间满足要求，不出现故障清除后迟迟不能被发现故障消除后，自身与周边网元状态恢复正常，与周边的网元连接恢复正常故障消除后，业务恢复正常故障消除后，内存/CPU/IO等资源占用正常故障消除后，原有的容错措施（放通/流等）自动取消，恢复到原有业务处理状态故障消除后，不出现长时间故障所累积业务量过大造成新的故障。例：缓存消息一次性发出造成消息风暴示例：可靠性测试

在这个构造中，当其中一台Application服务器出现故障，连接此服务器的两个web服务器将不再获得从负载平衡服务器上请求，这样，所有的负载都会传递到剩余的两台