项目测试操作过程与方法

项目测试操作过程及方法拟制：冬日期：2016-2-16审察：日期：订正记录日期订正版本描绘作者目录1概括................................................................................................................42软件测试理论................................................................................................42.1什么是软件测试................................................................................42.2软件测试的目标................................................................................53软件测试流程................................................................................................63.1软件测试流程图................................................................................63.2软件测试流程细则............................................................................7需求剖析.................................................................................7测试计划.................................................................................8测试设计.................................................................................8测试软/硬件环境搭建............................................................9测试数据准备.........................................................................9用例履行...............................................................................10测试更改...............................................................................10测试报告...............................................................................10查收测试...............................................................................113.3软件测试注意事项..........................................................................114软件测试分类..............................................................................................124.1模块测试...........................................................................................134.2子系统测试.......................................................................................134.3.系统测试...........................................................................................134.4查收测试...........................................................................................134.5回归测试...........................................................................................144.6Alpha测试........................................................................................144.7Beta测试..........................................................................................145黑盒测试方法..............................................................................................145.1等价类区分.......................................................................................155.2边值剖析法.......................................................................................165.3因果图...............................................................................................175.4猜错法...............................................................................................185.5随机数法...........................................................................................186白盒测试方法..............................................................................................186.1语句覆盖...........................................................................................196.2.判断理盖...........................................................................................206.3.条件覆盖...........................................................................................206.4.判断／条件覆盖..............................................................................216.5条件组合覆盖..................................................................................217标准文档......................................................................................................22概括本规是对软件测试的一份指导性文件，对软件测试过程中所波及到的测试理论、测试种类、测试方法、测试标准、测试流程以及软件产品开发单位所担当的职责进行整体规，以有效保证软件产品的质量。软件测试理论2.1什么是软件测试不论如何重申软件测试的重要性和它对软件靠谱性的影响都可是分。在开发大型软件系统的漫长过程中，面对着极其盘根错节的问题，人的主观认识不行能完好切合客观现实，与工程亲密有关的各种人员之间的通讯和配合也不行能十全十美，所以，在软件生命周期的每个阶段都不行防止地会产生差错。我们力争在每个阶段结束以前经过严格的技术审察，尽可能早地发现并纠正差错；可是，经验表示审察其实不可以发现所有差错，别的在编码过程中还不行防止地会引入新的错误。假如在软件投入生产性运转以前，没有发现并纠正软件中的大多半差错，则这些差错早晚会在生产过程中裸露出来，那时不单更正这些错误的代价更高，并且常常会造成很恶劣的结果。测试的目的就是在软件投入生产性运转以前，尽可能多地发现软件中的错误。当前软件测试仍旧是保证软件质量的重点步骤，它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个阶段。往常在编写出每个模块以后就对它做必需的测试(称为单元测试)，模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束以后，对软件系统还应当进行各样综合测试，这是软件生命周期中的另一个独立的阶段，往常由特意的测试人员担当这项工作。大批统计资料表示，软件测试的工作量常常占软件开发总工作量的40％以上，在极端状况，测试那种关系人的生命安全的软件所花销的成本，可能相当于软件工程其余开发步骤总成本的三倍到五倍。所以，必须高度重视软件测试工作，绝不要认为写出程序以后软件开发工作就接近达成了，实质上，大概还有相同多的开发工作量需要达成。仅就测试而言，它的目标是发现软件中的错误，可是，发现错误其实不是我们的最整天的。软件工程的根本目标是开发出高质量的完好切适用户需要的软件。2.2软件测试的目标下边这些规则也能够看作是测试的目标或定义：测试是为了发现程序中的错误而履行程序的过程；好的测试方案是极可能发现迄今为止还没有发现的错误的测试方案；成功的测试是发现了到现在为止还没有发现的错误的测试。从上述规则能够看出，测试的正确立义是“为了发现程序中的错误而履行程序的过程”。这和某些人往常想象的“测试是为了表示程序是正确的”，“成功的测试是没有发现错误的测试”等等是完好相反的。正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。假如为了表示程序是正确的而进行测试，就会设计一些不易裸露错误的测试方案；相反，假如测试是为了发现程序中的错误，就会力争设计出最能裸露错误的测试方案。因为测试的目标是裸露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不合适的。所以，在综合测试阶段往常由其余人员构成测试小组来达成测试工作。别的，应当认识到测试决不可以证明程序是正确的。即便经过了最严格的测试以后，仍旧可能还有没被发现的错误暗藏在程序中。测试只好查找出程序中的错误，不可以证明程序中没有错误。软件测试流程3.1软件测试流程图开发人员PM测试负责人测试人员开始1、学习、评审学惯用户需求列表、需求规格书2、编写测试方案3、编写测试用例4、评审测试方案、测试用例5、负责测试方案、测试用例等文档入库6、召开阶段会议结束

