软件测试

论文题目： 软件测试 专业：移动互联应用技术 摘 要学校的课程学习与实现工作符合选题-软件测试，从学习到实习接触多体会深。随着中国IT产业的发展和软件市场的成熟，人们对软件的期望越来越高，软件的质量，性能和可靠性逐渐成为人们关注的焦点。 近年来，由于软件错误导致的经济损失导致了频繁和严重的后果。 因此，如何保证软件产品的质量和可靠性已成为人们必须解决的重要问题，软件测试是保证软件质量的重要手段。关键字：软件测试；测试用例；需求分析；黑盒测试；目 录第一章.前言51.1. 软件测试的背景和意义51.2.软件测试的定义6第二章. 软件测试相关技术62.1.白盒测试72.2.黑盒测试72.3等价划分法72.4.边界值分析法82.5.因果图方法82.6.错误推测法8第三章. 需求分析93.1需求分析的内容93.2需求分析的过程及方法103.2.1需求分析的过程103.2.2需求分析的方法11第四章. 软件测试的过程134.1.测试计划134.1.1.编写目的134.1.2.编写条件144.1.3.总结评审154.2测试用例154.2.1测试用例基本要求16（1）基本格式：软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。164.2.2.搭建测试环境，执行测试用例174.2.3注意事项184.3.问题报告204.3.1.软件配置204.3.2.硬件配置204.3.3输出214.3.4相关输出信息214.3.5日志信息214.4结果分析22第五章. 自动化测试225.1定义235.2工具介绍23第六章. 总结25参考文献26第一章.前言学校的课程学习与实现工作符合选题-软件测试，从学习到实习接触多体会深。国内外现状：国内-国内的软件行业正在快速的发展，而软件测试与开发的比例从1:5逐渐趋向于1:2，但部分中小企业软件的开始到上线总体流程过慢，需要多适应“敏捷开发”这种模式。如今客户和企业也更注重软件的质量，所以软件测试被重视但还有待提高。国外-由于软件行业发展早成熟快，测试：开发比例逐渐稳定且软件开发模式快捷，对软件测试重视且技术成熟。1.1. 软件测试的背景和意义随着计算机技术的飞速发展和在国民经济和社会生活各个方面的越来越广泛的应用，随着软件系统规模和复杂性的增加，软件的生产成本以及软件的缺陷和缺陷各种损失都有。也大大增加，甚至产生灾难性后果。软件质量问题已成为使用软件和开发软件的任何人关注的焦点。由于软件是人脑的高度智能化的体现和产品的特殊性，与其他技术和生产领域不同，软件和恐惧可能存在缺陷。如何预防和减少这些可能出现的问题？答案是进行软件测试。测试是消除和预防软件缺陷和故障的最有效手段，从而促进了软件测试理论和技术实践的快速发展。新的测试理论，测试方法和测试技术不断涌现。软件测试组织和组织也在迅速兴起和发展，软件测试技术专业也在不断完善和完善。1.2.软件测试的定义软件测试使用人工或者自动手段来运行或测试某个系统的过程%2C其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness)+完全度(completeness)和质量(quality)的软件过程；是SQA(software+quality+assurance)的重要子域。测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势可以帮助项目管理者发现当前软件开发过程中的缺陷以便及时改进；这种分析也能帮助测试人员设计出有针对性的测试方法改善测试的效率和有效性；没有发现错误的测试也是有价值的完整的测试是评定软件质量的一种方法。第2章. 软件测试相关技术2.1.白盒测试白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑测试、基路测试等，主要用于软件内部结构的验证。2.2.黑盒测试黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边界值分析、因果图、错误推测等，主要用于软件确认测试。2.3等价划分法等价类划分是把所有可能的输入数据即程序的输入域划分成若干部分（子集）然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的常用的黑盒测试用例设计方法.2.4.边界值分析法边界值分析方法是对等价类划分方法的补充.边界值分析方法的考虑长期的测试工作经验告诉我们大量的错误是发生在输入或输出范围的边界上而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例可以查出更多的错误。2.5.因果图方法前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但未考虑输入条件之间的联系相互组合等。考虑输入条件之间的相互组合可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）。2.6.错误推测法错误推测法基于经验和直觉推测程序中所有可能存在的各种错误从而有针对性的设计测试用例的方法.其基本思想列举出程序中所有可能有的错误和容易发生错误的特殊情况根据他们选择测试用例.第3章. 需求分析需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。3.1需求分析的内容需求分析是软件规划阶段的一项重要活动，也是软件生命周期的重要组成部分。 这个阶段是分析系统需要“实施”的内容，而不是如何“实施”。 需求分析的目标是分析和组织用户为开发软件提出的“需求”或“需求”，并形成描述确认后的完整性，清晰度和标准化的文档，以确定软件的功能。 需要实施和完成什么。 此外，软件的一些非功能性要求（如软件性能，可靠性，响应时间，可扩展性等），软件设计约束，运行时和其他软件关系也是软件需求分析的目标。为了促进软件研发工作的规范化、科学化，软件领域提出了许多软件开发与说明的方法，如结构化方法、原型化法、面向对象方法等。这些方法有的很相似。在实际需求分析工作中每一种需求分析方法部有独特的思路和表示法，基本都适用下面的需求分析的基本原则。(1)侧重表达理解问题的数据域和功能域。对新系统程序处理的数据，其数据域包括数据流、数据内容和数据结构。而功能域则反映它们关系的控制处理信息。(2)需求问题应分解细化，建立问题层次结构。可将复杂问题按具体功能、性能等分解并逐层细化、逐一分析。(3)建立分析模型。模型包括各种图表，是对研究对象特征的一种重要表达形式。通过逻辑视图可给出目标功能和信息处理间关系，而非实现细节。由系统运行及处理环境确定物理视图，通过它确定处理功能和数据结构的实际表现形式。3.2需求分析的过程及方法3.2.1需求分析的过程需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。分析与综合：逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。制订规格说明书：即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。评审：对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。3.2.2需求分析的方法目前，软件需求的分析与设计方法较多，一些大同小异，而有的则基本思路相差很大。从开发过程及特点出发，软件开发一般采用软件生存周期的开发方法，有时采用开发原型以帮助了解用户需求。在软件分析与设计时，自上而下由全局出发全面规划分析，然后逐步设计实现。从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。(1)功能分解方法。将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解功能、子功能、功能接口。(2)结构化分析方法。结构化分析方法是从问题空间到特定表示的映射方法。 它是结构化方法中重要且普遍接受的表示系统。 它由数据流图和数据字典组成。 该分析也称为数据流方法。 基本策略是跟踪数据流，即研究数据在问题域中的流动方式以及在每个链路上执行的处理，以发现数据流和处理。 结构化分析可以定义为数据流，数据处理或处理，数据存储，端点，处理指令和数据字典。(3)信息建模方法。它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是ER图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。(4)面向对象的分析力法。面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)。第4章. 软件测试的过程4.1.测试计划4.1.1.编写目的通过测试，傻瓜进销存系统强大而完善的功能，描述需要测试的特性、测试的方法、测试环境的规划、测试用例的设计方法、明确测试策略。4.1.2.编写条件俗话说：凡事预则立，不预则废！在测试项目之初就要制定相应的测试计划。接下来谈下如何编写测试计划问题。首先了解以下几个问题：1 为什么要编写测试计划？1）领导能够根据测试计划做宏观调控，进行相应资源配置等；2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；3）便于其他人员了解测试人员的工作内容，进行有关配合工作2 什么时间开始编写测试计划？（测试需求分析前总体测试计划书/测试需求分析后详细测试计划书）3 由谁来编写测试计划？具有丰富经验的项目测试负责人4 测试计划编写6要素？（5W1H）1）why为什么要进行这些测试；2) what测试哪些方面，不同阶段的工作内容；3) when测试不同阶段的起止时间；4) where相应文档，缺陷的存放位置，测试环境等；5) who项目有关人员组成，安排哪些测试人员进行测试6) how如何去做，使用哪些测试工具以及测试方法进行测试。4.1.3.总结评审1.计划评审+测试计划编写完成后，一般要对测试计划的正确性、全面性以及可行性等进行评审，评审人员的组成包括软件开发人、营销人员、测试负责人以及其他有关项目负责人。2.计划总结+项目完成后，应该对计划的执行情况进行评审，看有哪些不合理的地方，以便为编写下一个项目测试计划做经验积累。4.2测试用例测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。4.2.1测试用例基本要求（1）基本格式：软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。（2）用例编号编辑测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称+测试阶段类型（系统测试阶段）+编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。(3)测试标题编辑对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。(4)重要级别编辑定义测试用例的优先级别，可以笼统的分为 四个不同的等级(5)输入限制编辑提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。(6)操作步骤编辑提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。(7)预期结果编辑提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。4.2.2.搭建测试环境，执行测试用例测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 Sql Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。4.2.3注意事项测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：（1）.全方位的观察测试用例执行结果： 测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 %，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 %。如果观察点单一，这个严重消耗资源的问题就无从发现了。（2）.加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。（3）.及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重现问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。（4）.与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。（5）.及时更新测试：测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。4.3.问题报告软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。4.3.1.软件配置包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。4.3.2.硬件配置计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬图1.测试用例设计件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确详实的记录硬件配置情况。4.3.3输出这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。4.3.4相关输出信息输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。4.3.5日志信息规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。4.4结果分析执行软件测试后，测试活动尚未结束。对测试结果的分析是不可或缺的重要组成部分， “ 编筐编篓，全在收口 ” ，对测试结果的分析对下一轮测试工作的发展具有重要意义。在之前的“测试准备”中，建议测试人员遍历缺陷跟踪库以检查其他测试人员发现的软件缺陷。测试结束后，您还应该分析找到的软件缺陷，并对发现的缺陷进行分类。您会发现您提交的问题仅限于几个类别;然后，完成测试执行工作的其他测试人员发现的问题也放在一起，您会发现您提交的问题类别与他们不同。这个是正常的。人们的思想是有限的。在测试过程中，每个测试人员都有自己的盲点来思考问题和测试执行的盲点。有效的自我分析和其他测试人员的分析，你会发现自己的。盲区，有针对性的分析盲点，肯定会在下一轮测试中避免盲点。第5章. 自动化测试5.1定义自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。5.2工具介绍QTP全名HP QuickTest Professional software ，2012年12月6日发布11.5版本，并更名为Unified Functional TestingQTP是quicktest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此你在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。5.3.前提条件实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：（1) 需求变动不频繁测试脚本的稳定性决定了自动化测试的维护成本。 如果软件需求变化太频繁，测试人员需要根据更改的要求更新测试用例和相关测试脚本。 脚本本身的维护是代码开发的过程，需要时需要对其进行修改，调试和修改。 该框架，如果成本不低于其节省的测试成本，那么自动化测试就会失败。项目中的某些模块相对稳定，而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试，而变动较大的仍是用手工测试。（