【测试开发】软件测试基础篇

简介: 软件测试的生命周期软件测试&软件开发生命周期如果描述一个bug如何定义bug的级别bug的生命周期如何开始第一次测试测试的执行和bug管理如何发现更多的bug?产生争执怎么办

软件测试的生命周期


软件测试的生命周期:

需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估


软件测试&软件开发生命周期


需求阶段

–测试人员了解需求、对需求进行分解,得出测试需求

计划阶段

根据需求编写测试计划/测试方案

设计阶段

–测试人员适当的了解设计,对于设计测试用例是很有帮助的,测试人员搭建测试用例框架,根据需求和设计编写一部分测试用例

编码阶段

–测试人员一般是不需要编码的,但已经编码的模块,专业的白盒测试人员可以计划执行单元测试,完善、细化测试用例以及调整测试计划和方案。

测试阶段

–测试阶段是软件测试人员最为重要的工作阶段,根据测试用例和计划执行测试,在执行的过程中记录、管理

缺陷,测试完成后编写测试报告。

运行维护

–测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解,加上测试人员的沟通表达能力一般都比较强,所以测试人员可以参与用户使用软件的培训,在试运行项目时收集问题并及时反馈给相关负责人


如果描述一个bug


一个合格的bug描述应该包括以下几个部分:


发现问题的版本

开发人员需要知道出现问题的版本,才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。

问题出现的环境

环境分为硬件环境和软件环境,如果是web项目,需要描述浏览器版本,客户机操作系统等,如果是app项目,需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

错误重现的步骤

描述问题重现的最短步骤。

预期行为的描述

要让开发人员知道怎么样才是正确的,尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障,能写明需求的来源是最好的。

要相信:测试人员是最懂需求的。

错误行为的描述

描述错误的现象。crash等可以上传log,UI问题可以有截图。

其他

某些公司会有一些其他的要求,例如故障的分类:功能故障,界面故障,兼容性故障等。有些有优先级的分类,严重影响测试需要开发人员优先修改的,可以设置优先级为高。

不要把多个bug放到一起

在无法确认是同一段代码造成的故障时,不要将bug放在一起提交。

案例: 网易邮箱注册测试

65.png


如何定义bug的级别


在开发和测试的争执中,一部分是究竟是不是bug?一部分是bug的级别有点高吧?那么如何定义bug的级别?


男盆友的行为严重级别


和别的妹子约炮(崩溃)

和别的妹子搞暧昧(严重)

和别的妹子一起吃饭(一般)

多看了别的妹子几眼(次要)

bug的定义每个公司都不一致,在定义级别之前需要查看公司规范。


以下为样例:


Blocker(崩溃):

阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。

Critical(严重):

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)。

Major(一般):

功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多)

Minor(次要):

界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)


bug的生命周期


每个公司、每一个工具对bug生命周期的定义都是不一致的,下面仅是一个常见的例子


测试人员应该跟踪一个Bug的整个生命周期,从Open到Closed的所有状态


66.png


New:新发现的Bug,未经评审决定是否指派给开发人员进行修改。

Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员。

Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证

Rejected:如果认为不是Bug,则拒绝修改。

Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。

Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug

Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改。

无效的bug:open->closed open-rejected-closed


Bug的跟踪以及状态变更应该遵循一些基本原则:


测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试,确保相同的问题不再出现,才能关闭缺陷。


对于拒绝修改和延迟修改的Bug,需要经过包含测试人员代表和开发人员代表、用户方面的代表(或代表用户角度的人)的评审。


如何开始第一次测试


作为一个菜鸟在进入测试团队开始第一次测试的时候,我们需要做很多的准备:


1、阅读所有项目有关的文档,包括:需求文档、设计文档、用户手册

2、尽可能参加各种项目会议,了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务专业性较强

的项目,例如银行业务,需要了解各种业务知识,如高低柜、一二三类账户等、存款、贷款等。

3、熟悉项目所使用的测试管理工具、配置管理工具,获取对应的地址和登录方式

4、阅读已有的测试方案和测试案例

5、阅读旧有的bug库,了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则

6、了解公司的规范要求,特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规范等


在进行了以上的准备工作之后,第一次测试工作到来了,我们需要与测试组长确认


具体的工作内容:


1、测试的计划是什么?

2、测试的内容是什么?test case有多少?安排了几天执行?有没有自由测试的时间?

3、我要测试的内容开发人员是谁?需求人员是谁?

4、分配给我的测试内容是否需要特殊的测试资源?资源是否满足需要?


在我们确认了以上内容之后,就可以开始测试的执行了


测试的执行和bug管理


现在我们开始进行测试了:


打开待测试的系统

打开测试管理工具用例模块,开始执行用例

发现bug!进行复现并确认bug的复现步骤

记录bug

沟通bug

验证以前提交的bug

确认本次测试完成

编写测试报告

执行测试时处理要做到测试用例和需求的覆盖外,还要有临时发挥的能力。根据自己的经验、对测试的感悟以及随机测试可以发现很多根据测试用例无法发现的缺陷。


不能拘泥于测试用例或者已经有的测试方法,在测试执行过程中要不断总结测试方法和测试故障模型。真正优秀的测试人员在执行测试时是想着做,做着想,这样的测试效果才好,尤其是在测试过程中,对程序的处理相当了解的情况下,测试的思路会更加清晰和全面。


如何发现更多的bug?


软件测试同样存在二八原则,80%的故障集中于20%的模块,如果某部分问题较多,加强测试广度和深度!