输入/输出用户需求列表需求规格书测试方案测试用例阶段报告3.2软件测试流程细则需求剖析测试人员和开发人员均应参加需求评审、设计评审。对《需求说明书》、《系统界面原型》和《软件设计说明书》等进行阅读和审察，与产品经理、项目经理交流，认识并熟习系统业务逻辑，同时依据系统功能复杂度，系统业务复杂度估量开发时间和有效测试履行时间，为项目总计划和测试计划的拟订供给参照和依照。经过对文档剖析，分解各功能模块，各功能点，为测试用例设计提供数据依照。测试人员认识项目需求更改。重点明确需求以下：1、功能测试需求2、性能测试需求3、压力测试需求4、系统容量需求5、系统安全性需求6、安装测试需求7、数据变换需求8、兼容性需求9、项目文档1）产品交流2）客户、售古人员，产品交流记录3）项目文档资料4）业务背景资料测试计划依据需求文档和项目计划拟订测试计划。测试计划旨在说明各测试阶段任务、人员分派、时间安排、测试重点、工作规等。测试计划在策略和方法方面说明如何计划、组织和管理测试项目。测试计划达成后应当在项目组进行评审。测试人员会同项目主管依据软件需求拟订并确认《测试计划》。测试设计在设计测试方案时，第一分解测试容，关于一个复杂系统，往常能够分解成几个相互独立的子系统，正确地区分这些子系统及其逻辑构成部分和相互间的关系，能够降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统剖析人员的开发剖析文档加工成以测试为角度的功能点剖析文档，重要的是描绘对系统分解后每个功能点逐个的校验描绘，包含何种方法测试、何种数据测试、希望测试结果等。而后以功能点剖析文档作为依照进行测试用例的设计，设计测试用例是关系到测试成效以致软件质量的重点性一步，也是一项特别仔细的工作，依据对详细的北侧系统的剖析和测试要求，逐渐细化测试的围和容，设计详细的测试过程和数据，同时将结果写成能够按步履行的《测试用例》文档。每个测试用例一定包含以下几个部分：1）编号和模块2）测试的任务项和功能点3）输入和使用的数据和操作过程4）希望的输出结果5）其余特别的环境要求、序次要求、时间要求等6）输出《测试用例》文档测试用例是为实行测试而向被测试系统供给的输入数据、操作或各种环境设置以及希望结果的一个特定的会合。解决要测什么、怎么测和如何权衡的问题。依照用户需求剖析说明书、测试方案来设计测试用例，发现需求与设计中的问题后，与项目经理实时交流确认。1）测试用例设计方法测试用例的设计方法有等价类测试、界限值剖析、鉴于判断表的测试、鉴于因果图的测试、鉴于状态图的测试、鉴于场景的测试。在设计测试用例经常用的设计方法有等价类测试、界限值剖析两种方法。2）测试用例操作步骤在设计编写测试用例时，依据需求文档和开发文档设计用例，评审通事后将使用该测试用例测试被测系统。在测试时期，发现用例描绘不清、需求更改或用例设计错误，实时在一致文档中记录，待本轮测试结束后，更新基线用例。3）测试用例选择准则测试用例的代表性：能够代表各样合理和不合理的、合法的和非法的、界限和越界的,以及极限的输入数据、操作和环境设置等；测试结果的可判断性：即测试履行结果的正确性是可判断的或可评估的；测试结果的可再现性：即对相同的测试用例,系统的履行结果应当是相同的。测试软/硬件环境搭建依据需求文档供给的容，和开发部交流确立测试项目所需的软硬件环境，达成对测试项目所需软硬件资源的准备工作，使软硬件资源获取知足。测试数据准备达成对测试项目基本数据的准备操作，包含数据库连结、用户信息、用户角色权限、单位组织等信息和测试有关的测试数据。用例履行测试准入条件项目开发组达成编码后，提交测试所要求的待测软件及各样设计文档、手册（附录一、二）。同时开发人员经过自测经过，起码保证程序能够正常运转；对应的功能在正常流程下是能够正常使用。测试进行冒烟测试经过，开始进行正式测试。项目测试阶段测试人员依照测试计划和测试用例进行测试活动。测试一般分为两个阶段：测试履行阶段：该阶段测试人员测试出bug后将缺点提交至缺点管理库JIRA。在缺点的描绘上，起码要包含以下一些方面貌：标题、模块、重要程度、优先级、操作描绘；回归问题单：开发改正完bug以后，测试进行考证回归。c）测试退出标准功能需求覆盖100%。所实用例所有履行剖析缺点的趋向的收敛的，且遗留问题切合企业定义的胸怀标准。测试过程中缺点率达到企业系统测试质量标准。测试更改当需求更改，功能变化，测试人员依据更改状况，评估测试更改所需时间，提出更改风险。如更改状况被项目组经过，测试人员将按上述流程进行更改测试。测试报告测试结束后，测试人员对测试结果进行汇总；测试主管审察测试结果，得出测试结论；测试组进行测试剖析和评估，编写《测试剖析报告》。提交《测试剖析报告》。将所有文件存档。对测试未经过的待测软件，测试人员汇总并向项目开发组提交测试错误报告。项目开发组对测试错误报告进行确认，对有争议的问题可由上一级技术负责人确认和仲裁；项目开发组针对测试错误报告进行逐项改正，改正达成后再将待测软件及错误改正状况提交及测试组进行回归测试。待测软件测试通事后，项目测评结束。制作《用户操作手册》（帮助文件）。查收测试项目经理与实行人员交流查收事项。实行人员在客户指定的环境下参照《安装保护手册》进行产品安装调试，并把合同商定的文档、源程序等交给客户。实行人员对客户进行系统操作方法培训。客户试用系统展开业务，测试人员采集客户反应的问题；测试人员在查收中发现或采集到用户反应的缺点并见告项目经理，并将缺点记录到JIRA中分派给合适的开发人员。开发人员剖析缺点的原由及解决该缺点，并将该缺点的解决方法及解决状态更新JIRA。并将改正的代码赐予实行人员部署，待用户考证，直到交托。3.3软件测试注意事项依据《软件开发规》认真检查软件的界面能否符合要求。（每一个子界面也应这样）此中，应注意提示信息和软件开发商信息能否正确。小的图标能否符合要求。检查菜单中间的各项功能和功能按钮能否能正确使用。依据《软件开发规》和《用户需求》及《软件详尽设计》设计测试用例。（以界限值法、等价类区分法为主）。对功能界面要求注意与功能有关的信息显示及显示地点能否正确。数据输入界面应注意文字格式及数字和文字的差别。能否能够正保证存信息。数据查问（显示）界面应注意显示信息能否正确和完好。能否能正确查问。对打印功能要求注意打印出的报表能否正确。（包含报表各项信息、数据信息和报表字体等）。这一项测试主假如对软件的错误办理功能进行测试。就是进行错误的操作或输入错误的数据，检查软件对这些状况能否能做出判断并予以提示。特别状况下要制造极端状态和不测状态，比方网络异样中止、电源断电等状况。必定要注意测试中的错误集中发生现象，这和程序员的编程水平易习惯有很大的关系。对测试错误结果必定要有一个确认的过程。一般有A测试出来的错误，必定要有一个B来确认，严重的错误能够召开评审会进行议论和剖析。拟订严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间达成一个高水平的测试。回归测试的关系性必定要惹起充分的注意，改正一个错误而惹起更多错误出现的现象其实许多见。妥当保留全部测试过程文档，意义是不问可知的，测试的重现性往往要靠测试文档。软件测试分类除非是测试一个小程序，不然一开始就把整个系统作为一个独自的实体来测试是不现实的。与开发过程近似，测试过程也一定分步骤进行，每个步骤在逻辑上是前一个步骤的持续。大型软件系统往常由若干个子系统构成，每个子系统又由很多模块构成。所以，大型软件系统的测试基本上由下述几个步骤构成：4.1模块测试在设计得好的软件系统中，每个模块达成一个清楚定义的子功能，并且这个子功能和同级其余模块的功能之间没有相互依靠关系。所以，有可能把每个模块作为一个独自的实体来测试，并且往常比较简单设计查验模块正确性的测试方案。模块测试的目的是保证每个模块作为一个单元能正确运转，所以模块测试往常又称为单元测试。在这个测试步骤中所发现的常常是编码和详尽设计的错误。4.2子系统测试子系统测试是把经过单元测试的模块放在一同形成一个子系统来测试。模块相互间的协调解通讯是这个测试过程中的主要问题，所以这个步骤侧重测试模块的接口。4.3.系统测试系统测试是把经过测试的于系统装置成一个完好的系统来测试。在这个过程中不单应当发现设计和编码的错误，还应当考证系统的确能提供需求说明书中指定的功能，并且系统的动向特征也切合预约要求。在这个测试步骤中发现的常常是软件设计中的错误，也可能发现需求说明中的错误。不管是子系统测试仍是系统测试，都兼有检测和组装双重含义，往常称为集成测试。4.4查收测试查收测试把软件系统作为单调的实体进行测试，测试容与系统测试基本近似，可是它是在用户踊跃参加下进行的，并且可能主要使用实质数据(系统未来要办理的信息)进行测试。查收测试的目的是考证系统的确能够知足用户的需要，在这个测试步骤中发现的常常是系统需求说明书中的错误。4.5回归测试回归测试是在软件保护阶段，对软件进行改正以后进行的测试。其目的是查验对软件进行的改正能否正确。这里，改正的正确性有双重含义：一是所作的改正达到了预约目的，如错误获取更正，能够适应新的运转环境等等；二是不影响软件的其余功能的正确性。4.6Alpha测试在系统开发靠近达成时对应用系统的测试；测试后，仍旧会有少许的设计更改。这类测试一般由最后用户或其余人员员达成，不可以由程序员或测试员达成。4.7Beta测试当开发和测试根本达成时所做的测试，而最后的错误和问题需要在最后刊行前找到。这类测试一般由最后用户或其余人员员达成，不可以由程序员或测试员达成。黑盒测试方法黑盒测试(black—boxtesting)又称功能测试、数据驱动测试或鉴于规的测试(即ec颠cation—basedtesting)。用这类方法进行测试时，被测程序被看作看不见部的黑盒。在完好不考虑程序部构造和部特征的状况下，测试者仅依照程序功能的需求规考虑确立测试用例和推测测试结果的正确性。所以黑盒测试是从用户看法出发的测试，黑盒测试直观的想法就是既然程序被规定做某些事，那我们就看看它能否是在任何情况下都做的对。完好的“任何状况”是没法考证的，为此黑盒测试也有一套产生测试用例的方法，以产生有限的测试用例而覆盖足够多的“任何状况”。因为黑盒测试不需要认识程序部构造，所以很多高层的测试如确认测试、系统测试、查收测试都采纳黑盒测试。黑盒测试第一是程序往常的功能性测试。要求：每个软件特征一定被一个测试用例或一个被认同的异样所覆盖。用数据种类和数据值的最小集测试。用一系列真切的数据种类和数据值运转，测试超负荷、饱和及其余“最坏状况”的结果；用设想的数据种类和数据值运转，测试排挤不规则输入的能力；对影响性能的重点模块，如基本算法、应测试单元性能(包含精度、时间、容量等)。不单要查核“程序应当做什么?”还要观察“程序能否做了不应做的2”同时还要观察程序在其余一些状况下能否正常。这些状况包含数据类型和数据值的异样等等。下述几种方法：(a)等价类区分，(b)因果图方法，(c)边值剖析法，(d)猜错法，(e)随机数法，就是从更宽泛的角度来进行黑盒测试。每一个方法都力争能涵盖更多的“任何状况”，但又各有优点，综合使用这些方法，会获取一个较好的测试用例集。5.1等价类区分等价类区分是一种典型的黑盒测试方法。等价类是指某个输入域的会合。它表示对揭穿程序中的错误来说，会合中的每个输入条件是等效的。所以我们只需在一个会合中选用一个测试数据即可。等价类区分的方法是把程序的输入域区分红若干等价类，而后从每个部分中选用少量代表性数据看作测试用例。这样便可使用少量测试用例查验程序在一大类状况下的反应。在考虑等价类时，应当注意差别以下两种不一样的状况：有效等价类：有效等价类指的是对程序的规是存心义的、合理的输入数据所构成的会合。在详细问题中，有效等价类能够是一个，也能够是多个。无效等价类：无效等价类指对程序的规是不合理的或无心义的输入数据所构成的会合。关于详细的问题，无效等价类起码应有一个，也可能有多个。确立等价类有以下几条原则：假如输入条件规定了取值围或值的个数，则可确立一个有效等价类和两个无效等价类。比如，程序的规中提到的输入条包含“项数可以从1到999”，则可取有效等价类为“l考项数＜999”，无效等价类为“项数＜l，，及“项数＞999”。输入条件规定了输入值的会合，或是规定了“一定如何”的条件，则可确立一个有效等价类和一个无效等价类。如某程序波及表记符，其输入条件规定“表记符应以字母开头”则“以字母开头者”作为有效等价类，“以非字母开头”作为无效等价类。假如我们确知，已区分的等价类中各元素在程序中的办理方式是不一样的，则应将此等价类进一步区分红更小等价类。输入条有效等价无效等价件类类。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。依据已列出的等价类表，按以下步骤确立测试用例：为每个等价类规定一个独一的编号；设计一个测试用例，使其尽可能多地覆盖还没有覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖；设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步，使所有无效等价类均被覆盖。这里重申每次只覆盖一个无效等价类。这是因为一个测试用例中假如含有多个缺点，有可能在测试中只发现此中的一个，另一些被忽视。等价类区分法能够全面、系统地考虑黑盒测试的测试用例设计问题，可是没有注意采纳一些“高效的”、“有针对性的”测试用例。后边介绍的边值剖析法能够填补这一弊端。5.2边值剖析法边值剖析法是列出单元功能、输入、状态及控制的合法界限值和非法界限值，设计测试用例，包含所有界限值的方法。典型地包含IF语句中的鉴别值，定义域、值域界限，空或畸形输入，末受控状态等。边值剖析法不是一类找一个例子的方法，而是以界限状况的办理作为主要目标特意设计测试用例的方法。此外，边值剖析不单观察输入的边值，也要考虑输出的边值。这是从人们的经验得出的一种有效方法。人们发现很多软件错误不过在下标、数据构造和标量值的界限值及其上、下出现，运转这个地区的测试用例发现错误的概率很高。用边值剖析法设计测试用例时，有以下几条原则：假如输入条件规定了取值围，或是规定了值的个数，则应以该围的界限及刚才高出围的界限外的值，或是分别对最大、最小及稍小于最小、稍大于最大个数作为测试用例。若有规“某文件可包含l至255”个记录“，则测试用例可选1和255及0和256等。针对规的每个输出条件使用原则〔a〕。假如程序规中提到的输入或输出域是个有序的会合(如次序言件、表格等)就应注意选用有序集的第一个和最后一个元素作为测试用例。剖析规，尽可能找出可能的界限条件。一个典型的边值剖析例子是三角形分类程序。选用a，b，c构成三角形三边，“随意两边之和大于第三边”为界限条件。边值剖析相等价类区分重视不一样，平等价类区分是一个增补。如上述三角形问题，选用a＝3，b＝4，c＝5，a＝2，b＝4，c＝7则覆盖有效和无效等价类。假如能在等价类区分中注入边值剖析的思想。在每个等价类中不仅选用一个覆盖用例，而是从而选用该等价类的界限值等价类区分法将更有效，最后能够用边值剖析法再增补一些测试用例。5.3因果图等价类区分法并无考虑到输入状况的各样组合。这样固然各个输入条件独自可能犯错的状况已经看到了，但多个输入状况组合起来可能犯错的状况却被忽视。采纳因果图方法能帮助我们按必定步骤选择一组高效的测试用例，同时，还可认为我们指出程序规的描绘中存在什么问题。利用因果图导出测试用例需要经过以下几个步骤：剖析程序规的描绘中哪些是原由，哪些是结果。原由经常是输入条件或是输入条件的等价类。结果是输出条件。剖析程序规的描绘中语义的容，并将其表示成连结各个原由与各个结果的“因果图”。因为语法或环境的限制，有些原由和结果的组合状况是不行能出现的。为表示这些特定的状况，在因果图上使用持殊的符号注明拘束条件。把因果图变换成判断表。把判断表的每一列写成一个测试用例。5.4猜错法猜错法在很大程度上是凭经验进行的，是凭人们对过去所作的测试工作结果的剖析，对所揭露的缺点的规律性作直觉的推测来发现缺点的。一个采纳两分法的检索程序，典型地能够列出下边几种测试状况：被检索的表只有一项或为空表；表的项数恰巧是2的幂次；表的项数比2的幂次多1等。猜错法充散发挥人的经验，在一个测试小组中集思广益，方便适用，特别在软件测试基础较差的状况下，很好地组织测试小组(也能够有外来人员)进行错误猜想，是有效的测试方法。5.5随机数法即测试用例的参数是随机数。它能够自动生成，所以自动化程度高。使用大批随机测试用例测试经过的程序会提升用户对程序的信心。但其重点在于随机数的规律能否切合使用实质。白盒测试方法白盒法测试，是以程序的部逻辑为基础，有选择地履行程序中最有代表性的通路。所以，白盒法也叫逻辑覆盖法(bgicMM阴e)。最完全的逻辑覆盖法，是覆盖程序巾的诲一条通路。但当程序中含有大批循环时，要履行每一条通路是44可能的。所以，我们只好寄希望于程序的覆盖度尽可能高一些。当前常用的一些覆盖标准有：语句覆盖、判断覆盖、条件澄盖、判断涤件覆盖、条件组合覆盖、路径覆盖等。白盒法考虑的是测试用例对程序部逻辑的覆盖程度，所以又称为逻辑覆盖法。最完全的白盒法是覆盖程序中的每一条路径，但这不行能，我们希望覆盖的路径尽可能多一些。为了权衡测试的覆盖程度，需要建立一些标准，当前常用的一些覆盖标准是：语句覆盖；判断覆盖；条件覆盖；判断／条件覆盖；条件组合覆盖。6.1语句覆盖程序的某次运转一般其实不可以履行到此中的每一个语句，所以，假如某语句含有一个错误，而它在测试中没履行，这个错误就不行能被发现。为了提升发现错误的可能性，应当在测试时起码要履行程序中的每一个语句。所谓“语句覆盖”测试标准，它的含义是：选择足够的测试用例，使得程序中每个语句起码都能履行一次。例子：ProcedureExample(VarA,B,C:real)beginif(A>1)and(B=0)thenx:=x/A；if(A=2)or(x>1)thenx:=x+lend;为了使程序中每个语句起码履行一次，只需设计一个能经过路径ace的例子就能够了。比如选择输入数据为：A=2，B=0，x=3便可达到“语句覆盖”标准。明显，语句覆盖是一个比较弱的覆盖标准。假如第一个条件语句中的and错误地写成or，上边的测试用例是不可以发现这个错误的，或许是第二个条件语句中x>1误写成x>0，这个测试用例也不可以