logo资料库

软件测试基础知识各大软件公司面试所遇BUG问题各大软件公司面试所遇BUG问题.docx

发布时间：2022-06-09 发布人：admin 分类：说明书 资料大小：0.07M 资料格式：docx 举报 版权申诉
第1页 / 共19页
第2页 / 共19页
第3页 / 共19页
第4页 / 共19页
第5页 / 共19页
第6页 / 共19页
第7页 / 共19页
第8页 / 共19页
资料共19页，剩余部分请下载后查看
    浅谈软件测试中的Bug
    软件测试SQL操作大全
    浅谈软件测试中的 Bug 现在软件开发公司越来越重视产品质量，很多软件公司纷纷成立了自已的测试团队，测试在软件开发 的周期中显得越来越重要。软件测试是为发现错误而运行一个程序或者系统的过程。软件测试的主要目的 是发现软件中的错误或缺陷。这里软件中的一个错误或缺陷就是一个 Bug。软件测试的过程就是不断的寻 找 Bug，然后排除 Bug。微软的研发管理中，它的 Bug 管理系统是居于核心地位的。测试人员只要发现问 题就立即新建一个 Bug 予以跟踪并指派给相关的开发小组长，开发人员会根据 Bug 的详细信息找到问题所 在，修改程序解这个 Bug 并把 Bug 返回给当初的测试人员。阅读每个 Bug，你可以详细的看到大家解决这 个问题的完整思路。一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免 80%的 Bug， 而系统测试又能找出其余 Bug 中的 15%，最后的 5%的 Bug 可能只有在用户的大范围、长时间使用后才会 曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。 一、软件 Bug 涵义 软件 Bug 实际是软件产品没有达到预期设计目标，在软件内部存在的一种缺陷。在不影响用户和系统 正常运行的情况下处于隐蔽状态，没有表现出来。当 Bug 发生运行错误时，轻者影响用户使用，重者会构 成事故，造成损失或伤害。软件 Bug 按其危害程度大致分为 4 类：①致命性错误：Bug 一旦运行，造成系 统崩溃或挂起、数据被破坏。②严重性错误：造成系统不稳定，产生错误结果，业务处理功能无法实现。 ③一般性错误：用户在完成某一功能时出现错误，但不影响该功能的实现和系统的正常运行。④操作性错 误：用户使用软件时，感觉不方便。 二、Bug 产生的原因 软件几乎天天在修改，审核，验证再测试，可相当长一段时间的测试过程中会发现居多这样那样的缺 陷，层出不穷的发现 Bug，到底是什么原因？总结以下几种常见原因： 2.1 测试遗漏 软件测试的设计主要体现在测试用例的设计，以及通过测试策略将这些测试用例同测试计划，测试执 行，还有测试结果数据的收集整理结合在一起执行，由于测试人员水平的高低，测试工具使用的熟练程度， 以及对所测试对象的理解深度等原因，测试设计很难完善，主要表现在测试用例设计的不全面，存在遗漏， 或者测试方案的不周密，以及可能的测试人员执行时产生的偏差等等，这些测试方面的遗漏和偏差都可能 导致软件问题没有及时发现，造成测试的遗漏。 2.2 设计及修改原因 软件需求或者设计方案经常被更改，特别是变更没有导入一套成熟的变更管理体系的情况下，每次变 更无疑于埋下大量的地雷，这些都为 Bug 提供滋生的环境。另外后期修改维护中对 Bug 未做准确的分析定 位，修改方案未审核，或者修改过程中程序员出现“头痛治头，脚痛治脚”，“补了东边漏了西边”等不良修改 过程中引发出新的问题，也是导致 Bug 被扩大的原因。 2.3 Bug 的潜伏性及阶段性
    有时候， Bug 实际存在但由于触发它的条件不满足从而呈现潜伏状态只能在某个阶段才能被发现，单 元测试，集成测试，系统测试等阶段测试重点关注的对象就不同，如集成测试可以发现单元测试通过后的 模块之间接口上的错误。特别象嵌入式系统中多进程以及多任务处理问题、系统容错性问题、内存问题等 等，这些情况下表现出的潜伏性更加复杂多变，导致发现这些 Bug 需要一个特别长的周期或者需要某一特 定测试环境能被有效搭建的情 况下才能查找出。 2.4 Bug 的隐蔽性和周期性 该 Bug 实际存在但由于其他 Bug 的存在导致它所在的代码没有得到执行，因而无法暴露该 Bug，这种 情况在以黑盒测试为主的测试中表现尤为突出，只有通过周期性的 Bug 修复及测试才能发现该类 Bug。 三、软件 Bug 的危害 2002 年美国商务的国家标准技术研究所发表了一份有关软件 Bug 的损失报告。据该报告推测，美国 每年由于软件 Bug 而引起的损失额高达 595 亿美元。这一数字相当于美国国内生产总值的 0.6%，占美国 每年软件销售总额的 1/3。也就是说，每卖 3 美元软件，就会带来 l 美元的损失。由此可见软件 Bug 所带 来的损失是多么巨大。下面通过两个案例进一步说明软件 Bug 的危害。 例 1：据《金融时报》报道，2002 年 4 月 1 日，日 本最大的银行—瑞穗金融控股集团（富士银行、第一劝业银行和兴业银行三家银行合并后组成）合并 后对外营业的第 l 天，许多储户 J 凉讶地发现账户的余额被重复扣掉了或存款没有更新余额，原因是该行 计算机系统出现了问题，造成 200 多万账户余额出现错误。一个月后错账还没有处理完毕，一时举国上下 震动，为此银行声誉严重受损 例 2：在 Mierosoftl981 年推出的 Basie 软件上， 黯用户只要用“.1”（或者其他数字）除以 lo 时就会出错，而在使用的 Fortran 软件中也存在着破坏数据 的 Bug，由此造成了许多客户的极大不满。在 1984 年推出电子表格软件之前，Microsoft 曾特地邀请 ArthurAnderson 咨询公司进行测试。但由于该公司没有能力执行全面的软件测试，结果存在一种相当厉害 的破环数据 Bug，迫使 Microsoft 公司为 2 万多名用户免费提供版本更新，代价是每个版本 lO 美元，一共 花了 2O 多万美元。原定于 1986 年 7 月发行的 Word3.O，直到 1987 年 2 月才问世。原因是这套软件竟然 有 700 多处 Bug，有的 Bug 可以破坏数据甚至摧毁程序，一下子就使 Microsoft 名声扫地，公司不得不为 用户免费提供升级版本，费用超过了 100 万美元。 四、发现 Bug 的方法 为了提高软件的质量，发现 Bug 并不断的排除 Bug 是软件测试的目的。软件测试的有效方法是 11 步 的软件测试的过程，这 11 步软件测试过程的描述如下： （1）评估开发计划和状态：这是建立测试计划 的先决条件，该测试计划用于评估已实现的软件解决方案。测试人对开发计划的完整性和正确性进行评价； （2）制定测试计划：测试计划描述的是如何完成测试。包括完成所需的资源和进度； （3）测试软件需求： 需求阶段是检查系统缺陷最经济的阶段，需求阶段发现的缺陷不但不会再延伸到设计和代码中，相反，是 在它最早可能出现的地方捕获； （4）测试软件的设计：主要是通过验证技术测试软件的内外部设计。测
    试人员关心的是设计是否达到了需求的目标以及是否在指定的硬件上能够有效而高效的运行； （5）测试 软件构造：来自于内部设计文档用于开发软件的方法决定了所需的测试类型及其扩展性； （6）执行测试： 主要是以动态的方式测试代码。测试计划中所指定的方式、方法及工具等都将用于确认可执行的代码满足 了所陈述的软件需求及设计的结构化规格说明； （7）验收测试：使软件用户可以对软件在其日常工作中 所体现的适应性和可使用性进行评价； （报告测试结果：测试的报告是一个连续的过程。将缺陷尽可能早 地报告给相关部门是非常重要的，这样才能用尽可能小的代价来修复缺陷； （9）测试软件安装：一旦测 试小组确认软件可以作为产品使用后，就应该测试软件在产品环境下的执行能力； （10）测试软件变更： 只要需求发生了变更，测试计划就必须做相应的改变； （11）评价测试有效性：可以在软件测试工作结束 时对测试的有效性进行评价来改善测试。 五、软件 Bug 的防治 实际上，软件 Bug 并非不可消除，加强项目管理和软件测试就是“灭虫”的有效手段。美国商务的国家 标准技术研究所报告显示，如果通过强化项目管理和软件测试及早发现软件 Bug 并得以解决，可以减少 1/3 以上的损失（相当于减少 222 亿美元的损失）。所以，要想提高软件质量，就必须加强软件项目管理和软 件测试。 1.加强项目管理 软件项目管理不仅可以“灭虫”，而且还可以借此实现软件产品的规范管理，有效提高软件质量。软件 项目管理的任务就是有效地组织人员并利用一些软件技术工具，按照事先制定的计划执行，做好监督、检 查过程控制，确保按标准、在预算成本内、预定期限内完成软件开发项目。项目管理的内容可分如下几部 分： （l）软件开发组织： 主要是成立软件项目开发小组、草拟项目管理的各项制度、组织项目阶段评审、保存项目过程中的相 关文件和数据、为优化项目管 理提出建议等。 （2）软件开发计划 ：软件项目本身是复杂的，而复杂的软件项目若无细心的规划则不可能成功，所以要制定完善的计划， 比如确定项目的范围和目标；制定项目管理和技术约束机制；做好项目工作量、成本、时间等方面的估算； 确定项目资源中人员需求、硬件和软件配置等所需的资源；确定每日工作日程，把项目工作细分到项目中 的每一个人。 （3）做好人员管理： 科技以人为本，只有调动项目组中每一个人的积极性，才能圆满完成项目。这需要考虑如下几方面的 问题：第一，这个软件项目需要多少人来完成；第二，能够使小组每个成员都发挥能力；第三，能够使小 组每位成员都有成就感；第四，让每一个项目成员都能提出问题及解决问题的方案；第五，让每一个成员 知道软件质量的重要性。 （4）做好配置管理：
    软件产品在整个开发过程中，特别是在建立初期经常会发生变更，如果没有变更控制，在大型软件开 发的过程中就很容易发生混乱。因此，软件配置的目标是标识变更、控制变更、确保变更正确地实现，向 有关人员报告变更情况。最好使用专门的变更控制管理工具，对软件代码进行配置管理，为代码规定各层 次目录，对每个目录下的代码模块存取及版本控制，都由软件自动完成，确保各种版本不会混乱。 （5）加强质量管理： 做好软件产品质量的控制活动，对软件质量控制贯穿于开发的全过程。规划软件质量保证活动，检验 软件产品是否按照合适的标准、步骤和需求运作；公布软件质量保证活动的结果；定义软件产品的质量目 标，制定达到这些目标的计划，监控及根据业务部门需要调整这些软件计划；做好过程控制，按项目计划 的进度跟踪项目，同时做好对各种开发文档的评审和各阶段软件测试的确认；定义可度量的软件产品质量 目标及其优先级；做好软件产品的设计控制，这是质量体系的主体。 （6）强化风险管理： 软件项目管理存在着风险， 如果我们提前重视风险，并且有所防范，就可以最大限度减少风险的发生。这就要求项目管理人员在 项目开始前，必须做好风险的识别和评估，把可能产生的风险环节列人风险驾驭计划，这是进行风险管理 的有效手段。 ① 建立风险项目检查表。检查内容包括：产品规模风险检查、业务影响风险检查、与客户相关的风险 检查、过程风险检查、技术风险检查、开发环境风险检查、与人员的模式和经验有关的风险检查等。 ② 做好风险评估。评估内容包括：风险发生的可能性、发生的结果（影响）、建立一个尺度表示风险 可能性（如罕见、普通、可能、极可能），描述风险带来的后果估计对产品和项目的影响，确定风险评估 的正确性，根据影响尺度对每个风险的表现、范围、时间做出尽量准确的判断。 2.做好软件测试 软件测试是软件开发的一个重要环节，也是软件质量保证的一个重要环节。从某种意义上讲是对银行 业务需求检查、验证的一种手段，检查软件功能是否按照系统需求进行设计，同时为软件可靠性与安全性 的评估提供依据。测试的目标就是以最少的时间和人力找出软件中潜在的各种 Bug。 （1）测试的基本原则： 认真编写测试计划和测试方案，精细设计测试用例；程序员应避免测试自己编写的程序；.认真彻底检 查每一个测试结果；在测试时，不要设想程序中不会查出错误；应该在测试工作真正开始前就开始计划测 试。 （2）测试的内容 ① 功能测试：主要侧重于运用一定的测试方法和测试案例，核实测试对象是否按计划运行，软件功能 是否实现了用户需求。该测试针对不同的测试对象实施和执行，包括单元测试、集成测试、验收测试和数 据移行测试。
    ② 系统测试：主要包括恢复测试、安全测试、压力测试、性能测试和兼容测试。恢复测试主要检查系 统的容错能力；安全测试检查系统对非法侵人的防范能力；压力测试检查程序对异常情况的抵抗能力，总 是迫使系统在异常的资源配置下运行，以检查系统的承受能力；性能测试检查系统是否达到要求，它有时 与压力测试相结合，并需要其他 软硬件的配套支持；兼容性测试测试系统产品在不同的硬件平台、操作系统、浏览器软件和版本下的 运行情况。 （3）软件测试方法 目前软件测试主要是白盒测试和黑盒测试。白盒测试即结构化测试，它依赖于对程序细节的严密检验， 针对特定条件和循环集设计测试用例，对软件的逻辑路径进行测试，在程序的不同点检验程序的状态，以 判定其实际情况是否和预期的状态相一致。白盒测试方法一般用来分析程序的内部结构。黑盒测试是根据 用户的规格说明，即针对命令、信息、报表等用户界面及体现它们的输人数据与输出数据之间的对应关系， 特别是针对功能进行测试，对于银行软件通常采用黑盒测试的方法。 （4）软件测试流程 组织和管理测试人员，建立测试队伍；根据测试需要建立测试环境；编写测试计划；根据软件功能说 明书，做好测试案例的设计和评审；按照测试计划、测试案例进行测试，对交易测试完毕和测试过程中发 现的 Bug，要做好跟踪和管理；测试完毕，编写测试报告；修改完毕的软件做回归测试。 （5）做好软件 Bug 管理 使用测试管理工具做好软件 Bug 管理，并通过正确的途径提交测试报告，要求测试人员提交测试报告 时必须做到：尽快报告软件 Bug；测试报告的结构必须清晰、统一，并且方便阅读；测试报告只解释事实 和描述 Bug 必须的细节；测试报告应是单一的，每一个报告只针对一个 Bug；Bug 的描述应是明确的、通 用的。对测试报告中反映的 Bug 问题，要有专人通过测试管理库进行跟踪，经常检查软件 Bug 的状态是否 已经修改。 软件测试 BUG 参考标准 一、 目的 对 BUG 概念、类型划分、 BUG 状态、 BUG 严重程度等内容进行定义和规范，以 便进一步指导我们的软件测试工作。 二、概念 BUG ：软件中存在的瑕疵，可能会导致系统失效。简单的说就是软件系统中存在的可 能导致系统出错、失效、死机等问题的错误或缺陷。 三、 BUG 的类型划分 功能类
    A. 重复的功能 B. 多余的功能 C. 功能实现与设计要求不相符 D. 功能使用性、方便性、易用性不够 界面类 A. 界面不美观 B. 控件排列、格式不统一 C. 焦点控制不合理或不全面 数据处理类 A. 数据有效性检测不合理 B. 数据来源不正确 C. 数据处理过程不正确 D. 数据处理结果不正确 流程类 A. 流程控制不符和要求 B. 流程实现不完整 提示信息类 A. 提示信息重复或出现时机不合理 B. 提示信息格式不符和要求 C. 提示框返回后焦点停留位置不合理 建议类 A. 功能性建议
    B. 操作建议 C. 检校建议 D. 说明建议 性能类 A. 并发量 B. 数据量 C. 压缩率 D. 响应时间 常识类 A. 违背正常习俗习惯的，比如日期 / 节日等 特殊类 A. 不符合 OEM 版本或 DEMO 版本特殊要求的 四、 BUG 状态 已提交：软件测试员发现 BUG 后提交到 BUG 管理系统中的状态。（初始状态） 已修改：程序员在修改了 BUG 后提交到 BUG 管理系统中的状态。 不修改：程序员或项目经理根据需求分析、概要设计、详细设计说明书等上的要求经 过考虑后决定对 BUG 不进行修改。其 BUG 的状态为不修改，需要说明理由。 延迟：根据目前项目进程或计划等情况，暂时延期的状态 待讨论：需要进行讨论后才能决定是否需要修改的 BUG 的状态。 已验证：已经解决的并经过测试员复测的 BUG 的状态。 关闭：完全解决了，只供以后备查的状态 重新打开：重新出现在新的版本中，重新打开以前关闭的 bug 状态
    ( 当然在 bug 工具中，可以自己定制适合项目的状态项目，比如废除，拒绝等 ) 五、 BUG 的等级划分与优先级 1 、严重：死机，数据丢失，主要功能完全丧失，系统悬挂等错误。修改优先级为最 高，该级别需要程序员立即修改。 2 、较高：主要功能丧失，导致严重的问题，或致命的错误声明。修改优先级为高， 该级别需要程序员尽快修改。 3 、一般：次要功能丧失， 不太严重，如提示信息不太准确。修改优先级为中，该级 别需要程序员修改。 4 、轻微：微小的问题，对功能几乎没有影响，产品及属性仍可使用，如有个错别字。 修改优先级为低，该级别需要程序员修改或不修改。 六、 BUG 的优先级 （一般与 BUG 等级挂钩） 参考 1 、紧急、非常高、高、中等、低 参考 2 、下一个 build 版本 ,a 测试 ,b 测试 , 发布版本，最终发布版本 七、 BUG 记录内容 软件测试软件测试的重要环节：Bug 管理流程 节：Bu 软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错 误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误， 保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个 Bug 都要经过测
    分享到：
    赞 收藏

    相关推荐

    资料库

    课程资源

    共收录17145份资料，累计13个分类，关注成员有19位，主要包括：PHP,网络管理,网页制作,Java,.Net,数据库,3G/移动开发,C/C++,游戏开发,嵌入式,讲义,软件测试,专业指导

    热门标签

    PHP 网络管理 网页制作 Java .Net 数据库 3G/移动开发 C/C++ 游戏开发 嵌入式 讲义 软件测试 专业指导

    最新资料