软件测试方法作业流程类型缺陷.docx

I. 测试类型
功效指是系统能做什么。
系统子系统或组件要实现功效能够在工作产品中，如需求规格说明书，用户用例或功效规格说明书给予描述，不过也可能没有对应文档。
功效测试基于功效和特征和专门系统之间交互，系统功效来设计测试条件和测试用例。
1 专门系统之间交互，我们又叫做‘功效交互’
2 能够采取基于规格说明书技术（有正式需求或设计规格说明书时）
3 也能够基于测试人员对功效和特征了解（假如没有对应文档时）
4 功效测试关键是考虑软件外部表现行为（黑盒测试）
5 功效测试能够在个等级测试中进行（比如组件测试、集成测试和系统测试等等级全部有基于设计或需求规格说明书功效测试）
1. 功效测试举例
1 安全性测试也是功效测试一个，它会对安全性相关功效（比如防火墙）进行测试，从而检测系统和数据是否能抵御外部恶意威胁，比如病毒等。
2 互操作性测试是另一个功效性测试，评定软件产品和其它一个或多个组件或系统交互能力。
2. 非功效测试
非功效性测试就是测试系统工作怎样
非功效测试包含但不限于：性能测试、负载测试、压力测试、可用性测试、可维护性测试、可靠性测试和可移植性测试
非功效测试能够在任何测试等级上实施
3. 非功效测试举例
负载测试：一个经过增加负载来测量组件或系统测试方法。比如：经过并发用户数和事务数量来测量组件或系统能够承受负载。
压力测试：在要求或超出要求需求条件下测试组件\系统，以对其进行评定。
健壮性测试：判定软件产品健壮性（在出现无效输入或压力环境条件下，组件、系统能够正常工作程度，参见fault-tolerance）测试。
性能测试：判定软件产品性能（组件、系统在给定处理周期和吞吐率（throughputrate）等约束下，完成指定功效程度）测试过程。参见efficiencytesting.
4. 和变更相关测试
和变更相关测试：当软件被修改、缺点被修复、新增了功效、软件运行环境发生改变等，需要开展和变更相关测试。
依据经验，修改一个现存程序，比编写一个新程序更轻易产生错误（依每写一行代码错误数量计）
再测试：重新实施上次失败测试用例，以验证纠错正确性。参见确定测试（confirmationtesting）
回归测试：测试先前测试过并修改过程序，确保更改没有给软件其它未改变部分带来退化缺点（regressionbung）.软件修改后或使用环境变更后要实施回归测试。
回归测试策略：
回归测试规模能够依据在已运行软件中发觉新缺点风险大小来决定，比如能够只重新运行全部发觉缺点用例（即只进行确定测试）、测试全部经过修改功效、测试全部新增功效、对整个系统进行完美回归测试等，对变更进行影响分析（impactanalysis）有利于确定回归测试深度。
将回归测试自动化是很好选择。
回归测试能够在全部测试等级上进行，同时适适用于功效测试、非功效测试和结构测试。
5. 维护测试
维护测试是在一个现有运行系统上进行，且一旦对软件或系统进行修改、移植或退伍处理时，就需要进行维护测试。
除了对已变更部分进行测试外，维护测试还包含对系统没有发生变更其它部分进行大范围回归测试。维护测试范围取决于变更风险、现有系统规模和变更大小。
维护测试依据变更情况不一样，能够在某一或全部测试等级和测试类型上进行。
修改能够是计划中功效增强（比如：依据版本公布计划）、纠正和应急变更、环境改变比如计划中操作系统或数据库升级，或因为新发觉或暴露软件、操作系统、硬件漏洞而大打补丁等。
为软件移植（如从一个平台移植到另外一个平台）而进行维护测试应该包含新环境运行测试（operationaltesting），和对变更以后软件运行测试。
为系统退伍而进行维护测试应该包含数据移植或存档测试，假如需要长时间数据保留话。
II. 测试方法
软件测试方法是指测试软件性能方法。伴随软件测试技术不停发展，测试方法也越来越多样化，针对性更强；选择适宜软件测试方法能够让用户事半功倍。软件测试方法有系统测试、动态测试、单元测试、集成测试等多个。

