软件测试基础知识总结
2013-10-17 12:35
274 查看
一、基本概念
软件中BUG的定义
软件的bug指的是软件中(包括程序与文档)不符合用户需求的问题。这个定义使我们判断一个软件问题是否是bug的唯一标准
软件测试的最终目的
是检验实际的软件系统是否符合用户的需求，所以不能为了发现错误而发现错误。
测试环境
测试环境 = 软件+硬件+网络
软件主要是指软件运行的操作系统。
软件环境的分类
软件开发环境：软件在开发过程中使用的环境
软件生产运行环境：最终用户使用环境
软件测试环境要与软件生产运行环境保持一致，要从开发环境中独立出来。
测试用例
测试用例 = 输入+输出+测试环境（+测试步骤）
输入：测试数据和操作步骤
输出：期望结果
测试环境：系统环境设置
编写测试用例的唯一标准是用户需求，具体参考资料是《系统需求规格说明书》和软件原型。
优点：便于团队交流，便于重复测试，便于跟踪统计，便于用户自测。
二、软件测试分类
黑盒测试与白盒测试——按是否查看源代码划分
黑盒测试：把被测的软件看做是一个黑盒子，不关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。
白盒测试：把盒子盖打开，去研究里面的源代码和程序结构，查看程序的源代码具体是怎么实现的。
静态测试与动态测试：——按是否运行程序划分
静态测试：static testing 不实际运行被测软件，而只是静态的检查程序代码（包括检查注释），界面或者文档中可能存在的错误的过程。
动态测试：dynamic testing 实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符。
判断一个测试属于动态测试还是静态测试，唯一的标准是看是否运行程序。
单元测试、集成测试、系统测试、验收测试：——按阶段划分
时间比例1:2:4:2
单元测试：unit testing 对软件中的最小可测单元进行检查和验证（单元是指认为规定的最小被测功能模块）
依据：源程序，《详细设计文档》
一般步骤：1.编译运行程序
2.静态测试（检查代码是否符合规范）
3.动态测试
桩模块和驱动模块
桩模块：stub 模拟被测模块所调用的模块
驱动模块：driver 用来接收测试数据，启动被测模块并输出结果
集成测试：integration testing 单元测试的下一阶段，将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口，检查各个单元模块结合到一起能否协同配合，正常运行。
依据：单元测试的模块以及《概要设计文档》
系统测试：system testing 将整个软件系统看做一个整体进行测试，包括对功能，性能，以及软件所运行的软硬件环境进行测试。
需要花大量时间和精力去完成的，也是软件交给用户进行验收测试的最后一道关卡。
依据：《系统需求规格说明书》
验收测试：acceptance testing 系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试。
分为 a（a fa）测试 【由用户，测试人员，开发人员等共同参与的内部测试】和 b (be ta)测试【内测后的公测，完全交给最终用户的测试】
功能测试盒性能测试：——属于黑盒测试
功能测试：function testing 检查实际软件的功能是否符合用户的需求
功能测试又可以细分为很多种：逻辑功能测试logic function testing，界面测试UI testing，易用性测试usability，安装测试installation，兼容性测 试compatibility等。
性能测试：performance testing 一般要使用自动化测试工具。软件性能主要包括时间性能和空间性能。
性能测试分为：一般性能测试，稳定性测试，负载测试，压力测试
一般性能测试：让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。
稳定性测试：reliability 也叫做可靠性测试。连续运行被测系统，检查系统运行时的稳定程度。
负载测试：load 让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。
压力测试：stress 持续不断的给被测系统增加压力，只要将被测系统压垮为止，用来测试系统所能承受的最大压力。
回归测试，冒烟测试，随机测试：
回归测试：regression 对软件的新的版本测试时，重复执行上一个版本测试时的用例。
冒烟测试：smoke 是指对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
随机测试：random 测试中所有的输入数据都是随机生成的，其目的是模拟用户的真是操作，并发现一些边缘性的错误
三、软件测试基本原则
1.zero bug 和good enough原则
zero bug ： 软件没有任何的错误
good enough：只要软件达到一定的质量要求，就可以停止测试了。（过分的测试浪费资源）
2.不要试图穷举测试
3.开发人员不能既是运动员又是裁判
4.软件测试要尽早执行
5.软件测试应该追溯需求
6.缺陷的二八定理
一般情况下，软件80%的缺陷集中在20%的模块
7.缺陷具有免疫性
软件中BUG的定义
软件的bug指的是软件中(包括程序与文档)不符合用户需求的问题。这个定义使我们判断一个软件问题是否是bug的唯一标准
软件测试的最终目的
是检验实际的软件系统是否符合用户的需求，所以不能为了发现错误而发现错误。
测试环境
测试环境 = 软件+硬件+网络
软件主要是指软件运行的操作系统。
软件环境的分类
软件开发环境：软件在开发过程中使用的环境
软件生产运行环境：最终用户使用环境
软件测试环境要与软件生产运行环境保持一致，要从开发环境中独立出来。
测试用例
测试用例 = 输入+输出+测试环境（+测试步骤）
输入：测试数据和操作步骤
输出：期望结果
测试环境：系统环境设置
编写测试用例的唯一标准是用户需求，具体参考资料是《系统需求规格说明书》和软件原型。
优点：便于团队交流，便于重复测试，便于跟踪统计，便于用户自测。
二、软件测试分类
黑盒测试与白盒测试——按是否查看源代码划分
黑盒测试：把被测的软件看做是一个黑盒子，不关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。
白盒测试：把盒子盖打开，去研究里面的源代码和程序结构，查看程序的源代码具体是怎么实现的。
静态测试与动态测试：——按是否运行程序划分
静态测试：static testing 不实际运行被测软件，而只是静态的检查程序代码（包括检查注释），界面或者文档中可能存在的错误的过程。
动态测试：dynamic testing 实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符。
判断一个测试属于动态测试还是静态测试，唯一的标准是看是否运行程序。
单元测试、集成测试、系统测试、验收测试：——按阶段划分
时间比例1:2:4:2
单元测试：unit testing 对软件中的最小可测单元进行检查和验证（单元是指认为规定的最小被测功能模块）
依据：源程序，《详细设计文档》
一般步骤：1.编译运行程序
2.静态测试（检查代码是否符合规范）
3.动态测试
桩模块和驱动模块
桩模块：stub 模拟被测模块所调用的模块
驱动模块：driver 用来接收测试数据，启动被测模块并输出结果
集成测试：integration testing 单元测试的下一阶段，将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口，检查各个单元模块结合到一起能否协同配合，正常运行。
依据：单元测试的模块以及《概要设计文档》
系统测试：system testing 将整个软件系统看做一个整体进行测试，包括对功能，性能，以及软件所运行的软硬件环境进行测试。
需要花大量时间和精力去完成的，也是软件交给用户进行验收测试的最后一道关卡。
依据：《系统需求规格说明书》
验收测试：acceptance testing 系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试。
分为 a（a fa）测试 【由用户，测试人员，开发人员等共同参与的内部测试】和 b (be ta)测试【内测后的公测，完全交给最终用户的测试】
功能测试盒性能测试：——属于黑盒测试
功能测试：function testing 检查实际软件的功能是否符合用户的需求
功能测试又可以细分为很多种：逻辑功能测试logic function testing，界面测试UI testing，易用性测试usability，安装测试installation，兼容性测 试compatibility等。
性能测试：performance testing 一般要使用自动化测试工具。软件性能主要包括时间性能和空间性能。
性能测试分为：一般性能测试，稳定性测试，负载测试，压力测试
一般性能测试：让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。
稳定性测试：reliability 也叫做可靠性测试。连续运行被测系统，检查系统运行时的稳定程度。
负载测试：load 让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。
压力测试：stress 持续不断的给被测系统增加压力，只要将被测系统压垮为止，用来测试系统所能承受的最大压力。
回归测试，冒烟测试，随机测试：
回归测试：regression 对软件的新的版本测试时，重复执行上一个版本测试时的用例。
冒烟测试：smoke 是指对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
随机测试：random 测试中所有的输入数据都是随机生成的，其目的是模拟用户的真是操作，并发现一些边缘性的错误
三、软件测试基本原则
1.zero bug 和good enough原则
zero bug ： 软件没有任何的错误
good enough：只要软件达到一定的质量要求，就可以停止测试了。（过分的测试浪费资源）
2.不要试图穷举测试
3.开发人员不能既是运动员又是裁判
4.软件测试要尽早执行
5.软件测试应该追溯需求
6.缺陷的二八定理
一般情况下，软件80%的缺陷集中在20%的模块
7.缺陷具有免疫性
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 