黑盒测试如何保证需求的覆盖度
黑盒测试的含义及特点
黑盒测试的含义及特点
黑盒测试是软件测试的一种重要方法，旨在评估软件系统的功能性。
与白盒测
试侧重于检查内部代码逻辑不同，黑盒测试只关注程序的输入与输出，旨在验证系统是否按照需求规范正确运行，而不考虑内部实现细节。
含义
黑盒测试是一种软件测试方法，测试人员仅基于软件规格说明书和需求文档来
测试软件系统。
在执行黑盒测试时，测试人员不了解软件内部实现细节，而是将软件视为一个”黑盒“，并通过输入数据来检查输出结果的正确性。
特点
1.独立性：黑盒测试与具体实现无关，只关心输出结果是否符合预期。
因此，测试人员可以在不了解内部结构的情况下进行测试，保持独立性。
2.功能导向：黑盒测试侧重于功能性测试，主要检查软件系统是否符
合需求规范和预期功能。
3.封装性：黑盒测试不关心程序内部的实现细节，可以适用于各种软
件开发阶段，如需求分析阶段、系统设计阶段等。
4.易懂性：黑盒测试依据功能性需求文档进行测试，易于理解和应用。
测试人员只需了解需求规范，而不需要深入了解软件内部结构。
5.覆盖面广：通过黑盒测试，可以从用户角度全面检查软件功能，确
保软件系统与用户需求保持一致。
总的来说，黑盒测试是一种独立于内部结构的功能性测试方法，具有独立性、
功能导向、封装性、易懂性和覆盖面广等特点。
通过黑盒测试，可以有效确保软件系统的功能性符合需求规范，并提高软件质量。
测试工程师的经验分享如何提升测试用例的覆盖率
测试工程师的经验分享如何提升测试用例的覆盖率测试用例的覆盖率是衡量软件测试质量的重要指标之一。
一个高效且全面的测试用例覆盖率能够帮助测试工程师发现更多的软件缺陷，并提供更准确的测试结果。
本文将分享一些提升测试用例覆盖率的经验，希望对测试工程师们有所帮助。
一、理解需求和设计在编写测试用例之前，测试工程师首先要深入理解软件的需求和设计。
对于需求的理解不仅包括表面的功能需求，还应该关注一些隐藏的需求、界面交互和系统运行逻辑等方面。
只有真正理解了这些关键要点，测试用例才能准确地覆盖到各种场景，从而提升覆盖率。
二、使用不同的测试技术为了提高测试用例的覆盖率，测试工程师可以采用多种不同的测试技术。
常见的测试技术包括黑盒测试、白盒测试、灰盒测试等。
黑盒测试主要关注软件功能的正确性，通过测试用户界面进行测试。
白盒测试则侧重于软件内部的结构和逻辑，通过测试代码进行测试。
而灰盒测试则结合了黑盒测试和白盒测试的特点。
通过灵活应用这些测试技术，可以更全面地覆盖软件的各个方面，提升测试用例的覆盖率。
三、考虑边界条件和异常情况在编写测试用例时，测试工程师需要特别关注边界条件和异常情况。
边界条件是指输入输出值的极限情况，通过测试这些边界情况可以帮助测试工程师发现可能存在的缺陷。
而异常情况则是指软件在异常输入或者异常操作下的响应情况。
测试工程师应该针对各种可能的异常情况编写测试用例，以确保软件在异常情况下的稳定性和可靠性。
四、组合测试用例为了提升测试用例的覆盖率，测试工程师可以将不同的测试用例进行组合。
通过对不同的功能场景进行组合测试，可以更全面地覆盖各种可能的组合情况，从而发现更多的潜在缺陷。
例如，对于一个复杂的软件系统，测试工程师可以将不同的功能模块进行组合测试，以验证整个系统的稳定性和一致性。
五、优化测试用例测试工程师在编写测试用例时应该尽量避免冗余和重复的测试。
如果某个测试用例已经覆盖了某个功能点，那么就没有必要再编写相同功能的测试用例。
怎么保证测试用例的覆盖率
怎么保证测试⽤例的覆盖率待总结..⼀、测试⽤例的切⾯设计 所谓测试切⾯设计，其实就是测试⽤例⼤项的划分。
测试⽤例划分的经典⽅法是瀑布模型，也就是从上到下，逐渐细分，⼤模块包括⼩模块，⼩模块包括更⼩的模块。
但仅仅如此是不够的，我们还要从更多的⾓度切⼊系统，从不同的⾓度把系统切分成⼀块⼀块的，来进⾏测试，从⽽确保测试⼤项的完整性。
1、功能点切⾯ 这是最常见的切⾯，通常我们认为页⾯上的⼀个按钮就是⼀个功能点。
然后我们可以根据功能的复杂程度，按每个功能；或⼀个功能点分多页；或多个功能点合成⼀页来进⾏⽤例的撰写。
2、特定切⾯ 除此以外，还有⼀种特定切⾯的划分⽅法，也是⽤例撰写时经常会⽤到的。
所谓的特定切⾯，就是忽略掉表⾯上的功能点，⽽关注测试对象的某⼀个⾯。
⽐如我们的内部管理系统提供了销售录⼊导⼊、注册录⼊导⼊等功能，从菜单划分上对应了七⼋个功能点。
但这些功能处理后台有个共同的处理项就是授权记录的⽣成，这时我们就可以把“授权记录⽣成”单独拿出来做⼀个测试项，⽽在其它测试项中涉及这⼀部分的⽤例就不必再⼀⼀撰写。
此外象⼀些界⾯共通的操作⽤例单独写成⼀页，也是⼀种特定切⾯。
所以如果说将⽤例按功能点划分是⼀种纵向划分法，那么特定切⾯就是从横向的⾓度分析所得到的切⾯。
在普通功能点划分上再根据实际情况设计特定切⾯，可以使我们的⽤例阅读性、理解性、操作性更强。
3、隐含切⾯ 这类⽤例是最容易被忽略的。
它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚⾄可能是在某种特定情形下的处理。
这都需要测试⼈员通过对软件的学习了解，来进⾏挖掘。
（1）、后台功能 常见的如⼀些定时⾃动启动的服务；以及某种特定情况下⾃动执⾏的操作等。
它们在界⾯上往往是不体现的，但许多在需求设计中还是会提到，也有⼀些⽐较细⼩的功能可能会被忽略，就需要测试⼈员根据对项⽬的了解程度来进⾏挖掘。
所以说⼀个熟悉项⽬的和⼀个不熟悉的测试⼈员，写出来的⽤例就完全是两个层次的。
黑盒测试方法
黑盒测试方法黑盒测试（Black Box Testing）是一种软件测试方法，它基于对被测试软件的功能需求进行测试，而不关心其内部的工作原理。
黑盒测试主要验证软件的功能是否符合需求，并检查软件是否能够正确地处理各种输入。
下面将介绍一些常见的黑盒测试方法。
1. 等价类划分测试（Equivalence Partitioning Testing）：将输入数据划分为等价类，并选择代表性的测试用例进行测试。
等价类划分测试的目的是减少测试用例的数量，节省测试时间和成本，同时保证测试覆盖度。
例如，对于一个要求输入年龄的软件，可以将年龄分为小于18岁、18-60岁和大于60岁三类，然后从每个类别中选择测试用例进行测试。
2. 边界值测试（Boundary Value Testing）：在等价类划分测试的基础上，选择特定的边界值进行测试。
因为边界值往往容易引起错误，所以边界值测试是一种重要的黑盒测试方法。
例如，对于一个要求输入0-100的分数的软件，选择0、1、99和100作为测试用例进行测试。
3. 错误推测测试（Error Guessing Testing）：基于经验和直觉，猜测可能存在的错误，并选择相应的测试用例进行测试。
这种方法常常依赖于测试人员的经验和专业知识，可以发现一些其他方法无法发现的错误。
例如，在一个购物网站中，测试人员可能猜测用户可能输入错误的邮政编码、信用卡号码等信息，并选择相应的测试用例进行测试。
4. 因果图测试（Cause-Effect Graph Testing）：根据输入和输出之间的因果关系，构建因果图，并选择代表性的测试用例进行测试。
这种方法能够帮助测试人员理清输入和输出之间的关系，从而提高测试覆盖度。
例如，对于一个需要输入用户名和密码的登录界面，可以构建因果图，其中考虑到用户名和密码为空时的情况、用户名和密码不匹配的情况等，然后选择相应的测试用例进行验证。
5. 边界值测试（GUI Testing）：验证图形用户界面（Graphical User Interface）的正确性和易用性。
银行新一代核心系统建设中 黑盒测试方法的覆盖性研究
银行新一代核心系统建设中黑盒测试方法的覆盖性研究本文基于银行新核心系统的特点及多种黑盒测试方法的优缺点，提出组合策略的方法解决系统测试覆盖性的痛点并进行了相关论述。
标签：核心系统;黑盒测试;覆盖性一、新一代核心系统简述在二十一世纪初期，许多银行的核心系统有很大比例的业务无法纯粹依靠系统进行完成，仍需要手工做账，无法做到办公信息化、电子化以及智能化。
这种纯手工或者半手工的方式大大的消耗了人力资源，并且还存在不小的操作风险。
现今随着云计算、区块链、物联网、人工智能等新鲜技术的不断涌现，近年来国内银行纷纷进行新一代核心系统建设，借鉴互联网企业的相关经验探索分布式IT 架构及构建企业级业务架构，旨在提高自身管理效能，提升管理效率以达到电子化、信息化和智能化办公。
无论对于哪家银行，核心系统的更新升级都是一项庞大复杂的系统工程，它具有建设周期长、成本高以及涉及要素面广等特征。
从需求分析到项目开发再到系统测试，都是系统建设中不可缺少的环節，本文着重研究系统测试这一重要环节，针对黑盒测试，研究其对于系统的覆盖性是否全面，旨在为新核心项目建设提供启示作用，能够进一步提高银行业核心系统建设水平并推动银行业信息化、电子化和智能化建设稳步向前发展。
二、黑盒测试方法简述黑盒测试也有另一个称法，叫做功能测试，顾名思义，它是测试系统中的每项功能是否正常运行。
所谓黑盒，也就是将系统看作一个无法打开的黑匣子，不考虑内部的结构也不考虑内部的算法，只关注系统的输入输出，核查系统功能是否按照其需求说明书来正确使用。
黑盒测试可以简单的分为划分等价类、边界值分析法、错误推测法、因果图法以及场景法等，不同的测试方法具有不同的测试特点。
划分等价类着重于输入数据的集合，边界值分析重点关注对于边界值的划分，错误推测依赖测试人员的经验和判断，因果图强调输入条件间的互相组合，场景法基于系统中的不同流程所组成的场景。
黑盒测试十分适合功能测试，核心点就在于对照需求说明书来测试系统相关功能，但黑盒测试的缺点也相应明显，它无法毫无遗漏的进行测试，同时系统中的一些bug或故障无法通过黑盒测试进行检测，黑盒测试主要依赖需求说明书的正确性，如果说明书本身有遗漏或者冗余，黑盒测试都无法进行甄别，这个问题也是黑盒测试的痛点，在下一节中会详细描述。
软件测试黑盒测试方法是什么
软件测试黑盒测试方法是什么在软件开发过程中，软件测试是一个非常关键的环节，其中黑盒测试方法是一种常用的测试技术。
黑盒测试是一种基于软件需求规格和功能规格进行测试的方法，而不考虑程序内部的结构和实现细节。
通过黑盒测试，测试人员可以评估软件的功能性、性能、安全性等方面，以确保软件符合用户需求并具有高质量。
黑盒测试的基本原理黑盒测试的基本原理是从软件功能和用户需求的角度出发，设计测试用例和测试数据，通过模拟用户的操作和输入，验证软件在各种情况下的功能是否正确。
在黑盒测试中，测试人员不需要了解软件的内部实现，只需要根据需求文档和功能规格进行测试，因此可以独立于开发团队进行测试工作。
黑盒测试的常用技术等价类划分法等价类划分法是黑盒测试中常用的一种测试技术，它将输入数据划分为若干个等价类，然后从每个等价类中选择代表性的数据作为测试用例。
通过等价类划分法，可以有效地减少测试用例的数量，同时覆盖各种可能的情况，提高测试效率。
边界值分析法边界值分析法是一种基于输入值的边界条件进行测试的方法。
通过测试输入数据的边界值和边界条件，可以检测软件在边界情况下的行为是否正确。
边界值分析法通常适用于数值计算、数据输入等情况下的测试。
因果图方法因果图方法是黑盒测试中一种用于分析和设计测试用例的方法，它通过构建因果图来表示软件的功能规格和输入输出关系，然后根据因果图设计测试用例。
因果图方法可以帮助测试人员更好地理解软件的功能逻辑，提高测试覆盖率和质量。
黑盒测试的优缺点优点1.不需要了解程序内部实现，独立于开发团队进行测试；2.可以从用户角度出发，更贴近用户需求；3.能够测试整体功能，验证软件的完整性和稳定性；4.可以提前发现潜在的逻辑错误和功能缺陷。
缺点1.只能覆盖指定的功能需求，无法检测程序内部的错误；2.需要准确的需求文档和功能规格，对测试用例设计要求较高；3.无法发现程序的性能和安全漏洞；4.测试覆盖率受限于测试用例设计的完整性。
白盒测试跟黑盒测试的区别是什么
白盒测试与黑盒测试的区别在软件测试领域，白盒测试和黑盒测试是两种常见的测试方法，它们在测试目标、方法和覆盖范围上有着明显的区别。
以下将介绍白盒测试和黑盒测试的区别。
1. 白盒测试白盒测试又称为结构化测试或透明式测试，是一种测试人员可以查看软件内部结构和源代码来设计测试用例的测试方法。
白盒测试通常由开发人员或专业测试人员执行，侧重于验证代码的逻辑覆盖和功能覆盖。
测试人员通过了解代码结构和逻辑，在编写测试用例时可以覆盖各个代码路径，以确保代码的质量和健壮性。
白盒测试的优点包括测试用例设计的精确性高、可以发现代码中的潜在缺陷、提高代码的覆盖率等。
但是，白盒测试也存在一些缺点，如测试人员需要了解代码结构和编程语言、耗时耗力等。
2. 黑盒测试黑盒测试又称为功能测试或规格测试，是一种测试人员只关注软件功能和接口等外部特性来设计测试用例的测试方法。
黑盒测试不需要了解软件的内部结构和源代码，而是根据需求规格和软件功能来编写测试用例，测试人员通过输入输出的方式验证软件是否符合预期行为。
黑盒测试的优点包括可以从用户的角度出发设计测试用例、测试人员不需要了解代码细节等。
但是，黑盒测试也存在一些缺点，如无法发现代码内部的逻辑缺陷、测试覆盖率不容易精确控制等。
3. 白盒测试和黑盒测试的区别•角度不同:–白盒测试从代码内部的角度出发，关注代码逻辑的正确性和质量；–黑盒测试从用户或外部系统的角度出发，关注软件功能和接口的正确性和质量。
•测试用例设计方式不同:–白盒测试设计测试用例时需要了解代码结构和逻辑，测试用例更加精准；–黑盒测试设计测试用例时只需根据需求规格和功能来设计，更加用户化。
•覆盖范围不同:–白盒测试可以覆盖代码的所有执行路径，但无法保证覆盖业务需求的完整性；–黑盒测试可以覆盖用户需求和功能规格，但无法覆盖代码的所有执行路径。
•适用场景不同:–白盒测试适用于复杂的业务逻辑、安全性高的系统、需要高覆盖率的场景；–黑盒测试适用于用户需求明确、功能规格明确、需要从用户角度验证的场景。
黑盒测试常用的测试方法有哪些
黑盒测试常用的测试方法有哪些在软件测试领域，黑盒测试是一种主要关注软件功能和功能性需求的测试方法。
黑盒测试不需要了解软件的内部工作原理，而是从用户的角度出发，测试软件是否符合预期的功能行为。
在进行黑盒测试时，测试人员主要关注软件的输入和输出以及其对用户可见的行为。
下面将介绍一些常用的黑盒测试方法。
等价类划分法等价类划分法是一种常用的黑盒测试方法，通过将输入数据划分为有效的等价类和无效的等价类来设计测试用例。
在等价类划分法中，测试人员只需选择一个代表性的输入值进行测试，从而减少测试用例的数量并确保测试覆盖全部可能的情况。
边界值分析法边界值分析法是一种针对输入值的黑盒测试方法。
该方法主要关注输入值的边界情况，通过测试边界值附近的输入数据来发现潜在的错误。
边界值分析法可以有效地发现输入值超出范围时引发的错误，提高测试的全面性和准确性。
因果图法因果图法是一种基于功能需求的黑盒测试方法，通过绘制因果图来表示系统功能之间的关系，从而设计测试用例。
因果图法可以帮助测试人员理清系统功能之间的逻辑关系，从而快速定位可能存在的缺陷，并设计有效的测试用例。
判定表驱动法判定表驱动法是一种结构化的黑盒测试方法，通过创建判定表来描述软件的各种输入情况和对应的期望结果。
测试人员可以根据判定表设计测试用例，覆盖各种可能的输入组合，确保软件功能的完整性和正确性。
状态转换法状态转换法是一种适用于有状态的系统的黑盒测试方法，通过建模系统的各种状态及状态之间的转换关系，设计测试用例。
状态转换法可以帮助测试人员识别系统在不同状态下的行为，确保软件在状态转换时能够正确地处理输入和输出。
综上所述，黑盒测试涉及多种复杂的测试方法，如等价类划分法、边界值分析法、因果图法、判定表驱动法和状态转换法等。
通过灵活运用这些方法，测试人员可以设计出覆盖全面的测试用例，发现潜在的缺陷，保证软件质量和可靠性。
黑盒测试方法的合理运用对软件开发过程至关重要，可以有效降低错误率，提高软件的可靠性和稳定性。
黑盒测试法定义
黑盒测试法定义黑盒测试法是软件测试中常用的一种测试方法，它是一种在不了解软件内部结构的情况下对软件进行测试的方法。
黑盒测试法着重于测试软件的功能和接口，而不需要了解软件的内部逻辑。
通过这种方法，测试人员可以从最终用户的角度来进行测试，从而确保软件能够按照用户需求正常工作。
黑盒测试法原理黑盒测试法的原理是根据软件规格说明或用户需求，设计测试用例来验证软件的功能是否符合预期。
在黑盒测试中，测试人员主要关注软件输入和输出之间的关系，以及软件对输入的处理方式。
通过设计一系列测试用例，测试人员可以检测软件的功能是否正常，是否符合用户的需求。
黑盒测试法特点1.独立性：黑盒测试法与软件内部结构无关，测试人员可以独立进行测试，无需了解软件的具体实现。
2.用户导向：黑盒测试法是从用户需求出发的测试方法，确保软件功能符合用户期望。
3.功能性测试：主要测试软件的功能是否正常，是否满足预期要求。
4.黑盒思维：测试人员需要站在最终用户的角度来设计测试用例，确保测试覆盖了用户可能的操作路径。
黑盒测试法实施步骤1.确定测试目标：明确要测试的功能和需求，编写测试计划。
2.设计测试用例：根据软件规格说明或用户需求，设计一系列测试用例。
3.执行测试用例：按照设计的测试用例，执行测试并记录测试结果。
4.分析测试结果：分析测试结果，查找软件功能的缺陷或不符合用户需求的地方。
5.制定修复措施：根据测试结果，制定修复方案并重新测试。
黑盒测试法应用场景1.软件功能测试：黑盒测试法适用于对软件功能进行测试，确保软件按照用户需求正常工作。
2.验收测试：在软件交付给客户之前，进行黑盒测试以验证软件是否符合客户需求。
3.系统集成测试：在软件不同模块集成后，通过黑盒测试法检查系统整体功能是否正常。
4.自动化测试：黑盒测试法也可以用于自动化测试，通过设计测试脚本来执行测试用例。
在软件开发过程中，黑盒测试法是一种非常重要的测试方法，可以帮助开发团队确保软件功能的正确性和完整性。
安全测试中的黑盒与灰盒测试方法
安全测试中的黑盒与灰盒测试方法安全测试是一种确保系统或软件在面对潜在威胁时依然可以正常运行的过程。
在进行安全测试时，黑盒测试和灰盒测试是两种常用的测试方法。
本文将介绍这两种测试方法的基本概念、特点和适用场景。
一、黑盒测试方法黑盒测试又称为功能测试，是一种基于需求和规格说明的测试方法。
测试人员在进行黑盒测试时，无需了解系统或软件内部的工作原理，只需关注其输入和输出。
1. 特点（1）测试人员无需了解内部细节：黑盒测试强调测试的功能，而不是依赖于程序的内部逻辑。
因此，测试人员不需要了解内部细节，只需通过给定的输入来验证输出是否符合预期。
（2）更加接近用户角度：黑盒测试更加注重系统或软件的外部行为，更接近用户的操作和使用方式。
通过模拟真实用户的操作，以确保系统在用户实际使用时的正常工作。
（3）需求覆盖全面：黑盒测试基于需求和规格说明进行测试，因此能够确保覆盖系统或软件的所有功能，并验证是否满足预期需求。
2. 适用场景（1）新系统或软件的测试：在系统或软件尚未完全开发完成之前，黑盒测试能够验证各功能是否按照需求工作，减少项目进展过程中的问题。
（2）无需关注内部细节的测试：某些测试场景下，可能没有必要了解系统或软件的内部工作原理，只需要验证其功能是否正常即可。
二、灰盒测试方法灰盒测试介于黑盒测试和白盒测试之间，既考虑了系统或软件的功能，也关注其中的一些内部逻辑。
测试人员在进行灰盒测试时，可以了解系统或软件的大致结构和一些内部代码。
1. 特点（1）部分了解内部细节：与黑盒测试不同，灰盒测试允许测试人员部分了解系统或软件的内部结构和代码，以更好地定位潜在问题。
（2）更具灵活性和准确性：灰盒测试既关注系统或软件的外部行为，也关注一些内部逻辑。
测试人员可以在确认功能是否正常的同时，通过探索内部细节和逻辑，发现潜在的安全漏洞。
2. 适用场景（1）部分了解内部结构的测试：当测试人员对系统或软件的内部有所了解，并希望结合内外因素进行测试时，灰盒测试是一个较为适合的方法。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
黑盒测试如何保证需求的覆盖度
如何保证需求的覆盖度？首先我们要明确这里提到的需求到底是什么。
在软件开发活动中，涉及到的需求有用户需求、系统需求、测试需求等。
用户需求：描述了用户使用产品必须要完成的任务，在软件开发活动中，属于最基本的需求。
系统需求：描述了软件设计人员、编程人员必须要完成的任务。
系统分析员通过分析用户需求，把用户的需求转变成开发设计人员看得懂的系统需求。
测试需求：描述了软件测试人员必须要完成的任务。
资深测试工程师通过分析系统需求，产生测试需求，作为测试活动的指导。
写到这里，我猜想命题人的本意应该指的是上面提到的系统需求，但我的观点认为，黑盒测试应该保证的是测试需求的覆盖度，系统需求的覆盖度应该由测试需求保证。
具体到这个题目来讲，只要涉及到度量，都会要求规范。
要度量需求，首先就必须保证需求本身是可度量的，这就要求需求必须明确、规范。
用户需求由最终用户提出，通常比较笼统，例如用户可能会这样描述其需求，
UR1 “能够上网缴电话费”
系统分析员的工作就是分析用户需求，把用户的需求转换成开发设计人员能够理解的系统需求。
系统需求从技术层面上对用户需求进行分析，把用户的需求分解成若干个功能点，例如
SR1 登录缴费系统
要求加密传输，密码不少于6位等
SR2 输入电话号码
要求验证号码的正确性
SR3 查询特定的电话费
查询结果中要包含各类明细
SR4 缴费
连接网上银行页面，要根据不同商业银行的网银，做不同的判断；
缴费结果一定要明确显示
… …
在测试小组参与后，资深测试工程师要根据系统需求，编写相应的用户需求。
用户需求一定要保证对系统需求的100%覆盖，即系统需求的所有功能点在用户需求中必须有所反映。
例如TR1-1 登录成功
TR1-2 登录失败
……
上述的TR1-1到TR1-2都对应于系统需求的SR1（功能点）。
测试工程师要编写测试用例，依据是测试需求，测试用例要保证对测试需求的100%覆盖，即测试需求的所有检查点在测试用例中必须有所提现。
例如
TCF1-1-1
输入用户名huior，对应的密码987654，以及验证码
预期结果：用户正确登录缴费系统，进入欢迎界面
TCF1-2-1
输入不存在的用户名huior_error，密码123456，以及验证码
预期结果：提示“用户名不存在”的错误，返回登录界面
TCF1-2-2
输入正确的用户名huior，密码123456，以及验证码
预期结果：提示“密码错误”，返回登录界面
TCF1-2-3
输入正确的用户名huior，密码987654，以及错误的验证码
预期结果：提示“验证码错误”，返回登录界面
… …
测试员在执行测试用例的过程中，会发现BUG，BUG可以和测试用例对应。
这样的话，软件开发的各个过程都可以对应起来。
有了这样的对应关系，黑盒测试对于需求的覆盖度就会很容易度量。
例如，测试员只执行了用例TCF1-1-1，只覆盖了TR1-1需求，假设系统需求中只定义了2个功能点，则
测试需求的覆盖度= 1 / 2 * 100% = 50%
实现
一般情况下，要成功的实施以上的过程，单单靠手工实现起来很难。
目前市场上已经有比较专业的工具来协助实现以上过程。
我原来听过一些产品的介绍，要完全实现以上过程，需要几个工具结合起来使用，例如DOORS + TD配合使用，就可以把以上四个过程对应起来。
不足
一个测试用例（例如输入10）就可以让逻辑覆盖率达到100%，但很明显，该100%并不能说明测试已经很充分。
同样，黑盒测试对于需求的覆盖度量只能作为一种参考。
例如，以上的例子中，假如测试员执行了用例TCF1-1-1和TCF1-2-1 ，则覆盖了TR1-1和TR1-2的需求
测试需求的覆盖度= 2/2 *100% = 100%
很显然，虽然需求已经全部覆盖，但测试还不充分，还远不能结束。
所以我的结论是黑盒测试对于需求的覆盖度量只能作为一种参考，不能以此来衡量测试的优劣。
以上文字仅代表个人观点。