B测试，英文名是Beta testing。又称Beta测试用户验收测试（uat）。
B测试是软件多个用户在一个或多个用户实际使用环境下进行测试。
当开发和测试要完成所做测试，而最终错误和问题需要在最终发行前找到。这种测试通常由最终用户或其它人员完成，不能由程序员或测试员完成。
A测试-Alpha测试
A测试，英文名是Alpha testing。又称Alpha测试。
Alpha测试是由用户在开发环境下进行测试，也能够是企业内部用户在模拟实际操作环境下进行受控测试，Alpha测试不能由该系统程序员或测试员完成。
在系统开发靠近完成时对应用系统测试；测试后仍然会有少许设计变更。这种测试通常由最终用户或其它人员来完成，不能由程序员或测试员完成。
可移植性测试，英文名是Portability testing。又称兼容性测试。
可移植性测试是指测试软件是否能够被成功移植到指点硬件或软件平台上。
1. UI测试
用户界面测试，英文名是User interface testing。又称UI测试。
用户界面，英文名是User interface。是指软件中可见外观及其底层和用户交互部分（菜单、对话框、窗口和其它控件）。
用户界面测试是指测试用户界面风格是否美观，文字，图片组合是否完美，操作是否友好等等。UI测试目标是确保用户界面会经过测试对象功效来为用户提供对应访问或浏览功效。确保用户界面符合企业或行业标准。包含用户友好性、人性化、易操作性测试。
用户界面测试用户 分析软件用户界面设计是否合乎用户期望或要求。它常常包含等菜单，对话框及对话框上全部按钮，文字，犯错提醒，帮助信息（Menu和heipcontent）等方面测试。比如，测试Microsoft Excel中插入符合功效所用对话框大小，全部按钮是否对齐，字符串字体大小，犯错信息内容和字体大小，工具栏位置、图标等等。
2. 冒烟测试
冒烟测试，英文名是Snoke testing。
冒烟测试名称能够了解为该种测试耗时短，仅用一袋烟功夫足够了。也有些人认为是形象地类比新电路板基础功效检验。任何新电路板焊好后，先通电检验，假如存在设计缺点，电路板可能会短路，板子冒烟了。
冒烟测试对象是新编译每一个需要正式测试软件版本，目标是确定软件基础功效正常，能够进行后续正式测试工作。冒烟测试实施者是版本编译人员。
3. 随机测试
随机测试，英文名是Ad hoc testing。
随机测试没有书面测试用例、统计期望结果、检验列表、脚本或指令测试。关键是依据测试者经验对软件进行功效和性能抽查。随机测试是根听说明书实施用例测试只要补充手段，是确保测试覆盖完整性有效方法和过程。
随机测试关键是对被测软件部分关键功效进行复测，也包含测试那些目前测试样例（TestCase）没有覆盖到部分。另外，对于软件更新和新增加功效要关键测试。关键对部分特殊点情况点、特殊使用环境、并发性、进行检验。尤其对以前测试发觉直达Bug，进行再次测试，能够结合回归测试（Regressive testing）一起进行。
当地化测试当地化测试，英文是Localization testing。
当地化就是将软件版本语言进行更改，比如将英文windows改成汉字windows就是当地化。当地化测试对象是软件当地化版本。当地化测试目标是测试特定目标区域设置软件当地化质量。当地化测试环境是在当地化操作系统上安装当地化软件。从测试方法上能够分为基础功效测试，安装/卸载测试，当地域域软硬件兼容性测试。测试内容关键包含软件当地化后界面布局和软件翻译语言质量，包含软件、文档和联机帮助等部分。
1. 基础化
当地化能力测试，英文是Localizability testing。
当地化能力测试是指不需要重新设计或修改代码，将程序用户界面翻译成任何目口号言能力。为了降低当地化能力测试成本，提升测试效率，当地化能力测试通常在软件伪当地化版本上进行。
当地化能力测试中发觉经典错误包含：字符硬编码（即软件中需要当地化字符写在了代码内部），对需要当地化字符长度设置了固定值，在软件运行时以控件位置定位，图标和位图中包含了需要当地化文本，软件用户界面和文档术语不一致等。
2. 国际化
国际化测试，英文是International testing。又称国际化支持测试。
国际化测试目标是测试软件国际化支持能力，发觉软件国际化潜在问题，确保软件在世界不一样区域全部能正常运行。国际化测试使用每种可能国际输入类型，针对任何区域性或区域设置检验产品功效是否正常，软件国际化测试关键在于实施国际字符串输入/输出功效。国际化测试数据必需包含东亚语言、德语、复杂脚本字符和英语（可选）混合字符。
国际化支持测试是指验证软件程序在不一样国家或区域平台上也能够如预期那样运行，而且还能够根据原设计尊重和支持使用当地常见日期，字体，文字表示，特殊格式等等。比如，用英文版 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串?用阿拉伯版 Windows XP 和 阿拉伯版Microsoft Word 能否展示阿拉伯字符串?又比如，日文版Microsoft Excel对话框是否显示正确翻译日语?一旦来说实施国际化支持测试测试人员往往需要基础上了解这些国家或地域语言要求和期望行为是什么。
3. 安装测试
安装测试，英文是Installing testing。
安装测试是确保软件在正常情况和异常情况下，比如，进行首次安装、升级、完整或自定义安装全部能进行安装测试。异常情况包含磁盘空间不足、缺乏目录创建权限等场景。核实软件在安装后可立即正常运行。安装测试包含测试安装代码和安装手册。安装手册提供怎样进行安装，安装代码提供安装部分程序能够运行基础数据。
B. 白盒测试
白盒测试，英文是White Box Testing。又称结构测试或逻辑驱动测试。
白盒测试是把测试对象看作一个打开盒子。利用白盒测试法进行动态测试时，需要测试软件产品内部结构和处理过程，不需测试软件产品功效。
白盒测试法覆盖标准有逻辑覆盖、循环覆盖和基础路径测试。其中逻辑覆盖包含语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
白盒测试是知道产品内部工作过程，可经过测试来检测产品内部动作是否根据规格说明书要求正常进行，根据程序内部结构测试程序，检验程序中每条通路是否全部有能按预定要求正确工作，而不顾它功效，白盒测试关键方法有逻辑驱动、基路测试等，关键用于软件验证。
白盒测试常见工含有：Jtest、VcSmith、Jcontract、C++ Test、CodeWizard、logiscope。
C. 黑盒测试
黑盒测试，英文是Black Box Testing。又称功效测试或数据驱动测试。
黑盒测试是依据软件规格对软件进行测试，这类测试不考虑软件内部运作原理，所以软件对用户来说就像一个黑盒子。
软件测试人员以用户角度，经过多种输入和观察软件多种输出结果来发觉软件存在缺点，而不关心程序具体怎样实现一个软件测试方法。
黑盒测试常见工含有：AutoRunner、winrunner
D. 自动化
自动化测试，英文是Automated Testing。
使用自动化测试工具来进行测试，这类测试通常不需要人干预，通常在GUI、性能等测试和功效测试中用得较多。经过录制测试脚本，然后实施这个测试脚原来实现测试过程自动化。中国领先自动化测试服务提供商是泽众软件。自动化测试工含有QTP、Testcomplete、AutoRunner和TAR等。
1. 回归测试
回归测试，英文是Regression testing。
回归测试是指在发生修改以后重新测试先前测试以确保修更正确性。理论上，软件产生新版本，全部需要进行回归测试，验证以前发觉和修复错误是否在新软件版本上再次出现。
依据修复好了缺点再重新进行测试。回归测试目标在于验证以前出现过但已经修复好缺点不再重新出现。通常指对某已知修正缺点再次围绕它原来出现时步骤重新测试。通常确定所需再测试范围时是比较困难，尤其当临近产品公布日期时。因为为了修正某缺点时必需更改源代码，所以就有可能影响这部分源代码所控制功效。所以在验证修好缺点时不仅要服从缺点原来出现时步骤重新测试，而且还要测试有可能受影响全部功效。所以应该激励对全部回归测试用例进行自动化测试。
2. 验收测试
验收测试，英文是Acceptance testing。
验收测试是指系统开发生命周期方法论一个阶段，这时相关用户或独立测试人员依据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足协议或用户所要求需求测试。
验收测试通常有三种策略：正式验收、非正式验收或Alpha 测试、Beta 测试。
E. 静态测试
静态测试，英文是Static Testing。
静态测试指测试不运行部分，比如测试产品说明书，对此进行检验和审阅.。静态方法是指不运行被测程序本身，仅经过分析或检验源程序文法、结构、过程、接口等来检验程序正确性。静态方法经过程序静态特征分析，找出欠缺和可疑之处，比如不匹配参数、不合适循环嵌套和分支嵌套、不许可递归、未使用过变量、空指针引用和可疑计算等。静态测试结果可用于深入查错，并为测试用例选择提供指导。
静态测试常见工含有：Logiscope、PRQA；
F. 动态测试
动态测试，英文是Moment Testing。
动态测试是指经过运行软件来检验软件动态行为和运行结果正确性。
依据动态测试在软件开发过程中所处阶段和作用，动态测试可分为以下多个步骤：
1、单元测试
2、集成测试
3、系统测试
4、验收测试
5、回归测试
G. 单元测试
单元测试，英文是Unit Testing。
单元测试是最微小规模测试;以测试某个功效或代码块。经典地由程序员而非测试员来做，因为它需要知道内部程序设计和编码细节知识。这个工作不轻易做好，除非应用系统有一个设计很好体系结构; 还可能需要开发测试驱动器模块或测试套具。
H. 集成测试
集成测试，英文是Integration Testing。
集成测试是指一个应用系统各个部件联合测试，以决定它们能否在一起共同工作并没有冲突。部件能够是代码块、独立应用、网络上用户端或服务器端程序。这种类型测试尤其和用户服务器和分布式系统相关。通常集成测试以前，单元测试需要完成。
集成测试是单元测试逻辑扩展。它最简单形式是：两个已经测试过单元组合成一个组件，而且测试它们之间接口。从这一层意义上讲，组件是指多个单元集成聚合。在现实方案中，很多单元组合成组件，而这些组件又聚合成程序更大部分。方法是测试片段组合，并最终扩展进程，将您模块和其它组模块一起测试。最终，将组成进程全部模块一起测试。另外，假如程序由多个进程组成，应该成对测试它们，而不是同时测试全部进程。
集成测试识别组合单元时出现问题。经过使用要求在组合单元前测试每个单元，并确保每个单元生存能力测试计划，能够知道在组合单元时所发觉任何错误很可能和单元之间接口相关。这种方法将可能发生情况数量降低到更简单分析等级
I. 系统测试
系统测试，英文是System Testing。
系统测试是基于系统整体需求说明书黑盒类测试，应覆盖系统全部联合部件。系统测试是针对整个产品系统进行测试，目标是验证系统是否满足了需求规格定义，找出和需求规格不相符合或和之矛盾地方。
系统测试对象不仅仅包含需要测试产品系统软件，还要包含软件所依靠硬件、外设甚至包含一些数据、一些支持软件及其接口等。所以，必需将系统中软件和多种依靠资源结合起来，在系统实际运行环境下来进行测试。
J. 端到端
端到端测试，英文是End to End Testing。
端到端测试类似于系统测试，测试级“宏大”端点，包含整个应用系统环境在一个现实世界使用时模拟情形全部测试。比如和数据库对话，用网络通讯，或和外部硬件、应用系统或合适系统对话。端到端架构测试包含全部访问点功效测试及性能测试。端到端架构测试实质上是一个"灰盒"测试，一个集合了白盒测试和黑盒测试优点测试方法。
K. 卸载测试
卸载测试，英文是Uninstall Testing。
卸载测试是对软件全部、部分或升级卸载处理过程测试。关键是测试软件能否卸载，卸载是否洁净，对系统有没有更改，在系统中残留和以后生成文件怎样处理等。还有原来更改系统值是否修改回去
L. 验收测试

