软件测试工程师的工作总结1与软件测试技术工作总结多篇范文汇编doc.docx
《软件测试工程师的工作总结1与软件测试技术工作总结多篇范文汇编doc.docx》由会员分享，可在线阅读，更多相关《软件测试工程师的工作总结1与软件测试技术工作总结多篇范文汇编doc.docx（21页珍藏版）》请在冰豆网上搜索。
软件测试工程师的工作总结1与软件测试技术工作总结多篇范文汇编doc
软件测试工程师的工作总结1与软件测试技术工作总结（多篇范文）汇编
软件测试工程师的工作总结
【摘要】 软件质量越来越受到人们的关注，软件测试作为新兴行业有很多不完善的地方。
很多从事软件测试工作的同行处于迷茫之中，如何提高，如何解决测试工作中的实际问题，困惑着每一个人。
本文总结了一下个人经验，希望对大家有帮助。
【关键词】 软件测试 软件 测试学习 软件测试工程师
我最初参加测试工作的时候，不知道什么是软件测试，集成测试和系统测试的概念经常混淆， cmm 是什么就更加不知道了。
那时候最简单的开关机也是通过直接拔插电源完成，安装系统对我来说简直是有史以来人类的最高技能，对于那些拿着螺丝刀安装机器的人就认为是宇内超级高手，身具杀人于无形之绝世秘技。
拿破仑说不想当将军的士兵不是好士兵，我最初的梦想就是想成为软件测试的高手，傲视天下。
所以不断偷师，总结经验，自认为掌握了成为高手的几个秘技，这几年混迹 “ 江湖 “ 还算无往而不利。
不敢独享，望与吾辈测试人员切磋，早日总结成功密技之大成，助新进人员早日入门，也算不愧对东北活雷锋的称号。
第一招 学会利用网络
刚参加工作面对浩瀚的网络世界，当时如刘姥姥进大观园，什么都新奇，什么都想要，从网上下载很多源程序的代码，软件技术文档之类，恨不得把所有的好东西收集到手中，其实有些在他人看起来就是垃圾一堆。
当时觉得有了这些 “ 武林秘籍 “ ，成为高手指日可待。
最初参加工作由于自己工作努力有幸转为开发，加入项目组后我的习惯还是没有改，反而变本加厉，手中的资源更加多，上网的时间更加频繁。
一次项目经理分配任务，觉得依靠手中的秘籍加上自己的 “ 聪明才智 “ 很快会完成，不料短短的时间，所有的一切变成了马奇诺防线。
解决问题很慢，思路不清晰，项目经理在对我施压的过程中教会了我终身难忘的一招，学会利用网络寻找要解决问题的答案，从此 google 成了我的最爱，关键字成了我变化的招数。
在软件测试工作中，他帮我解决了很多疑难问题，解答了很多令我迷惑的地方。
也是我帮助测试同行解决问题手段之一，很多软件测试新手，甚至老手都没有意识到自己手上就握有 “ 无敌秘籍 “ ，所以只要你耐心找，答案就在身边。
这里总结一下利用网络搜索引擎的技巧：
组合搜索
每次搜索某个文件，如果只给出一个单词进行搜索，经常会出现成千上百万计的匹配网页。
然而如果再加上一个单词，那么搜索结果会更加切题。
选择表述内容的词组
一般我在网页搜索引擎的时候，选择一些可以表达我要查找内容的关键词组，用来缩小搜索范围，从而找到搜索结果是最好的办法。
运用词组搜索涉可以先先简单地输入一个问题作为词组搜索，如果仍然找不到合适的，那就用多个可以表达要查询内容的关键字进行查询。
定位信息来源
有的时候用词组搜索不到或者无法准确表达所需信息。
可以用另一种方法直接到信息源，就是直接到到提供某种信息的站点去。
可以用公式 “ 公司名 ” 去猜测某一组织的特点。
从而得到所要搜索的信息的主要词组
其实网络上还有很多关于搜索技巧的文章，大家可以自行学习。
千万要记住搜索引擎是帮助你成功的有力武器。
第二招 学会动手
参加软件测试工作后，随着工作经验的增长自我感觉越来越好。
在公司里也逐渐受到同事领导的重视，一次针对公司的新的软件功能进行测试的时候，像往常一样 “ 随手 “ 测试出了几个 bug ，然后 “ 仔细 “ 的填写了 bug 单（这个 bug 的现象已经出现了很多次了）。
这时候测试经理走过来，重新复查了一下填写的 bug 。
他在重现我的 bug 的过程中，简化了我的输入变化， bug 神奇的又出现了，同样的现象，他关闭软件重新变化输入，扩展出 10 几个变化后，软件不动了，内存不断上升。
终于他找到了产生软件的 bug 的原因，然后对我说 “ 寻找 bug 要准确定位，我们开发团队是一个整体，时间是等量的，时间不在你身上浪费，就是在他身上浪费。
如果测试人员每次发现的 bug 描述不清楚，并且多个问题潜在的错误原因是一个，虽然操作可能稍微有些变化。
这样开发人员在重现 bug 的时候他要调试跟踪判断，很花费时间，而且效率低。
如果测试人员发现 bug 的时候多动手可以更加准确的定位 bug 步骤和原因，给开发人员最精确的步骤和准确的描述，这样整个团队才能高效，所以需要大家协作！
。
“ 。
在以后的日子里，每次解决问题的时候我都记得多试验几次，多尝试。
网上很多朋友还有同事问我问题的时候，其实他们只是万里长征就差一步，只要再多动手实验一次就可以达到目的了。
所以多动手，多尝试。
第三招 思考自己所作的
刚开始入行的时候，总是思考如何做好软件测试。
认为公司的测试流程混乱总是很郁闷，认为自己学不到东西，如何才能测试好产品，常说心动不如行动，以前看到古龙小说中经常出现的场景无名小子不断挑战高手，总结积累。
我总结了有些经验是实战中得到的，所以不断尝试引入新的测试流程然后评估，这个过程虽然很痛苦，但是从中积累了不少经验。
这段时间让我学习到了很多东西，接触了 iso,cmm ，测试管理工具，自动化工具（因为公司不正规给了我很多学习的机会，后来到了比较大的软件公司后，以前的经历给了我更多的发展机会，因为大公司非常正规了，公司内部人员分工明确，所以能力的锻炼反倒少了）。
由于工作中经常写报告反倒养成了总结教训的习惯，因为纸面上的东西是永远也忘不掉的。
在写的过程中可以不断补充扩展，整个过程是思想升华的过程，当年达摩面壁九年就是融会贯通的典型例子，如果他不是有个思考的过程，他也不能成为一代大家。
如果后来不时有人把他的绝技记录下来，也就不能有后来的少林寺七十二绝技。
所以善于思考，总结经验，也是成为高手之路的不二法决。
第四招 学会利用论坛资源
其实测试新兵和测试高手之间的区别，往往是不会利用现有资源。
在论坛中我们会看到很多新手不断的提问，但是有很多问题其实都是已经别人提过了，或者已经有解决方案的。
所以经常会看到 “测试高手“的身影，并且不提问题，而且还能“锄强扶弱“，是测试新丁的救命稻草。
好像是高手们无所不能，其实摘掉这层耀眼的光环，他们并没想像得那么厉害，只不过通过自己的搜索找到的答案，然后帮助其他人。
当然也有很多人都是通过自学，然后在论坛中交流得到了很多经验，高手其实也是因为善于思考问题，亲自动手解决问题。
所以动手和利用论坛资源的过程中他们也在不断提高。
很多时候看到论坛中有人提问，问题描
述不清，很多人看了很困惑。
发贴题目动不动请高手帮忙，救命之类的，好像天下大乱，世界末日。
虽然这个题目很招人，但是无法让那些想帮助你的人帮你，因为题目不清晰，而且高手字样吓阻了很多人。
其实问问题也是个思路整理的过程，描述清晰，让人理解清楚，才能望文知意知道你的当前发生问题的环境，才能让那些想帮你的人解决问题，否则给人无从下手的感觉，解决问题效率不高。
第五招 学习和你所测试的软件产品相关的知识
要想成为好的测试人员，还要了解你要测试的软件的相关知识。
要了解软件产品的架构是什么样的。
要了解软件的市场需求，在接触软件之初要可以多看看用户的反馈信息，这些才是用户最关心的，也是你在测试中需要注意的问题，满足客户是最大的需要。
但是了解软件需求之后要学会要多读些软件系统的技术文档，软件设计文档，这些文档可以帮助你了解产品如何工作。
还有多看看公司 bug 库中的问题，这些存在的问题可以帮助你了解软件产品那些地方存在缺陷，软件系统那些地方会出现错误。
软件是运行在一个大环境中，如果对系统不熟悉，那么有些问题你不能从一个更广阔的层面考虑，学习操作系统的知识，有助于你发现缺陷，定位问题更加准确。
比如软件运行在 windows 或者 linux ，如果你不懂操作系统，你就无法建立测试环境，有些时候时候软件的组件发生问题，就是你系统配置造成的，对系统不熟悉，你会把外在原因归结为软件本身。
所以要学习关于和软件系统相关的知识，比如编程，网络，数据库等。
不一定你要学习到多好的程度，只是通过这些扩展的知识面，你可以在发现问题，解决问题上不会局限在狭小的圈子里。
和一切相关的人员交流，不同的交流渠道，获取消息是不同的，角度也不同。
和客户交流，你会在测试中从客户的角度发现问题；和开发人员交流，你会了解开发人员怎么实现软件功能的；和项目管理人员交流，你会知道开发进度以及遇到的困难。
软件测试技术工作总结
it公司面试手册提供最全的it类面试题,包括
java：
java面试题j2ee面试题hibernate面试题spring面试题struts面试题ejb面试题.net:
.net面试题面试题c#面试题
数据库：
数据库面试题oracle面试题sqlserver面试题mysql面试题
网络：
网络技术面试题网络安全面试题
web开发：
php面试题web开发面试题
linuxunix：
unix面试题linux面试题
软件测试：
软件测试面试题
其他类：
英语面试外企面试python面试题程序员面试
更多面试题请访问：
:
//
软件测试技术总结
软件测试就是为了发现程序中的错误而分析和执行程序的过程。
——概念
+基本知识+软件开发过程-定义-计划-实现-稳定化-部署
一、软件开发模型（四种典型的模型）
1、瀑布模型
概述：
包括计划，需求分析，设计，编码，测试，运行维护六个阶段。
六个阶段自上而下、相互衔接，以固定的次序进行。
特点：
1.阶段的顺序性和依赖性；2.文档驱动；3.推迟实现的观点；4.质量保证。
缺点：
不适合需求模糊的系统
2、原型模型
概述：
先建立一个能够反映用户需求的原型系统，使得用户和开发者可以对目标系统的概貌进行评价和判断，然后对原型系统进行反复的扩充、改进、求精，最终建立符合用户需求的目标系统。
特点：
1.快速开发工具；2.循环；3.低成本。
分类：
按照对原型的处理方式，可以分为渐进型和抛弃型。
3、增量模型
概述：
在增量模型中每个阶段都生成软件的一个可发布版本，阶段交错进行，版本逐渐完善。
同原型模型的最大区别在于，在原型模型中每个阶段发布一个原型而在增量模型中则完成一个正式版本。
4、螺旋模型
概述：
适用于大型软件的开发，它将瀑布模型和快速原型模型结合起来，并加入了风险分析。
特点：
1.每个阶段都包括制定计划，风险分析，实施工程，评审四个阶段；2.开发过程迭代进行，每迭代一次螺旋线增一周，工程前进一个层次，系统生成一个新版本，投入新的时间成本，最终得到客户满意的版本。
-软件测试从需求开始：
现代的软件测试将测试渗入到软件开发的各个阶段，即使瀑布模型，表面看测试工作是在测试阶段开始的，事实上，在计划、需求、设计阶段，测试人员便已经开始了他们的工作，如：
了解软件需求，编写测试计划，搭建测试环境。
二、测试用例
1、三要素：
前提条件和操作步骤、预期结果、实际结果。
2、必须以需求为依据。
三、软件测试分类
1、是否关注软件结构和算法
-黑盒测试：
基于软件需求的测试方法。
-白盒测试：
基于软件内部设计和程序实现的测试方法。
2、是否执行被测试软件
-动态测试：
在测试过程中执行被测试软件的测试方法。
-静态测试：
------------不----------------------。
3、基于不同的测试阶段：
1、单元测试：
主要测试软件的单元模块，需要编写额外的测试驱动程序，采用白盒测试的方法，一般由开发人员完成。
2、集成测试：
将一些“构件”集成在一起时测试他们是否能正常运行，构件可以是程序模块，也可以是客户机-服务器程序等，需要编写测试仿真程序，采用白盒和黑盒相结合的方式，通常由开发人员承担。
3、系统测试：
测试软件系统是否符合所有的需求，包括功能性测试和非功能性测试。
一般由独立的测试人员完成，通常采用黑盒测试方法。
4、验收测试：
（α、β）与系统测试类似，但由客户或最终用户执行，测试软件是否符合需求规格说明书。
5、回归测试：
指在软件开发过程中，每次错误被修正后或软件的功能、环境发生变化后进行的测试。
四、软件测试的三个步骤：
1、测试计划：
测试人员首先对需求进行分析，最终定义一个测试集合，通过刻画和定义测试发现需求中的问题，然后根据软件需求同测试主管制定并确认“测试计划”。
2、测试设计和开发：
软件测试人员根据软件需求和软件设计说明书完成测试用例的设计和必要的测试驱动程序的开发。
3、执行测试：
需要做的工作包括搭建测试环境、运行测试、记录测试结果、报告软件缺陷、跟踪软件缺陷、分析测试结果，必要时进行回归测试。
五、测试工程师的能力要求：
1、5c
-controlled/ken'treuld/接受管理，有条理的
-petent/'kcmpitent/了解正确的测试技术
-critical/'kritikel/专注于发现问题
-prehensive/.kcmpri'hensiv/注意细节
-considerate/ken'siderit/能够和开发人员很好的交谈
2、职业素质-责任心-学习能力-怀疑精神-沟通能力-专注力-洞察力-团队精神-注重积累
六、制定测试计划的五个步骤：
1、分析和测试软件需求2、定义测试策略3、定义测试环境4、定义测试管理
5、编写和审核测试计划
如果在需求分析阶段发现并结果问题需要花费$1，则在设计阶段解决同样的问题需花费$5，在编码阶段需$10，交付后解决同样的问题需花费$200。
——越早测试越好
七、在需求分析过程中测试人员需要进行如下工作：
1）理解需求，参与审核需求文档；2）理解项目的目标、限制，了解用户的应用背景；
3）编写测试计划；4）准备测试资源。
八、需求测试
-需求测试测试的对象是主意而不是代码，针对文档进行测试。
九、好的需求文档的特征
1、具有清晰的格式和文档结构2、需求的内容正确3、需求的内容完整
4、需求具有可行性需求的必要性5、对不同的需求优先等级进行定义6、描述明确
7、可证性和可测试性8、可修改性-可追踪9、需求文档被及时更新
十、需求测试内容
1、需求文档是否符合公司的格式要求2、是否正确
3、要保证需求文档中所描述的内容是真实可靠的
4、这是“真正的”需求吗？
描述的产品是否是要开发的产品？
5、需求是否完备？
第一个发布的版本是否需要更多的功能？
列出的需求可以减少一部分？
6、需求是否兼容？
需求有可能是矛盾的。
7、需求是否可实现？
如：
需求设想的设备是否比实际运行的要快？
需求要求的内存、i/0设备是否太多？
需求的输入或输出设备要求的分辨率是否要求过高？
8、需求是否合理？
在开发进度、开发费用、产品性能、可靠性和内存使用之间存在着平衡关系。
9、需求是否可测？
对于软件测试人员来说判断需求是否可测是这个过程中最重要的工作。
十一、需求测试方法
1、复查review2、走查walkthrough3、审查inspection
十二、测试策略的内容
1、确定测试范围软件是无法被完全测试的2、确定测试方法不同的系统需要不同的测试方法
3、定义测试标准入口标准，暂停和继续的标准，出口标准等
十三、软件测试结束的标准
-基于测试用例的使用规则
1）构造测试用例（由相关人员进行评审）
2）执行测试用例中，当测试用例的不通过率达到20%则拒绝继续测试，待开发人员修正软件后再继续。
3）当功能性测试用例通过率达到100%，非功能性测试用例通过率达到90%时，允许正常结束。
-基于“测试期缺陷密度”规则---------含义：
对软件测试一个cpu小时发现的缺陷数，比较适用于系统测试-基于“运行期缺陷密度”规则---------含义：
把软件运行一个cpu小时发现的缺陷数，比较适用于验收测试注：
一个阶段的出口标准!
下一个阶段的入口标准
系统测试结束的标准!
软件的发布标准发布标准!
软件0缺陷
-选择测试工具是否需要，需要什么工具，怎么获取
-降低软件测试代价是企业普遍关注的问题，可通过
a.减少冗余和无价值的测试；b.减少测试阶段（万般无奈下）
十四、测试环境
-基本内容：
设备环境、软件环境、数据环境
-需考虑的因素-计算机平台-操作系统-浏览器-软件支持平台-外围设备-网络环境-其他专用设备-搭建测试环境时的配置原则：
-使用的频度或范围-实效的可能性-最大限度的模拟真实环境
十五、测试管理
由于测试工程中设计的人员、活动、工具是很多的，在制定测试计划时需要对这些因素进行管理-选择缺陷管理工具和测试管理工具-定义工作进度
-建立风险管理计划
（1）可能遇到的风险
1.由于设计、编码阶段出现大量质量问题，导致测试工作量时间增加
2.开始测试时所需的硬件、软件没有准备好3.未能完成对测试人员的技术培训
4.测试时的人力资源安排不足5.测试过程中，发生了大量的需求变更
6.测试过程中，项目的开发计划被大幅度调整7.不能及时准备好测试所需的环境
8.不能及时准备好测试数据
（2）风险管理的过程
1.识别风险2.评估风险3.制定对策4.跟踪风险
+测试设计与开发
+总体设计
-投入产出：
测试设计的输入是测试计划，输出是评审过的测试用例集合
-定义设计目标遵循的原则
（-清楚地说明没项测试的目标-使每项测试的目标单一，可以对应到规格说明书中的一项需求-只说明测试应该完成什么工作，而不说明如何完成）
-流程：
总体设计-开发测试用例-评审测试用例
i.定义设计目标ii.定义输入说明iii.定义测试环境和配置
iv.测试设计文档v.开发测试用例
+测试用例——概念：
为特定目标开发的测试输入、执行条件和预期结果的集合。
+好的测试用例：
1.容易发现软件的错误2.精确的重复某测试失败的情景，可重复性
3.清晰的定义一个或多个期望的结果4.没有冗余
+测试用例的作用
-指导测试的实施-作为编写测试脚本的“设计规格说明书”-评估测试标准的度量基准-分析缺陷的标准+白盒测试用例设计
+设计方法
+逻辑覆盖法
（-语句覆盖-判定覆盖-条件覆盖-判定-条件覆盖-条件组合覆盖-路经覆盖-基本路经法）
+辅助模块设计
（1.驱动模块：
相当于被测程序的主程序。
接受测试数据，把这些数据传给被测模块然后输出实际测试结果。
2.桩模块：
用于调用被测模块调用的子模块。
可以做少量的数据操作，不需要把子模块的所有功能都带进来，但不容许什么都不做。
）
+黑盒测试用例设计
-等价类划分法
-边界值法——“缺陷遗漏在角落里，聚集在边界上。
”
-因果图法弥补等价类和边界值法的不足
-错误推测法
-测试用例的管理可以通过配置管理工具cvs,vss,clearcase等实现，以保证测试是可重复的。
+常见错误分析
-用户界面问题
·输入无合法性检查和值域检查。
·界面信息不能及时更新，不能正确反映数据状态，甚至对用户产生误导。
·表达不清或过于模糊的信息提示。
·要求用户输入多余的本来系统可以自己得到的数据。
·为了得到某个设置或对话框用户必须做许多冗余的操作，如对话框嵌套太多。
·不能记忆用户的设置或操作习惯，使每次进入系统用户都需重新操作一次初始环境。
·不经用户确认就对系统或数据进行了重大修改。
-形象类问题
·不符合用户的操作习惯。
如，快捷键定义不科学不实用，甚至无快捷键。
·不够专业，缺乏基本知识。
·界面中英文混杂，甚至拼写错误。
·说明书或帮助的排版格式不专业：
中英文不对应，标点的半全角问题，没有排版准则。
·界面元素参差不齐，文字不能完全显示。
－稳定性问题
·不可重现的死机，或不断申请但不能完全释放资源，使系统性能越来越低。
·主系统和子系统使用了相同的临界资源而相互不知道。
如：
使用相同的类名或临时文件名、使用同样的数据库字段名或登陆帐号。
·不能重现的错误，许多与代码中的未初始化变量有关，有些与系统不检查异常情况（网络中断、内存申请不成功、长时间无响应等）有关。
-其他问题
·运行时不检查内存、硬盘空间、数据库等。
·无根据的假设用户环境：
硬件/网络情况；有些动态库；假设网络随时都是联通的。
·提供的版本带病毒。
·提供错误的版本给测试组或测试用户，或程序员与测试组使用不同版本。
·用户现场开放和修改，又没有记录和保留。
·版本中部分内容或接口倒退，或出现版本管理混乱。
·有些选项永远都是灰的，或有些在该变灰时没变灰。
+测试用例的评审
-测试或测试组件完全针对的是需求中列出的功能吗？
-测试组件是否覆盖了所有的需求？
-有冗余的吗？
-每个测试步骤都有清楚描述的预期结果吗？
+优先级
+3级
优先级1：
此测试用例必须执行-2：
有时间就执行-3：
可以不执行
+5级
1：
此测试必须通过，否则产品发布存在危险2：
在发布前必须执行3：
时间允许就执行4：
此测试可以在下一次发布或发布后短期内执行5：
可以不测试
第二篇：
软件测试技术面试总结
软件测试就是为了发现程序中的错误而分析和执行程序的过程。
——概念
+基本知识+软件开发过程-定义-计划-实现-稳定化-部署
+软件开发模型（四种典型的模型）
+瀑布模型
-概述：
包括计划，需求分析，设计，编码，测试，运行维护六个阶段。
六个阶段自上而下、相互衔接，以固定的次序进行。
-特点：
1.阶段的顺序性和依赖性；2.文档驱动；3.推迟实现的观点；4.质量保证。
-缺点：
不适合需求模糊的系统
+原型模型-概述：
先建立一个能够反映用户需求的原型系统，使得用户和开发者可以对目标系统的概貌进行评价和判断，然后对原型系统进行反复的扩充、改进、求精，最终建立符合用户需求的目标系统。
-特点：
1.快速开发工具；2.循环；3.低成本。
-分类：
按照对原型的处理方式，可以分为渐进型和抛弃型。
+增量模型
-概述：
在增量模型中每个阶段都生成软件的一个可发布版本，阶段交错进行，版本逐渐完善。
-同原型模型的最大区别在于，在原型模型中每个阶段发布一个原型而在增量模型中则完成一个正式版本。
+螺旋模型
-概述：
适用于大型软件的开发，它将瀑布模型和快速原型模型结合起来，并加入了风险分析。
-特点：
1.每个阶段都包括制定计划，风险分析，实施工程，评审四个阶段；
2.开发过程迭代进行，每迭代一次螺旋线增一周，工程前进一个层次，系统生成一个新版本，投入新的时间成本，最终得到客户满意的版本。
-软件测试从需求开始：
现代的软件测试将测试渗入到软件开发的各个阶段，即使瀑布模型，表面看测试工作是在测试阶段开始的，事实上，在计划、需求、设计阶段，测试人员便已经开始了他们的工作，如：
了解软件需求，编写测试计划，搭建测试环境。
-测试用例
-三要素：
前提条件和操作步骤、预期结果、实际结果。
-必须以需求为依据。
-软件测试分类
-是否关注软件结构和算法
-黑盒测试：
基于软件需求的测试方法。
-白盒测试：
基于软件内部设计和程序实现的测试方法。
-是否执行被测试软件
-动态测试：
在测试过程中执行被测试软件的测试方法。
-静态测试：
------------不----------------------。
-基于不同的测试阶段：
-单元测试：
主要测试软件的单元模块，需要编写额外的测试驱动程序，采用白盒测试的方法，一般由开发人员完成。
-集成测试：
将一些“构件”集成在一起时测试他们是否能正常运行，构件可以是程序模块，也可以是
客户机-服务器程序等，需要编写测试仿真程序，采用白盒和黑盒相结合的方式，通常由开发人员承担
升级会员 