基于小型银行系统的软件测试

　　1986年以来软件工程已经提出了近40年。可以说，它已经从“婴儿期”到“青年期”。软件工程的理论、方法和技术日新月异，软件测试的理论、方法和技术层出不穷。但是，困扰软件开发和软件工程研究的每个人都存在着一些问题：这些软件测试方法能否有效地保证软件测试的顺利、高效地完成？它真的能保证测试软件的质量吗？

　　软件测试是软件质量保证工程的重要组成部分，从软件质量的角度来看，它是最关键的韵律质量保证方法。从软件开发瀑布模型的角度来看，这两个测试也是一个非常重要的工程阶段。为了保证所设计软件产品的可用性和可靠性，必须对所开发的软件产品进行系统全面的测试。基于这种需求，软件测试被视为软件开发过程中的一个重要阶段。软件界普遍强调这一点，并试图探索更完善的测试理论、技术和方法。

　　然而，随着软件技术的不断发展，以及软件系统的规模和复杂性的不断增加，软件测试已经不能满足传统组织理论和技术在软件质量、开发成本和开发周期等方面的需求。特别是在银行业，国家银行业每年投入大量人力和物力，创造新的制度，改造旧体制。这些系统已经被许多软件开发人员建立起来了。然而，由于软件工程方法效率低、可操作性差、缺乏系统性，使得软件开发商很难适应银行系统的复杂性，造成成本高、风险高、周期长。所有这些都严重影响了他们的利润率，也增加了银行的投资成本。

　　在软件开发过程中，软件测试在开发成本中占有很大的比重，通常超过40%。有效解决银行业务软件测试问题，降低软件测试成本，提高软件测试质量，对银行和软件开发人员都有好处。因此，针对银行业务软件的特点，有必要研究有针对性的软件测试方法。降低银行软件开发成本，提高软件开发人员的利润率。二是提高银行软件系统的可靠性、健壮性、可扩展性、正确性和性能，以更好地服务于社会。

　　软件测试直接关系到软件的质量，软件测试是保证软件质量的关键。这是许多人很容易理解的一点。

　　在银行业务软件的开发过程中，存在着投资高、周期长的软件开发现象。这是因为与普通的软件系统相比，银行业务软件有其自身的特点。这些特点决定了银行业务的测试在侧重点、评价指标和通用软件测试方法等方面都不同于一般的软件测试。要充分了解银行业务软件的测试，首先要认识到银行业务软件的特点。

　　银行业本身就是一个非常特殊的行业。银行业务软件作为银行业务的一种工具，与一般的软件系统有着不同的特点。

　　（1）大规模

　　银行软件，特别是核心银行软件程序，其数量通常在数千、几万以上；平均行数甚至几万行代码；总人数占软件开发总人数的十万以上；人工输入需要100年以上。

　　银行商业软件背后的数据是惊人的。在数以百万计的银行账户，数百万人每天数万；每次交易的银行都要求有详细记录对应的邮政储蓄银行，规模比较小的情况下，一个地级市的每日交易量高达数千笔数，这也意味着，每一天至少有几十名的详细记录。一天数以万计的记录每年能达到数百万笔。更重要的是，银行系统的数据是不允许清理的，而且数据量是可以想象的。

　　当软件规模达到一定程度时，对软件开发的技术和管理是一个严峻的考验。

　　（2）复杂业务

　　银行业务种类繁多，如基本储蓄业务、公共业务和后来的中间业务，从几百家到几百家。

　　例如每个业务复杂，之间的关系，现在多种中间业务，大部分储蓄业务支持的核心要求，因为中间业务本身不能修改储户的账户，必须通过储蓄业务修改界面，这意味着在新的中介服务业将导致储蓄业务的变化。

　　（3）事务多样性

　　在银行的商业软件中实现一个完整的函数称为事务。根据交易的不同特点，对交易进行了不同的划分。

