软件测试经验总结

第一篇：软件测试经验总结

软件生命周期(SDLC)的六个阶段

1、问题的定义及规划

此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。

2、需求分析

在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。“唯一不变的是变化本身。”，同样需求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。

3、软件设计

此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。

4、程序编码

此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。

5、软件测试

在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。

6、运行维护

软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。

2、软件生命周期模型

从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为“生命周期模型”（Life Cycle Model）。

典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。

瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来。迭代模型比瀑布模型问题暴露的要早；快速原型法比瀑布模型直观。

3.软件测试概念

广义概念：指软件生存周期中所有的检查、评审和确认工作，其中包括了对分析、设计阶段，以及完成开发后维护阶段的各类文档、代码的审查和确认

狭义概念：识别软件缺陷的过程，即实际结果与预期结果的不一致

4.软件测试目的测试的目的就是发现软件中的各种缺陷

测试只能证明软件存在缺陷，不能证明软件不存在缺陷

测试可以使软件中缺陷降低到一定程度，而不是彻底消灭

以较少的用例、时间和人力找出软件中的各种错误和缺陷，以确保软件的质量

5．软件测试原则

Good-enough: 一种权衡投入/产出比的原则

保证测试的覆盖程度，但穷举测试是不可能的所有的测试都应追溯到用户需求

越早测试越好，测试过程与开发过程应是相结合的测试的规模由小而大，从单元测试到系统测试

为了尽可能地发现错误，应该由独立的第三方来测试

不能为了便于测试擅自修改程序

既应该测试软件该做什么也应该测试软件不该做什么

6．软件测试的的重点

测试用例的设计

测试用例的设计是整个软件测试工作的核心

测试用例反映对被测对象的质量要求，决定对测试对象的质量评估

测试工作的管理

尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提

测试环境的建立

测试环境应该与实际测试环境一致

7．黑盒测试

什么是黑盒测试

又称功能测试或数据驱动测试，是针对软件的功能需求/实现进行测试，通过测试来检测每个功能是否符合需求，不考虑程序内部的逻辑结构

黑盒测试方法

功能划分

等价类划分

边界值分析

因果图

错误推测等

8．什么是白盒测试

白盒测试也称结构测试或逻辑驱动测试，必须知道软件内部工作过程，通过测试来检测软件内部是否按照需求、设计正常运行

白盒测试的主要方法

对应于程序的一些主要结构：语句、分支、逻辑路径、变量；白盒测试的主要方法是： 语句覆盖方法

分支覆盖方法

逻辑覆盖方法

什么是动态测试

动态测试需要在开发/测试环境或实际运行环境中运行软件，并使用测试用例去查找软件缺陷；动态测试包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等

10.什么是静态测试

静态测试不实际运行软件，主要是对软件的编程格式、结构等方面进行评估.静态测试包括代码检查、程序结构分析、代码质量度量等。它可以由人工进行，也可以借助软件工具自动进行

11.手工测试和自动测试

a.手工测试缺点在于测试工作量大，重复多，回归测试难以实现

b.自动测试利用软件测试工具自动实现全部或部分测试工作：管理、设计、执行和报告；节省大量的测试开销，并能够完成一些手工测试无法实现的测试

手工完成测试的全部过程无法保证测试的科学性与严密性:

修改的缺陷越多，回归测试越困难

没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率

反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一

测试花费的时间越长，测试的严格性也就越低

自动测试将测试人员从反复、烦杂的测试执行中解放出来，用更多的时间进行测试设计和结果分析

软件测试不可能完全自动化

不能完成所有手工测试任务

无创造性且灵活性差，不能改进测试的有效性

过程中可能会遇到许多意想不到的问题，特别是当软件不稳定时

测试脚本的维护高

12.测试流程

单元测试

集成测试

系统测试

用户验收测试

回归测试

确认测试报告

13.单元测试

完成对最小的软件设计单元—模块的验证工作

目标是确保模块被正确地编码

使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误

通常情况下是面向白盒的对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早地发现和解决不易显现的错误

单元测试的内容

接口测试

内部数据结构

全局数据结构

边界

语句覆盖，错误路径

14.集成测试

通过测试发现与模块接口有关的问题

目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构

应当避免一次性的集成（除非软件规模很小），而采用增量集成集成测试主要内容

API(Application Programming Interface,应用程序编程接口)

API/参数组合15．系统测试

根据软件需求规范的要求进行系统测试，确认系统满足需求的要求

系统测试人员相当于用户代言人

在需求分析阶段要确定软件的可测性，保证有效完成系统测试工作

系统测试主要内容

所有功能需求得到满足

所有性能需求得到满足

其他需求（例如安全性、容错性、兼容性等）得到满足

16.用户验收/确认测试

Alpha测试

是由用户在开发者的场所来进行的，Alpha测试是在一个受控的环境中进行的Beta测试

由软件的最终用户在一个或多个用户场所来进行的，开发者通常不在现场，用户记录测试中遇到的问题并报告给开发者

17．压力测试VS性能测试

性能测试的目的不是去找bugs,而是排除系统的瓶颈，以及为以后的回归测试建立一个基准。而性能测试的操作，实际上就是一个非常小心受控的测量分析过程。在理想的情况下，被测软件在这个时候已经是足够稳定了

性能测试是为了检查系统的反映，运行速度等性能指标，他的前提是要求在一定负载下，如检查一个网站在100人同时在线的情况下的性能指标，每个用户是否都还可以正常的完成操作等。

概括就是：在不同负载下（负载一定）时，通过一些系统参数（如反应时间等）检查系统的运行情况；

压力测试是为了发现系统能支持的最大负载，他的前提是要求系统性能处在可以接受的范围内，比如经常规定的叶面3秒钟内响应；概括就是：在性能可以接受的前提下，测试系统可以支持的最大负载。

举例说明：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。

18.主流测试工具的测试流程

========winrunner启动时选择要加载的插件进行一些设置（如录制模式等）识别应用程序的GUI，即创建map(就是学习被测试软件的界面）建立测试脚本（录制及编写）对脚本除错及调试（保证能够运行完）插入各种检查点（图片，文字，控件等）在新版应用程序中执行测试脚本分析结果，回报缺陷

=========quicktestpro========准备录制

打开你要对其进行测试的应用程序，并检查QuickTest中的各项设置是否适合当前的要求。2 进行录制

打开QuickTest的录制功能，按测试用例中的描述，操作被测试应用程序。编辑测试脚本

通过加入检测点、参数化测试，以及添加分支、循环等控制语句，来增强测试脚本的功能，使将来的回归测试真正能够自动化。调试脚本

调试脚本，检查脚本是否存在错误。在回归测试中运行测试

在对应用程序的回归测试中，通过QuickTest回放对应用程序的操作，检验软件正确性，实现测试的自动化进行。分析结果，报告问题

查看QuickTest记录的运行结果，记录问题，报告测试结果。

＝＝＝＝TestDirect============

安装好后，先进入站点管理创建域及工程添加用户编辑licenses及本服务器编辑数据库

－－TD选择新建的工程进行定制(列表，用户，组，版本等)在require中增加需求把需求转化为plan在testlab中由计划新建测试具体用例与执行发现bug，在defect中提交bug

（每一部分都可以相对独立地使用）

======loadrunner制定负载测试计划

(分析应用程序，确定测试目标，计划怎样执行LoadRunner）开发测试脚本

（录制基本的用户脚本，完善测试脚本）创建运行场景

（选择场景类型为Manual Scenario，选择场景类型，理解各种类型，场景的类型转化）监视场景（MEMORY 相关，PROCESSOR相关，网络吞量以及带宽，磁盘相关，WEB应用程

序，IIS5.0，SQL SERVER，NETWORK DELAY等)

分析测试结果

7(分析实时监视图表,分析事务的响应时间,分解页面,确定WEBSERVER的问题,其他有

用的功能)

第二篇：软件测试中有关界面测试经验总结

软件测试中有关界面测试经验总结

1.应验证界面显示内容的完整性：

a)报表显示时应考虑数据显示宽度的自适应或自动换行。

