软件测试就业培训课程

系统测试项目实施上海博为峰软件技术有限公司SHANGHAIBWFSOFTWARETECHCO.
,LTD.
2012-02-15系统测试过程上海博为峰软件技术有限公司SHANGHAIBWFSOFTWARETECHCO.
,LTD.
2012-02-15瀑布式开发V模型开发敏捷开发XPScrum过程模型系统测试过程的四大活动系统测试计划确定测试范围,制订过程标准,分配工作,安排进度等系统测试设计制定测试方案,分解测试需求系统测试实现设计测试用例系统测试执行开展测试执行活动,提交缺陷报告、进行缺陷跟踪,提交测试日报和测试报告系统测试过程角色(Roles)职责(Responsibility)入口准则(EntryCriteria)出口准则(ExitCriteria)输入(Inputs)输出(Outputs)工具(Tools)方法(Method)培训(Training)模板(Template)度量(Measurements)检查表(CheckLists)系统测试流程中的要素什么是入口准则(EntryCriteria)开始某项活动所必需满足的条件或者环境.
各个阶段的入口准则系统测试计划阶段软件项目计划(PP)的开发计划(SDP)完成软件项目计划(PP)的测试计划(SVVP)完成系统测试设计阶段需求分析(SRS)完成,并建立了需求基线系统测试实现阶段系统测试方案(STS)完成,并建立基线系统测试执行阶段集成测试完成系统测试入口准则什么是出口准则(ExitCriteria)退出或者结束某些活动时所必需满足的条件或者环境.
各个阶段的出口准则系统测试计划阶段完成系统测试计划(STP)的编写,并通过评审系统测试设计阶段完成系统测试方案(STS)的编写,并通过评审系统测试实现阶段完成系统测试用例(STC)、系统预测试项、系统测试规程、系统测试代码及相关设计文档、系统测试工具,通过上述文档的评审系统测试执行阶段完成系统测试执行,达到系统测试计划中的测试通过准则要求,并通过系统测试报告(STR)的评审系统测试出口准则什么是输入开展某些活动时所参考的资料、或者所需要加工的原材料.
各个阶段的输入系统测试计划阶段开发计划、测试计划、需求规格说明书系统测试设计阶段需求规格说明书、系统测试计划系统测试实现阶段需求规格说明书、概要设计说明书、详细设计说明书、系统测试计划、系统测试方案系统测试执行阶段系统测试计划、系统测试方案、系统测试用例、系统预测试项、系统测试规程、集成测试报告系统测试输入什么是输出完成某些活动后可以提交的工件或产出.
各个阶段的输出系统测试计划阶段:系统测试计划系统测试设计阶段:系统测试方案系统测试实现阶段:系统测试用例、系统预测试项、系统测试规程、系统测试代码及相关设计文档、系统测试工具及相关设计文档、使用说明、评审记录系统测试执行阶段:系统预测试报告及转系统测试评审表、缺陷报告、测试日报、系统测试报告及系统测试报告评审表系统测试输出系统测试计划模板系统测试方案模板系统测试用例模板系统测试日报模板系统测试报告模板缺陷记录模板系统测试的模板系统测试计划检查表系统测试方案检查表系统测试用例检查表系统测试报告检查表系统预测试检查表转系统测试检查表系统测试的检查表(CheckLists)系统测试计划上海博为峰软件技术有限公司SHANGHAIBWFSOFTWARETECHCO.
,LTD.
2012-02-15明确系统测试的组织形式明确系统测试的测试对象完成系统测试的需求跟踪明确系统测试的通过/失败标准明确系统测试的挂起标准及恢复的必要条件明确系统测试工作的任务分配明确系统测试结束后应交付的测试工作产品系统测试计划要明确的内容确定系统测试计划执行过程中的组织结构及结构间关系,以及所需要的组织独立程度.

确定系统测试过程与其他过程如开发、项目管理、质量保证、配置管理之间的关系.

确定系统测试工作中的沟通渠道,确定测试人员发现并监督问题解决的权利,确定批准测试输出工作产品的权利.

明确系统测试的组织形式系统测试对象在规定的条件下要度量的软件外部质量特性的标识集.
软件特性是一组表现软件质量特征的属性包括内部质量属性、外部质量属性和使用质量属性系统测试主要针对系统外部质量属性进行测试明确系统测试的测试对象(1)明确系统测试的测试对象(2)软件特性和测试类型之间的关系:一个软件特性可能有多种测试方法,取决于软件项目的具体要求.
不同的软件特性可以用不同的测试方法,同样的测试方法可能针对多个软件特性.

明确系统测试的测试对象(3)软件特性和常用系统测试类型的对应关系:功能性功能测试、安全性测试、互连测试可靠性可靠性测试、启动/停止测试、恢复测试、健壮性测试、备份测试易用性可用性测试、文档测试、安装性测试效率强度测试、性能测试、指标测试、内存泄漏测试、容量测试、压力测试维护性可维护性测试可移植性配置测试、兼容测试、安装测试明确系统测试的测试对象(4)如何确定本次系统测试对象参照软件质量模型中的6个特性、27个子特性分析《软件需求规格说明书》及软件产品所应遵守的相关规范、标准.

将分析出的软件功能性需求和各非功能性需求对应到各特性下.
将各特性下的比较大的需求进行细化,得到最终的系统测试项.
确定本次系统测试的测试范围和测试类型.
明确系统测试的测试对象(5)进行系统测试需求分析,确定系统测试项与需求规格说明书(SRS)中的需求之间的对应关系.

