软件测试策略.docx
《软件测试策略.docx》由会员分享，可在线阅读，更多相关《软件测试策略.docx（10页珍藏版）》请在冰豆网上搜索。
软件测试策略
软件测试策略
测试策略
策略：
根据实际情况制定的行动方针和实施方式
测试策略：
把软件测试用例的设计方法集成到一系列周密计划的测试流程中，为软件测试提供一个清晰的路线图，以指导软件测试的成功完成。
测试策略
（2）
测试策略包括计划、测试case设计、测试执行、测试结果收集和分析
软件测试的组织
开发人员不适合测试自己的软件
独立测试组织（ITG）的存在必要性：
不受开发固有思维的影响
站在中立的角度，避免利益冲突
专职于查找问题，分工明确
更有利于V&V中发挥作用
更利于对软件进行评估
ITG的测试活动（repeat）
独立测试组织的测试活动是软件质量保证的关键元素，代表了规约、设计和编码的最终检查
与开发独立，可以明确工作界面，减少开发人员和开发leader对测试结果的主观影响。
作为一个职能部门，与开发处于同等重要的作用。
ITG的职责
制定产品测试计划
划分每个测试阶段及测试重点
设计测试case
开发测试程序
执行测试，申报bug
向组织提交测试报告
进行技术转移
参加产品实施
贯穿瀑布模型的测试过程
测试流程举例
不成熟组织中的测试流程
测试有自己的周期，和开发生命周期并行
测试组和一个不成熟的开发组织一起工作，将感到非常痛苦
不成熟的开发组织将产生一个非产品化、混乱的、屡受搓折的环境中产生低质量的不另人满意的结果
成熟组织中的测试流程
在一个成熟的开发组织中，测试组可以并能够集中精力在内部流程改进上
测试流程的有效改革将会成为促进不成熟组织改进开发流程的催化剂
测试什么时候开始？
测试应从需求开始
测试越早开始，效率越高
缺陷放大
尽早开始测试
有50%的错误是在需求阶段产生的。
修复这些缺陷的代价，远小于这些缺陷转移后的代价
抓住机会，在开发的早期进入测试，达到事半功备的效果
测试什么时候结束？
测试没有止境，只是从开发转到测试，测试转到维护，维护转到客户
时间、资源不够的时候，就到了测试该结束的时候
量化的软件故障模型
测试结束的标准
建立在量化基础上
随着测试时间，单位之间里的bug数减少
当故障模型曲线趋近于直线，且单位时间发现bug很少，甚至为0时，可以做为一个milestone
随着运行环境、需求的变化，故障曲线会发生变化
测试因素
（1）
在制定测试策略时，首先要分析出系统的主要测试因素。
通过对测试因素的分析，制定出在整个软件生命周期中采用什么样的测试技术和方法。
测试因素
（2）
符合度（Compliance）
确认系统与需求、标准、规则的符合程度。
如系统设计是否符合产品需求，是否符合用户提出的业务标准、行业标准等。
此测试因素强调的是测试的依据是用户的需求、规范和标准。
正确性（Correctness）
系统的功能数据输入、处理流程、输出是否正确。
程序满足它的需求规约和实现用户需求的程度
测试因素（3）
易用性（EaseofUse）
这是一个共性问题，任何用户都希望自己所使用的系统是好用的。
但对于不同的用户，对这个因素的要求程度不一样，有一些只运行在后台的进程，不需要操作员手工操作的系统，对此项的要求不高。
易掌握程度（Easeofoperation）
这里强调的是系统的学习过程是否容易，指导手册是否完备、准确。
使系统易学、易掌握。
如windows等这种使用人数众多的通用系统，就要求非常容易的被掌握。
测试因素（4）
过程的可跟踪性（Audittrail）
操作的过程、轨迹是否有log记录，可以被跟踪。
这在一些服务等级很高的系统中要求非常严格，如银行系统，要求对每个操作过程都有记录。
文件完整性（FileIntegrity）
对系统数据文件的完整性、安全性的要求。
如数据库文件的完整性等。
服务等级（Servicelevels）
服务等级包括是否需要7*24小时不中断业务，是否需要非常高的保密控制，是否需要数据的决定准确等。
测试系统需求说明书中对平均失效间隔时间（MTBF）,故障停机时间（MTTR）的相关测试。
测试因素（5）
易维护性（Maintainability）
系统是否易于维护。
可以通过定位和修复一个错误所需要的工作量来衡量
权限控制（Authorization）
系统功能和数据的访问权限被分级
只有授权用户可以访问
加密方法安全，不容易破解
进程的连续性（Continuityofprocessing）
在临时或永久的软件故障和系统故障发生的时候，系统自动或手动进行恢复的可能性，系统其他相关软件能否正常运行的可能性
测试因素（6）
访问控制（AccessControl）
检查系统的安全性，软件的安全性及保密性，是否有破坏软件安全性的方法和工具等。
可移植性（Portability）
可以在不同操作系统、不同数据库环境中运行
移植代码易于维护
耦合度（Coupling）
不同模块之间的关联是否紧密
耦合度高，集成性高，性能高
耦合度底，易于扩展
性能（Performance）
大容量数据及大访问量情况系统的响应速度
测试因素
访问控制（AccessControl）
可移植性（Portability）
耦合度（Coupling）
性能（Performance）
易维护性（Maintainability）
权限控制（Authorization）
进程的连续性（Continuityofprocessing）
过程的可跟踪性（Audittrail）
文件完整性（FileIntegrity）
服务等级（Servicelevels）
易用性（EaseofUse）
易掌握程度（Easeofoperation）
符合度（Compliance）
正确性（Correctness）
测试因素小结
针对不同的系统，测试因素即测试重点是不一样。
一般系统选取3到7个测试因素即可。
测试类型
测试类型为一个统称，它包括了简单的黑盒测试方法和测试策略上的集合。
其中所反映的黑盒测试方法主要为边界测试和异常测试。
其他所有的测试类型实际上都是测试的策略上的选取。
融合一定的黑盒测试技术的原因是为了能够提醒测试者在设计测试案例的时候更多的考虑功能在边界和异常情况下是否正确。
测试类型会随着测试的实际开展而有所删减
测试类型举例
（1）
正常测试：
测试某个功能是否满足需求的定义，功能是否正确，完备。
边界测试：
对某个功能的边界情况进行测试。
异常测试：
对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的，类似这样的情况需要书写相关的异常测试
测试类型举例
（2）
性能测试：
检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。
内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。
压力测试：
压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件
兼容测试：
测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。
测试类型举例（3）
接口测试：
在模块组装测试中，很多问题出现在接口部分。
单个模块的功能实现了，但组装在一起，就无法正常工作。
接口测试要包括两部分的测试：
（1）根据设计文档，构造测试数据，验证接口是否正确
（2）将接口关联的模块组装在一起进行连调测试。
接口测试可以同时检查设计文档的正确性。
可安装性测试：
主要检查软件能否按照其可能发生的安装过程和配置正确，成功的安装软件。
界面测试：
主要为了测试基于UI界面的测试
测试类型举例（4）
启动/停止测试：
检查系统，启动，停止，监控，维护等相关的功能是否正常
文档测试：
检查内部/外部文档的清晰性和准确性，对外部文档而言，还必须考虑文档的简单明了，相关的技术术语是否解释清晰等方面的检查。
配置测试：
原本主要是测试整个系统中各个设备，资源之间的功能，可控度和可维护程度。
现在主要说明的是基于配置文件所提供的各种功能，选项的测试。
测试类型举例（5）
易用性测试：
从使用的合理性和方便程度对系统及软件进行相关的测试和检查，在不影响程序主体和耗费时间太长的前提下，建议多从客户的使用角度来考虑
多语言测试：
对不同的语言平台，环境下，包括界面，语法，基本功能方面的测试
测试类型小结
正常测试：
边界测试：
异常测试：
性能测试：
压力测试：
兼容测试：
接口测试：
可安装性测试：
界面测试：
启动/停止测试：
文档测试：
配置测试：
易用性测试：
多语言测试：
测试因素与测试类型的关系
测试因素是基础
测试类型是综合了测试因素，白盒、黑盒测试技术后，对测试种类的一种分类。
属于测试case的类型
测试类型可以根据实际测试情况、测试不同阶段进行增删
在测试策略制定中，首先选择测试因素。
再根据所选择的测试因素，在测试case设计中，尽量考虑多的测试类型，构造测试case.
测试策略小结
测试策略是软件测试的行动方针和实施方法
测试策略规划了软件测试的路线图
测试策略包括测试计划、资源分配、测试因素选择、各个阶段的测试重点等综合信息
测试策略的目的是如何计划、组织测试活动，选取适当的测试方法，发现更多的软件问题，有效的完成测试任务
测试流程中的问题
测试流程改进的六要素
软件测试质量根本上是软件流程决定的。
预防缺陷转移在软件生命周期的早期
要有专人对测试流程负责
测试是专业学科，需要经过培训，有专业技能的人
培养一只高效的有创造性破坏观点的团队
适当的选则合适的测试工具
关于测试team的建立
明确职能：
责、权、利统一
人员招聘：
了解并乐意从事测试工作、具有专业技能、有很好的学习能力、勾通能力
测试管理流程需要考虑的：
bug管理工具、版本控制工具
测试Team组成
（1）
TeamLeader
有丰富的业务知识和技术背景
有良好的组织、协调、管理能力
负责测试人员招聘
制定测试规范及测试流程
设计测试有关的模板
负责主要产品的测试计划和方案制定
跟踪测试进度
协调与开发及售后相关部门的关系
团队建设，树立测试team在整个组织中的威信
测试team组成
（2）
测试工程师
具有相关行业背景知识
具有相关领域的技术技能
良好的沟通、表达和分析能力
负责测试case的设计
负责执行测试、申报bug、汇总测试报告
负责对售后或用户的产品培训
测试team组成（3）
版本控制工程师
有软件版本控制的概念
负责源代码、release程序、文档的版本管理
开发必要的版本控制脚本
参与版本计划的指定，并在每个milestone中执行
测试team组成（4）
文档工程师
良好的文字表达能力
了解相关业务和技术
负责客户使用、维护、安装手册的编写
负责产品Demo的制作
测试Team的规模
将产品进行模块分解，根据模块复杂程度，组织测试资源
根据产品可测试时间和工作量，考虑人员数量
一个产品线的测试与开发的比例，建议为：
1：
2~3
关键核心模块的人员比例：
1：
1~1.5
测试Team中的常见问题
（1）
测试Team中的常见问题
（2）
测试实践的过程（步骤一）
根据开发计划，制定《配置管理计划》
标记出软件的版本信息
标记出系统开发、运行环境信息
标记出配置项（程序、需求、设计文档、使用手册、目标程序）的信息（名称-责任人-提供时间-存储位置等）
测试实践的过程（步骤二）
根据开发计划，制定《测试计划》
确定测试需求
评估风险
制定测试策略
确定测试资源
创建时间表
生成测试计划
测试实践的过程（步骤三）
设计测试case,开发测试程序
根据需求、设计文档，进行测试case的设计
测试case的设计顺序采用由粗到细，由模糊到精细的过程
采用统一的模板
为测试case开发必要的测试程序，如数据发生器，数据转换程序，client程序等
在设计测试case时，应与需求做到多多对应。
测试case应包括所有需求
测试实践的过程（步骤四）
测试执行
根据测试计划，按照测试case执行测试
测试中发现的问题报bug反馈给开发
对错误修复后的软件进行回归测试
修改、细化测试case
保存测试case及bug
测试执行的几点建议
尽早开始编译，消除系统在集成环境中编译的问题，节省测试时间
在测试之初，进行系统集成的联调，可以及早发现主流程问题和模块接口问题。
建立dailybuild流程，进行增量测试
测试执行顺序按照测试计划中的定义，有计划的进行
测试实践的过程（步骤五）
提交阶段《测试报告》
测试计划执行情况
测试中发现问题情况汇总
遗留问题分析
测试实践的过程（步骤六）
产品release
进行release前的确认测试，重点检查
（1）产品包的完整性
（2）源代码与执行程序版本一致性
（3）使用文档与执行程序的一致性
（4）介质的正确性
完成release包的readme说明
Release产品入库，做配置管理标识
发布release信息
关于缺陷跟踪
典型缺陷跟踪流程
如何写好bugreport
测试的精髓就是通过你的工作，发现隐藏在程序中的bug，将它们清楚、准确的通报给程序员。
这是测试最具有实质性的结果。
因此写好错误报告，是测试工程师的重要工作和职责。
有效bugreport的特点
可再现.
如果程序员无法查看到或总结出bug的存在，那么他很可能设置该bug的状态为"不存在"或者”bug申报错误"，然后继续处理下一个bug。
因此，你所提供的每个细节都会有帮助。
具体.
程序员能够越快地找到具体的问题，这个问题就会越快被修正。
清楚、准确
问题报告贵在清楚、准确
Bugreport的信息
（1）
基本信息
产品名
模块名
申报时间
申报人
开发受理人
环境信息
测试版本
测试平台
测试阶段
Bugreport的信息
（2）
Bug分类信息
故障级别
优先级别
问题类型
Bug信息
BugTitle
问题描述
Bug的故障级别-紧急
紧急
Bug足以造成系统崩溃，造成文件不可靠或潜在的数据丢失
Bug造成非正常地返回操作系统（系统崩溃或显示系统错误信息）
Bug造成程序越或要求Reboot系统
造成缺乏关键的程序功能并无法逾越
由于设计问题，使系统存在严重隐患
Bug的故障级别-严重
（1）
Bug可能不会削弱系统，但将造成严重问题（如：
严重的格式化错误等）
功能缺乏给用户带来极大不方便
Bug可以绕过，但将会很不方便或很难实现
存在不明确或不完整的错误信息提示，极大地影响产品使用
由于Bug的存在使产品其它部分不能测试
Bug的故障级别-严重
（2）
由于计算方法问题，使数据错误
由于设计原因，造成前后不一致，但问题可恢复
容错性方面存在不足
由于精度问题造成数据不一致
Bug的故障级别-一般
这个Bug在将来是严重的，但比主要问题（MajorProblem）要轻。
可以有一个比较简单的绕过Bug的解决方案
存在不明确或不完整的错误信息提示，但对产品使用影响较小
Bug的故障级别-遗留
遗留
不可能被用户发现的Bug
尚无法满足的新需求
在当前release版本无法解决的问题，但不会影响用户的使用
Bug解决的优先级
问题类型
（1）
初试化问题
初始化的sql语句错误、不完整、内容不正确；
初始化的配置文件错误；
初始化的文件属性错误
编译问题
程序包中少文件；
目标文件位置错误；
目标文件重名造成错误；
有多余目标文件打在程序包中；
打包内容与开发提交内容不一致
问题类型
（2）
环境问题
操作系统版本、3wserver、oracle版本、第三方软件版本等原因造成的问题
功能问题
符合需求，但功能实现有错误
接口问题
符合需求和设计文档，但程序之间的接口有错误；
接口错误，实现与设计不一致；
缺少
问题类型（3）
设计缺陷
设计方案缺陷，使产品功能与需求不一致，并造成的功能实现问题。
需求问题
需求描述不明确，造成功能实现错误或无法测试
性能问题
在大用户量，高访问频率情况下出现的问题的系统响应速度慢
问题类型（4）
稳定性问题
在长时间运行情况下出现的问题。
这类问题的特点是偶发性出现，很难复现和定位。
兼容性问题
在支持多操作系统、多数据库的产品中，不能全部支持设计中要求的系统情况。
文档问题
客户文档与产品实现不一致
客户文档描述错误
客户文档内部不完全
关于bugtitle
问题Title:
在此描述问题的摘要
一个好的摘要应该能够迅速且唯一地确认一份bug的报告。
否则，当开发人员面对的bug报告比较多的时候，他们就不能从摘要确切地知道bug的状况，而导致错误的优先级工作顺序。
象"aiip.sql在安装时失败"的摘要是一个精确的标题，而象"软件失败"或者"安装问题"这类标题则是错误的例子。
关于问题描述
问题描述：
详细描述问题的现象、再现bug的操作步骤、特殊的配置和输入、你期望的结果和对此问题和预测。
详细描述问题现象
通过描述，可以再现问题
请为程序员提供尽可能多的细节，以便他们能够对问题进行判断/解决.
可以包括测试场景、测试输入、预期结果，实际结果，错误估计等信息。
升级会员 