　　根据交易的响应时间，它分为在线交易和大宗交易。在线交易需要很短的响应时间，一般要求控制在5秒之内。例如，一般柜面业务属于在线交易，而响应时间不需要大宗交易，主要用于大数据量的批量处理，如银行在夜间的总成绩检查。

　　事务多样性增加了系统的复杂度，增加了程序的逻辑复杂度，增加了软件测试的难度。

　　（4）应用独立性

　　一般来说，银行业务软件是为满足银行业务需求而开发的应用软件，它不同于系统软件。银行业务软件的开发只需要关心业务处理，而不需要关心数据存储、网络通信、安全控制等底层细节。这是因为银行软件通常是在交易平台上运行，如CICS，燕尾服，和曾经流行的热塑性弹性体。实际交易平台中间件的一种，其作用是隔离应用程序和底层的处理系统，如数据存储、网络通信、安全控制、进程调度，应用程序的开发变得相对简单，只需要关注业务逻辑，但也增加了银行软件的可移植性。

　　银行业务软件的应用独立性大大降低了测试工作量，在实践中不必对系统底层的系统进行测试。

　　(5)要求严格

　　银行业务软件的开发要求是非常严格的，尤其是安全性和计算准确性这方面。比如，利息计算，要求在计算过程中保留小数点后三位，最终计算结果保留小数点后两位。

　　银行业务软件对于输入输出都有明确的规定，所以测试中对输入输出的检查也是十分严格和明确的。

　　(1)实用性

　　实用性是指当规范允许运行时，一个正确的软件满足用户需求的程度。因为银行软件的开发大多是基于定制开发的。发展的基础是特定用户的需求。正确开发银行软件必须满足用户需求。因此，没有必要怀疑银行业务软件的实用性。

　　（2）可靠性

　　可靠性是衡量软件故障的频率和严重程度的一个标准。故障是指软件在允许的操作条件下运行时产生的不可接受的结果或行为，而故障通常是由问题引起的。软件的可靠性可以通过故障的频率和故障造成的损害程度来衡量。损伤程度可以通过修正问题的时间和损伤结果的修复时间来度量。

　　银行软件要求高可靠性。如何保证其可靠性，如何评估其可靠性，是银行业务软件测试中值得研究的问题。

　　（3）正确性

　　如果在允许的条件下运行的软件能够满足输出规范，则称为正确的软件。换句话说，如果软件具有满足输入规格和软件所需的所有资源，并且最终输出与输出规范一致，则称之为软件。

　　正确性是银行软件测试中应用最广泛的度量标准之一。因为银行软件的一个特点是对每个功能的输入和输出都有要求。这个要求甚至更详细地描述输入和输出数据的类型、长度和位置。

　　（4）鲁棒性

　　健壮性是指软件在异常情况下正常运行的能力。正确性描述了软件在需求范围内的行为，而健壮性则描述了超出需求范围的软件行为。鲁棒性包含两层含义：一是容错，二是恢复能力。

　　（5）可扩展性

　　可伸缩性反映了软件适应“变化”的能力。在软件开发过程中，变更包括需求的变更、设计的变更、算法的改进、程序的变更等。由于本文中没有讨论设计和编码，所以假定设计和编码都是正确的。这里要讨论的主要问题是需求的变化。需求的变化是否得到了一定的衡量标准，本文所讨论的需求变化都是要处理的。软件的可伸缩性可以通过需求变更的影响范围和处理时间来度量。

　　以上对银行业务软件的行为特性的分析，将为银行业务软件测试的评价提供很好的依据。

　　由于银行业务软件具有交易多样性，对应的测试也具有多样性。在实际应用中最多的就是联机测试、批量测试和压力测试。

　　1.3.1联机测试

　　在银行业务中，网上交易占总开发额的一半以上。网上交易是直接与用户交互，因此对用户操作的响应时间要求较高，一般要求3-5秒回应；网上交易由于时效性要求、输入和输出数据一般较少；网上交易数据修改小，如存款交易只修改客户账户余额和其他个人项目。而网上交易是银行业务数据的来源，因此网上交易的正确与否直接关系到银行账户是否正确。

