测试、测试、测试
--软件Software测试
理论和实战题记:测试是交付成功
优质产品保证我们每个人
不会都是软件Software测试人员但都是某些软件Software用户
缺省或默认情况下用户都会觉得买到软件Software是没有问题
般不会去想这样软件Software可能会有问题用户只要使用这些软件Software来解决他们需要解决问题就可以了当他们发现问题时候甚至会感到震惊存在问题很多都和测试成效有关系般软件Software产品存在问题确实比较少但我觉得即使是以前买正版金山快译2000都有着些显而易见bug如果测试不充分那么这些问题会潜伏在软件Software中等到用户发现以后再有开发人员进行维护改正
费用般是开发阶段40倍到60倍人们对测试存在着
些误区例如:1 测试是想象到可能出现
问题然后试图验证这些问题实际上能想象到
只是部分情况随意性太大还要取决于开发人员经验对业务熟悉程度和他想象到程度2 让时间有富裕
员工去做些测试表面上看这体现了管理
效率和灵活性但实际上也体现了管理者对测试轻视测试和测试人有很大关系测试工作人员应该是勤奋并富有耐心善于学习、研究和发现问题细心有条理整理总结问题如果具备这样优点做其它工作同样也会很出色因此这里还有个要求就是要喜欢测试这项工作如果他是专职那么肯定更有经验和信心国内小伙子好象都喜欢做
员两者工作性质区别待遇区别地位区别对自我实现价值认识也区别这是行业个需要改善问题如果只是为了完成任务而完成任务或者发现了几个问题就觉得满意了这在任何其它工作中都是不行3 测试是相对简单
工作实际上并非如此
要真正做好件事都不容易测试也有很多相关技术和工具而对测试轻视问题也许要通过痛苦经历和结果才可能确切体会到很多专家都在对测试理论进行深入探讨和研究测试
基本知识让我们
起快速过遍:什么是软件Software测试:在软件Software投入运行前
对软件Software需求分析、设计规格介绍说明和编码最终复审是软件Software质量保证关键步骤测试
目标:以较少用例、时间和人力找出软件Software中潜在各种和缺陷以确保系统质量从测试
类型来看测试分为2种:黑盒测试和白盒测试黑盒测试又称为功能测试或数据驱动测试
把系统看成个黑盒子不考虑内在逻辑只根据需求规格介绍说明书要求来检查功能是否符合它功能介绍说明白盒测试又称为结构测试和逻辑驱动测试
允许测试人员对内部逻辑结构及有关信息来设计和选择测试用例对逻辑路径进行测试测试用例由测试输入数据以及和的对应
输出结果组成测试用例设计好坏直接决定了测试效果和结果从测试实际
前后过程来看软件Software测试上是由系列区别测试所组成这些软件Software测试步骤分为:单元测试、组装测试(集成测试)、确认测试和系统测试软件Software开发过程是自顶向下测试则正好相反以上这些过程就是自底向上逐步集成 单元测试(模块测试):针对每个模块进行
测试可从内部结构出发设计测试用例多个模块可以平行地对立地测试通常在编码阶段进行必要时候要制作驱动模块和桩模块集成测试:在单元测试
基础上将所有模块按照设计要求组装成为系统必须精心计划应提交集成测试计划、集成测试规格介绍说明和集成测试分析报告确认测试:验证软件Software
功能和性能及其它特性是否和用户要求致系统测试:将软件Software放在整个计算机环境下
包括软硬件平台、某些支持软件Software、数据和人员等在实际运行环境下进行系列测试测试工作
文档主要有:测试计划、测试模型和用例设计或规格介绍说明、测试分析报告等从软件Software工程上说这是属于软件Software配置部分(我不知道如果什么报告都没有只是不断地摆弄执行看到和问题就记下来算不算真正测试？) 测试需要
定技术和工具在用例设计过程中
可以考虑到很多方面并且也有很多指导思路方法和技术黑盒测试用例设计包括:
等价类划分:划分等价类--确立测试用例--设计用例
边界值分析:通过分析
考虑如何确立边界情况推测法:靠经验和直觉来推测中可能存在各种从而有针对性地编写用例可以列举出可能和可能发生地方然后选择用例因果图:通过画因果图
在图上标明约束和限制转换成判定表然后设计测试用例这适合于检查输入条件各种组合情况功能图FD:通过形式化地表示
功能介绍说明并机械地生成功能图测试用例白盒测试用例设计包括:
1 逻辑覆盖
以内在逻辑结构为基础测试包括以下5种类型:1.1 语句覆盖:每
条可执行语句至少覆盖次；1.2 判定覆盖(分支覆盖):设计若干个测试用例
运行所测使中每个判断取真分支和取假分支至少执行次；1.3 条件覆盖:设计足够多
测试用例运行所测使中每个判断每个条件每个可能取值至少执行次；1.4 判定-条件覆盖:设计足够多
测试用例运行所测使中每个判断每个条件所有可能取值至少执行次并且每个可能判断结果也至少执行次；1.5 条件组合测试:设计足够多
测试用例运行所测使中每个判断所有可能条件取值至少执行次；1.6 路径测试:设计足够多
测试用例运行所测要覆盖中所有可能路径2 基本路径测试
在
控制流图基础上通过分析控制构造环路复杂性导出基本可执行路径集合从而设计测试用例包括以下5个方面:2.1
控制流图:描述控制流种图示思路方法2.2
环境复杂性:McCabe复杂性度量从环路复杂性可导出基本路径集合中独立路径条数这是确定中每个可执行语句至少执行依次所必须测试用例数目上界
2.3 导出测试用例
2.4 准备测试用例
确保基本路径集中每条路径执行2.5 图形矩阵:是在基本路径测试中起辅助作用
软件Software工具利用它可以实现自动地确定个基本路径集静态分析思路方法:1 生成各种引用表、静态
分析2 人工测试:桌前检查、代码评审等
3 软件Software测试工具:包括静态分析工具、动态测试工具、测试数据自动化生成工具、模块测试台、测试合成环境
3.1 静态分析工具:语言
预处理器、数据库工具、分析器和报告生成器直接扫描所测试正文对数据流和控制流进行分析然后送出测试报告3.2 动态测试工具:通过选择适当
测试用例实际运行所测比较实际运行结果和预期结果发现3.3 测试数据自动化生成工具:包括路径测试数据生成
、随机测试数据生成以及根据数据规格介绍说明生成测试数据3.4 模块测试台是
种专门测试用例描述语言负责将输入数据传送到所测试模块中然后将实际输出结果和在描述测试用例语言中所表述期望结果进行比较发现另外也包括其它功能:语句跟踪、动态断句、覆盖度量、用户自定义符号表、内容表和输出格式3.5 测试合成环境:包括环境模拟
代码检查测试文档生成测试执行严整输出比较正确性证明等以及各种调试工具而且还有集成系统集成了多种工具如SADAT、Microsoft Test for Windows和PureArtria等***********************************************************
测试
管理作为项目或产品开发
个必要组成部分需要良好组织和管理使用软件Software质量规范标准编写和实现测试用例和模型可以有效地组织测试般测试工作过程也可以是:计划-->配置(必要软硬件资源下)-->开发(构造或配置测试工具、创建测试套件和测试方案库、准备适当报告工具并记录测试系统如何运转)-->测试执行(进行测试、记录测试条件和问题报告结果)测试管理也可以从测试经理和测试小组2个方面去看:
测试经理要管理好团队(Team)
很多人认为测试是枯燥乏味事情而且似乎低级事情所以测试经理应该不断地激励小组成员为他们争取利益在时间进度上保证稳步前进就象赛跑开始就加班加点只会导致极限过早到来作为测试经理
应该有足够质量意识评价质量风险思路方法是“失败模式和效果分析”(Failure Mode and Effect Analysis, FMEA)这种思路方法可以允许您在特定质量风险和结果上映射需求、规范标准以及项目小组假设然后按照风险级别进行分类并按序排列实际上如果能得到充分
资源已是很困难了能用好临时测试人员也已经不错了般企业主管和技术经理都并不如何真正重视测试工作意义和价值也许他们认为临时投入次性强力测试足以发现绝大部分问题而实际上这对产品长远发展以及质量改进都没有太大好处测试过程中软件Software功能可能进行调整和变化
测试发现问题也会导致变化需要重新测试对这些变更也需要进行管理另外
由于上层管理部门不重视必须想办法和的进行清楚而有效沟通；同开发部门沟通也非常重要
开发和测试在性质上是有些对立很容易在相互的间产生些不必要矛盾和开发部门区别是般质量或测试部门和市场或销售部门立场倒是比较致如果双方都认为高质量产品是市场战略中重要品牌战略彻底测试对于达到这样目标来说意义重大因此有必要和市场部门保持协作和交流测试经理可以经常问自己
些问题:计划做哪些测试？实际完成了哪些测试？使用了多少用例？其中多少没有通过？管理部门是否有足够
支持？他们是否向你要过测试报告？开发部门联络是否及时？等等如果你是测试管理人员应该可以想到更多问题测试小组:
测试小组有多大
规模般取决于项目规模、测试人员和开发人员比例、项目经理(project manager)对质量保证认识和期望等也取决于你准确测试计划对
些项目来说最好是在开始阶段就有测试人员有所介入如本文
开始所提到在测试小组中测试人员必须具备素质包括:有效坦率真诚交流能力、清晰简明表达能力、定好奇心(但不至于太强以至于花太多精力去探究个微小问题)不应害怕提出尖锐问题引起麻烦定责任心注意力能够高度集中
是职业悲观主义者(但不是抱怨和憎恶)以下是
些测试思路方法和基本工具:测试方案、测试模型和测试用例
测试就象是做实验
样实验对于象我这样理工科毕业生来说真是太熟悉不过了做实验的前必然有实验方案、内容和步骤测试似乎也是同样另外基于测试用例测试和常见随机性测来测去也是完全区别尽管习惯于随机性测试人如果注意力集中话他头脑里也是有些测试用例有关测试实验室
进行测试工作首先要争取到尽可能好环境如果可能应该建立测试实验室实验室包括必要装备、工具软件Software(包括测试工具)和各种操作系统平台保持实验室实用、整洁避免他人干扰甚至破坏测试环境有关测试跟踪软件Software
制作个简单测试问题跟踪软件Software记录测试结果将测试发现问题分类并对测试发现问题和模块、开发人员进行关联有助于分析问题并可有效记录测试结果形成测试报告并从中找出些规律性东西来因此测试问题跟踪软件Software还是有定价值有关测试自动化
有定风险对个稳定系统甚至可以自己开发自动化软件Software而对于正处于快速变形中软件Software开发过程接口、主要功能和支持环境在发展变化中为测试配置环境也要付出很多时间以下是有关测试
些窍门技巧和经验:在制定测试计划
时候就要考虑到测试风险并抉择要执行哪些测试并放弃哪些测试；测试计划评审应该让开发人员参和；测试模型
制作应该尽可能贴近用户或者站在用户使用立场上来观测软件Software此时应该能发现更多问题由于测试发现问题
在解决问题后还要重新测试因此测试时间可能会比实际更长些
识别和注意少数重要
方面而忽略多数次要方面有时候少数问题足以致命这些问题将是软件Software测试结果中重要性最高定位有时是很难要找出必然发生前因后果而不至于描述而误导开发人员有时候确实存在不能重建问题解决办法的是在报告中给予介绍说明对
描述应该是准确、完整而简练描述问题或者不完整描述会引起开发人员误解其后果是可以想见有时有经验
测试人员凭借直觉就可以发现些问题这可称为“猜测”测试人员容易犯2种
:是测试人员发生判断将本没有系统行为报告为或者将指定了过高严重级别或者过高估计了问题严重性这样会引起开发人员不信任产生种象“狼来了”样效果； 2是测试人员将严重性或优先级定得过低从而产生“测试逃逸”这样会造成产品质量风险以上两种应该尽量避免最后
我忽然想测试实际上可以覆盖到硬件甚至非计算机产品测试也许可以相互借鉴还有
种很奇特感想这种感想使我反而有些困惑不清了我发现对测试来说理论和实战距离好象非常遥远我先看了本软件Software工程书然后写下了前面半内容然后我又匆匆翻看了本美国人书叫做
测试流程管理
然后整理出了本文后半内容该书中有着比本文多得多各方面实战经验歌德说过理论是苍白生命的树常青我稍稍改变下就变成了:理论是苍白实战的树常青也许测试是种实战性很强工作大学教授们般也不可能热衷于参加测试工作吧Blueski
2001-9-12
最新评论