测试理论&基础面试系列1【软件测试面试题】

系列导航：分享测试面试题目及答案，题目来源于网络或机构整理面试题，答案仅供参考，个人学习记录、整理分享，欢迎交流讨论。

1.请简述w测试模型

W模型又称双V模型，它由V模型演变而来，弥补了V模型的不足。左边的V是开发的生命周期，右边的V是测试的生命周期。
W模型不仅体现了对程序的测试，还体现了对需求、文档和设计阶段的测试。
W模型是一个开发与测试并行的模型，能否清楚的看到开发和测试工作同步进行。 W模型体现了尽早测试和不断测试原则。
W模型也有其局限性，左边的V亦是把开发视为一系列串行的活动，无法支持迭代。

2.测试计划编写的六要素

why ——测试目的
what——测试内容、测试方面
when——测试起止时间
where——测试环境、文档与缺陷管理
who——测试人员安排
How——测试工具、测试存放位置

3.测试人员在软件开发中的任务

关注用户需求、寻找避免缺陷、确保软件质量

4.没有产品说明书、需求文档，如何进行黑盒测试

依据客户的功能点整理测试需求追溯表
依据开发人员的软件规格清单整理功能测试点
依据项目Demo或者同行业类似产品的测试
咨询客户、通过邮件确定争议问题

5.内测、公测（α、β测试）的区别

Alpha测试由组织内的测试人员执行，而Beta测试由最终用户执行。
在Alpha测试中不进行深入的可靠性和安全性测试，而在Beta测试期间检查可靠性、安全性和健壮性。
Alpha测试包括白盒测试和黑盒测试，而Beta测试主要涉及黑盒测试。 Alpha测试需要测试环境，而Beta测试不需要测试环境。
Alpha测试需要很长的执行周期，而Beta测试只需要几周的执行时间。
关键问题和错误在Alpha测试中立即得到解决和修复，而问题和错误则从最终用户收集，并在Beta测试中进一步实现。
总结：
Alpha版：软件完成编码阶段，内部测试是否有错误/问题。
Beta版：软件是稳定的，向有限的用户群发布。目标是获得客户对产品的反馈，并相应地对软件进行更改。

6.测试结束标准

1.超出预定的测试时间
2.执行完毕所有测试用例未发现故障
3.使用特定测试用例设计方案作为测试停止的判断
4.正面指出的停止测试的具体要求（如查出预定数目故障）
5.根据单位时间查处的故障数决定

7. 什么是探索性测试、冒烟测试

探索性测试是指在没有需求文档或不完善的情况下，依据经验进行探索尝试性地测试，是一种形成的基本的思维性测试。
冒烟测试是一种概念，强调测试软件的基本功能，而不是对软件版本包的深入测试，是进行详细测试之前的预测试。目的是在于速验证软件基本功能是否存在缺陷。

8.你认为软件测试人员应具有的素质

较好的技术能力
对业务的理解能力
良好的沟通能力
分析、解决事情的能力

7.简述测试用例设计的完整过程

首先依据需求文档、概要设计、测试计划、测试方案细分出各个功能模块的测试项。
根据测试项按照概要设计、详细设计、测试方案中的测试覆盖率细分出测试子项。 最后按照测试子项，依据测试用例设计方法设计测试用例。
另外要选择好用例管理工具、及时更新用例、做好用例分级、做好用例评审、考虑结对编写、用例设计要全面等。

8.一个身份证号码输入框，如何设计测试用例

校验身份证号码规则的有效性（符合地址码、生日码、性别码、顺序码规则）
校验末尾为x的情况
校验位数不足或超出的情况
校验输入非数字的情况

9.登陆功能如何设计测试用例

从以下几个方面：
1.功能测试：检查系统登录功能是否满足需求。
2.界面测试：检查登录界面元素、风格是否符合需求，有没有分辨率不清晰、页面错乱或遮挡等情况。
3.性能测试：检查系统响应时间，大数据并发响应时间。
4.安全测试：输入框是否屏蔽sql注入、xss攻击、输入错误密码次数限制等。
5.兼容性测试：对不同操作系统、浏览器是否可以正常工作。
6.可用性测试：检查系统的有效性、效率、易用性以及容错能力。
7.本地化测试：系统需要支持多种语言或多个国家上线时，切换语言时系统功能稳定性。

10.缺陷的生命周期

new 新建, 缺陷的初始状态
assigned 已指派，分配给具体的开发人员
open 打开, 开发人员开始修改缺陷
fixed修复,开发人员修改缺陷完毕
closed 回归测试通过,关闭缺陷
eopen 回归测试失败,再次打开
postpone 推迟修改
duplicate 与已提交的Defect重复
reject 拒绝修复，可能为测试人员与开发人员对于需求理解不同

11. 缺陷报告的内容

缺陷标题、简要描述、缺陷类型、缺陷等级、却显得详细步骤描述、缺陷的期望结果与实际结果、截图附件、日志信息、指派人员等。

12.缺陷提交不被认可怎么办

首先，提交到缺陷管理库进行备案。
进行二次确认：依据需求文档、产品说明、设计文档等来确认；或考虑类似软件的一般特性来确认；或根据用户使用习惯来确认。与设计人员、开发人员、客户代表等相关人员沟通确认。
若开发仍拒绝修改，客观严谨地向测试经理说明情况、合理论述，不参杂个人情感，等待测试经理做出最终决定。仍存争议可继续向上级反映。