还剩36页未读，继续阅读
本资源只提供10页预览，全部文档请下载后查看！喜欢就下载吧，查找使用更方便
文本内容:
第一章测试基础软件测试的目的证明（表达软件可以工作）一检测（发现错误）f防止（管理质量）测试执行单元测试（UT执行）一个测试用例的测试执行；
1.集成测试（IT执行）一个测试用例集的测试执行；
2.系统测试（ST执行）不同测试阶段的测试执行
3.测试用例（Test Case）指对一项特定的软件产品测试任务的描述，体现测试方案、方法、技术和策略测试和调试的区别测试调试定位错误，修改程序以修正错误目的找出存在的错误文档，代码对象代码有特定流程，有计划性无特定流程，不可设计，无计划性流程从已知条件开始，用预定义过程，有预知从未知条件开始，结束过程不可预计条件结果
4.回归测试的目的a.验证错误是否修复；
5.b.检测对代码的修改是否引入了新的错误软件测试的重要工作a.检视代码，评审开发文档；b.进行测试设计，写作测试文档（测试计划、测试方案、测试用例等）；
6.c.执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终得到了修正；
7、数据流相关概念数据的定义；数据的引用（环节3）数据流分析的作用分析代码中关于数据定义和引用方面的错误；进行代码优化（赋值语句运算效率高）信息流分析输入变量和语句关系；语句和输出变量关系；输入和输出变量管
8、理（环节4）覆盖率工具的作用•分析被测试代码控制结构，决定插装位置；•实行插装；•将插装代码重新编译；
9、•执行被测对象，根据插装的监控哨信息记录覆盖率白盒测试的特点•测试人员需要了解软件的实现；•可以检测代码中的每条分支和途径；•揭示隐藏在代码中的错误；•对代码的测试比较彻底；•实现代码结构上的优化；•白盒测试投入较大，成本高；•白盒测试不验证规格的对的性什么是黑盒测试•黑盒测试把被测对象当作一个黑盒，只考虑其整体特性，不考虑其内部具体实现；•黑盒测试针对的被测对象可以是一个系统、一个子系统、一个模块、一个子模块、一个函数等•黑盒测试又可以被称为基于规格的测试
10、常见的黑盒测试类型功能性测试；容量测试；负载测试；恢复性测试
11、常见的黑盒测试方法等价类、边界值、因果图、鉴定表、状态迁移、正交分解、错误猜测、输入/输出域覆盖、系统测试的时候，假如没有SRS时，有两类BUG无法发现1）需求漏掉；2）需求偏差黑盒测试的优点•对于更大的代码单元来说（子系统甚至系统级）比白盒测试效率要高；•测试人员不需要了解实现的细节，涉及特定的编程语言；•从用户的视角进行测试，很容易被大家理解和接受；•有助于暴露任何规格不一致或有歧义的问题黑盒测试的缺陷•没有清楚的和简明的规格，测试用例很难设计；
12、•不能控制内部执行途径，会有很多内部程序途径没有被测试到；
13、•不能直接针对特定的程序段，这些程序也许非常复杂（因此也许隐藏更多的问题）动态和静态测试的分类依据在于被测对象是否运营起来
14、手工静态分析一一同行评审正规检视；技术评审；走查
15、评审对象计划、需求文档、设计图、代码等
16、自动化静态分析静态验证；语法分析器；符号执行器1自动化测试应当考虑的因素2测试进度规定3人力资源规定4版本稳定度5版本应用情况6可自动化率7版本规模1自动化测试的误区:一2自动化不能取代手工测试3手工测试都做不好，或者经验积累不够，就尝试自动化，很难成功自动化只能保证测试执行效率，保证已有的问题不会再发生，自动化测试不能发现大量新缺陷进行了自动化测试的软件不一定就是安全的，质量有保证的所以手工测试是自动化测试的一个基础1自动化五大等级2录制和回放3脚本4自动化框架脚本5数据驱动6关键字驱动自动化测试的限制板书自动化测试不具有想象力，不可以检查脚本中给定的观测点之外的错误;•自动化测试只能提高测试效率，不能提高测试效果，不能发现比人工测试更多的问题；如被测对象不稳定，存在变动性的话不适合开展自动化测试，否则脚本的编写和维护所花费的时间也许远大于人工测试；•只有手工测试积累到一定限度（提供更多的观测点），才干做好自动化测试第四章测试过程1）各阶段测试的目的2）单元测试检测软件模块对《具体设计说明书》的符合限度
2、集成测试检测软件模块对《概要设计说明书》的符合限度
3、系统测试通过与《需要规格说明书》作比较，发现软件与系统定义不符或与之矛盾的地方目的考察范围测试方法评估基准单元、集成、系统测试的比较测试类型单元消除局部模块的逻辑和功能单元内部逻辑覆盖率大量采用白盒测测试上的错误和缺陷（消除单元、的数据结试方法模块内部的逻辑和功能上的构、逻辑控错误与缺陷）制、异常解决等集成找出与软件设计相关的程序接口和接接口覆盖率结合使用白盒与测试结构，模块调用关系，模块口数据传黑盒测试方法，较间接口方面的问题（找出与递关系、模多采用黑盒方法软件架构设计相关的程序结块组合后构造测试用例构，单元/子模块间的调用关的整体功（也有说法叫灰系，单元/子模块间接口方米能盒测试方法）那的问题）系统对整个系统进行一系列的整整个系统测试用例对需黑盒测试测试体、有效性测试（对系统规对需求的求规格的覆盖格中的功能与性能进行一系符合度率列的有效性测试）回归测试策略完全反复测试;选择性反复测试（覆盖修改法；周边影响法；指标达成方法；选择重要级别高的测试用例）1）回归测试流程2）在测试策略制定阶段，制定回归测试策略3）拟定需要回归测试的版本4）回归测试版本发布，按照回归测试策略执行回归测试5）回归测试通过，关闭缺陷跟踪单（问题单）
4、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试
5、有用户参与的其他一些测试验收测试、a测试、8测试a测试与B测试的Alpha测试Beta测试比较测试环境开发环境或者模拟实实际使用环境际操作的环境下可以是终端用户也可测试人员终端用户（涉及潜在用户）以是公司内部的用户有开发人员在场，事实开发人员通常不在测试现开发人员上是一种受控的测试场，测试情况通常不受控是否在场比较Alpha测试关注软件产品的FLURPS（即功能、Beta测试着重关注产品的局域化、可使用性、可支持性，涉及文档、客户关注点靠性、性能和支持），培训和支持产品的生产能特别注重产品的界面力和特色共同点
1.都希望从实际终端用户的使用角度来对软件的功能和性能进行测试，以发现也许只有终端用户才干发现的错误；
2.都不能由测试人员和程序员完毕；
6、重要的测试文档测试计划；测试方案；测试用例；测试规程；测试报告；测,•试日报验证与确认VV:验证VERIFICATION强调过程；确认VALIDATION强调结果VV模型优点-实现了测试设计和测试执行相分离；•揭示了软件测试活动分层和分阶段的本质特性测试执行的顺序与开发活动相反VV模型:TTTA二也申M二洞心才士安二八；,系统测试阶段输入输出
11.系统测试分为几个阶段，每个阶段的输入/输出是什么？
1.软件开发计划系统测试计划计划阶段
2.软件测试计划
3.需求规格说明书设计阶段
1.系统测试计划系统测试方案
2.需求规格说明书
1.系统测试计划
1.系统测试用例
2.系统测试方案
2.系统测试规程实现阶段系统测试
3.需求规格说明书
3.系统测试预测试项
1.系统测试计划
1.系统预测试报告
2.系统测试方案
2.系统测试报告
3.系统测试用例
3.缺陷报告执行阶段
4.系统测试规程
4.测试日报
5.系统测试预测试项
6.集成测试报告
1.软件测试计划集成测试计划计划阶段
2.概要设计说明书设计阶段
1.概要设计说明书集成测试方案
2.集成测试计划
1.概要设计说明书L集成测试用例
2.集成测试集成测试实现阶段
2.集成测试计划规程
3.集成测试方案
1.集成测试计划
2.集成测试
1.集成测试报告方案
3.集成测试用例
4.集
2.缺陷报告执行阶段成测试规程
1.软件测试计划单元测试计划计划阶段
2.具体设计说明书设计阶段
1.具体设计说明书单元测试方案
2.单元测试计划实现阶段
1.具体设计说明书
1.单元测试用例单元测试
2.单元测试计划
2.单元测试规程
3.单元测试方案
1.单元测试计划
1.单元测试报告2,单元测试方案
2.缺陷报告执行阶段
3.单元测试用例
4.单元测试规程第五章单元测试
11.单元的基本属性2明确的功能3可定义的规格4与其他单元接口的清楚划分
2.单元测试的目的ab在于发现各模块内部也许存在的各种错误，重要是基于白盒测试C验证代码是与设计相符合的；d发现设计和需求中存在的错误；发现在编码过程中引入的错误和设计不相符或和设计相符，但是由于编码疏漏引起
3.单元测试关注的重点批注体现软件的成熟也[XHC1]:犯错解决|、单元接口、局部数据结构、独立途径、边界条件_____
14.单元测试的重要关注点2参数的属性、顺序、个数是否与LLD一致3不能修改只做输入用的形参，否则也许导致数据的错误修改4约束条件是否通过形参来传送1驱动和桩的功能2驱动单元被测函数的主函数，能接受输入数据，输出实际
7.d.通过测试度量软件质量软件危机的出现重要表现在a.由于缺少大型软件开发经验和软件开发数据积累，开发工作计划很难制定；b.开发初期需求分析不够明确，导致开发后期矛盾集中暴露；c.不遵循开发规范，开发文档不完整，软件难以维护；d.缺少严密有效的软件质量检测手段，交付给用户的软件质量差
8.软件危机的后果a.软件质量不高，很难稳定；b.软件项目延期，进度无法控制；c.成本增长，无法控制预算软件危机的根源a.根据摩尔定律，硬件发展不久，相应对软件系统的盼望越来越高；
9.b.软件系统复杂性提高，需多人合作；
10.c.软件开发是人的智力活动，无法用已有的产业工程方法来组织管理软件生命周期的各个阶段计划一需求分析一设计一编码一测试一运营一评价
11.设计概要设计（HLD）:在设计阶段把各项需求转换成相应的体系结构,每一部分是功能明确的模块；
12.具体设计（LLD）:对每个模块要完毕的工作进行具体的描述
13.软件研发三要素人员、过程、工具软件项目组人员组成分析人员、设计人员、开发人员、测试人员、配置管理测试结果
7、桩单元用来代替所测单元调用的子单元单元测试策略孤立的测试策略、自顶向下、自底向上的单元测试策略1）孤立的测试策略•方法不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块每个模块进行独立的单元测试・优点该方法是最简朴，最容易操作的可以达成高的结构覆盖率该方法是纯粹的单元测试■缺陷桩函数和驱动函数工作量很大，效率低2）自顶向下的单元测试策略•方法先对最顶层的单元进行测试，把顶层所调用的单元做成桩模块另一方面对第二层进行测试，使用上面已测试的单元做驱动模块如此类推直到测试完所有模块•优点可以节省驱动函数的开发工作量，测试效率较高•缺陷随着被测单元一个一个被加入，测试过程将变得越来越复杂,并且开发和维护的成本将增长3）自底向上的单元测试策略•方法先对模块调用层次图上最低层的模块进行单元测试，模拟调用该模块的模块做驱动模块然后再对上面一层做单元测试，用下面已被测试过的模块做桩模块以此类推，直到测试完所有模块・优点可以节省桩函数的开发工作量，测试效率较高•缺陷不是纯粹的单元测试，底层函数的测试质量对上层函数的测试将产生很大的影响
5.单元测试的四个阶段•测试计划完毕单元测试计划；・测试设计完毕单元测试方案；令•测试实现完毕单元测试用例、单元测试规程、单元测试脚本及数据文献；令•测试执行执行单元测试用例，修改发现的问题并进行回归测试，提交单元测试报告单元测试桩驱动举例无论是单元测试还是集成测试都涉及到以下三个函数主控函数int Ctrlint x,int y加法函数int addint x,int y减法函数int subint x,int y注意进行单元测试时，设计用例时依据的是LLD；进行集成测试时，设计测试用例依据的是HLDo下面给出来的是需要测试的实际的代码int Ctrlint x,int yreturn temp;int subint x,int yint temp=0;int addint x,int yreturn x-y;ifx=ytemp=addx,returnx+y;y;elsetemp=subx,y；自顶向下单元测试策略令不同测试环节中的驱动可以写到一起，也可以分开写，这里是写到一起了/测试Ctrl函数需要写一个驱动和两个桩驱动函数void driverintret=0;ret二Ctrl⑵1;//xyprintfutestcase JISUAN_UT_CTRL_001pass”；if ret=3printftestcase JISUAN_UT CTRL001fail”；elseret=Ctrl1,1;//x=yif ret=2printfutestcase JISUAN_UT_CTRL_002pass“;elseprintf testcaseJISUAN_UT CTRL002fail;ret=ctrl1,2;//xyifret==-lprintfutestcase JISUAN_UT_CTRL_003pass”；elseprintf testcaseJISUAN_UT_CTRL_003fail”;＞桩函数int stubaddintx,int yintstub_subint x,int yifx==2y==lifx==ly=2return-1;return3;ifx==ly==lreturn999999;return2;return999999;＞修改代码为了让桩能体现在测试过程中，需要修改Ctrl函数:int Ctrlintx,int yinttemp=O;ifx=ytemp=stub_addx,y;el setemp=stub_subx,y;return temp;/测试add函数.驱动函数桩函数同测试Ctrl函数时的驱动同测试Ctrl函数时sub函数相应的桩修改代码int Ctrlintx,int y{inttemp=O;if x=ytemp=add x,y;if x=2y==ltemp==3printf testcaseJISUAN_UT_ADD_001pass;elseprintf testcaseJISUAN_UT_ADD_001fail;.if x==ly==l temp==2printf testcaseJISUAN_UT_ADD_002pass;elseprintf atestcaseJISUAN_UT_ADD_002fail;elsetemp=stub_sub x,y;return temp;}测试sub函数驱动函数桩函数同测试Ctrl函数时的驱动＞修改代码int Ctrlintx,int yinttemp=O;ifx=ytemp=addx,y;else{temp=subx,y;ifx==ly==2temp==-lprintf atestcaseJISUAN_UT_SUB_O01pass”;elseprintf atestcaseJISUAN_UT_SUB_001fail;}returntemp;}第六章集成测试1）集成测试的目的保证各组件组合在一起后可以按照既定意图写作运营，并保证增量的行为对的（属于灰盒测试）2）验证接口是否与设计相符3）发现设计和需求中存在的错误
2.集成测试关注的重点单元间的接口、集成后的功能
3.集成测试的层次模块内集成、子系统内集成、子系统间集成1）集成测试策略2）|大爆炸集成3）自顶向下集成4）自底向上集成批注[XHC2]:重要5）三明治（混合式）集成6）基干集成7）分层集成8）基于功能的集成9）基于消息的集成批注[XHC3]:实际中应用较多10）基于进度的集成11）基于风险的集成各种集成测优点缺陷合用范围试策略的优缺陷大爆炸集成
1.只要很少数的驱动和桩
1.一次运营成功的也许性不
1.维护型项目（增强型）
2.可并行工作，人力、物力大
2.每个函数都通过了充资源运用率较高
2.定位和修改错误比较困难足单元测试的小规模系统
3.可并行工作，人力、物力
3.会有很多接口错误进入到（特别是接口函数）资源运用率较高系统测试自顶向下
1.较早验证了重要的控制
1.桩的开发和维护成本大
1.产品控制结构比较清点和判断点
2.底层组件行为的验证被推楚和稳定
2.选用按深度方向组装的迟了
2.产品高层接口变化较方式，可一方面实现和验证
3.底层组件的测试不充足小一个完整的软件功能
3.产品底层接口未定义
3.功能可行性较早得到证或经常也许被修改实（带来信心）
4.产品控制组件具有较
4.最多只需一个驱动，减大的技术风险，需要尽早少驱动开发费用被验证
5.支持故障隔离
5.希望尽早看到产品的系统功能行为自底向上
1.允许对底层组件行为的1,驱动的开发和维护成本高
1.底层接口比较稳定、初期验证
2.对高层的验证被推迟到了变动较少的产品
2.工作初期可以并行进行最后，设计上的错误不能被及
2.高层接口变化较频繁集成时发现的产品
3.减少了桩的工作量
3.对高层的验证被推迟到了
3.底层组件较早被完毕
4.支持故障隔离最后，设计上的错误不能被及的产品时发现三明治集成集合了自顶向下和自底向上中间层在被集成前测试不充足大部分软件开发项目策略的优点基干集成具有三明治集成的优点
1.必须对系统的结构和互相大型复杂项目依存性进行仔细分析
2.必须开发驱动和桩
3.有些接口也许测试不充足基于功能集
1.可尽快看到关键功能的
1.对有些接口测试不充足，成/基于消息实现，并验证对的性会丢失许多接口错误集成
2.进度上要短
2.也许会有较大的冗余测试
3.可减少驱动的开发基于进度集
1.具有比较高的并行度
1.许多接口耍到后期才干验进度优先级高于质量的项成
2.能有效缩短项目开发的证，无法发现有效的接口问目进度题
2.桩和驱动开发工作量大
3.由于进度，组件很不稳定且会不断变动，导致测试的反复和浪费3•由于进度，组件很不稳定且会不断变动，导致测试的反复和浪费基于风险集最具有风险的组件最早进行需要对各组件的风险有一个清成验证，有助于系统的快速稳楚的分析定第七章系统测试1）系统测试目的2）通过与需求做比较，发现与系统定义不符合或与之矛盾的地方
2.系统测试的用例应根据需求分析说明书来设计，并在实际使用环境下运营
3.系统测试对象1）软硬件集合在一起的系统2）验证时应尽也许模拟实际的运营环境与条件
4.系统测试常用类型功能、性能、压力、容量、安全性、GUI、可用性、安装、配置、异常（恢复性）、备份、健壮性、文档、在线帮助、网络、稳定性测试1）功能测试2）概念根据产品的SRS和测试需求列表，验证产品的功能实现是否符合产品的需求规格a）目的为了发现以下几类错误b）是否有不对的或漏掉了的功能c）功能实现是否满足用户需求和系统设计的隐藏需求3）输入能否对的接受？能否对的输出结果？4）性能测试5）概念用来测试软件在集成系统中的运营性能6）目的度量系统相对于预定义目的的差距7）工具LoadRunner WebLoad、SilkPerformer重要性a）性能是质量的重要组成部分b）给用户树立良好形象c）节省成本的重要手段
5.性能测试的关键有效的协调、对的的模型、瓶颈的定位、合理的建议
6.性能需求五大特性需求行、代表性、完整性、可测试性、可用性1）压力测试关注稳定性和破坏性
7.目的调查系统在其资源超负荷的情况下的表现
8.目的通过极限测试方法，发现系统在极限或恶劣环境中自我保护能力，重要验证系统的可靠性1）容量测试2）目的使系统承受超额的数据容量来发现它是否可以对的解决关注点a）整体的业务流量（一般关注静态容量）b）数据库的容量c）最大文献数目d）最大事务数
9.安全性测试口令认证、加解密技术、权限管理、安全日记人员、SQA（质量保证人员）1）软件研发流程类型瀑布模型无风险控制能力，适合需求变化较小的情况2）螺旋模型基于风险管理的模型，高风险的优先考虑，对风险管理人员的规定较高3）RVP流程面向对象的，通用的（4大阶段，6大工作流，8项迭代）特点4）基于风险5）用例集驱动6）以架构为中心7）迭代和增量IPD流程1）产品结构重整（资源重整）2）公共模块共用
10.内容外观、界面元素行为、布局、和谐功能1）可用性测试关注点2）过度复杂的功能或指令3）困难的安装过程4）错误信息过于简朴5）用户被迫去记住太多的信息6）语法、格式和定义不一致配置测试概念测试系统在各种软硬件配置、不同的参数配置下系统具有的功能和性能
11.目的验证所有配置的可操作性和有效性，特别需要对最大配置、最小配置或特殊配置进行测试异常测试概念又叫系统容错和可恢复性测试，通过人工干预手段使系统产生软、硬件异常,通过验证系统异常前后的功能和运营状态，达成检查系统的容错、排错和恢复的能力它是系统可靠性评价的重要手段容错解决系统自动解决、人工干预解决系统可靠性指标平均失效时间间隔（MTBF）、平均恢复时间（MTTR）1）系统可靠性设计技术2）避开错误
12.容错技术结构冗余（动、静态）、信息冗余、时间冗余、硬件冗余、附加冗余技术健壮性测试Robustness Testing
13.用于测试系统在出现故障时，是否可以自动恢复或忽略故障继续运营网络测试:1）概念在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试,保证设备对接正常2）内容考察系统的解决能力、系统兼容性、系统稳定可靠性及用户使用等方面3）一致性测试检测系统与协议规范符合限度4）性能测试检测协议实体或系统的性能指标5）互操作性测试
14.坚固性测试检测协议实体或系统在各种恶劣环境下运营的能力系统稳定性测试目的是评价系统在一定负荷情况下、长时间的运营情况第八章测试覆盖率覆盖率概念•覆盖率是用来度量测试完整性的一个手段覆盖率是测试技术有效性的一个度量覆盖率二（至少被执行一次的item数）/item的总数；
1.•覆盖率大体可以划分为两大类逻辑覆盖和功能覆盖；
2.测试用例设计不能一味追求覆盖率，由于测试成本虽覆盖率的增长而增长
3.逻辑覆盖重要类型语句覆盖、鉴定覆盖、条件覆盖、鉴定-条件覆盖、途径覆盖语句覆盖率（Statement Coverage）,在测试时运营被测程序后，程序中被执行到的可执行语句的比率；语句覆盖率二（至少被执行•次的语句数量）/（可执行的语句总数）分支覆盖率（Branch Coverage）也叫鉴定覆盖（Decision Coverage）,它的含义是在测试时运营被测程序后，程序中所有判断语句的取真分支和取假分支被执行到的比率；鉴定覆盖率.二（鉴定结果被评价的次数）/（鉴定结果的总数）条件覆盖率（Condition Coverage）的含义是，在测试时运营被测程序后，所有判断语句中每个条件的也许取值（真值和假值）出现过的比率；条件覆盖率二（条件操作数值至少被评价一次的数量）/（条件操作数值的总数）分支-条件覆盖率（Branch ConditionCoverage）也叫鉴定条件覆盖（Decision ConditionCoverage）,它的含义是，在测试时运营被测程序后，所有判断语句中每个条件的所有也许值（为真为假）和每个判断自身的鉴定结果（为真为假）出现的比率；分支条件覆盖率二（条件操作树枝或鉴定结果至少被评价一次的数量）/（条件操作数值总数+鉴定结果总数）途径覆盖率（Path Coverage）的含义是，在测试时运营被测程序后，程序中所有也许的途径被执行过的比率；途径覆盖率二（至少被执行到一次的途径数）/（总的途径数）其他覆盖率功能覆盖率；面向对象的覆盖率；函数覆盖；指令块覆盖；鉴定途径覆盖第九章测试用例举例测试用例编号BOSS_ST_MARKETING_NEW_01P重要级别高（福有“较高、中、较低、低”几个等级）测试项目新增营销记录测试标题新增10元的营销记录用例类型基本领件（相应尚有“备选事件”、“异常事件”）用例设计者songfun设计日期2023-04-25相应需求编号REQ_MARKETING_NEW_01相应UI Marketing,htm相应UC UCMARKETING_NEW01版本号Build vO.1相应开发人员Frank预置条件操作员登录营销管理系统测试方法等价类划分（相应尚有“错误猜测法”、“边界值分析”等）输入用户名51testing性别男金额10元描述aaaaaaa操作环节
1.进入【营销下发】页面
12.点击『增长』按钮；
3.输入相应数据；
4.点击「拟定J按钮；
5.在后台数据库（tcst/test@testDB）输入查询语句验证select*from MarketingTabwhere ID=，100T
6.在后台数据库（test/tes台testDB）输入查询语句验证:select*from MarketingTabwhere ID=1001预期输出
1.执行环节
④后，页面弹出添加成功提醒信息框；
2.执行环节
⑤后查询数据库，记录的确添加成功且数据无误
3.执行环节
⑤后查询数据库，记录的确添加成功且数据无误第十章测试经验和误区1）软件测试的误区2）测试和调试是同样的3）测试组应当为保证质量负责4）过度依赖BETA测试5）把测试作为新员工的一个过渡工作6）把不合格的开发人员安排做测试7）关注于测试的执行而忽略测试的设计8）自动化测试是万能的9）测试是可以穷尽的10）测试是为了证明软件的对的性
2.测试是枯燥乏味，缺少发明力的工作1）软件测试的10大原则2）测试是一个连续改善的过程，而不是一个阶段3）测试必须被计划、被控制、并且被提供时间和资源4）测试应当分级别5）测试应当有重点6）测试不是为了证明程序的对的性，而是为了证明程序不能工作7）测试是不也许穷尽的，当测试出口条件满足时就可以停止测试8）测试是开发的朋友，不是敌人9）测试人员应当站在公正的立场上进行测试，如实的记录和报告缺陷10）自动化测试能解决一部分问题，但不是所有
3.测试不能仅仅涉及功能性的验证，还应当包含性能、可靠性、可维护型、安全性等方面的验证1）软件测试的10个最佳实践:2）尽早的、频繁的进行测试一一减少成本、提高质量3）尽早的产生一个综合的主测试计划4）对质量规定较高的产品或大型复杂的产品成立独立的测试组5）在每个开发阶段，使用测试和评价的结果作为是否可以通过的标准6）开发和维护一个测试需求和目的的风险优先级列表7）把测试作为产品的一部分等同起来，使用相同的评价标准和过程8）提供集成化的测试工具和测试技术支持9）加强测试度量工作和缺陷分析工作，不断地改善测试10）加强测试的培训并且为测试人员提供技能发展的通道加强沟通和交流，让项目组内所有人员都了解测试的重要性和测试的工作a同行评审a同行评审Peer Review是一种通过作者的同行来确认缺陷和需要变更区域的检查方法需要进行同行评审的特定产品在定义项目软件过程的时候被拟定并且作为软件开发计划的一部分被安排了进度b•需要前期准备、计划和时间进度表c•越早越好
2.同行评审的作用•初期发现缺陷；•去除缺陷；•减少成本；•提高质量同行评审的类型•正规检视Inspection最严格，规定有规范的流程，参与者通过正式培训；
3.•技术评审Technique Review以技术方案的比较、裁决为目的，严格限度介于正规检视和走读之间；
4.•走读Walk Through最自由松散的形式，无流程规定，有评审团队,评审流程无规定通用评审流程环节正规检视流程计划阶段:•项目负责人指定组织者•作者自检工作产品•组织者规划本次评审:•检查入口准则是否符合文档标准？是否己用工具检查？代码*500行；文档＜二40页；..•准备评审包工作产品（HLD）；参考资料（SRS-检查一致性）；评审表（Review Form）；查检表（Checklist）•指定评审专家（3-6人）；•组织者将评审包、评审告知单发给相关人员介绍会议•被评审对象采用新技术、新方法；・被评审对象第一次被评审少（作者介绍被审对象以及相关技术）•评审专家第一次参与评审玲（评审者介绍评审流程）•介绍会议的召开距接到评审告知的时间大于5小时；
4.介绍会议的时间不超过1小时，30-60间为宜，关注讲解准备阶段（最重要、发现缺陷最多）•评审专家个人独立完毕工作产品的审阅，提出缺陷；•准备时间大于会议时间，且应于会议前2天开始；•评审者收到组织者发来的评审包；审核工作产品、发现缺陷；填写评审表单；反馈评审表单给组织者；
5.组织者检查评审表单；裁决是否需要增长评审评审投入（增长准备时间；增长评审专家人数；更换评审专家）会议阶段（2小时内；只提出问题，不关注解决）•组织者召开评审会议；•讲解员讲解工作产品；（尽量不要由作者兼任）•大家共同确认问题（评审表单中记录的问题；会上发现的问题；当争执不下时组织者应做出裁决）•对已确认的问题进行分类；•作者决定是否召开第三小时会议;•记录员记录所有的问题及分类，并发给组织者；（记录员尽量不要山作者和组织者担任）•组织者更新评审表单
6.第三小时会议•有争议的问题继续讨论，给出决议；•讨论解决问题方案；•组织者更新评审表单
7.返工发回作者修改；跟踪•汇总所有需要的数据到评审表单发给相关评审专家；（J2组织者）•组织评审专家确认各缺陷得到了修改，并且没有引入新的缺陷；•协助组织者确认相关问题得到了对的修改并且没有引入新的缺陷；•确认评审表单中各相关度量数据对的（发现缺陷数；评审投入时间；评审专家人数等）（评审专家个2）软件开发工具自身隐藏的问题等g.等….缺陷类型漏掉、错误、额外的实现第二章软件质量
4、
3.影响软件质量的因素流程、技术、组织
5、流程一组活动（活动是否都是必须的，活动角色之间的关系）
6.CMM1:初始级，Initial,不可预测并且缺少控制；CMM2可反复级Repeatable,可反复以前的重要经验；（关键过程区域需求管理；软件项目计划；软件项目跟踪和监督；软件子协议管理；软件质量保证；软件配置管理）CMM3已定义级Defined,过程被描述，并得到良好理解；（关键过程区域组织过程定义；组织过程焦点；培训大纲；集成软件管理；软件产品工程；组际协调；同行评审）CMM4已管理级Managed,过程被测量并受控；（关键过程区域定量的过程管理；软件质量管理）CMM5优化级，Optimizing,关注过程改善（关键过程区域:缺陷防止；技术变更管理；过程变更管理）
8.IS09001和CMM的关系相似点强调管理、过程、规范化和文档化；不同点CMM把焦点对准软件；IS09001的范围涉及硬件、软件、流程性材料和服务；两者关系CMM2级与IS09001强相关；CMM的每个关键过程域至少按某种解释与IS09001弱相关
9、六西格玛的实行方式Define:定义一一提出问题，拟定目的Measure:测量----------收集资料，寻找因素Analyse分析一一研究资料，拟定因素Improve:改善----------优化解决方案Control:控制----------推行控制系统
10、软件质量模型功能性当软件在指定条件下使用时，软件产品提供满足明确和隐含需求的功能的能力涉及适合性；准确性；互操作性；保密安全性；功能性的依从性可靠性在指定条件下使用时，软件产品维持规定的性能级别的能力涉及:成熟性；容错性；易恢复性；可靠性的依从性易用性在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力涉及易理解性；易学性；易操作性；吸引性；易用性的依从性效率在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力涉及时间特性；资源运用性；效率依从性维护性软件产品可被修改的能力修改也许涉及修正、改善或软件对环境、需求和功能规格说明变化的适应涉及易分析性；易改变性；稳定性；易测试性；维护性的依从性可移植性软件产品从一种环境迁移到此外一种环境的能力涉及适应性；易安装性；共存性；易替换性；可移植性的依从性
11、SQA与测试的关系测试从技术的角度来保证软件质量SQA从流程的角度保障软件质量组织用来保障SQA和测试的活动
12.SQA的重要工作范围•指导并监督项目按照过程实行；•对项目进行度量、分析，增长项目的可视性；•审核工作产品，评价工作产品和过程质量目的的复合度；•进行缺陷分析，缺陷防止活动，发现过程的缺陷,提供决策参考，促进过程改善
13.度量:对事物属性的量化表达；软件度量是指计算机软件中范围广泛的测度，涉及对软件系统、构建或生命周期过程具有的某个给定属性的度的一个定量测量目的•提高软件生产率，缩短产品研发周期，减少研发成本、维护成本；•提高软件产品质量，提高用户满意度；•为组织连续改善提供量化的指标和反馈
14.软件度量的作用1）理解；预测；评估；改善2）分类规模；工作量；进度；质量
15.如何将度量的知识应用于实际工作中建立测试工作的度量数据，目的是作为预测和改善的基础a.熟悉需求进度、工作量、规模；设计用例工作效率、覆盖率；b.执行用例工作效率、缺陷密度；）C.第三章测试方法
1.什么是白盒测试•白盒测试是依据被测软件，分析程序内部构造，并根据内部构造设计用例,来对内部控制流程进行测试，可完全不顾程序的整体功能实现情况；•白盒测试是基于程序结构的逻辑驱动测试；•白盒测试又可以被称为玻璃盒测试、透明盒测试、开放盒测试、结构化测试、逻辑驱动测试
2.为什么进行白盒测试•一般在测试前期进行，通过达成一定的逻辑覆盖率指标，使得软件内部逻辑控制结构上的问、难题能基本得到消除；•能保证内部逻辑结构达成一定的覆盖限度，可以给予软件代码质量更大的保证；•发现问题后解决问题的成本较低
3.白盒测试的常用技术
4、•静态分析控制流分析、数据流分析、信息流分析等；
5、•动态分析逻辑覆盖测试（分支测试、途径测试等）、程序插装等
6、控制流相关概念程序元素、控制流关系、控制流图、控制流矩阵（环节5）1）控制流分析能发现的问题2）转向并不存在的标号；3）没有用的语句标号；4）从程序入口进入后无法达成的语句；5）不能达成停机语句的语句。
个人认证
优秀文档
获得点赞 0
