软件测试学习笔记---阿冬专栏

软件测试基础知识

来自：/article/1964342.html

以下是从网络上找到的一位从事软件测试大约10年的专业人员，总结的关于软件测试的不同分类及说明。最后是关于冒烟测试的一些简要介绍。
参考来源：
http://www.cnblogs.com/tankxiao/archive/2012/02/20/2347016.html

软件测试分类

软件测试的分类方法很多，主要有以下几点：

1.1 按测试设计方法分类

	测试名称	测试内容
1	Black box黑盒测试	把软件系统当成一个”黑盒”，无法了解或使用系统的内部结构及知识。从软件的行为/功能，而不是内部结构出发来设计测试。
2	White box白盒测试	设计者可以看到软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。
3	Gray box 灰盒测试	介于黑盒和白盒之间。

总结：实际工作中，对系统的了解越多越好。目前大多数的测试人员都是做黑盒测试，很少有做白盒测试的。因为白盒测试对软件测试人员的要求非常高，需要有很多编程经验。做.NET程序的白盒测试你要能看得懂.NET代码。做J***A程序的测试，需要你能看懂J***A的代码。 如果你都能看懂了，你还会做测试么？

1.2 按执行测试的方法分类

	测试名称	测试内容
1	Manual Test手动测试	测试GUI
2	Automation自动化测试	测试API

总结：对于项目来说，手动测试和自动化测试同等重要，都是保障软件质量的方法。目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化，很多复杂的业务逻辑也很难自动化， 所以自动化测试无法取代手动测试。
对于软件测试人员个人发展来说，做自动化测试是个挑战，也是测试人员发展的一个方向， 需要测试人员学习大量的开发知识（开发的知识真是学无止境啊）。从长远角度来看，自动化测试肯定是越来越吃香的。
而手动测试比较适合刚工作不久的人，手动测试最大的缺点就是技术含量低，单调乏味，容易废人。
总的来说，手工测试胜在测试业务逻辑，而自动化测试胜在测试底层架构。
如果被测试的程序可测试性比较好， 很有必要做成自动化测试。 能做自动化的尽量做成自动化，下面这些情形是可以做自动化的
1. 测试存储过程。例如用C#去测试存储过程
2. 测试Web servies. 例如：用SoupUI工具，或者C#,Java 去测试Web servies。
3. 界面和业务逻辑分离的系统，比如，MVC，MVP架构， 或者WPF 程序。 可以用测试脚本去测试这些程序的API。

1.3 按测试目的分类

1.3.1 功能测试

测试的范围从小到大，从内到外，从程序开发人员到测试人员，到一般用户Alpha/Beta测试。

	测试名称	测试内容
1	Unit Test 单元测试	在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性(开发人员做的)。
2	Functional Test 功能测试	验证模块的功能 （测试人员做的）。
3	Integration Test 集成测试	验证有依赖关系的模块功能（测试人员做）
4	Scenario Test 场景测试	验证几个模块能否完成一个用户场景（测试人员做）
5	System Test 系统测试	测试整个系统功能（测试人员做）
6	Alpha 测试	软件测试人员在真实用户环境中对软件进行全面测试（测试人员做）
7	Beta测试	真实的用户在真实的用户环境中进行的测试，也叫公测。（最终用户做的）

1.3.2 非功能测试

一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“Quality of Service requirement”服务质量需求。没有软件的功能，这些特性都无从表现出来，因此，我们要在软件开发的适当阶段，一般是基本功能完成后做这些测试。

	测试名称	测试内容
1	Stress test 压力测试	验证软件在超过负载设计的情况下仍能返回正确的结果，没有奔溃
2	Load Test 负载测试	测试软件在负载情况下能够正常工作。
3	Performance Test 性能测试	测试软件的效能，是否能够提供满意的服务质量。
4	Accessibility Test 辅助功能测试	测试软件是否向残疾用户提供足够的辅助功能。
5	Localization/Globalization Test本地/全球化测试
6	Compatibility Test 兼容性测试
7	Configuration Test 配置测试	测试软件在各种配置下能够正常工作。
8	Usability Test 可用性测试	测试软件是否好用。
9	Security Test 安全性测试

