测试一些概念
软件测试
软件测试流程
需求分析:在这个阶段,测试人员会审查和分析项目的需求文档,以确保他们理解需要测试的功能和特性。
制定测试计划:在这个阶段,测试人员会制定一个详细的测试计划,包括测试目标、测试范围、测试资源、测试时间表和风险等。
测试设计:在这个阶段,测试人员会根据需求文档和测试计划,设计各种测试用例和测试脚本。
环境设置:在这个阶段,测试人员会设置所需的测试环境,包括硬件、软件和网络等。
测试执行:在这个阶段,测试人员会按照测试计划和测试用例,执行测试,并记录测试结果。
测试结果分析:在这个阶段,测试人员会分析测试结果,确定是否存在 defects,并记录 bug 报告。
defects 跟踪和修复:在这个阶段,开发人员会根据 bug 报告,修复 defects,并将修复后的代码交 back 给测试人员进行重新测试。
测试结束和评估:在这个阶段,测试人员会评估测试结果,确定是否满足测试计划和需求文档的要求,并做出相应的决策,例如是否需要进行后续测试。
黑盒白盒
黑盒测试不关心软件内部实现细节,只关注软件的输入和输出行为
测试方法:包括等价类划分、边界值分析、因果图分析、错误推测法等。
白盒测试是基于内部逻辑和结构的测试方法,测试人员需要了解程序内部工作原理
测试内容:主要测试软件的内部逻辑和结构,确保所有的代码路径都被执行。
测试方法:包括语句覆盖、判定覆盖、条件覆盖、路径覆盖等。
执行者:黑盒测试通常由测试人员执行,白盒测试通常由开发人员执行。
测试阶段:黑盒测试在软件开发的后期进行,白盒测试在开发的早期阶段进行。
覆盖范围:黑盒测试可能无法覆盖所有代码路径,白盒测试则尝试覆盖所有可能的代码路径。
自动化测试工具
postman接口测试
它能够发送任何类型的HTTP请求 (GET, POST, PUT, DELETE…)
Selenium WEB自动化测试
Selenium 支持多系统环境(Windows,Mac,Linux)以及多种浏览器(Chrome,FireFox,IE以及无头浏览器(没有界面))。它的脚本可以由各种各样的编程语言编写,比如 Java,Groovy,Python,C#,PHP,Ruby 以及 Perl。
Jmeter 接口测试,性能测试
Apache JMeter是一个开源的Java桌面应用程序,主要用于web应用程序的负载测试。它还支持单元测试和有限的功能测试。
它有很多好的特性,比如动态报告、可移植性、强大的测试IDE等,并且支持不同类型的应用程序、协议、shell脚本、Java对象和数据库。
测试用例编写
从那些方面考虑,举一个例子
- 功能性测试(Functional Testing):测试系统是否符合预期功能,是否能够正确地执行任务。
- 界面测试(UI Testing):测试系统的用户界面是否易于使用、符合设计规范,并且能够正确地显示所需的信息。
- 性能测试(Performance Testing):测试系统的性能和响应时间,以确保系统能够在各种负载下正常工作。
- 安全测试(Security Testing):测试系统的安全性,以确保系统能够保护用户的数据和个人信息。
- 兼容性测试(Compatibility Testing):测试系统是否能够在不同的平台、浏览器和操作系统上正常工作。
- 可靠性测试(Reliability Testing):测试系统的可靠性和稳定性,以确保系统能够在长期运行时保持正常工作。
假设你正在测试一个在线购物网站,这个网站包括用户注册、登录、浏览商品、添加到购物车、结账和支付功能。这是一个结合了Selenium和JMeter的综合测试例子:
Selenium测试:
功能测试:
用户注册:使用Selenium模拟用户输入用户名、密码、邮箱等信息,验证注册是否成功,密码是否加密存储。
登录:输入注册的用户名和密码,验证登录是否成功,会话是否有效。
商品浏览:模拟用户浏览商品列表,点击商品查看详情,检查商品信息是否正确。
添加到购物车:选择商品后,点击添加到购物车,验证商品是否成功添加,购物车数量是否正确。
结账:从购物车中选择商品进行结算,检查总价、优惠信息等是否正确。
支付:模拟支付过程,验证支付接口是否正常,支付状态是否更新为已支付。
JMeter测试:
性能测试:
压力测试:设置多个虚拟用户同时访问网站,测试在高并发情况下,如注册、登录、商品浏览等操作的响应时间、吞吐量和系统稳定性。
负载测试:测试在不同负载(如每秒请求量)下的系统性能,如服务器CPU使用率、内存占用、数据库查询速度等。
稳定性测试:持续运行JMeter测试脚本,观察系统在长时间运行下的稳定性,检查是否有崩溃、错误或性能下降的情况。
数据库
sql增删改查
sql注入
常见响应状态码
网页响应状态码是HTTP协议中用于表示请求结果的一种编码方式,由三位数字组成,用于告知客户端请求的处理结果。状态码通常以HTTP/1.1协议为例,分为多个类别,用于描述不同类型的响应情况。以下是一些常见的HTTP状态码:
-
1xx:信息性响应 - 表示请求已被接收,继续处理。
- 100: Continue - 服务器收到部分请求信息后,通知客户端可以继续发送剩余信息。
- 101: Switching Protocols - 服务器告知客户端将切换到另一种协议进行后续通信。
-
2xx:成功响应 - 表示请求已被成功接收、理解并处理。
- 200: OK - 请求成功,数据已发送。
- 201: Created - 请求已成功处理,并创建了一个新的资源。
- 202: Accepted - 服务器已接受请求,但尚未处理。
- 204: No Content - 请求已成功处理,但没有返回任何内容。
- 206: Partial Content - 对范围请求的响应,只返回请求的部分内。
-
3xx:重定向 - 表示需要进一步操作以完成请求。
- 301: Moved Permanently - 请求的资源已被永久移动到新位置。
- 302: Found - 请求的资源临时移动到新位置。
- 304: Not Modified - 服务器响应客户端的GET请求时,告知客户端资源未修改,可以使用缓存中的版本。
- 307: Temporary Redirect - 请求的资源临时移动到新位置。
-
4xx:客户端错误 - 表示客户端的请求有错误。
- 400: Bad Request - 服务器不理解请求的语法。
- 401: Unauthorized - 请求需要用户验证。
- 403: Forbidden - 服务器拒绝请求,通常是因为权限问题。
- 404: Not Found - 请求的资源不存在。
- 405: Method Not Allowed - 请求的资源不支持请求中指定的方法。
- 408: Request Timeout - 服务器等待客户端响应超时。
-
5xx:服务器错误 - 表示服务器未能完成请求。
- 500: Internal Server Error - 服务器遇到了一个未预见的情况,无法完成请求。
- 501: Not Implemented - 服务器不支持请求的功能。
- 502: Bad Gateway - 中间网关或代理服务器收到无效的响应。
- 503: Service Unavailable - 服务器当前无法使用(过载或维护)。
- 504: Gateway Timeout - 服务器作为网关或代理使用时,未能及时从上游服务器收到响应。
怎么确定BUG是前端还是后端
确定 Bug 是在前端还是后端的方法如下:
- 首先,需要了解 Bug 的具体描述和现象,例如:页面显示错误、数据保存不正确、系统崩溃等。
- 根据 Bug 的描述,可以初步确定 Bug 可能出现的范围,例如:页面显示错误可能是前端 CSS/HTML 问题;数据保存不正确可能是后端逻辑问题;系统崩溃可能是服务器或后端代码问题。
- 通过调试和日志分析,可以更准确地确定 Bug 的来源。
对于前端 Bug:
- 可以使用浏览器的开发者工具(F12),分析网络请求和响应、查看 Console 日志、检查 DOM 元素和样式等。
- 可以使用代码调试工具,例如 VSCode 的 Debugger 插件,逐行执行代码,查看变量和函数的执行结果。
对于后端 Bug:
- 可以使用后端服务器的日志记录,例如 Nginx、Apache、Tomcat 等,查看请求和响应的详细信息。
- 可以使用后端代码的调试工具,例如 IDEA 或 VSCode 的 Debugger 插件,逐行执行代码,查看变量和函数的执行结果。
通过以上分析和调试,可以确定 Bug 是在前端还是后端。同时,也需要考虑到可能是两端都存在问题的情况,例如:前端发送的参数和格式不正确,导致后端代码无法正常执行。
压力测试
压力测试(Stress Testing)是一种软件测试方法,其目的是评估系统在超出正常工作负载或预期使用情况下的性能、稳定性、可靠性和资源消耗。压力测试通常用于以下几个方面:
极限测试:测试系统在最大负载或最大并发用户情况下的表现,以验证其是否能够处理预期的峰值流量。
容量测试:确定系统在一定时间内的处理能力,比如每秒处理多少请求,以确保系统在高流量下仍能正常运行。
性能评估:测试系统在特定任务下的响应时间、吞吐量和资源利用率,以优化系统性能。
故障检测:通过模拟过载或异常情况,检查系统是否能正确处理错误,或者在压力下是否会出现崩溃或数据丢失。
负载均衡:测试系统在分布式环境中的负载均衡能力,确保各组件能够协同工作,避免单点故障。
性能测试
性能测试(Performance Testing)是软件测试的一个重要组成部分,它关注的是系统在正常或异常工作负载下的运行效率、响应时间和资源使用情况。性能测试的目的是:
评估系统性能:测量系统在不同负载条件下的响应时间、吞吐量、并发用户数等性能指标,以确定其是否符合预期的性能要求。
发现性能瓶颈:通过模拟大量用户或数据流量,找出系统中的性能瓶颈,如数据库查询效率低、网络延迟、内存不足等。
优化系统设计:根据测试结果,对系统架构、代码、数据库查询等进行优化,提高整体性能。
验证系统容量:确定系统在高负载下的最大处理能力,确保在高峰期也能提供良好的用户体验。
负载和压力测试:测试系统在极限情况下的性能,如最大并发用户数、最大数据量等,以确保系统在压力下仍能正常运行。
Debug和 Release测试区别:
Debug(调试)和 Release(发布)测试主要有以下区别:
-
优化程度:
- Release 版本通常会进行各种优化,例如代码优化、性能优化等,以提高程序的运行效率和速度。
- Debug 版本则更侧重于提供调试信息和工具,优化程度相对较低。
-
调试信息:
- Debug 版本包含大量的调试符号和信息,方便开发者在调试过程中查看变量的值、调用堆栈等,有助于定位和解决问题。
- Release 版本通常会去除这些调试信息,以减小程序的体积和提高运行性能。
-
错误检查:
- Debug 版本可能会进行更严格的错误检查和边界检查,以便在开发过程中尽早发现潜在的问题。
- Release 版本可能会减少一些不必要的错误检查,以提高性能。
-
内存使用:
- Debug 版本在内存管理方面可能相对宽松,例如不进行某些内存优化,以便更易于发现内存相关的错误。
- Release 版本会更注重内存的高效使用和管理。
-
运行速度:
- 由于优化和调试信息的差异,Release 版本的运行速度通常比 Debug 版本快。
-
可执行文件大小:
- Release 版本的可执行文件通常比 Debug 版本小,因为去除了调试信息等。
在实际开发中,开发者通常在 Debug 环境中进行开发和调试,确保程序功能正确无误,然后在发布前切换到 Release 环境进行测试和优化,以提供给用户性能更好、更稳定的程序。