转载软件测试总结

软件测试，从零开始[/b]一、如果开发人没有提供需求文档，如何有效的识别测试需求？

1． 主动获取需求，可以与技术支持的人沟通（最贴近用户），抓住输入、处理过程、输出、性能要求、运行环境来分析需求；

2． 确认需求的优先级

3． 加入开发小组的邮件群；

4． 与开发人员为邻；

二、测试用例设计

1． 测试用例要素：标题、输入、重要级别、操作步骤、输出；

2． 重用同类项目测试用例，适当“拿来主义”；

3． 利用已有软件的CHECKLIST；

4． 加强测试用例的评审（CMM3）；、

5． 定义测试用例招待顺序；

三、测试用例执行

1． 搭建测试环境，执行测试用例；

2． 测试执行应注意的问题：

a) 全方位观察用例执行结果，除了比较实际输出与预期输出，还要察看系统资源利用率及运行日志等

b) 记录测试过程，通过操作日志来记录操作过程，尽量与用例描述的操作步骤一致；

c) 及时确认发现的问题，配合开发人员重现问题；

d) 与开发人员良好的沟通；

3． 及时更新测试用例；

4． 提交一份优秀的问题报告单；

a) 测试环境描述，软、硬件都要；

b) 操作步骤\输入\输出；

c) 截图及日志信息等。

四、测试结果分析

单元测试[/b]组织、流程、技术是软件质量三角。

一、组织结构应保证测试组参与单元测试

测试组以哪种方式参与单元测试，要看实际情况定，如果测试人员较多，基本上能达到测试：开发值为1：1的话，可以由测试人员独立承担重要模块的单元测试，如果测试人员不足，可以由测试人员进行单元测试计划与单元测试设计，而由开发人员实现单元测试；如果测试人员非常少，则参与单元测试文档及单元测试报告的评审。

二、加强单元测试工作流程规范

1． 制定单元测试过程，计划、设计、实现、执行阶段。

a) 计划，时间表、工作量、任务分配、人员分配、资源分配、测试工具、测试方法、结束标准、验收标准、存在的风险、风险处理办法，输出《单元测试计划》；

b) 设计阶段，对哪些单元进行测试、被测单元之间关系、被测单元同其他模块的单元之间的关系、测试策略、如何进行单元测试用例设计、如何进行单元测试代码设计、采用什么工具，输出《单元测试方案》；

c) 实现阶段，设计单元测试用例，编号单元测试代码，编写桩模块、驱动模块，输出《单元测试用例》及测试代码；

d) 执行阶段，执行测试脚本、记录测试结果、错误处理等，输出《单元测试报告》。

2． 单元测试工作产品需纳入配置管理；

3． 要制定覆盖率指标及质量目标来指导和验收单元测试；

4． 加强详细设计文档评审；（如果没有经过评审的详细设计文档，建议用代码走读代替单元测试）

三、单元测试者技能的提高

1． 加强对单元测试人员的技能培训；

2． 引入工具进行辅助；

3． 单元测试者加强对被测软件的全面了解；

为盈利而测试[/b]程序测试是为了发现错误而执行程序的过程。

误区一：忽视对正常输入的测试；

误区二：忽视设计阶段的参与与评估；

误区三：忽视测试计划与测试文档的建立与维护；

误区四：忽视缺陷的分析，报告及跟踪；

误区五：错误的测试目标及测试终止条件；

误区六：不懂合理调配使用测试人员的知识技能结构；

一、软件质量与软件测试？

二、软件测试的经济目的

1． 满足用户需求，提高产品的竞争力，最终提高产中的销售量

a) 可靠性；

b) 安全性；

c) 性能；

d) 外观；

e) 易用性；

2． 尽早发现缺陷，降低后继质量成本

三、何时应当停止测试

残留的缺陷与最后个阶段排除的缺陷相等，即可终止测试。

软件测试的常识[/b][/b]一、测试是不完全的

二、测试具有免疫性，即缺陷具有免疫性

三、测试是泛性的，即全程测试

四、80-20原则

五、为效益而测试（Keep it simple but not too simple）