　　（1）界面严密性

　　银行业务不需要接口有多漂亮，但它必须要求接口的基本元素是完整的，并确保高效的输入和输出。银行业务的网上交易具有明确的输入和输出要求，因此在线测试首先必须测试输入和输出是否符合要求。例如，个人储蓄账户需要输入客户的姓名、文件类型、文件编号，每个输入最多可以输入多少个字符、数字或字符，如果小数位数、整数、输出数；需要打印书籍、打印、打印哪些内容在什么位置的书，这些都是明确要求。

　　（2）数据容错

　　对于所有的软件来说，容错是必不可少的，它直接决定了软件的健壮性。银行业务有明显的错误输入数据，甚至是提示符的顺序。

　　（3）对及时性的反应

　　网上交易具有响应时间短、并发数大的特点。因此，当对在线事务进行测试时，响应时间必须控制在一定范围内（通常为5秒）。如果响应时间过长，则会降低系统的吞吐量。二是可能出现超时，容易受到外部干扰。三，它会给用户一种系统不稳定的印象。这些都影响系统的正常运行。想象一下，如果一个点一天有1000笔交易，如果不能保证响应时间在5秒，但30秒，交易量，一天要六天才能完成，这只会导致储户大量滞留在网点和最终导致储户的损失，这是任何一个银行企业都不愿意看到的。

　　除了测试单个事务执行的响应时间之外，响应时间测试更多地是测试大量事务并发执行的响应时间。由于系统实际运行，很少单独执行单事务。

　　（4）处理正确性

　　正确的处理是每个功能的核心。处理正确性的基础是需求规范和详细说明。它被认为是正确的，以满足要求的规格和详细的指示。事实上，检查处理的正确性实际上在一定程度上涵盖了数据容错检查，还包括数据处理、数据存储和输出处理。

　　1.3.2批量测试

　　批处理是在线交易的区别。批量处理和网上交易是银行业务软件的两个重要组成部分。联机事务通常用于交互的给定请求处理用户，并记录数据，例如储户帐户的分支、处理请求的帐户事务、分发帐户、生成分类帐和打印存款单和存折。在线交易的数据修改量很小，在晚上的数据处理更加（或业务是自由时间）批处理完成，包括一天结束的时候，在今年年底，推出了利益的冲动和总帐核对，业务报告，以处理大数据量的处理，处理时间，无需人工干预，通常需要一个小时到几个小时。

　　批处理主要由数据备份和恢复、数据处理和报表生成组成，并对三部分进行相应的批处理测试。上述在线测试需要验证处理，实际上处理很大程度上是正确的数据在线批处理检查，例如，通过查看批量生成总检查报告确定是否在线交易记录的错误现象存在不平衡帐户。由于批处理不是响应时间所必需的，批处理测试的重点是数据处理的正确性。当然，可以批量处理的时间毕竟是有限的。

　　总之，批量测试的重点是两点：数据处理的正确性和处理性能。

　　1.3.3压力测试

　　压力测试是模拟用户实际应用和系统负载的软硬件环境。利用长期测试软件对被测系统的可靠性进行了测试，并对测试系统的响应时间进行了测试。由于数据量大、运行时间长，应力测试难以满足要求。此外，加工正确性和结果的输出不是测试重点，因此压力测试大多是通过测试工具完成的。

　　应力测试主要由数据准备和执行测试组成。由于压力测试基本上是模拟实际应用环境的，所以必须事先准备背景数据，数据量应与实际应用环境中的数据量相当。最常见的做法是直接将真实数据直接用于压力试验的背景数据。

　　压力试验仍分为在线压力试验和间歇压力试验。在线压力测试主要分为最大事务并发性测试和特定事务并发响应时间测试。最大事务并发性测试是在特定环境中可以执行的事务数，或在单位时间内可以完成的最大事务数。最大事务并发测试的结果将决定新的银行业务软件是否满足实际在线运行处理能力的最高要求。例如，基于历史运营数据库的预测，五年内最大的事务并发性将达到20，如果新软件只能达到15笔，则不符合要求，必须重新设计以满足整个或部分软件的要求。对某些事务并发性的响应时间测试是保持某些事务中并发性的程度，例如每秒10次，以及测试事务的响应时间是否满足要求。

