学习协议测试的心得体会模板.doc

学习协议测试心得体会

篇一: 软件测试学习感悟
学习软件测试感受及体会
这学期学习了赵培英老师教授软件测试这门计算机专业专业课, 我们学院又开设了刘老师相关这方面讲座, 更根本使我们加深了对软件测试认识。所以我想谈谈相关软件测试体会及学到部分知识。
作为计算机专业一门很关键课程, 在计算机领域占据着不可替换角色, 伴随人类社会进步, 多种领域计算机普及, 计算机软件也越来越多出现在各个场所, 为大家办公, 生活, 学习, 休闲等提供了前所未有方便。软件测试, 其目是: 第一是确定软件质量, 其首先是确定软件做了你所期望事情（Do the right thing）, 其次是确定软件以正确方法来做了这个事件（Do it right）。作为计算机专业学生, 我想以我自己见解来叙述一下我对软件测试了解。
以前, 就是在我没有认真了解测试行业之前, 我也一直认为测试应该是不关键, 甚至认为有必需有专门测试职业吗？认为软件关键是开发人员事, 软件结果也是由开发人员决定, 当我学了软件工程这门课, 真正了解到它必需性, 实际上真不是那么一回事哦。软件无处不在, 然而, 软件是人编——所以不完美。
我还查阅了部分资料就是不注意软件测试案例:
1、 迪士尼狮子王 （1994～1995）软件在少数系统中能正常工作, 但在大众使用常见系统中不行。以后证实, 迪士尼企业没有对市场上投入实用多种pc机型进行正确测试。
2、 英特尔飞跃浮点除法软件缺点（1994）英特尔为自己处理软件缺点拿出4亿美元支付更换坏芯片费用。造成付出如此昂贵代价, 其关键原因是发觉了软件缺点没有正确处理。
3、 美国航天局火星极地登陆（1999）该项目使用前有经过测试, 两个测试小组双方独立工作都很好, 但从未走在一起。
4、 爱国者导弹防御系统 （1991）一枚导弹在多哈击毙28名美国士兵, 症结在于一个软件缺点: 一个很小系统时钟错误累积起来就可能拖延14小时,
造成跟踪系统失去正确度。在多哈攻击战中系统被拖延100小时。
5、 千年虫 （大约1974）估量世界各地更换或升级该系统程序处理原有错误费用已经超出数亿美元。
这就是不重视测试部分严重后果, 所以我们发觉了软件测试必需性! 在设计有效测试用例之前, 测试工程师必需了解软件测试基础标准, 包含: 1 、 全部测试都应追溯到用户需求。正如我们所知: 软件测试目标在于揭示错误。而最严重错误（从用户角度来看）是那些造成程序无法满足需求错误。
2 、 应该在测试工作真正开始前较长时间内就进行测试计划。测试计划能够在需求模型一完成就开始, 具体测试用例定义能够在设计模型被确定后立刻开始。所以, 全部测试应该在任何代码被产生前就进行计划和设计。
3 、 Pareto 标准应用于软件测试。简单地讲, Pareto 标准暗示着测试发觉错误中 80 ％很可能起源于程序模块中 20 ％。当然, 问题在于怎样孤立这些有疑点模块并进行根本测试。
4 、 测试应从 " 小规模 "
开始, 逐步转向 " 大规模 " 。最初测试通常把焦点放在单个程序模块上, 深入测试焦点则转向在集成模块簇中寻求错误, 最终在整个系统中寻求错误。
5、 为了达成最好效果, 应该由独立第三方来结构测试。 " 最好效果 " 指最有可能发觉错误测试（测试关键目标）, 所以创建系统软件工程师并不是结构软件测试最好人选。
6、 不充足测试是不负责任; 过分测试是一个资源浪费, 一样也是一个不负责任表现.。
还有就是相关软件测试分类: 从是否需要实施被测软件角度, 可分为: －静态测试
－动态测试
从测试是否针对系统内部结构和具体实现算法角度来看, 可分为 : －白盒测试
－黑盒测试
相关静态测试和动态测试:
（1）静态测试是指不实际运行被测软件, 而只是静态检验程序代码、 界面或文档中可能存在错误过程。
其中包含代码测试、 界面测试和文档测试3个方面。对于代码测试, 关键测试代码是否符合对应标准和规范。对于界面测试, 关键测试软件实际界面与需求中说明是否相符。对于文档测试, 关键测试用户手册和需求说明是否符适用户实际要求。
（2）动态测试是指实际运行被测程序, 输入对应测试数据, 检验实际输出结果和预期结果是否相符过程。所以, 我们判定一个测试属于动态还是静态测试 , 唯一标准就是看是否运行程序。
相关黑盒测试和白盒测试 :
（1）黑盒测试
指是把被测软件看作是一个黑盒子, 我们不去关心盒子里面结构是什么样子, 只关心软件输入数据和输出结果。
黑盒测试方法是在程序接口上进行测试, 关键是为了发觉以下错误:
? 是否有不正确或遗漏了功效?
? 在接口上, 输入能否正确地接收? 能否输出正确结果?
? 是否有数据结构错误或外部信息(比如数据文件)访问错误?
? 性能上是否能够满足要求?
? 是否有初始化或终止性错误?
用黑盒测试发觉程序中错误, 必需在全部可能输入条件和输出条件中确定测试数据, 来检验程序是否都能产生正确输出。 但这是不可能。
黑盒测试测试用例设计
? 等价划分法
? 边界值法
? 错误推测法
? 因果图法
（2）白盒测试
指是把盒子盖打开, 去研究里面源代码和程序结构。
白盒测试也称结构测试或逻辑驱动测试, 它是知道产品内部工作过程, 可经过测试来检测产品内部动作是否根据规格说明书要求正常进行, 根据程序内部结构测试程序, 检验程序中每条通路是否都有能按预定要求正确工作, 而不顾它功效。 使用被测单元内部怎样工作信息, 许可测试人员对程序内部逻辑结构及相关信息来设计和选择测试用例, 对程序逻辑路径进行测试。基于一个应用代码内部逻辑知识, 测试是基于覆盖全部代码、 分支、 路径、 条件。
白盒测试关键方法:
? 逻辑驱动测试
? 基础路径测试
关键用于软件验证。
使用程序设计控制结构导出测试用例。
逻辑驱动测试:
关键是测试覆盖率, 以程序内在逻辑结构为基础测试。包含以下6种类型: ? 语句覆盖
? 判定覆盖
? 条件覆盖
? 判定-条件覆盖
? 条件组合覆盖
? 路径覆盖
白盒测试关键目
? 确保一个模块中全部独立路径最少被实施一次;
? 对全部逻辑值均需要测试真、 假两个分支;
? 在上下边界及可操作范围内运行全部循环;
? 检验内部数据结构以确保其有效性
测试是软件开发过程关键组成部分, 是用来确定一个程序品质或性能是否符合开发之前所提出部分要求。软件测试目, 第一是确定软件质量, 其首先是确定软件做了你所期望事情（Do the right thing）, 其次是确定软件以正确方法来做了这个事件（Do it right）; 第二是提供信息, 比如提供给
开发人员或程序经理反馈信息, 为风险评定所准备信息; 第三软件测试不仅是在测试软件产品本身, 而且还包含软件开发过程。假如一个软件产品开发完成以后发觉了很多问题, 这说明此软件开发过程很可能是有缺点。
经过这一门课程学习和老师给我们讲座, 意识到测试并非是我想像从用户角度任意使用软件产品, 从而发觉有没有质量问题, 它有它理论和实践体系。软件测试是一项严谨工作, 软件测试员一个基础素质是打破砂锅问到底。喜爱找出那些深藏不露系统冲突, 乐于处理最复杂问题, 外表上热衷於往返奔忙, 追求尽善尽美, 为征服系统而额手称庆。
最终尤其感谢老师对我们课程学习讲授, 让我们了解到计算机更多知识, 也让我们了解到求职相关计算机方面岗位, 应含有哪些专业知识, 谢谢老师!
篇二: 软件测试培训心得体会
软件测试培训心得体会
概述
8月2日至8月6日, 中国软件评测中心测试技术应用与实践培训课程在武汉召开, 本人非常荣幸参与此次培训, 经过这次经验让我系统梳理了软件测试理论技术, 对软件测试有了一个更深入更全方面认识。
下面请准许我简述软件测试概念及软件测试在软件工程中关键性。
一: 软件测试历史与发展 到了上世纪80年代早期, 软件和IT行业进入了大发展, 软件趋向大型化、 高复杂度, 软件质量越来越关键。这个时候, 部分软件测试基础理论和实用技术开始形成, 而且大家开始为软件开发设计了多种步骤和管理方法, 软件开发方法也逐步由混乱无序开发过程过渡到结构化开发过程, 以结构化分析与设计、 结构化评审、 结构化程序设计以及结构化测试为特征。大家还将“质量”概念融入其中, 软件测试定义发生了改变, 测试不单纯是一个发觉错误过程, 而且将测试作为软件质量确保(SQA)关键职能, 包含软件质量评价内容, Bill Hetzel在《软件测试完全指南》(Complete Guide of Software Testing)一书中指出:“测试是以评价一个程序或者系统属性为目标任何一个活动。测试是对软件质量度量。”这个定义至今
仍被引用。软件开发人员和测试人员开始坐在一起探讨软件工程和测试问题 。
软件测试已经有了行业标准(IEEE/ANSI ), 1983年IEEE提出软件工程术语中给软件测试下定义是:“使用人工或自动手段来运行或测定某个软件系统过程, 其目在于检验它是否满足要求需求或搞清预期结果与实际结果之间差异”。这个定义明确指出:软件测试目是为了检验软件系统是否满足需求。它再也不是一个一次性, 而且只是开发后期活动, 而是与整个开发步骤融合成一体。软件测试已成为一个专业, 需要利用专门方法和手段, 需要专门人才和教授来负担。
进入上世纪90年代, 软件行业开始迅猛发展, 软件规模变非常大, 在部分大型软件开发过程中, 测试活动需要花费大量时间和成本, 而当初测试手段几乎完全都是手工测试, 测试效率非常低;而且伴随软件复杂度提升, 出现了很多经过手工方法无法完成测试情况, 尽管在部分大型软件开发过程中, 大家尝试编写了部分小程序来辅助测试, 不过这还是不能满足大多数软件项目统一需要。于是, 很多测试实践者开始尝试开发商业测试工具来支持测试, 辅助测试人员完成某一类型或某一领域内测试工作, 而测试工具逐步盛行起来。大家普遍意识到, 工具不仅仅是有用, 而且要对今天软件系统进行充足测试, 工具是必不可少。测试工具能够进行部分测试设计、 实现、 实施和比较工作。经过利用测试工具, 能够达成提升测试效率目。测试工具发展, 大大提升了软件测试
自动化程度, 让测试人员从繁琐和反复测试活动中解脱出来, 用心从事有意义测试设计等活动。采取自动比较技术, 还能够自动完成测试用例实施结果判定, 从而避免人工比对存在疏漏问题。设计良好自动化测试, 在一些情况下能够实现 “ 夜间测试 ” 和 “ 无人测试 ” 。在大多数情况下, 软件测试自动化能够降低开支, 增加有限时间内可实施测试, 在实施相同数量测试时节省测试时间。 而测试工具选择和推广也越来越受到重视。
在软件测试工具平台方面, 商业化软件测试工具已经很多, 如捕捉/回放工具、 Web测试工具、 性能测试工具、 测试管理工具、 代码测试工具等等, 这些都有严格版权限制且价格较为昂贵, 但因为价格和版权限制无法自由使用, 当然, 部分软件测试工具开发商对于一些测试工具提供了Beta测试版本以供用户有限次数使用。幸运是, 在开放源码小区中也出现了很多软件测试工具, 已得到广泛应用且相当成熟和完善。
二: 软件测试概念与目
软件测试就是利用测试工具根据测试方案和步骤对产品进行功效和性能测试, 甚至依据需要编写不一样测试工具, 设计和维护测试系统, 对测试方案可能出现问题进行分析和评定。实施测试用例后, 需要跟踪故障, 以确保开发产品适合需求。
1. 测试目是为了表明软件能够工作
2. 测试目是为了表明软件不能够能够正常工作
3. 测试目不是要证实什么, 而是为了把软件不能正常工作预知风险降低到能够接收程度
4. 测试不是行为, 而是一个自觉约束, 不用太多测试投入产生低风险软件上 。
三: 自我体会
体会一: 软件测试在整个软件生命周期中关键性它存在于整个项目周期, 在项目开始之初需求调研时候就开始了, 在形成需求规格说明书时候就需要针对文档进行测试。这个步骤在后续整个项目中占了很大比重, 能主导整个软件项目走向, 成败是否全在于开始阶段决议。
体会二: 软件测试真正意义这与发觉错误, 而不在于验证软件是正确
在严格测试也不能完全发觉软件当中全部错误, 不过测试还是能发觉大部分错误, 能确保软件基础可用和软件适用性, 所以在后使用过程中还需要加强快速响应步骤。结合软件测试理论, 故障暴露在最终用户端之前立刻主动去发觉并处理。这点需要加强研发队伍建设。
体会三: 在系统性能方面需要重视
经过这次培训中多个案例讲解, 让我了解到系统在上线以后会有很多不能预知性能问题, 需要在上线之前实现进行模拟, 以避免风险, 包含大数据量访问, 高并发数等等。当然也有很多应对手段, 没有那种手段能够称最完美, 只有最适宜, 需要灵活掌握, 综合利用以达成最优程度, 这个很值大家一起研究。
四: 个人想法
依据软件部门现在情况, 接下为了我们软件能在质量上得到保障减轻项目后期维护验收风险, 在此做以下想法和提议; 想法一: 有效制订软件测试步骤;
因为前期软件工程项目中, 未对软件进行系统化测试, 造成后期维护成本较高, 变相增加了软件开发人职员作量。 方案:
1: 测试需求分析
? 明确需求范围
? 明确每个功效业务处理步骤
? 不一样功效点作业务组合
? 挖掘显示需求背后隐藏需求
? 测试需求分析: 单功效点输入输出------业务流分析-------
篇三: 软件测试心得
软件测试心得体会
软件测试工作是一个系统而复杂工程, 软件测试目就是确保软件质量、 确定软件以正确方法做了你所期望事情, 所以工作关键任务是发觉软件错误、 有效定义和实现软件成份由底层到高层组装过程、 验证软件是否满足规格书要求和系统定义文档所要求技术要求、 为软件质量模型建立提供依据。
而且软件测试不仅是要确保软件质量, 还要给开发人员提供信息, 以方便其为风险评定做对应准备, 以及为其提供分析依据, 关键是要贯穿在整个软件开发过程中, 确保整个软件开发过程是高质量。
软件测试对测试工程师来讲, 要求含有较强专业知识, 严谨细心耐心测试态度, 良好反向思维、 发散思维能力、 沟通能力等等。
以下是就自己个人工作经历谈部分浅见:
1. 标准文档制订:
1.1.任何一个企业要让自己产品面市, 都要有自己一
套完整品质标准, 这个标准一定是在符合国家标准及用户
标准基础上形成企业标准, 系统而全方面地描述一款
产品功效、 性能、 可靠性、 健壮性、 安规要求等一系
列产品标准, 并依据用户特定要求对应调整。
1.2.测试仪器作业指导书(SOP)及保养说明等。定义仪器
使用步骤、 操作指南和保养细则等。
2. 测试资料归档:
标准媒体文件、 测试汇报、 BUG LIST库（电子类问题、 结构
类问题、 软件类问题: 方案自存问题、 品证测试问题、 生产
测试问题、 用户反馈问题、 终端消费者反馈问题等）、 认证测
试文档归纳总结(认证企业培训资料、 认证过程中出现并改善
问题)、 测试工程师经验分享、 常见问题解答FAQ等。
3. 功效测试:
3.1.这是软件测试工作中最关键和最基础一项测试, 该测
试关键内容是检验软件是否符合需求定义, 并经过构
造正常操作来检验动作是否正确; 在这个测试里,
正确性是最最关键软件质量要素。
3.2.功效测试根据可见性能够分为两类: 显性功效和隐性功
能。
显性功效: 指在菜单里能够看得到功效。
隐性功效: 指在菜单里看不到功效。
比如, 电话本显性功效有增加、 编辑、 删除、 拨打等,
这些功效能够在电话本菜单里面看得到, 姓名列表排
序则属于一个隐性功效, 因为在电话本菜单里没有这
样一个子菜单, 但它却是一个实实在在功效。
如以下这些隐性功效都测试中都需关键关注:
a. 电话本上下页切换, 是否有遗漏联络人信息？
b. 是否支持手机内存、 SIM卡电话本同时下载？还是
支持从一个介质里下载？
c. 断电后再上电, 系统设置时间是否有记忆功效？
d. GPS信号正常时, 导航地图中时间是否有更新？
e. TFT屏在Power off→on, ACC off→on时, 屏角度
是否有记忆？
f. 模拟导航时, 是否有双工功效？后台源声音输出是否
正常？
g. 路试语音产品外置麦克风使用效果时, 考虑车速、 风
声、 车内讲话噪声、 汽车底盘/发动机噪声等对麦克
风录音效果影响, 软件多线程开启时造成资源占
用/系统繁忙对后台录音系统影响。(也可从结构方
面考虑: 外置麦克风型腔开孔接触面积, 是否360
度可旋转等来增加录音路径等。）
h. 地图上POI信息经过后台语音搜索获取不到, 处理
方法: 要求方案商讯飞完善后台语音库。
3.3.在实际测试过程中, 显性功效经过菜单遍历能够很容
易地进行无遗漏测试, 不过隐性功效却很轻易为我们
所忽略! 一个有效处理措施是去检验软件功效定义
列表(Feature List), 从这个列表里面找出那些隐性
功效。
3.4.制订测试用例时, 要充足考虑各功效模块软件显性功
能和隐性功效。
4. 健壮性测试:
橘生淮南则为橘, 生于淮北则为枳。是说明橘健壮性太差。
该成语充足说明了我们对产品进行健壮性测试必需性。
4.1.健壮性是指在异常情况下, 软件还能正常运行能力。
健壮性有两层含义: 一是容错能力, 二是恢复能力。
健壮性测试关键包含: 电子硬件健壮性(如: 遥控距离测
试、 高低电压适应性测试、 插拔电及开关机测试、 静电
抗扰度测试、 热插拔测试)和机械健壮性(如: 整机结构
设计基准测试、 模拟运输测试、 常温包装跌落测试)。
4.2.这项测试关键是检验软件对异常操作容错能力, 异常
操作通常要考虑异常输入操作及异常条件两个方面。 比如: 测试蓝光媒体播放器时, 反复把HDMI连接线拔掉, 造成通信异常中止, 再接上复合视频(CVBS)信号输出, 即由数字信号输出转为模拟信号输出。恢复测试关键考察一下几项: （1）系统能否重新运行; （2）有没相关键数据丢失; （3）是否毁坏了其它相关软件或硬件; （4）若软件出现系统报错, 是否有自恢复能力。
4.3.软件很多功效实现是有很多隐含条件, 在健壮
性测试中, 要检验当这些条件不满足时候反应。 比如: 现在大多数3G智能手机, 与各电信运行商形成利益捆绑, 每款手机支持特定电信运行商提供通信服务, 其它运行商提供服务则被拒之门外。当使用移动SIM卡安装在只支持联通通信服务3G手机上, 关注该手机表现: 是否在实施自动更新时重启？还是实施自动更新后提醒不支持移动运行通信服务: SIM card not supported, emergency calls only？
比如: 在做完常温包装跌落测试后, 再测试机芯读碟能力, 读取偏芯碟、 面振碟、 偏重心碟、 刮痕碟、 指纹碟等等碟片, 与未做跌落测试前读碟能力进行比较。假如读碟能力比以前更差, 则考虑改善方法: 软件合适增加录轨时间或机芯托盘加固等。