开发人员也存在二八原则,80%的故障集中于20%的开发人员,如果某些开发人员的bug较多,加强他开发模块的测试广度和深度!

多进行逆向思维和发散性的思维

不要局限于用例和需求文档

尽早介入项目, 不要等到开发的差不多了再介入项目


产生争执怎么办


67.png



相关文章
|
24天前
|
运维 Ubuntu 测试技术
自动化运维的利剑:Ansible在配置管理中的应用软件测试的艺术:探索性测试的深度与广度
【8月更文挑战第27天】 在数字化浪潮中,高效的运维工作是支撑企业IT系统稳定运行的关键。Ansible,作为一款简易而强大的自动化运维工具,正逐渐成为IT专业人士的新宠。本文将通过浅显易懂的语言和生动的案例,带你了解Ansible的核心概念、安装步骤、基础命令以及它在配置管理中的实际应用。我们的目标是让初学者能够轻松上手Ansible,同时为有经验的运维工程师提供一些实用的技巧和思路。
|
23天前
|
安全 测试技术
软件测试的艺术:探索性测试的奥秘
【8月更文挑战第28天】在软件开发的宇宙中,测试是那颗指引航船安全抵达目的地的北极星。探索性测试(Exploratory Testing, ET)作为一种灵活而富有创造性的测试实践,它如同艺术家的画笔,描绘出软件质量的全貌。本文将带你领略探索性测试的魅力,从其哲学到实操技巧,再到如何与自动化测试和谐共存,我们将一同走进这个充满未知与惊喜的软件测试领域。
|
24天前
|
SQL 安全 测试技术
网络安全的屏障与钥匙:漏洞防护与加密技术解析软件测试的艺术:探索性测试的力量
【8月更文挑战第27天】在数字时代的海洋中,网络安全是保护我们数据资产的灯塔和堤坝。本文将深入浅出地探讨网络安全领域的关键要素——安全漏洞、加密技术以及不可或缺的安全意识。通过实际案例分析,我们将了解如何识别和修补潜在的安全漏洞,掌握现代加密技术的工作原理,并培养起一道坚固的安全防线。文章旨在为读者提供实用的知识和技能,以便在日益复杂的网络环境中保持警惕,确保个人及组织信息的安全。
|
3天前
|
机器学习/深度学习 人工智能 测试技术
软件测试中的自动化测试实践与挑战
本文深入探讨了软件测试领域中的自动化测试,从基本概念到实际应用案例,揭示了自动化测试在提升软件开发效率和质量中的关键作用。同时,文章也分析了在实施自动化测试过程中面临的主要挑战,并提出了相应的解决策略。
18 5
|
5天前
|
敏捷开发 测试技术 UED
软件测试的艺术:探索性测试的力量
【9月更文挑战第14天】在软件开发的海洋中,测试是确保航船不沉没的灯塔。本文将带你领略一种非传统的测试方法——探索性测试的魅力和力量。我们将一起揭开这种方法的神秘面纱,通过具体案例分析,理解它如何提升软件质量和用户体验。准备好扬帆起航,一起探索未知吧!
|
5天前
|
监控 jenkins 测试技术
软件测试中的自动化测试策略与实践
本文将深入探讨自动化测试在软件开发中的重要性及其实施策略。我们将从自动化测试的基本概念入手,分析其在提高软件质量、缩短开发周期和降低维护成本方面的优势。通过具体案例,展示如何有效地规划和执行自动化测试,以及如何评估其效果。
13 1
|
7天前
|
安全 测试技术 UED
软件测试的艺术:探索性测试的力量
【9月更文挑战第12天】在软件开发的海洋中,测试是导航船只安全航行的关键。本文将深入探讨一种独特的软件测试方法——探索性测试(Exploratory Testing),它如同艺术家的画笔,通过即兴和创造性的测试活动揭示软件之美与缺陷。我们将一起航行于探索性测试的浪潮之中,了解它如何增强测试过程的灵活性、深度和乐趣,同时提供高效和有效的质量保证。
|
20天前
|
监控 测试技术 Python
软件测试的艺术与科学:探索测试自动化的奥秘
【8月更文挑战第30天】在软件开发的海洋中,测试是那把确保航船不偏离航线的罗盘。本文将带您一探究竟,从测试的基础到高级自动化策略,揭示如何通过代码和工具提升测试效率。准备好启航,因为我们将深入探讨软件测试的核心,以及如何利用自动化技术来优化您的测试流程。
17 4
|
21天前
|
物联网 测试技术 持续交付
软件测试的艺术与科学:探索自动化测试框架未来技术的融合与创新:探索区块链、物联网和虚拟现实的交汇点
【8月更文挑战第30天】在软件开发的海洋中,测试是确保航行安全不可或缺的灯塔。本文将带领读者揭开软件测试神秘的面纱,深入理解自动化测试框架的重要性和实现方法。通过实际案例,我们将一起探索如何构建高效、可靠的自动化测试系统,从而保障软件质量,提升开发效率。
|
24天前
|
测试技术
软件测试的艺术:探索性测试的力量
【8月更文挑战第27天】在软件测试领域,探索性测试(Exploratory Testing)是一种既自由又创造性的测试实践。它不依赖于事先编写的测试用例,而是鼓励测试人员发挥他们的直觉、经验和逻辑推理能力,去发现软件中可能隐藏的缺陷和问题。这种方法强调的是测试过程的灵活性和适应性,让测试更加贴近实际的用户场景和需求。探索性测试不仅能够提高测试效率,还能够促进测试人员之间的知识共享和协作。