- 博客(390)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 计算机网络——DNS域名系统
本地DNS服务呗黑客攻击，给用户返回了错误的IP，用户发送的域名解析出了其他页面在DNS查询服务器的过程中某个域名服务器被替换了，从而导致最终查到的是错误的IP拒绝服务攻击，简称DOS攻击，一种网络攻击手法，其目的在于使目标电脑的网络或系统资源耗尽，使服务器暂时中断或停止，导致其正常用户无法访问4.如何防范DNS攻击？个人选取可信度高的DNS服务器。
2023-06-21 19:41:20
120
原创 计算机网络——安全传输，HTTPS协议，TLS原理（HTTPS加密认证的过程）
数字证书是指在互联网通信中标志通信各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份。数字证书是可信任组织颁发给特定对象的认证。数字证书包括：证书格式，版本号，证书序列号，签名算法，有效期，对象名称，对象公开密钥...不是，因为只有加密，不能解密。在进行哈希操作前，给要哈希的对象添加一个自定义的字符。
2023-06-20 20:07:44
197
原创 计算机网络——七层模型与四层模型
想要使计算机之间能够互相通信，需要解决很多问题，诸如：如何保证数据链路的通畅，如何确定目标计算机的状态，如何识别目标计算机，错误数据如何勘测。计算机网络分层就是把这些问题进行分类，不同的层实现不同的功能，类似于将问题解耦，建立的一个国际范围的网络体系结构标准。
2023-06-20 17:14:46
227
原创 79.如何进行安全测试？
常用方法：1.sql注入；2.xss脚本攻击；注入：sql注入，命令注入，文件注入。越权：越过更高权限，越过同级权限。业务流程安全探索：人工检测。白盒代码分析：自动化。黑盒扫描机制：自动化。
2023-06-17 23:09:46
85
原创 78.你们的开发语言是什么？
java后台开发：SSM springboot。前端：JavaScript+css+html。python开发：Django flask。
2023-06-17 19:18:23
79
原创 77.开发是如何将项目转到测试的
一般开发完成后会进行邮件通知，并将新的代码地址，修改后的sql文件，需求开发完成的情况通知到测试 测试人员收到最新代码及sql文件后更新到测试环境中，进行冒烟测试，冒烟测试不通过则转测失败
2023-06-17 19:15:06
225
原创 76.项目同时上线，你怎么处理？
首先确定，几个项目是否可以同步上线完成 如果项目不是同时上线，确认项目的优先级，和产品沟通优先级较低的项目推迟上线
2023-06-17 19:12:14
78
原创 75.功能测试中重复测试很多，你怎么看待这个问题？
对于测试来说，需要有良好的耐心，一些必要的重复还是要去执行 另外，重复的事情可以进行自动化测试来替代
2023-06-17 19:10:07
213
原创 74.兼容性测试怎么测？web和app
app:不同手机厂商，型号，系统版本，内存大小，分辨率，屏幕大小，高端机与低端机，平板。web:不同的浏览器，IE，谷歌，火狐，浏览器显示比例，浏览器前进，后退，刷新按钮。
2023-06-17 19:08:23
113
原创 73.什么是多分支开发和单分支开发？
使用git工具或者svn工具，将每个版本或者模块进行划分，不同的开发负责不同的模块，完成后进行分支合并，把所有功能全部整合起来。
2023-06-17 19:06:20
275
原创 72.上线后有没有另外的测试用例在生产环境中测试？
没有：我们会挑选原来的测试用例中，级别较高的用例去执行，或者建立一个check list 去检查功能是否能正常使用。有：我们会去单独编写测试用例，只包括主体流程和新增功能的用例。
2023-06-17 19:02:21
128
原创 71.测试过程中，发现很多用例重复，有人认为没必要再测，你怎么看？
如果是同一模块的重复用例，我们可以考虑不再进行重复测试；如果是不同模块，引用相同的测试用例，还是有必要进行重复测试的。
2023-06-17 18:53:19
218
原创 68.怎么保证测试质量或者你怎么保证100%覆盖了需求？
首先就是要把需求了解透彻，用例编写完成后进行用例评审，编写用例的时候用边界值，等价类补充用例，根据经验用错误推断法来追加一些用例，如果存在组合情况的话，使用因果图或者判断表来编写，如果业务场景清晰的情况下用流程分析法，如果状态有发生改变的话用状态迁移法。编写用例是一个极其考研耐心的事情，要考虑到各种场景，全面覆盖到会出现的场景。
2023-06-17 18:46:26
257
原创 67.测试中有哪些风险
测试用例编写的时候，对需求的理解有偏差 测试人员水平不够，测试覆盖点不够全面 测试人员时间不够，导致测试不完全 测试环境不足，导致测试点不能完全的测试完成
2023-06-17 11:16:12
141
原创 65.回归测试的策略
功能的回归：优先测试用例级别较高的功能模块，可以进行自动化测试，如果时间够的话可以进行全量测试 Bug的回归：复测这个Bug，并且相关联的模块与功能也会复测一边，以免由于修改Bug导致其他问题的产生
2023-06-17 11:00:59
115
原创 64.什么是冒烟测试？在什么时候进行冒烟测试？
冒烟测试一般在系统测试之前，对所有主体的业务功能，测试看是否存在严重Bug，如果存在严重Bug，表示冒烟测试不通过。
2023-06-17 10:57:05
326
原创 63.如何写好一个测试用例
当然我们在编写测试用例的时候，一定要步骤，场景清晰，尽量去覆盖所有的测试场景。能够发现Bug的用例就是一个好的测试用例。
2023-06-17 10:54:16
71
原创 61.有没有写过测试报告，具体包括哪些内容？
报告中的结果：根据测试用例的覆盖率，通过率，Bug数量汇总，Bug类型和级别的统计，阶段测试Bug统计，遗留Bug风险等数据，分析测试目标有没有达成，已发现的Bug对系统的影响，系统交付使用后可能面临的风险，以及可能的优化点。测试报告，其实就是把我们测试的整个过程情况，数据统计，做成报告，包括用例执行情况，测试了哪些模块，多少用例，自动化通过率，自动化怕跑了多少，是否全部通过，发现了多少Bug，Bug的情况，是否遗漏Bug，测试结论等等这些。测试报告的侧重点：Bug的统计和分析。
2023-06-17 10:49:55
175
原创 62.测试报告中测试的结论是什么？
Bug的情况，Bug级别，Bug分布情况（分布在哪些模块），Bug产生的原因（设计问题，需求问题，代码问题） 测试是否通过
2023-06-17 10:49:39
176
转载 59.为什么要写测试用例？
2、通过详细的用例设计反推是否有需求漏洞，提前发现需求细节问题；5、测试用例是测试的重要资产，便于测试内容回溯、测试工作交接；4、测试过程中用于判断测试进度，预知测试风险；1、理清测试细节，提高测试覆盖率，避免漏测；3、提前准备测试数据，便于测试过程高效执行；
2023-06-16 15:32:13
196
原创 57.你的测试数据是从哪里获得的？怎么获得？假如不告诉你，你怎么处理?
一般的测试数据是由测试人员自己造的 如果数据量很大，则可以找运维人员从生产环境中导出相关数据，导出的数据需要屏蔽隐私信息 或者自己用程序生成大量的测试数据
2023-06-16 15:29:32
307
原创 55.如何保证测试质量
需求要吃透，不理解的地方要多问，多去了解 严格按照测试流程去执行，多考虑用户测试场景，对测试用例进行评审 要有良好的测试执行，要求用例执行率达到100%，多轮测试，进行探索性测试，必要时测试之间进行交叉测试，用测试工具来管理测试工作 不断反思和提升
2023-06-16 15:12:05
85
原创 54.项目上线后发现Bug，测试人员应该如何处理？
主要看Bug的严重级别，如果非常致命则需要赶快找项目经理或者产品商量紧急变更上线，如果不是很严重的错误，则修复好之后和下一个版本一起上线，上线后发现的Bug，如果不能确定其严重程度，还是要及时反馈给产品或者项目经理知道。
2023-06-16 15:09:58
189
原创 52.Bug的级别有哪些，级别如何判断
对业务有至关重要的影响，业务系统完全丧失业务功能，无法再继续进行，或业务系统丢失了业务数据且无法恢复，影响公司运营的重要业务数据出错。对业务有较小的影响，业务系统丧失了较少的业务功能。不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷。对业务有严重的影响，业务系统已经丧失部分重要的业务功能，或业务系统丢失了业务数据且可以恢复，一般业务数据出错。程序在显示上有些不美观或不符合用户习惯以及一些文字性错误。可以提高产品质量的建议，包括新需求和对需求的改进。
2023-06-16 14:59:46
147
原创 48.提交Bug包含哪些内容？
所属产品，所属项目，所属模块，影响版本，指派人员，截至日期，严重程度，优先级，Bug类型，Bug标题，重现步骤，附件。
2023-06-16 14:27:04
340
原创 47.Bug怎么管理的，Bug的生命周期或者Bug的状态
提交——开发人员（已激活未确认）——开发进行确认，状态变为已激活已确认——开发修复完成标注状态为已修复——测试人员复测通过——已关闭——不通过时返回给开发状态重新激活。提交Bug指派给对应的开发，开发进行修复，修复完成后，交给测试复测，复测成功后关闭Bug，不通过则返回给对应的开发。使用禅道来进行缺陷管理。
2023-06-16 14:10:20
230
原创 46.提交Bug时需要注意哪些问题？
不要着急提交，首先要确认Bug，是否是操作错误等导致的，或者和开发说明情况，定位分析后确认是前端还是后端的问题后再提交 简单明了的概括Bug标题，清晰的描述Bug重现步骤，分析Bug和预期正确结果，附加Bug的截图或者日志 在不能确认某种情况下是否为Bug的时候，请教其他人，找产品确认 提交完Bug以后，后面还要跟踪Bug的修复情况，及时进行复测及回归测试
2023-06-16 11:56:42
145
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人