原创作者：jerry
来自Sawin软件研发之窗
最后修改时间：2007-8-31
冒烟测试是指开发团队提交给测试团队进行测试的前期，测试团队检查产品的主要功能是否实现，是否有影响产品正常运行的错误。如果存在这些问题，测试团队有权退回测试任务给开发组，开发组重新组织单元和集成测试。
又叫衰竭测试，测试人员对已经测试过的内容进行重新测试的活动。因为经过一轮测试以后测试组发现一些缺陷，开发人员在修改这些缺陷的同时势必会引起其他缺陷的发生，回归测试主要就是测试这些新缺陷的活动。
基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件
不基于内部设计和代码的任何知识，而是基于需求和功能性。
最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试桩。
一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。集成方法由自上而下，自下而上，混合三种方式。
用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。
基于系统整体需求说明书的黑盒类测试;应覆盖系统所有联合的部件
测试不运行的部分————只是检查和审阅。
通常意义上的测试————运行和使用软件。
指正规测试完毕后由公司内部人员充当客户进行测试；
指产品在推出之前，给一些友好客户使用，让他们来进行测试。
图一 缺陷管理流程
1. 测试人员发现一个缺陷，设置状态为New；
2. 提交给缺陷控制人员；
3. 缺陷控制人员判断这个缺陷是否为缺陷；
4. 如果不是设置状态为Invalid；
5. 否则判断这个缺陷在本轮测试中是否可以修改；
6. 如果暂时不能不能修改，保持状态New；
7. 否则设置状态为Assigned；
8. 将Assigned的缺陷交给开发人员修改；
9. 修改完毕，设置状态为Fixed；
10. 测试人员复测标记为Fixed的缺陷；
11. 复测是否成功；
12. 复测成功，设置状态为Closed；
13. 否则设置状态为ReOpen；
14. 返回步骤8
（SEI TSP国际标准）
1. 每次测试开始，开发部门提出测试重点，开发机版本同步到测试机器上；
2. 测试人员进行冒烟测试，如果冒烟测试没有通过退回给开发部门，等待开发部门重新提交测试任务，返回第1步；
3. 否则测试人员执行测试活动；
4. 开发人员修改被确认的缺陷（状态为Assigned）；
5. 当测试人员认为测试结束，大部分缺陷都发现完毕，开发机上版本第二次同步到测试机器上；
6. 测试人员对缺陷进行复测，标记为ReOpen或Closed；
7. 开发人员对于ReOpen的缺陷进行修改；
8. 复测期间每天晚上将开发机器上的版本同步到测试机器上；
9. 如果所有Open，ReOpen的缺陷都Closed掉，本轮测试结束，回到第1步进行新的一轮回归测试；
10. 当一轮测试中发现的缺陷不存在Blocker，Critical，Major，Normal的缺陷，或者Minor，Trivial，Enhancement的缺陷少于10个，测试机器上的版本同步到发布机器上，测试任务完成。
Ø Blocker：（阻碍的）
阻碍开发和/或测试工作，冒烟测试没有通过，不能够进行正常的测试工作
Ø Critical：（紧急的）
系统无法测试，或者系统无法继续操作，应用系统异常中止
对操作系统造成严重影响，系统死机，被测程序挂起，不响应等
造成重大安全隐患情况（如机密性数据的泄密）
功能没有实现，无法进行某一个功能操作，影响系统使用
Ø Major：（重大的）
功能基本实现，但在特定情况下导致功能失败
导致输出的数据错误（数据内容出错、格式错误、无法打开等）
导致其它功能模块无法正常执行
功能不完整或者功能实现不正确
导致数据最终操作结果错误
Ø Normal：(普通的)
功能部分失败，对整体功能的实现基本不造成影响。
Ø Minor：（较小的）
链接错误、系统出错提示不正确或没有捕获系统出错信息、数据的重要操作（添加、删除、修改）没有提示、出现频率极低，会对功能实现造成非致命影响。
Ø Trivial：（外观的）
产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等
Ø Enhancement(改进的)
对于系统产品建议或意见
Ø P5：严重级别比较高的，影响测试进行或者系统无法继续操作
Ø P4：对系统操作有影响，但是不需要马上修改
Ø P3：页面缺陷（不属于定义的缺陷范围）或者建议
Ø P2：准备在下一轮测试前修改完毕
Ø P1：准备在下一版本中修改
在内容中分别按下面格式进行书写
Bug所处的模块
出现bug的详细描述
bug现象
bug总结
|
编号
|
Chinafi_***_XXX
|
|
前置条件
|
|
|
说明
|
|
|
项号
|
测试步骤
|
显示结果
|
是否通过
|
概要说明
|
|
1
|
1,
|
|
|
|
|
|
2，
|
|
|
|
|
|
3，
|
|
|
|
|
|
4，
|
|
|
|
|
|
5，
|
|
|
|
|
2
|
1，
|
|
|
|
|
|
2，
|
|
|
|
|
|
3，
|
|
|
|
|
|
4，
|
|
|
|
|
|
5，
|
|
|
|
|
|
6，
|
|
|
|
|
|
7，
|
|
|
|
|
|
8,
|
|
|
|
|
|
9，
|
|
|
|
编号格式：”Chinafi_”+ModuleName+”_”+XXX:
1. Chinafi 为固定的开始字符；
2. ModuleName:为模块名，首字母大写，字母之间以_隔开；
3. XXX：为3位0-9的字母；
前置条件：完成此项测试，哪些模块的功能必须正确，那些资源必须到位等前提条件；
说明：测试项目的描述；
项号：一个测试中包括可几个项目，每个项目的编号；
测试步骤：完成测试的具体步骤描述；
显示结果：对于一些重要步骤的页面显示结果，每一项最后一步的显示结果必须书写；
是否通过：Y测试通过，N测试未通过；
概要说明：对于测试过程中的一些说明注解。
|
编号
|
Chinafi_Storeroom_Overview_002
|
|
前置条件
|
我库管理[test]功能正常
|
|
说明
|
大库概况功能调整(具体人才信息，实时改为每天凌晨自动执行)
|
|
项号
|
测试步骤
|
显示结果
|
是否通过
|
概要说明
|
|
1
|
1,进入系统
|
|
|
|
|
|
2，进入人才/我库管理
|
|
|
|
|
|
3，按[test]
|
|
|
|
|
|
4，进入人才/大库概况
|
|
|
|
|
|
5，点没入自动库人数小计中的数据
|
页面显示速度很快，并且没有功能错误
|
Y
|
正式机器上调用为二十几秒，140机器上为5，6秒
|
|
2
|
1，进入系统
|
|
|
|
|
|
2，进入人才/大库概况
|
|
|
|
|
|
3，统计没有进入自动库人数统计
|
结果为N
|
|
|
|
|
4，到案管/我的人才库中寻找一条只有进入一个人才库的人才
|
|
|
|
|
|
5，点访这个人才
|
|
|
|
|
|
6，将这个人才剔除
|
|
|
|
|
|
7，执行人才/我库管理中的[test]
|
|
|
|
|
|
8, 进入人才/大库概况
|
|
|
|
|
|
9，统计没有进入自动库人数统计
|
结果为N+1
|
Y
|
|
在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支持以下测试的工具和技术。
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以
及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI)
与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要：
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化测试。
负载测试是一种性能测试。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行
的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其
他与时间相关的方面。
是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正
常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或
工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的
报表。
与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。
对“用户友好性”的测试。显然这是主观的，且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。
对软件的全部、部分或升级安装/卸载处理过程的测试。
可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/
输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。
安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问。
应用程序级别的安全性可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数
据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而
“用户二”只能看见同一客户的统计数据。
系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
配置测试又叫兼容性测试，核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体
硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。
（如浏览器版本。OS版本等）
是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。
测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试
由于测试人员的思路不尽相同，每个人测试的侧重点不同，由于都按照测试用例进行测试，但是测试用例一般仅描述系统的
一些基本测试项，不会将所有的测试用例方方面面都写到，有时还需要测试人员的经验和素质。所以A测试某个产品用了七个工作日，第一天到第四天报出许多
bug,但从第五天开始几乎报不出啥bug了。七天后换了B,B一下子又测试出一堆bug,不能说A的水平差，只能说，该产品已经对A产生了抗药性，这就
是测试学中的杀虫剂现象。
所以在测试中每次轮流测试最好安排不同的测试人员进行不同模块测试工作，以避免杀虫剂现象产生。