接收测试，英文是Accept Testing。
接收测试是基于用户或最终用户规格书最终测试，或基于用户一段时间使用后，看软件是否满足用户要求。通常从功效、用户界面、性能、业务关联性进行测试。
M. 性能测试

性能测试，英文是Performance Testing。
性能测试是在交替进行负荷和强迫测试时常见术语。理想“性能测试”(和其它类型测试)应在需求文档或质量确保、测试计划中定义。性能测试通常包含负载测试和压力测试。
通常验证软件性能在正常环境和系统条件下反复使用是否还能满足性能指标。或实施一样任务时新版本不比旧版本慢。通常还检验系统记忆容量在运行程序时会不会出现内存泄露(memory leak)。比如，验证程序保留一个巨大文件新版本不比旧版本慢。
1. 健全测试
健全测试，英文是Sanity testing。
健全测试是指一个初始化测试工作，以决定一个新软件版本测试是否足以实施下一步大测试能力。比如，假如一个新版软件每5分钟和系统冲突，使系统陷于泥潭，说明该软件不够“健全”，不含有深入测试条件。
2. 衰竭测试
衰竭测试，英文是Failure Testing。
衰竭测试是指软件或环境修复或更正后“再测试”。可能极难确定需要多少遍再次测试。尤其在靠近开发周期结束时。自动测试工具对这类测试尤其有用。
3. 负载测试
负载测试，英文是Load testing。
负载测试是测试一个应用在重负荷下表现。比如测试一个 Web 站点在大量负荷下，何时系统响应会退化或失败，以发觉设计上错误或验证系统负载能力。在这种测试中，将使测试对象负担不一样工作量，以评测和评定测试对象在不一样工作量条件下性能行为，和连续正常运行能力。
负载测试目标是确定并确保系统在超出最大预期工作量情况下仍能正常运行。另外，负载测试还要评定性能特征，比如，响应时间、事务处理速率和其它和时间相关方面。
4. 强迫测试
强迫测试，英文是Force Testing。
强迫测试是在交替进行负荷和性能测试时常见术语。也用于描述对象在异乎平常重载下系统功效测试之类测试，如某个动作或输入大量反复，大量数据输入，对一个数据库系统大量复杂查询等。
5. 压力测试
压力测试，英文是Stress Testing。和负载测试差不多。
压力测试是一个基础质量确保行为，它是每个关键软件测试工作一部分。压力测试基础思绪很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏条件下运行测试。通常要进行压力测试资源包含内部内存、CPU 可用性、磁盘空间和网络带宽等。通常见并发来做压力测试。
6. 恢复测试
恢复测试，英文是Recovery testing。
恢复测试是测试一个系统从以下灾难中能否很好地恢复，如碰到系统瓦解、硬件损坏或其它灾难性问题。恢复测试指经过人为让软件（或硬件）出现故障来检测系统是否能正确恢复，通常关注恢复所需时间和恢复程度。
恢复测试关键检验系统容错能力。当系统犯错时，能否在指定时间间隔内修正错误并重新开启系统。恢复测试首先要采取多种措施强迫系统失败，然后验证系统是否能立即恢复。对于自动恢复需验证重新初始化（reinitialization）、检验点(checkpointing mechanisms)、数据恢复(data recovery)和重新开启 (restart)等机制正确性；对于人工干预恢复系统，还需估测平均修复时间，确定其是否在可接收范围内。
N. 安全测试