如何进行测试需求分析收集各种需求信息确定原始测试需求在需求的基础上做细化,得到测试点从ISO9126质量模型进行分析,考虑各种特性从功能交互法进行分析,考虑功能之间的相互影响从用户关联法进行分析,考虑各种类型的用户合并重复的测试点,得到测试项将测试项划归到各个测试特性(测试类型)中如果粒度还是太大,还要将测试项细分为测试子项依此类推,得到测试子项的子项,直到符合要求建立《系统测试项—需求跟踪矩阵表》完成系统测试的需求跟踪(1)如果SRS文档过于简单,或者缺少SRS文档,怎么办建议自己通过各种其他方式整理、收集需求,具体来源:参考相关的用户手册(Manual)参考行业内标准/国际规范参考竞争对手的资料参考相关的继承性文档借鉴经验收集的内容包括:系统架构(S)功能特性(F)数据处理(D)运行平台(P)使用的用户(O)完成系统测试的需求跟踪(2)测试标准是客观的陈述,该陈述指明了判断/确认测试何时结束.
该标准可以只考虑测试活动的度量,也可能需要结合所测试的应用程序的质量度量来考虑.

测试标准可以是一系列的陈述或对另一文档(如软件企业系统测试过程指南或系统测试标准)的引用.

明确系统测试的通过/失败标准(1)定义每个项目的测试通过/失败的准则:用例的执行情况要达到何种目标所有计划的测试用例都已经执行,或者高优先级的用例要达到多少的覆盖率;覆盖率要达到什么目标所有的功能需求都被覆盖;所有的性能需求都被覆盖;达到何种测试的质量目标所有计划的测试用例都已经被重新执行一次,并且没有发现新的缺陷;所有的缺陷都已经定位;使用何种缺陷分析方法判断测试是否可以退出通过缺陷分析中的Gompertz模型/Rayleigh分析,可以得知测试是否已经充分,是否可以退出.

明确系统测试的通过/失败标准(2)测试挂起当测试过程无法进行下去或者失去了继续进行测试的意义时,可以将测试活动挂起.

测试恢复当被挂起的测试活动所需要的条件得到了满足时,测试活动恢复执行系统测试的挂起标准及恢复的必要条件(1)挂起条件:指明挂起测试的准则,即在什么情况下将挂起全部或部分测试项的测试.

恢复条件:指明恢复测试的标准及其必须重复的测试活动.
为什么要确定通过/失败标准和挂起/恢复条件是保证测试顺利执行的前提在测试执行时应时刻用这些条件来提醒自己与项目组建立共同的理解系统测试的挂起标准及恢复的必要条件(2)进行系统测试任务划分分析每个任务,确定以下内容:任务所采用的方法和标准任务的输入和输出任务所需的资源任务的人员分工任务的时间和进度安排任务的风险和应对措施明确系统测试工作任务分配(1)系统测试任务:按系统测试自身的阶段划分测试计划、测试设计、测试实现、测试执行按测试特性划分功能测试、性能测试、安全性测试等按测试对象功能属性划分业务处理特性、配置管理特性、告警特性等业务之间的组合关系顺序的、并行的、嵌套的、迭代的、有条件引发的明确系统测试工作任务分配(2)如何划分测试任务按测试阶段:测试计划测试设计测试实现测试执行按被测对象的功能属性:子系统1子系统2.
.
.
按测试特性:功能测试性能测试安全性测试.
.
.
明确系统测试工作任务分配(3)明确任务所需要的方法和标准为每个任务确定具体的实施方法明确执行该任务时,应采用的方法以及所应遵循的标准明确任务的输入和输出任务输入:执行任务所需要依据的资料任务输出:任务执行完后应该输出的工作产品,包括测试文档、测试脚本、测试报告、测试工具等等明确系统测试工作任务分配(4)明确任务所需的资源人力资源估计每个活动所需要的人员能力每个活动所需要的人工数量:按人工时按人工日物力资源估计硬件和软件环境测试工具、仪器等测试物料明确系统测试工作任务分配(5)明确任务的人员分工将任务划分结果依据工作量估计具体分配到人按测试阶段:测试计划:由测试经理A负责测试设计:由高级测试工程师B负责测试实现:由测试工程师C负责测试执行:由测试员D负责按被测对象的功能属性:子系统1:由测试工程师A负责子系统2:由测试工程师B负责按测试特性:功能测试:由测试工程师A负责性能测试:由测试工程师B负责安全性测试:由测试工程师C负责.
.
.
明确系统测试工作任务分配(6)明确任务的时间和进度安排明确系统测试工作任务分配(7)计划进度表的形式甘特图WORD图表EXCEL表明确系统测试工作任务分配(8)估计任务的风险和应对措施:估计系统测试各任务安排中的风险和假设,确定本计划中哪些风险较大,并且为每一个风险指定应急处理计划.

应考虑到的风险系统测试在现有人力物力时间条件下是否可行系统测试工具是否满足需求,工具的使用效果如何,需要多长时间熟悉测试者是否具备一定的技术水平,是否已有测试经验测试中是否有足够的技术支援版本发布是否会延期明确系统测试工作任务分配(9)风险估计风险的三维空间:项目结构项目规模技术熟悉程度常用风险分析方法:JudgmentandInstinctDollarEstimationIdentifyingandWeightingRiskAttributes明确系统测试工作任务分配(10)确定各测试任务完成后应交付的测试文档、测试代码及测试工具等测试工作产品,这些工作产品可以作为测试任务的考评.
一般包括如下工作产品:系统测试计划系统测试方案系统测试用例系统测试规程系统测试日志系统测试报告系统测试输入及输出数据系统测试工具自动化测试脚本系统测试结束后应交付的工作产品IEEE829什么是IEEE829IEEE829-1998,也被称做829软件测试文档标准,作为一个IEEE的标准定义了一套文档用于8个已定义的软件测试阶段,每个阶段可能产生它自己单独的文件类型.
这个标准定义了文档的格式但是没有规定它们是否必须全部被应用,也不包括这些文档中任何相关的其它标准的内容.

