软件测试工程师常见问题总结 |
您所在的位置：网站首页 › 软件测试遇到问题怎么解决 › 软件测试工程师常见问题总结 |
软件测试工程师常见问题总结
|
写在前面：有幸看到该篇https://blog.csdn.net/zimingzim/article/details/79996767博客，里面的一些问题觉得概括的很广，特意记录，其中的一些回答包括自己的理解，同时也借鉴该篇博文的优秀回答，也会同步一些问题，共勉。 1、为什么要在一个团队中开展软件测试工作？ 没有经过测试的产品很难把控产品的质量，测试作为产品上线之前的最后一道工序，对产品的质量起到重要的作用，只有经过测试的产品才能对该产品有一个精准的风险把控。 2、测试能给你带来什么样的快乐？ 当我测试出产品的缺陷的时候，我会很快乐，觉得自己可以查找到隐藏的缺陷并让开发人员修复，降低了产品上线的质量风险；当我没有测试出产品缺陷的时候，我会很快乐，因为团队的编码能力很棒。 3、软件测试的目的？ 测试的目的是以最少的人、财、时间找到产品隐藏的缺陷，并及时进行修改，提高产品的质量，同时降低产品上线之后因缺陷引发的商业损失。 4、Alpha测试与Beta测试的区别 大型通用软件在发布之前，都会进行Alpha和beta测试，目的是从实际终端用户的角度去发现可能在真实用户使用过程中会出现的缺陷。 Alpha测试一般指一个用户在开发环境模拟真实用户操作或内部员工在模拟真实环境下的操作，开发人员在现场，可实时将问题同步给开发人员，一般不由程序员和测试人员操作。α测试可以从产品编码结束之时开始，或模块测试完成之后开始，或在确认测试过程中产品达到一定的稳定性和可靠性开始，Alpha测试为非正式验收测试。 Beta测试一般存在于α测试之后，β测试一般由真实用户在真实环境下进行的测试，开发者一般不在现场，由用户总结缺陷，并定期向开发者汇报。 α代表软件测试的第一个版本（软件开发初期的版本，初具规模），beta代表软件测试的第二个版本。(网上所提供的一些软件测试版本) 5、简述集成测试的过程 完成单元测试/完成模块化测试----->组装模块------->集成测试 6、质量的八大特性是什么？各种特性的定义？ 1.功能性：软件所实现的功能与需求一致； 2.使用性：用户在使用、操作软件的难易程度； 3.可靠性：在满足一定条件下，软件可以提供正常功能，出现错误的时候，可以友好兼容，如软件闪退或重启，可以正常使用； 4.移植性：软件切换平台之后数据可以保持一致，且软件正常使用 5.维护性：软件在维护过程中出现故障，软件系统是否具备可分析性和处理性，重新设计后的软件的稳定性 6.重用性：整个软件或者某一模块可作为软件包使用 7.性能：在规定条件下，实现软件功能所需的响应时间和计算机资源(CPU、内存、磁盘空间和数据吞吐量)的使用程度 8.安全性：使用软件过程中的网络、数据安全，不会被窃取或泄露7、系统测试计划是否需要同行审批，为什么？ 是，系统测试计划属于项目开发过程的关键性文档。 8、软件质量应该从哪些方面来评价？ 功能、性能、外观、安全、易用性、稳定性等 9、系统测试包含哪些方面？ 性能测试、安全测试、文档测试、备份测试、功能测试 10、测试结束的标准是什么？ 1.用例全部执行；2.bug全部修复；3.覆盖率、单元测试等达到符合标准 11、制定测试计划之前需要了解什么问题？ 1.测试的是什么产品？新产品还是迭代开发？需求是什么？2.测试的资源安排，人、财、物3.完成测试的标准是什么？12、请详述设计测试用例的方法？ （只是列出一个测试用例思考的方向，具体设计靠经验） ①黑盒测试一般根据需求文档进行测试用例的编写，一般使用到：等价类划分、边界值分析、因果图、错误推测法等 ②白盒测试关注内部代码结构分为静态测试和动态测试： 静态测试：通过静态的检查代码程序/界面/文档存在的问题（代码编写的规范性、测试界面、文档是否编辑正确和完 整）；动态测试：通过路径和分支测试（语句覆盖、条件覆盖、分支覆盖、路径覆盖等）13、比较负载测试，压力测试，容量测试、强度测试的区别 负载测试：检查系统处理大量用户的请求或事物的能力，负载测试属于一种性能测试，指数据在超负荷的情况下，程序是否能承担。压力测试：检测系统在恶劣环境下的运行情况，如内存不足、网络差、CPU高负荷的情况，用来评估在超越最大负载的情况 下系统将如何运行，考验系统在正常的情况下对某种负载强度的承受能力 。压力测试就是一种破坏性的测试，用以判断系统的稳定性和可靠性。一般把压力描述为“CPU使用率达到75%以上，内存使用率达到70%以上”。 容量测试：是面向数据的，检测系统处理大数据量的能力，目的是为了证明程序不能处理目标文档中规定的数据容量。强度测试：使程序承受高负载或强度的检验。14、C/S与B/S结构的软件，应该采取什么样的方法分别测试？他们存在什么样的区别与联系？ C/S：客户端/服务器，C负责呈现界面，响应交互，与S通讯，客户端由开发者针对系统特性开发，因为客户端本身就与服务器通讯，所以可以修改通讯方式。如我们手机上的app就属于C/S架构 B/S：浏览器/服务器，浏览器充当跟服务器通讯的一个容器，这个容器里面包含html/css/jquery等，就是俗称的网页，B/S 模式的软件开发一般被称为WEB开发 测试点：C/S主要测试点在C（客户端），安装测试、升级测试、功能测试、稳定性测试、服务器端数据测试B/S多为网页，常见的有界面外观测试、功能测试、数据校验等 区别与联系：区别有C/S变动需要客户端的升级操作，即升级权限在用户手中，B/S模式的软件服务器端可直接进行升级， 用户不需要做任何操作，基于C/S架构的软件，可以调用系统级的api，而B/S架构的软件只能调用浏览器开放的api。联系是都需要与S（服务端）通讯。测试方面也存在很多相同的测试点。14、原生APP与H5的区别？ 1.开发方面：原生APP针对不同的系统（安卓、iOS）采用不同的开发语言（Android-java、iOS-Object-c）引用不同的开发 包，需要行成独立的项目，H5采用统一开发语言，一个项目即可。 2.能力方面：原生app可以调用硬件设备的底层功能，如个人信息、摄像头、重力感应等，H5只能调用硬件设备的少量功能 。 3.版本控制：原生app只能将新版本的app放到应用市场上去，是否升级版本的控制权在用户手中，H5可以直接在服务器端 做升级，用户不需要做任何操作，这样就导致原生app存在多个版本，而H5则统一版本。 4.使用方式： 原生app需要下载安装包安装之后才可使用，H5依赖手机浏览器。15、mysql的3种删除语句 一：用法和区别 drop：drop table 表名 删除内容和定义，并释放空间。执行drop语句，将使此表的结构一起删除。 truncate (清空表中的数据)：truncate table 表名 删除内容、释放空间，但保留表的数据结构。 truncate不能删除行数据，虽然只删除数据，但是比delete彻底，它只删除表数据。 delete：delete from 表名 （where 列名 = 值） 与truncate类似，delete也只删除内容、释放空间但不删除定义；但是delete即可以对行数据进行删除，也可以对整表数据进行删除。 二：注意 1.delete语句执行删除的过程是每次从表中删除一行，并且同时将该行的删除操作作为事务记录在日志中保存，以便进行进行回滚操作。 2.执行速度一般来说：drop>truncate>delete 3.delete语句是数据库操作语言(dml)，这个操作会放到 rollback segement 中，事务提交之后才生效；如果有相应的 trigger，执行的时候将被触发。 4.truncate、drop 是数据库定义语言(ddl)，操作立即生效，原数据不放到 rollback segment 中，不能回滚，操作不触发trigger。 5.truncate语句执行以后，id标识列还是按顺序排列，保持连续；而delete语句执行后，ID标识列不连续 16、Jmeter控制执行顺序 控制线程组执行顺序，可在测试计划界面勾选‘独立运行每个线程组’ 17、postman将请求A结果中的某一值作为B请求的参数 https://blog.csdn.net/lemon_linaa/article/details/95531691 18、Java实现数组数字排序 https://blog.csdn.net/lemon_linaa/article/details/95537762 19、软件的缺陷等级应如何划分？ 致命：由于程序引起的死机、非正常退出；死循环；数据库数据丢失；数据库连接错误；由于错误操作引起的程序中断；主要功能错误；数据通讯错误等。严重：程序错误；接口错误；系统主要功能部分缺失；功能实现与需求严重不符；模块无法启动或调用；安全、稳定性等。一般：功能没有完全实现但不影响正常使用。建议：界面展示；描述用语；用户体验等。20、你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 如果真的不是bug，承认错误；如果是需求描述不清引起的理解错误，则积极与相关人员沟通确认；如果双方争执不下，咨询上级领导处理。 21、您认为做好测试计划工作的关键是什么？ 熟悉测试的产品和需求明确测试的目标，需要达到什么样的测试效果采用评审和更新机制，保证测试计划满足实际需求分别创建测试计划、测试用例、测试报告等相关测试文档22、你认为软件测试过程中较常见的困难是什么？如何有效克服这些困难？ bug复现：某些bug属于偶然复现，如果是属于轻微级别的bug，还好，如果是属于严重级别的bug，还不容易复现的情况，会带来很大的影响，一个是截屏记录，清楚描述出现步骤，二个是根据偶现bug的级别来判断是否需要多次测试，一定要解决该bug，如实在无法复现，需要进行记录。bug的修复引发其他bug：开发者在修复bug的时候可能会不小心引起其他模块的bug，所以在验证bug的时候需要将相关联的模块也进行测试。需求不明确引起的理解误差：由于需求文档描述不明确，会导致开发者和测试者的理解不同，需要积极和相关人员进行沟通23、集成测试通常都有那些策略？ 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；各个子功能组合起来，能否达到预期要求的父功能；一个模块的功能是否会对另一个模块的功能产生不利的影响；全局数据结构是否有问题；单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。 |
【本文地址】
今日新闻 |
点击排行 |
|
推荐新闻 |
图片新闻 |
|
专题文章 |