　　体积压力试验主要是测试程序的效率。这是对大量数据的测试。通过后台数据，将需要处理的数据量达到一定的水平，并对批处理的处理时间进行测试。当然，在线压力试验和间歇压力试验也可以联合进行。

　　上述在线测试、批量测试和压力测试是银行业务软件开发中应用最为广泛的三个测试环节。此外，还进行了安全测试、前端测试、网络通信测试、数据迁移测试等。因为它不适用于所有的银行业务软件开发项目，所以我们不会讨论这个问题。

　　银行系统测试就是要在软件投入运行前，对需求分析、设计规格说明和编码的结果进行审查，是质量保证的关健步骤。软件测试是根据开发各阶段的规格说明和程序的内部结构而精心设计一批用例（即输入数据及其预期的结果），并利用这些测试用例去运行程序，以及发现程序错误的过程。

　　我们所设计的测试是层次化测试模型，但是不管什么样的模型我们始终都围绕着软件测试的基本步行着。图2-1是软件层次化测试流程图。

　　图2-1软件层次化测试流程图

　　金融业务分析基本上是数据处理，银行系统中数据分析的四种操作是视图、增加、更改和删除，这与系统数据库存储的操作相对应：查询、插入、更新和删除。数据是业务处理的来源。业务流程的准确性与数据的正确性密切相关。如何准确地处理数据将影响前台业务逻辑能否准确实现。这与软件数据处理的特定名词相关：数据库处理。如果它不是精确的数据处理，它也是软件测试中最重要的部分。软件系统测试越早越好。它不仅是对系统功能的测试，也是对系统编码的测试。从另一个角度看，程序编码的质量决定了系统功能测试的工作安排。测试不仅是对软件系统的功能，更需要从基础条件本身的测试系统，不仅保证了软件编程的正确性，也保证了软件的可靠性和健壮性：软件解决方案，在任何情况下都是一定的，即使软件在即将崩溃的状态。所以总体设计测试在这个时候起了作用。当然，这一层不仅要检测隐式编程问题，更重要的是对软件系统的健壮性和可用性测试，包括：解决系统中的异常数据库还没有集成，软件故障是不能使用恢复机制来保证软件正常运行的。确保系统中使用的并发用户的软件的高可靠性等的能力。

　　通过层次分析软件测试的好处是使每一层都具有相对独立的功能。层次结构也有利于沟通、理解和标准化。分层测试设计的问题是每个层的功能模块必须清晰，相互独立。当一个否认实现方法的一个层被改变时，如果你能保持彼此的水平界面不改变，就不会影响相邻的层次；每个层次的边界必须是清晰的，跨边界的信息量应该尽可能少，并且所有级别都应该是适度的数量。如果层数太少，单一层次的内容过于复杂。如果层数太大，整个系统结构过于复杂，使得各级功能模块的设计变得困难。将层次化思想应用于软件测试，生成软件测试的层次模型。在软件分层的实现中，以下原则应基于以下原则：

　　1）对模块的功能进行抽象和分层，明确定义单个层次的功能。

　　2）在任何级别上的功能的选择都可以灵活地标准化。

　　3）不同的系统被划分为同一级别，同级级别具有相同的功能。

　　4）当高级服务使用下层时，下层服务的实现是不可见的。

　　5）级别的数量应该是适当的，级别太少，层次结构太大。

　　3.1.1单元测试优点

　　单元测试，即代码级测试，向测试人员提供输入数据和输出数据。设计者会发现有趣的输入数据和条件，从而产生有趣的输出结果。

　　关键测试：测试程序可以部分地测试程序部分。通过测试代码，将感兴趣的测试数据输入独立模块，然后立即报告模块获得的中间结果，并对可能存在问题的模块进行彻底测试。

