软件测试常考面试题

OA：办公系统

CRM：客户关系管理系统

ERP：系统是企业资源计划

测试用例应包括哪些内容？
编号、模块名称、编写人、日期、操作说明、输入数据、预期结果等。

设计用例的方法：
在测试的不同阶段运用不用的测试方法设计用例的方法依据不同:
白盒测试用例设计有如下方法：逻辑覆盖、循环覆盖和基本路径覆盖

黑盒测试用例设计方法：等价类划分、边界值分析、错误猜测、因果图、状态图、测试大纲、
场景法、正交策略表。

一份测试计划应该包括哪些内容？
背景、项目简介、目的、测试范围、测试策略、人员分工、资源要求、进度计划、参考文档、
常用术语、提交文档、风险分析。

 

如何测试一个 纸杯？

功能度：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水（案例一）放 24 小时检查泄漏时间和情况；盛上汽油（案例二）

放 24 小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

 

单元测试、集成测试、系统测试的侧重点是什么？

单元测试针对的是软件设计的最小单元--程序模块（面向过程中是函数、过程；面向对象

中是类。）,进行正确性检验的测试工作,在于发现每个程序模块内部可能存在的差错.一般

有两个步骤:人工静态检查\动态执行跟踪

集成测试针对的是通过了单元测试的各个模块所集成起来的组件进行检验,其主要内容是

各个单元模块之间的接口,以及各个模块集成后所实现的功能.

系统测试针对的是集成好的软件系统，作为整个计算机系统的一个元素,与计算机硬件\

外设\某些支持软件\数据和人员等其他系统元素结合在一起,要在实际的运行环境中,对计

算机系统进行一系列的集成测试和确认测试.

 

搜索框测试点：

功能测试

搜索内容为空，验证系统如何处理

搜索内容为空格，查看系统如何处理

边界值验证：在允许的字符串范围内外，验证系统的处理

超长字符串输入，系统是否会截取允许的长度来检验结果

合法的字符串长度后，加空格验证检索结果

多关键字中间加入空格，逗号，tab验证系统的结果是否正确

验证每种合法的输入，结果是否正确

是否支持检索内容的复制、粘贴、编辑等操作

是否支持回车键搜索

多次输入相同的内容，查看系统的检索结果是否一致

特殊字符、转义字符、html脚本等需要做处理

敏感词汇，提示用户无权限等

输入的内容是否支持快捷键操作等

只能输入允许的字符串长度等

输入链接是否正确跳转，

搜索的历史纪录是否显示在下面

搜索内容有没有联想功能

 

界面测试

查看UI是否显示正确，布局是否合理

是否有错别字

搜索结果显示的布局是否美观

已查看的结果链接，链接的颜色要灰化处理，

结果数量庞大时，页面的分页布局是否合理

安全性测试

 

脚本的禁用

SQL的注入，检索SQL SELECT语句等

敏感内容的检索是禁止的

特殊字符的检索

被删除、加密、授权的数据，不允许被查出来，是否有安全设计控制

兼容性测试

 

多平台Windows，mac

移动平台android，ios

多浏览器火狐、chrome、IE等

性能测试

 

搜索页面的链接打开速度是否满足设计要求

搜索出结果消耗时间，是否满足设计要求

 

压力测试和负载测试的区别

负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题

 

压力测试是在高负载情况下对系统的稳定性进行测试。是在高负载（大数据量、大量并发用户等）下的测试，观察系统在峰值使用情况下的表现，从而发现系统的功能隐患 负载测试：多用户，用户数渐增，持续同时发同一业务请求，产出最大TPS 压力测试：多用户，资源使用饱和，持续同时发同一业务请求，产出系统瓶颈或使用极限

产品迭代测试流程

小编现在主要是做OA系统的迭代测试，偏于业务逻辑的功能测试，今天在这里简单记录一下可能会涉及到的测试流程知识点：

一、设计评审

按照测试流程，第一步就是参与涉及评审，一般设计评审会有三方角色参与，分别是：产品、开发、测试。产品经理会提前通知参加评审的时间和地点，以及提供srs涉及文档。常规设计评审都是以会议的模式展开，设计评审的过程：

1、产品经理讲解设计文档；

2、开发人员估测代码可行性和实现功能的工作量；

3、测试人员预估测试工作量。

通过三方讨论，最终决定设计是否过关，是否采用。而在此过程中，测试人员需要的注意事项有以下几项：

1、  设计评审前，仔细查看设计文档，理解新功能和之前版本哪些功能有交叉的测试点，以及之后进行测试时可能需要注意的地方。先预估一下测试的工作量，记录自己不懂的地方，以便于在设计评审中，重点关注一下相关模块，有疑惑及时提出。

2、  设计评审中，注意一定要养成记录评审的习惯。评审过程中肯定会有一些设计开发和产品有争议的，比如代码实现量大，或会改动到其他某些模块，也可能是暂时无法实现的，这些都要记录下来，一则加深自己对于评审的记忆（因为距离评审通过到开发交付演示，时间可能会有点长），同时也对之后编写测试用例应该注意的地方，提前做一个文档记录的预防。

3、  设计评审完成后，整理自己评审前和评审中的文档，如果评审通过，则可以根据最新的设计文档，梳理出一份简单的用例导图。