偶觉得很准的测试~~

最新推荐文章于 2024-07-16 21:54:33 发布

原创最新推荐文章于 2024-07-16 21:54:33 发布 · 905 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#测试 #工作

博客讲述了四个女人P、M、L、F爱男人W，W为见F经过P家并答应陪住一晚，后自觉配不上F，L不接受他，F原谅他并结婚。通过对五个人喜欢顺序的选择，可反映对工作、家庭、爱情、金钱、性爱的态度。

有四个女人分别叫P、 M、 L、 F

同时爱着一个叫W的男人，但是W只爱F一个人，W想去F家，但是必须经过M或 P的家.

W去了M家,M说：“我得不到的东西，别人也别想得到。”
又去了P家，P说：“你想从我家经过，也可以，但是你要在这里陪我住一个晚上，否则，你永远也过不去，你永远也见不到F。” 没办法,W只好答应。

第二天早上，W通过了P家，但是经过一夜的事，他觉得自己已经配不上 F了，于是他就去了 L 家，告诉 L昨晚的事情，问 L 是否可以接受自己，L说：“爱情是纯洁的，虽然我爱你，但是你已经做过那样的事，我不能接受你了。”

没办法，W最后到了 F家，告诉她发生的事情，问她是否能原谅自己。F
说：“虽然你做了那样的事，但是你是为了见到我才迫不得已做的，我原谅你，依然爱你。”他们结婚了。

问题是：这五个人你最喜欢哪一个？请按喜欢的顺序依次排列

答案在下面,慢点往下拉~~

W----工作. F----家庭 L----爱情 M---金钱 P---性爱

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

Qblog

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
2
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

什么是软件测试？软件测试全程是什么

qishuzdh的博客

08-22

544

今天笔者先给大家来详细的说说软件测试流程（全程的哟），有些小伙伴对于软件测试都是一知半解的状态希望大家看完这篇文章能够更好的了解到软件测试。随着软件测试技术的发展，测试工作由原来单一的寻找缺陷逐渐发展成为预防缺陷，探索测试，破坏程序的过程，测试活动贯穿于整个软件生命周期中，故称为全程软件测试全程软件测试，强调整个软件生命周期中，各阶段的测试活动。无论是需求阶段，开发阶段，还是测试阶段，都需要确定在当前阶段测试活动的内容以及成都，确保每个阶段的质量，才能保证产品最终的质量。

软件测试常见面试题及答案

阿里大叔说测试的博客

05-23

1209

2 条评论您还未登录，请先登录后发表或查看评论

opencv_extra/testdata/dnn/download_models.py

热门推荐

好习惯成就伟大

04-10

4万+

#!/usr/bin/env python from __future__ import print_function import hashlib import sys import tarfile if sys.version_info[0] < 3: from urllib2 import urlopen else: from urllib.request impor...

ubuntu 16.0.4 安装 cmake 3.17.2

qq_33228039的博客

04-30

2万+

参考：https://blog.csdn.net/king_700/article/details/105752062 0.如果系统有cmake，版本过低，先卸载 sudo apt remove cmake 1.先在官网（https://cmake.org/download/）下载cmake源代码cmake-3.17.2.tar.gz，注意是linux版的，别下错了 2.解压 ...

Tar打包、压缩与解压缩到指定目录的方法

weixin_30697239的博客

05-18

4504

tar在linux上是常用的打包、压缩、加压缩工具，他的参数很多，折里仅仅列举常用的压缩与解压缩参数参数： -c ：create 建立压缩档案的参数； -x ：解压缩压缩档案的参数； -z ：是否需要用gzip压缩； -v：压缩的过程中显示档案； -f：置顶文档名，在f后面立即接文件名，不能再加参数举例：一，将整个/home/www/images 目录下的文件全部打包为...

Docker常用命令总结

出发之前永远是梦想，上路之后永远是挑战。

04-10

1万+

