测试笔试题4

软件测试面试题
1.简述测试流程
第一步：对要执行测试的产品/项目进行分析，确定测试策略，制定测试计划。该计划被审核批准后转向第二步。测试工作启动前一定要确定正确的测试策略和指导方针，这些是后期开展工作的基础。只有将本次的测试目标和要求分析清楚，才能决定测试资源的投入。

第二步：设计测试用例。设计测试用例要根据测试需求和测试策略来进行，进度压力不大时，应该设计的详细，如果进度、成本压力较大，则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。

第三步：如果满足“启动准则”（EntryCriteria），那么执行测试。执行测试主要是搭建测试环境，执行测试用例。执行测试时要进行进度控制、项目协调等工作。

第四步：提交缺陷。这里要进行缺陷审核和验证等工作。

第五步：消除软件缺陷。通常情况下，开发经理需要审核缺陷，并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后，进入到回归测试阶段。如果满足“完成准则”（ExitCriteria），那么正常结束测试。

第六步：撰写测试报告。对测试进行分析，总结本次的经验教训，在下一次的工作中改

2什么是软件测试的目的与原则
软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码实现的最终审查。
软件测试的目的是：
（1）从用户角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，已考虑是否可以接受产品。
（2）从软件开发者出发，则希望软件测试成为表明软件产品不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。

3.目前主要的测试用例设计方法是什么?
等价类划分，边界值，错误推测法，因果法，判定表驱动法，正交法，功能图法，场景法，

4.给你一个网站，你如何测试?
1.首先，确认需求，
2.其次，分析测试需求，并制定测试计划，确定测试范围、使用测试技术以及对测试进行人员安排等等，
3.再然后，根据测试需求编写测试用例，可使用Excel或者相关用例管理工具对用例进行管理，
4.网站进入测试阶段，根据用例进行测试，若发现问题，则将问题提交到相应的缺陷管理工具，指派到问题负责人。
5.问题修复完毕，对修复的问题进行回归验证，并验证是否有引发其他问题，
6.最后编写测试报告，简要概述测试过程以及测试结果，
7.总结，本次主要是从测试过程来讲述如何测试一个网站
对于具体怎么测试，要看测试方法是什么，如是功能测试、兼容性测试、还是性能测试、安全测试.....不同的测试方法测试内容不同。
至于测试时间也是无法直接给定的，要根据测试范围、测试方法等来决定。

 

5.软件的安全性应从哪几个方面 去测试?

软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

用户认证安全的测试要考虑问题： 明确区分系统中不同用户权限 、系统中会不会出现用户冲突 、系统会不会因用户的权限的改变造成混乱 、用户登陆密码是否是可见、可复制 、是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）、用户退出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统 、系统网络安全的测试要考虑问题 、测试采取的防护措施是否正确装配好，有关系统的补丁是否打上 、模拟非授权攻击，看防护系统是否坚固 、采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是 NBSI 系列和 IPhacker IP ） 、采用各种木马检查工具检查系统木马情况 、采用各种防外挂工具检查系统各组程序的外挂漏洞
数据库安全考虑问题： 系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）、系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍） 、系统数据可管理性 、系统数据的独立性 、系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

6.黑盒测试和白盒测试是软件测试的两种基本方法，请分别说明各自的优点和缺点!
黑盒测试

优点:
1.对于较大的代码单元来说，黑盒测试比白盒测试效率较高。
2.测试人员不需要了解细节，包括特定的编程语言。
3.测试人员和开发人员是彼此独立的。
4.从用户的角度测试，很容易被理解和接受。
5.有助于暴露与任务规格不一致或者有歧义的地方。
6.测试用例可以在需求规格完成之后马上执行。
缺点:
1.测试的只有一小部分，不可能测试全部输入。
2.没有清洁和简明的需求规格说明书，测试用例很难设计。
3.如果测试人员，不被告知开发人员已经执行过的用例，在测试数据上会存在不必要的重复。
4.很多测试路径没有测试到。
5.不能直接对特定程序段进行测试，改程序段可能隐藏更多错误。
6.大部分和研究相关的测试都是直接针对白盒测试的。
不知道能不能解决你的疑问。

白盒测试
优点：
1) 帮助软件测试人员增大代码的覆盖率。 提供代码的质量，发现代码中隐藏的问题

