1.B/S架构和C/S架构区别

• B/S 只需要有操作系统和浏览器就行，可以实现跨平台，客户端零维护，维护成本低，但是个性化能力低，响应速度较慢
• C/S响应速度快，安全性强，一般应用于局域网中，因为要针对不同的操作系统,需要针对性的开发,并且维护成本高

2.HTTP协议

http协议又叫做超文本传输协议，在做网络请求的时候，我们基本上是使用http协议。
http协议包括请求和响应。
请求中包括:请求地址，请求方式，请求方式包括get请求和post请求，get和post的区别是get请求是在地址栏后边跟随请求参数，但是请求参数大小是有限制，不同浏览器是不同的。一般是4KB。post请求主要用于向服务器提交请求参数。post请求的参数是放到请求实体内容中的，相对get请求较为安全一些。另外，请求中会有各种请求头信息，比如支持的数据类型，请求的来源位置，以及Cookie头等相关头信息。

响应，主要包含响应的状态码，像200，304，307，404，500
还有各种响应头信息，比如设置缓存的响应头，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.测试前：
1.对测试目的有一个清晰的认知、2.熟悉产品的功能测试点、3.熟悉模块原理，避免“互相影响”问题的产生、4.关注用户场景问题和上网问题、
5.不可马虎的关键测试用例设计、
2.编写测试用例时：
1.构建测试用例框架、2.测试步骤的设计（一是如果步骤过于粗糙很容易出现漏测问题；二是写的过于细致，可能耗时耗力，并且会限制执行人员的思维。）
3.测试用例设计方法及思考
1.切记产品测试的主要目标、2.注意用词精准问题

23.常见的测试用例设计方法

等价类划分、边界值分析、错误推断法、判定法表、正交实验法

24.什么时候用到场景法

场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。
使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。
基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。
场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。
Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。

25.偶然性问题的处理

1.一定要提交bug、
1． 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。
2． 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3． 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重现，程序员也会了解问题所在。
4． 无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5． 记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。
2.尽量重现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：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等

45.登录功能怎么测试

功能方面的测试：
输入正确的用户名和密码，点击提交按钮，登录成功，跳转到正确的页面
输入正确的的用户名, 错误的密码，登录失败，并且提示相应的错误信息
输入错误的用户名，正确的密码, 登录失败，并且提示相应的错误信息
用户名为空, 验证登录失败，并且提示相应的错误信息
密码为空, 验证登录失败，并且提示相应的错误信息
用户名和密码都为空，点击登陆
用户名和密码前后有空格，，中间空格是否处理（需求而定）

性能方面的测试
打开登录页面，需要多长时间
输入正确的用户名和密码后，登录成功跳转到新页面，需要多长时间

安全性方面的测试
密码是否在前端加密，在网络传输的过程中是否加密
用户名和密码的输入框，能否防止SQL注入攻击
用户名和密码的输入框，能否防止XSS攻击
错误登陆的次数限制（防止暴力破解）
是否支持多用户在同一机器上登录
一个用户在不同终端上登陆
用户异地登陆

用户体验测试：
页面布局是否合理，输入框和按钮是否对齐
输入框的大小和按钮的长度，高度是否合理
是否可以全用键盘操作，是否有快捷键
输入用户名，密码后按回车，是否可以登陆
牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用

兼容性测试
BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
APP：在主流的不同机型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo、苹果等

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.当手机内存不够时，淘宝运行起来是否会出现卡顿的现象

47.测试用例通用规则