容器生命周期管理 run start/stop/restart docker start：启动一个或则多个已经被停止的容器 docker stop：停止一个运行的容器 docker restart：重启容器 kill docker kill [OPTIONS] CONTAINER [CONTAINER...] [OPTIONS]： s :向容器发送一个信号 [root@localhost ~]# docker run --rm -it centos bash & [1] 78366 [root

软件测试做了五年黑盒测试，我总结的这些经验

测试人，要卷就卷成最强的！

10-21

907

黑盒测试：是在已知产品所具有的功能的前提下，通过测试来检测每个功能是否能够正常使用。在测试时，把程序看作一个不能打开的黑盒子。在完全不考虑程序的内部结构和内部特性的情况下，在程序接口进行测试，只检查程序功能是否按照需求规格说明书的规定正常工作、程序是否能适当地接受输入数据而产生正确的输出信息，并保持外部信息（如数据库文件）的完整性。

2022大厂高频软件测试面试真题（附答案）

与君初相识，犹如故人归

06-08

9858

接口测试实际跟一般测试不同就是测试用例的设计部分。获取接口规范。设计接口测试功能用例（主要从用户角度出发看接口能否实现业务需求，用例设计就是黑盒用例那一套）。各种入参验证（正常情况，异常情况包括输入参数个数不对，类型不对，可选/必选，还有考虑参数有互斥或关联的情况）。接口返回值各种验证（符合接口文档需求）了解接口实现逻辑，实现逻辑覆盖（语句/条件/分支/判定/…）接口能并发执行吗、安全吗，性能满足要求吗?采用工具或者自写代码来验证。发现问题跟功能测试一样，该报bug报bug，该跟踪状态的跟踪状态postma

软件测试面试题整理(三)之工作/项目流程篇

2301_80119579的博客

07-16

789

2、还有一个就是在借款流程中，我们通过修改数据库中的数据，把借款时间修改了，制造出一个逾期未还款的数据，结果显示还款的金额比借款金额还少，而且管理费收得特别高，存在不合理性。，我们就用insert into输入数据或（者 update set 修改数据），我们需要到数据库查看有没有相关记录保存，保存的数据跟我们输入或者修改的记录是否一致；3、还有一个是在产品上线后，运维人员在统计数据时发现少了一条数据，我们去数据库检查发现0分0秒的数据没有统计，后来开发人员修改了代码之后就解决了。

cat4500e-universalk9.SPA.03.08.10.E.152-4.E10.tar

09-24

Description : CAT4500e SUP7-E/SUP7L-E Universal Crypto Image Release : 3.8.10E Release Date : 07-Apr-2020 FileName : cat4500e-universalk9.SPA.03.08.10.E.152-4.E10.tar Min Memory : DRAM 2048 Flash 1024 Size : 181.85 MB ( 190679040 bytes) MD5 Checksum : 3fe6accd33fbf5672c2fe71eb5382dda SHA512 Checksum

PyPI 官网下载 | accountifie-0.3.17.tar.gz

01-26

资源来自pypi官网。资源全名：accountifie-0.3.17.tar.gz

09-29

完整vs项目，包含项目完整配置文件，下载，即可编译出lib openssl.exe等非网上命令行 nmake编译一个解决方案，4个分项目 4各项目各个项目下有具体说明 libcrypto项目生成libcrypto.lib 第一个编译 libssl项目生成libssl 需要上面的生成的libcrypto.lib 这两个项目修改项目属性为静态链接库lib，生成静态库，项目属性改为动态链接库dll,添加def文件，就可以生成动态库 libapps项目生成libapps.lib openssl.exe需要，一直静态就可以 openssl项目生成openssl.exe 需要上面三个lib 首先openssl项目需要libcrypto与libssl项目生成的lib(不管是静态库还是动态库都有) 如果是静态lib,则生成的openssl.exe是独立的，较大如果是动态库会生成lib与dll两个文件，lib是编译链接时用，dll是运行时用，确保dll文件的名字与对应def文件中定义的dll文件名一致内含openssl-1.1.1y源码，已配置好，下载即可编译

linux-arm-legacy-b2af78846ad0fe2a0fb114bd3f55ef8d4eff4d7d.tar.gz