IEEE829-1998文档系列测试计划测试设计规格测试用例规格测试过程规格测试项传递报告测试记录测试附加报告测试摘要报告系统测试计划文档的编写(1)测试计划是一个管理计划的文档,包括:测试如何完成谁来做测试将要测试什么测试将持续多久(虽然根据可以使用的资源的限制而有变化)测试覆盖度的需求,例如所要求的质量等级系统测试计划文档的编写(2)系统测试计划模板包含的要素:目标概述组织形式测试对象需求跟踪测试通过/失败的标准测试挂起的标准及恢复的必要条件测试任务安排应交付的测试工作产品工作量估计资源的分配系统测试计划文档的模板通过系统测试计划活动需要达到的目标:所有测试需求都已被标识出来;测试的工作量已被正确估计并合理地分配了人力、物力资源;测试的进度安排是基于工作量估计的、适用的;测试启动、停止的准则已被标识;测试输出的工作产品是已标识的、受控的和适用的.
《系统测试计划》-目标概述包含两个部分的内容项目背景简要描述项目背景、项目的主要功能特征、体系结构及项目的简要历史等.

目的是帮助参与项目的人员能够更好的理解测试计划的内容.
范围指明该系统测试计划适用于哪些对象和哪些范围.
《系统测试计划》-概述组织形式描述系统测试活动中确定的组织结构及结构间关系、各组织结构及成员的职责.

《系统测试计划》-组织形式测试组成员结构测试经理(TestManager)测试组长(TestLead)高级测试工程师(SeniorTestEngineer)测试员(JuniorTestEngineer)组长职责制订测试计划;给测试工程师分配任务并依据制定的计划指导和监控他们的工作;与开发组协调和沟通,例如确定版本发布日期、沟通版本质量进展、缺陷发展趋势;组织测试设计及相关文档的编写和评审;组织本组进行相关需求跟踪;组织本组进行缺陷分析等质量活动;向测试经理等高层领导汇报本组工作.
.
.
.
.
.
《系统测试计划》-测试组测试对象应列出:系统测试计划活动中所有功能测试项和非功能测试项测试项中的哪些特性和特性组合将不被测试,并说明不被测试的原因在这里所列的测试项仅仅是为了表达应测试什么,至于如何测试可以在测试方案中进行描述.

《系统测试计划》-测试对象(1)例如业务功能业务流程数据库事务域值合法性用户界面对象状态窗口模式菜单标准尺寸的控件/文字性能在3秒内对用户登陆请求给出响应当系统内存低于32M的情况下运行应用程序,考察其性能指标为设计规定是1,000,000条记录的系统增加1,000,001条记录配置在windows98系统下进行配置测试在Unix系统下进行配置测试安装新安装(典型安装、定制安装)光盘升级安装网络升级安装《系统测试计划》-测试对象(2)建立需求跟踪矩阵(RTM)《系统测试计划》-需求跟踪需求标识需求项系统测试项标识系统测试项描述iPhone4S_Phone_01通话功能iPhone4S_ST_Phone_Call拨打电话iPhone4S_ST_Phone_Take接听电话iPhone4S_Phone_02短信功能iPhone4S_ST_Msg_New新建短信iPhone4S_ST_Msg_Reply回复短信iPhone4S_ST_Msg_Read接收短信通过标准测试过程的通过/失败标准被测对象的通过/失败标准系统测试活动的通过标准举例:对于所有1-2级用例100%覆盖,3-4级用例60%覆盖(根据测试时间安排确定);或者本轮测试重点特性用例100%覆盖;所有的功能需求、性能需求都被覆盖;系统测试没有发现致命问题、严重问题在5-10个之间、一般问题在10-20个之间;测试过程中缺陷率达到公司系统测试质量标准(通过Gompertz模型/Rayleigh分析)《系统测试计划》-测试通过/失败的标准系统测试挂起标准举例:基本功能测试不能通过;出现致命问题导致30%用例被堵塞,测试无法执行下去.
.
.
.
.
.
系统测试恢复条件举例:导致测试堵塞的问题被修复,并通过了回归测试;.
.
.
.
.
.
《系统测试计划》-测试的挂起和恢复测试任务安排描述系统测试活动中所明确的测试任务分工.
例如可以分为四个基本的测试任务:计划测试、设计测试、实现测试、执行测试,每个任务还可以细分为子任务.

