微网站站点名称,网站开发模块,设计网站推荐知乎,除了小红书还有什么推广平台文章目录 2.6 初识一、软件测试理论二、软件的生产过程三、软件测试概述四、软件测试目的五、软件开发与软件测试的区别#xff1f;六、学习内容 2.7 理解一、软件测试的定义二、软件测试的生命周期三、软件测试的原则四、软件测试分类五、软件的开发与测试模型1.软件开发模型… 文章目录 2.6 初识一、软件测试理论二、软件的生产过程三、软件测试概述四、软件测试目的五、软件开发与软件测试的区别六、学习内容 2.7 理解一、软件测试的定义二、软件测试的生命周期三、软件测试的原则四、软件测试分类五、软件的开发与测试模型1.软件开发模型2.测试模型1V模型2W模型 六、B/S与C/S架构1.测试考虑2.B/S与C/S架构的区别 七、软件质量模型面试问题 2.8一、测试用例二、测试用例编写格式要素三、缺陷1.缺陷定义2.缺陷判定标准3.缺陷的跟踪流程缺陷的生命周期4.缺陷的核心内容5.缺陷的严重程度6.修复缺陷的优先级7.提交缺陷注意事项8.编写缺陷规范9.缺陷修改补充说明10.缺陷密度计算 面试问题 2.6 初识
一、软件测试理论 二、软件的生产过程 客户需求产生—产品经理需求文档----UI设计师设计效果图—研发工程师研发产品----测试工程师检测软件—部署上线
三、软件测试概述
什么是软件测试
利用技术手段验证软件的是否有问题
四、软件测试目的
降低企业风险提高用户体验
提高软件的质量保证软件的安全降低软件开发成本
降低因软件缺陷带来的商业风险
树立用户对软件的信心。
五、软件开发与软件测试的区别
软件开发开发人员写代码
软件测试使用测试软件进行测试
六、学习内容
功能测试功能测试接口测试自动化测试性能测试车载测试
趋势两会
学习建议模仿思考
主动学习教会同桌
及时复习
晚自习1.自我感谢介绍祝福2.家乡美
2.7 理解
软件测试的工作流程
扩展公司人员小公司
例如xxx科技有限公司
老板【1】
产品经理业务员【3】
研发人员开发软件的(ui前端后端)【20】
测试人员检查软件【3】
运维人员维护软件的【2】
研发/测试1:8
前台财务人事
一、软件测试的定义
通过手工或者测试工具按照测试方案和流程对被测对象进行功能或性能的检测。从而验证实际结果与预期结果之间是否存在差异。 测试对象软件的主体功能使用说明书配置数据
二、软件测试的生命周期
软件的生命周期从无到有再从有到无的过程
阶段从小到大 需求分析—测试计划—测试设计—测试执行—测试评估 三、软件测试的原则 原则是每个人在行事中所遵循的准则 测试只能证明软件存在问题不能证明不存在问题 测试工作要尽早的介入降低修复成本 不能进行穷尽测试要进行分类测试 缺陷存在集群现象通常大部分BUG发生在一下小部分核心模块中好测试的环境 杀虫剂现象尽量多的测试手段以便发生更多的BUG 测试依赖环境对软件开展测试前应先准备好测试的环境 不存在缺陷是谬论
四、软件测试分类
按软件产生的阶段划分
单元测试集成测试系统测试验收测试(αβγUAT)
单元测试白盒函数类黑盒窗口菜单按钮
集成测试模块与模块之间的测试
系统测试对软件整体功能性能等进行全面测试
验收测试α.内测β.公测γ.候选版本UAT用户测试
按代码可见度划分
黑盒测试看不见内部灰盒测试可见内容有限白盒测试完全能看见 按是否运行划分
静态测试指不实际运行被测软件而只是静态的检查程序代码、界面或文档中可能存在的错误过程。
动态测试指实际运行被测程序输入相应的测试数据检查实际输出结果和预期结果是否相符的过程。
按测试手段划分
人工测试自动化测试
其他测试
冒烟测试回归测试随机测试
冒烟测试对核心功能按照全部正确的数据或者流程对系统进行最基本功能的测试保证软件最基本的功能和流程能走通。
回归测试对已修复BUG再次测试软件版本更新/迭代后对老版本的内容再次测试。
随机测试1.挑选之前发生严重BUG的地方 2.挑选之前漏测的地方 3.挑核心模块主业务和关于钱的
五、软件的开发与测试模型
1.软件开发模型
瀑布模型 需求分析—设计—编码—实现—软件测试—完成—维护瀑布模型特点瀑布模型是一种线性的
瀑布模型的优缺点
优点开发的各个阶段比较清晰当前阶段完成后只需关注后续阶段强调早期的计划与需求调研适合需求稳定的产品。缺点不适应需求的化依赖早期的需求调研风险延至后期才暴露失去了及早纠正的机会。改良在前期一些重要的阶段之间加入了迭代的思想尽量避免把风险拖至后期。
2.测试模型
1V模型 需求分析—概要设计—详细设计—编码—单元测试—集成测试—系统测试—验收测试
优点开发的各个阶段比较清晰当前阶段完成后只需关注后续阶段强调早期的计划与需求调研适合需求稳定的产品。缺点不适应需求的化依赖早期的需求调研风险延至后期才暴露失去了及早纠正的机会。改良在前期一些重要的阶段之间加入了迭代的思想尽量避免把风险拖至后期。
2W模型
开发模型与测试模型合在一起 六、B/S与C/S架构
1.测试考虑
B/S架构浏览器与服务器
测试考虑网站在各种了浏览器能打开
C/S架构客户端与服务器
测试考虑软件在各种手机上都能安装使用
2.B/S与C/S架构的区别
B/S比C/S架构成本低升级便利但是C/S架构更安全更效率
七、软件质量模型
ISO国际标准 例如何验证某系统质量呢以微信为例
功能性与需求数量一致功能正确性能响应快、占用资源少兼容性不同设备平台正常使用易用性用户体验好安全性敏感信息无泄密存储有保障可靠性持久运行无异常可移植性升级迁移数据不丢失可维护性异常恢复简单、可扩展功能、升级更新便捷。
面试问题 你们公司的测试流程能说一下吗 你们公司的验收测试是怎么做的 三选一1.去甲方 2.甲方来 3.第三方 你能说一下黑盒测试和白盒测试的区别吗 黑盒测试重点关注软件的功能以及性能是否满足需求 白盒测试重点关注代码以及逻辑是否正确 你们软件多久迭代一次迭代后回归测试做多久 迭代大版本2、3个月迭代一次小版本1、2周迭代一次 回归测试大版本十几天小版本几天。
2.8
一、测试用例
什么是测试用例
测试用例test case是为测试项目而设计的执行文档
作用防止漏测重复测试实施测试的标准以便更好的开展测试工作。
二、测试用例编写格式要素
通常用Excel文档编写要素由以下八个要素组成
用例编号、用例标题、测试模块、优先级、前置条件、测试步骤、测试数据、预期结果。
用例编号通常由项目_模块_编号组成
用例标题预期结果测试点
测试模块所属项目或模块/子模块。
优先级表示用例的重要程度或影响力由高至低依次为1、2、3、4也有称P0、P1、P2、P3
前置条件要执行此条用例有哪些前置操作
测试步骤描述操作的步骤
测试数据操作软件需要的数据没有可以不填
预期结果期望达到的结果唯一性。 三、缺陷
1.缺陷定义
软件在使用过程中存在的任何问题都叫软件缺陷简称Bug。
软件缺陷的存在会导致软件产品在某种程度上不能满足用户需求。
2.缺陷判定标准
少功能软件未实现需求说明书中明确要求的功能。
多功能软件实现的功能超出了需求说明书指明的范围。
功能错误软件出现了需求说明书中指明不应该出现的错误。
隐形功能错误软件未实现需求说明书中虽未明确指明但应实现的要求。
不易使用软件难以理解不易使用运行缓慢用户体验不好。隐形功能错误和不易使用尽量不提
3.缺陷的跟踪流程缺陷的生命周期 口述
我提交BUG通知开发人员开发人员会先判断这个BUG是否重复如果重复则关闭这个缺陷如果不重复则判断这个缺陷是否是个BUG确认这个是BUG后与开发项目经理等项目相关人员进行商讨是直接修复还是推迟处理如果推迟处理确认推迟处理的版本和日期如果不能直接则立即修复修复之后由我进行再次测试如果测试通过则关闭这个BUG如果测试没有通过则重新提交BUG由开发人员再次判断。
4.缺陷的核心内容
缺陷标题缺陷的预置条件缺陷的复现步骤缺陷的预期结果缺陷的实际结果缺陷的严重程度修复缺陷的优先级缺陷的附件。 5.缺陷的严重程度
通常指缺陷对软件质量的破坏程度即此缺陷的存在将对软件的功能和性能产生怎样的影响。
共分为4级由高至低依次为1、2、3、4P0、P1、P2、P3。 1级P0致命死机非法退出死循环数据库发生死锁。 如软件死机意外退出操作系统崩溃。 2级P1严重功能不符严重计算错误接口数据错误等。 如主要功能失效或未实现。 3级P2一般界面或内容错误异常操作未给出提示等。 如非主要功能失效或未实现。 4级P3轻微格式不规范提示窗口文字未采用行业术语等。 如某个控件没有对齐某个标点符号丢失等。 5级P4建议型如果有
6.修复缺陷的优先级
表示处理和修正软件缺陷的先后顺序。即哪些缺陷需要优先修正哪些缺陷可以稍后修正。
共分为4级由高至低依次为1、2、3、4P0、P1、P2、P3。
1级P0紧急立即修复。如1天内修复。2级P1高级几天内修复。如一周内修复。3级P2中级上线前修复。如此版本上线前修复。4级P3低级时间允许时再修复。如在不影响软件主要功能使用的前提下可考虑在后续版本修复。
一般而言严重程度高的缺陷修复的优先级也高。但我们还需要注意有些BUG严重程度低修复的优先级不一定低。 7.提交缺陷注意事项 8.编写缺陷规范 9.缺陷修改补充说明
并不是所有缺陷都要修复考虑性价比和时间有时市场的压力使得产品最终发行有时间限制或者测试人员错误理解或者不正确操作引出的缺陷错误的修改影响的模块较多带来的风险较大(遗留)修改性价比太低缺陷报告中提出的问题很难重现等等这些原因导致的缺陷会视情况而定。
为什么开发人员会拒绝修改缺陷
程序员无法重现或者现象难以捕捉
没有明确的报告以说明重现缺陷的步骤
程序员无法读懂的缺陷报告
用户很少使用或者不符合用户使用习惯的操作出错
由不受信任的测试人员提出。
10.缺陷密度计算
进行缺陷密度计算可有效的进行软件管理。目前行业标准是每一千行代码中存在5个以上Bug。
缺陷总数÷代码行数×1000‰ 缺陷密度/KLOC
如一个1万行的源程序代码里发现了68个缺陷
则缺陷密度为6.8/KLOC
计算方式68÷10000×1000‰6.8‰
小结
1、如何描述软件的生命周期
2、如何描述软件测试的生命周期
3、软件测试的工作流程是什么
4、软件测试的定义是什么
5、软件测试的对象是什么
6、软件测试的目的是什么
7、软件测试的原则是什么
8、软件测试分为哪些类
9、瀑布模型是什么如何改良
10、V模型与W模型是什么V模型如何改良
11、B/S架构与C/S架构有什么区别
12、软件测试的质量标准特性是什么
13、测试用例的要素有哪些
14、测试用例的作用是什么
15、什么是缺陷
16、发现Bug后你是怎么确认的
17、缺陷的要素Bug单有哪些
18、缺陷的严重程度以及修复缺陷的优先级怎么划分
19、缺陷的处理流程生命周期
20、你提交的缺陷开发不认可你怎么办
21、如何提交一条高质量的Bug
面试问题
1、你提交的BUG开发认为不是个BUG你会怎么做你提交的缺陷开发不认可你怎么办
首先我会看下开发是在什么情况下认为它不是个BUG其次我会跟开发核对下需求文档看是否理解有异角度不同
若开发还是不认可我会再次把BUG的重现步骤以及相关的截图以及运行日志一并发给开发验证
实在解决不了我会向经理报风险通常会在周五下午的周总结会上提出并解决若比较紧急会立即开会解决。
2、测试用例的要素有哪些
用例编号、用例标题、测试模块、优先级、前置条件、测试步骤、测试数据、预期结果。
3、发现Bug后你是怎么确认的
发现异常情况后初步判断是否可能是Bug。我会检查是否是由于测试环境、数据等外部因素导致的异常。
复现问题尝试按照相同的步骤重现问题确保问题的可复现性。如果问题无法复现我会记录下来并继续观察看是否能在其他条件下复现。排除干扰因素检查是否是由于测试环境、数据等外部因素导致的异常。例如检查网络连接是否正常、数据库是否正确初始化等。确认问题如果能够稳定复现且排除了外部因素干扰基本可以确认为Bug。我会详细记录问题的重现步骤、截图、日志等信息以便开发人员快速定位问题。
发现BUG我会先检查是不是环境的问题然后复现BUG
4、缺陷的要素Bug单有哪些
缺陷编号、缺陷标题、缺陷描述、缺陷级别、优先级、所属模块、与缺陷相关的具体需求或功能点、状态缺陷的当前状态如新建、已确认、已修复、已关闭等。
5、缺陷的严重程度以及修复缺陷的优先级怎么划分
6、缺陷的处理流程生命周期
7、如何提交一条高质量的Bug
确认复现附件截图视频等
自己先确认这是BUG 然后复现这个BUG把这个BUG的复现过程写清楚
注意事项1.一个BUG一个单 2.填写BUG单要简明提要
8、你一天能写多少条用例
9、你一天能执行多少条用例
10、如果时间紧急没时间写用例你怎么开展工作
11、你一天能找几个BUG
