用wordpress建公司网站步骤,国家对网站建设有什么要求,2022网页游戏,网站年报公示怎么做#x1f345; 视频学习#xff1a;文末有免费的配套视频可观看 #x1f345; 关注公众号【互联网杂货铺】#xff0c;回复 1 #xff0c;免费获取软件测试全套资料#xff0c;资料在手#xff0c;涨薪更快 1、B/S架构和C/S架构区别
B/S 只需要有操作系统和浏览器就行 视频学习文末有免费的配套视频可观看 关注公众号【互联网杂货铺】回复 1 免费获取软件测试全套资料资料在手涨薪更快 1、B/S架构和C/S架构区别
B/S 只需要有操作系统和浏览器就行可以实现跨平台客户端零维护维护成本低但是个性化能力低响应速度较慢
C/S响应速度快安全性强一般应用于局域网中因为要针对不同的操作系统,需要针对性的开发,并且维护成本高
2、HTTP协议
http协议又叫做超文本传输协议在做网络请求的时候我们基本上是使用http协议。
http协议包括请求和响应。
请求中包括请求地址请求方式请求方式包括get请求和post请求get和post的区别是get请求是在地址栏后边跟随请求参数但是请求参数大小是有限制不同浏览器是不同的。一般是4KB。post请求主要用于向服务器提交请求参数。post请求的参数是放到请求实体内容中的相对get请求较为安全一些。另外请求中会有各种请求头信息比如支持的数据类型请求的来源位置以及Cookie头等相关头信息。
响应主要包含响应的状态码像200304307404500
还有各种响应头信息比如设置缓存的响应头Content-Type内容类型设置cookie头信息。
200成功服务器已成功处理了请求 304未修改客户端发出了条件式请求但服务器上的资源未曾发生改变则通过响应此响应状态 307重定向浏览器内部重定向 404未找到服务器无法找到客户端请求的资源Not Found 500服务器内部错误无法完成请求
3、POST与GET区别
Get请求一般是去取获取数据其实也可以提交但常见的是获取数据post请求一般是去提交数据。
Get是不安全的因为在传输过程数据被放在请求的URL中Post的所有操作对用户来说都是不可见的请求数据是放在body体中最常用场景用户登录密码提交一定是使用post请求的
Get传送的数据量较小这主要是因为受url长度限制Post传送的数据量较大一般被默认为不受限制。
Get请求可以被缓存Post请求不会被缓存
4、Cookie和Session的区别与联系
Cookie和Session都是会话技术Cookie是运行在客户端Session是运行在服务器端。
Cookie有大小限制以及浏览器在存cookie的个数也有限制Session是没有大小限制和服务器的内存大小有关。
Cookie有安全隐患通过拦截或本地文件找得到你的cookie后可以进行攻击。
Session是保存在服务器端上会存在一段时间才会消失如果session过多会增加服务器的压力。
5、测试的目的
简单地说就是替用户受过测试的最终目的是确保最终交给用户的产品的功能符合用户的需求把尽可能多的问题在产品交给用户之前发现并改正
6、软件测试分为哪几个阶段
单元测试、集成测试、系统测试、验收测试。
单元测试
是在软件开发过程中要进行的最低级别的测试活动在单元测试活动中软件的独立单元将在与程序的其他部分相隔离的情况下进行测试测试重点是系统的模块包括子程序的正确性验证等。
集成测试
也叫组装测试或联合测试。在单元测试的基础上将所有模块按照设计要求组装成为子系统或系统进行集成测试。实践表明一些模块虽然能够单独地工作但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题在全局上很可能暴露出来影响功能的实现。测试重点是模块间的衔接以及参数的传递等。
系统测试
是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。测试重点是整个系统的运行以及与其他软件的兼容性。
系统测试范围
功能测试、ui测试、性能测试、容错测试、可用性测试、异常问题测试、稳定性测试、系统稳定性测试、兼容性测试、接口测试、安全性测试、登录权限测试
验收测试
是软件产品检验的最后一个环节。按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审决定是否接收或拒收系统。
其它得几个阶段划分
回归测试
是指对软件的新版本测试时重复执行之前某一个重要版本的所有测试用例目的
1.验证之前版本产生的所有缺陷已全部被修复 2.确认修复这些缺陷没有引发新的缺陷
冒烟测试
是指在对一个新版本进行系统大规模的测试之前先验证一下软件的基本功能是否实现是否具备可测性。也叫可测性测试。
7、a测试与ß测试的区别
а测试 是由一个用户在开发环境下进行的测试也可以是公司内部的用户在模拟实际操作环境下进行的测试。
ß测试 是一种验收测试。beta测试是指在一个或多个用户的场所进行的测试。
8、验收测试怎么做
1、界面测试指软件产品所有的页面浏览时功能按钮或者界面是否能正常显示。 2、功能测试产品的功能是否都能正常实现。 3、性能测试发现性能瓶颈的过程包括对CPU、内存、网络环境、版本等多项测试内容。 4、安全测试产品的信息保密密码保护等功能的测试。
9、白盒、黑盒和灰盒测试区别
黑盒和灰盒的区别
如果某软件包含多个模块当使用黑盒测试时你只要关心整个软件系统的边界无需关心软件系统内部各个模块之间如何协作。而如果使用灰盒测试则需要关心模块与模块之间的交互。
白盒和灰盒的区别
在灰盒测试中你无需关心模块内部的实现细节对于软件系统的内部模块灰盒测试依然把它当成一个黑盒来看待。而白盒测试还需要再深入地了解内部模块的实现细节和各个分支。
10、冒烟测试的目的
为正式测试前验证是否产品或系统的主要需求或预置条件是否存在bug。
11、回归测试怎么做
1.在测试策略制定阶段制定回归测试策略 2.确定需要回归测试的版本 3.回归测试版本发布,按照回归测试策略执行回归测试 4.回归测试通过关闭缺陷跟踪单问题单 5.回归测试不通过缺陷跟踪单返回开发人员开发人员重新修改问题再次提交测试人员回归测试
12、需求分析的目的
第一、把用户需求转化为功能需求1对测试范围进度量 2对处理分支进行度量 3对需求业务的场景进行度量 4明确其功能对应的输入、处理和输出 5把隐式需求转变为明确。
第二、明确测试活动的五个要素测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境测试中需要的技能工具以及相应的背景知识测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确以避免测试遗漏和误解。
13、测试计划的目的
1.尽早地明确测试工作内容范围、测试工作的方法以及测试工作所需要的各种资源。 2.所有涉及到测试工作的人员尽快将下一步测试工作需要考虑的问题和准备的条件落实。 3.测试计划工作的重点在于对当前工作任务的准备和规划以及信息的交流。
14、什么时候开始写测试计划
测试计划是在需求整理完成和开发计划一起制定的一份计划书它属于项目计划中其中的一个计划
15、由谁来编写测试计划
项目经理从项目角度考虑 测试经理从测试组角度考虑 测试人员编写具体测试计划
16、测试计划的内容
1. 测试目标对测试目标进行简要的描述。 2.测试概要摘要说明所需测试的软件、名词解释、以及提及所参考的相关文档。 3.测试范围测试计划所包含的测试软件需测试的范围和优先级哪些需要重点测试、哪些无需测试或无法测试或推迟测试。 4.重点事项列出需要测试的软件的所有的主要功能和测试重点这部分应该能和测试案例设计相对应和互相检查。 5.质量目标制定测试软件的产品质量目标和软件测试目标。 6.资源需求进行测试所需要的软硬件、测试工具、必要的技术资源、培训、文档等。 7.人员组织需要多少人进行测试各自的角色和责任他们是否需要进行相关的学习和培训什么时候他们需要开始并将持续多长时间。 8.测试策略制定测试整体策略、所使用的测试技术和方法。 9.发布提交在按照测试计划进行测试发布后需要交付的软件产品、测试案例、测试数据及相关文档。 10.测试进度和任务人员安排将测试的计划合理的分配到不同的测试人员并注意先后顺序.如果开发的Release不确定可以给出测试的时间段.对于长期大型的测试计划可以使用里程碑来表示进度的变化。 11.测试开始/完成/延迟/继续的标准制定测试开始和完成的标准某些时候测试计划会因某种原因(过多阻塞性的Bug)而导致延迟问题解决后测试继续。 12.风险分析需要考虑测试计划中可能的风险和解决方法。
17、结束条件(项目上线的条件)
1.软件经过充分的测试
开发人员测试—〉交叉测试—〉测试人员测试—〉用户的业务专家测试—〉一定数量的用户业务专家集中测试—〉上线前试运行----〉上线。
2.用户培训
管理员一定厂或地区必须有一个人经过了培训。
3.基础数据导入完成
用户、组织机构、业务数据等基础必须数据导入完成。
4.授权必须完成
5.新老系统的切换必须提前演练过各种老数据的导入工作完成。
6.应急方案必须有。
18、常见的测试风险
1.需求风险、2.测试用例风险、3.缺陷风险、4.代码质量风险、5.测试环境风险、6.测试技术风险、7.回归测试风险、8.沟通协调风险、9.研发流程风险、10.其他不可预计风险
19、测试用例的要素
1.用例编号、2.测试模块、3.用例的标题、4.测试级别、5.测试目的和条件、6.测试输入、7.操作步骤、8.预期结果
20、测试用例级别的划分
测试用例优先级的目的测试用例优先级可以用来方便地基于测试策略来筛选用例。比如某块功能改动小就只用测高或中高优先级的用例。 比如冒烟测试的时候我们只需要筛选优先级最高的用例执行即可。
根据我们测试用例优先级目的那么优先级越高的测试用例覆盖的测试点应该是用户最关心的 比如一个注册功能 能够注册成功这个用例的优先级就是最高的但是不是所有的注册成功的case都是优先级最高只需要挑选一个即可 其他各种异常校验都是次要优先级的 还有一些场景覆盖的测试点很难出现或者叫就算有问题影响也不大 可以放到低优先级
21、怎样保证覆盖用户需求
1.确认需求、2.梳理需求确认测试范围、3.制定测试计划、4.根据测试计划编写测试用例、5.执行测试步骤
22、写好测试用例的关键 /写好用例要关注的维度
测试前
1.对测试目的有一个清晰的认知
2.熟悉产品的功能测试点
3.熟悉模块原理避免“互相影响”问题的产生
4.关注用户场景问题和上网问题
5.不可马虎的关键测试用例设计
编写测试用例时
1.构建测试用例框架
2.测试步骤的设计一是如果步骤过于粗糙很容易出现漏测问题二是写的过于细致可能耗时耗力并且会限制执行人员的思维。
测试用例设计方法及思考
1.切记产品测试的主要目标
2.注意用词精准问题
23、常见的测试用例设计方法
等价类划分、边界值分析、错误推断法、判定法表、正交实验法
24、什么时候用到场景法
场景法适用于解决业务流程清晰和业务比较复杂的系统或功能场景法是一种基于软件业务的测试方法。
使用场景法目的是用业务流把各个孤立的功能点串起来为测试人员建立整体业务感觉从而避免陷入功能细节忽视业务流程要点的错误倾向。例语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
基本上每个软件都会用到场景法因为每个软件背后都有业务的支撑。
场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时我们并不是先关注某个控件的细节测试等价类边界值判定表等而是要先关注主要业务流程和主要功能是否正确实现这就需要使用场景法。当业务流程和主要功能没有问题我们再从等价类、边界值、判定表等方面对控件细节进行测试先整体后细节。
Note场景法测试用例设计的重点是测试业务流程是否正确测试时需要注意的是业务流程测试没有问题并不代表系统的功能都正确还必须对单个功能进行详细的测试这样才能保证测试的充分性。
25、偶然性问题的处理
一定要提交bug
1 记得有这么个缺陷以后再遇到的时候可能就会了解发生的原因。 2 尽力去查找出错的原因比如有什么特别的操作或者一些操作环境等。 3 程序员对程序比测试人员熟悉的多也许你提交了即使无法重现程序员也会了解问题所在。 4 无法重现的问题再次出现后可以直接叫程序员来看看问题。 5 记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。
尽量重现bug
26、当我们认为某个地方是bug但开发认为不是bug怎么处理
1.告知开发bug的判断依据同时明确开发说不是bug的理由。 2.对开发的理由进行校验校验依据1.参照需求文档2.跟产品经理进行沟通确认。 3.校验结果不是bug关闭bug如果是bug提交给开发进行处理确保产品质量
27、产品在上线后用户发现bug这时测试人员应做哪些工作
1、测试人员复现问题后提交问题单进行跟踪 2、评估该问题的严重程度以及修复问题时的影响范围回归测试需要测试哪些功能 3、问题修复后先在测试环境上回归通过后再在生产环境上打补丁然后再进行回归测试 4、总结经验分析问题发生的原因避免下次出现同样问题。
28、二八定理
缺陷往往喜欢扎堆一个模块已经发现的缺陷比别的模块多通常不是代表这个模块已经把缺陷暴露完了而是意味着这个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理80%的缺陷出现在 20%的模块。
29、如何跟踪缺陷
当发现缺陷后我们要在禅道上提交问题单给开发并每隔一段时间(间隔一个小时或两个小时都可以)去检查缺陷是否被处理如果没及时处理就要提示开发让开发及时修复问题问题修复后要及时进行回归测试。
30、缺陷的状态
1、 初始化缺陷的初始状态 2、 待分配缺陷等待分配给相关开发人员处理 3、 待修正缺陷等待开发人员修正 4、 待验证开发人员已完成修正等待测试人员验证 5、 待评审开发人员拒绝修改缺陷需要评审委员会评审 6、 关闭缺陷已被处理完成。
31、缺陷的等级
轻微缺陷、一般缺陷、严重缺陷、致命缺陷
32、缺陷单应该包含这些要素
缺陷标题、缺陷类型、重现步骤、预期结果、实际结果、缺陷优先级、附件备注
33、测试报告的主要内容
测试报告包括哪些内容: 测试模块每个模块里需要记录测试的开始时间、结束时间、设计多少用例、通过多少、失败多少、有多少BUG、遗留多少BUG、解决多少BUG、追后对这个模块总结一下
BUG的统计根据时间轴来统计BUG的数量例如XXXX年X月X日发现BUG多少关闭BUG多少剩余BUG多少高级的BUG有多少中级的BUG有多少低级和建议的BUG有多少一直罗列到项目完结
项目总结汇报一下测试的大致结果。
遗留和风险该软件还有什么遗留问题还有什么风险都要一一说明
最后评判该软件是否符合上线标准日期签字加盖章等
34、如何定位bug
1、发现bug首先要查看bug的详细信息根据描述初步分析是哪个模块哪段代码的问题 2、检查引发bug的测试环境、测试代码段和测试数据排除测试人员的误操作导致的程序异常 3、确认测试代码、测试环境和数据都正确后再进一步分析bug根源。这里就需要看具体的测试业务了可借助相关的工具进行分析 4、如果产品或业务有相关的日志记录可通过分析日志来确认bug 5、当测试人员经过一系列的分析可以基本确认bug产生的原因后就可以直接找开发提bug了注意沟通技巧 6、如果各方面都分析完还不能确认bug的原因可以找开发一起定位注意保留bug现场或者可以复现bug场景 7、确认bug后提单给开发进行bug跟踪。 问题单上要描述清楚以下信息 具体的测试时间、测试环境、测试场景、测试的具体业务和功能、使用的测试代码和测试数据、测试执行步骤、测试结果、bug现象最好截图、日志记录、预期结果、bug确认相关人员等 8、跟踪bug等开发人员修复bug后进行回归测试。关注bug是否完全修复、有没有对其他功能造成影响、有没有引入新的问题
35、开发没时间修复如何推进bug的修复
1、 针对路径较深的bug测试在推动开发修复bug时需要注意以下几点
a) 从用户的角度分析问题的严重性分析用户的遇到此问题的概率引导开发站在用户角度去思考从而使开发意识到问题的严重性 b) 可以和开发人员列举一个之前的类似问题为开发提供参考 c) 产品是负责这个软件的人员当测试与开发意见无法达成一致时不要因为无法推动开发修改而放弃一定要找产品确认最终的决定权交给产品人员。
2、 上线时间紧张开发来不及修改了这个时候测试应该分析问题的严重性和产品人员商议是否需要修改
3、 修改bug改动较大影响范围广没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况建议开发人员做调研工作请教其他的同事或者组织一个临时会议集众人之力研究好的修改方案
4、 第三方应用问题开发无法修改。确认原因之后需要找相关的工作人员例如产品联系第三方的工作人员反馈问题尽量推动应用解决问题
小结
总之bug修不修测试应该有一个自己的原则同时也要权衡利弊。不能因为推不动开发就放弃由着bug上线也不能揪着一个小bug不放影响上线时间。
36、软件测试流程
了解用户需求–》参考需求规格说明书–》测试计划人力物力时间进度的安排–》编写测试用例–》评审用例–》搭建环境–》测试包安排预测冒烟测试-正式测试-bug-测试结束出报告–》版本上线–》面向用户
37、对一支圆珠笔进行测试要从哪些方面进行测试三角形测试用例设计
性能测试
能否正常书写 是否有笔油泄露 笔帽是否能正常按下弹起来
功能测试
一支笔可以用多长时间、写出的字是否褪色
易用性测试
笔的长短粗细是否顺手 一根笔芯用尽是否方便更换
界面测试
外形是否美观 时尚有趣
安全性测试
笔油是否含有有害物质 笔尖是否容易伤到人 笔油或者墨水保质期多长 过期是否产生有害物质、
兼容性测试
在不同的温度、气压、和重力下能否正常使用 在不同的纸质和力度下书写结果如何
三角形测试用例设计
1、当三边不可能构成三角形时提示错误可构成三角形时计算三角形周长。 2、若是等腰三角形打印“等腰三角形” 若两个等腰的平方和等于第三边平方和则打印“等腰直角三角形”。 3、若是等边三角形则打印“等边三角形”。 4、画出程序流程图并设计一个测试用例。 因果图、等价类划分推荐测试方法
38、在项目中发现哪些经典bug什么原因导致的
编码的问题
接口限流防刷的时候通过计数器限流如果超过某个阈值向前端返回一个codeMsg对象用于显示的时候显示的是String是乱码的问题之前由于一直返回都是json 格式都是封装好在data里。
这次返回是直接通过输出流直接写到response直接返回字节数组的而不是spring controller 返回数据springboot 默认utf-8出现乱码问题用utf-8编码解决。
比较难解决的bug无非就两种一种就是程序的逻辑出现问题导致得不到正确的结果第二种就是一些中间件开发环境的问题。
1如果是逻辑出现了问题你项目比较大的话那只能是通过单步调试或者用System.out.println()打印出来想要得到的数据看看是哪步出了问题。
2如果是开发环境或者是中间件的问题那只能是通过网上查阅资料来解决问题。如果你英语阅读能力还可以的话我推荐使用Stack Overflow来查阅资料。
39、在需求文档不太详细的情况下如何开展测试
1.主动了解做这个功能的背景意图要去解决一个什么样的问题 这个可以找产品或者开发要或者谁要求做这个功能的人要知道这些后测试的时候才心中有数知道功能实现对不对
2.尽量让熟悉这块的业务的人去测试这样功能的一些业务问题就可以测试出来
3.因为没有需求说明书测试这边只有在功能做好了转测试了才知道功能是什么样子所以这个时候写测试用例来不及就采取这样思路操作 测试的时候边测试边记录测试的点然后组内把这些测试点评审下看看是否还有遗漏的地方
40、如何尽快找到软件中的bug?
优先解决可重现的bug、对于某些没有头绪的bug可以找有经验的同事商讨、bug放大、二分定位法、模拟现场、等
41、ATM机吞卡的吞卡现象是不是BUG?
不是是特意设置的安全措施防止有人马虎操作后忘记取走银行卡而被人冒领卡中的钱款所以特意设置了倒计时限时内没有取走银行卡就会吞卡
42、如何减少非问题单的提交
1、缺陷的概要描述要清晰准确要使相关开发负责人员能够一目了然问题是什么。 2、一个完整的缺陷报告单必须包含其必要的元素信息例如概要描述缺陷发现人测试环境浏览器缺陷重现步骤严重等级指派人所属功能模块等等必要元素信息必须描述全面清楚。 3、缺陷的重现步奏必须描写清晰明了使相关开发负责人能够根据重现步骤准确的重现所提交的缺陷使其定位缺陷的原因所在。 4、指派给人一定要明确如知道缺陷是所属具体的某一个开发人员时应该直接指派给对应的负责人这样就能减少中间分配环节的时间。 5、测试数据测试的数据作为重现缺陷的一个重要元素信息一定要将测试时所使用的信息给描写清楚准确。让开发人员根据测试所提供的测试数据准确重现缺陷。 6、附件截图信息附件或截图信息能让开发人员能够一目了然的清楚问题的所在所以必要的时候提供附件或者截图信息也非常的重要。 7、描述缺陷内容的语气在进行缺陷单书写时尽量使用专业术语体现测试的专业性其次注意书写缺陷报告单时不要带有个人客观的语气内容以免影响开发和测试人员之间的关系。
43、有个程序在windows上运行很慢怎么判断是程序存在问题还是软硬件系统存在问题
1、检查系统是否有中度的特征如浏览器窗口连续打开系统中文件图标改成统一图标CPU使用率保存90%以上等 2、检查软件/硬件的配置是否符合软件的推荐标准 3、确认当前的系统是否是独立即没有对外提供什么消耗CPU资源的服务如虚拟机运行 4、如果是C/S或者B/S结构的软件需要检查是不是因为与服务器的连接有问题或者访问有问题造成的 5、在系统没有任何负载的情况下查看性能监视器确认应用程序对CPU/内存的访问情况
44、搜索功能怎么测试
功能方面的测试
搜索单个字词语句子检索到的内容是否准确链接是否准确 长度例如输入框支持100字符 那需要测试100字符、101字符最大长度的显示是否正常 哪些是支持的字符类型数字、字母、汉字、字符#、特殊字符(需求而定 字符串前后中带空格前后的空格是否过滤 中间的空格是否保留(需求而定 全角半角的字母、数字(需求而定
性能方面的测试
点击搜索按钮后搜索结果多长时间能够显示 进入搜索页面需要多久
安全性方面的测试
能否防止SQL注入攻击,否防止XSS攻击
用户体验测试
页面布局是否合理输入框和按钮是否对齐 输入框的大小和按钮的长度高度是否合理 快捷键能不能全选部分选择复制剪切粘贴是否可用粘贴超过最大长度的字符串怎么显示
兼容性测试
BS架构不同浏览器测试比如IE火狐谷歌360这些。 APP在主流的不同类型不同分辨率不同操作系统的手机上测试华为vivooppo等
45、登录功能怎么测试
功能方面的测试
输入正确的用户名和密码点击提交按钮登录成功跳转到正确的页面 输入正确的的用户名, 错误的密码登录失败并且提示相应的错误信息 输入错误的用户名正确的密码, 登录失败并且提示相应的错误信息 用户名为空, 验证登录失败并且提示相应的错误信息 密码为空, 验证登录失败并且提示相应的错误信息 用户名和密码都为空点击登陆 用户名和密码前后有空格中间空格是否处理需求而定
性能方面的测试
打开登录页面需要多长时间 输入正确的用户名和密码后登录成功跳转到新页面需要多长时间
安全性方面的测试
密码是否在前端加密在网络传输的过程中是否加密 用户名和密码的输入框能否防止SQL注入攻击 用户名和密码的输入框能否防止XSS攻击 错误登陆的次数限制防止暴力破解 是否支持多用户在同一机器上登录 一个用户在不同终端上登陆 用户异地登陆
用户体验测试
页面布局是否合理输入框和按钮是否对齐 输入框的大小和按钮的长度高度是否合理 是否可以全用键盘操作是否有快捷键 输入用户名密码后按回车是否可以登陆 牵扯到验证码的还要考虑文字是否扭曲过度导致辨认难度大考虑颜色色盲使用者刷新或换一个按钮是否好用
兼容性测试
BS架构不同浏览器测试比如IE火狐谷歌360这些。 APP在主流的不同机型不同分辨率不同操作系统的手机上测试华为vivooppo、苹果等
46、如果需要你来测试淘宝的购物车你会如何设计测试用例需要从哪些方面来考虑。
1.打开淘宝页面后页面的布局是否是完整的 2.页面的功能按钮是否可以正常显示 3.在商品页面是否会显示加入购物车 4.选中的商品是否能加入购物车 5.加入购物车后是否可以显示商品的所有信息 6.添加到购物车的商品是否可以进行删除 7.如果在网络不佳或无网络时是否可以成功的加入购物车 8.添加购物车后点击加号的时候数量是否会增长 9.添加购物车后点击减号的时候数量是否会减少 10.如果点击减号减到一定程度时是否会提示不能再减少了 11.如果淘宝用户未登录时如果添加到购物车时是否会提示请先登录 12.如果没有选择任何商品点击结算是否会提示用户“请添加要结算的商品” 13.勾选商品后已选商品的总价是否会显示 14.勾选商品显示总价后总价计算是否正确 15.勾选商品点击结算按钮后是否会进入确认订单信息的页面 16.进入确认订单信息页面的总价是否正确 17.总价是否会出现精度不准的情况比如正确总价是18.99结果显示的确实18.999999999999 18.是否有回到顶部功能 19.是否可以编辑商品属性 20.能否移入到收藏中 21.店铺名称是否显示 22.能否选择全部商品 23.能否取消选择全部商品 24.是否可以在购物车中修改商品的规格 25.添加购物的数量超过库存数量是否进行限制 26.是否可以进行清空购物车 27.结算金额是否会随着商品数量的增加减少进行变化 28.如果刷新的次数过多是否会出现闪退的现象 29.当手机来电话时淘宝页面是会还会运行 30.当手机内存不够时淘宝运行起来是否会出现卡顿的现象
整理了一波之前发布的软件测试资源【点击文末小卡片免费领取】无套路领取
最后祝大家都能找到心仪的工作快乐工作幸福生活广阔天地大有作为。我也整理了一波之前发布的软件测试文档【点击文末小卡片免费领取】无套路领取 同时在这我为大家准备了一份软件测试视频教程含面试、接口、自动化、性能测试等就在下方需要的可以直接去观看也可以直接【点击文末小卡片免费领取资料文档】
软件测试视频教程观看处 2024年吃透经典软件测试面试题200问3天学完让你的面试少走99%弯路【存下吧附100W字面试宝典】