对每项任务都应从7个主题进行描述:任务:用简洁的句子对任务加以说明;方法和标准:指明执行该任务时,应采用的方法以及所应遵循的标准;输入/输出:给出该任务所必需的输入及输出;时间安排:给出任务的起始及持续的时间,为方便文档维护,建议采用相对时间,即任务的起始时间是相对于某一里程碑或阶段的相对时间;资源:给出任务所需要的人力和物力资源,工作量应明确到"人天";风险和假设:指明启动该任务应满足的假设以及任务执行可能存在的风险;角色和职责:指明由谁负责该任务的组织和执行,以及谁将担负怎样的职责;《系统测试计划》-测试任务安排(1)例如:按被测对象分工《系统测试计划》-测试任务安排(2)APaDaEaBaRaBPbDbEbBbRbPcDcEcBcRc例如:按测试活动分工《系统测试计划》-测试任务安排(3)APaDaEbBbRaBPaDaEbBbRaPaDaEbBbRa列出系统测试活动中的所有交付物《系统测试计划》-应交付的测试工作产品序号交付工作产品提交时间提交人员1《ThinkSNSv1.
6系统测试计划》2012-1-23张无忌2《ThinkSNSv1.
6系统测试方案》2012-2-6杨逍3《ThinkSNSv1.
6系统测试用例》2012-2-18范遥4《ThinkSNSv1.
6系统测试执行记录》2012-3-28谢逊5《ThinkSNSv1.
6系统缺陷报告》2012-4-9谢逊6《ThinkSNSv1.
6系统测试日报》2012-4-18谢逊韦一笑7《ThinkSNSv1.
6系统测试报告》2012-5-11殷天正根据安排的任务,估计各任务的工作量,具体到"人·天"《系统测试计划》-工作量估计序号任务负责人工作量(人天)1计划测试张无忌152设计测试杨逍123实现测试范遥394执行测试谢逊52总计118所有任务需要的资源人员及培训要求测试环境测试工具测试仪器或材料其他需求《系统测试计划》-资源分配系统测试设计上海博为峰软件技术有限公司SHANGHAIBWFSOFTWARETECHCO.
,LTD.
2012-02-15系统测试计划对系统测试全过程的组织、资源、原则等进行规定和约束,并制定系统测试全过程各个阶段的任务以及时间进度安排,并提出对各项任务的评估、风险分析和管理需求.

系统测试方案描述系统需要测试的特性,采用的测试策略和方法,测试环境的部署和规划,测试工具的设计和选择,测试用例的设计方法,以及测试代码的设计方案.

二者的区别系统测试方案需要在系统测试计划的指导下进行,系统测试计划提出"做什么",而系统测试方案明确"怎么做".

系统测试计划通常由管理者(测试经理)来实施,系统测试方案通常由技术专家(测试系统分析师)来实施.

系统测试方案和系统测试计划的区别系统测试方案模板包含的要素:概述被测对象应测试特性不被测试的特性测试模型测试组网图/结构关系图测试原理/策略操作流程测试需求环境需求被测对象需求测试工具需求测试代码需求测试数据需求测试设计测试工具设计测试代码设计测试用例设计测试规程设计系统测试方案文档的编写概述包含的内容:目的适用对象适用范围一个例子:CounterV1.
0是TProject项目的开发和测试对象,CounterV1.
0没有商用的需求,仅提供给培训学员,作为测试培训的对象,它是一个完全独立的产品.

本文为CounterV1.
0单元测试方案,将用来指导CounterV1.
0单元测试用例设计、驱动函数和桩函数的设计以及单元测试的执行.
适用对象为参与CounterV1.
0单元测试的开发人员和测试人员.
《系统测试方案》-概述测试对象或测试项对于被测产品及其模块的概述.
需求要素使用背景主要功能实现结构历史《系统测试方案》-被测对象应测特性(Featurestobetested)详细描述本次系统测试中,所有应该被测试的功能和特性,以及特性的组合.

还应指出哪些特性可以在本次系统测试中重点测试,哪些特性只做基本功能验证.

测试用例的设计应当据此进行.
不需测试的特性(Featuresnottobetested)为了避免误解和防止不切实际的预期,应该定义产品中哪些部分是不需要或者无法进行的测试.

这可能是由于资源限制或者技术原因所导致的.
注意:与系统测试计划所列出的应测特性和不被测试特性不同.
在系统测试计划所关心的是大的特性,而方案里是更为具体的关于大的特性的分解.

《系统测试方案》-应测特性和不需测试的特性可以从下面三个方面描述测试模型系统测试组网图测试中所有项目用到的组网图统一放在此处,并注明是用于哪个测试项目.

测试对象在测试组网图中的位置应符合需求规格说明书的要求.
系统测试原理描述本阶段测试实现的工作原理和基本思路,指出用于测试的测试活动、技术和工具.

包括要用到的专门技术,例如异常测试、压力测试模型等,以及用于分析测试结果的方法.

操作流程描述基本测试项目的操作流程和状态转移图等(可以取代测试规程).
《系统测试方案》-测试模型(1)例子《系统测试方案》-测试模型(2)例子(续)《系统测试方案》-测试模型(3)测试需求是根据本阶段的测试目标从不同角度明确本阶段的各种测试需求因素.

环境需求指出必需的和希望的测试仪器、设备、工具需求和其它需求.
被测对象特殊要求为完成测试是否需要对被测对象以及相关对象作特殊要求,例如对相关对象的版本要求、接口协议要求等.

测试工具要求如果采用自动化测试,在此处列出对于测试工具的需求,测试工具包括自主开发,商用,二次开发工具等测试代码要求如果需要被测对象插装测试代码、进行可测性设计,在此处列出对于测试程序、测试接口的需求.

测试数据要求为执行各测试项目需要在测试前预先设置的数据,避免测一项改一次数据,特别是在自动化测试中,或者仪器测试中需要定义的测试套和测试数据库.

其他要求确定需要的特殊工具,确定其他任何测试需要(如,办公室空间需要等),确定对测试小组来说目前还没有但是必需的需求的来源.

测试需求必须确保对项目需求规格的的跟踪与覆盖.
《系统测试方案》-测试需求测试设计描述测试各个阶段需要运用的测试要素,包括测试用例、测试工具、测试代码的设计思路和设计准则.

为每一组重要的特性或特性组合指定一个可以保证这些特性被足够地测试的途径,应详细的指出用于该组特性测试的测试活动、技术、工具.