安全测试，英文是Security Testing。
安全测试是测试系统在预防非授权内部或外部用户访问或有意破坏等情况时怎么样。这可能需要复杂测试技术。安全测试检验系统对非法侵入防范能力。安全测试期间，测试人员假扮非法入侵者，采取多种措施试图突破防线。比如：
①想方设法截取或破译口令；
②专门定做软件破坏系统保护机制；
③有意造成系统失败，企图趁恢复之机非法进入；
④试图经过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够时间和资源，没有不可进入系统。所以系统安全设计准则是，使非法侵入代价超出被保护信息价值。此时非法侵入者已无利可图。
O. 兼容性

兼容测试，英文是Compatibility Testing。
兼容测试是测试软件在一个特定硬件/软件/操作系统/网络等环境下性能怎样。向上兼容向下兼容，软件兼容硬件兼容。软件兼容性有很多需要考虑地方。
P. 可用性

可用性测试，英文是Practical Usability Testing。
可用性测试是对“用户友好性”测试。显然这是主观，且将取决于目标最终用户或用户。用户面谈、调查、用户对话录象和其它部分技术全部可使用。程序员和测试员通常全部不宜作可用性测试员。
Q. 比较测试

比较测试，英文是Compare Testing。
比较测试是指和竞争伙伴产品比较测试，如软件弱点、优点或实力。来取长补短，以增强产品竞争力。
R. 可接收性