　　测试覆盖率：测试人员可以找出程序的哪些部分经过测试，并找到哪些代码、分支或路径尚未测试，这可以增加对未测试区域的测试。控制流：测试人员知道程序的下一步会做什么，就像它当前状态的功能一样。它可以修改程序，让它总是报告它正在做什么，或者使用一个叫做调试器的特殊程序来运行被测试的程序，然后跟踪代码行的执行。当程序误入歧途时，测试人员可以立即判断它。

　　数据完整性：测试人员知道程序的哪一部分将修改数据项，可以发现数据不合适的操作模块，也可以在程序中编写一个特殊的代码来计算一个测试变量的位置值和实际值，并进行比较，如果有错误报告。

　　内部边界：测试人员可以在内部边界看到代码，比如外部测试人员是完全看不见的，程序可以根据形态学参数（自由度）小于或大于100，并使用不同的计算方法来估计x2函数的值。其他程序在快速读取大量数据时，可能将数据放入临时存储空间，这会迫使内存或处理时间溢出，然后观察程序处理临时存储的强度。

　　在不断变化的测试阶段，单元测试是一种非常有效的测试方法，是软件测试周期中最重要的测试方法。因为考虑到公司的成本，检测到的软件问题越早，单元测试粒度就越好。它有助于减少调试和修复错误的难度，并从这方面降低软件问题修复的成本。同时，增强的单元测试也可以减少软件周期中集成测试和系统测试的压力。

　　3.1.2测试方法

　　在介绍了单元测试的优点之后，我们将对单元测试的方法进行跟踪。在我们的单元测试策略中使用的是硒和数据库测试，自动测试框架硒是一个开源Web，它帮助我们实现单元测试，使用JavaScript进行整个测试过程管理，包括读取测试套件、执行测试和记录测试结果。它使用JavaScript单元测试工具来模拟真实的用户行为，JSUnit为核心，包括浏览页面，点击链接，输入文字，提交表单，触发鼠标事件，等等，并能够验证各种页面效果。也就是说，只要在测试用例中描述了用户行为和结果，我们就获得了一个自动化测试套件的功能来运行它，并通过浏览器通信将信息发送到浏览器执行测试用例，从而达到自动测试的目的。数据库测试是我们验证系统中SQL的方式。

　　例如，银行账户管理系统，客户数据处理的核心，所以数据库处理能力很高，每个银行的交易，结算利息，需要准确、快速地返回到数据库，数据库系统显然是重要的，我们使用硒编写测试脚本和脚本与数据库交互。通过这种方法保证了业务流程银行的准确性、高效的数据库数据处理能力，并利用测试脚本实现了同一代码在不同数据源条件下的往返、查询、更改、删除等功能。

　　事实上，业务流程测试是为了确认银行软件功能和过程的正确性，即确认测试，确认测试是严格遵循相关标准的符合性测试，以确定软件产品是否符合规定的要求。如果达到这个要求，开发的软件被认为是合格的。因此，验证测试有时被称为资格测试。所谓需求是指软件需求文档中定义的软件功能和技术指标，或者专门为软件测试而设计的验证测试规则。在软件测试中，软件的所有功能都要根据软件需求进行测试和验证。重点检查软件是否正确，实现测试软件需求文档中指定的功能，并判断内部输入和外部输入是否异常。

　　这一层是测试软件测试过程的核心部分，它所需要的资源和时间在软件测试非常多，找到错误是最关键的，也是关系到项目的成败，如果虫子太多水平的试验发现，前两层不在返工的可能性比较大。这个阶段也是对产品功能的最后检查。所有错误必须在这个阶段解决，不能留给下一级测试。为了确保符合这些标准的测试必须有准确的测试用例，测试的目的是发现软件缺陷和不符合规定的地方，所以我们必须要设计一个好的测试用例的选择，测试数据准确，并根据银行业务的过程中，一多种系统环境下，所有可能的测试条件的遍历，查看测试结果，验证了系统软件能给出正确的输出。