包括要用到的专门技术、用于分析测试结果的设计方法(例如:用比较程序或用观察法进行分析)等应在此确定.

测试设计描述的细致程度应能够用于确定主要的测试任务和估计每一个任务的时间需要.

指出最低限度测试完备性,确定判断测试行为完备性的技术手段(例如,某软件的完备性判断条件为每条语句至少被执行一次).
确定任何额外的完成准则(例如,不同级别的错误数目应该低于某一数值).
用于跟踪需求修改的技术手段也应被指定.

《系统测试方案》-测试设计(1)测试工具设计描述将要采用的测试工具的设计要点、设计思路.
如有具体相关文档,需指明文档引用关系.
.
描述举例:本次测试需要功能测试自动化工具的支持,该工具需要满足如下需求:脚本的录制和回放、脚本的编辑、日志功能、支持Delphi控件.

本次测试还需性能测试工具的支持,该工具需要满足如下需求:脚本的录制和回放、脚本的编辑、接口协议数据的录制和编辑、日志功能、性能的监控.

目前采用业内主流的商用工具QTP和LoadRunner来完成上述测试工作,并且这两个工具满足上述要求.
《系统测试方案》-测试设计(2)测试代码设计描述将要插装的测试代码或测试脚本的设计要点和设计思路.
如有具体相关文档,需指明文档引用关系.
测试代码种类打印代码打印函数打印宏打印到文件使用断言触发性代码灵活添加代码描述举例本次测试需要编写自动化测试脚本,需要对以下基本操作进行脚本录制形成脚本库:登录系统:脚本函数名为Login()注册用户:脚本函数名为AddUser()删除用户:脚本函数名为DelUser()修改用户:脚本函数名为ModUser()《系统测试方案》-测试设计(3)测试用例设计描述测试用例设计总体原则、测试项目划分依据.
测试项目(TestItems)的设计应体现和跟踪需求规格说明书的内容.
在测试用例的设计上,要能总结测试用例的共同属性,如共同的约束条件、共同的环境需求、共同的程序上的需求、共同的测试用例依赖条件.

在考虑测试用例规划、分类原则的同时,还要考虑好用例编号的规则,并进行相应描述.

对测试用例按照测试项目进行分类罗列和简单描述,并遵从唯一性标识原则.

《系统测试方案》-测试设计(4)测试规程设计主要描述系统测试用例的执行过程,包括如何搭建系统测试环境,先执行哪些测试用例,再执行哪些用例,如何记录测试结果等.

关注点测试规程编号测试目的相关测试用例特殊需求测试步骤《系统测试方案》-测试设计(5)系统测试实现上海博为峰软件技术有限公司SHANGHAIBWFSOFTWARETECHCO.
,LTD.
2012-02-15系统测试用例的设计根据是系统的需求规格说明书、各种规范系统测试用例的依据决不是软件的本身系统测试用例不仅仅包括功能测试用例,同时还应该包含属性测试用例系统测试用例编写原则一、根据ISO9126质量模型分析《需求规格说明书》,将需测试的需求项归纳到各特性、子特性下:系统测试用例编写思路(1)质量特性质量子特性测试项功能性适合性准确性互操作性安全性功能依从性效率时间特性资源利用性…………二、对分析出来的测试需求项进行归纳、总结,确定需要进行何种类型的测试,并把各测试项归类到各测试类型下:功能测试性能测试负载测试压力测试容量测试安全性测试界面测试易用性测试安装测试系统测试用例编写思路(2)配置测试兼容性测试异常测试易恢复性测试备份测试健壮性测试文档测试在线帮助测试网络测试.
.
.
.
.
.
三、对各测试类型下的测试项细分,形成为测试子项:系统测试用例编写思路(3)需求标识需求项系统测试项标识系统测试项描述系统测试子项标识系统测试子项描述iPhone4_01通话功能i4_ST_Phone_Call拨打电话i4_ST_Phone_Call_Mobi拨手机号i4_ST_Phone_Call_Urge紧急电话i4_ST_Phone_Take接听电话i4_ST_Phone_Take_Stan待机接听i4_ST_Phone_Take_Onli联机接听iPhone4_02短信功能i4_ST_Msg_New新建短信i4_ST_Msg_New_Dire直接新建i4_ST_Msg_New_Indi间接新建i4_ST_Msg_Reply回复短信i4_ST_Msg_Reply_Dire直接回复i4_ST_Msg_Reply_New新建回复i4_ST_Msg_Read接收短信i4_ST_Msg_Read_Txt接收文本i4_ST_Msg_Read_Mms接收彩信四、对各测试子项对应的具体需求规格进行分析,利用各种系统测试用例设计方法,从各角度设计用例去对需求规格进行覆盖,从而达到对SRS的充分覆盖:等价类划分法边界值分析法判定表分析法因果图分析法正交试验法流程分析法(场景法)状态迁移图法输出域覆盖法错误猜测法系统测试用例编写思路(4)系统测试用例应达到如下目标:每个需求都有测试用例覆盖到,即测试用例对SRS达到100%覆盖;达到质量部门规定的用例密度,例如"用例数/KLOC";用例要尽量均匀分布在每个需求中.
否则单独的用例密度这个指标是没有意义的.

系统测试用例编写思路(5)系统测试执行上海博为峰软件技术有限公司SHANGHAIBWFSOFTWARETECHCO.
,LTD.
2012-02-15系统测试执行活动就是按事先制定的系统测试计划,依据系统测试用例,完成测试的各项操作任务.

