搜索
武汉软件工程职业学院史志辉QQ：420514171邮箱：shizhihui0000@163.com本书的五个章节软件测试与项目分析团队组织及任务分配测试用例编写与管理功能测试实施性能测试实施本章主要内容1.1软件测试概念1.2软件测试内容1.3软件测试分类1.4软件测试流程1.5OA项目分析软件项目流程教学目标了解软件测试的概念了解软件测试包含哪些内容熟记软件测试常用的分类方法熟练掌握软件测试流程，能对一个简单项目进行分析熟悉软件项目的流程。软件测试---对软件的测试用更为科学的语言可以表述为：为了检查软件是否达到了客户需求的活动而进行的检查、验证活动，这种活动，我们统称为“软件测试”广义上讲，软件测试是指软件产品生存周期内所有的检查、评审和确认活动。设计评审文档审查需求测试单元测试集成测试系统测试验收测试狭义上讲，软件测试是对软件产品质量的检验和评价的过程。一方面，检查、揭露软件产品质量中存在的质量问题另一方面，对产品质量进行客观的评价并提出改进意见软件测试贯穿于整个软件的生命周期从不同的角度，软件测试的目的是不一样的。客户普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。软件开发者希望测试可以表明软件产品不存在错误，验证软件已经正确地实现了用户的需求，确立人们对软件质量的信息。造成了早期测试者与开发者的对立。我们应该认识到软件测试是软件质量保证中必不可少的一环，具有及其重要的地位。软件测试与软件开发的最终目的都是生产出一个高质量的软件。定义：为了发现错误而审查软件文档、检查软件数据和执行程序代码的过程。软件测试的对象不仅仅是程序源代码，还包括与之相对应的文档及配置数据。百度定义：使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别.软件测试是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness)、完全度(completeness)和质量(quality)的软件过程；是SQA(softwarequalityassurance)的重要子域。GrenfordJ.Myers曾对软件测试的目的提出过以下观点:测试是为了发现程序中的错误而执行程序的过程；好的测试方案是尽可能发现迄今为止尚未发现的错误的测试方案；成功的测试是发现了至今为止尚未发现的错误的测试。软件测试的几大原则：软件开发人员即程序员应当避免测试自己的程序。不管是程序员还是开发小组都应当避免测试自己的程序或者本组开发的功能模块。若条件允许，应当由独立于开发组和客户的第三方测试组或测试机构来进行软件测试。但这并不是说程序员不能测试自己的程序，而且更加鼓励程序员进行调试，因为测试由别人来进行可能会会更加有效、客观，并且容易成功，而允许程序员自己调试也会更加有效和针对性。应尽早地和不断地进行软件测试。应当把软件测试贯穿到整个软件开发的过程中，而不应该把软件测试看作是其过程中的一个独立阶段。因为在软件开发的每一环节都有可能产生意想不到的问题，其影响因素有很多，比如软件本身的抽象性和复杂性、软件所涉及问题的复杂性、软件开发各个阶段工作的多样性，以及各层次工作人员的配合关系等。所以要坚持软件开发各阶段的技术评审，把错误克服在早期，从而减少成本，提高软件质量。对测试用例要有正确的态度：第一，测试用例应当由测试输入数据和预期输出结果这两部分组成；第二，在设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件。因为软件投入实际运行中，往往不遵守正常的使用方法，却进行了一些甚至大量的意外输入导致软件一时半时不能做出适当的反应，就很容易产生一系列的问题，轻则输出错误的结果，重则瘫痪失效！因此常用一些不合理的输入条件来发现更多的鲜为人知的软件缺陷。人以群分，物以类聚，软件测试也不例外，一定要充分注意软件测试中的群集现象，也可以认为是“80-20原则”。不要以为发现几个错误并且解决这些问题之后，就不需要测试了。反而这里是错误群集的地方，对这段程序要重点测试，以提高测试投资的效益。严格执行测试计划，排除测试的随意性，以避免发生疏漏或者重复无效的工作。应当对每一个测试结果进行全面检查。一定要全面地、仔细地检查测试结果，但常常被人们忽略，导致许多错误被遗漏。妥善保存测试用例、测试计划、测试报告和最终分析报告，以备回归测试及维护之用。在遵守以上原则的基础上进行软件测试，可以以最少的时间和人力找出软件中的各种缺陷，从而达到保证软件质量的目的。开发过程中的文档可行性报告项目立项申请书项目进度安排计划需求规格说明书开发进度计划测试计划概要设计文档详细设计文档数据库设计文档数据字典源码清单单元测试用例配置数据：主要是系统运行所必需的基础数据。建库SQL语言建表SQL语言存储过程数据库连接配置文件系统初始驱动程序测试工程师需要对上述文档与配置数据进行检查、评审与确认按测试方法黑盒测试白盒测试灰盒测试静态测试动态测试手动测试自动化测试按测试阶段分需求测试单元测试集成测试系统测试用户测试回归测试黑盒测试又称功能测试，数据驱动测试或者基于需求规格说明书的功能测试通过测试检查被测对象每个功能能否正常使用，是否满足用户的需求从用户的角度检查被测系统的界面、功能等方面的需求的实现情况。缺点：过分依赖用户需求，要求需求稳定，不能频繁变动黑盒测试黑盒测试的主要检查点功能不争取或遗漏界面错误数据访问性错误性能错误初始化和终止性错误黑盒测试的主要检查点—功能不争取或遗漏理想状态下按照用户需求规格说明书一一检查实际检查中，需要从以下几个方面进行由业务部门提供概要的需求文档由研发部门提供functionlist(功能列表)根据业务经验判断要求测试工程师有丰富的业务知识黑盒测试的主要检查点—界面错误在没有明确的用户需求的情况下，与检查功能不正确或遗漏的情况类似应该注意的是：界面测试往往没有一个明确的标准，多数时候依靠测试工程师本人的好恶进程评价，因而这类缺陷在提交修改的时候应该多加谨慎界面错误一般集中在错别字、界面布局等方面黑盒测试的主要检查点—数据访问性错误数据访问性错误发生位置：多数发生在接口上。这类错误对于异步处理的软件而言是致命的实例如广州的“羊城通”充值卡系统比较稳妥的处理方法是软件测试工程师参与试运行过程，在实际的各类用户访问中查看可能出现问题的异常访问，并及时解决黑盒测试的主要检查点—性能错误往往需要专门的性能测试来检查软件的性能问题黑盒测试中，从以下几个方面考虑，不必关注程序内部代码的质量业务响应速度业务并发处理能力业务成功率系统资源耗用例如，B/S结构软件测试中，页面展开速度的快慢，就是被测对象响应速度的一种表现形式黑盒测试的主要检查点—初始化和终止性错误初始化就是做一些进入软件之前的准备工作：把变量赋为默认值，把控件设置为默认状态等等。初始化错误就是指这个阶段的错误终止性错误是指所有的在软件运行过程中导致软件意外终止的错误这类错误多发生在软件的安装与卸载测试过程中，在这个时候，要做注意此类错误黑盒设计常用的设计—等价类设计方法等价类设计方法就是将被测对象的输入域划分为若干不相交的区域，从这些区域中提取出一些具有代表性的数据作为测试用例，这些值在测试过程中的作用与各个区域中的其他值是等效的是在穷举法不能应用的情况下的一种替代方法比如，测试a+b的算法，将输入域分为int，float等等类型，在每个类型中都取具有代表性的一组数据来进行测试黑盒测试常用的设计边界值分析，通常与等价类结合使用，该方法通过选择等价类的边界进行用例的设计，不仅仅关注输入域的边界，还考虑输出域的边界错误推断，这种方法是前两种方法的必要补充，资深的测试工程师，除了可以利用较多的用例设计方法来设计测试用例，还可以根据自身的经验和直觉来判断出被测对象中可能存在的问题，从而充实测试用例，找到更多的软件缺陷白盒测试与黑盒测试相对的软件测试方法又称为结构测试、逻辑驱动测试或基于程序代码内部构成的测试测试工程师关注的是程序代码的内部结构、逻辑设计等要求测试工程师有很深的软件开发功底，精通相应的开发语言，一般的软件测试工程师难以胜白盒测试—主要测试方法代码检查法静态结构分析法静态质量度量法逻辑覆盖法基本路径测试法最为常见的方法是代码检查法白盒测试—代码检查法代码检查包括桌面检查、代码审查和走查，主要检查代码和设计的一致性代码对标准的遵循、可读性，代码逻辑表达的正确性，代码结构的合理性等方面主要是为了找出违背程序编写标准的问题，程序中不安全、不明确和模糊的部分，找出程序中不可移植部分、违背程序编程风格的问题，包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。一般公司都有比较成熟的编程规范，在代码检查的时候，可以根据编程规范进行检查灰盒测试介于黑盒测试、白盒测试之间的一种测试方法。黑盒测试仅仅关注程序代码的功能性表现，不关注内部的逻辑设计、构成情况，白盒测试则仅仅从程序代码的内部构成考虑，检查其内部代码设计结构、方法调用等，而灰盒测试结合这两种测试方法。灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细完整，只是通过一些表征性的现象、事件、标志来判断运行状态灰盒测试灰盒(GrayBox)是一种程序或系统上的工作过程被局部认知的装置。灰盒测试，也称作灰盒分析，是基于对程序内部细节有限认知上的软件调试方法。测试者可能知道系统组件之间是如何互相作用的，但缺乏对内部程序功能和运作的详细了解。对于内部过程，灰盒测试把程序看作一个必须从外面进行分析的黑盒。灰盒测试通常与web服务应用一起使用，因为尽管应用程序复杂多变，并不断发展进步，因特网仍可以提供相对稳定的接口。由于不需要测试者接触源代码，因此灰盒测试不存在侵略性和偏见。开发者和测试者间有明显的区别，人事冲突的风险减到最小。灰盒测试相对白盒测试更加难以发现并解决潜在问题，尤其在一个单一的应用中，白盒测试的内部细节可以完全掌握。灰盒测试结合了白盒测试盒黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。静态测试静态测试，静态的、不执行被测对象程序代码而需找缺陷的过程通俗来讲，就是用眼睛看。通过检查源程序的语法、结构、过程、接口来检查程序的正确性主要目的在于找出不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等问题静态测试的结果可以用于进一步的查错，并为测试用例的选取提供指导静态测试优点：在实际使用中，代码检查比动态测试更有效率，能快速找到缺陷，发现30%～70%的逻辑设计和编码缺陷；代码检查看到的是问题本身而非征兆缺点：代码检查非常耗费时间，而且代码检查需要知识和经验的积累。代码检查应在编译和动态测试之前进行，在检查前，应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表等。动态测试实际地执行被测对象的程序代码，执行事先设计好的测试用例，检查程序代码运行得到的结果与测试用例中设计的预期结果之间是否存在差异，判定实际结果与预期结果是否一致，从而检验程序的正确性、可靠性和有效性，并分析系统运行效率和健壮性等性能状况动态测试由四部分组成：设计测试用例、执行测试用例、分析比较输出结果、输出测试报告动态测试的三种主要的方法：