《软件测试》课件：第7课 测试执行.ppt

1、软件测试执行软件测试执行陈大卫2022年3月5日课程内容课程内容1. 测试执行的工作范围2. 联想软件BUG定义3. 测试管理系统使用4. 关于BUG的几个问题5. BUG分析技术1.测试执行工作范围测试执行工作范围 搭建测试环境 执行测试用例 发现软件缺陷（BUG） 记录BUG和提交BUG BUG跟踪 BUG分析和定位2.联想软件联想软件BUG定义定义联想软件BUG定义是公司标准规范的一部分。 被测对象不满足下列任何一条，即认为是软件BUG： 不满足用户需求或隐含需求； 与前期需求或设计不符合或不一致。 联想软件BUG的属性含多个方面，包括按严重程度、再现程度、优先级别、质量特性、BUG状态

2、、引入阶段等。联想软件联想软件BUGBUG定义定义： 指在测试过程中，软件不满足需求或质量要求的情况下，由测试人员提出的缺陷均称为BUG。 属性属性说明说明具体内容具体内容BUG状态指在BUG跟踪和管理过程中的状态标识。包括待修复、待验证、已解决、遗留和注销5个状态。严重程度以可能对用户造成的影响程度做为最终的判断依据。包括致命、严重、一般、微小4种。优先级别指开发人员修改BUG的优先程度，由项目经理在审核BUG时分配。包括尽快修复、必须修复、建议修复、低优先级4种。再现程度指BUG在特定环境和操作中BUG的重复出现的频率。包括每次再现、经常再现、很少再现、出现一次。质量特性BUG反映出软件产

3、品质量的特性。包括功能性、可靠性、易用性、效率、可维护性、可移植性6大特性。引入过程为BUG最初引入的过程或阶段。包括需求、系统设计、概要设计、详细设计、UI设计、编码、用户文档。BUGBUG严重程度严重程度致命致命BUG：v 测试执行主要功能直接导致系统死机、蓝屏、挂起或是程序非法退出；v 系统的主要功能点没有实现；v 主要模块/功能不满足需求或设计上的要求；v 软件的安全缺陷导致重要数据丢失或损坏。v BUGBUG严重程度严重程度严重严重BUG： 测试执行次要功能导致系统死机、蓝屏、挂起或是程序非法退出； 系统的次要功能点没有实现； 对于主要功能的执行结果与预期结果差别较大，或是计算结果不

4、正确； 软件的易用性不好，导致用户可能不能正常完成软件的主要功能操作； 程序执行过程过于缓慢； 程序占用占用过大的系统资源，或是占用资源后不能正常释放； 主要界面有明显的错别字或描述错误。.BUGBUG严重程度严重程度一般一般BUG： 软件的实际执行过程与预期结果有差异，但不严重； 非正常操作或输入导致系统出错，或执行结果不正确； 系统运行过程中偶尔（出现概率5%）有出错提示或导致系统运行不正常； 软件交互性不好，对于用户可能造成难于操作、学习和理解； 在用户经常使用的环境中，界面不美观，影响软件品质； 界面、程序或帮助文档中文档或文字描述问题，造成用户难于理解。BUGBUG严重程度严重程度微

5、小微小BUG： 软件的实际执行过程与预期结果有较小的差异； 软件不能处理用户可能使用的极端条件下的操作；界面、程序或帮助文档中文档或文字描述问题，但影响不大。BUGBUG优先级优先级 优先级别体现了开发人员修改BUG的优先顺序，分4个级别：尽快修复、必须修复、建议修复、低优先级。 判定权限：项目经理。 BUGBUG优先级优先级尽快修复：尽快修复： 需要开发人员马上修复，并尽快修改完成。 一般指BUG较为严重，并且会对其他工作造成不良影响的情况。必须修复：必须修复： 需要开发人员修复，并且要修改完成。 一般指BUG较为严重，但对其他工作影响较小的情况。建议修复：建议修复： 开发人员最好要进行修改

6、，但并不一定必须修复。 一般指BUG较为轻微，影响软件品质。 此类BUG若最终不修改，一般要做为遗留BUG。低优先级：低优先级： 开发人员可以根据实际情况来决定是否修改。 一般指BUG无关紧要，对项目质量影响非常小。 此类BUG若最终不修改，可以注销或做为遗留BUG。3.测试管理系统使用测试管理系统使用测试管理系统介绍测试管理系统介绍 项目BUG信息的记录与跟踪平台。 系统用户：测试人员。开发人员。项目经理。浏览人员。测试管理系统主要功能测试管理系统主要功能 是测试全过程的管理平台，贯穿整个测试生命周期。 为测试管理者和项目经理提供量化和可视化管理。 包括测试计划、测试用例、测试执行、BUG信

7、息、测试报告、测试总结和用户反馈的各个阶段的管理。BUG生命周期生命周期4. 关于关于BUG的几个问题的几个问题 怎样发现BUG 怎样描述BUG 怎样处理BUG4.1 怎样发现怎样发现BUG用客户的头脑思考-学会移情象愚笨的用户那样做-不遵守任何规定，不做任何假定不要局限在对显而易见事实的测试在缺陷密集区继续查找目标明确的结构化测试凭借经验，直觉和预感经验是人们对错误行为的称谓目标明确的结构化测试目标明确的结构化测试v 在破坏性测试之前进行通过性测试 -等价类划分，数据测试，状态测试.v 开始破坏性测试 -竞争条件和时序错乱 -重复，压迫和重负v 加强测试 -BUG轰炸 -其他人员加入，BET