六、缺陷的必然性

七、软件测试必须有预期结果

八、软件测试意义（事后分析）：计划——执行——总结——改进——计划

如何提高软件的质量[/b][/b]一、什么是质量？

二、流程对质量的贡献

1．瀑布模型：广泛、易于理解与掌握，需求变更适应能力弱；适用于复杂但易于理解的项目，在质量要求高于进度和成本要求的时候，瀑布模型尤其适用；

2．螺旋模型：关注发现跟降低项目的风险，从小规模开始，探测到没有风险才逐渐加大规模，缺点是复杂，对项目管理人员要求较高，要有责任心与有管理经验；

3．IPD流程，通过流程成本来提高产品质量，不适应需求变动的项目及小项目；

三、流程与技术

四、全面质量管理TQM（Total Quality Manager）

五、关注测试

六、成功铁三角：组织、流程、人

七、国际上流行的质量标准

1．ISO

2．CMM

a）初始级：软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。

b) 可重复级：人们根据多年的经验和教训，总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

c) 已定义级：要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。

d) 管理级：所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。

e) 优化级：优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

八、如何起步？

浅谈功能测试用例模板设计[/b][/b]一、测试用例等级：冒烟测试、关键路径测试、可接受级测试（招待通过一次即可）、建议

执行的用例。

二、测试用例结果：通过、失败、警告、阻塞、忽略。

成功测试自动化的7个步骤[/b]一、 [/b]改进软件测试过程

二、 [/b]定义需求[/b]

三、 [/b]验证概念[/b]

四、 [/b]支持产品的可测试性[/b]

五、 [/b]具有可延续性的设计[/b]

六、 [/b]有计划的部署[/b]

七、 [/b]面对成功的挑战[/b]

缺陷漏测分析：测试过程改进[/b][/b]一、漏测的定义

二、漏测分析的目的

1．对漏测进行分类以便于更进一步深入的分析

2．对分类数据进行统计

3．在统计分析的基础上进行全过程的标识和变更

4．在对一些特殊的漏测项进行分析的基础上，对过程的一些局部进行标识和变更

5．运用度量数据说明过程变更的效果

三、如何进行漏测分析（一次/月）

1．计划

2．漏测分类

a)漏测产生活动：开发阶段、测试阶段

b)产品模块

c)缺陷影响

d)引入版本

e)平台

f)严重级别

g)发现漏测的版本

3．分析活动：跟踪工具，主要是缺陷跟踪工具

4．分析活动：统计，频率以一个季度进行一次为好。

5．分析活动：全流程过程改进

6．分析活动：局部过程改进

7．度量

四、测量

1．测量驱动改进

2．评价漏测分析效果

a)TFVUD(Total Field Valid Unique Defects:用户发现的经过确认的、不重复的、不是错误操作所致的、非建议类的缺陷；

b)PDD(Post Development Defects)：测试发现的缺陷数。

五、总结

功能性（实现软件应具备的基本功能）

易用性（用户学习掌握该软件所耗费的时间及在具体业务流程上的简化）

执行速度（多数是启动速度，查询速度，刷新速度及响应时间等因素）

用户使用时产生错误的比率（在允许用户任意使用的情况下，越少越好）

用户满意度（这里指的是用户界面设计与功能设计的用户评价）

遗漏信息

没有任何屏幕指令

假定打印出的文件随时可得

无正式文字证明（说明）的功能特征

看起来不可能退出的状态

没有光标

没有对输入做出响应

在长期延迟时没有表示其活动

当某个改变即将生效时没有给出建议

没有对已经打开的文件进行检查

错误的、误导的或令人迷惑的信息

漫谈人机界面测试[/b][/b]一、一致性测试

1．提示格式是否一致；

2．菜单格式是否一致；

3．帮助格式是否一致；

4．术语是否一致；

5．对齐方式是否一致；

6．界面外观、布局、交互方式是否一致；

7．命令语法是否一致；

8．功能类似界面外观、布局、交互方式是否一致；

9．与同类产品外观、布局、交互方式是否一致；