b)所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等)，必须使测试数据的记录数超过一屏/一页，以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印，界面显示是否正常；

2.应验证界面显示内容的一致性：

a)如有多个系统展现同一数据源时，应保证其一致性；

3.应验证界面显示内容的准确性：

a)对于报表中的所有字段值都应该有明确的定义，对于无意义的字段值，不应该显示空，应显示“--”或“/”，表示该字段值无意义。

4.应验证界面显示内容的友好性：

a)对统计的数据应按用户习惯进行分类、排序。

b)某些重要信息在输入、修改、删除时应有“确认”提示信息；

c)界面内容更新后系统应提供刷新功能。

d)用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面；

5.应验证界面提示信息的指导性：

a)在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户。

b)用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕。

c)在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述；当输入数据不符合规则时应提示用户是否继续。

d)在对任何配置信息修改后，都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下)；

6.应验证界面显示内容的合理性：

a)在对某些查询功能进行测试时，应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。

b)界面测试时，应考虑某一界面上按钮先后使用的顺序问题，以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。

c)界面测试时，应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确。

7.界面测试时，应考虑用户使用的方便性：

a)在某些对数据进行处理的操作界面，应考虑用户可能对数据进行处理的频繁程度和工作量，考虑是否可以进行批量操作。

8.界面测试时，应考虑界面显示及处理的正确性：

a)界面测试时应验证所有窗体中的对象状态是否正常，是否符合相关的业务规则需要。b)应验证各种对象访问方法(Tab 健、鼠标移动和快捷键)是否可正常使用，并且在一个激活界面中快捷键无重复；

c)界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过鼠标拷贝粘贴输入。d)对于统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发，应避免其他形式的触发。

e)对界面上的任何对象进行拖拉，然后进行查询、打印，应保证查询打印结果不变；

9.界面测试时，应考虑数据显示的规范性：

a)确保数据精度显示的统一：如单价0元，应显示为0.00元；

b)确保时间及日期显示格式的统一；

c)确保相同含义属性/字段名的统一；

d)对所有可能产生的提示信息界面内容和位置进行验证，确保所有的提示信息界面应居中。

1.1.1文本框的测试

如何对文本框进行测试：

a,输入正常的字母或数字；

b,输入已存在的文件的名称；

c,输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入256个字符，检查程序能否正确处理；

d,输入默认值，空白，空格；

e,若只允许输入字母，尝试输入数字；反之；尝试输入字母；

f,利用复制，粘贴等操作强制输入程序不允许的输入数据；

g,输入特殊字符集，例如，NUL及n等；

h,输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；

i,输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示；

在测试过程中所用到的测试方法：

1,输入非法数据；

2,输入默认值；

3,输入特殊字符集；

4,输入使缓冲区溢出的数据；

5,输入相同的文件名；

命令按钮控件的测试

测试方法：

a,点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口； b,对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示:天数不能大于31；

c,对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；

单选按钮控件的测试

测试方法：

a,一组单选按钮不能同时选中，只能选中一个。

b,逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；

c,一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；

up－down控件文本框的测试

测试方法：

a,直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；

b,利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；

c,直接输入超边界值，系统应该提示重新输入；

d,输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；

e,输入字符。此时系统应提示输入有误。

组合列表框的测试

测试方法：

a,条目内容正确，其详细条目内容可以根据需求说明确定；

b,逐一执行列表框中每个条目的功能；

c,检查能否向组合列表框输入数据；

复选框的测试

测试方法：

a,多个复选框可以被同时选中；

b,多个复选框可以被部分选中；

c,多个复选框可以都不被选中；

d,逐一执行每个复选框的功能；

列表框控件的测试

测试方法：

a,条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；

b,列表框的内容较多时要使用滚动条；

c,列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；

滚动条控件的测试

要注意以下几点：

a,滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间； b,拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；

c,单击滚动条；

d,用滚轮控制滚动条；

e,滚动条的上下按钮；

各种控件在窗体中混合使用时的测试

a,控件间的相互作用；

b,tab键的顺序，一般是从上到下，从左到右；

c,热键的使用，逐一测试；

d,enter键和esc键的使用；

在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。

ps:密码输入框测试时要特别注意进行字母大写输入的测试。

查找替换操作

案例演示:打开word中的“替换”对话框

测试本功能有通过测试和失败测试两种情况

通过测试:

1,输入内容直接查找,或查找全部

2,在组合框中寻找已经查找过的内容,再次查找并确认文档的内容正确,如,已经查找过“测试用例”,再次进入不用重新输入查找内容,直接在文档中搜寻就可以.失败测试:

1,输入过长或过短的查询字符串.如,假设查询的字符串长度为1到255,那么输入0,1,2,256,255和254进行测试；

2,输入特殊字符集,如,在word中.^g代表图片,^代表分栏符,可以输入这类特殊字符测试；

替换测试大体相同.关于编辑操作窗口的功能测试的用例:

1,关闭查找替换窗口.不执行任何操作,直接退出；

2,附件和选项测试.假如,设定“精确搜寻”,“向后”搜索等附件选项等等来测试；

3,控件间的相互作用.如,搜寻内容为空时,按钮“搜寻全部”,“搜寻”,“全部替换”,“替换”都为灰色.4,热键, Tab键.回车键的使用.插入操作

1,插入文件

测试的情况

a,插入文件；

b,插入图像；

c,在文档中插入文档本身；

d,移除插入的源文件；

e,更换插入的源文件的内容；

2,链接文件

测试方法:

a,插入链接文件；

b,在文档中链接文档本身；

c,移除插入的源文件；

d,更换插入的源文件的内容.3,插入对象

要测试的内容

a,插入程序允许的对象,如,在word中插入excel工作表；

b,修改所插入对象的内容.插入的对象仍能正确显示；

c,卸载生成插入对象的程序,如,在word中插入excel工作表后卸载excel,工作表仍正常使用.编辑操作

