软件测试导论.

软件测试导论软件测试相关概念定义、目的、对象、分类等软件测试的定义软件测试（Softwaretesting）是软件生存期中的一个重要阶段，是软件质量保证的关键步骤。通俗地讲，软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码进行最终复审的活动。1983年IEEE提出的软件工程术语中给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统或系统部件的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。软件测试的意义爱国者导弹防御系统一个小的系统时钟错误，导致在多哈袭击战中，系统被拖延100多个小时。——1991美国航天局火星极地登陆由于确定何时关闭推进器的程序中某一个数据位被意外修改，飞船在试图登陆火星表面失踪。——1999软件测试的对象12345用户需求用户：我要什么？理解正确性表达正确性需求说明书需求分析员：我可以提供什么？设计说明书设计员：我要软件做什么？源程序程序员：我要要让计算机怎么做？运行结果计算机：程序运行得到的结果理解正确性设计正确性表达正确性理解正确性编码正确性运行正确性输入正确性相符合么？软件测试的目的基于不同的立场，存在着两种完全不同的测试目的。从用户（测试人员）的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立人们对软件质量的信心。软件测试的原则所有的测试都应可追溯到客户需求穷举测试是不可能的严格执行测试计划，排除测试的随意性。应当对每一个测试结果做全面检查。妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。黑盒测试基于软件需求，而不是基于软件内部设计和程序实现的测试方式。白盒测试基于软件内部设计和程序实现的测试方式。单元测试主要测试软件模块的源代码。一般由开发人员而非独立测试人员来执行，因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外的测试驱动程序。集成测试将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可以是程序模块、客户机－服务器程序等等。功能测试测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。一般由独立测试人员执行。系统测试测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。一般由独立测试人员执行，通常采用黑盒测试方式。回归测试指错误被修正后或软件功能、环境发生变化后进行的重新测试。回归测试的困难在于不好确定哪些内容应当被重新测试。验收测试由客户或最终用户执行，测试软件系统是否符合需求规格说明书。软件测试的分类软件测试的分类负载测试测试软件系统的最大负载，超出此负载软件可能会失常。压力测试概念上与负载测试相似，叫法不同。性能测试测试软件在各种状况下的性能，如在正常或最大负载下的状况。易用性测试测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。安装与反安装测试测试软件在“全部、部分、升级”等状况下的安装/反安装过程。恢复测试测试该系统从故障中恢复过来的能力。安全性测试测试该系统防止非法侵入的能力。兼容性测试测试该系统与其它软件硬件兼容的能力。比较测试通过与同类产品比较，考察该系统的优点、缺点。Alpha测试一种先期的用户测试，此时系统刚刚开发完成。Beta测试一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。软件测试方法测试用例设计、缺陷提交法则等测试人员相关素质打破沙锅问到底1.探索精神：软件测试员不会害怕进入陌生环境。2.故障排除能手：软件测试员善于发现问题的症结，喜欢猜谜。3.不懈努力：软件测试员总是不停尝试。他们可能会碰到转瞬即逝或者难以重建的软件缺陷；他们不会心存侥幸，而是尽一切可能去寻找。4.创造性：想出富有创意甚至超常的手段来寻找软件缺陷。5.追求完美：他们力求完美，但是知道某些无法企及时，不去苛求，而是尽力接近目标。6.判断准确：软件测试员要决定测试内容、测试时间，以及看到的问题是否算作真正的缺陷。7.老练稳重：软件测试员不害怕坏消息。8.说服力：软件测试员要善于表达观点，表明软件缺陷为何必须修复，并通过实际演示力陈诉观点。测试相关文档《测试计划》：指明范围、方法、资源，以及相应测试活动的时间进度安排表的文档。《测试方案》：指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。《测试用例》：指明为完成一个测试项的测试输入、预期结果、预期执行条件等因素的文档。《测试报告》：指明执行测试结果的文档。什么是测试用例？所谓的测试用例就是将软件测试的行为活动，做一个科学化的组织归纳。软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。测试用例要素所属模块：按照不同的模块进行测试，为测试用例分组；编号ID：测试用例的唯一性标志；用例描述：简单的语言描述所测试的内容，例如“设置广播服务器网络参数，并测试网络连通性”；重要级别：高、中、低三级；、预置条件：就是执行当前测试用例的前提描述，如果不满足这些条件，则无法进行测试；测试输入：测试用例执行时，需要输入的外部信息。例如：某一个文件，数据记录等；操作步骤：执行当前测试用例所要经过的操作步骤，需要给出每一步操作的详细描述，测试人员根据测试用例操作步骤，完成测试用例的执行预期结果：当前测试用例的预期输出结果，用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。测试结果：Pass、Fail、Block测试用例设计方法等价类划分法边界值分析法场景法错误推测法因果图法判定表驱动法正交试验设计法功能图法等价类划分法等价类划分法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；反之，如果某一类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。边界值分析法由测试工作的经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。边界值分析是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明为检验边界附近的处理专门设计测试用例，常常取得良好的测试效果。场景法现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。软件缺陷——bug五级规范七级规范（bugzilla严重级别，Severity）bugzilla优先级（Priority）问题级别描述问题严重等级级别定义描述1导致系统崩溃、死机；出现不可挽救的数据丢失或损坏、内存泄露；blocker中断缺陷Blocksdebelopmentand/ortestingwork.妨碍开发和测试，非常严重。例如：程序不能运行起来，服务不能启动，或启动以后立刻崩溃。P12导致程序模块丢失或未实现；软件错误导致数据丢失；用户需求未实现；critical临界缺陷crashes,lossofdata,severememoryleak.软件崩溃、丢失数据或严重的内存泄漏等。例如：本应7*24小时运行的程序在运行一天以后崩溃、录像服务丢失录像数据等。P23发现影响被测功能正确实现的问题；major较严重缺陷majorlossoffunction.功能主体受损失。例如：原本设计的一个功能不能实现或实现得不好，或影响实际使用效果的缺陷。P3normal普通缺陷foranapplicationcrashorotherissue.4一般性错误或者功能实现不完善等；minor次要缺陷minorlossoffunction,orotherproblemwhereeasyworkaroundispresent.功能受到较小的影响；或其他问题，可以通过简单的方法解决；例如：较小功能按钮的失效等。P4trivial轻微缺陷cosmeticproblemlikemisspelledwordsormisalignedtext.只存在于表面的问题，比如错别字、拼写错误或界面对齐不好等。5一些建议性的错误；enhancement测试建议Requestforenhancement.要求新增的功能，或者测试的建议。P5Bug描述要素bug六要素录入要求范例摘要必选项。简要、准确、完整的描述错误实质。需要注明出现问题的模块、页面以及按钮名称等，异常情况需在摘要后加上“（异常）”，建议类的问题需要在摘要后加上“（建议）”加以区分。摘要：（异常）客户端-录像回放，录像下载过程中，异常停止下载。重建必选项。有层次的简述出现bug的操作步骤。要求完整记录与bug出现有关的操作，描述完毕后可根据重建的内容自行操作一遍以确认无误。重建：客户端，录像下载，11月28日18:00以后选择70多个录像文件开始下载，进行老化测试。11月29日早晨发现，客户端上显示停留在一个录像文件下载0%的进度，是正在下载的状态，但无下载速度，且没有再本地生成文件。概率可选项。用于区分问题的出现概率。不写时，出现概率应为默认的100%，如果并非每次都出现或者是异常问题一定要注明，可用百分比来表述，如两次重现操作中有一次可以出现该问题，则概率为50%。概率：测试过程中在单台客户端出现三次。隔离可选项。用于区分问题的重要程度，并能帮助开发定位问题。无法隔离的bug和可以很容易隔离的bug对于项目的重要程度是不一样的。隔离：停止不下载的文件，重新选择一个录像文件开始下载以后可以正常继续。分析可选项。记录个人在测试中的分析过程，通过逻辑性的语言描述猜测问题可能出现的原因或相关联产生的问题等。分析：经抓包分析，录像服务器没有收到ack，可能因此导致此下载会话异常没有开始且没有断开。附件可选项。尽可能的记录图片、dump文件（异常崩溃时必须有）、抓包文件等附件，附件可以帮助测试人员尽可能全面的向开发人员描述问题，降低沟通成本。附件：录像异常停止下载.jpg，录像异常停止下载.pcapBug描述的5C原则Correct：(准确)每个要素的描述准确，不会引起误解；Clear：(清晰)每个组成部分的描述清晰，易于理解；Concise：(简洁)只包含必不可少的信息，不包含任何容易冗余信息，如操作过程中与bug的出现无关的操作步骤。Complete：(完整)包含重现缺陷的完整步骤，和其他本质信息。Consistent：(一致)按照一致的格式书写全部的缺陷模块。如客户端-录像回放-录像下载，或服务器-会话服务器-会话保活。性能测试性能测试通常会使用特定的测试工具，来模拟超常的数据量、负载等，监测系统的各项性能指标，如CPU和内存的使用情况、响应时间、反应速度等。性能测试的目的：为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。性能测试指标的来源：用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）主要的性能指标：服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间压力测试在一种需要反常（如长时间的峰值）数量、频率或资源的方式下，