缺点 ：
1) 程序运行会有很多不同的路径，不可能测试所有的运行路径
2) 测试基于代码，只能测试开发人员做的对不对，而不能知道设计是否正确，可能会漏掉一些功能需求
3) 系统庞大时，测试开销会非常大。

7,什么是并发?
1、并发运行就是让计算机同时运行几个程序或同时运行同一程序多个进程或线程。
2、早期的计算机只具有一个中央处理器（CPU)并且是单核（只有一个运算器）的，这种情况下计算机操作系统采用并发技术实现并发运行，具体做法是采用“ 时间片轮询进程调度算法”，它的思想简单介绍如下： 在操作系统的管理下，所有正在运行的进程轮流使用CPU，每个进程允许占用CPU的时间非常短（比如10毫秒），这样用户根本感觉不出来CPU是在轮流为多个进程服务，就好象所有的进程都在不间断地运行一样。但实际上在任何一个时间内有且仅有一个进程占有CPU及CPU的运算器。
3、现阶段许多计算机具有多个中央处理器或一个处理器具有多个运算器（多核），情况就不同了，如果进程数小于CPU或运算器数，则不同的进程可以分配给不同的CPU或运算器来运行，这样，各个进程就是真正同时运行的，这便是并行。但如果进程数大于CPU或运算器数，则仍然需要使用并发技术。
4、有些操作系统并不支持多个CPU或多核CPU，如 ms winodws 9x、3.x，这样的操作系统多个CPU、或多核CPU对它们来说是无用的。

总线程数 <= CPU数量：并行运行
总线程数 > CPU数量：并发运行

8.您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果?

尽量面对面的沟通，其次是能直接通过电话沟通，如果只能通过Email等非及时沟通工具的话，强调必须对特性的理解深刻以及能表达清楚。

运用一些测试管理工具如TestDirector进行管理也是较有效的方法，同时要注意在TestDirector中对BUG有准确的描述。

在团队中建立测试人员与开发人员良好沟通中注意以下几点：
一真诚、二是团队精神、三是在专业上有共同语言、四是要对事不对人，工作至上

当然也可以通过直接指出一些小问题，而不是进入BUG Tracking System来增加对方的好感。

9.测试结束的标准是什么?
作为软件测试结束的标志是：错误强度曲线下降到预定的水平。

10.请你回答一下性能测试有哪些指标，对一个登录功能做性能测试，有哪些指标
性能测试常用指标从外部看，主要有：

1、吞吐量：每秒钟系统能够处理的请求数，任务数

2、响应时间：服务处理一个请求或一个任务的耗时

3、错误率：一批请求中结果出错的请求所占比例

从服务器的角度看，性能测试关注CPU，内存，服务器负载，网络，磁盘IO

对登录功能做性能测试：

1、单用户登陆的响应界面是否符合预期

2、单用户登陆时后台请求数量是否过多

3、高并发场景下用户登录的响应界面是否符合预期

4、高并发场景下服务端的监控指标是否符合预期

5、高集合点并发场景下是否存在资源死锁和不合理的资源等待

6、长时间大量用户连续登录和登出，服务器端是否存在内存泄漏

 

