软件测试基本概念

1.软件测试的定义：
使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

1.互联网公司的研发团队结构
·产品经理
负责需求分析，产品审核等等。
·开发
开发也分前端和后端。
·测试
·运维
网络设备的维护与管理。
·运营
产品开发完成后，靠运营去拉动客户，增加访问量，推销产品。
·设计
负责对软件的UI进行设计。

2.测试的分类：
·按照开发阶段：单元测试，集成测试，系统测试，验收测试
·按照实施组织：α、β、第三方相当于，产品设计完成的最初版本，仅供内部测试，这个叫做α，技术趋于成熟后，交给特定的少量用户使用，也就是内测，就是β。最后，产品相当成熟，基本没有问题，这时候就可以上市发行了，这就是第三方测试。
·按照执行方式： 静态测试（不执行代码，检查有没有设计错误），动态测试，运行代码，检查有没有错误。
按照是否查看代码：分为黑盒测试，白盒测试，灰盒测试。黑盒测试，不关注内部实现，只在乎主要功能是否达到，白盒测试，不关注用户界面针对软件的过程以及细节进行详细检查，灰盒测试则是介于两者之间。
·按照是否手工执行划分:手工测试，自动化测试。
·按照地域划分：本地化测试，国际化测试。

3.软件开发的生命周期

制定计划——需求分析——设计——编码——测试——运维

4.软件测试流程
（1）需求分析：
首先需要学习并了解软件的业务，分析需求点。
（2）测试计划
编写完成的测试计划包括了测试人员，测试周期，测试方法，测试工具等。
（3）设计测试用例
测试用例是软件测试最核心的模块，在执行任何测试之前，必须完成测试用例的编写。测试用例是知道你执行测试，帮助你证明或者发现软件缺陷的一种说明，测试用例写好后悔进行评估。
（4）用例执行
首先大剑环境，准备好测试数据，进行预测试，预测试通过后，按照测试用例进行正常测试。
（5）评估
些评估报告，队整个测试的过程和版本的质量做一个评估。

5.编写测试用例的常用方法
·等价类
·边界值
·判定表
·因果图
·状态迁移
·正交试验
·场景法
·错误推断

6.如何进行测试用例的设计

1.测试需求分析，从项目部拿到需求文档后，通过自己的分析对项目的需求有清晰的了解，对于要测试什么，按照什么顺序，覆盖到那些需求，都要有深入的了解。
2.业务流程分析：分析完需求后，明确每一个功能的业务处理流程，不同功能业务点的组合，以及项目的隐式需求。
3.完成以上两步，就可以正式开始测试用例的编写，设计测试用例时应该尽可能考虑到边界，异常，性能等方面。
4.编写完以后对测试用例进行检查，自我检查，交叉查检查，部门检查。
·检查测试用例本身的描述是否清晰，有没有二意性。
·测试用例内容是否完整，是否清晰地包含输入和输出的预期结果，
·测试步骤是否清晰
·测试中使用的数据是否恰当，准确。
·测试内容是否完全覆盖了需求

7.测试用例的要素
·用例编号
·用例名称
·前置条件
·优先级
·重要性
·测试数据
·测试步骤
·预期结果
·实际结果

8.bug的六要素
·bug的编号
·bug名称
·bug的优先级
·bug的严重程度
·bug的复现步骤（发现bug的步骤、预期结果、实际结果）
·附件（佐证bug的存在一般以截图，录制视频等形式）

9.bug的分类以及生命周期
bug的分类

bug，其实就是软件期望的行为与实际行为的差异。从程序的角度来看，在软件整个生命周期中都会有bug的出现。需求分析过程中，需求理解的不足，导致的理解错位 ，遗漏甚至变化都可能导致bug；设计本身有好坏之分，但是bug本身还是比较隐晦，不是那么明显。编码阶段，也会有理解错误，语言特性，第三方库框架，等等导致的bug. 后期打包，部署，运维也会产生 bug，打包的错误，配置错误，以及环境的错位。自己主要谈谈编码引入的和环境的导致bug。这是最最经常碰到的bug。　　另外也可以从其他方面开分类，比如稳定可重现的bug与不可稳定重现的bug。比如多线程导致的竞争。数据敏感的导致的不能稳定重现的bug。从是否与环境关联，业务逻辑的bug，环境相关的的bug等。

一个BUG的生命周期

缺陷状态　　对于一个问题，其处理过程是一个周期，周期的不同阶段，其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。

打开 ：表示问题被提交等待有人处理。

重新指派 ：问题被重新指派给某人处理。

处理 ：问题在处理中，尚未完成。

固定 ：确认此问题存在，但暂时不进行处理。

回归 ：对已经修复的问题进行回归确认。Reopened

关闭 ：问题的最后一个状态。

提交（打开）缺陷

在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。当然，我们在提交一个问题之前首先应该保证，这个缺陷是没有被提过的，以免造成重复缺陷单。如果是回归不通过的缺陷，其状态又会变为打开状态。

分配（转交）缺陷

一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员。　　有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员。也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。

确认缺陷

当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷（可能由于测试人员不了解需求）或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。

推迟处理

在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理（或到下个版本进再进行修复）。

固定

对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。

处理缺陷

开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）

回归缺陷

回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。　　确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。　　确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。　　确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。

关闭缺陷

对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。