可接收性测试，英文是Acceptability Testing。
可接收性测试是在把测试版本交付测试部门大范围测试以前进行对最基础功效简单测试。因为在把测试版本交付测试部门大范围测试以前应该先验证该版本对于所测试功效基础上比较稳定。必需满足部分最低要求。比如不会很轻易程序就挂起或瓦解。假如一个新版本没经过可测试性验证，就应该阻拦测试部门花时间在该测试版本上测试。同时还要找到造成该版本不稳定关键缺点并督促立即加以修正
S. 边界条件

边界条件测试，英文是Boundary Testing。又称边界值测试。
一个黑盒测试方法，适度等价类分析方法一个补充,由长久测试工作经验得悉，大量错误是发生在输入或输出边界上。所以针对多种边界情况设计测试用例，能够查出更多错误。
边界条件测试是围绕边界值测试。通常意味着测试软件各功效是否能正确处理最大值，最小值或所设计软件能够处理最长字符串等等。
T. 强力测试

强力测试，英文是Mightiness Testing。
强力测试通常验证软件性能在多种极端环境和系统条件下是否还能正常工作。或说是验证软件性能在多种极端环境和系统条件下承受能力。比如，在最低硬盘驱动器空间或系统记忆容量条件下，验证程序反复实施打开和保留一个巨大文件1000次后也不会瓦解或死机。
U. 装配安装

