软件测试基本理论

软件测试分类
按所处开发阶段，分为：单元测试、集成测试、系统测试、验收测试。
按是否运行，分为：静态测试、动态测试。
按是否查看源代码，分为：黑盒测试、白盒测试、灰盒测试。
其他类型：回归测试、冒烟测试、随机测试。

冒烟测试： 一个新版本的开发完成后，对该版本的最基本功能进行测试。先投入较少的人力和时间验证一个软件的主要功能，如果主要功能都没有实现，则打回开发组重新开发。这样做的好处是可以节省大量的时间成本和人力成本。

回归测试： 一是就是当你修复一个bug后，把之前的测试用例再次应用到修复后的版本上进行测试。二是当一个新版本开发好后，而且冒烟测试通过，此时可以先用上一个版本的测试用例对新版本进行测试，看是否有bug！回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

两者的区别
冒烟测试主要是在新版本发布后，对其最基本的功能进行测试，保证最基本流程能走通，以便进行后续的测试。
回归测试主要是验证之前版本产生的所有缺陷已全部被修复和确认修复这些缺陷没有引发新的缺陷。

测试用例八要素
用例编号、测试项目、用例名称、重要等级、预置条件、测试数据、测试步骤、预期结果。

1、用例编号
具有唯一性。一般是由数字和字符组成的字符串，可包括：单词缩写、下划线、数字等。注：尽量不要写汉语拼音，因为拼音的意义可能有好几种，有可能会导致乱码。

参考编号规范：产品编号-测试阶段（UT/IT/ST）-系统测试项名-系统测试子项名-XXX
1）产品编号：也叫项目标识，表明该用例所属的项目或者产品。
2）测试阶段（UT/IT/ST）：表明该用例所处的测试阶段。UT为单元测试阶段，IT为集成测试阶段，ST系统测试阶段。
实际工作中有些公司会将产品编号以及测试阶段省略。
3）测试项目名：对应的是较大系统的测试点。
4）测试子项目名：有些测试是没有子项目名的，只有当测试项目粒度比较大的时候才会有测试子项目 。如：我们要测试用户能否成功登录这个功能，那我们就可以分为很多个子项，qq登录、邮箱登录等。
5）编号：一般是数字，如001、002等。

2、测试项目
对应测试用例中的子项名。
1）单元测试用例：对应函数名。
2）集成测试用例：对应集成后的模块功能或者接口功能。
3）系统测试用例：对应一个功能点（功能测试）、性能指标（性能测试）、界面中控件（GUI测试）等等。

3、用例名称
也叫测试目的。要简单、概要，体现测试的出发点和关注点。

4、重要等级
用例的重要级别一般分成三个级别：高、中、低。
高级别：对应保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例；
中级别：对应重要程度介于高和低之间的测试用例；
低级别：对应实际使用频率不高，对系统业务功能影响比较大的模块或功能的测试用例。
注：正常情况的测试用例的重要级别比异常情况的测试用例的重要级别要高。

5、预置条件
测试用例在执行前需要满足的一些前提条件，否则测试用例无法执行。
预置条件一般分两种：环境的设置、先要运行其他用例。
1）环境的设置
　　例如：登录成功的预置条件就是：该用户名已经注册过了。
　　例如：购买商品成功的预置条件就是：后台已经配置好商品、发货区域、以及支付方式了。
2）先要运行的其他用例
有些操作系统会比较复杂，如果都是从最开始的操作开始会导致用例写起来比较麻烦，这样可以在预置条件中设定要先运行的测试用例，后面的用例只需要写后续的操作就可以了。
　　例如：对自动取款机进行测试，有针对的输入账户信息的测试，有对输入取钱金额的测试，后者的预置条件就可以写成输入正确账户信息的测试用例。

6、测试数据
用例执行过程中需要加工的外部信息，根据软件测试用例的具体情况，有手工输入、文件、数据库记录等。
禁止过多描述性语言，若为文件，会有提示选择路径，最好写具体，让别人易懂易操作。

7、测试步骤
明确描述测试执行过程中具体的操作步骤，以方便测试执行人员可以根据该操作步骤完成测试用例执行。

8、预期结果
检验被测对象是否正常工作。
写预期输出的时候可以从以下三个方面来考虑：界面显示、数据库变化、相关信息变化。
1）界面显示：在操作步骤完成之后，界面会有显示；比如说我们测试用户登录功能，界面可能会显示登录成功或者登录失败。
2）数据库的变化：在操作步骤完成之后，数据库中的记录会发生相应的变化，比如删除功能的测试，点击删除后，数据库中该记录会被删除。
3）相关信息的变化：在操作步骤执行完成后，一些和被测对象相关的信息会发生变化，比如：注销功能的测试，点击注销后，以前能访问的页面将无法再访问。

博客主页：https://blog.csdn.net/yisumi