编辑操作包括剪切,复制,粘贴操作.测试剪切操作的方法

a,对文本,文本框,图文框进行剪切；

b,剪切图像

c,文本图像混合剪切

复制操作方法与剪切类似.测试时,主要是对粘贴操作的测试,方法是:

a,粘贴剪切的文本,文本框及图文框；

b,粘贴所剪切的图像；

c,剪切后,在不同的程序中粘贴

d,多次粘贴同一内容,如,剪切后,在程序中连续粘贴3次；

e,利用粘贴操作强制输入程序所不允许输入的数据.界面测试用例的设计方法

1,窗体

测试窗体的方法:

a,窗体大小,大小要合适,控件布局合理；

b,移动窗体.快速或慢速移动窗体,背景及窗体本身刷新必须正确；

c,缩放窗体,窗体上的控件应随窗体的大小变化而变化；

d,显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常；

进行测试时还要注意状态栏是否显示正确；工具栏的图标执行操作是否有效,是否与菜单栏中图标显示一致；错误信息内容是否正确,无错别字,且明确等等；

2,控件

测试方法:

a,窗体或控件的字体和大小要一致；

b,注意全角,半角混合c,无中英文混合.菜单

进行测试时要注意

a,选择菜单是否可以正常工作,并与实际执行内容一致；

b,是否有错别字:

c,快捷键是否重复；

d,热键是否重复；

e,快捷键与热键操作是否有效

f,是否存在中英文混合g,菜单要与语境相关,如,不同权限的用户登陆一个应用程序,不同级别的用户可以看到不同级别的菜单并使用不同级别的功能；

h,鼠标右键快捷菜单

第三篇：软件测试工程师面试经验总结

首先说明我算上找实习的时候的面试总共就经历了不到5次，没有多少经验，就在网上和书上摘录了些我认为比较重要的，分享给大家，希望各位都能找到一份适合自己的好工作。1.笔试题

对于笔试，有的公司笔试题是不区分开发和测试岗位的，测试人员除了要掌握好测试的基本知识外最好也是有编程基础，具有尽量多的计算机的知识，像操作系统的基本知识（线程等），数据库的基本操作（增删改查，关联查询，授予权限等），数据结构的知识（像二叉树的前序、中序、后序查询）。2.面试

如果在笔试中没有考测试的基本知识，那在面试中是肯定要被问到的。面试前一定要做好准备，可以在网上搜一下关于这个公司的笔试题和面试题，以供参考。如果时间充裕可以找一本自己能看的进去的讲软件测试的书，认真的有侧重点的看看。软件测试的几个主要的阶段，不一定死记硬背能用自己的话说出来也可以或者能举例说明，那几个主要的白盒和黑盒的测试方法能熟练的应用到实际的例子中，等价类划分和边界值分析经常被问到。

每个公司做的项目都不一样，最好先了解下要应聘的那家公司主要是做哪方面的，比如对美外包的公司就要求英语水平，能看懂英文文档甚至能同外国人交流，最好能提前先看些英语的文章，准备下英文的自我介绍，临时提高下英语水平。

我被问到的面试题（答案仅供参考）

1.为什么不考研？

2.想要一份什么样的工作

3.做软件测试人员需要具备什么样的职业素质

（1）专业技能，包括测试的技能和开发的技能（2）积极的态度

（3）良好的沟通能力（4）细心（5）耐心

（6）团队意识 4.对他们公司的了解

5.再就是些工作地点能否接受，有没有男朋友之类的基本问题 以下是针对实习项目问的问题（答案仅供参考）

6.缺陷报告有几个状态，都包括哪些内容

状态：新建，打开，修复，关闭，重复的bug，无效的bug，被拒绝的bug，其他 内容：：标题、模块名称、项目名称、测试环境、重现步骤、期望结果、实际结果、严重级、优先级、发现人、接收人和附件（截图，说明等）。7.有一个文本框，只能输入0-5个字母的组合，如何进行测试 从字符串的长度考虑，按照边界值方法设计测试用例

从字符串的组成内容考虑，按照等价类划分方法设计测试用例 8.简单的说一下性能测试和压力测试 9.写过自动化测试的脚本吗

10.我实习的项目是一个金融的网站，技术的面试官问我，商品的价格是左对齐还是右对齐（对于这个问题我也不知道为啥会被问到，有什么具体的含义，猜想可能是判断我的项目经验是否真实）

下面是我网上摘录的一些可能被问到的面试题

1.您认为做好测试用例设计工作的关键是什么？

答：白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

2.在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

3.谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面

4.什么是软件测试。

5.Alpha 测试与beta 测试的区别。

6.测试结束的标准是什么？

7.测试项目：杯子

需求测试:查看杯子使用说明书 界面测试:查看杯子外观

功能度：用水杯装水看漏不漏；水能不能被喝到 安全性：杯子有没有毒或细菌

可靠性：杯子从不同高度落下的损坏程度

可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用 兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等 易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

国际化：杯子上的图案有没有触犯到某个国家或宗教的禁忌

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述 疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透 跌落测试: 杯子加包装(有填充物),在多高的情况摔下不破损

震动测试: 杯子加包装(有填充物),六面震动,检查产品是否能应对恶劣的铁路公路航空运输

测试数据：测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法

期望输出：该期望输出需查阅国标、行标以及使用用户的需求 说明书测试: 检查说明书书写准确性

给大家提三个产品:1.手机 2.电饭锅 3.电梯

8.图书（图书号，图书名，作者编号，出版社，出版日期）

作者（作者姓名，作者编号，年龄，性别）

用SQL语句查询年龄小于平均年龄的作者姓名、图书名，出版社。

9.软件测试分为几个阶段 各阶段的测试策略和要求是什么

10.您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

11.请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程

12.您认为做好测试计划工作的关键是什么？

13.您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

14.测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？ 答：软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法（最好是能先评审）

15.为什么要在一个团队中开展软件测试工作？ 答：因为没有经过测试的软件很难在发布之前知道该软件的质量，就好比ISO质量认证一样，测试同样也需要质量的保证，这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题，及时让开发人员得知并修改问题，在即将发布时，从测试报告中得出软件的质量情况。

第四篇：测试经验总结

1.测试人员和用户的联系与区别

黑盒测试人员和用户，都是站在实际应用层进行操作，因此他们对应用层的可用性、实用性非常关注。用户不懂的是软件的使用，而相对用户来说，测试人员对软件比较了解，但不熟悉业务本身。

八个字归纳：用户是用，测试是测。

用户不懂使用就需要技术支持人员去培训，而测试人员在测试初期经过开发人员和项目负责人的简单培训后，就应该通过所学的理论知识和相关的业务知识独立去了解、深入到软件的功能点中。

应该做到：由测试人员培训技术支持人员，由技术支持人员实施时给用户培训。

2.带着问题去测试

阿猪工作守则第一条：带着问题去测试