　　为了改进软件测试过程，我们必须进行有计划的测试。测试用例是最重要的。编写测试用例是通过实际操作证明测试点的功能点和业务实现。在对关键点进行测试时，应从正面和负面两方面着手，不仅要证明软件系统在正常情况下的响应，而且要证明软件系统在异常情况下也能正确处理。对于最苛刻的测试，我们应该考虑到各种可能性。对于非主要需求，测试用例可能不太合适，但最低需要有两个方面：正面和负面。

　　如表3-1所示，每个区域都在一个特定的测试需求明确的软件接口的上市，对我们类型与搜索屏幕搜索标准的基础上，每个领域的每个区域的记录是否对应的编辑框的内容是不是没有价值的数据，内容和顺序检查下拉列表的区域不匹配的需求和文档的软件要求，因为只有SQL搜索链接接口测试，不会影响SQL数据变化，所以这一举措是理想。

　　表3-1测试实例

　　从操作方便的输入数据，并确认系统检查输入数据的有效性；中断执行的功能，确认是否可以取消在行动之前，要求完成；具有还原能力（事务回滚能力）功能，确认他们是否完成后，包括参数设置在行动中撤回；函数的参数选择，确认是否有默认值；要求对信息的解释，确认他们是否有明确的要求；与接口能力的界面元素，以确认他们是否是有效的；需要的功能和操作的容错性，确定风险，系统会提示错误可以很容易地纠正错误，输入是否能从错误中恢复；功能和操作有能力自定义确认有效性的自定义能力。

　　图层测试模板，我们设计如下：

　　单引号操作：当用户存储包含英文单引号的信息时，大多数基于SQL的数据库系统都会出现问题，因此每一个可以接受文本数字类型的项目都必须有一个包含一个或多个单引号的文本框。当然，这种问题也应该包括特殊的字符，如英语双引号，和，<，>。在测试中，我们要注意错误操作之前的提示和恢复和补救措施。

　　要求的输入测试：测试指出，屏幕上的屏幕上的指令和每个字段上的输入数据的每个函数都必须输入，以确保在字段中输入数据是强制性的。如果没有提示和后续操作来输入相关数据，则进行测试。

　　特殊字段类型测试数据输入：对每个功能规范或接口要求（ID、日期、电话号码、邮政编码）字段进行特殊测试，包括不应接受数据类型的输入数据、错误输入提示测试软件和后续操作；

　　字段长度测试：为函数规范或接口所需字段的最大长度准备测试用例。输入数据应该大于这个最大长度，并且测试软件用于提示和随后的错误输入操作。

　　数值类型的边界测试：如果它是数字类型，长度不能总是测试问题。我们应该编制数值类型的边界值测试用例，验证软件对边界错误输入值的处理和后续响应。

　　3.4.1压力测试

　　银行软件系统压力测试的第一个重要数据是除了已公布的损失外，银行的潜在潜在损失。扣除上述银行现有资本和未来两年利润的潜在损失。结果是压力测试的第二个重要数据，一个测试用例在我们的系统中。

　　一年的集中交易量在8个月内完成，每天20个工作日，每天8小时；80-20原则，每个工作日80%次营业20%次，每80%小时营业1.6小时；估计结果为测试压力：

　　去年约100万笔业务，业务处理每15%个提交给应用服务器的7个请求；每70%个业务处理要提交给应用服务器的5个请求；每个业务的其余15%的业务向应用服务器提交3个请求。根据以往的统计结果，年营业增长率为15%。考虑到未来三年业务发展的需要，测试需要进行2倍于现有业务量。

　　每年的请求总数是：（100*15%*7+100*70%*5+100*15%*3）*每年2＝3亿。每天的请求数是：300/160=187万5000/天。每秒请求数为：（18750×80%）/（8×20%×3600）＝2.60次/秒。在正常情况下，应用服务器的处理请求的能力应该达到：每秒3次。LoadRunner是用来比较一年的压力测试，结果显示如图3.1所示：

　　图3.1压力测试结果

　　3.4.2网络攻击测试