09-29

ARM的linux内核文件，这是3.14版本。基本用于gem5的全系统仿真

Python库 | home-assistant-frontend-20200917.0.tar.gz

04-09

资源分类：Python库所属语言：Python 资源全名：home-assistant-frontend-20200917.0.tar.gz 资源来源：官方安装方法：https://lanzao.blog.csdn.net/article/details/101784059

Linux中的常用命令指令（四万字零基础超全详解）

林二月的博客

06-06

9790

分析：我们执行一个指令的时候，这个指令可能会由文件读入数据，经过处理之后，再将数据输出到屏幕上。在上图当中， standard output 与 standard error output 分别代表“标准输出（STDOUT）”与“标准错误输出（STDERR）”，这两个数据默认都是输出到屏幕上面。本学期学习了Linux操作系统实践课程，最近临近期末，小白博主便做了一个Linux常用指令用法整理总结，可以方便自己在期末进行复习，也希望可以帮到需要的同学。

半小时带你熟悉Docker镜像的构建方式

weixin_49228079的博客

11-26

5798

目录摘要一、Docker镜像的分层二、Docker镜像的创建 2.1、Docker镜像 2.1.1、应用发布的标准格式 2.1.2、支撑一个Docker容器的运行 2.2、Docker镜像的创建方法 2.2.1、基于已有镜像创建 2.2.2、基于本地模板创建 2.2.3、基于Dockerfile创建 2.3、基于已有镜像创建 2.3.1、将容器里面运行的程序及运行环境打包生成新的镜像 2.3.2、操作步骤 2.4、基于本地模板创建 2.5、基于Dockerfile创.

精通 TensorFlow 1.x：11~15

龙哥盟

04-15

3983

原文：Mastering TensorFlow 1.x 协议：CC BY-NC-SA 4.0 译者：飞龙本文来自【ApacheCN 深度学习译文集】，采用译后编辑（MTPE）流程来尽可能提升效率。不要担心自己的形象，只关心如何实现目标。——《原则》，生活原则 2.3.c 十一、TF 服务：生产中的 TensorFlow 模型 TensorFlow 模型在开发环境中经过训练和验证。一旦发布，它们需要托管在某个地方，提供用工程师和软件工程师使用，以集成到各种应用中。 TensorFlow 为此提供了一

测试人员如何有效记录和报告BUG？

最新发布

06-30