测试中会遇到很多问题，没关系，没有脑子里面的一个个问号，是不能很好的发现问题的。往往发现一些藏的很深的bug都是在测试人员一步步解决这些问号的过程中，切忌遇到问题就问，不仅因为增加不必要的与开发人员、负责人等的交流时间可能延误项目进度，而且自己对问题的印象也不会很深刻，毕竟在相对较短的测试时间内，听不如记，记不如自己去发现规律。

3.测试期间提问题和交流的时机

什么时候应该提问题？

我们都知道，作为测试人员，并不是测试期间什么时候遇到问题就要马上问，那什么时候是提问的时间？

培训

培训时，一般在讲解内容的间歇允许打断，由培训人员解答测试人员的疑惑。培训的过程其实就是一个传输新知识并答疑的时间，这个期间的提问是欢迎的，也可以增加参与性和调动积极性。所以希望大部分的问题能在这个阶段提出来。受时间、环境等条件制约，有时培训的人讲的也不一定细致和全面，这时就需要自己多想，想想这个功能是干什么的，为什么这么做，对应的业务是什么。

阿猪工作守则第二条：培训时脑子灵活转动，多想多问

以前大家可能有过参加辩论会的经历，就算没有其实和人聊天也是一个交互的过程。参加辩论会要求快速思考，然后放慢语速说出自己的观点，因为不能说错。我们在参加培训时前者相同，后者相反。脑子嘴巴都要快，说错了也没有关系，自己的想法被纠正的过程中也是加深印象和理解的过程。

计划评审

提出对于软件不理解、安排的任务不明白的地方。

测试期间

这个时期最主要的问题应该集中在影响测试流程和进度的问题，而不是说明书或其它文档上已有的内容，或者与自己负责模块无关的内容。开发人员和其他测试人员都有自己的进度安排，因此，影响测试流程和进度的问题,马上问！

不影响流程的问题，记下来统一问！

不必要的问题（说明书或其它文档上已有的内容、讲过三遍以上的问题、今晚去哪里吃饭的问题），不问！

好处：避免不必要的时间支出，不打乱自己的测试思路，一气呵成，并且使项目成本得到控制

坏处（？）：脑子里、笔记本上留下一堆待解决的问号吧，浪费脑细胞和公司的笔和纸

张等资源

阿猪工作守则第三条：先做事，后学习

在有限的时间内先完成该做的事，有空闲的时间再去补充自己的知识。

要很好的把握上述内容，也要求提高培训期间培训人员培训内容的完善性，要求前期培训人员强调出软件的重点、难点和注意事项。这个期间适合于上面提到的“带着问题去测试”的方法。

但有一点需要注意：不要为了一个地方的卡壳在那耗上一天半天的，这就不值得了。测试中期评审测试问题

答疑解惑的时间。

测试报告评审

对一些结论有疑惑和不解的地方，提！

4.记笔记

一个老生常谈的话题。

阿猪工作守则第四条：好记性不如烂笔头

测试培训的时候对于一些重点应该记下来，即使当时听懂了；没听明白的更应该记下来，到测试软件的时候去验证自己的疑问。如果培训时特别强调的地方，测试时再去问，这就不好了。

养成一个良好的习惯，会使以后的工作更加顺利。

5.在公司和学校的学习的区别

学校是专门学习的地方，公司就是工作的地方，因此，它们的性质决定了其学习内容和方法的不同。

学校 公司 备注

内容上 主要是系统的理论知识 主要是和项目相关的业务知识 如果在测试中感到自己部分理论知识欠缺时，就应该回家多补充了

时间上 大块时间的连续学习相对邻散 在公司一般不会拿出大块时间来学习和讲解 形式上 老师授课＋自学 培训＋交流＋测试过程中自学

个人觉得，一个高效的测试流程应该如下：

a.花几个小时至多半天时间快速阅读浏览软件说明书、设计文档；

这个阶段要让脑子里面形成对软件的整体印象感，能够让自己把握全局，因此，测试负责人安排时间看文档时，决不能忽视它的重要性，否则就会出现后续阶段磕磕碰碰的情况。注重速读，把握软件说明，忽略具体的数据库设计、功能点设计、计算、规则和辅助工具（相关软件）说明文档，囫囵吞枣的方法在这里就显得很有效。

如果项目时间紧或没有文档，这个步骤所做的事可以在下面完成。

b.利用培训时间消化吸收的知识

c.软件上手

几个小时至多半天时间，熟悉软件框架和基本功能，不要求所有功能都会操作，自己负责的模块可以多侧重一些。

d.细测

主要症对计划中安排给自己做的模块，这时就要相对放慢节奏，每一步操作、每个对话框（操作界面）都要深究，别放过任何情况。这时会遇到一些错误或不理解的地方，明显的如报错就提到开发过程论坛，不明显的就先记下来，等这个功能点测完再回头去看，你会发现：

50％的问题可以自己分析出来和解决，有的问题不是问题，只是开始还没有完全理解。阿猪工作守则第五条：软件不是一次能测透的Rome is not built in one day.工期、人力、环境资料等，都制约着测试的深度和广度，因为不要期望一次能完全把握某个软件。

综合测试的优势在于，我们负责公司产品的把关，而项目由产品延伸而来；测试产品会不断出新的版本，一次没有理解，可以在下一次中弥补，温故而知新。

一口吃不成一个胖子，看我这么瘦又这么能吃就知道了^^

要结合自己的实际情况决定本次测试的深度，不要看着别人进度快了就打乱自己的节奏，只要安排合理，应该按照计划来。特别忌讳认为自己这块没问题了就马上去看看别人负责的功能，期望全能。这样一般来说除了ljl这种全能性人物外都会造成最后自己的问题留了一堆，别人的也没搞懂。

新人特别注意，踏踏实实的搞懂每个自己负责的模块，打阵地站，这种方法很有效。评价自己是否可以转入下个模块的几个因素：自我提问与别人提问、测试进度

如果大多数相关人员（主要是测试负责人、其他部分相关测试人员特别是开发组集成测试人员和技术支持人员）对于自己负责模块的问题都能解答，搞定！NEXT-->转入下个模块。

否则，还是再回头想想思路和遗漏的地方。当然，要综合考虑测试进度。请组长对自己提几个软件的问题，他会很乐意的。

e.小结

一个阶段就进行一次小结，这个小结可以是书面的，比如测试问题记录、测试用例补充、测试模块设计等，但大多是自己分析，为了方便接下来模块的测试.f.性能测试

性能测试不仅是测试性能，同时也加深自己对软件应用的理解，因为性能测试往往和实际应用或用户需求结合的很紧密，避免造成软件功能都会用，但不知用来干麻的尴尬情况。g.安装盘测试

安装盘程序测试，简单过一下软件功能有无错误。

安装盘程序文件、库文件、组件等的完整性、正确性，这个非常重要，要不返工就浪费时间了。这个阶段要积极与开发负责人和GJ沟通，确保最后的胜利。

h.测试总结

