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

学习协议测试的心得体会
学习协议测试心得体会

篇一：软件测试学习感悟
学习软件测试感受及体会
这学期学习了赵培英老师教授软件测试这门计算机专业专业课，我们学院又开设了刘老师关于这方面讲座，更彻底使我们加深了对软件测试认识。所以我想谈谈关于软件测试体会及学到一些知识。
作为计算机专业一门很重要课程，在计算机领域占据着不可替代角色，随着人类社会进步，各种领域计算机普及，计算机软件也越来越多出现在各个场合，为人们办公，生活，学习，休闲等提供了前所未有方便。软件测试，其目是：第一是确认软件质量，其一方面是确认软件做了你所期望事情（Do the right thing），另一方面是确认软件以正确方式来做了这个事件（Do it right）。作为计算机专业学生，我想以我自己观点来阐述一下我对软件测试理解。
以前，就是在我没有认真了解测试行业之前，我也一直认为测试应该是不重要，甚至认为有必要有专门测试职业吗？认为软件主要是开发人员事，软件成果也是由开发人员决定，当我学了软件工程这门课，真正了解到它必要性，事实上真不是那么一回事哦。软件无处不在，然而，软件是人编——所以不完美。
我还查阅了一些资料就是不注意软件测试案例：
1、迪士尼狮子王 （1994～1995）软件在少数系统中能正常工作，但在大众使用常见系统中不行。后来证实，迪士尼公司没有对市场上投入实用各种pc机型进行正确测试。
2、英特尔奔腾浮点除法软件缺陷（1994）英特尔为自己处理软件缺陷拿出4亿美元支付更换坏芯片费用。导致付出如此昂贵代价，其主要原因是发现了软件缺陷没有正确处理。
3、美国航天局火星极地登陆（1999）该项目使用前有经过测试，两个测试小组双方独立工作都很好，但从未走在一起。
4、爱国者导弹防御系统 （1991）一枚导弹在多哈击毙28名美国士兵，症结在于一个软件缺陷：一个很小系统时钟错误累积起来就可能拖延14小时，
造成跟踪系统失去准确度。在多哈袭击战中系统被拖延100小时。
5、千年虫 （大约1974）估计世界各地更换或升级该系统程序解决原有2000年错误费用已经超过数亿美元。
这就是不注重测试一些严重后果，因此我们发现了软件测试必要性！ 在设计有效测试用例之前，测试工程师必需理解软件测试基本原则，包括： 1 、所有测试都应追溯到用户需求。正如我们所知：软件测试目标在于揭示错误。而最严重错误（从用户角度来看）是那些导致程序无法满足需求错误。
2 、应该在测试工作真正开始前较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。
3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现错误中 80 ％很可能起源于程序模块中 20 ％。当然，问题在于如何孤立这些有疑点模块并进行彻底测试。
4 、测试应从 " 小规模 "
开始，逐步转向 " 大规模 " 。最初测试通常把焦点放在单个程序模块上，进一步测试焦点则转向在集成模块簇中寻找错误，最后在整个系统中寻找错误。
5、为了达到最佳效果，应该由独立第三方来构造测试。 " 最佳效果 " 指最有可能发现错误测试（测试主要目标），所以创建系统软件工程师并不是构造软件测试最佳人选。
6、 不充分测试是不负责任；过分测试是一种资源浪费，同样也是一种不负责任表现.。
还有就是关于软件测试分类：从是否需要执行被测软件角度，可分为： －静态测试
－动态测试
从测试是否针对系统内部结构和具体实现算法角度来看，可分为 ： －白盒测试
－黑盒测试
关于静态测试和动态测试：
（1）静态测试是指不实际运行被测软件，而只是静态检查程序代码、界面或文档中可能存在错误过程。
其中包括代码测试、界面测试和文档测试3个方面。对于代码测试，主要测试代码是否符合相应标准和规范。对于界面测试，主要测试软件实际界面与需求中说明是否相符。对于文档测试，主要测试用户手册和需求说明是否符合用户实际要求。
（2）动态测试是指实际运行被测程序，输入相应测试数据，检查实际输出结果和预期结果是否相符过程。所以，我们判断一个测试属于动态还是静态测试 ，唯一标准就是看是否运行程序。
关于黑盒测试和白盒测试 ：
（1）黑盒测试
指是把被测软件看作是一个黑盒子，我们不去关心盒子里面结构是什么样子，只关心软件输入数据和输出结果。
黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误:
? 是否有不正确或遗漏了功能?
? 在接口上，输入能否正确地接受? 能否输出正确结果?
? 是否有数据结构错误或外部信息(例如数据文件)访问错误?
?性能上是否能够满足要求?
? 是否有初始化或终止性错误?
用黑盒测试发现程序中错误，必须在所有可能输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确输出。 但这是不可能。
黑盒测试测试用例设计
?等价划分法
?边界值法
?错误推测法
?因果图法
（2）白盒测试
指是把盒子盖打开，去研究里面源代码和程序结构。
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书规定正常进行，按照程序内部结构测试程序，检验程序中每条通路是否都有能按预定要求正确工作，而不顾它功能。 使用被测单元内部如何工作信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序逻辑路径进行测试。基于一个应用代码内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。
白盒测试主要方法：
?逻辑驱动测试
?基本路径测试
主要用于软件验证。
使用程序设计控制结构导出测试用例。
逻辑驱动测试：
主要是测试覆盖率，以程序内在逻辑结构为基础测试。包括以下6种类型： ?语句覆盖
?判断覆盖
?条件覆盖
?判定-条件覆盖
?条件组合覆盖
?路径覆盖
白盒测试主要目
? 保证一个模块中所有独立路径至少被执行一次；
?对所有逻辑值均需要测试真、假两个分支；
?在上下边界及可操作范围内运行所有循环；
?检查内部数据结构以确保其有效性
测试是软件开发过程重要组成部分，是用来确认一个程序品质或性能是否符合开发之前所提出一些要求。软件测试目，第一是确认软件质量，其一方面是确认软件做了你所期望事情（Do the right thing），另一方面是确认软件以正确方式来做了这个事件（Do it right）；第二是提供信息，比如提供给
开发人员或程序经理反馈信息，为风险评估所准备信息；第三软件测试不仅是在测试软件产品本身，而且还包括软件开发过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷。
经过这一门课程学习和老师给我们讲座，意识到测试并非是我想像从客户角度任意使用软件产品，从而发现有无质量问题，它有它理论和实践体系。软件测试是一项严谨工作，软件测试员一个基本素质是打破砂锅问到底。喜欢找出那些深藏不露系统冲突，乐于处理最复杂问题，外表上热衷於来回奔忙，追求尽善尽美，为征服系统而额手称庆。
最后特别感谢老师对我们课程学习讲授，让我们了解到计算机更多知识，也让我们了解到求职关于计算机方面岗位，应具备哪些专业知识，谢谢老师！
篇二：软件测试培训心得体会
软件测试培训心得体会
概述
2012年8月2日至2012年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？
例如：在做完常温包装跌落测试后，再测试机芯读碟能力，读取偏芯碟、面振碟、偏重心碟、刮痕碟、指纹碟等等碟片，与未做跌落测试前读碟能力进行比较。如果读碟能力比以前更差，则考虑改进措施：软件适当增加录轨时间或机芯托盘加固等。