　　虽然外界很难确定银行计算机网络是否在系统安全和信息安全方面受到黑客的攻击，但银行却遭到了网络攻击。

　　我们采用了银行帐户管理系统。

　　首先，源IP地址欺骗测试：如果数据包通过路由器到达端点，而响应包也可以返回源，它是源IP地址有效，这是源IP地址欺骗攻击的前提。假定在同一段中有两个主机A、B，另一部分中的主机X。B赋予某种特权，A.为了获得相同的权限，X进行欺骗攻击如下：首先，X扮演和发送一个SYN包与一个随机序列号的主机B的主机B响应一个应答包，这等于原序列号加1。然而，此时主机X已被拒绝服务攻击的主机X“淹没”，导致主机服务失败。因此，主机A丢弃了B发送的分组，以完成三次握手，X也需要向B发送一个应答包，其响应数等于B加1发送给a的分组的序号。此时，主机X无法检测到主机B的数据包（因为它不在同一网段中）。我们只使用TCP序列号估计来预测应答包的数量并将其发送给目标B。如果猜测正确，则B认为接收的ACK来自内部主机A。此时，X获得主机A在主机B上享有的特权并开始攻击服务。

　　第二，使用加密方法：在数据发送到网络之前，我们可以加密它。虽然加密过程需要对当前网络稍加修改，但它将确保数据的完整性和真实性。

　　第三，路由器可以进行配置，使其能够拒绝网络外部同一IP地址的连接请求。此外，当包的IP地址不在这个网络中时，路由器不应该将主机的包发送到网络。需要注意的一点是，路由器可以阻塞试图到达内部网络的特定类型的包。但是它们也通过分析测试的源地址来执行。因此，它们只能过滤来自内部网络的外部数据包。如果您的网络具有外部受信任的主机，则路由器将无法阻止其他人冒充IP欺骗这些主机。

　　3.4.3数据溢出测试

　　我们需要解决的是数据库截断或异常程序溢出问题，主要用于处理程序的字节长度可以发现小于输入的字节长度，加工长度溢出，两界面之间的长度截断或者数据库异常问题导致不一致的问题；我们所采取的方法是输入最大数或人物提交允许输入界面，看到处理和数据库是正常的，通过测试方法如表3-2：

　　输入项目测试场景测试结果

　　测试用例程序可以处理的字节长度小于输入字节长度，导致程序在处理时候返回数据异常或程序出错的bug通过id搜索字条功能，可输入12位，所以输入12个9后页面没有返回正常搜索而是出现异常返回信息，经确认发现是处理长度只有4个字节

　　数据库目标字段小于输入允许长度,输入字段在数据库被截断或数据提交异常的bug前台提示允许输入2000中文字，但输入2000个后页面提交，页面返回null，经确认原来数据库中字段允许长度只有500个字

　　输入接口小于输出接口在前台的佣金项输入最大允许输入项n个9，提交服务后Account接口处理这一环节出错预扣佣金失败，代扣接口最大处理金额是m(n个9远大于m)，远远小于我们允许输入金额

　　3.4.4异常恢复测试

　　一个系统必须是容错的，也就是说，运行过程中的错误并不能阻止整个系统的功能。在某些情况下，软件系统缺陷需要在适当的时间内加以纠正，否则会造成严重的损失。

　　恢复测试最重要的是验证软件系统的容错性。例如，当一个软件系统有一个异常时，它不能在指定的时间内恢复并重新运行系统。恢复测试首先需要不同的测试方法，迫使软件系统出现异常，从而使观测系统尽快恢复。对于自动恢复，我们需要验证初始化、测试点、数据恢复和重启的正确性。对于人工回收系统，我们需要预测维修时间并确定客户是否在可接受的范围内。

　　在这些底层代码中检测到非常严格的运行时错误，但它们不能或不应该试图自己处理这些错误。解决这些严格的运行时错误的责任应该由高端组件来完成。为了解决错误，必须通知高端组件的错误。本质上，错误处理包括对高端组件的错误检测和通知。这些组件依次处理错误，并试图从错误中恢复。

