理论篇

软件测试生命周期是什么？(或者另外一种问法 ：软件/项目 测试流程是怎样的？)，每个阶段要做什么？

测试需求分析

测试需求评审

编写测试计划

设计测试用例

测试用例评审

搭建测试环境

测试执行

回归测试

测试报告

三角形测试用例设计

我们可以设三角形的3条边分别为A，B，C。如果它们能够构成三角形的3条边，必须满足： (1)A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B; (2)如果是等腰的，还要判断A=B，或B=C，或A=C。 (3)如果是等边的，则需判断是否A=B=C; 

在项目中发现哪些经典bug？什么原因导致的？

注册信息中的错误提示信息：如手机信息栏应填入11位有效电话号码，但提示信息却为“13位电话号码”，这是因开发人员粗心大意造成的

接口bug：传的字段值为空，但是开发没给默认值设个0导致接收不到数据

什么是软件测试？为什么要开展软件测试？测试结束的标准是什么?

软件测试的定义： 在规定的条件下对程序进行操作，以发现程序的错误，并对软件质量进行评估。

测试的目的： 软件测试不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量

测试结束条件: 需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标。

测试计划工作的目的是什么？测试计划工作的内容包括什么？其中哪些是最重要的？

测试计划的内容 包括被测试项目的背景、测试范围、测试方式、测试资源、测试开始和结束条件、进度安排、测试组织，以及与测试有关的风险等方面的内容。

开放性问题

一条软件缺陷(bug)包含哪些内容？

缺陷标题，严重级别，问题所属模块，问题描述，测试角色，复现步骤，预期结果，实际结果，有关的日志和截图。

缺陷分为哪些等级并举例说明？ 

bug的跟踪流程是怎样的(bug的生命周期)？

测试工程师填写《缺陷跟踪单》，提交开发定位问题

开发人员定位错误后修复缺陷转给测试人员回归

测试人员对该修复进行验证，确认是否正确修复，确认是否有引发新问题，是否影响了原有正常的功能

你们用哪些工具管理bug？

禅道

bugfree

tapd

redmine

描述单元测试，集成测试，黑盒测试的侧重点

单元测试（Unit Testing） 单元测试是指对软件中的最小可测试单元进行检查和验证。

集成测试的关注点：

1. 在把各个模块连接起来时，穿越模块接口的数据是否会丢失。

2. 各个子功能组合起来，能否达到预期的要求。

黑盒测试(Black box) 把 软件看成一个黑盒子，不管内部逻辑和内部特性，只依据规格说明书检查程序的功能是否符合功能说明

Alpha,Beta测试的区别是什么？

а测试 软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试。 ß测试 软件开发公司组织各方面的的典型客户在日常工作中实际使用，并要求用户报告异常情况、提出改进意见，然后公司再进行完善。

画出瀑布模型和V模型

一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

软件测试的风险主要体现在哪里？

软件测试中的软件风险分析是根据预测软件将出现的风险，制定软件测试计划并排列优先等级，风险分析是对软件中潜在的问题进行识别、估计和评价的过程。

风险也包括进度风险、质量风险、人员风险、需求变更、成本风险等

系统测试包含哪些测试类型？

功能测试

用户体验测试

性能测试

UI测试

兼容性测试

安装测试

文档测试

稳定性测试等

有哪些软件测试用例设计方法？ 等价类、边界值、错误推测法、场景法、判定表、花瓣分析法

在需求文档不太详细的情况下，如何开展测试？

把app的所有功能都操作一遍，理清项目的数据流，澄清存在异议的地方，提取测试点；

根据提取的测试点编写测试用例，并评审；

执行测试用例，提交问题单并跟踪，直至问题被解决；

测试结束后，收集测试数据，输出测试报告。

如何尽快找到软件中的bug?

尽快熟悉公司的产品业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷；

把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗?

善于怀疑，不要过于相信开发人员的能力；

不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己，要始终以用户的需求为根本；

使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题就可能出来了；

善于学习他人经验，进行总结，转化为自己的知识体系

软件中存在错误的来源有哪些方面？

软件未实现需求和规格要求的功能 ；

软件未实现需求和规格未明确提及但应该实现的内容 ；

软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好；

测试用例执行中发现的与预期结果不符的现象

怎样才能设计出好的测试用例

覆盖用户的需求；

从用户使用场景出发，考虑用户的各种正常和异常的使用场景；

用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；

用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；

做好用例评审，及时更新测试用例。

一条测试用例包含哪些内容？

用例编号(ID),用例标题,用例级别,用例的预置条件,用例的测试步骤,用例的预期结果

ATM机吞卡的吞卡现象是不是BUG?

不一定，看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于BUG；若输入一次密码错误吞卡则是不正常的，属于BUG。

如何减少非问题单的提交？

熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；

跟产品确认该问题是否属于非问题单。

如果你提交了一个bug，但开发人员说这个不是问题，你该如何处理？

先跟开发沟通，依据需求说明书，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。

如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。

有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？

同类型软件在你的操作系统硬件环境上运行，如果一慢一块，则是软件问题

同一软件在别人的操作系统上，如果运行速度加快，则是你的操作系统或硬件的问题

回归测试怎么测？

对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全量回归；当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。

软件上线的标准是什么 ？

需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标。