装配/安装/配置测试是验证软件程序在不一样厂家硬件上，所支持不一样语言新旧版本平台上，和不一样方法安装软件全部能够如预期那样正确运行。比如，把英文版 Microsoft Office 安装在韩文版 Windows Me 上，再验证全部功效全部正常运行。
V. 隐藏数据

隐藏数据测试在软件验收和确定阶段是十分必需和关键一部分。程序质量不仅仅经过用户界面可视化数据来验证，而且必需包含遍历系统全部数据。
假设一个应用程序要求用户两条信息-----用户名和密码来创建帐户。这个用户输入这两条数据后保留。最终，一个确定窗口将经过数据库中找到这条数据来显示用户名和密码给用户。为了验证全部数据保留是否正确，一个QA测试人员会在这个确定窗口简单查看下用户名和密码。假如她们成功了？假设数据库统计了第三条信息----创建日期，它可能不会出现在确定窗口，而只在存档中才出现。假如创建日期保留不正确，而QA测试人员只验证屏幕上数据，那么这个问题就不可能被发觉。创建日期可能就是一个bug，因为一个用户帐户保留了一个错误日期到数据库中，这个问题也不可能会被引发注意，因为它被用户界面所隐藏。这只是一个简单例子，不过它却演化出了一点：隐藏数据测试关键性。
W. 等价划分

等价划分测试英文是equivalence partition testing。
等价划分测试是依据等价类设计测试用例一个技术。是黑盒测试经典方法之一，经过把被测试程序全部可能输入数据域划分成若干部分。从每一部分中选择少数有代表性数据作为测试用例，可有效降低测试次数，极大提升软件测试效率，缩短软件开发周期．等价类划分测试目标就是为了在有限测试资源情况下，用少许有代表性数据得到比很好测试效果。有效等价类和无效等价类。有效等价类中数据代表是一组符合需求文档正确有意义数据。无效等价类则正相反。
X. 判定表

判定表英文是decision table，是指一个表格，用于显示条件和条件造成动作集合。
定义：判定表是分析和表示多逻辑条件下实施不一样操作情况工具。
判定表优点：能够将复杂问题根据多种可能情况全部列举出来，简明并避免遗漏。所以，利用判定表能够设计出完整测试用例集合。
在部分数据处理问题当中，一些操作实施依靠于多个逻辑条件组合，即：针对不一样逻辑条件组合值，分别实施不一样操作。判定表很适合于处理这类问题
Y. 深度测试

深度测试英文Depth test ，是指实施一个产品一个特征全部细节，但不测试全部特征。
当比较函数返回真时候才显示出效果来。必需启用“#深度测试”，才能实施测试。不使用时候需要关闭。
Z. 基于设计

基于设计测试英文是design-based testing，是依据软件构架或具体设计引出测试用例一个方法。
一个基于设计模型测试方法(Model Based TestIng System,MATIS).该方法利用用户界面自动生成方法,把设计模型中类属性定义和实现中控件属性组织在一起,构建描述界面逻辑对照表,辅助测试脚本引擎实施自动测试脚本.借助设计模型中扩展类定义,MATIS方法能够自动生成测试用例和测试数据。
AA. 文档测试

