【测试开发】 测试题总结

祝天天开心

文章目录

  • 1. 测试用例编写
  • 2. 如何对bug进行描述
  • 3. bug状态转换
  • 4. 测试人员和开发人员产生争执
  • 5. 登录功能测试用例设计
  • 6. 测试生命周期
  • 7.


1. 测试用例编写

编写水杯的测试用例
注意,测试用例有一个万能公式
功能测试+性能测试+页面测试+安全性测试+兼容性测试+易用性测试,每点最少写四到五条。下图为例子。
【测试开发】 测试题总结_第1张图片

2. 如何对bug进行描述

  1. 发现问题的代码版本,一定要说明是哪个版本的代码出了问题
  2. 问题出现的环境,例如手机app要描述手机型号,操作系统版本,web网站要描述浏览器名称,客户机操作系统。
  3. 错误重现的步骤,要描述问题出现的最短步骤
  4. 预期行为的描述,从用户的角度说明,怎样是正确的。
  5. 错误行为的描述,描述错误的现象,可以穿截图,log等。
    登陆的判断条件不完整

下面这个例子,是登录功能未能屏蔽特殊字符有的bug提交

故障发现版本,blogsystem-xShell版
故障类别:功能性
故障级别:一般
故障标题:用户名输入判断异常,未能屏蔽特殊字符

故障描述
测试环境,chrome浏览器,浏览器为113.0版本,Linux操作系统
测试步骤,在登陆框用户名内输入特殊字符,可注册成功
预期结果,在登陆框内输入特殊字符,输出错误提示: 用户名不能有特殊字符
实际结果,用户名含特殊字符,可注册成功
附件:截图

3. bug状态转换

如下图,为bug状态转换图
【测试开发】 测试题总结_第2张图片

  1. New,发现一个bug
  2. Open,确认这个的确是一个bug
  3. Reject,编程人员认为这不是一个bug,拒绝修改。Delay,由于一些原因,需要延时修改
  4. Fixed,bug正在被修改中
  5. Closed,bug被修改,通过测试
  6. End,结束
  7. Reopen,经修改后的bug未通过验证,需要编程人员再次修改

4. 测试人员和开发人员产生争执

  1. 先保证自己描述bug足够清晰准确
  2. 和开发人员沟通,从用户角度说明,这个为什么是bug
  3. 关于bug等级划分,一定要有理有据
  4. 若实在无法沟通,可组织bug评审,邀请开发、测试、产品等代表参会,针对该问题进行分析如何进行解决。

5. 登录功能测试用例设计

【测试开发】 测试题总结_第3张图片

6. 测试生命周期

软件测试生命周期一般包括以下阶段:

需求分析:在这个阶段,测试团队与开发团队一起分析客户需求和系统规格说明书,以确保他们理解项目的要求,并能够创建相关测试计划。

测试计划:在这个阶段,测试团队将根据需求分析结果制定测试计划。测试计划应该明确测试目标、测试方法、测试环境、测试资源和测试进度等信息。

测试设计:在这个阶段,测试团队将根据测试计划设计测试用例,包括测试场景、测试数据和预期结果等。

测试执行:在这个阶段,测试人员将执行测试用例,记录测试结果并跟踪缺陷

缺陷管理:在测试执行阶段,测试人员将会发现缺陷。这些缺陷需要进行详细记录,分类和优先级排序,并由开发团队进行修复。

测试报告:在这个阶段,测试团队将撰写测试报告,概述测试过程、测试结果及缺陷情况。测试报告应该清晰明了,帮助开发团队识别和解决问题。

测试结束:在这个阶段,测试团队将对所有缺陷进行验证,并确认所有测试用例已经被执行。同时,测试团队也将对测试过程和测试结果进行总结

7.

黑盒测试(Black-box testing)是一种软件测试方法,它主要通过输入和输出来检查系统的功能是否符合预期。测试人员只关注系统的外部行为,而不考虑内部实现细节。

在黑盒测试中,测试人员不需要了解被测试系统的内部结构和代码逻辑,而是基于需求规格说明或者用户手册等测试用例规范进行测试,以验证系统在不同输入条件下的响应和输出是否与预期结果一致。

这种测试方法可以帮助测试人员更全面地测试系统,并发现用户可能会遇到的问题。它可以检查系统是否满足需求规范和用户期望,并且可以帮助测试人员发现未被预料到的错误。
白盒测试(White-box testing)是一种软件测试方法,它主要通过检查代码的内部结构和实现细节来评估系统的正确性和健壮性。测试人员需要了解被测试系统的内部逻辑和数据流程,并使用这些信息来设计测试用例。

在白盒测试中,测试人员基于程序源代码或者其他内部文档进行测试,以确保代码的每个分支和路径都得到覆盖。这样可以发现在不同情况下代码执行中的错误、死循环、空指针异常等问题。

这种测试方法通常用于对关键功能的测试,比如安全性、性能等方面的测试。白盒测试可以帮助测试人员更好地理解软件系统的内部机制,从而提高测试效率和准确性,同时也可以为开发人员提供有价值的反馈,帮助他们改进代码质量。
灰盒测试(Gray-box testing)是介于白盒测试和黑盒测试之间的一种测试方法。在灰盒测试中,测试人员通常具有部分关于系统内部功能和实现的信息,但并不完全了解系统的全部实现细节。

相对于黑盒测试,灰盒测试可以更深入地理解被测试系统的内部机制,同时也可以适当地减少测试人员的工作量。通常,测试人员会使用系统的设计文档、API文档或其他相关信息来编写测试用例,以便在足够的覆盖率下检查代码的正确性和健壮性。

与白盒测试相比,灰盒测试可以更好地模拟用户的真实使用场景,从而发现一些由于外部因素导致的问题。此外,灰盒测试也可以提供一些有价值的反馈,帮助开发人员改进代码质量。
冒烟测试是软件测试中的一种快速而基础的测试方法,目的在于检查软件或系统的主要功能是否正常。通常会在软件或系统的关键部分进行测试,以验证其是否能够在基本场景下正常工作。这些测试通常在软件开发周期的早期阶段进行,以捕捉问题并尽早解决。

冒烟测试可以帮助团队及时发现问题,因为它们可以在很短的时间内执行,通常只需要几分钟到几个小时。如果出现问题,则可以立即通知开发人员和测试人员,并进行必要的修复和更深入的测试。由于冒烟测试的效率和快速性,它们被广泛应用于DevOps实践中。
显式等待和隐式等待都是在自动化测试中用来处理页面加载和元素定位的技术。它们的主要区别在于等待的方式和时机。

隐式等待会在代码中设置一个默认时间,当代码执行到需要定位某个元素的语句时,如果该元素还没有加载出来,程序就会等待一段时间,直到元素加载完成或达到了设置的超时时间。这种等待方式是全局性的,适用于整个测试过程,不需要添加额外的代码。

相比之下,显式等待是针对某个具体的操作或元素定位而设定的等待时间,需要在代码中显式地添加等待语句。通过使用WebDriverWait类和ExpectedConditions条件来实现。显式等待只有在满足特定条件时才会停止等待,例如,直到某个元素可见、可点击或者包含特定文本等。

因此,可以看出隐式等待更适合用于简单的场景,而显式等待则更适用于大型复杂的应用程序中。

你可能感兴趣的:(测试开发,服务器,运维)