1软件测试的基础
1.1软件测试的涵义软件测试指在软件投入运行前，进行对软件需求分析、设计规格说明以及编码的最终复审，这是保证软件质量的关键性步骤。其是为了发现错误进而执行程序的过程。
软件测试的工作归结起来就是两个V,Verification和Validationo Verification翻译为验证，在在IS09000中，验证的严格定义是:验证是通过检查和提供客观证据，表明规定要求已经满足的认可。Validation翻译为确认，在IS09000中，确认的严格定义是:确认是通过检查和提供客观证据，表明一些针对某一特定预期用途的要求已经满足的认可。
1.2确认和验证二者的关系确认(CValidatior)是一系列的活动和过程，在开发过程期间或者后期，在一个给定的外部环境中，评价一个系统或者部件是否满足指定的需求。需求规范说明的确认以及程序的确认(分为静态确认，即经由人工分析或程序正确性证明从而来确认程序是否正确;与动态确认，即经由程序测试以及动态分析检查程序执行状态从而来确认程序存在问题与否两种)是包含在确认中两种形式。其强调的是对于结果的检验。
从定义上可以看出验证关注是否满足规定，即需求规格说明书，确认关注的是是否满足预期用途，即用户的真正需求。我们知道，软件的设计，编码实现都是依据软件的需求规格说明书。
确认与验证工作都属于软件测试。不论哪个环节出现了问题，这些问题都会被表现在软件测试当中。对于软件测试来说，其目的是验证软件是否符合软件的需求规格说明，因此都可归于验证过程。然而需求规格说明书并不能代表用户的真正需求，而且依据需求的设计也往往同需求会有些偏差，所以得出的软件产品在经过了集成测试以后还需要进行确认测试。
1.3测试信息流。三类输入在测试过程当中是必需的:①包含软件开发文档，目标执行程序以及数据结构在内的软件配置;②包含测试计划和测试用例以及测试驱动程等在内的测试配置;③为提高软件的测试效率，为了测试工作而服务的测试工具。
测试过后，将实测结果和预期结果相比较。调试出错的数据。对发现的错误进行定位并确定其性质，进而改正，将相关文档进行修改。再一次测试修改之后的文档直到测试通过。通过对结果数据的收集与分析，对软件建立可靠性模型。
假如在测试的过程中没有发现错误，则一定是对测试配置没有进行细致而充分的考虑，软件中仍然潜伏着错误。而不得不由用户在使用的过程中发现这些潜在的错误，由开发者在维护的时候去改正。但是改正的费用却要比在开发阶段高出10倍左右。
1.4测试与软件开发各阶段的关系自上而下，逐步细化的过程是软件开发过程，而测试的过程是自下而上，逐集成的相反的过程。上一级测试需要低一级的测试为其准备条件。
第一步要进行由开发人员自己完成的单元测试，以消除模块内部在逻辑以及功能上的错误。然后再进行视公司组织架构放在开发或测试组进行的集成测试，检查以及排除系统或者子系统结构上的错误。随后再根据需求，进行下一步的确认测试。最后则从全体系统出发，运行系统测试，看是不是满足要求。
2软件测试的过程以及策略
测试过程是按照4个步骤进行的单元测试、集成测试和确认测试以及系统测试。
2.1单元测试单元测试指的是对软件当中最小可测试单元进行检查以及查证。一般是根据实际的情况来判定单元具体含义。
①单元测试的具体内容:针对每个程序的模块，单元测试主要测试模块接口、局部数据结构、边界条件、独立的路径和错误处理这5个方而的问题。
1模块接口测试:即检查进出程序单元的数据流正确与否，对模块接口数据流的测试一定要在任何其他测试之前进行。
2局部数据结构测试:测试其内部的数据能否保持完整性，其中包括内部数据的内容和形式及相互关系不发生错误。
3路径测试:检查是不是存在由于计算错误、不正确的判定或不正常的控制流而产生的错误。
4边界条件测试:是单元测试的最后一步，必须采用边界值分析方法来设计测试用例，测试为限制数据处理而设置的边界处，看模块是否能够正常工作。
5出错处理测试:测试模块在工作中发生了错误时，其中的出错处理设施是否有效。
②单元测试的具体步骤。单元测试通常在编码阶段进行。编译运行程序，并进行语法正确性验证，若无语法错误，编译通过;静态测试，参照编码规范，并检查程序当中是否存在不符合规范的地方;动态测试，深入检查代码的正确性、容错性以及边界值等。需要提前设计测试步骤和测试用例。
模块不是独立的，模块和外界的联系在考虑测试模时也要同时考虑进去。若一模块需完成多个功能，可将该模块看成几个小程序构成。单元测试的工作可先对其中的每个小程序进行，性能测试对于关键模块还是要做的。对于支持一些标准规范的程序，关联测试的进行也是必需的。
2.2集成测试(Intergration Testin)集成测试是单元测试的下一个阶段，指的是将通过测试的单元模块组装成为系统或者是子系统，再次进行测试。在组装的过程当中，检查程序结构组装的正确性时应明确:
①穿越模块接口的数据是不是会在将各个模块连接时丢失;
②不利的影响会不会在某个模块与另外的某一模块的功能中产生;
③预期功能的要求能否在单元各个子功能组合后实现;
④一系列问题会不会出现在对全局数据结构的使用当中;
⑤会不会放大(甚至达到不能接受的程度)单个模块误差的累积;
⑥数据库会不会因单个模块的错误而导致自身的错误。
对于模块组装方式以形成可运行系统的方式的选择会直接影响到所有测试工具的类型以及模块测试用例的形式、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。将模块组装成系统的方式通常被分为:
①一次性集成测试方式(CNo-Incremental Integration)这个测试方式也叫做整体拼装，首先分别测试每个模块，再把所有模块按设计要求放在一起结合成为所要实现的程序。涉及模块间接口以及全局数据结构等方而的问题是程序中没办法避免的，一次试运行成功的可能性并不是很大。
②增殖式集成测试方式。这个测试方式又称为渐增式集成方式，该测试的集成是逐步实现的:逐次将未曾集成测试的模块和已经集成测试的模块或子系统结合成程序包，再将这些模块集成为较大系统，在集成的过程中边连接边测试，以发现连接过程中产生的问题。
③混合增殖式测试。作为最容易出问题的模块，涉及到复杂算法和真正输入或输出的模块一般处在底层，假如这些模块到组装和测试的后期才遇到，一旦发现问题，则会导致次数非常多的回归测试。所以要将这些模块最先得到组装及测试，要在早期解决最容易出问题的部分。正是因为这个原因，所以通常会将以上两种方式结合起来进行组装及测试。
2.3确认测试确认测试又称有效性测试，它的任务是验证软件的有效性，即验证软件的功能和性能及其它特性是否与用户的要求一致。
在确认测试阶段，首先要进行有效性测试以及软件配置审查，然后进行验收测试和安装测试，在通过了专家鉴定之后，才能成为可交付的软件。
2.4系统测试(System testin乡系统测试指的是将软件作为基于计算机系统的一个元素，与其他系统相组合，与其他系统元素(计算机硬件和外设以及某些支持软件、数据和人员)结合在一起，在实际运行环境下进行的一系列测试。
系统测试的目的在于充分运行系统，验证系统各个部件是不是都可以满足正常工作并完成所分配的功能，并且能满足性能的要求。
3软件测试的测试用例的设计
3.1测试方法的概述人工测试和基于计算机的测试是软件测试大致划分的种类。基于计算机的测试又可划分为白盒测试以及黑盒测试/功能测试。
①黑盒测试/功能测试。黑盒测试是指，测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误的测试方法。用这种方法进行测试时，把被测试程序当作一个黑盒，在不考虑程序内部结构的内部特性、测试者只知道该程序输入和输出之间的关系或程序功能的情况下，依靠能够反映这一关系和程序功能需求规格的说明书，来确定测试用例和推断测试结果的正确性。使用黑盒测试发现程序中的错误，要在所有可能的输入条件以及输出条件中来确定测试数据，以检查程序是否都能产生正确的输出。
②白盒测试/白盒测试是指:倘若其以产品的内部结构为基进行测试，查看是否按照规定执行了内部操作和是否最大限度使用了软件各个部分功能。其对程序细节的严密的检验有很大的依赖。对于软件的逻辑路径进行测试是针对特定条件和循环集设计测试用例的。其实际情况是否和预期的状态相一致是在程序的不同点检验程序的状态来进行判定的。
不管是黑盒测试或是白盒测试，因其可能的测试输入数据数目常达到天文数字，所以决定了无法将所有可能的输入数据都拿来进行穷举测试。期限、费用和人力以及时机等条件限制了任何的软件项目，尽管是需要针对所有可能的数据进行测试而将隐藏的错误充分揭露出来，但事实上这也是不现实的。
3.2逻辑覆盖测试逻辑覆盖属白盒测试。它针对程序内部的逻辑结构设计测试用例。这一技术方法要求测试人员非常清楚程序的逻辑结构。逻辑覆盖依据覆盖测试的目标不同又可分以下几种:
①语句覆盖:语句覆盖又称为点覆盖，指的是设计若干个测试用例，并运行被测程序，从而使得每一可执行语句被至少执行一次。语句覆盖算是最弱的逻辑覆盖，其效果是有限的，必须与其它方法交互使用。
②判定覆盖:又被称为判定覆盖。指的是设计若干个测试用例，并运行被测程序，从而使得程序中每个判断的真假分支至少执行一次。
③条件覆盖:指的是设计足够多个测试用例，并运行被测程序，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
④多重条件覆盖:要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
⑤路径覆盖:路径覆盖测试指的就是设计足够的测试用例，覆盖程序中所有可能的路径。这是也是最强的覆盖准则。做到完全覆盖在路径数目很大的时候是很困难的，这要求必须把覆盖路径数目压到一定的限度。
3.3错误推测方法错误推测方法指的是基于经验和直觉来推测程序中可能存在的各种误，进而有针对性地设计测试用例的方法错误推测法的基本思想是:将程序中所有可能的错误以及容易发生错误的特殊情况进行列举，再依照这些情况选择测试用例。
3.4边界值分析法依照无数的测试实践表明，大量的故障往往不是发生在其内部，而是发生于输入定义域或者输出值域的边界上，所以针对各种边界情况设计测试用例常会取得很好的测试效果。使用这种方法，第一步应是确定边界情况。选取正好等于，刚刚大于或者刚刚小于边界的值作为测试数据。黑盒测试是边界分析法最有效的。
4软件测试的独立性分析
为了确保对开发小组开发软件检查的客观性，VV小组必须从技术上，财务上和管理上和开发小组保持独立。VV方法包括设计审查、检查、演练、要求的可追溯性分析，软件危害分析，安全评估，软件确认测试和系统测试。为了提高效率，VV活动必须和开发活动同步进行。
4.1技术独立技术独立要求VV人员不能和开发人员相同。以便用不同的技术思路去思考，发现因思维定势而被忽略的错误。技术独立反映在工具上，要求采用和开发不同的测试和分析工具。
4.2管理独立管理独立要求VV的管理不受开发方的任何限制，VV人员可以自由制定测试和分析计划。VV人员发现问题和汇报不受开发方的压力。
4.3财务独立财务独立是保证技术独立和管理独立的重要手段。财务独立使得VV的预算不受开发方的控制，以保证VV人员有足够的资源来完成他们的任务。
技术独立，管理独立和财务独立，以及配备技术资历相当，人员数量相当和开发小组平衡的VV机构是顺利实现安全级软件系统VV活动的基本前提。
独立的VV的主要优点是可以使得进行评估的人或小组的观点保持客观性。他们对于项目没有感情上的联系，也没有任何袒护的动机，独立的VV会更严格。
详细的计划是VV活动的开端，为了实施该计划，需要有一个仔细规划的VV机构。非常重要的一点是，一个独立的VV机构对安全级软件的VV活动是非常必须的，只有这样才能达到客观性并保证高质量的软件。事实上，美国核管会要求安全级软件的VV必须由技术上，财务上及管理上和开发小组独立的VV小组完成。除了这个独立性要求以外，VV小组成员的人数和技能要与开发小组相当。
如果VV小组人员大大少于开发小组人员，要么他们不能完成所有应该完成的任务，要么VV的工作会滞后。VV组成人员的素质也非常重要。如果VV工程师要判断软件工程师的工作，那么他们应该能够理解软件开发的过程和技术。如果VV工程师的素质不能满足要求，VV的工作将是非常低效的。
5结语
总而言之，将有限的人力和物力资源进行最大限度的利用来低成本高质高效地完成软件开发项目。软件测试工作具有复杂性，繁琐性和反复性，在穷举测试是行不通的，但为了达到节省时间以及资源还要提高测试效率的目的，就必须要从庞大的测试用例中挑选出少量的测试数据，使得这些测试数据的采用达到最优的测试效果，高效地揭露出隐藏的错误，最终实现开发经济，可靠，安全的软件。
参考文献:
[1]任永忠，土翠芳.核电站安全系统中使用数字化技术的关注焦点[fJ].仪器仪表标准化与计量，2009 5.
[2]杨永祥.电站数字化仪控系统软件验证和确认实用手册.