11.如何测试一个 纸杯?
测试项目：杯子
需求测试：查看杯子使用说明书
界面测试：查看杯子外观
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
抗破坏性：杯子从不同高度落下的损坏程度
可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试：杯子加包装(有填充物),在多高的情况摔下不破损
震动测试：杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路\公路\航空运输
测试数据：测试数据具体编写此处略(最讨厌写测试数据了).其中应用到:场景法、等价类划分法、因果图法、错误推测法、边界值法等方法
期望输出：该期望输出需查阅国标、行标以及使用用户的需求
说明书测试：检查说明书书写准确性
启发式测试策略模型( Heuristic Test Strategy Model)
在做测试设计时，首先想到的是要应用我们已有的测试技术(Test Techniques)并综合考虑项目环境(Project Environment)、产出物(Product element)、质量准则(quality Criteria)。这样我们就能够得到一个有基本保障的(看得到的)质量(Perceived Quality)
回到刚才所说的“测试一个纸杯”，我们目前能拿到的只有手中的“一个纸杯”，对照一下刚才所说的图，其实最先想到的应该是产出物(Product element)。模型给出了产出物域需要思考的项：
　　结构(Structure)- 所有组成产出物的东西。
　　代码，界面，接口，硬件，非可执行文件，附属物件。
　　功能(Functions)- 所有产品所实现的功能
　　用户界面，系统接口，应用，计算，时间相关性功能，变化(如改变字体)，
　　开启/关闭，多媒体，错误处理，交互，可测性
　　数据(Data) -所有产品处理的数据
　　输入，输出，预设值，持久数据，序列，大小数量变化，噪声数据，生命周期等
　　平台(Platform) -所有被测软件所依赖的外部事物
　　外部硬件，外部软件，内部组建
　　操作(Operation) -所有产品可执行的操作
　　用户，环境，常见操作，非正常操作，极限操作
　　时间(Time) -所有与产品相关的时间指标
　　输入/输出，快/慢，并发，变化率
结构：用料是否环保?是否能平稳放在桌面上?放了水是否能平稳放在说面上?杯口是否光滑?。。。。。
　　功能：到进水是否不漏，是否不变形?拿起来是否能够不显著变形?水是不是能倒出来?。。。。。
　　数据：放半杯水，放一整杯水，放冷水，放热水，放茶叶，放可乐。。。。。。。
　　平台：能否放在桌子上不倒?手拿着是否不变形，不会感到不舒服?是否能放到杯架、套到别的杯子上?。。。
　　操作：倒进水，喝水，再倒水，倒开水，捏变形，弹烟灰，丢弃。。。。
　　时间：看喝水的时候水是不是很快的能流出来。。。
　　这里边有重复项，这没关系，合并同类项就好了，我们不是要强制归类，而是要利用这些引导词帮你想到该测试的地方。
功能测试(Function test)
能否装水，
除了装水， 能否装其他液体。比如可乐，酒精
能装多少ML的水
杯子是否有刻度表
杯子能否泡茶，跑咖啡
杯子是否能放冰箱，做冰块
杯子的材质是什么（玻璃，塑料,黄金做的）
界面测试(UI Test)
外观好不好看。
什么颜色
杯子的形状是怎么样的。
杯子的重量是多少
杯子是否有异味
杯子的图案是否合理
性能测试(performance test)
能否装100度的开水 (泡茶)
能否装0度冰水
装满水，放几天后，是否会漏水
杯子内壁上的涂料是否容易脱落。
杯子上的颜色是否容易褪色或者脱落
被我坦克压下，是否会碎 (这条是开玩笑的哈)
安全性测试(Security test)
制作杯子的材料，是否有毒
放微波炉里转的时候，是否会爆炸, 或者杯子是否会熔化。
从桌子上掉到水泥地上是否会摔碎。
杯子是否容易长细菌
杯子是否有缺口，会划坏嘴巴
杯子内壁上的材料，是否会溶解到水中
杯子破碎后，是否会对使用者造成伤害
可用性测试(Usability Test)
杯子是否容易烫手
杯子是否好端，好拿
杯子的水是否容易喝到
杯子是否有防滑措施

12.购物车功能怎么进行测试?
功能测试
1.点击购物车是否可以跳转购物车界面
2.选中商品后是否可以正确计算出商品总价
3.点击管理是否可以弹出管理相应按钮（清理、移入收藏夹、删除）
4.点击商家前的空心圆是否可以批量选中购物车内相应店铺所有商品
5.点击商品前的空心圆是否可以选中该商品
6.点击商品是否可以跳转商品详情购买界面
7.点击店铺是否可以跳转店铺
8.点击颜色分类是否可以进行颜色重新选择
9.点击下方全选前的空心圆是否可以选中购物车内所有商品
10.未选择商品点击结算是否可以弹窗提示“您还没有选择宝贝哦”
11.选择商品点击结算是否可以跳转至确认订单界面
12.点击已选择商品前的对勾是否可以取消选中状态

界面测试
1.图片展示是否有误
2.颜色搭配是否赏心悦目
3.选中商品后商品前的空心圆有怎样的变化
4.购物车下是否可以展示购物车内商品数量
5.是否可以正确展示购物车商品信息（店铺、图片、文字描述、价格等）
6.“你可能还喜欢”模块商品图片布局是否美观
7.已下架商品是否会有相应提示

性能测试
1.页面响应速度怎样
2.下滑是否会有卡顿
3.最多可以存放多少件商品
4.最大一次性可以交易的金额是多少