测试接近尾声，总结自己对软件的掌握情况，得出测试结论、归纳测试方法、提出修改建议，为软件以后版本的修改提供依据，也为以后再测类似软件提供捷径。

5.小结

 用户用软件，测试测软件

培训时多想多问

好记性不如烂笔头

带着问题去测试，在测试中解决问题

 先做事，后学习，争取双赢

软件不是一次能测透的

第五篇：测试经验总结

6年测试工作的思考

前言

在公司已经干了6年的测试了，干测试经理也5年了。正好趁此机会把自己6年来一直想写但没写的东西写出来。这篇文件纯粹是对自己工作的回顾。由于时间仓促基本上是想到什么些什么，有点儿乱，也请大家多多担待了。只要还有些人能从中找到些儿同感，或从中得到一些帮助，一些经验，我就知足了。

1.什么是测试

首先我要谈谈什么是测试。相信好多测试人员跟我一样，来公司之前也没有从事过任何测试工作。对于测试都是从零开始的。也有好多人跟我一样，从各种书上或是培训中得到过有关测试的各种定义。但不知道大家有没有净下心思考一下。什么是测试。在公司公司测试工作的定义是什么，测试的工作范围是什么。

测试的定义根据测试技术的发展，历经了3个主要的阶段。第一个阶段，认为测试就是找产品中的bug。第二个阶段，除了找bug以外，又增加测试是对软件质量的度量这一概念。第三个阶段，明确了测试是指为了度量和提高被测试软件的质量，对测试件进行工程设计，使用和维护的并发生命周期。注意其中提高的测试件，其主要是与软件这个词进行对应。明确测试也是一种开发过程。他的工作成果就是测试件，好像平时我们所谓的测试案例、测试脚本等等都可以称为测试件。然后使用测试件去度量和提高被测试软件的质量。

目前，在中国大部分软件企业，尤其是中小型的软件企业还停留在第一阶段。我个人觉得公司稍微好一点儿，处于一、二阶段之间。因为我们平时做的最多的一件事，还是找bug。至于测试案例和测试脚本等等，只占用工作量的很小一部分。而且我看不到大家在平时的测试工作中是完全依据测试案例进行测试的。目前测试案例等工作更多的成为了一种形式上的产物。从有些部分所有产品的测试案例在一个下午就能评审完就能看得出来。

说到这里顺便在谈一句测试计划。目前的测试计划是作为产品计划的一部分。先明确大概发版时间，然后是各个阶段的里程碑，其中提交集成的里程碑是死的。开发需要的时间就是那么多，剩下倒推的时间就是测试的时间。这样定出的计划是否能够起到计划的作用就不好说了。现在的计划更多的是罗列联调测试的各种内容，至于时间，不说也罢。所以从中也可以开出公司的测试也就停留在一、二阶段之间。

明确了公司测试的定义（个人理解），也就不难理解公司给测试人员的定位了。在测试人员中经常流传的一种说法就是国外测试人员的地位多么多么的高，开发就是coding。咱们公司开发比测试多拿多少多少，测试人员地位是开发序列中最低的。大家也要看看人家公司测试人员的素质，测试在开发过程中的重要性。再看看自己所从事的工作，就是找软件的bug。当然我也个人认为有经验极其丰富的测试人员对产品的贡献比开发和需求大。明确了这些，心里也就能少点儿不平衡感。

2.测试方法的思考

说完个人对测试含义的理解，再说说个人对测试方案的一些思考。

个人认为在公司6年，测试方法没有什么提高。主要还是以黑盒测试为主。中间也曾经引入过各种各种工具，但测试人员真正用起来的也就是robot。而且robot主要是进行回归测试，再加上一些人并没有真正认识到其价值，应用范围也极其有限。对整体测试效率的提升影响不大。所以目前的测试方案还主要是以需求为依据的黑盒测试。至于什么极限值了，成对测试法等等，都是建立在黑盒测试的基础上，而且从我一来公司就有相应的测试项目，只不过没有明确概念而已。

另一个说个人觉得6年来公司测试方法没有什么提高的原因是，6年前测试是以人为主，靠得是测试人员的经验，对产品的熟悉程度，对业务的理解程度。6年后测试还是以人为主，人就是测试的主体，产品质量的保证。还没有过渡到测试案例就是测试的主体，测试案例的完整性是产品质量的保证。只要测试还是以人为本，我觉得测试的效率就不会有太大提高，产品质量的信心来源也是对相关测试人员的信任。我个人觉得以黑盒测试为主要的测试方法没错，而且也比较符合目前公司的测试现状。但一定要注意各种经验的总结、积累，更重要的是共享。虽然目前测试案例在测试工作过程中的地位不重要，但其毕竟是编写者的经验积累。汇总起来也是一笔可观的财富。可现在如果有人问我850的测试方案在那里，其中还有多大比例能够用在现在的产品中，在现在的测试工作中有多少以前的案例能够复用。其他产品中的测试案例中有多少是关于接口功能，有多少我可以借鉴。我不知道，这也是自己工作不到位的地方。所以我要说的作为黑盒测试为主要的测试方法，一定要注意测试经验的总结和共享。

而且我认为一个人如果黑盒测试能做到位，做到最后培养的是一种测试的感觉。测到最后，产品你一看就能知道那里可能有问题，那里应该没什么问题。这样有重点地投入测试力量可以收到事半功倍的效果。可这是需要大量测试经验的积累的，不是我告诉你，你就知道的能力。在此前提上加强测试人员之间的横向沟通，形成经验贡献。可以较快的培养测试人员的测试感觉。

最为测试经验积累的另一个重要方法就是加强对测试案例的要求和管理。每版测试案例不仅要包括新增功能，还需要包括上一版本中继承的案例，修改或删除上版案例中变更的内容。从而形成一份完整的关于产品所有功能点、接口、升级、年结等等各方面的测试案例。真正做到测试案例是测试的主体，从而提高测试效率，提高产品质量。

3.测试工具的概念和作用

测试工具，什么叫测试工具。我认为任何能提高你测试效率的工具都可以称之为测试工具。不仅仅指robot或是loadrunner这类专门的测试工具，也不仅仅指使用各种编程工具编写的测试工具。像总账工具、eai等，即使只是帮我们导入一些常用档案，也可以节约我们的测试时间也可以称之为测试工具。

我个人现在公司测试在测试工具开发上还很不足。在公司里一提起测试工具，大家第一个想到的可能就是robot。即使是robot应用的也不够深入。大家经常认为robot主要录制gui的脚本，跟产品界面联系紧密。每次回放成功率不高，各个版本间脚本复用率也较低。而且每次总是以各种理由将脚本录制放到最后，经常就不了了之了。最后阶段的测试任务实在太紧。我想说的是robot的应用虽然有各种各样的局限性，但其毕竟提高了测试效率。比如说安装盘验证，使用robot验证，每天都可以节约一半以上的验证时间，这就是效率。认识了它的好处，才能想尽办法解决或避免在robot使用中的各种问题。以前同事有一套robot脚本规范就很好，使用后不仅提高了回放成功率，而且回放中断后，继续回放也变得很容易。所以说使用robot后，想100%回放成功不可能，想不再进行脚本的调试也不可能。认识这两个问题后，就需要加强robot使用经验的总结和共享，有针对性地加强robot使用问题的研究，每版测试开始时针对上版robot脚本的复用问题进行研究。这样才能用好它，真得使之成为一个工具，而不是一项任务。