系统测试执行阶段应完成:测试环境的准备系统测试执行操作系统测试执行记录和缺陷记录缺陷跟踪和回归测试测试日报(DailyReport)测试报告(TestReport)系统测试执行阶段的工作内容系统测试执行的输入系统测试计划(SystemTestPlan)系统测试方案(SystemTestStrategy)系统测试用例(SystemTestCases)系统预测试项系统测试规程集成测试报告系统测试执行的输出《软件系统预测试报告》及《转系统测试评审表》《缺陷报告》及《测试日报》《系统测试报告》及《软件系统测试报告评审表》系统测试执行的出口准则完成系统测试,达到系统测试计划中的测试通过准则要求通过《系统测试报告》的评审系统测试执行过程的输入、输出和出口准则搭建系统测试环境系统测试预测试转系统测试评审执行系统测试,进行系统测试记录,填写测试日报.
提交缺陷报告并反馈和跟踪缺陷解决,进行缺陷管理撰写并评审系统测试报告系统测试执行的活动系统测试执行活动的流程图根据系统测试方案,搭建系统测试环境是系统测试执行的一个重要步骤,测试环境适合与否会严重影响测试结果的真实性和正确性.

系统测试环境除支撑被测软件运行的硬件设备外,还应包含被测软件,和被测软件配套的操作系统、数据库等系统软件,备料、测试数据、相关资料文档等.

系统测试环境的部署一个常见的棘手问题:令人抓狂的回归测试"踢皮球"现象:测试指派给开发修复的Bug,被开发修改后置为修复状态,但测试在确认时发现并未修复,于是重新打开,但开发再次修复……测试再次重新打开……为了保证系统测试的顺利进行,应该制定转系统测试流程,因为没有流程保证的系统测试会出现各种情况影响测试质量,例如:开发提供了错误的版本;开发合并版本分支时部分修改没有合入;开发为修改缺陷而新引入的致命错误导致系统测试无法进行;测试变成了开发的调试;不断的修改、更换版本引起部分测试结果失效(因为无法保证在一个前后一致的版本上进行测试)转系统测试流程(1)转系统测试流程为:开发部门编译合并版本;开发部门进行冒烟测试;开发部门修复自测发现的错误,并提供正式版本;开发部门提交《转系统测试申请》并提交相关文档;测试部门进行系统预测试(从系统测试用例中提取基本功能验证用例);版本转系统测试评审通过转为正式的系统测试不通过则打回版本,要求开发重新发布转系统测试流程(2)系统测试预测试的目的是验证软件系统基本功能或预测主要的系统功能,以确保其后的系统测试执行能够顺利进行.

系统测试预测试应在开发项目组提出软件版本转系统测试申请后进行,主要是完成转系统测试评审需要输入的《系统预测试报告》.

执行验证软件系统基本功能活动的主体可以是软件开发项目组,也可以是软件测试项目组或联合的组织.

系统测试预测试评审责任主体为软件测试项目组,需要完成软件转系统测试评审表.
软件版本转系统测试评审通过后,才能启动执行系统测试过程.
启动执行系统测试过程后,系统预测试相关的软件版本,测试代码,文档,环境等均应在配置管理中基线化.

转系统测试评审按照《系统测试规程》执行系统测试,进行系统测试记录,每日提交测试日报.

执行系统测试的过程中,软件测试项目组对于发现的产品缺陷,要及时填写缺陷报告,并跟踪问题的解决,做好问题跟踪和解决记录.

测试项目组要进行缺陷管理,通过问题分析回溯软件产品产生问题的原因,通过缺陷分析来判断软件产品与设计要求的符合度.

如果由于缺陷较多或较为严重,使得部分系统测试工作无法继续执行,则软件测试项目组根据问题严重程度,有权暂停该部分的测试,或将软件版本返回软件开发项目组,重新组织进行转系统测试评审.

执行系统测试依据系统测试计划的测试通过准则,结束系统测试后,撰写系统测试报告.

系统测试报告需要通过评审,责任人为软件测试项目组,由软件开发项目组、配置管理小组、QA参与.

评审如果不通过,则系统测试报告退回.
在评审不符合项和问题解决后再提交评审申请,或重新启动系统测试过程.

在评审通过后,系统测试相关文档、代码、工具等均需跟随软件代码以及开发文档一起完成配置的基线化,系统测试过程结束.

系统测试报告的编写和评审系统测试环境要素硬件环境指测试必需的服务器、客户端、网络连接设备,以及测试仪器、打印机/扫描仪等辅助硬件设备所构成的环境.

软件环境指被测软件运行时的操作系统、数据库、共存软件、测试工具及相关手册等其他应用软件构成的环境.

在实际测试中,软件环境又可分为主测试环境和辅测试环境.
主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境;辅测试环境常常用来满足不同的测试需求或特殊测试项目.
系统测试环境符合软件运行的最低要求.
测试环境首先要保证能支撑软件正常运行.
选用比较主流的操作系统和软件平台例如,一个软件若声称支持"WindowsXP/WindowsServer2003/WindowsVista/Windows7"和"MicrosoftOffice2000/2003/2007/2010",一般我们会采用如"WindowsXP+Office2007"的环境.
营造相对简单、独立的测试环境.
除了操作系统,测试机上只安装软件运行和测试必需的软件,以免不相关的软件影响测试实施.

无毒的环境利用有效的正版杀毒软件检测软件环境,保证测试环境中没有病毒.
配置主测试环境遵循的原则兼容性测试在满足软件运行要求的范围内,可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证.

模拟真实环境测试有些软件,特别是面向大众的商品化软件,在测试时常常需要考察在真实环境中的表现.

横向对比测试:利用辅测试环境"克隆"出完全一致的测试环境,从而保证各个被测软件平等对比.