8、A测试4.2 怎样描述怎样描述BUG立刻记录在案 -准备好工作笔记,抓屏工具,还有具有全场摄象功能的大脑探索问题真相 -在报告问题之前进行分离缺陷和再现精确的描述 -让开发人员能够了解和重建问题 ,并且乐于修改 分离缺陷和再现分离缺陷和再现v 记录每一件事-寻找有效的重建步骤v 查找时间依赖和竞争条件v 压迫和负荷相关v 特定软件状态v 资源依赖性或其他v 不要忽视硬件v 不要沉溺于单一测试方式有效的软件缺陷描述有效的软件缺陷描述v 简洁 - 不说废话v 单一 - 一次说一个问题,或者一个BUG只需改一处v 明显和通用 - 每个人都能了解你在说什么v 再现 - 保证缺陷可重建v 不做评价- 陈

9、述事实而不是显露情绪v 监视修复过程并补充完善BUG描述 - 建立缺陷的生存周期和档案BUG描述的常见问题描述的常见问题v BUG描述不清,开发人员无法理解或者复现v BUG严重程度定义不一致v BUG优先级定义不一致v BUG引入阶段没有填写的习惯. v BUG提交后跟踪和处理方法不一致BUG描述不当引起的影响描述不当引起的影响v BUG修改时间长.大部分时间用于反复扯皮v BUG处理意见测试人员与开发人员分歧很大.影响效率v 开发人员容易产生抵触情绪和抱有怀疑态度.影响项目工作气氛和谐.v 项目统计数据发生偏差,影响度量分析和工作改进v 可能会遗漏真正重要的问题v BUG跟踪可能失去控制,

10、遗忘或拖延重要问题的修改时限BUG描述描述BUG描述描述不要只叙述结果，应该描述错误发生的操作步骤，可以把测试用例内容填入错误发生后利用抓屏,系统日志记录等辅助工具记录错误提示信息和错误现象。不要忘了提供这些附件给开发人员参考不要忘了提供这些附件给开发人员参考在提交到BUG管理系统之前进行BUG重建和定位。去掉多余的描述测试环境要填写精确再现程度要正确估计。如果是概率问题要尽量采用工具或者手工统计。但是首先要排除与资源等因素有关的缺陷。提高BUG分析能力。尽可能多的填写这部分。例如发现一个问题后可以拓展测试范围来在这个区域发现更多问题。4.3 怎样处理怎样处理BUG报告问题的说服技巧 -有效的

11、问题报告 -及早提出问题 -给点儿建设性意见 -人人喜爱的软件是不可能的,注意主观意见的分寸缺陷不是生来平等的 -并非所有缺陷都能够(值得)修复软件缺陷生命周期-寻找适当的人协助学会妥协和争取-建立和运用你的影响力评估和准备后续维护方案-眼光放长远BUG跟踪跟踪BUG跟踪跟踪遗留遗留：经项目经理确认在本版本中可以不修改的缺陷。注销注销：实质上不是程序的最终BUG，但需要保留。例如，所对应需求发生变更或是被取消的BUG，或是由于产生歧义，项目经理建议注销的BUG（需要根据情况酌情定夺）。5.BUG5.BUG分析技术分析技术分析BUG时，要考虑以下问题：1、 复现BUG现象所需的精确步骤和最少步骤

12、有哪些？这些步骤成功复现这些现象的频率如何？2、 执行测试用例的预期结果与实际结果不一致时，是测试错误，还是系统错误？也就是说，这种异常的结果起源于测试因素或测试人员的错误，还是系统故障影响顾客。3、 哪些外部因素影响到这个现象？包括硬件环境、操作系统、其他软件、分辨率配置或字体设置等。4、 什么是问题的根本原因（即我们通常说的“引入原因”），是代码、电子、网络，还是环境？根本原因是内部因素。5、 怎样才能在不产生新BUG的条件下使这个问题得到解决？6、 这种变化是否经过正确的调试，所属单元是否经过测试？7、 问题解决了吗？它现在是否通过了先前失败的测试，并且系统的其余部分仍工作正常？归纳和演

13、绎归纳法归纳法是一种从特殊到一般的思维过程，从对个别实例的认识当中，概括出共同特点，得出一般性规律的思考方法。演绎法演绎法是一种从一般的推测和前提出发，运用排除和推断过程做出结论的思考方法。归纳法分析 归纳法归纳法BUG分析技术分析技术是从测试结果发现的线索入手，分析它们之间的联系和关系，导出BUG原因的假设，然后再证明是否定这个假设，具体步骤如下：从BIM系统中，收集有关BUG信息，列出程序哪些执行正确，哪些执行错误的信息。组织BUG信息数据。整理这些BUG信息或对应的测试用例集，尽力发现其中规律，使用分类法构造一张线索表。提出假设。分析线索之间的关系，根据测试人员的技术和经验，导出一个或多

14、个错误原因的假设。证明假设。演绎法分析 演绎法演绎法BUG分析技术分析技术 是列出所有可能的BUG原因的假设，然后通过执行相关测试用例排除不适当的假设，最后在通过进一步测试验证余下的假设就是BUG原因，具体步骤如下：当测试发现了BUG后，首先确定是由于程序出错造成的，否则找出其他原因。具体也可以通过排除法实现。根据测试人员和开发人员的经验，提出可能产生BUG的各种原因。针对每个原因执行测试用例，如果执行后程序并没有出现BUG，则可排除此原因。不断执行上一步，一直到只剩下一个或几个原因可能会产生程序的BUG。针对余下的原因使用归纳法或直接修改程序来验证BUG产生原因。注意注意: 合适的工具将帮助你合适的工具将帮助你 问题和讨论问题和讨论谢谢谢谢 大家大家