一种工具也不是万能，有许多针对产品特性的测试工具。只能自己开发，大家应该积极提需求。凡是认为有可能提高测试效率的工具需求都可以提。能从网上找到现成的工具解决需求更好。不能，如果是普遍性的需求，可以专门进行开发。因为咱们产品的特性，每版间测试工具的复用度很大。从长远看就是节约开发成本，缩短开发周期。

在现阶段加大测试工具的适用范围和力度，用好各种测试工具，可能是提高整体测试效率最快最好的方法。但一定要加大推广的力度。否则有了好的工具，没人用或用不起来也是没用。

4.如何看待各种规则和执行

可能大家觉得平时开发过程中有好多规则、制度。这些除了一些自己公司内根据各种情况制定的外，大部分都是跟cmm体系相关的一些规则。可以说是已经被许多软件公司验证过，可以提高开发和测试效率的规则。但好多人觉得起没有什么用，就是在浪费时间。总是以一种完成任务或是应付差事的心情去做。我觉得大家之所以觉得其没用，恰恰就是由于你去做这件事的动机不对。总以应付差事的心情去做，你就不可能真正理解这么做的目的，这样做能给你带来什么好处，你从中会得到什么收益。所以我个人认为，既然有规则，不管是公司自创的或是借鉴其他标准，都是为了解决开发过程中的问题，为了提高开发的效率，保证产品质量。也许这些规则中有这样那样的不合理，但只有你认真地去做了，才能发现其中的不妥之处，才能改进，才能更有助于你的工作。

执行也是我觉得在工作中需要进一步加强的环节。许多规则就是因为执行力度不足，才容易让一些人找到空子，应付了事。但怎样加强执行力度，还是一个需要大家一起进行探讨的问题。

5.作为一名测试人员应该具有的素质

测试人员应该具有什么样的素质，相信好多人都有自己的理解，不同书上的观点也不尽相同。我就说说我在公司工作了六年，觉得一个合格的测试人员应该具有什么样的素质。业务和测试方面的能力就不说了。

测试人员应该具有的素质包括： 1.踏实细心和积极主动

我觉得作为一名测试人员首先要踏实细心。测试人员每天都要面对着枯燥的程序，从事着大量的重复工作，还要尽量发现产品中的bug。如果不踏实，你就坐不住，总想干别的，就无法净下心来想用户有可能怎么用，需求对产品是怎么要求的，现在产品中是怎么做的，哪里可能存在问题。不细心，就特别容易一些产品中微笑的错误，而恰恰就是这些错误是最影响产品形象的问题。

至于积极主动就不多说了。这是每个人都应该具有的素质。2.怀疑一切

不抱着怀疑一切的态度就不是一名合格的测试人员。经过你手测试的产品面对的是直接用户。你不认真负责，不抱着怀疑一切的态度。总想着这个功能本版没动应该没什么问题，这个功能没什么用户用不用认真测了。这样发出的产品，我是不敢让用户用。因为用户用起产品来是千奇百怪，有些用户的水平和对产品的理解比咱们还要深。所以一定要抱着怀疑一切的态度，认为产品每个功能都可能有问题，认真地测试产品的每一个测试点。

3.协作和团队感

协作和团队感也是十分重要的。要意识到测试、开发、需求是一个团队，一个整体。离了谁，产品的质量都无法保证。诚然有个别开发人员责任心不强，经常将未经任何验证的代码编译后发给测试进行验证。耽误了测试人员不少的时间。但越这样，测试人员越应该负责，否则产品发出去影响的是公司的形象。

还有个别开发人员开不起测试。此时就需要你通过各种方法去证明你自己的能力。比如测试出他根本就没考虑过的问题等等。以实际行动证明你离不开我，咱们是一个水平的。只有这样加强协作和团队建设，加强整个团队的质量意识，才能提高开发效率，保证产品质量。

4.自我提高和总结的能力

测试人员经常很迷茫，不知道自己的发展方向在哪里。测试技术还是专业知识。领导们所谓的个人发展方向考虑也经常是画一个饼在那里。这时就只能靠我们自己了。看你想今后从事哪方面的工作。一般情况下，如果升不到管理层就只有两条路可选了。一是业务精通，将来可以向需求或是售前、实施方向发展。一是技术精通，多掌握几种测试工具，又能力可以学习一些编程方面的知识。将来还继续从事测试方面的工作。随着中国软件开发的规范化，这条路也是很有发展的。

另外，我觉得作为一名合格的测试人员，一定要注意进行总结。通过总结可以对自己的工作进行一个回顾分析，看看那些做得不错，下次还继续这么做。那些工作还有改进的余地。对自己能力的提高是一个很好的帮助。

6.作为一名测试经理应该具有的能力

作为一名测试经理，我觉得除了具备一个测试人员应该具备的素质外，还应具备以下能力。

1.出色的沟通和协调能力

由于测试人员和开发人员的工作性质，必然导致测试人员和开发人员在工作中会产生冲突，对同一问题会产生不同的看法。这时，你怎么去协调，去沟通，解决这种矛盾，让自己所在的开发团队中极少的受此影响，就是考验你能力的时候。

2.条理性和计划性

作为测试经理，要负责带领团队内的其他测试人员全面的测试产品。由于测试项目很多，不仅包括产品功能，还要包括效率，性能，压力，并发互斥，环境等等方方面面。此时你如何去安排这些测试项目，哪些可以先做，哪些可以并行。与开发人员在一些项目的测试中如何协调就是考验你做事的条理性和计划性。

3.从全局考虑产品测试的能力

每一个测试人员在产品测试中，重点肯定是自己负责产品的功能，此时就容易遗漏其他的一些测试项目。有可能是接口的部分功能，又可能是升级或年结的部分功能。此时，你如何提请他们还有漏测的功能点。在有限时间内，能找出他产品测试上的薄弱点，就是考验你通盘考虑产品测试的能力。

后记

上面就是我对6年测试工作的一个回顾。这些都是我个人的一些观点，很不全面，也有不正确和遗漏的地方。大家看后，能从中得到一些自己需要的东西，我就知足了。

再次感谢在这6年中给了我许多帮助和支持的各位兄弟姐妹们。

附录A、QA工作心得

看过许多同行兄弟姐妹的工作感受，反映了一些从事QA工作过程中的困惑，心里也很有同感。之前做过几年的测试工作，到了新的公司开始做QA工作，虽说测试工作也是属于质量工作范畴，但是真正干起来才发现，还是有很大的不同的，尤其是思想方法和工作方法上。所以也是边学边干，这边和大家分享一点心得。

1、调整好自己的心态。