文档测试英文是documentation testing，测试关注于文档正确性。
文档测试有三大类分别是开发文件、用户文件、管理文件。
1. 开发文件：可行性研究汇报、软件需求说明书、数据要求说明书、概要设计说明书、具体设计说明书、数据库设计说明书、模块开发卷宗。
2.用户文件：用户手册、操作手册。
3.管理文件：项目开发计划、测试计划、测试分析汇报、开发进度月报、项目开发总结汇报。
软件测试中文档测试关键是对相关设计汇报和用户使用说明进行测试，对于设计汇报关键是测试程序和设计汇报中设计思想是否一致；对于用户使用说明进行测试时，关键是测试用户使用说明书中对程序操作方法描述是否正确，关键是用户使用说明中提到操作例子要进行测试，确保采取例子能够在程序中正确完成操作。
通常来说，文档是软件关键组成部分，所以文档测试也是软件测试关键内容。在软件整个生命周期中会出现很多文档，通常能够把文档粗略地分为三类：开发文档,管理文档和用户文档。
因为文档和代码不一样，不能直接运行，对于文档测试通常只能以文档审查方法进行。对于管理文档和审查通常归属于管理范围，而不是软件测试范围,因为对于管理文档审查目标不是为了发觉和消除用户所看到软件中缺点，而是为了愈加好地管理软件开发过程。对于开发文档，因为这些文档本身表现了所在开发阶段软件实际形态，对于这些文档测试实际上是早期软件测试关键活动。用户文档是那些随程序一起交付给用户文档,它们实际上是交付给用户软件关键组成部分。对于这些文档测试是对最终软件产品测试一部分。
BB. 域测试

域测试英文是domain testing，定义参考等价划分测试（equivalence partition testing）；
通常分为单域测试和多域测试，其中单域测试包含设备测试和业务测试，设备测试包含测试某个系统软交换设备、中继媒体网关设备、信令网关设备、接入媒体网关和IAD等设备。
等价类划分有两种不一样情况：有效等价类和无效等价类。设计时要同时考虑这两种等价类，因为软件不仅要能接收合理数据，也要能经受意外考验。
一有效等价类：是指对于程序规格说明来说是合理、有意义输入数据组成集合。利用有效等价类可检验程序是否实现了规格说明中所要求功效和性能。
二无效等价类：和有效等价类定义恰巧相反。
CC. 接口测试

接口测试英文是interface testing，接口测试测试系统组件间接口一个测试。
接口测试好处：
因为接口测试代码本身就是用junit（当然接口类型不一样，不一定是Junit来实现）来实现，是属于自动化测试范围，所以肯定也包含自动化测试所固有优势。
1） 提升测试质量
软件开发过程是一个连续集成和改善过程，而每一次改善全部可能引进新bug,所以当软件一部，或全部修改时，全部需要对软件产品重新进行测试。其目标是要验证修改后产品是符合需求，而当没有自动化测试代码时，往往会因为多种多样原因，回归不充足，造成bug遗漏。
2） 提升测试效率
软件系统规模越来越大，功效点越来越多，开发人员自测或测试人员人工测试很耗时和繁琐，势必造成测试效率低下，而自动化测试恰好处理这些耗时繁琐任务，在对外接口功效不变情况下，达成了一次编写，永久使用效果。
3） 提升测试覆盖
经过手工测试极难测试到部分更深层次异常和安全问题，经过部分辅助部分测试工具，能分析出代码覆盖率，经过覆盖率提升来提升测试深度。
4） 愈加好地重现软件缺点
因为每次实施全部是相同代码，一旦代码犯错，肯定回归犯错
5） 愈加好定位错误
因为接口测试是一个自下向上测试，所以一量犯错，很轻易定位犯错，不向系统测试那样了，一旦有Bug，需要几层验证以后才能确定犯错位置
6） 降低修改bug成本接口测试基础和开发人员编码平行工作，所以发觉问题会比系统测试早很多，所以降低了修改bug成本。
7） 促进测试人员和开发人员之间合作关系，测试工程师为了愈加好地开展工作，需要对开发技术有深入了解和实践，有了和开发工程师更多交流。
8） 降低了项目不能按时公布风险因为接口测试很早就介入，在提交给系统测试前对项目代码关键模块已经做了详尽测试，肯定加速系统测试时间，由此来确保项目标按时公布。
9）提升测试人员技能。做接口测试必需了解开发人员开发步骤和部分开发技能，也需要了解测试工具部分使用方法和部分测试思想，提升了测试人员技术附加值，提升了本身竞争力。
10）促进项目开发过程规范化
要进行接口，需要完善文档进行保障，没有测试文档，接口测试将寸步难行，接口测试将增加开发过程规范化产出，而规范化产出也确保了项目质量。
DD. 逆向测试

