软件测试通知书 本文关键词：通知书，测试，软件
软件测试通知书 本文简介：软件测试通知书卷号卷内编号密级软件测试通知书项目名称：项目编号：编写人员：编写日期：审批人员：审批日期：软件测试通知书需求变更描述表需求分析书卷号**需求分析书卷内编号**功能名称4.2功能名称编码删除组织变更时间2004-7-20变更申请人李四（用户）变更原由删除组织(4.2)，在需求分析中描述为
软件测试通知书 本文内容：
软件测试通知书
卷号
卷内编号
密级
软件测试通知书
项目名称：
项目编号：
编写人员：
编写日期：
审批人员：
审批日期：
软件测试通知书
需求变更描述表
需求分析书卷号**
需求分析书卷内编号**
功能名称
4.2
功能名称编码
删除组织
变更时间
2004-7-20
变更申请人
李四（用户）
变更原由
删除组织(4.2)，在需求分析中描述为删除一个组织（部门），并解除与其下所有员工的关系。服务器更新数据库，并写日志。
经过仔细考虑和实际实施发现，那些被解除关系的员工，可能无人认领而长期游离与组织之外，给管理造成不便。
相关资料
编号
资料名称
提供人和部门
资料作用
1
部门级文档管理系统需求规格说明书
第二项目组
变更依据
2
3
4
功能变更描述
只能对那些没有员工的组织执行删除操作，若组织下有员工，则不能删除。
操作规程变更描述
用户删除非空组织时，提示：该组织下存在员工，不能被删除，请先将该组织下的员工删除或移至其他组织下。
处理过程变更描述
用户空组织执行删除操作时，程序首先检查该组织下有没有员工，若有，弹出对话框提示用户“该组织下存在员工，不能被删除，请先将该组织下的员工删除或移至其他组织下”，若没有，则删除该组织。
性能需求变更描述
无
-
1
-
篇2：工行个人消费信贷项目软件测试计划
工行个人消费信贷项目软件测试计划 本文关键词：工行，消费信贷，测试，计划，项目
工行个人消费信贷项目软件测试计划 本文简介：工行个贷项目工行个贷项目系统测试计划系统测试计划((文档编号文档编号:FO-HYZQ-24-01-001):FO-HYZQ-24-01-001)方正奥德计算机系统有限公司方正奥德计算机系统有限公司20022002年年1111月月文档管理信息表文档管理信息表主题：主题：系统测试计划版本：版本：1．0.
工行个人消费信贷项目软件测试计划 本文内容：
工行个贷项目工行个贷项目
系统测试计划系统测试计划
(
(文档编号文档编号:FO-HYZQ-24-01-001):FO-HYZQ-24-01-001)
方正奥德计算机系统有限公司方正奥德计算机系统有限公司
20022002
年年
1111
月月
文档管理信息表文档管理信息表
主题：主题：系统测试计划
版本：版本：1．0.0
内容：内容：工行个贷系统测试计划
关键字：关键字：
参考文档：参考文档：
提交时间：提交时间：2002
年
11
月
29
日
创建人：创建人：倪勇飚
文档修改记录表文档修改记录表
修改人修改人修改时间修改时间修改内容修改内容
I
宏源证券项目系统测试计划
目目
录录
一、一、
概述概述1
二、二、
引言引言3
1、编制目的
3
2、术语说明
3
三、三、
测试环境测试环境3
四、四、
测试人员组织测试人员组织4
五、五、
项目描述项目描述4
六、六、
测试功能（业务）列表测试功能（业务）列表8
七、七、
开始测试标准开始测试标准9
八、八、
结束测试标准（项目提交标准）结束测试标准（项目提交标准）9
九、九、
各个测试项的详细说明各个测试项的详细说明10
十、十、局限性局限性.10
1
宏源证券项目系统测试计划
一、一、
概述概述
规定测试活动中的任务、测试方法、进度、资源和人员职责等。
1
1、、
测试方法测试方法
可以以瀑布型描述软件工程过程，为了说明软件测试测策略，可以把软件工程的过程表达成一个螺旋形。首先，系统工程为软件
开发规定了任务，从而把他和硬件要完成的工作分开。接着便是进行软件需求分析，决定被开发软件的信息域、功能、性能、限制条
件并确定该软件项目完成后的确认准则。沿着螺旋形向内旋转，将进入软件设计和代码编写阶段。从而使得软件开发工作从抽象逐步
走向具体化。
C
U
I
V
ST
D
R
S
软件需求
分析
系统工程
软件设计
代码编写
系统测试
确认测试
组装测试
单元测试
2
宏源证券项目系统测试计划
软件测试工作也可以从这一螺旋线上体现出来。在螺线的核心点针对每个单元的源代码，进行单元测试。在各单元测试完成之后，
沿螺线向外前进，开始针对软件整体构造和设计的组装测试。然后是检验软件需求是否得到满足的确认测试，最后，来到螺线的最外
层，把软件和系统的其它部分协调起来，当作一个整体完成系统测试。这样，沿着螺旋线，从内向外，逐步扩展了测试的范围。
以上用螺旋线表明的测试过程，按四个步骤进行，即单元测试、组装测试、确认测试和系统测试。
确认
的软
件
集成
的软
件
设计
信息
模块
单元
测试
模块
单元
测试
模块
单元
测试
模块
单元
测试
组装测试确认测试系统测试
软件
需求
其它
系统
元素
已测
模块
3
宏源证券项目系统测试计划
开始分别完成每个单元的测试任务，以确保每个模块能正常工作。单元测试大量采用了白盒测试方法。尽可能发现模块内部的程
序查错。然后，把已测试的模块组装起来，进行组装测试。其目的在于检测与软件设计相关的程序结构问题。这时较多地采用黑盒方
法来设计测试用例。完成组装测试之后，要对开发工作初期制定的确认准则进行检验。确认测试是使所开发的软件能否满足所有功能
和性能需求的最后保证手段，通常采用黑盒测试方法。完成确认测试之后，给出的应该是合格的软件产品，但为检验它能否与系统的
其它部分（如硬件、网络环境、数据库及操作人员）协调工作，需要进行系统测试。
单元测试（Unit
Testing）也称模块测试，这是针对软件测试的最小单位——模块进行正确性检验的测试工作。其目的在于发现各
模块内部可能出现的各种差错。单元测试需要从程序的内部结构出发设计测试用例，即采用所谓白盒测试方法。多个模块可以平行地
独立进行单元测试：
单元测试需要解决的问题
单元测试是要针对每个模块的程序，解决以下五个方面的问题
模块接口——对被测试的模块，信息能否正常无误地流入和流出。
局部数据结构——在模块工作过程中，其内部的数据是否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。
边界条件——在为限制数据加工而设置的边界处，模块是否能正常工作。
覆盖条件——模块的运行是否能达到特定的逻辑覆盖。
出错处理——模块工作中发生了错误，其中的出错处理实施是否有效。
4
宏源证券项目系统测试计划
模快与其周围环境的接口有无差错应首先得到检验，否则内部的各种测试工作都是徒劳的。Myers
提供的模块接口验证表是很有
用的以下简要地列出：
模块接受的输入参数个数与模块的变元个数是否一致？
参数与变元的属性是否匹配？
参数与变元所使用的单位是否一致？
传送给另一个被调用模块的变元个数与参数的个数是否相同？
传送给另一个被调用模块的变元属性与参数的属性是否匹配？
传送给另一个被调用模块的变元，其单位是否与参数的单位一致？
调用内部函数时，变元的个数、属性和次序是否正确？
在模块有多个入口的情况下，是否有引用与当前入口无关的参数？
是否会修改只是作为输入值的变元？
出现全程变量时，这些变量是否在所有引用它们的模块中都有相同的定义？
有没有把常数当作变量来传送？
当模块执行了外部的输入、输出时，Myers
提出还需要考虑：
5
宏源证券项目系统测试计划
文件的属性是否正确？
OPEN
语句是否正确？
格式说明与输入、输出语句给出的信息是否一致？
缓冲区的大小是否与记录的大小匹配？
是否所有的文件在使用前均已打开了？
对文件的结束条件的判断和处理是否正确？
对输入、输出错误的处理是否正确？
有没有输出信息的正文错误？
对于局部数据结构应该在单元测试中注意发现以下几类错误：
不正确的或者不相容的说明。
不正确的初始化或者缺省值。
错误的变量名，如拼写错或者缩写错。
不相容的数据类型。
6
宏源证券项目系统测试计划
下溢、上溢或是地址错误。
除局部的数据结构之外，在单元测试中还应该弄清楚全程数据对模块的影响。
如何设计测试用例，使得模块测试能够高效率地发现其中的错误，这是非常关键的问题。无论考虑何种逻辑覆盖都应该注意发现
以下一些典型的计算错误：
对运算优先性的错误理解，或者是错误的处理。
运算方式（mode）未加区分，发生了混合运算的情况。
初始化错误
计算精确度不够。
表达式中符号表示的错误。比较和控制流常常是彼此密切相关的，比较的错误势必导致控制流的错误。
需要特别注意发现的错误包括：
不同的数据类型进行比较
逻辑运算或其优先级用错
本应该相等的数据，由于精确度原因不相等。
变量本省或时比较有错。
7
宏源证券项目系统测试计划
循环终止不正确，或循环不已
在遇到发散的循环时不能摆脱出来。
循环控制变量修改有错。
程序运行中出现了异常现象并不奇怪，良好的设计应预先估计到，将来投入运行后可能发生什么出错的情况，并给出相应的处理
措施，使得用户不至于发生了这样的情况束手无策。检验程序中处理这一问题解决得怎样，可能出现的情况有：
对运行发生的错误描述得难于理解。
指明的错误并非实际遇到的错误。
出错后，尚未进行出错处理便引入系统干预
意外处理不当
提供的错误信息不足，以致无法找到出错的原因。
边界测试通常是单元测试的最后一步，是不容忽视的。实践表明，软件常常在边界地区发生问题。例如，处理
N
维数组的第
N
个元素时很容易出错，循环到最后一次执行循环体时可能出错。这可以利用边值分析方法来设计测试用例，以便发生这类程序错误。
单元测试的步骤
单元测试常常被当作代码编写的附属步骤，也有人把代码编写和单元测试作为一个开发阶段考虑。显然在程序编写完毕了、经过
8
宏源证券项目系统测试计划
复查、确认没有语法错误以后，针对每个程序模块单独进行的测试工作。
由于每个模块在整个软件中并不是孤立的，我们在每个模块进行单元测试时，也不能完全忽视它们和周围模块的相互联系。为模
拟这一联系，在进行单元测试时，需要设置若干辅助测试模块。辅助模块有两种，一种是驱动模块（Driver）,用以模拟被测模块的上
级模块；另一种桩模块（Stub）
，用以模拟被测模块中所调用的模块。
自然驱动模块和桩模块对测试人员来说是一种额外的负担，就是说，虽在单元测试中必须编写这些辅助模块的程序，但却并不作
为最终的软件产品提供给用户。好在这些模块的结构十分简单，模块间接口的全面检验可在组装测试中进行。
组装测试
在每个模块完成单元测试之后，需要按照设计时作出的结构图，把它们联系起来，进行组装测试(Integrated
Testing)。经验不多的
人可能会提出，既然单元测试时已经对所有模块的工作是否正常进行了检验，为什么还要联起来再次进行测试呢？实践表明，一些模
块能够单独地正常工作，并不能保证联结起来也能正常工作，程序在某些局部反应不出来的问题，在全局上很可能暴露出来，影响功
能的发挥。
怎样合理地组织组装测试，这里提供两种不同的方法，即非增式测试和赠式测试。
非增式测试方法是这样进行的：在装配辅助模块的条件下，对所有模块进行个别的单元测试。然后在此基础之上，按程序结构图
将各模块联合起来，把联合后的程序当作一个整体进行测试。
增式测试的做法与非增式测试有所不同。它的集成是逐步实现的，组装测试也是逐步完成的。也可以说它把单元测试和组装测试
9
宏源证券项目系统测试计划
结合起来，一道进行，增式组装测试可按不同的次序实施。因而可以有两种：
自顶向下增式测试是按结构图上自上而下进行的。
自底向上增式测试表示逐步集成和逐步测试的工作是按结构图上自下而上进行的。非增式测试的做法是先分散测试，再集中起来
一次完成组装测试。
2
2、、
测试任务测试任务
测试工作分为单元测试、集成测试和系统测试三个步骤，各阶段测试处理内容如下：
名名
称称处处
理理
内内
容容
单元测试函数级正确性测试
集成测试将各小组的所有模块按照设计要求组装成一个可以独立使用的系统，并对其进
行功能测试
系统测试将所有程序合并成一个完整的系统，并在尽可能接近实际运行环境的测试条件
下，对系统进行功能及性能测试。
《系统测试计划》是针对系统测试阶段的测试方案。
二、二、
测试目标测试目标
本次测试计划书是在个贷移行改造项目组各开发小组经历了源代码编写、测试、嵌入
JSP
工作，基本完成系统编码工作之后，制
10
宏源证券项目系统测试计划
定的对整个系统的两周测试计划。为个贷系统在
12
月
14
日成功上线对整个系统做最后的测试修改。
系统测试分两个阶段：
开发环境中的系统测试。
用户环境中的测试。
开发测试环境尽量模拟系统生产时的真实环境，对系统进行单元测试，组合测试和系统测试。受开发环境的限制，系统硬件环境
和网络环境是同最终系统的运行环境是不一致的。主要完成系统的单元边界测试，功能测试，可用性测试。
并在测试阶段对代码进行
用户测试环境尽量模拟系统生产时的真实环境，对系统进行系统测试。由于整个系统是构建在邮政综合网的广域网基础之上，用
户方提供的测试环境在网络结构上同系统生产环境是不一致的。系统的压力测试，UAT
测试，整体性能测试要在系统最终上线之后
才能实现。
三、三、
测试环境测试环境
1.开发环境中应用软件系统测试环境如下：
?硬件环境：
IBM
44P(16.54.13.96)服务器，充当应用服务器，
11
宏源证券项目系统测试计划
IBM
P670(16.54.13.93)数据库服务器。
?网络环境：100M
局域网的网络环境；
?操作系统环境：
AIX4.03
版；
?测试客户端系统软件：WIN2000，WINDOWS98，InternetExploer5.0,InternetExploer5.5，InternetExploer6.0
?数据库环境：ORACLE
8.1.6
for
Aix；
?应用程序环境：WebSphere
3.5；
?应用数据：测试人员建立的测试数据；
?测试客户端系统软件：WIN2000，WINDOWS98，WINDOWSME，InternetExploer5.0,InternetExploer5.5
2.测试环境中应用软件系统测试环境如下：
44P(16.54.13.96)服务器，充当应用服务器，
670(16.54.13.93)数据库服务器。
?网络环境：100M
局域网的网络环境；
?操作系统环境：
AIX4.03
版；
12
宏源证券项目系统测试计划
?测试客户端系统软件：WIN2000，WINDOWS98，InternetExploer5.0,InternetExploer5.5，InternetExploer6.0
?数据库环境：ORACLE
8.1.6
for
Aix；
?应用程序环境：WebSphere
3.5；
?应用数据：测试人员建立的测试数据；
?测试客户端系统软件：WIN2000，WINDOWS98，WINDOWSME，InternetExploer5.0,InternetExploer5.5
四、四、
测试人员组织测试人员组织
1.测试负责人：杜磊
1)编制系统测试计划，系统测试大纲，制定系统测试通过标准，整理模块测试记录，整理系统测试记录
2)编制系统测试案例
3)参与各系统单元测试、组合测试和系统测试。审核组合测试和系统测试结果。
2.各系统测试组长：杜磊
1)编制本系统中模块单元测试通过标准，协助测试负责人完成系统测试大纲。
13
宏源证券项目系统测试计划
2)编制本系统测试案例
3)参与本系统单元测试、组合测试和系统测试。审核本系统组合测试和系统测试结果。
4)完成本人参与编程部分的软件测试记录文档，审核本系统开发人员单元测试结果。
3.测试组成员：杜磊，徐加星，倪勇飚
1)编制单元测试案例
2)参与本人负责开发的单元测试、以及包括该单元的组合测试和系统测试。
3)完成本人参与编程部分的软件测试记录文档，模块测试记录文档。
1、编码人员测试工作
（1）
准备测试案例
（2）
按测试案例测试程序代码
（3）
形成测试纪录表和问题纪录表
2、非编码人员的工作
（1）
检查测试案例是否充足，是否满足测试需要？
（2）
协助编码人员完成测试案例的准备。
（3）
同编码人员一起完成测试。
14
宏源证券项目系统测试计划
（4）
分工：
3、提醒的问题。
由于工期较紧，若功能单元中未实现的或者欠缺的部分，需要编制针对这些问题的测试案例写入测试案例表中，将问题纪录
到测试问题记录表中。
五、五、
测试日程和测试内容测试日程和测试内容
1.测试进度测试进度：
系统测试计划如下：
开始日期开始日期结束日期结束日期测试内容测试内容
2002/11/212002/11/23开发环境单元测试
2002/11/262002/11/27开发环境组合测试
2002/11/282002/11/29开发环境系统测试
15
宏源证券项目系统测试计划
2.测试内容列表：测试内容列表：
1)单元测试：
业务业务
编号编号
测试内容测试内容测试日期测试日期测试人员测试人员测试起点测试起点测试终点测试终点期望的测试结果期望的测试结果
1客户贷款申请11．21倪勇飚输入客户基本
信息
建立客户贷款申
请书
正常显示
2客户贷款审批11．22倪勇飚申贷员检查客
户贷款申请书
最终审批员审批正常显示
2)组合及系统测试：
业务编业务编
号号
测试内容测试内容测试日期测试日期测试人员测试人员测试起点测试起点测试终点测试终点
2002/11/202002/11/30用户方测试环境组合测试及系统测试，同时进
行测试中出现问题的修改。
16
宏源证券项目系统测试计划
业务编业务编
号号
测试内容测试内容测试日期测试日期测试人员测试人员测试起点测试起点测试终点测试终点
1客户贷款申请11．28杜磊输入客户基本信息
建立客户贷款申请书
2客户贷款审批11．28杜磊申贷员检查客户贷
款申请书
最终审批员审批
17
宏源证券项目系统测试计划
注：详细内容见
系统测试报告
六、六、
开始测试标准开始测试标准
?一般性以上（含一般性）模块已全部完成；
?内部单元（模块）调试已完成
90%；
?系统连接已完成。
七、七、
结束测试标准（项目提交标准）结束测试标准（项目提交标准）
?计划测试案例必须全部完成；
?无已发现的
1，2，3
类错误；
?已发现的
4，5
类错误在各相关部门的允许范围内；
?在规定的时间范围，经过规定的测试后，不出现
1，2，3
类错误；
18
宏源证券项目系统测试计划
错误分类原则说明错误分类原则说明
1．灾难性错误：导致操作系统、数据库系统崩溃；
2．应用系统错误：导致应用系统无法运行；coredump，通讯异常；
3．核心功能错误：导致某种核心功能无法进行；帐务处理，密码校验；
4．一般功能错误：一般性功能出现不频繁的错误；
5．其他性错误：造成用户不便且不影响功能的错误。
八、八、
各个测试项的详细说明各个测试项的详细说明
参见系统测试报告
九、九、
局限性局限性
系统测试仅仅是在尽可能真实的环境下进行的测试，而且测试的内容只局限于功能性的测试，对系统的性能并未做任何测试。
篇3：2020年软件测试个人工作总结
20XX年软件测试个人工作总结 本文关键词：个人工作总结，测试，软件，XX
20XX年软件测试个人工作总结 本文简介：20XX年软件测试个人工作总结[1]我最初参加测试工作的时候，不知道什么是软件测试，集成测试和系统测试的概念经常混淆，cmm是什么就更加不知道了。那时候最简单的开关机也是通过直接拔插电源完成，安装系统对我来说简直是有史以来人类的最高技能，对于那些拿着螺丝刀安装机器的人就认为是宇内超级高手，身具杀人于
20XX年软件测试个人工作总结 本文内容：
20XX年软件测试个人工作总结[1]
我最初参加测试工作的时候，不知道什么是软件测试，集成测试和系统测试的概念经常混淆，
cmm
是什么就更加不知道了。那时候最简单的开关机也是通过直接拔插电源完成，安装系统对我来说简直是有史以来人类的最高技能，对于那些拿着螺丝刀安装机器的人就认为是宇内超级高手，身具杀人于无形之绝世秘技。拿破仑说不想当将军的士兵不是好士兵，我最初的梦想就是想成为软件测试的高手，傲视天下。所以不断偷师，总结经验，自认为掌握了成为高手的几个秘技，这几年混迹
“江湖
“还算无往而不利。不敢独享，望与吾辈测试人员切磋，早日总结成功密技之大成，助新进人员早日入门，也算不愧对东北活雷锋的称号。
第一招
学会利用网络
刚参加工作面对浩瀚的网络世界，当时如刘姥姥进大观园，什么都新奇，什么都想要，从网上下载很多源程序的代码，软件技术文档之类，恨不得把所有的好东西收集到手中，其实有些在他人看起来就是垃圾一堆。当时觉得有了这些
“武林秘籍
“，成为高手指日可待。最初参加工作由于自己工作努力有幸转为开发，加入项目组后我的习惯还是没有改，反而变本加厉，手中的资源更加多，上网的时间更加频繁。
一次项目经理分配任务，觉得依靠手中的秘籍加上自己的
“聪明才智
“很快会完成，不料短短的时间，所有的一切变成了马奇诺防线。解决问题很慢，思路不清晰，项目经理在对我施压的过程中教会了我终身难忘的一招，学会利用网络寻找要解决问题的答案，从此
成了我的最爱，关键字成了我变化的招数。在软件测试工作中，他帮我解决了很多疑难问题，解答了很多令我迷惑的地方。也是我帮助测试同行解决问题手段之一，很多软件测试新手，甚至老手都没有意识到自己手上就握有
“无敌秘籍
“，所以只要你耐心找，答案就在身边。
这里总结一下利用网络搜索引擎的技巧：
组合搜索
每次搜索某个文件，如果只给出一个单词进行搜索，经常会出现成千上百万计的匹配网页。然而如果再加上一个单词，那么搜索结果会更加切题。
选择表述内容的词组
一般我在网页搜索引擎的时候，选择一些可以表达我要查找内容的关键词组，用来缩小搜索范围，从而找到搜索结果是最好的办法。运用词组搜索涉可以先先简单地输入一个问题作为词组搜索，如果仍然找不到合适的，那就用多个可以表达要查询内容的关键字进行查询。
定位信息来源
有的时候用词组搜索不到或者无法准确表达所需信息。可以用另一种方法直接到信息源，就是直接到到提供某种信息的站点去。可以用公式
“.
公司名
.”
去猜测某一组织的特点。从而得到所要搜索的信息的主要词组
其实网络上还有很多关于搜索技巧的文章，大家可以自行学习。千万要记住搜索引擎是帮助你成功的有力武器。
第二招
学会动手
参加软件测试工作后，随着工作经验的增长自我感觉越来越好。在公司里也逐渐受到同事领导的重视，一次针对公司的新的软件功能进行测试的时候，像往常一样
“随手
“测试出了几个
bug
，然后
“仔细
“的填写了
bug
单（这个
bug
的现象已经出现了很多次了）。这时候测试经理走过来，重新复查了一下填写的
bug
。他在重现我的
bug
的过程中，简化了我的输入变化，
bug
神奇的又出现了，同样的现象，他关闭软件重新变化输入，扩展出
10
几个变化后，软件不动了，内存不断上升。终于他找到了产生软件的
bug
的原因，然后对我说
“寻找
bug
要准确定位，我们开发团队是一个整体，时间是等量的，时间不在你身上浪费，就是在他身上浪费。如果测试人员每次发现的
bug
描述不清楚，并且多个问题潜在的错误原因是一个，虽然操作可能稍微有些变化。这样开发人员在重现
bug
的时候他要调试跟踪判断，很花费时间，而且效率低。如果测试人员发现
bug
的时候多动手可以更加准确的定位
bug
步骤和原因，给开发人员最精确的步骤和准确的描述，这样整个团队才能高效，所以需要大家协作！。
“。
在以后的日子里，每次解决问题的时候我都记得多试验几次，多尝试。网上很多朋友还有同事问我问题的时候，其实他们只是万里长征就差一步，只要再多动手实验一次就可以达到目的了。所以多动手，多尝试。
第三招
思考自己所作的
刚开始入行的时候，总是思考如何做好软件测试。认为公司的测试流程混乱总是很郁闷，认为自己学不到东西，如何才能测试好产品，常说心动不如行动，以前看到古龙小说中经常出现的场景无名
名小子不断挑战高手，总结积累。我总结了有些经验是实战中得到的，所以不断尝试引入新的测试流程然后评估，这个过程虽然很痛苦，但是从中积累了不少经验。这段时间让我学习到了很多东西，接触了
iso,cmm
，测试管理工具，自动化工具（因为公司不正规给了我很多学习的机会，后来到了比较大的软件公司后，以前的经历给了我更多的发展机会，因为大公司非常正规了，公司内部人员分工明确，所以能力的锻炼反倒少了）。由于工作中经常写报告反倒养成了总结教训的习惯，因为纸面上的东西是永远也忘不掉的。在写的过程中可以不断补充扩展，整个过程是思想升华的过程，当年达摩面壁九年就是融会贯通的典型例子，如果他不是有个思考的过程，他也不能成为一代大家。如果后来不时有人把他的绝技记录下来，也就不能有后来的少林寺七十二绝技。
所以善于思考，总结经验，也是成为高手之路的不二法决。
第四招
学会利用论坛资源
其实测试新兵和测试高手之间的区别，往往是不会利用现有资源。在论坛中我们会看到很多新手不断的提问，但是有很多问题其实都是已经别人提过了，或者已经有解决方案的。所以经常会看到
“测试高手“的身影，并且不提问题，而且还能“锄强扶弱“，是测试新丁的救命稻草。好像是高手们无所不能，其实摘掉这层耀眼的光环，他们并没想像得那么厉害，只不过通过自己的搜索找到的答案，然后帮助其他人。当然也有很多人都是通过自学，然后在论坛中交流得到了很多经验，高手其实也是因为善于思考问题，亲自动手解决问题。所以动手和利用论坛资源的过程中他们也在不断提高。
很多时候看到论坛中有人提问，问题描述不清，很多人看了很困惑。发贴题目动不动请高手帮忙，救命之类的，好像天下大乱，世界末日。虽然这个题目很招人，但是无法让那些想帮助你的人帮你，因为题目不清晰，而且高手字样吓阻了很多人。其实问问题也是个思路整理的过程，描述清晰，让人理解清楚，才能望文知意知道你的当前发生问题的环境，才能让那些想帮你的人解决问题，否则给人无从下手的感觉，解决问题效率不高。
第五招
学习和你所测试的软件产品相关的知识
要想成为好的测试人员，还要了解你要测试的软件的相关知识。要了解软件产品的架构是什么样的。要了解软件的市场需求，在接触软件之初要可以多看看用户的反馈信息，这些才是用户最关心的，也是你在测试中需要注意的问题，满足客户是最大的需要。但是了解软件需求之后要学会要多读些软件系统的技术文档，软件设计文档，这些文档可以帮助你了解产品如何工作。还有多看看公司
bug
库中的问题，这些存在的问题可以帮助你了解软件产品那些地方存在缺陷，软件系统那些地方会出现错误。软件是运行在一个大环境中，如果对系统不熟悉，那么有些问题你不能从一个更广阔的层面考虑，学习操作系统的知识，有助于你发现缺陷，定位问题更加准确。比如软件运行在
windows
或者
linux
，如果你不懂操作系统，你就无法建立测试环境，有些时候时候软件的组件发生问题，就是你系统配置造成的，对系统不熟悉，你会把外在原因归结为软件本身。所以要学习关于和软件系统相关的知识，比如编程，网络，数据库等。不一定你要学习到多好的程度，只是通过这些扩展的知识面，你可以在发现问题，解决问题上不会局限在狭小的圈子里。
和一切相关的人员交流，不同的交流渠道，获取消息是不同的，角度也不同。和客户交流，你会在测试中从客户的角度发现问题；和开发人员交流，你会了解开发人员怎么实现软件功能的；和项目管理人员交流，你会知道开发进度以及遇到的困难。