每个公司、每一个工具对bug生命周期的定义
发表时间：2023-10-20 14:03:30
文章来源：炫佑科技
浏览次数：209
菏泽炫佑科技
每个公司、每一个工具对bug生命周期的定义
● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open->rejected->closed
缺陷状态变更过程的实际方法可能因项目团队而异。 并且需要结合实际的开发过程和协作过程来使用。
2.关于测试用例的基本要素和测试用例
测试用例是向被测系统发起的一系列集合，包括测试环境、测试数据、测试步骤、预期结果等。
为什么需要测试用例
换句话说，测试用例有什么好处？
1、测试用例是测试执行的基础
2. 回归测试时可以重复使用
3. 衡量需求的覆盖范围
4. 自动化测试的基础
5.参考意义，后续测试人员可以借鉴前人写的内容
根据需求设计测试用例
需求是测试人员进行测试的依据。 测试人员首先要对需求进行分析，验证需求的正确性和合理性，明确无误，逻辑上一致。在正确需求的基础上，细化测试需求，从测试需求中提取测试点或测试项，然后根据每个测试点设计测试用例； 在分析测试需求时，一般分为功能测试需求和非测试需求。 功能测试要求
1>功能要求
对于功能测试，我们可以使用功能框图来帮助我们分析测试需求。 概括起来，功能测试需求包括以下几个方面，通常包括以下几个方面。
(1)系统各功能接口验证
(2)使用业务串接功能进行测试
(3)功能一致性和交互性测试（多功能互操作性）
(4)系统不同输入和结果输出的业务数据测试。
（5）功能错误操作和异常操作测试（属于负面测试）
(6) 功能实现中使用的算法验证有时需要进行代码审查
(7)用户操作的易用性和用户体验往往与功能测试同时进行验证。
3>非功能性需求
非功能测试需求主要涉及性能、安全性、可靠性、兼容性、易维护性和可移植性等。从测试需求分析的角度来看，每类非功能特性测试都需要根据需求分别进行分析。 他们之间可能存在相互影响。 例如，安全性越高，就越有可能给易用性和性能带来更大的挑战。
所以总结来说，非功能性需求就是基于功能做一些限制，以满足特定的用户场景，给用户更好的体验。
这里需要说明的是，对于每一个应用软件系统，都存在非功能特性的质量要求，但不同的项目类型对每一个非功能特性的要求是不同的。 这需要根据具体项目、具体需求并分析不同产品应用的特点。
（1）纯客户端软件，如文字处理软件（Word、PPT）、媒体（音频/视频）播放软件（电脑自带）等。此类软件对系统的功能测试要求*低，但对兼容性、稳定性、可移植性有一定的要求。
(2)企业内部的客户端/服务器(C/S)应用系统。 例如，电子邮件、即时通讯系统（飞Q、企业QQ）等比纯客户端有更复杂的系统功能测试要求，要求功能正确、稳定性好。 但总体来说，对性能、安全性、兼容性的要求并不高。
（3）外部大型复杂网络应用系统，如电子商务、网上银行、视频网站（腾讯、优酷）等，除了复杂系统的功能测试要求外，在系统性能、安全性等方面、兼容性、容错性、可靠性等都有很高的要求。
具体设计方法1>等价类
根据需求将输入（特殊情况会考虑输出）划分为多个等价类，并从等价类中选择一个测试用例。 如果该测试用例通过，则它所代表的等价类也通过测试。
有效等价类：程序规范是合理且有意义的输入数据的集合。 使用有效的等价类来验证程序是否实现了规范中规定的功能和性能。
无效的等价类：根据需求规范不满足要求的集合。
等价类可以解决测试用例无法穷举的问题
所以这里有一个问题。 有效的等价类是合理的，可以验证软件是否实现功能和性能。 无效的等价类怎么办？ 如果不符合要求，还需要进行检测吗？ 答案是：需要。
2>边界值
我们将边界值与等价类一起使用，即我们专门针对输入和输出的边界设计测试用例，这称为边界值法。所以实际上测试用例就是来自等价类的边界值
3>错误的猜测方法
这种错误的猜测方法会考验测试者自身的技术。 错误猜测法是根据对被测软件设计的理解、过去的经验和个人直觉来推断软件中可能存在的缺陷，从而有针对性地设计测试用例的方法。
这种方法强调对被测试软件的需求以及设计和实现的细节的理解，以及个人的经验和直觉。 误差推测法的基本思想与当前流行的“探索性测试法”是一致的。 此类方法在敏捷开发模式下投入产出比较高，在测试中得到广泛应用。
这种方法的缺点是难以系统化，过于依赖个人能力。
4>情景法
所谓场景法，就是将孤立的功能连接在一起，形成一个场景。 每个功能的选择都会触发不同的方向。 测试用例是根据这些不同功能的不同输入触发的场景来设计的。举个例子，比如银行ATM机的插卡过程。
5>因果图法
所谓因果图就是一种逻辑图，恒等、与、或、非。 能够直观地表明程序输入条件（原因）和输出动作（结果）之间的关系。 因果图法是一种借助图形来设计测试用例的系统方法。 特别适合有多种输入条件的被测程序，
程序的输出取决于输入条件。
恒等：输入为真，输出为真
与：输入的多个条件为真，输出才为真
或：输入的多个条件有一个为真，输出就是真
非：输入为真，输出为假。输入为假，输出为真
那么我们如何根据因果图方法来设计测试用例呢？
1.分析所有的输入和输出
2.找出输入和输出之间的逻辑关系
3.根据输入和输出画因果图
4.根据因果图画判定表
5.根据判定表去设计测试用例
6>正交法
所谓正交法，就是从所有测试因素的水平组合中选取一些代表点进行测试。 通过对这些测试结果的分析，我们可以了解整体测试情况并找到*佳的横向组合。 正交实验设计是一种基于正交表的高效、快速、经济的实验。
（）：在实验中，要考察的变量称为因素（变量）
水平（Level）：在实验范围内，被考察因素的值称为水平（变量的值）
正交表的组成：
行数（Runs）：正交表的行数，即试验次数，用N表示。
因子数()：正交表的列数，用C表示。
级别数()：任何单个因素可以取值的*大数量。 正交表中包含的值是从0到“级别号-1”或从1到“级别号”，用T表示。
正交表的表示形式：L=行数（层数*因子数）L=N(TC)
正交表的两个性质： 1. 每列中的每个数字出现的次数相同。 2. 任意两列中的每对序数出现的次数相同。
设计测试用例的步骤
1. 有哪些因素（变量）？
2、每个因素有多少个水平（变量的值）？
3. 选择合适的正交表
4. 将变量的值映射到表中
5. 使用每行中因子水平的组合作为测试用例
6. 添加您认为可疑且未出现在表中的用例组合
3.测试分类根据测试对象划分1>接口测试
界面测试（简称UI测试）是指根据界面的要求（通常是UI设计稿）和界面的设计规则，对我们软件界面上显示的所有内容进行测试和检查，一般包括以下内容：
1、验证界面内容展示的完整性、一致性、准确性、友好性。 例如界面内容适应屏幕尺寸、换行、所有内容是否清晰显示等；
2、验证整个界面的布局、排版是否合理，各部分的字体设计、图片的展示是否符合要求；
3、测试界面上的不同控件，如对话框、文本框、滚动条、选项按钮等功能是否可以正常使用，有效和无效状态是否设计合理；
4、界面布局、色调符合时事发展
例如，常见的界面错误包括重叠、截断、不合理的文字换行等。
2>可靠性测试
可靠性（），即可用性，是指系统正常运行的能力或程度，一般表示为软件服务正常向用户提供总时间的百分比。
可靠性=正常运行时间/（正常运行时间+异常运行时间）*100%。 一般来说，可用性指标一般要求达到4个或5个“9”，即99.99%或99.999%
如果可用性达到99.99%，对于一个全年不间断（7*24）运行的系统来说，意味着全年不能正常工作的时间（）只有52分钟，不到一个小时。
如果可用性达到99.999%，则意味着系统全年将只有5分钟无法正常工作。
当然，这是分类别的，不同的系统有不同的要求。
3>容错测试
容错测试是指系统能够在不导致系统崩溃的情况下处理异常和用户的错误操作，从而提高系统的可用性。主要包括以下几个方面
1、输入异常数据或执行异常操作来测试系统的防护能力。 如果系统容错性好，系统只会在内部给出提示或者消化，不会造成系统错误甚至崩溃。比如数据层面的测试、验证测试、环境容错测试、接口容错测试
2. 容灾测试
通过各种手段，强制软件发生故障，然后验证系统保存的用户数据是否丢失，是否可以尽快恢复系统和数据。
4.文件测试
在实际测试中，*常见的是对用户文件的测试，比如手册等。也会有一些公司对需求文档进行测试，以保证需求文档的质量。主要关注点有以下几点：
文档术语
文档的正确性
文档完整性
文档一致性
文档易用性
5>兼容性测试
兼容性测试要求是指明确需要测试的兼容性环境，考虑软件和硬件的兼容性。 在软件兼容性方面，主要考虑以下几个方面：
1、系统自身版本的兼容性和用户现有数据的兼容性。 数据兼容性是重中之重。 对于用户来说，数据是*有价值的。
2、测试与应用环境的兼容性，如操作系统、应用平台、浏览器兼容性
3.测试与第三方系统和第三方数据的兼容性
6>可用性测试
这使得产品使用起来更加灵活和舒适。 软件产品也始终注重用户体验，让用户拥有舒适易用的体验。 对软件这方面的测试称为可用性测试。
易用性由七个要素组成：符合标准规范、直观性、一致性、灵活性、舒适性、正确性和实用性。
1、标准化、规范性
对于现有的软件运行平台来说，通常UI标准已经在不知不觉中建立起来并成为大家的共识。 大多数用户已经习惯并接受这些标准和规范，或者同意这些信息的含义。 例如，安装软件的界面的外观以及何时使用适当的对话框。
因此，用户界面上的所有信息都应该符合规范和习惯，否则用户使用起来会不舒服，也不会被用户认可。测试人员需要将不符合标准规范和实践的问题报告为缺陷
2.直觉
用户界面的直观性要求软件的功能和特性易于理解、清晰。 用户界面布局良好，对操作的响应符合预期。 例如，数据统计结果以报表的形式（条形图、扇形图等）清晰直观地展示； 当前许多主流搜索引擎和日历的设计也具有直观的特点；
3. 灵活性
软件可以有不同的选项来满足不同使用习惯的用户完成相同的功能。 但设计时必须把握好灵活性的程度，否则可能会因过多的用户状态和模式选择而增加软件设计的复杂度和程序实现的难度。
例如手机键盘包括九方格和全键盘，还支持手写，满足不同用户的需求。
4. 舒适度
主要强调的是界面友好、外观美观、操作过程流畅、色彩运用得当、按钮的立体感等。比如鼠标左手设置，给习惯用左手的人带来了方便，并且在右手很累的时候也提供了一种替代方案；
7>安装与卸载测试
应用程序安装和卸载是任何APP中*基本的功能。 一旦发生错误，就是关键优先缺陷。 主要需要考虑以下几个方面：
1、软件安装、卸载方式不同；
2、应用程序是否可以安装在不同环系和版本下（安装兼容性）
3. 是否可以手动暂停或取消安装或卸载过程？
4、安装空间不足时系统是否提示？
5、是否可以正常卸载，以及卸载应用软件的各种方式
6、如果卸载、安装过程中出现环境问题，软件是否能够正常合理的响应，如死机、断电、断网等。
8>安全测试
安全是指信息安全，是指计算机系统或网络保护用户数据的隐私和完整性、保障数据正常传输、抵御黑客和病毒攻击的能力。安全测试是非功能性测试中非常重要的一个方面。测试。 常见的安全漏洞及对系统的威胁如下：
1. 输入字段，例如输入恶意或含有病毒的脚本或长字符串；
2.代码中的安全问题，例如SQL/XML注入
3. 数据存储或传输不安全
4、数据文件、电子邮件文件、系统配置文件等含有危害系统的信息或数据；
5、访问控制、权限分配等有问题。
6. 假身份证：身份欺骗
7、篡改、恶意修改数据、破坏数据完整性
安全测试方法包括代码审查、渗透测试、安全运维等，常用的静态安全测试工具有、、、，常用的动态安全测试有OWASP的ZAP、HP等。其中，静态安全测试是一种常用的安全测试方法。
9>性能测试
我们在使用软件时，有时会遇到软件网页打开速度越来越慢，查询数据时需要很长时间才能显示列表的情况。
运行速度越来越慢等问题都是系统性能问题造成的。
处理软件产品的性能问题，必须分析产品的性能需求，然后根据系统性能需求和系统架构，完成
完成性能测试的设计和执行，*后进行持续的性能调优。常见的性能问题如下
资源泄漏
资源瓶颈
线程死锁、线程阻塞
查询速度慢或效率低
越来越多地受到外部系统的影响
10>内存泄漏测试
很多软件系统都存在内存泄漏问题，尤其是用缺乏自动垃圾回收机制的“非托管”语言编写的程序，例如C、CH等。从用户角度来看，内存泄漏本身不会造成任何危害，而普通用户可能根本感觉不到内存泄漏的存在。 但是，内存泄漏会累积。 只要它们执行的次数足够多，所有可用内存*终都会被耗尽，导致软件执行速度越来越慢，*后停止响应。 这种软件问题可以比喻为软件的“慢性病”。 造成内存泄漏的原因有很多，*常见的有以下几种。
分配内存后，忘记回收它。
程序编写方式有问题，导致无法回收（例如无限循环导致回收步骤无法执行）。
一些API函数使用不当，导致内存泄漏。
如何检测内存泄漏
1.手动静态方法：代码读取，手动查找未回收的内存。
2、自动工具法：使用相应的内存泄漏测试工具，如Leak，记录每次内存分配，并清楚地告诉用户内存是如何泄漏的。
按照是否查看代码来划分
在软件测试职位的面试中，面试官经常问到的概念是黑盒测试和白盒测试。 下面让我们彻底讨论它们。
1>黑盒测试
黑盒测试是在不考虑程序逻辑和内部结构的情况下自动化软件开发，检查系统功能是否按照需求规范正常使用，是否能够正确接收输入数据并输出正确的结果，满足规范要求。因此，黑盒测试也称为数据驱动测试，只关注软件的功能。 黑盒测试的优点
不需要了解程序内部的代码和实现，也不关注软件的内部实现。
2.从用户的角度设计测试用例。 很容易知道用户会使用哪些功能、会遇到什么问题，训练测试人员的产品思维。
3、测试用例基于软件需求开发文档，不容易漏掉软件需求文档中需要测试的功能。
黑盒测试的缺点是无法覆盖所有代码
常用的方法有等价类法、边界值法、误差猜测法、因果图法、情景法等。
2>白盒测试
白盒测试也称为结构测试或逻辑测试。 一般用于分析程序的内部结构，根据程序的逻辑结构设计测试用例进行测试。
白盒测试的目的是通过检查软件内部逻辑结构来覆盖软件中的逻辑路径； 在程序的不同地方设置检查点来检查程序的状态，以确定实际运行状态是否与预期状态一致。
主要包括语句覆盖、决策覆盖、条件覆盖、决策条件覆盖、条件组合覆盖、路径覆盖六种测试方法。
3>灰盒测试
灰盒测试是介于白盒测试和黑盒测试之间的测试。 灰盒测试主要用于集成测试阶段。 它不仅关注输出和输入的正确性，还关注程序的内部条件。
按开发阶段划分 1>单元测试
单元测试是对软件组件的测试。 其目的是验证软件基本组件的正确性。 测试的对象是软件设计的*小单元：模块。也称为模块测试
测试阶段：编码后或者编码前（TDD）
测试对象：*小模块
测试人员：白盒测试工程师或开发工程师
测试依据：代码和注释+详细设计文档
测试方法：白盒测试
测试内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试
2>集成测试
集成测试也称为联合测试（联合调试）和组装测试。 它使用适当的集成策略组装程序模块，并测试系统接口和集成功能的正确性。 集成的主要目的是检查软件单元之间的接口是否正确。
测试阶段：一般单元测试之后进行
测试对象：模块间的接口
测试人员：白盒测试工程师或开发工程师
测试依据：单元测试的模块+概要设计文档
测试方法：黑盒测试与白盒测试相结合
测试内容：模块之间数据传输、模块之间功能冲突、模块组装功能正确性、全局数据结构、单模块缺陷对系统的影响
3>系统测试
把软件系统看成是一次系统性的测试。包括测试功能、性能以及软件运行的软硬件环境
测试阶段：集成测试通过之后
测试对象：整个系统（软、硬件）
测试人员：黑盒测试工程师
测试依据：需求规格说明文档
测试方法：黑盒测试
测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等
4>回归测试
回归测试是指修改旧代码后重新测试，以确认修改没有引入新的错误或导致其他代码产生错误。
它在整个软件测试过程中占据很大比例的工作量，在软件开发的每个阶段都会进行多重回归测试。 随着系统变得越来越大，回归测试的成本也越来越大。 选择正确的回归测试策略对于提高回归测试的效率和效果是有意义的。
5>冒烟测试
冒烟测试的对象是每个新编译的需要正式测试的软件版本。 目的是在正式系统测试前确认软件主要功能和核心流程正常并执行。 冒烟测试一般是在开发人员完成开发并提交给测试人员进行测试后进行的。 先进行冒烟测试，确保基本功能正常，且不妨碍后续测试。
如果冒烟测试通过，测试人员就开始正式的系统测试。 如果失败，测试人员可以要求开发人员再次修复代码，直到冒烟测试通过，然后开始系统测试。
回归测试和冒烟测试都是系统测试。
6>验收测试
验收测试是部署软件之前的*后一个测试操作。 它是技术测试的*后阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并向软件购买者证明软件系统按照项目合同、任务满足*初的要求。声明、双方同意的验收依据文件。
测试阶段：系统测试通过之后
测试对象：整个系统（包括软硬件）。
测试人员：主要是*终用户或者需求方。
测试依据：用户需求、验收标准
测试方法：黑盒测试
测试内容：同系统测试(功能...各类文档等)
按测试实施组织 1> Alpha 测试 (Alpha)
手机出厂前的*后一次测试，开发和测试人员不参加。
Alpha测试是用户在开发环境中进行的测试，也可以是公司内部用户在模拟实际运行环境中进行的测试。 alpha 测试的目的是评估软件产品（即功能、本地化、可用性、可靠性、性能和支持）。 大型通用软件在正式发布之前通常需要进行Alpha和Beta测试。 Alpha 测试不能由程序员或测试人员完成。
大型通用软件在正式发布之前通常需要进行Alpha和Beta测试。 Alpha 测试不能由程序员或测试人员完成
2>β测试（Beta）
Beta 测试是一种验收测试。 Beta 测试由软件的*终用户在一个或多个地点进行。
alpha 测试和 beta 测试的区别：
测试地点不同：Alpha测试是指邀请用户到开发者场所进行测试，而Beta测试是指在一个或多个用户场所进行测试。
Alpha测试环境由开发者控制，用户数量相对较少，时间相对集中。 Beta测试环境不受开发者控制，用户数量比较多，时间不集中。
Alpha 测试在 Beta 测试之前执行。 一般软件产品都需要进行大规模的beta测试，测试周期也比较长。
3>第三方测试
由开发人员和用户之间的组织进行测试。
除以是否运行1>静态测试()
所谓静态测试（ test），就是不实际运行被测软件，而只是静态地检查程序代码、接口或文档中可能存在的错误的过程。 它不是测试数据的执行，而是测试对象的分析过程。 仅通过分析或检查源程序的设计、内部结构、逻辑、编码风格和规范来检查程序的正确性。
2>动态测试（ ）
动态测试是指实际运行被测程序，输入相应的测试数据，检查实际输出结果是否与预期结果相符的过程。 因此，判断一个测试是动态测试还是静态测试的唯一标准就是它是否运行
程序。
按是否手动划分 1> 手动测试（）
手动测试涉及人们一一输入用例，然后观察结果。 这是与机器测试相对应的一个相对原始但必要的步骤。 总结一下优点和缺点：
优点：自动化无法取代探索性测试和发散思维结果的测试。
缺点：执行效率慢、体积大、容易出错。
2>自动化测试( )
就是在预设条件下运行系统或应用程序并评估运行结果。 前提条件应包括正常条件和异常条件。 简单来说，自动化测试就是将人类驱动的测试行为转化为机器执行的过程。
自动化测试如功能测试自动化、性能测试自动化、安全测试自动化等。
自动化测试按照测试对象来划分，还可以分为界面测试、UI测试等。界面测试的ROI（产出投入比）高于UI测试。
自动化实施步骤：
1.完成功能测试，版本基本稳定
2.根据项目特性，选择适合项目的自动化工具，并搭建环境
3.提取手工测试的测试用例转化为自动化测试的用例
4.通过工具、代码实现自动化的构造输入，自动检测输出结果是否符合预期
5.生成自动测试报告
6.持续改进，脚本优化。
按测试区域划分1>国际测试
软件国际化和软件本地化是为全球不同地区的用户开发软件系统的两个过程。 本地化测试和国际化测试就是针对此类软件产品的测试。 由于软件的全球化和软件外包行业的兴起，软件本地化和国际化测试已成为一个独特的测试领域。
本地化和国际化测试在很多方面与其他类型的测试不同。 以下是本地化和国际化测试的一些要点。
1、本地化软件的外观与原版是否有明显差异，外观是否一致、无锯齿。
2. 所有界面元素是否已本地化每个公司、每一个工具对bug生命周期的定义，包括对话框、菜单、工具栏、状态栏、提示信息（包括
声音提示）、日志等。
3、不同屏幕分辨率下界面是否正常显示。
4、是否存在不同的字体大小，字体设置是否合适。
5、日期、数字格式、货币等能否适应不同国家的文化习俗。例如中文是年月日，英文是月日。
年。
6、排序方式是否考虑到不同语言的特点。例如中文按首字符拼音顺序排序，英文按首字符拼音顺序排序
按字母顺序排序。
7. 如果不同国家使用不同的计量单位，软件是否可以适配和转换。
8、软件能否在不同类型的硬件上正常运行，特别是在当地市场上销售的流行硬件上。
9、软件在其他操作系统的本地版本上是否可以正常运行。
10、在线帮助和文档是否已经翻译，翻译后的链接是否正常。文本翻译是否正确、恰当，是否有语法
错误。
and is a type that the and the . It to have , , and basic as .
2>
What we about was all about .