安全测试
1.交易过程中是否存在密码泄露的风险
2.商家是否能查看用户的购物车
3.用户地址和手机等信息是否会被泄露
4.别的用户能否查看他人的购物车

易用测试
1.能否兼容不同的浏览器（IE、火狐、谷歌等）
2.能否兼容不同的设备（笔记本、电脑、手机、平板等）
3.能否兼容不同的登录渠道（app、浏览器、微信小程序等）
4.删除功能是否有提示
5.是否有回到顶部的功能
6.商品过多时结算按钮是否可以浮动显示

13.对于有系统大量并发访问，你会如何做测试，有什么建议

此类测试实际上涉及多个部分的内容，不同部分的测试策略不相同。
一般而言，整体测试策略是：先针对部分系统进行性能及压力测试，得到各部分的峰值处理性能；再模拟整体流程测试，此时倒不用按照峰值跑，重点测试整体业务流程及业务预期负荷。
在定义好各部分的测试策略后，具体的工具使用选择倒不是主要问题。

1、不同省份、不同运营商CDN节点性能
此部分可以采用典型压力测试的方案。

2、核心机房BGP网络带宽
此部分重点在于测试各运营商BGP网络可靠性、实际速率等，一般采用smokeping、IxChariot等工具。

3、各类硬件设备性能
此部分一般采用专业的网络设备测试工具。

4、各类服务器（Web服务器、应用服务器、缓存服务器等）并发性能、分布式处理能力
此部分可以采用压力测试方案及工具。

6、业务系统性能
此部分可以采用业务系统压力测试方案。

7、数据库处理性能
大部分互联网公司都对数据库作了定制改造以满足业务需要，此部分测试需要结合业务系统进行测试，以获取核心业务场景下数据库的TPS/QPS，尤其是测试定制改造的地方。

8、支付渠道接口及分流测试
此部分相对而言可能是最大的瓶颈所在，也是互联网公司们无法完全掌控的地方，只能协调银行总部改造支撑。

另外还涉及备份方案、容灾方案、业务降级方案的测试。
这里指的业务降级方案，是基于“有损服务、柔性可用”的策略，为保证核心服务可用的前提下，对部分服务的质量降级处理。

 

14.简述负载测试与压力测试的区别。

1、含义不同：

负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。负载测试是一种测试方法，可以为性能测试、压力测试所采用。压力测试通常是在高负载情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。

　　

2、对象不同：

压力测试强度，负载测试载重。

负载压力测试是在一定约束条件下测试系统所能承受的并发用户量、运行时间、数据量，以确定系统所能承受的最大负载压力。负载压力测试有助于确认被测系统是否能够支持性能需求，以及预期的负载增长等。负载压力测试不只是关注不同负载场景下的响应时间等指标，它也要通过测试来发现在不同负载场景下会出现的，例如速度变慢、内存泄漏等问题的原因。负载压力测试是性能测试的重要组成部分，负载压力测试包括并发性能测试、疲劳强度测试、大数据量测试等内容。找到一些在测试流程中前面的阶段所进行的粗略测试中没有被找出的bugs，例如，内存管理bugs，内存泄露，缓冲器溢出等等。保证应用程序达到性能测试中确定的性能基线。这个可以在运行回归试验时，通过加载特定的最大限度的负载来实现。尽管性能测试和负载测试似乎很像，但他们的目的还是有差异的。

15.假设有一个池塘，里面有无穷多的水。现有2个空水壶，容积分别为5升和6升。题是如何只用这 2个水壶从池塘里取得3升的水。

1.将5L的水壶打满。此时两个水壶盛水5/5 0/6（即有5L的水在5L的水壶中，0L的水在6L的水壶中，下同）。2.将5L的水壶中全部水倒入6L的水壶中。此时两个水壶盛水0/5 5/6。3.将5L的水壶再次打满。此时两个水壶盛水5/5 5/6。4.用5L的水壶中的水倒入6L的水壶中，直至6L的水壶变满。此时两个水壶盛水4/5 6/6。5.将6L的水壶清空，并将5L水壶中的水倒入6L水壶中。此时两个水壶盛水0/5 4/6。6.将5L的水壶打满。此时两个水壶盛水5/5 4/6。7.重复4的过程。此时两个水壶盛水3/5 6/6。至此，我们取得了3L的水。