逆向测试/反向测试/负面测试英文是Negative Testing，测试瞄准于使系统不能工作。
负面测试和正面测试比较：
负面测试（Negative testing）是相对于正面测试（Positive testing）而言。它们也是测试设计时两个很关键划分。简单点说，正面测试就是测试系统是否完成了它应该完成工作；而负面测试就是测试系统是否不实施它不应该完成操作。形象一点，正面测试就象一个毕恭毕敬小学生，老师叫我做什么，我就做什么；而负面测试就象一个调皮捣蛋孩子，你叫我这么做，我偏不这么做，而且和你对着干。开发人员也是最讨厌修改这类bug。
EE. 非功效性

非功效性需求测试英文是non-functional requirements testing ，是和功效不相关需求测试，如：性能测试、可用性测试等。
为何非功效性需求很关键？
在您设计处理方案过程中满足功效性需求当然是很关键。不过，假如没有考虑非功效性需求，您处理方案则极难取得实效。
非功效性需求特点：1.不要脱离实际环境；2.可靠性；3.可用性；4.有效性；5.可维护性；6.可移植性。
FF. 极限测试

介绍
极限测试本质上是为了满足极限测试思想和步骤而设计一套测试策略和步骤,其本身并不局限于使用特定测试技术和方法。
III. 软件测试基础步骤
测试需求分析，测试计划编写，测试用例编写，测试，缺点统计，回归测试，判定测试结束，测试汇报提交。
测试步骤依次以下：
1. 需求：阅读需求，一：单元测试、集成测试、系统测试和验收测试（确定测试）；
了解需求，和用户、开发、架构多方交流，深入了解需求。--testing team
2. 测试计划: 依据需求估算测试所需资源（人力、设备等）、所需时间、功效点划分、怎样合理分配安排资源等。---testing leader or testing manager
3. 用例设计：依据测试计划、任务分配、功效点划分，设计合理测试用例。---testing leader, senior tester
4. 实施测试：依据测试用例具体步骤，实施测试用例。--every tester(关键是初级测试人员)
5. 实施结果统计和bug统计：对每个case统计测试结果，有bug在测试管理工具中编写bug统计。--every tester(关键是初级测试人员)
6. defect tracking：追踪leader分配给你追踪bug.直到 bug fixed。--every tester
7. 测试汇报：经过不停测试、追踪，直到被测软件达成测试需求要求，并没有重大bug.
8.用户体验、软件公布等……
IV. 什么是缺点
一切不满足用户需求全部是缺点。
下面我们对缺点概念在具体介绍一下。
1、软件未达成产品说明书标明功效。
2、软件出现了产品说明书中指明不会出现错误。
3、软件功效超出了产品说明书指明范围。
4、软件未达成产品说明书中虽未指出但应达成目标。
5、软件测试员认为软件难以了解、不易使用、运行速度缓慢，或最终用户认为不好。
相关这 5点我们举例来说明一下。第一点，比如说我们开发一个记事本软件，说明书中明确说了能够输入文字，结果开发软件不含有输入文本功效，肯定就是一个 defect了。第二点，说明书中明确说了在记事本软件中输入“联通”能够正确保留并打开浏览，结果我们记事本软件打开保留了输入“联通”文件出 现了乱码，这也是一个defect了。第三点，比如说我们说明书中没有定义记事本会自动对关键字高亮显示（这个关键是针对编程语言），结果我们记事本程序自动对关键字高亮显示了，这也是defect，尽管这么对用户使用会愈加好，不过她超出了产品说明书中指明功效范围，所以还是defect。第四点 不太好说，所以就不用记事本举例了，原谅我，呵呵。比如在中国开发财务管理软件必需要符合财政部要求，尽管说明书中通常不会指出，不过软件必需要符合这个要求，不然是不能发行使用啊！第五点就好了解，因为测试员是第一个使用软件，必需要从用户角度来对待，尽管这里会有主观感觉，但还是要尽可能客观 （就是多参考部分标准，比如定义界面，检察易用性标准），比如在Windows下程序对话框中“是”按钮全部是在左边，“否”按钮在右边，假如发觉在 我们记事本程序中，提醒是否保留文件对话框里“是”按钮在右边了，这就是一个defect了，因为它不符合Windows下用户使用习惯。

知道了什么是缺点，我们就再来看看怎么去描述一个缺点吧，看看缺点全部有哪些属性。

二、缺点属性
(1)、缺点标识：就是缺点编号了，每个缺点有一个唯一编号。
(2)、缺点类型：这是一个功效性还是性能bug，是文档还是界面bug，还是当地化bug。
(3)、缺点严重