<think>嗯，用户这次聚焦在如何规范记录和提交BUG报告上，正好接续上次讨论的"无法复现BUG"场景。从引用内容看，用户明显需要实操层面的具体指导，而非泛泛而谈。用户提供的三个引用很有价值：[^1]强调高质量BUG报告要素，[^2]补充了语言表达规范，[^3]则涉及跟踪流程。需要将这些分散的要点整合成体系化的操作指南。注意到用户特别要求"参考站内引用"，说明ta可能正在准备测试工作文档或面试。上次回复中关于"无法复现BUG"的步骤1（立即记录）其实已经涉及报告基础，这次要深化到日常所有BUG的报告规范。用户没提具体业务场景，所以需保持通用性，但可以暗示不同系统（如Web/APP）的特殊字段差异。核心矛盾在于：测试人员要平衡报告的完整性和效率。引用[^2]提到"避免复杂句型"很关键——很多新人会犯过度描述的毛病。应该用"模块化写作"的思路来化解：将报告拆解为标题、环境等必填字段，再配以自由描述的复现步骤。特别要注意引用[^3]隐含的团队协作视角。BUG报告本质是测试与开发的通信协议，需要包含"开发拒绝时如何论证"的预防性设计，比如截图证据的保存要求。这点在面试场景常被忽略。最后考虑加入风险控制维度。用户没问但实际需要的是：如何避免因报告不规范导致的BUG遗漏？可以在总结部分强调"报告即承诺"，每个字段都对应后续跟踪责任。</think>在软件测试中，规范地记录和提交BUG报告是保障缺陷高效处理的核心环节。以下是基于行业实践和引用资料的标准化操作流程，确保报告清晰、可追溯、可操作： --- ### **一、BUG报告的必备要素（结构化记录）** 根据引用[^1][^2]，高质量报告需包含以下核心字段： | **字段** | **规范要求** | **示例** | |-------------------|-----------------------------------------------------------------------------|------------------------------------------| | **标题** | 简明概括缺陷本质，包含模块+现象 | `[支付模块] 提交订单后支付状态未更新` | | **严重等级** | 按影响分级： • 致命（系统崩溃） • 严重（功能阻塞） • 一般（功能异常） • 建议（优化问题） | `严重` | | **优先级** | 按修复紧急性分级： • P0（立即修复） • P1（当前版本修复） • P2（后续版本修复） | `P1` | | **测试环境** | 精确描述环境变量： • 操作系统+版本 • 浏览器/APP版本 • 网络环境 • 测试数据 | `Windows 11, Chrome 115, 4G网络, 测试账号user_test` | | **复现步骤** | 分步骤描述操作路径，避免遗漏关键动作 | `1. 登录账号 2. 选择商品A加入购物车 3. 点击支付按钮` | | **实际结果** | 客观描述缺陷现象 | `支付成功提示弹出，但订单状态仍显示"待支付"` | | **预期结果** | 明确正确行为标准 | `订单状态应同步更新为"已支付"` | | **附件证据** | 必须提供： • 截图/录屏（标注问题点） • 日志文件（错误堆栈） • 控制台报错信息 | ![支付状态错误截图](url) | --- ### **二、提升报告质量的关键技巧** 1. **语言精准性** - 使用短句和短语，避免复杂修饰（如：“点击后**偶尔**出现空白页” → “**步骤3后页面概率性空白**”）[^2] - 禁用主观表述（如“我觉得”“可能”），改用客观事实（如“**控制台输出TypeError: undefined**”） 2. **复现路径优化** - 最小化复现步骤：删除无关操作，保留最简触发路径[^1] - 标注偶现条件：如“**连续操作5次后必现**”或“**仅在低网络带宽下出现**” 3. **附件使用规范** ```markdown ![缺陷截图描述](图片URL) • 截图需包含：URL地址、操作元素、错误提示 • 日志文件需标注错误时间戳（如：`[2024-07-20 14:25:32] ERROR PaymentService: Line 45`） ``` --- ### **三、团队协作与跟踪流程** 1. **提交后的沟通机制** - 若开发拒绝修复，需补充技术证据： - 提供相同环境下的复现录屏 - 引用需求文档条款（如：“**需求文档v1.2第5章规定支付状态需实时同步**”）[^3] - 争议时发起三方会议（测试+开发+产品经理） 2. **BUG状态跟踪** ```mermaid graph LR A[新建] --> B[开发修复] B --> C{测试验证} C -->|通过| D[关闭] C -->|不通过| B D -->|偶现缺陷| E[监控3个版本] E -->|未重现| F[注释后关闭] ``` - 对无法复现的BUG：标记“**暂无法复现**”，并在后续版本回归测试中监控[^3] --- ### **四、避免的常见错误** - **❌ 模糊描述**： “支付功能有问题” → **✅ 修正为**：“使用支付宝支付成功后，订单列表页金额显示为0” - **❌ 环境缺失**：未注明iOS版本 → **✅ 修正为**：“iOS 17.5.1, iPhone 15 Pro” - **❌ 步骤冗余**：包含登录、搜索等无关操作 → **✅ 修正为**：仅保留支付流程关键步骤 --- ### **五、总结：高质量报告的核心原则** 1. **完整性**：覆盖所有必备字段，提供完整证据链[^1] 2. **可复现**：开发人员可快速复现缺陷（提供测试账号/数据） 3. **可追溯**：通过标题和模块快速定位问题场景 4. **标准化**：遵循团队统一的缺陷管理模板 > 引用行业实践：“缺陷报告的目标是**用最少的信息量让开发快速定位问题**。测试人员需像法医一样客观记录现场，而非撰写小说。”[^2] ---