软件测试技术总结.doc

软件测试技术总结软件测试就是为了发现程序中的错误而分析和执行程序的过程。概念+基本知识+软件开发过程-定义-计划-实现-稳定化-部署一、软件开发模型(四种典型的模型)1、瀑布模型概述：包括计划，需求分析，设计，编码，测试，运行维护六个阶段。六个阶段自上而下、相互衔接，以固定的次序进行。特点：1.阶段的顺序性和依赖性；   2.文档驱动； 3.推迟实现的观点； 4.质量保证。  缺点：不适合需求模糊的系统2、原型模型  概述：先建立一个能够反映用户需求的原型系统，使得用户和开发者可以对目标系统的概貌进行评价和判断，然后对原型系统进行反复的扩充、改进、求精，最终建立符合用户需求的目标系统。特点：1.快速开发工具；       2.循环； 3.低成本。分类：按照对原型的处理方式，可以分为渐进型和抛弃型。3、增量模型概述：在增量模型中每个阶段都生成软件的一个可发布版本，阶段交错进行，版本逐渐完善。同原型模型的最大区别在于，在原型模型中每个阶段发布一个原型而在增量模型中则完成一个正式版本。4、螺旋模型概述：适用于大型软件的开发，它将瀑布模型和快速原型模型结合起来，并加入了风险分析。特点：1.每个阶段都包括制定计划，风险分析，实施工程，评审四个阶段；2.开发过程迭代进行，每迭代一次螺旋线增一周，工程前进一个层次，系统生成一个新版本， 投入新的时间成本，最终得到客户满意的版本。 -软件测试从需求开始：现代的软件测试将测试渗入到软件开发的各个阶段，即使瀑布模型，表面看测试工作是在测试阶段开始的，事实上，在计划、需求、设计阶段，测试人员便已经开始了他们的工作，如：了解软件需求，编写测试计划，搭建测试环境。 二、测试用例1、三要素：前提条件和操作步骤、预期结果、实际结果。 2、必须以需求为依据。三、软件测试分类1、是否关注软件结构和算法  -黑盒测试：基于软件需求的测试方法。  -白盒测试：基于软件内部设计和程序实现的测试方法。2、是否执行被测试软件  -动态测试：在测试过程中执行被测试软件的测试方法。  -静态测试：-不-。3、基于不同的测试阶段：1、单元测试：主要测试软件的单元模块，需要编写额外的测试驱动程序，采用白盒测试的方法，一般由 开发人员完成。2、集成测试：将一些“构件”集成在一起时测试他们是否能正常运行，构件可以是程序模块，也可以是客户机-服务器程序等，需要编写测试仿真程序，采用白盒和黑盒相结合的方式，通常由 开发人员承担。3、系统测试：测试软件系统是否符合所有的需求，包括功能性测试和非功能性测试。一般由独立的测试人员完成，通常采用黑盒测试方法。4、验收测试：(、)与系统测试类似，但由客户或最终用户执行，测试软件是否符合需求规格说明书。5、回归测试：指在软件开发过程中，每次错误被修正后或软件的功能、环境发生变化后进行的测试。四、软件测试的三个步骤：1、测试计划：测试人员首先对需求进行分析，最终定义一个测试集合，通过刻画和定义测试发现需求中的问题，然后根据软件需求同测试主管制定并确认“测试计划”。2、测试设计和开发：软件测试人员根据软件需求和软件设计说明书完成测试用例的设计和必要的测试驱动程序的开发。3、执行测试：需要做的工作包括搭建测试环境、运行测试、记录测试结果、报告软件缺陷、跟踪软件缺陷、分析测试结果，必要时进行回归测试。五、测试工程师的能力要求：1、5C  -Controlled /kEn'trEuld/ 接受管理，有条理的  -Competent /'kCmpitEnt/   了解正确的测试技术  -Critical /'kritikEl/   专注于发现问题  -Comprehensive /.kCmpri'hensiv/ 注意细节  -Considerate /kEn'sidErit/   能够和开发人员很好的交谈2、职业素质 -责任心-学习能力-怀疑精神 -沟通能力 -专注力-洞察力 -团队精神-注重积累六、制定测试计划的五个步骤：1、分析和测试软件需求 2、定义测试策略 3、定义测试环境 4、定义测试管理5、编写和审核测试计划如果在需求分析阶段发现并结果问题需要花费$1，则在设计阶段解决同样的问题需花费$5，在编码阶段需$10，交付后解决同样的问题需花费$200。越早测试越好七、在需求分析过程中测试人员需要进行如下工作：1)理解需求，参与审核需求文档； 2)理解项目的目标、限制，了解用户的应用背景；3)编写测试计划； 4)准备测试资源。八、需求测试-需求测试测试的对象是主意而不是代码，针对文档进行测试。九、好的需求文档的特征 1、具有清晰的格式和文档结构 2、需求的内容正确 3、需求的内容完整4、需求具有可行性需求的必要性 5、对不同的需求优先等级进行定义 6、描述明确7、可证性和可测试性 8、可修改性-可追踪 9、需求文档被及时更新十、需求测试内容1、需求文档是否符合公司的格式要求 2、是否正确3、要保证需求文档中所描述的内容是真实可靠的4、这是“真正的”需求吗？描述的产品是否是要开发的产品？5、需求是否完备？第一个发布的版本是否需要更多的功能？列出的需求可以减少一部分？6、需求是否兼容？需求有可能是矛盾的。7、需求是否可实现？如：需求设想的设备是否比实际运行的要快？需求要求的内存、I/0设备是否太多？需求的输入或输出设备要求的分辨率是否要求过高？8、需求是否合理？在开发进度、开发费用、产品性能、可靠性和内存使用之间存在着平衡关系。9、需求是否可测？对于软件测试人员来说判断需求是否可测是这个过程中最重要的工作。 十一、需求测试方法1、复查review 2、走查walkthrough 3、审查inspection十二、测试策略的内容1、确定测试范围 软件是无法被完全测试的 2、确定测试方法 不同的系统需要不同的测试方法3、定义测试标准 入口标准，暂停和继续的标准，出口标准等  十三、软件测试结束的标准  -基于测试用例的使用规则  1)构造测试用例（由相关人员进行评审）  2)执行测试用例中，当测试用例的不通过率达到20%则拒绝继续测试，待开发人员修正软件后再继续。  3)当功能性测试用例通过率达到100%，非功能性测试用例通过率达到90%时，允许正常结束。  -基于“测试期缺陷密度”规则-含义：对软件测试一个CPU小时发现的缺陷数，比较适用于系统测试  -基于“运行期缺陷密度”规则-含义：把软件运行一个CPU小时发现的缺陷数，比较适用于验收测试    注：一个阶段的出口标准!=下一个阶段的入口标准      系统测试结束的标准!=软件的发布标准       发布标准!=软件0缺陷 -选择测试工具 是否需要，需要什么工具，怎么获取 -降低软件测试代价是企业普遍关注的问题，可通过       a.减少冗余和无价值的测试；       b.减少测试阶段(万般无奈下) 十四、测试环境-基本内容：设备环境、软件环境、数据环境-需考虑的因素 -计算机平台-操作系统 -浏览器 -软件支持平台 -外围设备 -网络环境 -其他专用设备-搭建测试环境时的配置原则：-使用的频度或范围-实效的可能性-最大限度的模拟真实环境十五、测试管理由于测试工程中设计的人员、活动、工具是很多的，在制定测试计划时需要对这些因素进行管理-选择缺陷管理工具和测试管理工具 -定义工作进度-建立风险管理计划  (1)可能遇到的风险  1.由于设计、编码阶段出现大量质量问题，导致测试工作量时间增加  2.开始测试时所需的硬件、软件没有准备好 3.未能完成对测试人员的技术培训  4.测试时的人力资源安排不足 5.测试过程中，发生了大量的需求变更  6.测试过程中，项目的开发计划被大幅度调整 7.不能及时准备好测试所需的环境  8.不能及时准备好测试数据  (2)风险管理的过程  1.识别风险 2.评估风险 3.制定对策 4.跟踪风险+测试设计与开发+总体设计-投入产出：测试设计的输入是测试计划，输出是评审过的测试用例集合-定义设计目标遵循的原则  (-清楚地说明没项测试的目标   -使每项测试的目标单一，可以对应到规格说明书中的一项需求  -只说明测试应该完成什么工作，而不说明如何完成)-流   程：总体设计-开发测试用例-评审测试用例        I.定义设计目标        II.定义输入说明        III.定义测试环境和配置        IV.测试设计文档       V.开发测试用例+测试用例概念：为特定目标开发的测试输入、执行条件和预期结果的集合。+好的测试用例：  1.容易发现软件的错误   2.精确的重复某测试失败的情景，可重复性  3.清晰的定义一个或多个期望的结果   4.没有冗余+测试用例的作用  -指导测试的实施 -作为编写测试脚本的“设计规格说明书”  -评估测试标准的度量基准  -分析缺陷的标准+白盒测试用例设计  +设计方法  +逻辑覆盖法( -语句覆盖 -判定覆盖 -条件覆盖 -判定-条件覆盖  -条件组合覆盖 -路经覆盖  -基本路经法)  +辅助模块设计  (1.驱动模块：相当于被测程序的主程序。接受测试数据，把这些数据传给被测模块然后输出实际测试结果。  2.桩模块：用于调用被测模块调用的子模块。可以做少量的数据操作，不需要把子模块的所有功能都带进来，但不容许什么都不做。)+黑盒测试用例设计  -等价类划分法  -边界值法     “缺陷遗漏在角落里，聚集在边界上。”  -因果图法     弥补等价类和边界值法的不足  -错误推测法-测试用例的管理可以通过配置管理工具cvs,vss,ClearCase等实现，以保证测试是可重复的。+常见错误分析  -用户界面问题   ·输入无合法性检查和值域检查。  ·界面信息不能及时更新，不能正确反映数据状态，甚至对用户产生误导。  ·表达不清或过于模糊的信息提示。  ·要求用户输入多余的本来系统可以自己得到的数据。  ·为了得到某个设置或对话框用户必须做许多冗余的操作，如对话框嵌套太多。         ·不能记忆用户的设置或操作习惯，使每次进入系统用户都需重新操作一次初始环境。  ·不经用户确认就对系统或数据进行了重大修改。  -形象类问题  ·不符合用户的操作习惯。如，快捷键定义不科学不实用，甚至无快捷键。  ·不够专业，缺乏基本知识。  ·界面中英文混杂，甚至拼写错误。  ·说明书或帮助的排版格式不专业：中英文不对应，标点的半全角问题，没有排版准则。  ·界面元素参差不齐，文字不能完全显示。  稳定性问题   ·不可重现的死机，或不断申请但不能完全释放资源，使系统性能越来越低。  ·主系统和子系统使用了相同的临界资源而相互不知道。如：使用相同的类名或临时文件名、使用同样的  数据库字段名或登陆帐号。  ·不能重现的错误，许多与代码中的未初始化变量有关，有些与系统不检查异常情况(网络中断、内存申请  不成功、长时间无响应等)有关。  -其他问题   ·运行时不检查内存、硬盘空间、数据库等。  ·无根据的假设用户环境：硬件/网络情况；有些动态库；假设网络随时都是联通的。  ·提供的版本带病毒。  ·提供错误的版本给测试组或测试用户，或程序员与测试组使用不同版本。  ·用户现场开放和修改，又没有记录和保留。  ·版本中部分内容或接口倒退，或出现版本管理混乱。  ·有些选项永远都是灰的，或有些在该变灰时没变灰。+测试用例的评审  -测试或测试组件完全针对的是需求中列出的功能吗？  -测试组件是否覆盖了所有的需求？  -有冗余的吗？  -每个测试步骤都有清楚描述的预期结果吗？+优先级+3级  优先级1：此测试用例必须执行-2：有时间就执行-3：可以不执行  +5级1：此测试必须通过，否则产品发布存在危险2：在发布前必须执行3：时间允许就执行4：此测试可以在下一次发布或发布后短期内执行5：可以不测试