其中，
性能测试要求测试人员熟练性能测试工具，比如QTP, LoadRunner, Jmeter，Visual Studio也提供了很多性能测试的工具。要求测试人员对底层协议非常理解和编写脚本。性能测试非常有技术含量，很有发展前途，是软件测试人员的一个职业发展方向。
安全性测试的内容很广，非常有难度啊。接触到的有XSS（跨站脚本攻击）和SQL注入攻击。安全性测试非常有技术含量，也是软件测试人员的一个职业发展方向。

1.4 按测试的时机和作用分类

在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否顺畅。

	测试名称	测试内容
1	Smoke Test 冒烟测试	“冒烟”测试如果无法通过，则不能进行下一步工作。
2	Build Verification Test, BVT	验证构建是否通过基本测试。
3	Acceptance Test	验收测试，为了全面考核某功能/特性而做的测试。

BVT测试是一种Smoke Test，指Build生成好之后，自动运行的自动化测试脚本来检查这个Build的基本功能。如果BVT测试失败了，需要开发人员马上修改，重新生成Build。

1.5 按测试策略分类

	测试名称	测试内容
1	Regression Test 回归测试	对一个新的版本，重新运行以往的测试用例，看看新版本和已知的版本相比是否有退化（regression）。
2	Ad hoc Test 探索性测试	随机进行的，探索性的测试。
3	Sanity Test	粗略的测试，只需要执行部分的测试用例。

Regression Test回归测试：
对软件测试人员来说就是重复测试，所以回归测试最好是自动化的，否则测试人员就要一遍又一遍地重复测试。
1. 开发人员做些小改动，就需要测试人员做回归测试。确保现有的功能没有被破坏
2. Bug Fix 也需要回归测试，确保新的代码修复了Fix, 也确保现有的功能没有被破坏
3. 项目后期，需要做一个完整回归测试， 确保所有的功能都是好的
Ad hoc Test 探索性测试：
平常我最喜欢做随机测试了，抛开test case。自己按照自己的思路，随便点点。如果测试GUI，Ad hoc能发现大量的bug。
六年软件测试的感悟：
http://www.cnblogs.com/TankXiao/archive/2012/08/27/2576962.html#english

冒烟测试

参考来源：
http://97741.blog.51cto.com/87741/102515
http://kb.cnblogs.com/page/71988/
起初听到这个名词，真得很好奇，在软件开发领域怎么会有这么土气的名称呢。通过查阅相关资料，对冒烟测试有了一定的了解。

冒烟测试由来：

冒烟测试最早是由微软提出的，与微软一直提倡的每日构建（daily build）有很密切的关系。具体来说，冒烟测试就是在每日构建完成后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。
关于“冒烟测试”名称的来历，有几种说法。
说法一：从电路板的测试得来。因为当电路板做好以后，首先会加电测试。如果板子没有冒烟再进行其它测试，否则就必须重新来过。类似的如果冒烟测试没有通过，那么这个build也会返回给开发队伍进行修正。因此测试人员的版本必须首先通过冒烟测试的考验。
说法二：象生产汽车一样，汽车生产出来以后，首先要发动汽车，看汽车能够冒烟。如果能，证明汽车最起码可以开动了，说明完成了最基本的功能。
说法三：最早源于制造业，用于测试管道。测试时，用鼓风机往管道里灌烟，看管壁外面是否有烟冒出来，以便检验管道是否有缝隙。这一测试显然比较初级，更深层一点的测试至少要进行渗油测试、带压测试等等。Smoking Testing只是一种初级、直观的测试。

冒烟测试的应用：

冒烟测试一般用于每日构建（Daily Build），构建服务器首先从CVS服务器上，下载最新的源代码，然后编译单元测试，运行单元测试通过后，编译可执行文件，可执行文件若可运行，并能执行最基本的功能，则认为通过了冒烟测试。
简单地说，冒烟测试就是先保证系统能跑得起来，不至于让测试工作做到一半突然出现错误导致业务中断。目的就是先通过最基本的测试，如果最基本的测试都有问题，就直接打回开发部了，减少测试部门时间的浪费。