配置辅测试环境遵循的原则真实环境直接将整个系统(包括硬件和软件)和其交联的物理设备(如果有的话)真实的建立连接,形成最终真实的用户使用环境进行测试.

优点可以发现某些只能在真实环境下出现的问题.
不足构建这样一个环境需要高昂的费用它的测试运行也需要高额费用仿真环境一般是指软件仿真测试环境.
它能够逼真的模拟被测软件运行所需的真实物理环境的输入和输出,并且能够组织被测软件的输入,来驱动被测软件运行,同时接收被测软件的输出结果.

仿真测试环境能够保证测试的:可重复性完整性可扩展性系统测试环境的分类系统测试需要采用测试工具时,需要考虑:测试工具与被测软件系统的匹配程度测试工具提供的主要功能与辅助机制测试工具的服务和技术支持测试工具的价格系统测试的工具系统测试数据特点数据可以以消息、事务、记录、文件等形式存在数据来源很多产品手工构造工具生成,比如DataFactory软件捕获随机真实数据最好,但在很多情况下不易或不能得到系统测试的数据系统测试结果记录表(1)编号用例ID用例标题测试人员测试结果执行时间缺陷ID123456789…系统测试结果记录表(2)汇总轮次总数通过失败阻塞/挂起第一轮第二轮第三轮第四轮第五轮合计测试人员每天总结测试工作,便于了解自己的测试进度和测试情况,用以调整下一天的工作计划;测试人员每天对被测对象给出评估结果,用以调整后续工作中的测试策略;测试人员向测试经理反馈测试中的困难,保证测试的顺利进行;测试经理通过测试日报了解每个测试人员的工作进度,把握测试的整体进度,发现进度上的风险,并及时调整计划;测试经理通过测试日报了解各模块缺陷发展趋势,判断测试是否可以退出;开发经理通过测试日报了解当前被测试软件的质量情况,判断是否需要调整负责修复缺陷的开发人员的人力资源配比;如果产品有多个测试组并行测试,测试日报可以成为彼此交流的手段;系统测试日报的写作目的系统测试日报的格式项目ID标题版本执行者测试阶段日期概述执行用例数总用例数计划执行用例数累计已执行用例数本日发现问题数累计发现缺陷数致命问题数缺陷ID严重问题数缺陷ID一般问题数缺陷ID提示问题数缺陷ID困难编写《系统测试报告》的目的:测试人员对整个系统测试工作进行总结,对被测试对象进行评估,并对以后的测试工作给出建议;测试经理通过测试报告了解被测试产品的质量情况以及测试过程的质量;开发经理通过测试报告了解产品的质量情况,并在下阶段的开发工作中采取应对措施;测试报告中的质量评估可以作为软件产品是否对外发布的重要参考依据.

系统测试报告的写作目的系统测试报告的要点:概述测试时间、地点、人员环境描述总结和评价测试过程质量统计评估软件产品质量统计评估系统测试综合评价系统测试遗留问题报告系统测试报告的要点概述:简单介绍被测对象、测试特性及其版本/修订级别情况指明本次系统测试活动所依据的测试计划、测试方案、测试用例及测试过程测试时间、地点、人员:描述本次测试的时间,地点和测试人员,以及人员分工环境描述:描述本次测试的环境,包括软硬件、测试仪器、组网图等.
系统测试报告要点简介(1)总结和评价:从测试过程评估的角度:充分性:投入测试人时/KLOC、用例数/KLOC、用例对需求覆盖程度、效率:测试执行用例数/人时、发现缺陷数/人时.
.
.
用例稳定性:变更用例数/总用例数用例有效性:发现缺陷数/总用例数从被测试对象评估的角度:稳定性:缺陷数/KLOC、用例通过百分比、缺陷级别百分比动态质量趋势:对于GUI测试,可能评估基础就不是KLOC数,而是控件数或界面元素数对于性能测试,可能评估的就不是缺陷数,而是对各种业务环境进行性能对比系统测试报告要点简介(2)工作量的数据统计:分析:可以根据不同模块的工作量(人时/KLOC)来查看哪些模块测试比较充分,哪些模块测试不够充分.

结合模块的实际情况,对关键模块或者复杂模块投入的测试人时比例应相对较高;对非关键或者简单的模块投入的测试人时比例可以相对较低,根据该指标可以用来衡量测试过程中测试资源的分布是否合理.

测试过程的统计评估(1)模块/特性规模(KLOC)投入人时投入人时/KLOC参数检查0.
2315统计代码0.
215统计注释行0.
215统计空行0.
215统计总行0.
2315GUI0.
524合计1.
5117.
3测试用例数统计:分析:可以根据用例密度(用例数/KLOC)来查看哪些模块用例设计的比较充分,哪些模块用例设计的相对比较少.
结合模块的具体特点,需要进行分析,避免关键模块用例设计不充分的情况.

可以根据不同模块用例数来了解不同测试人员的工作量;结合时间方面的数据,对工作量少而花费时间较多的情况进行调查分析,对其中存在的问题采取相关策略进行有效的规避.

测试过程的统计评估(2)模块/特性规模(KLOC)用例数用例数/KLOC参数检查0.
2315统计代码0.
2420统计注释行0.
2420统计空行0.
2420统计总行0.
2315GUI0.
5510合计1.
52315.
33测试用例对需求的覆盖率:分析:从需求的覆盖率来查看用例密度(用例数/需求项),可以考量不同的需求被测试的程度:对于重要的关键的需求,应该设计比较充分的用例;对于功能比较简单的需求,可以设计相对少的用例;对于没有用例对应的需求,一定要调查相关负责人员的工作情况,避免工作中的不认真导致的测试的不全面性.

