《软件测试复习资料》由会员分享，可在线阅读，更多相关《软件测试复习资料（11页珍藏版）》请在金锄头文库上搜索。
1、Part I Big picture测试：在软件结构层次范围内或多种环境下评价软件功能点和行为的过程；根据规格说明书和用户需求验证&有效性确认软件产品；发现软件bugs。测试空间：获取性、性能特征、细节层次测试循环：（死循环）执行用例-结果-评价 猜想原因-附加测试-测试用例 -执行测试 识别原因-修改-回归测试-测试用例-执行测试Ch.1 软件测试背景软件缺陷：软件错误；引起软件失败的因素；官方定义。高质量的软件是合理的bug-free，及时交付并在预算之内，满足了需求或期望并可维护。不同的视角有不同的观点高质量软件类型：产品质量、过程质量、商业环境下的质量。软件失败的因素：确定、故障、问题
2、、错误、时间、异常、偏差、失败、矛盾、特性、bug故障、错误、失败统称bug软件缺陷形式上的定义：产品规格说明书：定义了产品应该有的的所有特性/功能。Bug定义：（有一个就是）a） 软件没有做规格说明里的东西b） 软件做了，但和规格说明里不一样c） 软件做了规格说明里没有提到的（修改规格说明）d） 软件没有做规格说明没有提到但是应该做的e） 软件很难理解，很难使用，很慢或（在测试人员角度）最终用户抱怨软件失效机理可以描述为：软件错误软件缺陷软件故障软件失效（了解）l 软件错误（software error）：是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。l 软件缺
3、陷（software defect）：是存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差，其结果是软件运行于某一特定条件时出现软件故障，此时称软件缺陷被激活。当软件意指程序时，软件缺陷（defect）与软件/程序污点（bug）同义。软件缺陷是存在于软件内部的、静态的一种形式。l 软件故障（software fault）：是指软件运行过程中出现的一种不希望或不可接受的内部状态。出现软件故障时若无适当措施（容错）加以及时处理便产生软件失效软件故障是一种动态行为l 软件失效（software failure）：是指软件运行时产生的一种不希望或不可接受的外部行为结果。ISO 8402质量
4、：产品的所有功能和特征、过程或提供的服务都具有它的能力-满足指定或必然包含的需要。Bug：故障，错误（内部存在的状态，开发和维护时存在）、失败（外部状态，与系统本来要求的行为和本身的不一致、背离）故障、错误VS失败：内部VS外部代码/设计/数据VS功能/特性白盒测试VS黑盒测试检测出来（需求）错误-故障-失败（设计）故障-失败（测试数据）故障-失败引起buga. 规格说明50%b. 设计c. 其他为什么规格说明是第一位？没有写；没有被详细写；一致改变；没有和队员及时沟通。If you cant say it, you cant do it.设计：和规格说明原因一样；仓促，改变，沟通不好为什么软
5、件有bug？沟通不良；不沟通；软件变化；自我Bug成本、损失：指数级增长，从规格说明-设计-编码-测试-发布测试员的目标：找到bugs；尽可能早的发现它们；确保它们最终都被修正；学习被业界讨论的技术。测试员：开发人员、测试组、QA组、最终用户调试员：程序分析员、开发人员测试：以找错误的目的，在控制条件下对系统或应用的操作，评价最终结果。尝试使出错，意图是“检测”调试：开始于一个识别的错误，是定位错误，并修正的过程。不关注怎样发现bug，关注怎样修正bugSome exercises:Whatswrongwithjusttestingthataprogramworksasexpected?Giv
6、esomereasonswhytheproductspecificationisusuallythelargestsourceofbugsinasoftwareproduct.Ch.2 软件开发过程软件产品：不仅仅是一个程序，是由正常交付的软件组件组成；典型地被组织到和生命周期中一些典型阶段一致的种类中所有测试员对这些产品组成都有所了解且去检测他们产品组成：用户需求；MRD（任务/特征描述，可用数据）；规格说明；进度表；设计文件；在线帮助；read me；发布包裹。帮助文件；用户手册；错误信息；安装说明；产品支持信息需求：使用者所需要的能力条件，去解决一个问题或获得某个事物（IEEE）好的需求
7、：可见；一致；完整；运行可靠；可度量；可取得；可跟踪；可修改规格：和需求不太一样，把需求最终正式文档化，最终定义产品是什么、外观怎样、有什么功能写MRD和SPEC，注意可确认性，符合原来规格说明定义的Some ways to quantify：速度；规模；易使用；可靠性；健壮性；易携带性进度表：详细制定；有软件工具生成，也有很多估算时间和花费的方法；测试人员也要考虑测试计划和进度表。设计文档：详细层次。结构设计文档，数据流图，状态转换图，实体关系图，决策表测试文档：说明软件产品测试的文档。测试计划，测试用例，bug报告，度量统计数据及报告总结，发现了多少bug软件工程人员：PM；高级的工程师；
8、系统测试员；系统分析员；构架师；编程人员；测试员；QA；技术文档的书写者；用户协作的书写者（用户手册，安装说明）；用户训练员；手册编写者；配置管理员PM：和设计人员协作决定什么功能可以在什么时间实现；在测试时和设计人员、测试设计工程师沟通测试组织中的角色测试管理者：协调，决定问题优先解决测试领导：领导设计测试计划等高级测试员：设计测试模块和测试用例，测试用例执行，提供技术支持低级测试员：执行测试用例，记录测试结果，提交bug报告和测试中的问题为什么要再SDLC建立模型？SDLC软件开发生命周期：起于应用第一次被构想，止于它不再被使用计划-分析-设计-实现-测试-roll-outSDLC过程：需
9、求-产品设计-技术设计-编码&单元测试-功能&系统&验收测试-发布big-bang大爆炸模型：集中很多人和金钱；花费很多精力和时间；极少的计划、安排和正式开发过程；没有测试；软件or废品code-and-fix边写边修改模型：开始于一个不正式产品规格说明，编码、修改，重复直到满意；工作随意；“Theres never time to do it right, but theres always time to do it over.”随着项目一直在变，要不断改变测试方法；在测完这个版本前，接到了下一个；waterfall瀑布模型：相邻阶段间可回溯；可跳跃回溯每件事都被仔细地严格地说明；安排好了
10、准确的计划和进度表；测试直到后期才开始；会有bug潜伏在早期程序中，最后影响产品；修复代价会很高Rapid快速模型：快速应用，把产品定义过程缩短没有特别提供测试，但经常在重复阶段时做；缺少正式定义测试阶段；整个模型易退化成边写边修改模型V模型-快速应用开发Spiral螺旋模型程序员可以较早介入到软件开发中；帮助测试员选择合适的测试计划和安排；开发需求和说明在随时间变化；每个螺旋都是瀑布模型；加入风险分析；太复杂，周期太长XP极限编程：小团队，高风险，快速变化的需求，需要可测性主要关注交流、简单、回馈、面对高风险的勇气TDD测试驱动开发：测试先于开发，TF+重构在编之前就写测试代码，优化代码等要
11、求粗要重构功能点+性能点阶段开发模型：bulid release1 - use release1 Bulid release2 - use release2Bulid release3 - use release3增量模型VS迭代模型：一步一步完成VS现有抽象概念、定义，然后再填充Some exercise: Whatdisadvantageistheretohavingaformal,lockeddownspecification? Whycanthewaterfallmethodbedifficulttouse?Ch.3 软件测试的现实不存在bug-free的产品；测试永远也无法穷尽；适合
12、的停止时间；测试有可能的话，尽早介入；bug严重等级；测试和fix没有界限；测试人员数字要足够大测试公理：1. 不可能完全测试一个程序：输入/输出太多；路径太多；观看者自己的评判标准2. 测试不能够证明bug不存在3. 软件测试是非常有风险的：寻找最佳点（成本和缺陷）4. 发现的bug越多，这里就有更过的bug：bad days；犯同样的错；发现的知识冰山一角5. 杀虫剂悖论：有抵抗，杀虫剂不再有效；新的，各种不同的测试用例6. 不是所有发现的bug都会被修改：时间；根本不是bug；风险；不值得；不能被修改；第三方因素7. 很难说清什么样的bug算是一个bug8. 产品规格说明永远不会有最终版
13、本：随着用户需求变化9. 软件测试人员不是开发团队中受欢迎的：早点发现bug；控制情绪；不要总是报告坏消息10. 软件测试是一个比较严格的技术精确度（precision）：所有的答案都差不多，但不是正确答案eg. 0.1230.03 可接受准确度（accuracy）：准确的答案0.125产品规格是错的，有精确度，无准确度确定（verification）：确认系统满足规格说明要求验证（validation）：是否能够满足用户需求质量（quality）：是否是质量中的一个要素，决定权完全在使用者手里，主观可靠性（reliability）：是否很稳定的类型，看用户的需求测试（testing）：参与质
14、量的控制方面，只关心错误，保证被修正，找bug质量保证QA（quality accuracy）：防止软件发生缺陷，创造比较标准的流程，可控，预防QC - QA - QM - TQM手工操作者-专职检验员-过程统计技术-全面质量管理-以顾客为中心黑盒测试：不知道结构，只关心输入和输出功能测试、数据驱动测试白盒测试：知道内部结构、路径是怎么实现的路径、分支、循环、结构性测试、逻辑驱动测试灰盒测试：综合以上两种，知道部分结构静态测试：检查并review代码及其他支持材料，不需要运行程序动态测试：代码进行运行测试分类：黑盒；白盒；单元（在函数或模块内的测试，不关注接口）；集成（更注重接口，新增的功能）；回归（难，原来的bug已修复，再次提交时，对这个bug的测试；原来已经通过的测试用例要不要测试，争议较大，如何选择测试的用例集合）测试阶段：比较测试：和竞争产品比较弱点和优点Alpha（）测试：系统测试开发接近完成时测试；可能需要少量设计修改；应用到真实的潜在用户；小范围，可控；把人集中起来Beta（）测试：验收测试开发和测试都可以看作完成，在最终发布前寻找最后的bugs和问题；范围更广，不可控。Eg. 游戏公测测试分类：功能性测试：黑盒测试的同义词系统测试：类黑盒测试、灰盒测试，基于总体的需求和