尊重开发人员、产品经理、项目经理等项目组内同事，不要把自己定位为监工，要把自己定位为服务员。如果你真的是从心里想帮助大家把事情做好，而不是教训别人，大家会感受到的。很多时候，调整好自己的心态才是难点。

2、有的放矢 不要盲目的发表意见，要做到有理有据，这也是避免项目组内成员产生争执和不理解的前提。在提出意见和建议前，最好做一下调查，收集一些资料和数据，或者和大家深入的聊一聊，开一些交流会，座谈会，收集到一线开发人员的真实感受，不要自己一觉得有问题就冲出来，这样肯定会被别人反感，也会降低大家对QA的认同和信任感。

3、数据说话

质量工作相对务虚不假，之前做测试好歹还有很多的bug摆在那里，刚开始做QA工作确实觉得虚了很多。自己的产出在哪里？后来发现，其实还是可以有很多的，呵呵。你可以给相关人员进行培训（质量知识、软件工程知识、产品开发知识、质量制度和规范等等），会议记录和培训资料算是你的产出的一部分。另外，对于项目过程中产生的问题，变更等，要有记录，一定周期内作出分析和报告，比如，变更发生率，项目延期的原因分布，与计划的不符合程度等等。进一步提出改进建议，有了这些数据支持，你提出建议也就更有说服力。

4、沟通再沟通

其实很多问题都是发生在沟通上，我觉得沟通好了，起码可以解决70%的问题。多为大家提供交流和沟通的机会，比如，发起一个交流会，让组内同事互相培训，形成一个良好的内部学习交流气氛。另外，什么也比不过面对面的沟通，抛弃聊天工具和email吧，走过去，和你的同事一起好好聊聊，吃饭的时候，坐车的时候，你会发现很多深入的问题的，呵呵。

5、循序渐进

规范制定好了，不要一下子就想完全推行到底。毕竟要改变别人已有的习惯，是会让别人不舒服的，呵呵。所以要循序渐进，分期分批，一点点来，习惯慢慢的就被改变了，这样大家就不会太抵触。而且，在分期分批推行规范的过程中，别忘了不断收集反馈意见，不断改进和修正规范，规范可不是qa说是什么就是什么的，一定要收集大家的意见，达成共识，这样才有被大家执行的基础。

6、展示自己

QA工作务虚，但是可以落到实处，是有很多实际工作要做的，比如文档编写，规范起草。培训、评审、跟进问题。这些工作的成果如何体现，效果如何，可以通过一些问卷调查，来收集大家的反馈，举个例子，如果推行产品开发流程规范前大家对流程的满意度是50%，推行规范两个月以后，满意度成了90%，你说这是谁的功劳呢？呵呵，这也是数据说话的一个方面，也是QA工作成绩的展现。说了这么多，其实我做QA工作也只有3个月，还有很多的不足，希望能和大家多多的交流，如果自己的一点心得，能够给大家一些帮助或启发，就深感欣慰了，呵呵。欢迎拍砖！

附录B、SQA之Q&A 软件质量保证，即 SQA，全称是 Software Quality Assurance。

问： SQA 目的是什么？

答： 对于任何的行业，讲到质量控制，归根结底都是为客户提供更高品质的产品，更好地满足客户的需求。质量有问题的话就不能满足客户的需求。在 CMMI 里边就有 “ 集成流程产品开发 IPPD(Integrated Product & Process Development)”，为什么要集成呢？就是说产品的研发不仅仅是开发团队的工作，还要把市场团队、销售团队、整个的流程、包括客户的反馈都要考虑进来、集成进来。目的是为了什么？其实就是为了更好地满足客户的需求。六西格玛里面说 DPMO(Defect Per Million Opportunities)，百万产品里有缺陷的产品只有三个。这是为什么？就是为了减少差错，从而让客户享受非常高质量的服务。

问： SQA 等于测试？

答： 测试其实只是 SQA 的一个环节，SQA 的全称是软件质量保证。在国外很多的大型的企业，比如说摩托罗拉、爱立信，他们的研发团队里面都专门有一个 QA 部门，其实他们并不是做测试工作的。QA 部门其实是管理开发流程的执行，并专门负责制定产品开发流程。比如说 RUP 里面有一个角色，叫 Process Engineer，过程工程师，他就属于 QA 部门，他的工作就是负责制定整个软件开发的流程。因为如果说要保证质量的话，不能只靠测试来保证。而必须在整个开发流程的各个环节都要做得很好，才能够真正地提升软件的质量。而测试只是整个开发流程最后的一个阶段。所以说一个好的流程就决定了一个软件的开发能不能按时交货，能否保证软件质量。这个流程就是由 QA 部门来制定的。QA 部门还有另外一个职责，就是保证整个研发团队能够严格按照这个流程来运作。在项目到达每一个里程碑的时候，QA 部门的 QA 经理就会介入，对项目做一个审核，检查前一阶段的工作是否按照公司制定的流程来运作。看看该有的工件是不是都有了，该有的步骤是不是都有了。开发团队要证明给 QA 人员看。只有过了这一关，QA 部门才会同意说开发团队可以往下走，进行下一步的工作。所以严格来讲，众广义上理解，SQA 是针对整个软件开发流程的，它关心的是怎样在软件开发生命周期中来保证好软件的质量。这是一个非常大的概念。

问： SQA 在 RUP 中是如何体现的？

答： 其实 RUP 整个流程都在讲 SQA。业界常见的模型，譬如 CMM/CMMI，六西格玛，ISO9000，RUP，它们做的基本上是同一件事情--都是在做流程改进，都在做质量控制，但是各自的侧重点不一样。像 RUP 和 SDP 专门侧重于从软件开发的整个生命周期来保证软件质量，所以对软件开发商特别适合。而其它的模型，侧重点则在其它的环节，比如说 ISO9000，用在制造业比较多一些； CMM，原来是应用在软件这个行业的，后来扩展到 CMMI，就扩展到其它行业它也适用。但适用面越广，它拉的层次就越高，可实际操作的东西就越少。RUP 是专门侧重于软件项目开发的。怎样来保证做好 QA 呢？ RUP 里定义了一个软件生命周期模型，分成四个阶段--初始阶段、细化阶段、构造阶段、交付阶段，每个阶段有不同的侧重点，通过多次的迭代，每次迭代里面都要做质量控制。

质量控制从需求开始，有很多需求分析和需求管理方面的技巧和技术方法，它们从需求方面来保证软件的质量；到了设计，就有很多成熟的设计方法，例如可视化建模，基于构件的架构设计和现在提出的模型驱动开发方法；再到实现，到测试等方面，都有很多的方法和技巧来提高软件的质量。这里面每一个环节的目的都是为了提高整个软件开发的质量。

开发过程中，什么样的问题会造成质量问题呢？其实最主要的就是沟通方面的问题，以及对系统复杂度把握程度的问题。我们逐渐发展了一些技术来帮助我们解决这些方面的问题，例如用 UML 这种标准化的语言来增强团队的沟通，用面向对象的技术来帮助加强对复杂度的控制能力。