　　我们知道，异常通常是从底层向上捕获的。异常越深，异常处理的次数就越多。在我们的系统异常处理中，我们使用以下方法：

　　#include<stdexcept>

　　#include<iostream>

　　using namespace std;

　　int main()

　　{

　　try

　　{

　　char*buff=new char[100000000];

　　//…use buff

　　}

　　catch(bad_alloc&alloc_failure)//bad_alloc is//derived from exception

　　{

　　cout<<"memory allocation failure";//…handle exception thrown by operator new

　　}

　　catch(exception&std_ex)

　　{

　　cout<<std_ex.what()<<endl;

　　}catch(…)//exceptions that are not handled elsewhere are caught here

　　{cout<<"unrecognized exception"<<endl;

　　}

　　return 0;

　　}

　　派生层次越深的handler必须出现在其基类的前面。这是因为handler的匹配过程是按照出现的顺序进行的。因此有可能某个handler永远不会被执行，例如，把一个处理派生类异常的handler放在处理基类异常的handler的后面。例如：

　　(std::exception&std_ex)

　　{

　　//…handle the exception

　　}catch(std::bad_alloc&alloc_failure)//unreachable

　　{cout<<"memory allocation failure";

　　}

　　软件测试是软件开发过程中不可分割的部分，它在软件的强壮和完善中起着决定性的作用。但是因为多年来根深蒂固的观念，很多单位对于测试重视不够，软件测试存在次序混乱、流程不规范、覆盖范围小的缺点，为了提高软件测试的的性能，本文在介绍了银行软件的特殊需求后，借助通信网络分层的概念，提出了层次化测试的概念，对多层次的软件测试进行认真细致的研究，我们所做的工作和得到的成果如下：

　　1、深入浅出地研究了软件测试的传统模型，给出了软件测试的多种基本的流程图，并详细介绍了这些传统测试模型的优点和缺陷。通过对比得出，银行软件测试出于健壮性和安全性的强烈要求，必须采取改进的软件测试方法。

　　2、为了克服传统软件测试方法的缺点，借助通信网络分层的概念，提出用分层方法控制软件测试的弊端，该测试方法对银行运用的软件采用不同层次的测试，每一层和下一层都是包含和铺垫的关系，减少了重复工作，逐层实现BUG的减少。实际的工作结果表明，层次化测试法具有提高效率、覆盖面广的效果，它可以取得与以往工作相比，节约资源和时间的益处。

　　3、另外通过这一过程，我们研究了自动化测试的使用原则和一些工具的介绍，自动化测试应该在兼顾效率和成本的原则下使用，并不是一定能够比手动测试更加先进。

　　[1]J.M.Juran.Juran谈质量计划(Juran on Planning for Quality)，New York:Free Press;London:Collier Macmillan,2017

　　[2]Brian Maric.Classic Testing Mistakes．http://www.kaner.com/articles.html．2014

　　[3]Cem Kaner．Don’t Use Bug Counts to Measure Testers．Software Testing＆Quality Engineering．2015

　　[4][美]Rex Black，软件测试过程管理。北京：机械工业出版社，2003.10

　　[5]胡贝蒂(Huberty Dirk)(作者),马博(译者),赵云龙(译者)软件质量与软件测试．清华大学出版社;第1版(2013.01)

　　[6]Dirk Huberty.软件质量和软件测试．北京：清华大学出版社，2013．

　　[7]Mary Ann Vandermark．缺陷漏测分析：测试过程改进．www．51testing．com．2015.10[8]蔡琰.浅谈功能测试用例模板设计．无忧测试．2014.07．

　　[9]刘群策．银行IT系统如何质量控制．http://www.simaone.org.2016.08

　　[10]钱义力.软件测试的过程改进研究与应用方案．北京工业大学.2015.04

　　[11]阿西著，李昂等译．Web测试指南．北京：机械工业出版社．2014．

　　[12]蔡琰．浅谈功能测试用例模板设计．无忧测试．2014.07