测试过程的统计评估(3)模块/特性需求项用例数用例数/需求项参数检查362统计代码482统计注释行482统计空行482统计总行482GUI6101.
67合计21482.
29测试用例的稳定性:分析:根据每个模块设计的用例的稳定性来判断:对个别变更比例比较高的模块要进行调查分析,看变更的原因在哪里是开发的文档发生了变更,还是由于测试方面理解发生了偏差导致的变更.

如果是开发方面变更频繁,需要反馈给开发方面;如果是后者,测试方面需要分析导致这个偏差产生的原因是客观的还是主观的;要采取相应的措施进行规避.

测试过程的统计评估(4)模块/特性用例数变更用例数变更用例数/用例数参数检查3133统计代码400统计注释行400统计空行4125统计总行300GUI5240合计23417.
4测试用例的有效性:分析:根据每个模块对应的缺陷密度(缺陷数/用例数)来判断用例设计的水准:如果模块对应的该值比较高,可以认为:该模块质量比较差用例设计的质量比较高如果模块对应的该值比较低,可以认为:该模块的质量比较好用例设计的质量一般测试过程的统计评估(5)模块/特性用例数发现的缺陷数缺陷数/用例数参数检查3133统计代码4125统计注释行400统计空行400统计总行3133GUI5240合计23522测试执行的效率:分析:根据不同的模块查看不同测试人员的执行效率:个别模块执行效率很高,考虑测试人员对工作比较负责,积极,或者使用了比较好的测试技术;测试人员测试的比较马虎,用例执行可能存在应付现象.
个别模块执行效率不高,考虑测试人员测试方法存在问题,或者能力有限,考虑是否需要帮助对应的模块测试难度较大,属客观因素.
测试过程的统计评估(6)模块/特性用例数变更用例数变更用例数/用例数参数检查3133统计代码400统计注释行400统计空行4125统计总行300GUI5240合计23417.
4版本缺陷统计-柱状图软件产品质量统计评估(1)版本缺陷统计-数据表格软件产品质量统计评估(2)分析:1根据不同版本缺陷的收敛状态来观察软件的质量1.
1如果缺陷收敛的比较快,可以考虑系统中的缺陷主要在模块或者函数内部生成,接口方面的缺陷相对较少,一个模块的修改不会引发其他模块的问题;可以认为软件产品质量相对比较容易控制;1.
2如果缺陷收敛的比较慢,可以考虑系统中的缺陷主要在模块的接口处产生,一个bug的修改,可能对多个模块产生影响,从而引入新的bug;可以认为软件产品的质量控制相对困难.

另外,通过这个指标,也可以考核测试组对每个版本测试的充分性,但在前面测试过程控制的前提下,这个指标主要用来衡量软件的质量水平.

缺陷等级统计-数据表格软件产品质量统计评估(3)缺陷等级统计-柱状图分析:根据不同的模块来查看缺陷的严重性要求对于等级相对比较严重的问题要进行分析,了解问题产生的原因,并考虑有没有比较好的方式进行规避.

对于严重问题比较多的模块,要结合开发人员的能力,工作态度和模块的难度考虑,考虑任务安排的合理性.

软件产品质量统计评估(4)测试用例的通过率分析:假设测试过程质量得到有效控制的前提下:在最后一个回归测试版本中,对用例的通过率的衡量可以考核软件产品质量的等级对于未通过的用例需要分析,看对软件产品质量的影响达到什么级别对于遗留的问题,需要分析遗留的主观和客观原因,考虑在以后的版本中是否可以进行规避软件产品质量统计评估(5)模块通过失败挂起未完成合计通过率参数检查1301520%统计代码40004100%GUI164102176%合计217113070%缺陷原因分布分析:根据缺陷的分布来分析研发过程的规范性如果在需求及设计阶段发现的缺陷较多,需要考虑相关过程的质量控制是否严格如果在需求及设计阶段发现的缺陷很少,可以认为过程的质量控制比较有效软件产品质量统计评估(6)对测试过程综合评价:从测试的充分性,效率,质量,协作等多个方面进行评价,重点在于暴露测试过程中的问题,并提出相应的改进策略.

对被测模块/特性综合评价:从软件产品的系统功能、业务正确性、安全性,可用性,可维护性,性能,可靠性等多个方面作出客观评价测试对象的整体质量:A:质量稳定,适合大规模应用;B:存在少数严重问题,但有规避措施,可以使用;C:基本功能可用,但问题较多D:基本功能不可用系统测试综合评价静态分析:效率分析测试活动持续时间:X人时执行用例数:Y个发现缺陷总数:Z个平均每小时用例数=执行用例数/测试活动持续时间=Y/X平均每小时发现缺陷数=发现缺陷总数/测试活动持续时间=Z/X影响测试效率的原因分析:对影响测试的各种因素进行分析,如:测试环境,物料;突发任务等系统测试评估(1)静态分析:充分性分析千行代码用例数:根据用例统计对测试充分性进行点评分析系统测试评估(2)模块/特性千行代码用例数已执行用例数用例总数用户管理29.
16780报表统计202440合计2691120执行结果统计根据结果统计对系统质量和测试过程进行点评静态分析:稳定性分析模块千行代码缺陷数和平均用例缺陷数点评分析这里的点评主要针对各特性千行代码缺陷数是否达到了质量目标,没有达到则要给出原因,并且确定是否需要继续测试.
通过对平均用例缺陷数的分析可以得出测试用例的质量.
如果平均用例缺陷数太少,则需要考虑新的测试方法,给出新的改进措施.