原来这个系统很复杂，使用面向对象的方法，本身就是为了简化系统构建的复杂度。改变你看问题的角度，你对问题的把握程度就会不一样。譬如人看一个二维迷宫很容易就能找到出路，但蚂蚁在里面就走不出来，因为看问题的角度不一样。面向对象方法和可视化建模技术可以让开发人员可以更好地去把握系统，增强对系统的可控制能力，从而从这些维度上来提高和保证软件的质量。

现在有很多自动化的工具，如 IBM Rational RAD(Rational Application Developer)/ RSA(Rational Software Architect)，都是支持 MDA 的开发方法，在模型这一级进行开发，从模型直接生成代码。在开发方面我们有很多辅助工具，帮助开发人员尽量将人工做的工作、复杂的重复性的工作、不具有创造性的工作让工具来做。让人去关注他应该关注的方面，比如开发人员应该关注业务逻辑的处理，但是软件的构建方面我们是尽量让工具来降低构建细节上的难度。这样也是有助于提高质量的。

然后产品出来了，需要进行测试，有测试流程、测试规范来帮助保证质量，这是最直接的。然后还有很多的环节还会发生错误，比如配置管理、版本的管理，也需要相关的支持来保证软件的质量。所以说软件质量保证不应该只是在一个环节上，比如测试环节来保证，而应该是整个的流程，我们应该全面地去改进流程来保证质量。

问： 做 SQA 这方面的人员，在沟通方面需要的什么样技巧和能力？

答： 首先从大的方面说，整个团队的沟通，首先是大家要讲同样的语言。UML 只是这种语言的一部分，我们不要狭义地理解这种沟通语言就是 UML。它还包括采用一个什么样的流程方法，整个团队都要理解。譬如你说项目正处于 “ 精化(Elaboration)” 阶段，这个团队都要能理解这个术语。

还有就是整个组织机构内部大家采用的流程都是要一样的。举个例子来说，Rational 有很多产品，其中很多都是收购来的。不同的产品团队采用的开发方法、开发工具都是不一样的，他们到了 Rational 之后做的第一件事就是整合。这个整合一方面是说产品要整合起来（我们有 Suite 产品）；同时也是针对开发团队开发方法的整合，例如 Rational 花了一两年的时间把所有产品团队统一到 RUP 和 ClearCase/ClearQuest平台之上，这是我们的首选。实际上到了 IBM 之后也是一样，IBM 现在正在做的计划就是让所有的实验室、研发团队都要使用 IBM Rational 自己的开发工具，他们都在使用 IBM 自己的开发方法、开发平台。这就是让大家的沟通基于一个统一的基础架构 ―― 统一的软件开发平台，这也是增强沟通的一种方式。另外，讲到 SQA 的人员，在 RUP 里对应的就应该是 Process Engineer。他的主要的职能就是定义流程，保证流程的执行，并且不断地改进流程。对他的要求就是要对流程要比较了解，有实际项目的开发经验，不然没有办法理解流程，这是技能方面；另外就是与人的沟通能力要强，跟一般的开发人员和项目经理是有区别的，沟通的能力一定要强，他要负责说服项目团队来遵循标准。

问： QA 人员与目经理和开发人员之间的关系是怎样的？

答： 首先彼此之间是一个合作的关系。如果片面理解 QA 人员只是 “ 过程警察 ” 的话，就可能把他和其他的角色对立起来了。实际上在一个团队内部要避免这种认识。因为大家都是在一个组织架构内部的，大家的目标是一致的，就是要把公司的业务做好。所以 QA 人员的职责和任务就是帮助这个项目团队更好地进行软件的开发。既然已经定义的流程是比较适合企业的，项目就应该遵守这个流程来进行开发。如果有时候项目因为赶工，或是其它的原因违背一些流程上的规定的话，就会对软件的质量会造成一定影响，他就有责任来帮助开发团队来纠正这方面的一些错误。还有就是进度方面的问题。如果不按照流程来走的话，短期内看起来进度是快了一点，但从整个项目的周期来看，有可能是给以后的工作带来隐患，客观上肯定是延长整个开发的进度的。所以对于一些流程管理得比较好的企业，你会发现他们的 QA 部门和开发团队是相处得比较融洽的，配合是比较紧密的。在我们的客户里就看到过他们的开发团队非常感谢自己的质量控制人员，觉得他们对自己是给了很大的帮助。

QA 人员跟每一个角色的关系，如果你对应到 RUP 的话，RUP 里就定义好每一个角色是做什么工作的。RUP 里分了 9 个规程(discipline)，流程工程师是在环境规程里边，项目经理是在项目管理规程里边。每一个规程其实就是一类开发活动，其中的角色和他们所产生的工件集合，是一个分类。可以把项目经理相关的工作，他所涉及到的工件，比如说软件开发计划、风险管理计划、质量保证计划都放在一起，放在这个规程里面。所以 QA 人员跟项目经理的关系就是去检查项目经理在这个岗位上所做的职责是否到位，是不是跟流程相符合。其他的角色也是一样的，譬如一个测试人员，就要看你有没有根据规定把缺陷按正确的测试流程汇报，发现缺陷之后是否能够得到改正，并作一个复审，还有回归测试的时候有没有考虑测试的完备性等问题，就是看测试人员有没有做好具体的工作。QA 人员和整个项目团队在工作中的关系就是看每一个角色是不是很好地完成了自身角色所应该完成的开发任务。标准是什么？就是这个组织的流程，流程是保证质量很重要的一个依据。

问： QA 人员如何判断其工作效果和质量？

答： 最直接就是 RUP 里的工件。可以去检查这些工件，可以根据检查的结果来判断角色是否达到了要求。既然是检查这个结果的话，就有必要涉及到统一流程和工具的问题。就是说开发团队有必要采用统一的开发方法和流程。不然的话每一个开发团队各自采用不同的开发流程，流程工程师就很难去评价，没有一个可对照的标准，没有可比性。另外，和采用的工具也有关系，就是说团队要尽量采用统一的开发平台。采用统一的开发平台，工具会帮助自动收集很多的信息。比如说我们的 Project Console 可以帮助收集很多量化的指标；现在有 Portfolio Manager，项目组合管理平台，可以帮助了解项目进度还有项目进行过程中产生的各种结果；还有包括测试的报告等等，这些都最好有一个统一的标准。打个比方来说，现在的航空公司都会选择相同飞机制造厂商的机型，就是要降低维护的成本。因为机型比较统一的话，就比较好进行管理。在一个软件企业的话，在内部采用统一的软件开发平台也能有助于企业判断项目的情况，判断的方法也会相对比较简单，工作量会降低。

这是从 QA 的角度来看，其次从整个团队的角度来说，今天是做这个项目，明天做另外一个项目，作为企业的管理人员肯定不希望员工今天做这个项目用一个工具，明天做另外一个项目用另外的工具，这样学习成本就太高了。