10．文字大小、字体、颜色、对齐方式是否一致；

11．连续出现的界面，外观、操作方式是否一致；

二、信息反馈测试

1．系统是否接受客户的正确输入并做出提示；

2．系统是否拒绝客户的错误输入并做出提示；

3．系统显示用户输入错误的提示信息是否准确；（浅显易懂）

4．系统是否在用户输入前提示用户正确的输入方式；

5．系统提示所用的图标或图示是否具有警示性跟代表性；

6．系统提示用语是否按警告级别跟完成程度区分；

7．系统在界面上是否提供突显功能；

8．系统是否在用户完成操作时给成功提示；

三、界面的简洁性

用户界面是否存在空白空间（没有空白空间的界面是杂乱无章的，易用性极差）；

各个控件之间的间隔是否一致；

各个控件在垂直和水平方向上是否对齐；

菜单深度是否在三层以内（建议不要超出三层，大家可以参考微软的例子）；

界面控件分布是否按照功能分组（菜单、工具栏、单选框组、复选框组、Frame等）；

界面控件本身是否需要通过滑动条的滑动来显示数据（建议采用分页显示并提供数据排序显示功能）；

四．界面美观度测试

1．前景与背景色搭配是否反差过大

2．前景与背景色是否采用较为清淡的色调而不是深色

3．系统界面是否采用了超过三种的基本色

4．字体大小是否与界面的大小比例协调

5．按钮较多的界面是否禁止缩放

6．系统是否提供用户界面风格自定义功能，满足用户个人偏好

五、用户动作性测试

1．用户频繁的操作是否存在快捷键；

2．是否允许动作的可逆性；

3．界面是否满足用户的记忆需求；

4．系统的反应速度是否符合用户的期望值；

5．是否有更快捷、更直观的方式来取代当前界面的显示方式；

6．用户使用时是否任何时候都可以打开帮助文档；

7．是否提供模糊查询及关键字记忆功能，减少用户记忆负担；

8．是否对可能等待较长时间的操作设置取消功能；

9．是否对错误操作提供可逆操作，恢复原态；

10．是否用控件替代手工输入；

11．选项过多的时候是否用下拉列表或关键字检索的方式供用户选择；

12．系统出错是否存在恢复机制，使用户返回出错前状态；

13．在用户输入数据之前，用户输入数据才能用的功能是否禁用；

14．系统是否提供所见即所得或“下一步提示”。

六、行业标准测试

1．图标、声音是否符合行业标准；

2．术语是否符合软件所在行业标准；

3．界面颜色是否与行业代表色接近；

4．界面的设计是否符合行业的最新理念跟大众趋势；

软件人机界面的测试需要一个立足“共性”但又要强调“个性”的测试思路，软件人机界面的测试与其他类型测试不同，更加强调从用户的角度、审美观去看待待测软件。既不能过于“大俗”，又不能过于“大雅”。很多时候，需要在强调规整和强调个性间进行权衡。这迫切需要我们的界面测试人员用大脑去思考，用心去体会。这对人机界面测试人员在审美观上也是一个极大的挑战。

软件质量保证、测试及配置管理面面观[/b][/b]一、软件质量六特性：正确性、可靠性、易用性、效率、可维护性、可移植性。

SEPG（Software Engineering Process Group）

剖析层出不穷的BUG[/b]1、 测试遗漏

2、 设计或修改原因

3、 BUG的概率及偶然性

4、 BUG的潜伏性及阶段性

5、 BUG的隐蔽性与周期性

6、 测试的周期性

Mercury[/b]认证[/b]WinRunner适合用来做VC、VB、DELPHI、JAVA、PB等开发的程序，而QTP适合用来做.Net跟J2EE开发的程序。

[/b]
[/b]
软件测试的若干问题[/b]一、自动化测试决策依据

1． 所测软件是否适合做自动化测试

2． 选择合适的自动化测试工具

3． 自动化测试成本，投入与产出比

整体性能测试分析[/b]当安装数据库时实例名不是采用默认值时，在TD中建立DBSEVER时要输入“服务器名\实例名”。