垃圾数据 英文 软件测试_垃圾炸弹测试数据 - CSDN
  • 这是一本在软件测试行业,非常经典的一本书了。 记得,我在2009年,刚做软件测试这行时,读的第一本软件测试参考书,就是Ron Patton写的这本《软件测试》书籍(原书第2版)。 这本书,介绍了软件测试的起源,...

          这是一本在软件测试行业,非常经典的一本书了。

           记得,我在2009年,刚做软件测试这行时,读的第一本软件测试参考书,就是Ron Patton写的这本《软件测试》书籍(原书第2版)。

           这本书,介绍了软件测试的起源,软件测试的经典案例,以及,软件测试的流程,各个流程阶段的定义,以及方法。

    各种测试方法,以及各个测试方法的应用。

           对于初次接触软件测试行业,或者,想要对软件测试行业有个大概了解的入门者,是本挺不错的参考书。

           这本书,迄今为止,已经过去了十年的时间,我也已从对测试的懵懂不解,到现在掌握测试知识,能够运用整个流程的知识,不止包括对测试的理解及掌握,甚至于,对需求文档的理解,并能提出需求文档的不足之处,在项目的初期,就对产品进行介入,提前进入测试状态,很好的诠释了,越早测试,发现的问题,成本越低;到现在也接触了测试管理工作,从入门,技能掌握,管理,这本书始终陪伴着一路以来的成长。

            以下,对《软件测试》这本经典书籍,做个简短的介绍,以便,让各位读者对这本书,有个大致的了解,以便根据个人情况,对是否阅读这本书的取舍,做个参考。 

           总体而言,这本书其实,对处于在软件测试行业不同阶段的人,一般都还是 普遍适用的。初入行者,可以了解,软件测试这个行业,软件测试的基本概念,软件测试的技术以及方法;对于进阶者,可以了解更高级的白盒测试,单元测试,安全测试,配置测试等测试;对于自动化或性能测试爱好者或者从业者,也可以了解自动化测试及性能测试;对于测试管理者,可以了解对整个城市流程的把控;对于软件测试职位方面的求职者,也有一定的指导意义。

     

    内容简介  · · · · · ·

    软件测试(原书第2版),ISBN:9787111185260,作者:(美)佩腾(Patton,R.) 著,张小松 等译;张小松译

    作者简介  · · · · · ·

    Ron Patton具有近20年软件测试和软件质量保证的工作经验,从事过各种产品的软件测试,从关键任务到儿单绘图程序。普先后就职于德州仪器公司、西门子公司和微软公司,担任过质量保证工程师、软件测试经理等职务。他现在是一个独立的软件项目管理和软件质量保证咨询师。

    目录  · · · · · ·

    第一部分 软件测试综述
    第1章 软件测试的背景 3
    1.1 臭名昭著的软件错误用例研究 3
    1.1.1 迪斯尼的狮子王,1994—1995 3
    1.1.2 英特尔奔腾浮点除法缺陷,1994 4
    1.1.3 美国航天局火星极地登陆者号探测器,1999 4
    1.1.4 爱国者导弹防御系统,1991 5
    1.1.5 千年虫问题,大约1974 5
    1.1.6 危险的预见,2004 5
    1.2 软件缺陷是什么 6
    1.2.1 软件失败的术语 6
    1.2.2 软件缺陷的官方定义 7
    1.3 为什么会出现软件缺陷 8
    1.4 软件缺陷的修复费用 9
    1.5 软件测试员究竟做些什么 10
    1.6 优秀的软件测试员应具备的素质 10
    1.7 小结 11
    1.8 小测验 12
    第2章 软件开发的过程 13
    2.1 产品的组成部分 13
    2.1.1 软件产品需要多少投入 13
    2.1.2 软件产品由哪些部分组成 16
    2.2 软件项目成员 17
    2.3 软件开发生命周期模式 18
    2.3.1 大爆炸模式 18
    2.3.2 边写边改模式 19
    2.3.3 瀑布模式 20
    2.3.4 螺旋模式 21
    2.4 小结 22
    2.5 小测验 22
    第3章 软件测试的实质 23
    3.1 测试的原则 23
    3.1.1 完全测试程序是不可能的 23
    3.1.2 软件测试是有风险的行为 24
    3.1.3 测试无法显示潜伏的软件缺陷 24
    3.1.4 找到的软件缺陷越多,就说明软件缺陷越多 25
    3.1.5 杀虫剂怪事 25
    3.1.6 并非所有软件缺陷都要修复 26
    3.1.7 什么时候才叫缺陷难以说清 27
    3.1.8 产品说明书从没有最终版本 28
    3.1.9 软件测试员在产品小组中不受欢迎 28
    3.1.10 软件测试是一项讲究条理的技术专业 28
    3.2 软件测试的术语和定义 29
    3.2.1 精确和准确 29
    3.2.2 确认和验证 30
    3.2.3 质量和可靠性 30
    3.2.4 测试和质量保证(QA) 30
    3.3 小结 31
    3.4 小测验 31
    第二部分 测试基础
    第4章 检查产品说明书 35
    4.1 开始测试 35
    4.1.1 黑盒测试和白盒测试 36
    4.1.2 静态测试和动态测试 37
    4.1.3 静态黑盒测试、测试产品说明书 37
    4.2 对产品说明书进行高级审查 37
    4.2.1 假设自己是客户 38
    4.2.2 研究现有的标准和规范 38
    4.2.3 审查和测试类似软件 39
    4.3 产品说明书的低层次测试技术 39
    4.3.1 产品说明书属性检查清单 39
    4.3.2 产品说明书术语检查清单 40
    4.4 小结 40
    4.5 小测验 40
    第5 章 带上眼罩测试软件 42
    5.1 动态黑盒测试:带上眼罩测试软件 42
    5.2 通过性测试和失效性测试 43
    5.3 等价类划分 44
    5.4 数据测试 46
    5.4.1 边界条件 47
    5.4.2 次边界条件 49
    5.4.3 默认、空白、空值、零值和无 51
    5.4.4 非法、错误、不正确和垃圾数据 52
    5.5 状态测试 53
    5.5.1 测试软件的逻辑流程 54
    5.5.2 失败状态测试 57
    5.6 其他黑盒测试技术 58
    5.6.1 像笨拙的用户那样做 58
    5.6.2 在已经找到的软件缺陷的地方再找找 59
    5.6.3 像黑客一样考虑问题 59
    5.6.4 凭借经验、直觉和预感 59
    5.7 小结 59
    5.8 小测验 60
    第6章 检查代码 61
    6.1 静态白盒测试:检查设计和代码 61
    6.2 正式审查 62
    6.2.1 同事审查 63
    6.2.2 走查 63
    6.2.3 检验 63
    6.3 编码标准和规范 64
    6.3.1 编程标准和规范示例 64
    6.3.2 获取标准 66
    6.4 通用代码审查清单 66
    6.4.1 数据引用错误 66
    6.4.2 数据声明错误 67
    6.4.3 计算错误 67
    6.4.4 比较错误 67
    6.4.5 控制流程错误 68
    6.4.6 子程序参数错误 68
    6.4.7 输入/输出错误 68
    6.4.8 其他检查 68
    6.5 小结 69
    6.6 小测验 69
    第7章 带上X光眼镜测试软件 70
    7.1 动态白盒测试 70
    7.2 动态白盒测试和调试 71
    7.3 分段测试 72
    7.3.1 单元测试和集成测试 72
    7.3.2 单元测试示例 74
    7.4 数据覆盖 75
    7.4.1 数据流 76
    7.4.2 次边界 76
    7.4.3 公式和等式 77
    7.4.4 错误强制 77
    7.5 代码覆盖 78
    7.5.1 程序语句和代码行覆盖 79
    7.5.2 分支覆盖 79
    7.5.3 条件覆盖 80
    7.6 小结 81
    7.7 小测验 81
    第三部分 运用测试技术
    第8章 配置测试 85
    8.1 配置测试综述 85
    8.1.1 分离配置缺陷 88
    8.1.2 计算工作量 89
    8.2 执行任务 90
    8.2.1 确定所需的硬件类型 90
    8.2.2 确定有哪些厂商的硬件、型号和驱动程序可用 90
    8.2.3 确定可能的硬件特性、模式和选项 91
    8.2.4 将确定后的硬件配置缩减为可控制的范围 91
    8.2.5 明确与硬件配置有关的软件唯一特性 92
    8.2.6 设计在每一种配置中执行的测试用例 93
    8.2.7 在每种配置中执行测试 93
    8.2.8 反复测试直到小组对结果满意为止 93
    8.3 获得硬件 93
    8.4 明确硬件标准 94
    8.5 对其他硬件进行配置测试 95
    8.6 小结 95
    8.7 小测验 95
    第9章 兼容性测试 96
    9.1 兼容性测试综述 96
    9.2 平台和应用程序版本 97
    9.2.1 向后和向前兼容 97
    9.2.2 测试多个版本的影响 98
    9.3 标准和规范 99
    9.3.1 高级标准和规范 99
    9.3.2 低级标准和规范 100
    9.4 数据共享兼容性 100
    9.5 小结 102
    9.6 小测验 102
    第10章 外国语言测试 103
    10.1 使文字和图片有意义 103
    10.2 翻译问题 104
    10.2.1 文本扩展 104
    10.2.2 ASCll、DBCS和Unicode 105
    10.2.3 热键和快捷键 105
    10.2.4 扩展字符 106
    10.2.5 字符计算 106
    10.2.6 从左向右和从右向左读 107
    10.2.7 图形中的文字 107
    10.2.8 让文本与代码脱离 107
    10.3 本地化问题 108
    10.3.1 内容 108
    10.3.2 数据格式 109
    10.4 配置和兼容性问题 110
    10.4.1 国外平台配置 110
    10.4.2 数据兼容性 111
    10.5 测试量有多大 112
    10.6 小结 113
    10.7 小测验 113
    第11章 易用性测试 114
    11.1 用户界面测试 114
    11.2 优秀UI由什么构成 115
    11.2.1 符合标准和规范 115
    11.2.2 直观 116
    11.2.3 一致 117
    11.2.4 灵活 117
    11.2.5 舒适 118
    11.2.6 正确 118
    11.2.7 实用 119
    11.3 为有残疾障碍的人员测试:辅助选项测试 119
    11.3.1 法律要求 120
    11.3.2 软件中的辅助特性 120
    11.4 小结 122
    11.5 小测验 122
    第12章 测试文档 123
    12.1 软件文档的类型 123
    12.2 文档测试的重要性 125
    12.3 审查文档时要找什么 126
    12.4 文档测试的实质 127
    12.5 小结 127
    12.6 小测验 127
    第13章 软件安全性测试 129
    13.1 战争游戏—电影 129
    13.2 了解动机 130
    13.3 威胁模式分析 131
    13.4 软件安全是一项功能吗?软件漏洞是一个缺陷吗 134
    13.5 了解缓冲区溢出 134
    13.6 使用安全的字符串函数 135
    13.7 计算机取证 137
    13.8 小结 139
    13.9 小测验 139
    第14章 网站测试 141
    14.1 网页基础 141
    14.2 黑盒测试 142
    14.2.1 文本 143
    14.2.2 超级链接 144
    14.2.3 图片 145
    14.2.4 表单 145
    14.2.5 对象和其他各种简单的功能 145
    14.3 灰盒测试 146
    14.4 白盒测试 147
    14.5 配置和兼容性测试 148
    14.6 易用性测试 149
    14.7 自动化测试简介 151
    14.8 小结 151
    14.9 小测验 151
    第四部分 测试的补充
    第15章 自动测试和测试工具 155
    15.1 工具和自动化的好处 155
    15.2 测试工具 156
    15.2.1 查看器和监视器 156
    15.2.2 驱动程序 157
    15.2.3 桩 158
    15.2.4 压力和负载工具 159
    15.2.5 干扰注入器和噪声发生器 159
    15.2.6 分析工具 160
    15.3 软件测试自动化 160
    15.3.1 宏录制和回放 161
    15.3.2 可编程的宏 162
    15.3.3 完全可编程的自动测试工具 163
    15.4 随机测试:猴子和大猩猩 164
    15.4.1 笨拙的猴子 165
    15.4.2 半聪明的猴子 166
    15.4.3 聪明的猴子 166
    15.5 使用测试工具和自动化的实质 168
    15.6 小结 168
    15.7 小测验 169
    第16章 缺陷轰炸和beta测试 170
    16.1 让别人测试你的软件 170
    16.2 测试共享 171
    16.3 beta测试 172
    16.4 外包测试 173
    16.5 小结 173
    16.6 小测验 174
    第五部分 使用测试文档
    第17章 计划测试工作 177
    17.1 测试计划的目标 177
    17.2 测试计划主题 178
    17.2.1 高级期望 178
    17.2.2 人、地点和事 179
    17.2.3 定义 179
    17.2.4 团队之间的责任 180
    17.2.5 哪些要测试,哪些不要测试 182
    17.2.6 测试的阶段 182
    17.2.7 测试策略 182
    17.2.8 资源需求 183
    17.2.9 测试员的任务分配 183
    17.2.10 测试进度 183
    17.2.11 测试用例 185
    17.2.12 软件缺陷报告 185
    17.2.13 度量和统计 185
    17.2.14 风险和问题 185
    17.3 小结 185
    17.4 小测验 186
    第18章 编写和跟踪测试用例 187
    18.1 测试用例计划的目标 187
    18.2 测试用例计划综述 188
    18.2.1 测试设计 189
    18.2.2 测试用例 191
    18.2.3 测试程序 192
    18.3 测试用例组织和跟踪 194
    18.4 小结 195
    18.5 小测验 195
    第19章 报告发现的问题 197
    19.1 设法修复软件缺陷 198
    19.2 分离和再现软件缺陷 200
    19.3 并非所有软件缺陷生来就是平等的 202
    19.4 软件缺陷的生命周期 203
    19.5 软件缺陷跟踪系统 205
    19.5.1 标准:测试事件报告 205
    19.5.2 手工软件缺陷报告和跟踪 206
    19.5.3 自动化软件缺陷报告和跟踪 206
    19.6 小结 210
    19.7 小测验 211
    第20章 成效评价 212
    20.1 使用软件缺陷跟踪数据库中的信息 212
    20.2 在日常测试中使用的度量 213
    20.3 常用项目级度量 216
    20.4 小结 220
    20.5 小测验 221
    第六部分 软件测试的未来
    第21章 软件质量保证 225
    21.1 质量是免费的 225
    21.2 工作现场的测试和质量保证 226
    21.2.1 软件测试 226
    21.2.2 质量保证 227
    21.2.3 软件测试团队的其他名称 228
    21.3 测试的管理和组织结构 228
    21.4 能力成熟度模型(CMM) 230
    21.5 IS0 9000 232
    21.6 小结 233
    21.7 小测验 233
    第22章 软件测试员的职业 234
    22.1 软件测试员的工作 234
    22.2 寻求软件测试职位 235
    22.3 获得亲身体验 236
    22.4 正规培训机会 237
    22.5 网站 237
    22.6 专注于软件和软件质量的专业组织 238
    22.7 更进一步阅读 238
    22.8 小结 239
    22.9 小测验 240
    附录A 小测验问题解答 241

    展开全文
  • 针对web系统的常用测试方法如下: 1. 页面链接检查: 每一个链接是否都有对应的页面,并且页面之间切换正确。可以使用一些工具,如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持...

    针对web系统的常用测试方法如下:

    1. 页面链接检查:

    每一个链接是否都有对应的页面,并且页面之间切换正确。可以使用一些工具,如LinkBotProFile-AIDCSHTML Link ValidaterXenu等工具。LinkBotPro不支持中文,中文字符显示为乱码;HTML Link Validater只能测试以Html或者htm结尾的网页链接;Xenu无需安装,支持aspdojsp等结尾的网页,xenu测试链接包括内部链接和外部链接,在使用的时候应该注意,同时能够生成html格式的测试报告。如果系统用QTP进行自动化测试,也可以使用QTP的页面检查点检查链接。

    2. 相关性检查:

    功能相关性:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确,常见的情况是,增加某个数据记录以后,如果该数据记录某个字段内容较长,可能会在查询的时候让数据列表变形。
    数据相关性:下来列表默认值检查,下来列表值检查,如果某个列表的数据项依赖于其他模块中的数据,同样需要检查,比如,某个数据如果被禁用了,可能在引用该数据项的列表中不可见。

    3. 检查按钮的功能是否正确:

    如新建、编辑、删除、关闭、返回、保存、导入,上一页,下一页,页面跳转,重置等功能是否正确。常见的错误会出现在重置按钮上,表现为功能失效。

    一些功能按钮等测试方法详细说明:

    1. 命令按钮测试

    测试方法:

     a,点击按钮正确响应操作。如,单击确定,正确执行操作;单击取消,退出窗口;

     b,对非法的输入或操作给出足够的提示说明,如,输入月工作天数为32时,单击确定后系统应提示:天数不能大于31

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

    1. 单选按钮的测试

    测试方法:

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

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

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

    1. 组合列表框的测试

    测试方法:

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

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

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

    1. 复选框的测试

    测试方法:

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

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

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

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

    1. 列表框控件的测试

    测试方法:

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

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

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

    1. 滚动条控件的测试

    要注意一下几点:

     a,滚动条的长度根据显示信息的长度或宽度及时变换,这样有利于用户了解显示信息的位置和百分比,如,word中浏览100页文档,浏览到50页时,滚动条位置应处于中间;

     b,拖动滚动条,检查屏幕刷新情况,并查看是否有乱码;

     c,单击滚动条;

     d,用滚轮控制滚动条;

     e,滚动条的上下按钮。

    1. 各种控件在窗体中混和使用时的测试

     a,控件间的相互作用;

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

     c,热键的使用,逐一测试;

     d,enter键和esc键的使用;

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

     

    4. 字符串长度检查: 

    输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。还要检查需求规定的字符串长度是否是正确的,有时候会出现,需求规定的字符串长度太短而无法输入业务数据。

    5. 字符类型检查: 

    在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。

    6. 标点符号检查: 

    输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理,可能添加的时候,将空格当作一个字符,而在查询的时候空格被屏蔽,导致无法查询到添加的内容。

    7.特殊字符检查:

    输入特殊符号,如@#$%!等,看系统处理是否正确。常见的错误是出现在% ‘ ” 这几个特殊字符

    8. 中文字符处理: 

    在可以输入中、英文的系统输入中文,看会否出现乱码或出错。

    9. 检查信息的完整性:

    在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。要注意检查的时候每个字段都应该检查,有时候,会出现部分字段更新了而个别字段没有更新的情况。

    10. 信息重复: 

    在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。

    11. 检查删除功能:

    在一些可以一次删除多个信息的地方,不选择任何信息,“delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除, 看是否正确处理。如果有多页,翻页选,看系统是否都正确删除,并且要注意,删除的时候是否有提示,让用户能够更正错误,不误删除。

    12. 检查添加和修改是否一致: 

    检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

    13. 检查修改重名:

    修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

    14. 重复提交表单:

    一条已经成功提交的纪录,返回后再提交,看看系统是否做了处理。对于Web系统来说,可以通过浏览器返回键或者系统提供的返回功能。

    15. 检查多次使用返回键的情况:

     在有返回键的地方,返回到原来页面,重复多次,看会否出错。

    16. 搜索检查: 

    有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确,搜索的时候同样要注意特殊字符,某些系统会在输入特殊字符的时候,将系统中所有的信息都搜索到。

    17. 输入信息位置: 

    注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。

    18. 上传下载文件检查:

    上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。下载文件能否打开或者保存,下载的文件是否有格式要求,如需要特殊工具才可以打开等。上传文件测试同时应该测试,如果将不能上传的文件后缀名修改为可以上传文件的后缀名,看是否能够上传成功,并且,上传文件后,重新修改,看上传的文件是否存在。

    19. 必填项检查:

    应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加“*”;对必填项提示返回后,焦点是否会自动定位到必填项。

    20. 快捷键检查:

    是否支持常用快捷键,如Ctrl+C Ctrl+V Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。

    21. 回车键检查: 

    在输入结束后直接按回车键,看系统处理如何,会否报错。这个地方很有可能会出现错误。

    22.刷新键检查:

    Web系统中,使用浏览器的刷新键,看系统处理如何,会否报错。

    23.回退键检查:

    Web系统中,使用浏览器的回退键,看系统处理如何,会否报错。对于需要用户验证的系统,在退出登录后,使用回退键,看系统处理如何;多次使用回退键,多次使用前进键,看系统如何处理。

    24.直接URL链接检查:

    Web系统中,直接输入各功能页面的URL地址,看系统如何处理,对于需要用户验证的系统更为重要。如果系统安全性设计的不好,直接输入各功能页面的URL地址,很有可能会正常打开页面。

    25.空格检查:

    在输入信息项中,输入一个或连串空格,查看系统如何处理。如对于要求输入整型、符点型变量的项中,输入空格,既不是空值,又不是标准输入。

    26.输入法半角全角检查:

    在输入信息项中,输入半角或全角的信息,查看系统如何处理。如对于要求输入符点型数据的项中,输入全角的小数点(,如4.5);输入全角的空格等。

    27.密码检查:

    一些系统的加密方法采用对字符Ascii码移位的方式,处理密码加密相对较为简单,且安全性较高,对于局域网系统来说,此种方式完全可以起到加密的作用,但同时,会造成一些问题,即大于128Ascii对应的字符在解密时无法解析,尝试使用“uvwxyz”等一些码值较大的字符作为密码,同时,密码尽可能的长,如17位密码等,造成加密后的密码出现无法解析的字符。

    28.用户检查:

    任何一个系统,都有各类不同的用户,同样具有一个或多个管理员用户,检查各个管理员之间是否可以相互管理,编辑、删除管理员用户。同时,对于一般用户,尝试删除,并重建同名的用户,检查该用户其它信息是否重现。同样,提供注销功能的系统,此用户再次注册时,是否作为一个新的用户。而且还要检查该用户的有效日期,过了有效日期的用户是不能登录系统的。容易出现错误的情况是,可能有用户管理权限的非超级管理员,能够修改超级管理员的权限。

    29.系统数据检查:

    这是功能测试最重要的,如果系统数据计算不正确,那么功能测试肯定是通不过的。数据检查根据不同的系统,方法不同对于业务管理平台,数据随业务过程、状态的变化保持正确,不能因为某个过程出现垃圾数据,也不能因为某个过程而丢失数据。

    30.系统可恢复性检查:

    以各种方式把系统搞瘫,测试系统是否可正常迅速恢复。

    31.确认提示检查:

    系统中的更新、删除操作,是否提示用户确认更新或删除,操作是否可以回退(即是否可以选择取消操作),提示信息是否准确。事前或事后提示,对于UpdateDelete操作,要求进行事前提示。

    32.数据注入检查:

    数据注入主要是对数据库的注入,通过输入一些特殊的字符,如“’”“/”“-”等或字符组合,完成对SQL语句的破坏,造成系统查询、插入、删除操作的SQL因为这些字符而改变原来的意图。如select * from table where id = ‘ ’ and name = ‘ ’,通过在id输入框中输入“12’-”,会造成查询语句把name条件注释掉,而只查询id=12的记录。同样,对于updatedelete的操作,可能会造成误删除数据。当然还有其它一些SQL注入方法,具体可以参考《SQL应用高级SQL注入.doc》,很多程序都是基于页面对输入字符进行控制的,可以尝试跳过界面直接向数据库中插入数据,比如用Jmeter,来完成数据注入检查。

    33.刷新检查:

    web系统中的WebForm. 控件实时刷新功能,在系统应用中有利有弊,给系统的性能带来较大的影响。测试过程中检测刷新功能对系统或应用造成的影响(白屏),检查控件是否回归默认初始值,检查是否对系统的性能产生较大影响(如每次刷新都连接数据库查询等)。

    34.事务检查:

    对于事务性操作,断开网络或关闭程序来中断操作,事务是否回滚。

    35.时间日期检查:

    时间、日期验证是每个系统都必须的,如2006-2-292006-6-31等错误日期,同时,对于管理、财务类系统,每年的1月与前一年的12月(同理,每年的第1季度与前一年的第4季度)。另外,对于日期、时间格式的验证,如2006228日、2006-2-2820060228等。日期检查还要检查日期范围是否符合实际的业务,对于不符合时间业务的日期,系统是否会有提示或者有限制。

    36.多浏览器验证:

    越来越多的各类浏览器的出现,用户访问Web程序不再单单依赖于Microsoft Internet Explorer,而是有了更多的选择:MaxthonFirefoxTencent Traveler等,考虑使用多种浏览器访问系统,验证效果。

    37.安装测试:

    对于C/S架构的系统,安装程序的测试是一个重要方面,安装程序自动化程度、安装选项和设置(验证各种方案是否都能正常安装)、安装过程中断测试、安装顺序测试(分布式系统)、修复安装及卸载测试。

    38.文档测试:

    主要是对用户使用手册、产品手册进行测试,校验是否描述正确、完整,是否与当前系统版本对照,是否易理解,是否二义性等。

    39.测试数据检查:

    事实告诉我们,测试数据比代码更有可能是错的,因此,当测试结果显示有错误发生的时候,怀疑代码错误前要先对测试数据检查一遍。

    40.请让我的机器来运行:

    在某些项目中,出现一个病态的问题:系统没有问题呀,它在我的机器上是能够通过的。这就说明了其中存在着和环境相关的BUG是否所有的一切都受到了版本控制工具的管理?本机的开发环境和服务器的环境是否一样?这里是否存在一个真正的BUG,只不过是在其他的机器里偶然出现?。所有的测试必须在所有系统要求的机器上运行通过,否则的话,代码就可能存在问题。

    41.Ajax技术的应用:

    Ajax有很多优点,但也有很多缺点,如果利用优点、避免缺点,是我们对新的Web2.0应用的一个挑战。而Ajax的应用最直接的问题就是用户体验,用户体验的效果直接关系到是否使用Ajax技术。会做,并不意味着应该做、必须做,这就是对Ajax技术的很重要的注解。

    42.Ajax技术的应用:

    Ajax采用异步调用的机制实现页面的部分刷新功能,异步调用存在异常中断的可能,尝试各种方法异常中断异步的数据调用,查看是否出现问题。在这里遇到的一个问题就是对日期控件的操作,已经如果页面数据较多的时候的刷新。

    43.脚本错误:

    随着AjaxIFrame等异步调用技术的发展,Javascrīpt技术也越来越受到开发人员的重视,但Javascrīpt存在调试困难、各浏览器存在可能不兼容等问题,因此在Web系统中对脚本的审查也是一个检测点

    展开全文
  • 作者: life0 发表日期: 2006-08-04 09:56 文章属性: 转1.... 软件测试中的基本词汇 7. 软件测试步骤 8.我想问到底软件测试的流程是什么? 9.请问Bug曲线是怎么会事? 10.负载测试与压力测试有何区别? 1

    作者: life0 发表日期: 2006-08-04 09:56 文章属性: 

    1.测试新手从何处入手  
    2.测试计划的前提是什么?  
    3.测试计划模版  
    4.单元测试,集成测试和系统测试  
    5.测试工具:  
    6. 软件测试中的基本词汇  
    7. 软件测试步骤  
    8.我想问到底软件测试的流程是什么?  
    9.请问Bug曲线是怎么会事?  
    10.负载测试与压力测试有何区别?  
    11.如何设计编制软件测试用例(一~三)  
    12.软件测试的14种类型  
    13.软件开发全过程检测及测试自动化  
    15.微软的测试题  
    16. 多线程与多进程  
    17.回归测试  
    18.测试大纲和测试计划  
    19.测试版本大全-转贴  
    20. 黑、白盒测试  
    21.Software Testing 10 Rules  
    1.测试新手从何处入手
    学习,努力学习,没有别的捷径的
    给大家提供一个我们的培训提纲,按照这些内容学吧
    8、 软件测试技术概论
    9、 测试管理
    10、系统测试计划和方案
    11、系统测试用例设计
    12、集成测试计划和方案
    13、集成测试用例设计
    14、单元测试计划和方案
    15、单元测试用例设计
    16、单元测试执行
    17、集成测试执行
    18、系统测试执行
    19、WEB项目测试专题
    20、C/S架构项目测试专题
    21、测试工程师职业素质
    当你刚被聘用到一个测试小组时,作为新手,可能你应该按别人指定的测试计划执行测试。这并不是说你没有能力制定这样的计划,而是别人制定的测试计划可能比你的好(这是一个公认的事实)。按别人的计划执行,并记下那些可以用不同方式完成的部分和优秀之处。用不了多久,你就有自己作主的权利了,最开始要从你负责组件的测试计划作起。充分利用你的笔记和经验,这有助于你在第一次就能够写出一个高效、专业的测试计划。
    当你在执行其他人的计划时,你可以考虑另外可尝试的测试用例。有一些可能不适用,但对于软件其他部分仍是好的测试用例,只是不是你负责的而已。不要低估自己作为测试人员的能力,要相信自己也能发现好的测试用例。
    制定测试计划时应该考虑可用的资源和需要组织涉及参与的活动。不管是低级别的计划还是高级别的计划,都需要详细地规定工作的责任人、各人的工作任务,以及任务完成的时间。没有经过彻底交流过的计划是不可能有效的。最无效的计划就是那些没人知道其存在的计划。
    2.测试计划的前提是什么?
    当然是项目计划,作为整个项目来说测试是一个非常重要的步骤,如果pm都没有这个意识,那么你的工作就没有立足的根本了。
    在了解了项目需求和开发计划后,你就可以根据项目开发时间来制定你的测试计划
    1.test plan 整个测试需要那些资源,时间安排,需要产生哪些文档
    2.test case 根据需求编写对应功能模块的测试案例,熟悉系统
    3.test report 对每一个完成的模块进行详尽的测试,完成test report
    4.bug 跟踪,并且进行数据统计和回归
    一般来说只要1个人跟一个项目,这些事情基本还是能够完成的,不敢说多高质量,但是比没有还是好得多
    3.测试计划模版
    a.
    “无忧测试”QQ整理——jzhao的测试计划

    感谢jzhao和大家分享!

    测试计划6月份--7月份

    制定人   开始时间   结束时间   测试阶段   修订  
      2004-06-21   2004-07-22          

    一、   测试类型及目标
    Win 32 Release 1.0:构建测试和集成测试
    a)   构建测试目标:
    正确实现需求特性;
    界面规范正确无误。
    b)   集成测试目标:
    正确实现本阶段的需求特性;
    界面规范正确无误;
    回归测试,对整个产品进行全面的测试
    国际化测试
    安装测试
    二、   测试策略
    l   使用测试用例。
    l   可以使用WinRunner测试工具,从而减少回归测试的工作量。
    l   使用Buggit作为缺陷管理工具,对缺陷进行分类管理,并且需要做出缺陷分析
    三、   资源安排

    B.这里给一份模板大家看看如何?

    1.简介   3
    1.1目的   3
    1.2背景   3
    1.3范围   3
    2.   测试参考文档和测试提交文档   3
    2.1测试参考文档   3
    2.2测试提交文档   3
    3.测试进度   3
    4.测试资源   3
    4.1人力资源   3
    4.2测试环境   3
    4.3测试工具   3
    5.系统风险、优先级   3
    6.测试策略   3
    6.1数据和数据库完整性测试   3
    6.2接口测试   3
    6.3集成测试   3
    6.4功能测试   3
    6.5用户界面测试   3
    6.6性能评测   3
    6.7负载测试   3
    6.8强度测试   3
    6.9容量测试   3
    6.10安全性和访问控制测试   3
    6.11故障转移和恢复测试   3
    6.12配置测试   3
    6.13安装测试   3
    7.问题严重度描述   3
    8.附录:项目任务   3


    1.   简介
    1.   1目的
    <项目名称>的这一“测试计划”文档有助于实现以下目标:

    [确定现有项目的信息和应测试的软件构件。
    列出推荐的测试需求(高级需求)。
    推荐可采用的测试策略,并对这些策略加以说明。
    确定所需的资源,并对测试的工作量进行估计。
    列出测试项目的可交付元素]
    1.   2背景
    [对测试对象(构件、应用程序、系统等)及其目标进行简要说明。需要包括的信息有:主要的功能和性能、测试对象的构架以及项目的简史。]
    1.3范围
    [描述测试的各个阶段(例如,单元测试、集成测试或系统测试),并说明本计划所针对的测试类型(如功能测试或性能测试)。
    简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
    如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施,则列出所有这些假设。
    列出可能会影响测试设计、开发或实施的所有风险或意外事件。
    列出可能会影响测试设计、开发或实施的所有约束。]


    2.   测试参考文档和测试提交文档
    2.1测试参考文档
    下表列出了制定测试计划时所使用的文档,并标明了各文档的可用性:
    [注:可适当地删除或添加文档项。]
    文档(版本/日期)   已创建或可用   已被接收或已经过复审   作者或来源   备注
    可行性分析报告   是□ 否□   是□ 否□      
    软件需求定义   是□ 否□   是□ 否□      
    软件系统分析(STD,DFD,CFD,DD)   是□ 否□   是□ 否□      
    软件概要设计   是□ 否□   是□ 否□      
    软件详细设计   是□ 否□   是□ 否□      
    软件测试需求   是□ 否□   是□ 否□      
    硬件可行性分析报告   是□ 否□   是□ 否□      
    硬件需求定义   是□ 否□   是□ 否□      
    硬件概要设计   是□ 否□   是□ 否□      
    硬件原理图设计   是□ 否□   是□ 否□      
    硬件结构设计(包含PCB)   是□ 否□   是□ 否□      
    FPGA设计   是□ 否□   是□ 否□      
    硬件测试需求   是□ 否□   是□ 否□      
    PCB设计   是□ 否□   是□ 否□      
    USB驱动设计   是□ 否□   是□ 否□      
    Tuner BSP 设计   是□ 否□   是□ 否□      
    MCU设计   是□ 否□   是□ 否□      
    模块开发手册   是□ 否□   是□ 否□      
    测试时间表及人员安排   是□ 否□   是□ 否□      
    测试计划   是□ 否□   是□ 否□      
    测试方案   是□ 否□   是□ 否□      
    测试报告   是□ 否□   是□ 否□      
    测试分析报告   是□ 否□   是□ 否□      
    用户操作手册   是□ 否□   是□ 否□      
    安装指南   是□ 否□   是□ 否□      
    2.2测试提交文档
    [下面应当列出在测试阶段结束后,所有可提交的文档]
    3.测试进度
    测试活动   计划开始日期   实际开始日期   结束日期
    制定测试计划          
    设计测试          
    集成测试          
    系统测试          
    性能测试          
    安装测试          
    用户验收测试          
    对测试进行评估          
    产品发布          


    4.测试资源
    4.1人力资源
    下表列出了在此项目的人员配备方面所作的各种假定。
    [注:可适当地删除或添加角色项。]
    角色   所推荐的最少资源(所分配的专职角色数量)   具体职责或注释
         
         
    4.2测试环境
    下表列出了测试的系统环境
    软件环境(相关软件、操作系统等)

    硬件环境(网络、设备等)


    4.3测试工具
    此项目将列出测试使用的工具:
    用途   工具   生产厂商/自产   版本


    5.系统风险、优先级
    [简要描述测试阶段的风险和处理的优先级]


    6.测试策略
    [测试策略提供了对测试对象进行测试的推荐方法。
    对于每种测试,都应提供测试说明,并解释其实施的原因。
    制定测试策略时所考虑的主要事项有:将要使用的技术以及判断测试何时完成的标准。
    下面列出了在进行每项测试时需考虑的事项,除此之外,测试还只应在安全的环境中使用已知的、有控制的数据库来执行。]
    注意:不实施某种测试,则应该用一句话加以说明,并陈述这样的理由。例如,“将不实施该测试。该测试本项目不适用”。
    6.1数据和数据库完整性测试
    [要<项目名称>中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统(DBMS),还需要进行深入的研究,以确定可以支持以下测试的工具和技术。]

    测试目标:   [确保数据库访问方法和进程正常运行,数据不会遭到损坏]
    测试范围:  
    技术:   [调用各个数据库访问方法和进程,并在其中填充有效的和无效的数据(或对数据的请求)。检查数据库,确保数据已按预期的方式填充,并且所有的数据库事件已正常发生;或者检查所返回的数据,确保正当的理由检索到了正确的数据]
    开始标准:  
    完成标准:   [所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭到损坏。]
    测试重点和优先级:  
    需考虑的特殊事项:   [测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。进程应该以手工方式调用。应使用小型或最小的数据库(记录的数量有限)来使所有无法接受的事件具有更大的可视度。]


    6.2接口测试
    测试目标   确保接口调用的正确性  
    测试范围:   所有软件、硬件接口,记录输入输出数据
    技术:  
    开始标准:  
    完成标准:  
    测试重点和优先级:  
    需考虑的特殊事项:   接口的限制条件


    6.3集成测试
    [集成测试―主要目的检测系统是否达到需求对业务流程及数据流的处理是否符合标准,检测系统对业务流处理是否存在逻辑不严谨及错误,检测需求是否存在不合理的标准及要求。此阶段测试基于功能完成的测试。]
    测试目标   检测需求中业务流程,数据流的正确性
    测试范围:   需求中明确的业务流程,或组合不同功能模块而形成一个大的功能。
    技术:   [利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。]
    开始标准:   在完成某个集成测试时必须达到标准
    完成标准:   [所计划的测试已全部执行。所发现的缺陷已全部解决。]
    测试重点和优先级:   测试重点指在测试过程中需着重测试的地方,优先级可以根据需求及严重来定
    需考虑的特殊事项:   [确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)]


    6.4功能测试
    [对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面(GUI)与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要:]

    测试目标   [确保测试的功能正常,其中包括导航,数据输入,处理和检索等功能。]
    测试范围:  
    技术:   [利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。]
    开始标准:  
    完成标准:  
    测试重点和优先级:  
    需考虑的特殊事项:   [确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)]


    6.5用户界面测试
    [用户界面(UI)测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI测试还可确保UI中的对象按照预期的方式运行,并符合公司或行业的标准。]

    测试目标   [核实以下内容:通过测试进行的浏览可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法(Tab键、鼠标移动、和快捷键)的使用窗口的对象和特征(例如,菜单、大小、位置、状态和中心)都符合标准。]
    测试范围:  
    技术:   [为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。]
    开始标准:  
    完成标准:   [成功地核实出各个窗口都与基准版本保持一致,或符合可接受标准]
    测试重点和优先级:  
    需考虑的特殊事项:   [并不是所有定制或第三方对象的特征都可访问。]


    6.6性能评测
    [性能评测是一种性能测试,它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件(例如工作量或硬件配置)的一种函数来进行评测和微调。
    注:以下所说的事务是指“逻辑业务事务”。这种事务被定义为将由系统的某个Actor通过使用测试对象来执行的特定用例,添加或修改给定的合同。]

    测试目标   [核实所指定的事务或业务功能在以下情况下的性能行为:正常的预期工作量预期的最繁重工作量]
    测试范围:  
    技术:   [使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务的迭代数量。脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基准),并在多个客户机(虚拟的或实际的客户机,请参见下面的“需要考虑的特殊事项”)上重复。]
    开始标准:  
    完成标准:   [单个事务或单个用户:在每个事务所预期时间范围内成功地完成测试脚本,没有发生任何故障。][多个事务或多个用户:在可接受的时间范围内成功地完成测试脚本,没有发生任何故障。]
    测试重点和优先级:  
    需考虑的特殊事项:   [综合的性能测试还包括在服务器上添加后台工作量。可采用多种方法来执行此操作,其中包括:直接将“事务强行分配到”服务器上,这通常以“结构化语言”(SQL)调用的形式来实现。通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)客户机。此负载可通过“远程终端仿真(Remote Terminal Emulation)工具来实现。此技术还可用于在网络中加载“流量”。使用多台实际客户机(每台客户机都运行测试脚本)在系统上添加负载。性能测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。]


    6.7负载测试
    [负载测试是一种性能测试。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。]
    [注:以下所说的事务是指“逻辑业务事务”。这各事务被定义为将由系统的某个最终用户通过使用应用程序来执行的特定功能,例如,添加或修改给定的合同。]

    测试目标   [核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。]
    测试范围:  
    技术:   [使用为功能或业务周期测试制定的测试。通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务发生的次数。]
    开始标准:  
    完成标准:   [多个事务或多个用户:在可接受的时间范围内成功地完成测试,没有发生任何故障。]
    测试重点和优先级:  
    需考虑的特殊事项:   [负载测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。]
    6.8强度测试
    [强度测试是一种性能测试,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。]
    [注:以下提到的事务都是指逻辑业务事务。]
    测试目标   [核实测试对象能够在以下强度条件下正常运行,不会出现任何错误:服务器上几乎没有或根本没有可用的内存(RAM和DASD)连接或模拟了最大实际(实际允许)数量的客户机多个用户对相同的数据或帐户执行相同的事务最繁重的事务量或最差的事务组合(请参见上面的“性能测试”)。注:强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的情况或条件。客户机的强度测试在“配置测试”的第3.1.11节中进行了说明。]
    测试范围:  
    技术:   [使用为性能评测或负载测试制定的测试。要对有限的资源进行测试,就应该在一台计算机上运行测试,而且应该减少或限制服务器上的RAM和DASD。对于其他强度测试,应该使用多台客户机来运行相同的测试或互补的测试,以产生最繁重的事务量或最差的事务组合。]
    开始标准:  
    完成标准:   [所计划的测试已全部执行,并且在达到或超出指定的系统限制时没有出现任何软件故障,或者导致系统出现故障条件的并不在指定的条件范围之内。]
    测试重点和优先级:  
    需考虑的特殊事项:   [如果要增加网络工作强度,可能会需要使用网络工具来给网络加载消息或信息包。应该暂时减少用于系统的DASD,以限制数据库可用空间的增长。使多个客户机对相同的记录或数据帐户同时进行的访问达到同步。]


    6.9容量测试
    [容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库。检验该软件是否正常运行并生成了正确的报表。]

    测试目标   [核实测试对象在以下高容量条件下能否正常运行:连接或模拟了最大(实际或实际允许)数量的客户机,所有客户机在长时间内执行相同的、且情况(性能)最坏的业务功能。已达到最大的数据库大小(实际的或按比例缩放的),而且同时执行多个查询或报表事务。]
    测试范围:  
    技术:   [使用为性能评测或负载测试制定的测试。应该使用多台客户机来运行相同的测试或互补的测试,以便在长时间内产生最繁重的事务量或最差的事务组合(请参见上面的“强度测试”)创建最大的数据库大小(实际的、按比例缩放的、或填充了代表性数据的数据库),并使用多台客户机在长时间内同时运行查询和报表事务。]
    开始标准:  
    完成标准:   [所计划的测试已全部执行,而且达到或超出指定的系统限制时没有出现任何软件故障。]
    测试重点和优先级:  
    需考虑的特殊事项:   [对于上述的高容量条件,哪个时间段是可以接受的时间?]


    6.10安全性和访问控制测试
    [安全性和访问控制测试侧重于安全性的两个关键方面:
    应用程序级别的安全性,包括对数据或业务功能的访问。
    系统级别的安全性,包括对系统的登录或远程访问。
    应用程序级别的安全性可确保:在预期的安全性情况下,Actor只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新帐户,但只有管理员才能删除这些数据或帐户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”看见同一客户的统计数据。
    系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。]
    测试目标   应用程序级别的安全性:[核实Actor只能访问其所属用户类型已被授权访问的那些功能或数据。]系统级别的安全性:[核实只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。]
    测试范围:  
    技术:   应用程序级别的安全性:[确定并列出各用户类型及其被授权访问的功能或数据。][为各用户类型创建测试,并通过创建各用户类型所特有的事务来核实其权限。]修改用户类型并为相同的用户重新运行测试。对于每种用户类型,确保正确地提供或拒绝了这些附加的功能或数据。系统级别的访问:[请参见以下的“需考虑的特殊事项”。]
    开始标准:  
    完成标准:   [各种已知的Actor类型都可访问相应的功能或数据,而且所有事务都按照预期的方式运行,并在先前的应用程序功能测试中运行了所有的事务。]
    测试重点和优先级:  
    需考虑的特殊事项:   [必须与相应的网络或系统管理员一直对系统访问权进行检查和讨论。由于此测试可能是网络管理可系统管理的职能,可能会不需要执行此测试。]


    6.11故障转移和恢复测试
    [故障转移和恢复测试可可确保测试对象能成功完成转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件可网络故障中恢复。
    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出(I/O)故障或无效的数据库指针和关键字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。]

    测试目标   [确保恢复进程(手工或自动)将数据库、应用程序和系统正确地恢复到预期的已知状态。测试中将包括以下各种情况:客户机断电服务器断电通过网络服务器产生的通信中断DASD和/或DASD控制器被中断、断电或与DASD和/或DASD控制器的通信中断周期未完成(数据过滤进程被中断,数据同步进程被中断)。数据库指针或关键字无效数据库中的数据元素无效或遭到破坏]
    测试范围:  
    技术:   [应该使用为功能和业务周期测试创建的测试来创建一系列的事务。一旦达到预期的测试起点,就应该分别执行或模拟以下操作:²   客户机断电:关闭PC机的电源。²   服务器断电:模拟或启动服务器的断电过程。²   通过网络服务器产生的中断:模拟或启动网络的通信中断(实际断开通信线路的连接或关闭网络服务器或路由器的电源)。²   DASD和DASD控制器被中断、断电或与DASD和DASD控制器的通信中断:模拟与一个或多个DASD控制器或设备的通信,或实际取消这种通信。²   一旦实现了上述情况(或模拟情况),就应该执行其他事务。而且一旦达到第二个测试点状态,就应调用恢复过程。²   在测试不完整的周期时,所使用的技术与上述技术相同,只不过应异常终止或提前终止数据库进程本身。²   对以下情况的测试需要达到一个已知的数据库状态。当破坏若干个数据库字段、指针和关键字时,应该以手工方式在数据库中(通过数据库工具)直接进行。其他事务应该通过使用“应用程序功能测试”和“业务周期测试”中的测试来执行,并且应执行完整的周期。]
    开始标准:  
    完成标准:   [在所有上述情况中,应用程序、数据库和系统应该在恢复过程完成时立即返回到一个已知的预期状态。此状态包括仅限于已知损坏的字段、指针或关键字范围内的数据损坏,以及表明进程或事务因中断面未被完成的报表。]
    测试重点和优先级:  
    需考虑的特殊事项:   ²   [恢复测试会给其他操作带来许多的麻烦。断开缆线连接的方法(模拟断电或通信中断)可能并不可取或不可行。所以,可能会需要采用其他方法,例如诊断性软件工具。²   需要系统(或计算机操作)、数据库和网络组中的资源。²   这些测试应该在工作时间之外或在一台独立的计算机上运行。]


    6.12配置测试
    [配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件 例如,应用程序、驱动程序等 而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。]

    测试目标   [核实测试可在所需的硬件和软件配置中正常运行。]
    测试范围:  
    技术:   ²   [使用功能测试脚本。²   在测试过程中或在测试开始之前,打开各种与非测试对象相关的软件(例如Microsoft应用程序:Excel和Word),然后将其关闭。²   执行所选的事务,以模拟Actor与测试对象软件和非测试对象软件之间的交互。²   重复上述步骤,尽量减少客户机工作站上的常规可用内存。]
    开始标准:  
    完成标准:   [对于测试对象软件和非测试对象软件的各种组合,所有事务都成功完成,没有出现任何故障。]
    测试重点和优先级:  
    需考虑的特殊事项:   ²   [需要、可以使用并可以通过桌面访问哪种非测试对象软件?²   通常使用的是哪些应用程序?²   应用程序正在运行什么数据?例如,在Excel中打开的大型电子表格,或是在Word中打开的100页文档。²   作为此测试的一部分,应将整修系统、Netware、网络服务器、数据库等都记录下来。]


    6.13安装测试
    [安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下 例如,进行首次安装、升级、完整的或自定义的安装 都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。]
    测试目标   核实在以下情况下,测试对象可正确地安装到各种所需的硬件配置中:²   首次安装。以前从未安装过<项目名称>的新计算机²   更新。以前安装过相同版本的<项目名称>的计算机²   更新。以前安装过<Project Name>的较早版本的计算机
    测试范围:  
    技术:   ²   [手工开发脚本或开发自动脚本,以验证目标计算机的状况 首次安装<项目名称>从未安装过;<项目名称>安装过相同或较早的版本。²   启动或执行安装。²   使用预先确定的功能测试脚本子集来运行事务。]
    开始标准:  
    完成标准:   <项目名称>事务成功执行,没有出现任何故障。
    测试重点和优先级:  
    需考虑的特殊事项:   [应该选择<项目名称>的哪些事务才能准确地测试出<项目名称>应用程序已经成功安装,而且没有遗漏主要的软件构件?。]


    7.问题严重度描述
    问题严重度   描述   响应时间
    高   例如使系统崩溃   程序员在多长时间内改正此问题
    中      
    低      
         
         
    8.附录:项目任务
    以下是一些与测试有关的任务:
    ²     制定测试计划
    n   确定测试需求
    n   评估风险
    n   制定测试策略
    n   确定测试资源
    n   创建时间表
    n   生成测试计划
    ²   设计测试
    n   准备工作量分析文档
    n   确定并说明测试用例
    n   确定测试过程,并建立测试过程的结构
    ²   复审和评估测试覆盖
    ²   实施测试
    n   记录或通过编程创建测试脚本
    n   确定设计与实施模型中的测试专用功能
    n   建立外部数据集
    ²   执行测试
    ²   执行测试过程
    ²   评估测试的执行情况
    ²   恢复暂停的测试
    ²   核实结果
    ²   调查意外结果
    ²   记录缺陷
    ²   对测试进行评估
    ²   评估测试用例覆盖
    ²   评估代码覆盖
    ²   分析缺陷
    ²   确定是否达到了测试完成标准与成功标准

    评论:单元测试/测试环境/过于复杂可针对公司不同情况精简/一个太简单,一个太复杂了,就要靠自己扩充和提炼了
    4.单元测试,集成测试和系统测试
    单元测试关注软件单元内部的逻辑结构和控制流程;
    集成测试关注软件模块之间的接口和模块集成后整体功能的实现;
    系统测试完全不考虑软件内部结构,只从需求出发进行验证。
    评论:
    单元测试应该是程序员自己做比较好。其他的测试应该以测试工程师为主,程序员、用户配合,这样效果比较好个人意见啊/很多不同意这个观点

    5.测试工具:
    winRunner ,Loadrunner, Rational等测试工具

    6. 软件测试中的基本词汇

    软件测试中的基本词汇
    ü     黑盒测试 (Black box testing) ── 不考虑内部设计和代码,根据需求和功能进行测试。

    ü     白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑,按照代码的语句、分支、路径和条件进行测试。

    ü     功能测试 (functional testing) ── 对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。(这一原则适用于所有的测试阶段。)

    ü     系统测试 ── 针对全部需求说明进行黑盒测试,包括系统中所有的部件。

    ü     端到端测试 (end-to-end testing) ── 类似于系统测试,但测试范围更“宏观”一些。模仿实际应用环境,对整个应用软件进行使用测试。例如与数据库进行交互作业、使用网络通信、与其他硬件、应用程序和系统之间的相互作用是否满足要求。

    ü     回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化,都重复进行测试。很难说需要进行多少次回归测试,特别是是到了开发周期的最后阶段。进行此种测试,特别适于使用自动测试工具。

    ü     负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况,以确定在什么情况下系统响应速度下降或是出现故障。

    ü     压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况:在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询,等等。

    ü     性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。

    ü     可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉,取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。

    ü     恢复测试 (recovery testing) ── 在系统崩溃、硬件故障、或者其他灾难发生之后,重新恢复系统的情况。

    ü     安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。

    ü     α 测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。

    ü   β 测试 (beta testing) ── 当开发和测试已基本完成,需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。
    ST系统测试
    IT集成测试
    UT单元测试
    SRS软件需求规格说明书
    HLD概要设计
    LLD详细设计
    CMO配置管理员
    RC需求变更
    REVIEW评审
    Alpha和Beta测试简介

    大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试,目的是从实际终端用户的使用角度,对软件的功能和性能进行测试,以发现可能只有最终用户才能发现的错误。

    Alpha测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。

    Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。因而,Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中,由用户记下遇到的所有问题,包括真实的以及主管认定的,定期向开发者报告,开发者在综合用户的报告后,做出修改,最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性,包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后,才能开始Beta测试。由于Beta测试的主要目标是测试可支持性,所以Beta测试应该尽可能由主持产品发行的人员来管理。

    由于Alpha和Beta测试的组织难度大,测试费用高,测试的随机性强、测试周期跨度较长,测试质量和测试效率难于保证,所以,很多专业软件可能不再进行Beta测试。随着测试技术的提高,以及专业测试服务机构的大量涌现,很多软件的Beta测试外包给这些专业测试机构进行测试。

    7. 软件测试步骤

    软件测试步骤
    •   测试过程按4个步骤进行,即单元测试、集成测试、确认测试和系统测试及发版测试。
    •   开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。
    •   集成测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。
    •   确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。
    •   系统测试把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。
    单元测试 (Unit Testing)
    •   单元测试又称模块测试,是针对软件设计的最小单位 ─ 程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
    •   单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
    1. 单元测试的内容
    •   在单元测试时,测试者需要依据详细设计说明书和源程序清单,了解该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理的输入和不合理的输入,都能鉴别和响应。
    (1) 模块接口测试
    •   在单元测试的开始,应对通过被测模块的数据流进行测试。测试项目包括:
    –   调用本模块的输入参数是否正确;
    –   本模块调用子模块时输入给子模块的参数是否正确;
    –   全局量的定义在各模块中是否一致;
    •   在做内外存交换时要考虑:
    –   文件属性是否正确;
    –   OPEN与CLOSE语句是否正确;
    –   缓冲区容量与记录长度是否匹配;
    –   在进行读写操作之前是否打开了文件;
    –   在结束文件处理时是否关闭了文件;
    –   正文书写/输入错误,
    –   I/O错误是否检查并做了处理。


    (2) 局部数据结构测试
    •   不正确或不一致的数据类型说明
    •   使用尚未赋值或尚未初始化的变量
    •   错误的初始值或错误的缺省值
    •   变量名拼写错或书写错
    •   不一致的数据类型
    •   全局数据对模块的影响
    (3) 路径测试
    •   选择适当的测试用例,对模块中重要的执行路径进行测试。
    •   应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
    •   对基本执行路径和循环进行测试可以发现大量的路径错误。
    (4) 错误处理测试
    •   出错的描述是否难以理解
    •   出错的描述是否能够对错误定位
    •   显示的错误与实际的错误是否相符
    •   对错误条件的处理正确与否
    •   在对错误进行处理之前,错误条件是否已经引起系统的干预等
    (5) 边界测试
    •   注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例,认真加以测试。
    •   如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素。





    2. 单元测试的步骤
    •   模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块。
    –   驱动模块 (driver)
    –   桩模块 (stub) ── 存根模块




    •   如果一个模块要完成多种功能,可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作,对关键模块还要做性能测试。
    •   对支持某些标准规程的程序,更要着手进行互联测试。有人把这种情况特别称为模块测试,以区别单元测试。
    集成测试(Integrated Testing)
    •   集成测试 (集成测试、联合测试)
    •   通常,在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是:
    –   在把各个模块连接起来的时侯,穿越模块接口的数据是否会丢失;
    –   一个模块的功能是否会对另一个模块的功能产生不利的影响;



    –   各个子功能组合起来,能否达到预期要求的父功能;
    –   全局数据结构是否有问题;
    –   单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。
    在单元测试的同时可进行集成测试,
    发现并排除在模块连接中可能出现
    的问题,最终构成要求的软件系统。





    •   子系统的集成测试特别称为部件测试,它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
    •   通常,把模块集成成为系统的方式有两种
    –   一次性集成方式
    –   增殖式集成方式


    1. 一次性集成方式(big bang)
    •   它是一种非增殖式组装方式。也叫做整体拼装。
    •   使用这种方式,首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统。

    2. 增殖式集成方式
    •   这种集成方式又称渐增式集成
    •   首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统
    •   在集成的过程中边连接边测试,以发现连接过程中产生的问题
    •   通过增殖逐步组装成为要求的软件系统。


    (1) 自顶向下的增殖方式
    •   这种集成方式将模块按系统程序结构,沿控制层次自顶向下进行组装。
    •   自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
    •   选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能。

    (2) 自底向上的增殖方式
    •   这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
    •   因为模块是自底向上进行组装,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。



    •   自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
    •   一般来讲,一种方式的优点是另一种方式的缺点。
    (3) 混合增殖式测试
    •   衍变的自顶向下的增殖测试
    –   首先对输入/输出模块和引入新算法模块进行测试;
    –   再自底向上组装成为功能相当完整且相对独立的子系统;
    –   然后由主模块开始自顶向下进行增殖测试。

    •   自底向上-自顶向下的增殖测试
    –   首先对含读操作的子系统自底向上直至根结点模块进行组装和测试;
    –   然后对含写操作的子系统做自顶向下的组装与测试。
    •   回归测试
    –   这种方式采取自顶向下的方式测试被修改的模块及其子模块;
    –   然后将这一部分视为子系统,再自底向上测试。
    关键模块问题
    •   在组装测试时,应当确定关键模块,对这些关键模块及早进行测试。
    •   关键模块的特征:
    ① 满足某些软件需求;
    ② 在程序的模块结构中位于较高的层次(高层控制模块);
    ③ 较复杂、较易发生错误;
    ④ 有明确定义的性能要求。


    确认测试(Validation Testing)
    •   确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
    •   对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。

    1. 进行有效性测试(黑盒测试)
    •   有效性测试是在模拟的环境 (可能就是开发的环境) 下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书列出的需求。
    •   首先制定测试计划,规定要做测试的种类。还需要制定一组测试步骤,描述具体的测试用例。

    •   通过实施预定的测试计划和测试步骤,确定
    –   软件的特性是否与需求相符;
    –   所有的文档都是正确且便于使用;
    –   同时,对其它软件需求,例如可移植性、兼容性、出错自动恢复、可维护性等,也都要进行测试

    •   在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类:
    –   测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而这部分程序被接受。
    –   测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。


    2. 软件配置复查
    n   软件配置复查的目的是保证
    u 软件配置的所有成分都齐全;
    u 各方面的质量都符合要求;
    u 具有维护阶段所必需的细节;
    u 而且已经编排好分类的目录。
    n 应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查这些文档资料的完整性和正确性。
    验收测试(Acceptance Testing)
    •   在通过了系统的有效性测试及软件配置审查之后,就应开始系统的验收测试。
    •   验收测试是以用户为主的测试。软件开发人员和QA(质量保证)人员也应参加。
    •   由用户参加设计测试用例,使用生产中的实际数据进行测试。

    •   在测试过程中,除了考虑软件的功能和性能外,还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
    •   确认测试应交付的文档有:
    –   确认测试分析报告
    –   最终的用户手册和操作手册
    –   项目开发总结报告。


    系统测试(System Testing)
    •   系统测试,是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。
    •   系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。
    α测试和β测试
    •   在软件交付使用之后,用户将如何实际使用程序,对于开发者来说是无法预测的。
    •   α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。

    •   α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。
    •   α测试可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。



    •   β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。
    •   测试时,开发者通常不在测试现场。因而,β测试是在开发者无法控制的环境下进行的软件现场应用。
    •   在β测试中,由用户记下遇到的所有问题,包括真实的以及主观认定的,定期向开发者报告。

    •   β测试主要衡量产品的FLURPS。着重于产品的支持性,包括文档、客户培训和支持产品生产能力。
    •   只有当α测试达到一定的可靠程度时,才能开始β测试。它处在整个测试的最后阶段。同时,产品的所有手册文本也应该在此阶段完全定稿。
    测试类型
    •   软件测试是由一系列不同的测试组成。主要目的是对以计算机为基础的系统进行充分的测试。
    功能测试
    功能测试是在规定的一段时间内运行软件系统的所有功能,以验证这个软件系统有无严重错误。

    强度测试

    强度测试是要检查在系统运行环境不正常乃至发生故障的情况下,系统可以运行到何种程度的测试。例如:
    –   把输入数据速率提高一个数量级,确定输入功能将如何响应。
    –   设计需要占用最大存储量或其它资源的测试用例进行测试。



    –   设计出在虚拟存储管理机制中引起“颠簸”的测试用例进行测试。
    –   设计出会对磁盘常驻内存的数据过度访问的测试用例进行测试。
    •   强度测试的一个变种就是敏感性测试。在程序有效数据界限内一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现,或者导致极度的性能下降的情况发生。此测试用以发现可能引起这种不稳定性或不正常处理的某些数据组合。



    性能测试
    •   性能测试是要检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。
    •   性能测试常常需要与强度测试结合起来进行,并常常要求同时进行硬件和软件检测。
    •   通常,对软件性能的检测表现在以下几个方面:响应时间、吞吐量、辅助存储区,例如缓冲区,工作区的大小等、处理精度,等等。

    恢复测试
    恢复测试是要证实在克服硬件故障(包括掉电、硬件或网络出错等)后,系统能否正常地继续进行工作,并不对系统造成任何损害。
    •   为此,可采用各种人工干预的手段,模拟硬件故障,故意造成软件出错。并由此检查:
    –   错误探测功能──系统能否发现硬件失效与故障;

    –   能否切换或启动备用的硬件;
    –   在故障发生时能否保护正在运行的作业和系统状态;
    –   在系统恢复后能否从最后记录下来的无错误状态开始继续执行作业,等等。
    –   掉电测试:其目的是测试软件系统在发生电源中断时能否保护当时的状态且不毁坏数据,然后在电源恢复时从保留的断点处重新进行操作。



    配置测试

    •   这类测试是要检查计算机系统内各个设备或各种资源之间的相互联结和功能分配中的错误。
    •   它主要包括以下几种:
    –   配置命令测试:验证全部配置命令的可操作性(有效性);特别对最大配置和最小配置要进行测试。软件配置和硬件配置都要测试。



    –   循环配置测试:证明对每个设备物理与逻辑的,逻辑与功能的每次循环置换配置都能正常工作。
    –   修复测试:检查每种配置状态及哪个设备是坏的。并用自动的或手工的方式进行配置状态间的转换。

    安全性测试
    安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用,有无漏洞。
    •   力图破坏系统的保护机构以进入系统的主要方法有以下几种:
    –   正面攻击或从侧面、背面攻击系统中易受损坏的那些部分;
    –   以系统输入为突破口,利用输入的容错性进行正面攻击;



    –   申请和占用过多的资源压垮系统,以破坏安全措施,从而进入系统;
    –   故意使系统出错,利用系统恢复的过程,窃取用户口令及其它有用的信息;
    –   通过浏览残留在计算机各种资源中的垃圾(无用信息),以获取如口令,安全码,译码关键字等信息;
    –   浏览全局数据,期望从中找到进入系统的关键字;
    –   浏览那些逻辑上不存在,但物理上还存在的各种记录和资料等。

    可使用性测试

    •   可使用性测试主要从使用的合理性和方便性等角度对软件系统进行检查,发现人为因素或使用上的问题。
    •   要保证在足够详细的程度下,用户界面便于使用;对输入量可容错、响应时间和响应方式合理可行、输出信息有意义、正确并前后一致;出错信息能够引导用户去解决问题;软件文档全面、正规、确切。

    安装测试
    安装测试的目的不是找软件错误,而是找安装错误。
    •   在安装软件系统时,会有多种选择。
    –   要分配和装入文件与程序库
    –   布置适用的硬件配置
    –   进行程序的联结。
    •   而安装测试就是要找出在这些安装过程中出现的错误。


    •   安装测试是在系统安装之后进行测试。它要检验:
    –   用户选择的一套任选方案是否相容;
    –   系统的每一部分是否都齐全;
    –   所有文件是否都已产生并确有所需要的内容;
    –   硬件的配置是否合理,等等。



    容量测试

    •   容量测试是要检验系统的能力最高能达到什么程度。例如,
    –   对于编译程序,让它处理特别长的源程序;
    –   对于操作系统,让它的作业队列“满员”;
    –   对于信息检索系统,让它使用频率达到最大。
    在使系统的全部资源达到“满负荷”的情形下,测试系统的承受能力。



    文档测试

    这种测试是检查用户文档(如用户手册)的清晰性和精确性。
    •   用户文档中所使用的例子必须在测试中一一试过,确保叙述正确无误。

    自动测试
    •   认识自动测试
    •   什么时候使用自动测试

    8.我想问到底软件测试的流程是什么?
    具体情况具体定,大体上是:
    测试计划-测试设计-测试用例-测试执行-测试报告。
    有些人把设计和用例放在一起,有些公司是讲test case 积累,下个项目可以继续累加,增加了覆盖率。
    测试开发包括测试用例的实现/测试代码的编写等等;测试设计实现测试方案的写作

    《面向对象的软件测试》,作者 John D.McGregor

    整个测试过程来说比较复杂,在这只说一下系统测试阶段的流程,首先是开发人员的需求分析阶段,在需求分析的同时,测试人员可以提出 可测试性需求,然后需求分析初步定搞后,测试人员可以参加需求评审,当需求经过评审纳入到配置库中后,测试人员就可以开始写测试计划了,测试计划主要是规划这次测试活动,角度是从管理方面,测试计划一般都有模版,然后在根据测试计划以及需求规格说明书来写测试方案,测试方案是从技术的角度来规划本次测试活动,有了方案了我们就可以根据它和SRS来写测试用例(这些都是有模版的),测试用例是最重要的!!测试用例写好了就可以进行测试的执行了,在这些过程中都会产生一些文挡,这些文档一般是需要经过评审的。当所有的测试用例都执行完了并且相关的测试文挡都通过了评审的话,那么本次测试活动就可以结束了。。。。

    测试流程
    转眼间来了公司一个多月了,工作时间应该算是很短的了,但是测试部门就我和勇斌两个人,我还算长的了,呵呵。由于以前公司没有测试人员,所以测试流程很不完善,估计大家对测试也不是很了解。以下是我个人的一些看法。
    测试部门的职责:
    今年的主要目标有三个,
     第一个是严格把关产品质量,所谓严格并不意味着测试会在软件项目和用户不需要的前提下,建立不合理和难以实现的质量目标。而是会进一步完善我们的现有的测试规范,严格按照规范办事。比如说,问题单改到%之多少才可以提交测试版本等等,这一点希望各位项目经理和开发人员能够理解。 如果改一个问题就出一个版本的话,我们的测试很难做的。这只是一个目标,呵呵.
     第二个要达到的目标是提供及时的测试服务,因为我们测试需要承担公司内所有项目的测试工作,而目前测试部人员缺少(就两个人),在有些情况下,开发已经完成编码工作,测试部由于人员等情况,我们可能将测试执行工作或是文档工作推后。在今后我们会尽量克服这个问题,做到能及时进行测试分析、及时执行测试、及提时提交问题单、及提交测试报告、及时编写测试用例。
     第三个目标是提高我们测试的服务水平
      因为现在需要测试公司内的所有项目,为了更好的达到测试的目标,测试必须设法适用于我们所面对的所有项目,这样对测试人员的水平也是一个挑战(怎样部署不同的项目的测试环境、怎样对于不同的操作系统下的项目进行测试,)这些都是我们有待提高的技术;另外现在公司的同事们对测试人员已非常尊重,这一点很好,其实测试与开发一样都同一个目标就是做好每一个项目,这些也是我们今后努力的目标。
    测试流程的定义:
    首先向大家介绍一下我理解的测试流程是什么,流程在词典上的解释是“工艺程序,从原料到制成品的各项工序安排的程序”,那测试流程就是指从软件测试开始到软件测试结束经过的一系列准备、执行、分析的过程。所以我认为测试流程并不是只存在于有完整测试团队的公司,它分布在每一个对软件执行测试的公司中,哪怕像我们这样的只有一两个测试人员的公司。
    下边是我根据咱们 公司做的一个关于bug管理的描述(公司内暂时没有bug管理工具,我正在寻找比较好的免费工具)
      测试人员(Tester)只要发现问题就立即新建一个Bug予以跟踪并发送给相关的开发小组长(Dev Lead)现在主要是通过excel表格来发送,,不好控制和管理,
    开发小组长会判断这个Bug属于某个特定的开发人员(Dev)并指派给他处理
    开发人员会根据Bug的详细描述信息找到问题所在,修改程序解决这个Bug并把Bug返回给当初的测试人员;希望开发发送给我们版本的时候,把以前的测试报告也发送给我们,最好注明那些问题已经修改,怎么修改的。那些问题依然存在。那些问题存在争议,争议的焦点。(备注:存在争议如何处理,)
    测试人员在看到某个Bug被解决后,就去验证这个Bug是否真的不存在了,根据最初的发现步骤去证实问题真的解决了就关闭这个Bug;若还能重现,或者不同意开发人员的解法,可以激活这个Bug,返还给当初的开发人员做进一步调查处理.
    下边的这些是我自己思考的一些问题:
    各个项目的需求,项目的完成时间,计划安排。我希望能够让我们了解更多的关于产品的信息,如果我们什么也不知道就拿一个产品进行测试,这样很难发现一些问题,甚至是一些表面的问题。我们知道了项目的安排和计划,便于我们能够合理的安排测试。
    当一个新的版本出现时,必须标明是哪个版本,修改了那些问题 。这样我们可以进行有针对性地测试。
    开发大概多长时间出一个版本,有些问题越到最后越麻烦。我希望我们能够及时地拿到版本,不要很长时间才测试一次,有些问题越到最后越难管理。
    编写测试用例。我正在考虑我们是不是需要编写一些简单的测试用例。
    这个问题是我们自己思考的,希望大家给点意见的。
    就是测试,什么叫测试完毕呢。
    我的理解就是首先你的按照正常的操作步骤,把所有的路径走一遍。我的正常的操作步骤就是客户肯定会用到的,经常用到的。然后再进行一些自由的测试,把自己能够想到的都测试一遍。

    9.请问Bug曲线是怎么会事?

    Bug曲线具体是如何定义的?

    是怎么制作出来的?

    意义是什么?

    它能反映出那些问题?(
    1)偶是这样认为的:
    从测试开始,bug被不断发现,那么这些bug与测试的日期等都有对应的关系,可以通过bug管理工具进行绘图,绘好就很容易看出bug随测试时间的变化趋势,不同的绘图方式,还能体现出什么类型的、什么级别,那个功能,谁负责的部份,由于什么原因等bug的趋势情况,这样就可以有针对性的加强那个部分,比如:bug图随着项目的逐步稳定,显示开发员A模块中的bug不断增加,没有任何递减的趋势,而其它相关开发员的模块bug不断下降,这时就要研究一下A开发员的工作了,是什么原因造成的,还是个人编码习惯等问题喽。。又比如:通过整体bug走势,可以一定程度上预测产品会达标的大概日期,因为bug曲线终归要近似趋零或达到可允许的范围(严重级别与个数)
    -在TD中可以绘制bug图附件中(有两幅刚截的参考图)
    -在testtrack中也可以.(我只发现表格形式的)

    2)严格来说,一个项目过程中的BUG走向应该是符合一定规律的,但由于我们外部条件和内部条件的因素,导致我们的曲线与书上所介绍的曲线有很大差异。
    3)大家应该更加注重的是这个曲线有何实际意义,对于测试、开发、以及成本等有何影响,就目前的测试的环境来看,研究这个曲线意义不大。测试人员可能还管不了那许多,还有即使有权力干涉开发人员的工作,但这也不能说明什么问题,反而招来非议,程序的编写主观性与客观性都存在,从这个曲线中不能反应任何关于开发人员的问题。对开发人员的评价自有另外的方法。而这个曲线的不正常,也可能与测试人员有关,很难保证所有测试人员一直都能保持一个正常的发挥其测试能力。

    一句话:这个曲线中看不中用!最多只能直观的说明某阶段发现了多少BUG。其它什么都说明不了。
    4)我是这么看的,
    BUG曲线纵轴是Bug数,而横轴根据你自己的定义,可以产生好多种类的曲线图,你可以将横轴定义为时间,或定义为人力资源,或定义为用例数等等,根据横轴定义的不同可以产生好多Bug曲线图.就看你怎么定义,怎么发明了.当然,你的定义肯定对你以后的度量工作产生积极的意义,那你的"发明"也真正有意义和作用
    5)如果你们的测试部门绝对独立,过程绝对严格,那这个曲线很能反映情况,否则。。。
    6)Bug 的曲线有很多种,就拿ClearQuest中来说,你可以根据自己的需要进行定制
    一般我用的比较多的有下面几种:
    新Bug的产生曲线:主要看每天新增bug的情况,理想情况应该是开始的时候不是很多,然后很快达到高峰,急剧减少,但是中间会有小的波动,这样的曲线是比较理想的
    系统中总的Bug曲线:这个是去掉解决完的bug的图,理想的情况和尚一个差不多,只是减少的会慢一点,波动也会大一些
    Bug的修复趋势:这个土我一般拿系统中的新增Bug,当天Close的bug放在一起看
    当然还有其它很多的图,我们会根据需要进行设定。其实我的意思就是大家不要拘泥于别人的形式,要根据自己的情况来做。
    我们这里每天一个项目大概每个人能报到7-10个bug,算是挺多了。
    CQ的功能很强大,可以定制各种反应软件不同指标的表格或者曲线。至于说到如何考核的问题,也是不能依葫芦画瓢。不同的公司,不同的系统架构,不同的企业文化,对考核的指标都会有不同的看法。
    Bug的修复率本身这个指标在不同的时期,我想期望值应该不同。而且这些指标并不能反映项目的好坏,就像我们公司现在实行SQA一样,稽核没有抓住实质的东西,没有细致的曲分析,相当于是为了稽核而稽核,就失去了意义了。每次老总问他们,这个项目的异常点这么多,是不是这个项目就是做的不好?他们总是回答不出。
    我建议你可以拿以前做的一个较好的项目,统计一下它的各项指标,然后可以把这些作为一个参考值,在后面的项目中发现这个指标不合理就及时调整。

    尽信书则不如无书,很多软件测试的专业资料上的指标是一种很理想的指标,或者是很成熟的公司,体制下的指标,我们如果生搬硬套,会很痛苦。
    10.负载测试与压力测试有何区别?
    1)压力测试是在一定的负荷条件下,长时间连续运行系统给系统性能造成的影响。
    负载测试:在一定的工作负荷下,给系统造成的负荷及系统响应的时间。
    从概念上区别他们,可以看出压力测试有个长时间运行,而负载测试负载类型可能是其他类型的。
    压力测试主要是为了发现在一(任意)定条件下软件系统的性能的变化情况。通过改变应用程序的输入以对应用程序施加越来越大的负载(并发,循环操作,多用户)并测量在这些不同的输入时性能的改变,也就是通常说的概念:压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。其实这种测试也可以称为负载测试,但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。
    比如实际中我们说从比较小的负载开始,逐渐增加模拟用户的数量, 直到应用程序响应时间超时,就是说的负载测试。
    2)负载测试更多的是在正常的工作条件下,验证系统的容量是否达到要求
    例如,一个服务器,能支持10万人同时访问,那么负载测试就是要测出在用户为10万人时,服务器是否还在正常工作的状态下,例如CPU的占用,内存的占用等。
    压力测试呢一般指在超过正常负载的情况下系统的能力,例如CPU占用正常工作应该低于50%,那么如果在一定的负载下,CPU的占用率达到80%,甚至100%,那么整个系统是否还能工作,而不是down机。还有,压力测试还应该包括在大负载下的异常处理能力。
    3)负载测试主要测试在给定的负载情况下,检测系统是否达到系统预期的性能目标。
    压力测试主要是在通过系统给定的预期的性能目标情况下,在逐渐给系统进行加压,测试系统在什么样的情况下,系统会产生异常。
    4)简单总结一下:
    压力:长时间连续运行,增加超负荷(并发,循环操作,多用户),什么时候系统会产生异常,以及异常处理能力,验证系统可靠性,找出瓶颈所在。
    负载:一个很短时间内,处理一个巨大的数据量或执行许多功能调用上的能力,验证系统预期的性能目标,响应时间等。
    11.如何设计编制软件测试用例(一~三)
    这是我们公司的培训资料,我看文件的保密级是大众级,发上来应该没事,希望对大家有点帮助,特别是新人.
    一、测试用例是软件测试的核心
    软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

    影响软件测试的因素很多,例如软件本身的复杂程度、开发人员(包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等等。因为有些因素是客观存在的,无法避免。有些因素则是波动的、不稳定的,例如开发队伍是流动的,有经验的走了,新人不断补充进来;一个具体的人工作也受情绪等影响,等等。如何保障软件测试质量的稳定?有了测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全,随着测试的进行和软件版本更新,也将日趋完善。

    因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导,是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。

    二、什么叫测试用例
    测试用例(Test Case)目前没有经典的定义。比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。

    不同类别的软件,测试用例是不同的。不同于诸如系统、工具、控制、游戏软件,管理软件的用户需求更加不统一,变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

    三、编制测试用例
    着重介绍一些编制测试用例的具体做法。

    1、测试用例文档
    编写测试用例文档应有文档模板,须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
    软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位,形成一个测试用例文档,但并不是绝对的。

    测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息:用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。以上内容涵盖了测试用例的基本元素:测试索引,测试环境,测试输入,测试操作,预期结果,评价标准。
    如何设计编制软件测试用例(二)

    2、测试用例的设置
    我们早期的测试用例是按功能设置用例。后来引进了路径分析法,按路径设置用例。目前演变为按功能、路径混合模式设置用例。

    按功能测试是最简捷的,按用例规约遍历测试每一功能。

    对于复杂操作的程序模块,其各功能的实施是相互影响、紧密相关、环环相扣的,可以演变出数量繁多的变化。没有严密的逻辑分析,产生遗漏是在所难免。路径分析是一个很好的方法,其最大的优点是在于可以避免漏测试。

    但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块,这些模块相互有关联。再采用路径分析法,其路径数量成几何级增长,达5位数或更多,就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。

    3、设计测试用例
    测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例,应该参照用例规约(或设计规格说明书),根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能,覆盖率达100%。

    设计备选事件和异常事件的用例,则要复杂和困难得多。例如,字典的代码是唯一的,不允许重复。测试需要验证:字典新增程序中已存在有关字典代码的约束,若出现代码重复必须报错,并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件,并同时尽量发现其中的软件缺陷。

    可以采用软件测试常用的基本方法:等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例,并最终实现暴露隐藏的缺陷,全凭测试设计人员的丰富经验和精心设计。

    四、测试用例在软件测试中的作用
    1、指导测试的实施
    测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准,测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中,以便自动生成测试结果文档。

    根据测试用例的测试等级,集成测试应测试那些用例,系统测试和回归测试又该测试那些用例,在设计测试用例时都已作明确规定,实施测试时测试人员不能随意作变动。
    如何设计编制软件测试用例(三)

    2、规划测试数据的准备
    在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据,以及标准测试结果。尤其象测试报表之类数据集的正确性,按照测试用例规划准备测试数据是十分必须的。
    除正常数据之外,还必须根据测试用例设计大量边缘数据和错误数据。

    3、编写测试脚本的"设计规格说明书"
    为提高测试效率,软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书,那么测试脚本的设计规格说明书就是测试用例。

    4、评估测试结果的度量基准
    完成测试实施后需要对测试结果进行评估,并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例:测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少,等等。以前统计基准是软件模块或功能点,显得过于粗糙。采用测试用例作度量基准更加准确、有效。

    5、分析缺陷的标准
    通过收集缺陷,对比测试用例和缺陷数据库,分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善,应立即补充相应测试用例,最终达到逐步完善软件质量。而已有相应测试用例,则反映实施测试或变更处理存在问题。

    五、相关问题
    1、测试用例的评审
    测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审,需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成,也可邀请客户代表参加。

    2、测试用例的修改更新
    测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故:第一、在测试过程中发现设计测试用例时考虑不周,需要完善;第二、在软件交付使用后反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成;第三、软件自身的新增功能以及软件版本的更新,测试用例也必须配套修改更新。

    一般小的修改完善可在原测试用例文档上修改,但文档要有更改记录。软件的版本升级更新,测试用例一般也应随之编制升级更新版本。

    12.软件测试的14种类型
    软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

    1 数据和数据库完整性测试

    数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
    数据库完整性原即:
    主码完整性:主码不能为空;
    外码完整性:外码必须等于对应的主码或者为空。
    数据合理性指数据在数据库中的类型,长度,索引等是否建的比较合理。
    在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支1持测试的工具和技术。

    比如,有两张表:部门和员工。部门中有部门编号,部门名称,部门经理等字段,主码为部门编号;员工表中有员工编号,员工所属部门编号,员工名称,员工类型等字段,主码为员工编号,外码为员工所属部门编号,对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空,他就违反主码完整性原则。如果某个员工所属部门的编号为##,但是##在部门编号中确找不到,这就违反外码完整性原则。
    员工类型如下定义:0:职工,1:职员,2:实习生。但数据类型为Int,我们都知道Int占有4个字节,如果定义成char(1).就比原来节约空间。


    2 白盒测试

    白盒测试是基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
    2.1 静态白盒测试
    利用眼睛,浏览代码,凭借经验,找出代码中的错误或者代码中不符合书写规范的地方。比如,代码规范中规定,函数必须为动宾结构。而黑盒测试发现一个函数定义如下:
    Function NameGet(){
    ….
    }
    这是属于不符合开发规范的错误。
    有这样一段代码:
    if (i<0) & (i>=0)

    这段代码交集为整个数轴,IF语句没有必要
    I=0;
    while(I>100){
    J=J+100;
    T=J*PI;
    }
    在循环体内没有I的增加,bug产生。

    2.2 动态白盒测试
    利用开发工具中的调式工具进行测试。比如一段代码有4个分支,输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
    看一段代码
    if(I<0){
    P1
    }else{
    P2
    }
    在调试中输入I=-1,P1程序段通过, P2程序段未通过,属于动态黑盒测试的缺陷

    3.功能测试

    功能测试指测试软件各个功能模块是否正确,逻辑是否正确。
    对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
    比如一个对电子商务系统,前台用户浏览商品-放入购物车-进入结账台,后台处理订单,配货,付款,发货,这一系列流程必须正确无误的走通,不能存在任何的错误。

    4.UI测试

    UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等
    用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观,与测试人员的喜好有关
    比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。

    5.性能测试

    性能测试主要测试软件测试的性能,包括负载测试,强度测试,数据库容量测试,基准测试以及基准测试
    5.1负载测试
    负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
    在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
    比如,在B/S结构中用户并发量测试就是属于负载测试的用户,可以使用webload工具,模拟上百人客户同时访问网站,看系统响应时间,处理速度如何?
    5.2强度测试
    强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
    实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
    比如:一个系统在内存366M下可以正常运行,但是降低到258M下不可以运行,告诉内存不足,这个系统对内存的要求就是366M。
    5.3数据库容量测试
    数据库容量测试指通过存储过程往数据库表中插入一定数量的数据,看看相关页面是否能够及时显示数据。
    数据库容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录,计算相关页面的调用时间。
    比如,在电子商务系统中,通过insert customer 往user表中插入10 000数据,看其是否可以正常显示顾客信息列表页面,如果要求达到最多可以处理100 000个客户,但是顾客信息列表页面不能够在规定的时间内显示出来,就需要调整程序中的SQL查询语句;如果在规定的时间内显示出来,可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
    5.4基准测试
    基准测试与已知现有的系统进行比较,主要检验是否与类似的产品具有竞争性的一种测试。
    如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据,你可以测试你这套系统,看看哪些地方比用友财务系统好,哪些地方差?以便改进自己的系统,也可为产品广告提供数据。
    5.5竞争测试
    软件竞争使用各种资源(数据纪录,内存等),看他与其他相关系统对资源的争夺能力。比如:一台机器上即安装您的财务系统,又安装用友财务系统。当CPU占有率下降后,看看是否能够强过用友财务系统,而是自己的系统能够正常运行?

    6. 安全性和访问控制测试

    安全性和访问控制测试侧重于安全性的两个关键方面:
    应用程序级别的安全性,包括对数据或业务功能的访问
    系统级别的安全性,包括对系统的登录或远程访问。
    6.1应用程序级别的安全性
    可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客户的统计数据。
    比如B/S系统,不通过登入页面,直接输入URL,看其是否能够进入系统?
    6.2系统级别的安全性
    可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。
    比如输入管理员账户,检查其密码是否容易猜取,或者可以从数据库中获得?

    7.故障转移和恢复测试

    故障转移和恢复测试指当主机软硬件发生灾难时候,备份机器是否能够正常启动,使系统是否可以正常运行,这对于电信,银行等领域的软件是十分重要的。
    故障转移和恢复测试可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
    比如电信系统,突然主机程序发生死机,备份机器是否能够启动,使系统能够正常运行,从而不影响用户打电话?
    8.配置测试

    又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。(如浏览器版本,操作系统版本等)
    下面列出主要配置测试
    8.1浏览器兼容性
    测试软件在不同产商的浏览器下是否能够正确显示与运行;
    比如测试IE,Natscape浏览器下是否可以运行这套软件?
    8.2操作系统兼容性
    测试软件在不同操作系统下是否能够正确显示与运行;
    比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件?
    8.3硬件兼容性
    测试与硬件密切相关的软件产品与其他硬件产品的兼容性,比如该软件是少在并口设备中的,测试同时使用其他并口设备,系统是否可以正确使用.
    比如在INTER,舒龙CPU芯片下系统是否能够正常运行?
    这样的测试必须建立测试实验室,在各种环境下进行测试。

    9.安装测试

    安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
    安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    10.多语种测试

    又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。
    本地化测试还要考虑:
    l 当语言从A翻译到B,字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”,翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
    l 要考虑同一单词在各个国家的不同意思,比如football在英文中为足球,而美国人使用中可能理解为美式橄榄球。
    l 要考虑各个国家的民族习惯,比如龙个美国中被理解邪恶的象征,但翻译到中国,中国人认为为吉祥的象征。

    11.文字测试

    文字测试测试软件中是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否有出入等等,包括图片文字。
    比如:“比如,请输入正确的证件号码!”何谓正确的证件号码,证件可以为身份证,驾驶证,也可为军官证,如果改为“请输入正确的身份证号码!”用户就比较容易理解了。

    12.分辨率测试

    测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

    13发布测试

    主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试

    13.1说明书测试
    主要为语言检查,功能检查,图片检查
    语言检查:检查说明书语言是否正确,用词是否易于理解;
    功能检查:功能是否描述完全,或者描述了并没有的功能等;
    图片检查::检查图片是否正确
    13.2宣传材料测试
    主要测试产品中的附带的宣传材料中的语言,描述功能,图片
    13.3帮助文件测试
    帮助文件是否正确,易懂,是否人性化。最好能够提供检索功能。
    13.4广告用语
    产品出公司前的广告材料文字,功能,图片,人性化的检查

    14 文档审核测试

    文档审核测试目前越来越引起人们的重视,软件质量不是检查出来的,而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料:

    文档审核测试主要包括需求文档测试,设计文档测试,为前置软件测试测试中的一部分。

    14.1需求文档测试

    主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;

    14.2设计文档测试

    测试设计是否符合全部需求以及设计是否合理。

    总结

    据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计,得出这样一个结论:软件缺陷在开发前期发现比在开发后期发现资金,人力上节约90%;软件缺陷在推向市场前发现比在推出后发现资金,人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的,可以根据产品的具体情况进行组装测试不同的类型。

    参考文献
    《Rational统一过程模型》
    《软件测试》
    bug管理主要有VSS,TD,TD专业点,VSS常用在版本和文档管理
    测试软件针对不同的测试环节也分很多种
    不过,个人认为,测试新手不要把眼光盯在各种测试软件上
    首先必须对测试理论和公司的软件产品要有个基本的概念
    然后熟悉一下测试流程
    在自己写几个测试计划
    当你对测试有个比较深刻的认识后
    在去考虑应用WR.CUINT等测试软件
    我觉得这样可能更有利个人的发展

    13.软件开发全过程检测及测试自动化

      首先谈谈软件测试。这可以说是一个非常令人捉摸不定的领域。“应该怎样对我们的产品进行测试?”和“怎样才算对产品进行了足够的测试?”等问题,对于不同企业的不同类产品、同一企业的不同类产品、或不同企业的同一类产品,实际操作上都会有很大的不同。

      SEI的SW-CMM在它的成熟度第三级的“软件产品工程”关键过程域中,把软件开发周期中不同阶段的测试作为实施活动中的关键实践。(在SW-CMM版本2.0 的讨论过程中,曾经有过提议,在成熟度第二级设立一个关键过程域“软件测试管理”。但在版本2.0 的讨论稿C 中,并没有这样做。从这里我们也可以看出,SW-CMM本身也是一个人为地制定的“软件”。)

      一般地,基于开发周期中不同阶段对不同对象所进行的测试,可划分为:

      单元测试(unit test ):

      由编程的开发人员自行计划与完成的,针对单个或相关联的一组程序单元的测试。

      组装测试(inegration test ):

      计划于设计阶段,由开发人员与测试人员合作完成的,针对结合起来的不同单元以及它们的接口的测试。

      系统测试(system test ):(可认为包括“可用性与图形用户界面测试”)

      测试整个系统,以证实它满足要求所规定的功能、质量和性能等方面的特性。

      回归测试(regression test ):

      用于验证改变了的系统或其组件仍然保持应有的特性。

      验收测试(acceptance test ):

      测试整个系统,以保证其达到可以交付使用的状态。

      关于上述各阶段的测试的具体内容及实现的方法,读者可参考SW-CMM及有关软件工程和软件测试的书籍。千万不要停留在只参考SW-CMM,因为该文件只讲述要做些什么,而没有介绍怎样做。同时,所有的资料中谈及的内容及方法,都是一般化的。对于一个特定软件的测试,必须经过使用者对通用的测试方法的改变及改进,才能有效和达到高效率。

      下面,谈谈软件测试的其他方面的一些问题。

      一个被人忽略的软件测试目的

      在谈到测试时,许多作者都引用了Grenford J. Myers 就软件测试目的提出的以下观点:

      1.测试是程序的执行过程,目的在于发现错误;

      2.一个好的测试用例在于能发现至今未发现的错误;

      3.一个成功的测试是发现了至今未发现的错误的测试。

      这是一种比较狭窄的观点。作为一个清醒的、纵观全局的软件开发人员或管理者,我们应当从软件过程的角度来看测试。

      一个被人忽略的软件测试目的是:测试可以帮助发现当前开发工作所采用的软件过程(也是一个“软件”)的缺陷,以便进行改进。(在以下的讨论中,“错误”与“缺陷”基本上认为代表相同意义。)

      怎样理解这种说法呢?

      首先,测试并不仅仅是为了要找出错误。分析错误产生的原因和错误在开发的哪一个阶段产生,具有非常重要的意义。

      通过分析错误的原因,我们可以立即在开发行动中对其进行改正。同时,这种分析也能帮助我们推理出 与所分析的错误有关联的潜在错误,从而有针对性地设计出检测的方法。

      通过分析错误产生于哪一个开发阶段、而又在哪一个阶段被发现,我们可以判断从错误的产生到错误的发现,跨越了多少个开发阶段。软件开发的一条重要原则是尽早发现与修正错误。(当然,更高的一条原则是尽量预防错误的出现。)一个错误能够超越本开发阶段而不被发现,就指明了该开发阶段的检测手段有缺陷,从而也不难有针对性地制定出加强的措施与办法。这也就是软件过程改进的一项重要内容。如果能做到在同一开发阶段发现及修正错误,该开发机构就可以预期有一个高质量的产品及一个低成本、高效率的软件过程。

      有些项目的主持人,认为以尽快的速度把测试之前的所有开发阶段完成(实际并没有完成),早日开始测试,以图达到快速和高质量(因为似乎有更长的时间可用于测试)。实际的效果将会是俗语所说的“欲速不达”。从常识就可以知道,花开发时间去继续扩大发展前面阶段引入的错误,得出的只能是更大量的需要耗时修正的错误。

      因此,正确分析与利用测试的结果,我们可以非常有效地进行软件过程改进。

      软件开发全过程检测,力争本阶段修正错误

      从上面的讨论,我们很自然的就能领会到,软件错误的发现绝不能等到测试才开始(按常规,最早的测试就是编码后的单元测试)。因此,笔者提出一个软件工程的守则:软件开发全过程检测,力争本阶段修正错误。单元测试是在软件开发的“实现阶段”才开始的,在此之前的“可行性研究与计划阶段”,“需求分析阶段”,“概要设计阶段”,和“详细设计阶段”,都必须有非常明确切实的手段与措施对开发结果进行检验,以保证阶段的正确完成。

      怎样判断一个软件过程的优劣,怎样进行软件过程改进,都可以在这个守则的指导下进行。这个守则是简单明确的,但因企业背景、条件的不同,开发环境条件的不同,项目产品的不同,实际的软件过程的实现方法就会变化无穷。考虑实现这个原则的方法的时候,可以尽量多参考各种理论及经验,但在选择制定本企业开发实践中使用的软件过程时,就必须处处根据是否能给自身的项目带来好处,以及自身的条件进行考虑。千万不要仅仅为了满足某个“标准”的提法而做一些无实际意义的工作。要尽量避免烦琐,争取做到简单、有条理和有最大的效果。

      软件测试的自动化

      软件测试的工作量很大(据统计,会用到40% 的开发时间;一些可靠性要求非常高的软件,测试时间甚至占到总开发时间的60% ),但测试却是在整个软件过程中极有可能应用计算机进行自动化的工作,原因是测试的许多操作是重复性的、非智力创造性的、需求细致注意力的工作。计算机就最适合于代替人类去完成这些任务。企业在这方面的投资,会对整个开发工作的质量、成本、和周期带来非常明显的效果。

      一些适于考虑进行自动化的测试操作为:

      1.测试个案的生成(包括测试输入,标准输出,测试操作指令等)。

      2.测试的执行写控制(包括单机与网络多机分布运行;夜间及假日运行。测试个案调用控制;测试对象、范围、版本控制等。)。

      3.测试结果与标准输出的对比。

      4.不吻合的测试结果的分析、记录、分类、和通报。

      5.总测试状况的统计,报表的产生。

      测试自动化与软件配置管理是密不可分的。与测试有关的资源都应在配置管理中进行统一的计划考虑。另外,测试工具的采用也是一个提高质量的关键,有些专用的测试工具能帮助发现一些用任何测试个案都难以触及的错误。
    14.安装与卸载测试-我的学习总结

    前几天发表了“如何进行卸载测试”的贴子,得到很多回复,这里表示感谢!
    通过认真地学习与总结前辈们的宝贵经验,现整理一部分如下,主要是加深自己对它们的理解,还有希望大家继续补充与给出建议,谢谢!
    软件安装与卸载测试是相辅相成,通过互相补充,会发现更多的测试角度,谢谢

    ============卸载测试==============
    文件----安装目录里的文件及文件夹(如:程序安装在几处的)
          非安装目录(向系统其它地方添加的文件及文件夹)
        它们包括(exe,dll,配置文件等)
    快捷方式-(桌面,菜单,任务栏,系统栏,控件面板,系统服务列表等)
    复原方面-卸载后,系统能否恢复到软件安装前的状态(包含目录结构、动态库,注册表,系统配置文件,驱动程序,关联情况等)
    卸载方式--程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具(如:优化大师)
    卸载状态--程序在运行/暂停/终止等状态时的卸载
    非正常卸载情况-卸载软件过程中,取消卸载进程,然后,观察软件能否继续正常使用
    冲击卸载--在卸载的过程中,中断电源,然后,启动计算机后,重新卸载软件,如果软件无法卸载,则重新安装软件,安装之后再重新卸载。
    卸载环境--不同的(操作系统,硬件环境,网络环境等)下进行卸载
    卸载后,该系统是否对其他的应用程序造成不正常影响(如操作系统,应用软件等)
    ==========安装测试============
    一:基本目标
    1.安装程序能正确运行
    2.程序安装正确
    3.程序安装后能正确运行
    4.完善性安装后程序能正确运行
    二:一些方面
    0、安装手册给的所有步骤得到验证;
    1、安装过程中所有缺省选项得到验证;
    2、安装过程中典型选项得到验证;
    3、测试各种不同的安装组合,并验证各种不同组合的正确性(包括参数组合,控件执行顺序组合,产品安装组件组合,产品组件安装顺序组合(如b/s)等)
    4、安装过程中异常配置或状态(非法和不合理配置)情况进行了测试(如:断电;数据库终止,网络终止等)
    5、安装后是否能产生正确的目录结构和文件,文件属性正确;
    6、安装后动态库是否正确;
    6、安装后软件能否正确运行;
    7、安装后没有生成多余的目录结构,文件,注册表信息,快捷方式等;
    9、安装测试应该在所有的运行环境上进行验证(手册上指定如:操作系统,数据库,硬件环境,网络环境等);
    10、自动安装还是手工配置安装
    11、至少要在一台笔记本上进行安装/卸载测试,因为有很多产品在笔记本中会出现问题,尤其是系统级的产品
    13、安装,该系统是否对其他的应用程序造成不正常影响(如操作系统,应用软件等)
    15.微软的测试题

    Test Paper for Software Design Engineer

    (Test time: 60 minutes)

    Name:         Date:         Location:



    Part 1: Technical Skills Set

    (请将 “ ● ”paste在您所掌握的技能程度表格内,并注明您的使用时间和相关的证书)

    技能列表 精通   熟练   掌握   了解   使用时间(月) 所获证书

    English (oral)

    English (written)

    OOP programming skills

    C/C++ (pointer, memory)

    Java

    C#

    NET

    算法&数据结构

    Win API experience –plus


    Part 2 : Technical Test

    1. 实现二分查找的递归算法的函数。(使用C++,不建议用伪码)











    2. 请指出该程序的错误。

    #include <iostream.h>



    int *p;



    void Function();

    {

    int n;

    n = 25;

    p = &n;

    }



    void main()

    {

    Function();

    cout<<"value of *p: "<<*p<<endl;

    }













    3. 英语写作

    Question: Please describe your career path in the next two years.
    16. 多线程与多进程
    线程的外壳是进程,进程管理线程;
    线程不占用系统资源,而进程占用系统资源;
    什么叫进程?进程同程序有什么区别?
    答:进程是程序在计算机上的一次执行活动。当你运行一个程序,你就启动了一个进程。显然,程序是死的(静态的),进程是活的(动态的)。进程可以分为系统进程和用户进程。凡是用于完成操作系统的各种功能的进程就是系统进程,它们就是处于运行状态下的操作系统本身;用户进程就不必我多讲了吧,所有由你启动的进程都是用户进程。进程是操作系统进行资源分配的单位。
    在Windows下,进程又被细化为线程,也就是一个进程下有多个能独立运行的更小的单位。
    在同一个时间里,同一个计算机系统中如果允许两个或两个以上的进程处于运行状态,这便是多任务。现代的操作系统几乎都是多任务操作系统,能够同时管理多个进程的运行。 多任务带来的好处是明显的,比如你可以边听mp3边上网,与此同时甚至可以将下载的文档打印出来,而这些任务之间丝毫不会相互干扰。那么这里就涉及到并行的问题,俗话说,一心不能二用,这对计算机也一样,原则上一个CPU只能分配给一个进程,以便运行这个进程。我们通常使用的计算机中只有一个CPU,也就是说只有一颗心,要让它一心多用,同时运行多个进程,就必须使用并发技术。实现并发技术相当复杂,最容易理解的是“时间片轮转进程调度算法”,它的思想简单介绍如下:在操作系统的管理下,所有正在运行的进程轮流使用CPU,每个进程允许占用CPU的时间非常短(比如10毫秒),这样用户根本感觉不出来CPU是在轮流为多个进程服务,就好象所有的进程都在不间断地运行一样。但实际上在任何一个时间内有且仅有一个进程占有CPU。
     如果一台计算机有多个CPU,情况就不同了,如果进程数小于CPU数,则不同的进程可以分配给不同的CPU来运行,这样,多个进程就是真正同时运行的,这便是并行。但如果进程数大于CPU数,则仍然需要使用并发技术。
      在Windows中,进行CPU分配是以线程为单位的,一个进程可能由多个线程组成,这时情况更加复杂,但简单地说,有如下关系:

      总线程数<= CPU数量:并行运行

      总线程数> CPU数量:并发运行

      并行运行的效率显然高于并发运行,所以在多CPU的计算机中,多任务的效率比较高。但是,如果在多CPU计算机中只运行一个进程(线程),就不能发挥多CPU的优势。

    这里涉及到多任务操作系统的问题,多任务操作系统(如Windows)的基本原理是:操作系统将CPU的时间片分配给多个线程,每个线程在操作系统指定的时间片内完成(注意,这里的多个线程是分属于不同进程的).操作系统不断的从一个线程的执行切换到另一个线程的执行,如此往复,宏观上看来,就好像是多个线程在一起执行.由于这多个线程分属于不同的进程,因此在我们看来,就好像是多个进程在同时执行,这样就实现了多任务.Whoops,真绕口.

    所以结合楼上的答复,不知道楼主是否可以满意!

    关于多线程,多进程的问题,楼主可以看看操作系统方面的书,可以得到更多的启示!


      如上,多线程和多任务是有很明显的区别的.但是再想一下,在一个应用程序内实现多线程不也是靠CPU分配时间片吗?既然原理是相同的,那么多线程也可以说是多任务的.

    17.回归测试
    回归测试和验证修复的bug不是等同的.回归测试要求在新的版本中,重新遍历测试用例,因为开发人员在解决问题时可能会影响到相关的模块,只验证修复的问题是否已经解决不能叫做回归测试.
    我们最新采用的回归测试的方法是:把所有的测试说明中的用例全部执行一遍!(很麻烦的说)
    然后对于初次测试出问题的地方及其边缘重点测试!
    1、关于Bug的状态前面有帖子楼主可以看看,开发人员如果认为Bug已修复,应把Bug的状态改成Resolved,测试人员发现有Resolved的Bug就要进行回归测试以验证Bug是否真的解决,如验证通过则将Bug的状态改成Verified Pass,然后再由相关人员(如测试负责人)把Bug的装体改成Closed;如验证失败则将Bug的状态改成Verified Fail,让开发人员再去解决。
    2、关于楼主提到的“但是在测试用例很多的情况下,自己可能也不记得那些测试用例中有实际结果与期望结果不一致的用例”说明Bug的提交和记录存在问题,Bug所对应的测试用例编号是肯定要包含在Bug报告中的,这样回归测试的时候就不会搞不清楚了。
    3、现在开源的Bug管理工具也是有的,如bugzilla,最好还是去装一个吧。

    Bug的状态各个公司会不同,多少也不一样,我原来在德公司就有30来种状态。呵呵!
    一般只要能够区分下面几种情况,并且不让人误解就好了
    1,新提交的Bug
    2,开发正在修改的Bug
    3,已经修改好并且等待测试人员验证的Bug
    4,验证通过的Bug
    5,验证没有通过的Bug(这个要和新提交的Bug同样处理,不过有的公司需要记住没有改好的次数,用来考评开发的绩效)
    6,设计问题
    7,测试人员报错
    8,暂时不修改的Bug
    回归测试的方法具体问题具体分析,可能有人说我这样等于什么都没说,可是每个项目不同,不同时期也不同,甚至可能测试的人员都换了,如果以一种固定的方法来做,未免显得有点死板。个人认为,在测试的时候,最好能够边测试,边在测试用例上加上备注,说明实际结果。并且最好用颜色标记,如果你够仔细,能够把有问题的测试用例再标注上Bug的编号就更好了,这样在复查bug时,就知道修改好的bug是由哪个用例引起的,可以执行一下相关的用例,看是否真的改好并且没有影响到其他部分,这样就可以放心的Close了。如果有人觉得这样太过麻烦或者中途有人员的变动,也可以只看Bug的描述,按照bug的说明进行验证就够了,但是要记住最好能够对相关的模块进行一下测试,看看流程是否还能走通。不过这就要求Bug的描述要写得比较清晰,明了。
    18.测试大纲和测试计划

    测试大纲只是简单的描述如何开展测试,而测试计划是针对测试中的每个环节的。单元测试、集成测试、系统测试等一般都写测试计划,写的重点不同。而大纲只是简要的写一下测试策略是什么,需要做哪些测试,测试过程如何组织,测试人员包括哪些。可以说管理人员写测试大纲,而测试人员写测试计划。

    19.测试版本大全-转贴

    alpha 内部测试版
      beta 外部测试版
      demo 演示版
      Enhance 增强版或者加强版 属于正式版
      Free 自由版
      Full version 完全版 属于正式版
      shareware 共享版
      Release 发行版 有时间限制
      Upgrade 升级版
      Retail 零售版
      Cardware 属共享软件的一种,只要给作者回复一封电邮或明信片即可。(有的作者并由此提供注册码等),目前这种形式已不多见。
      Plus 属增强版,不过这种大部分是在程序界面及多媒体功能上增强。
      Preview 预览版
      Corporation & Enterprise 企业版
      Standard 标准版
      Mini 迷你版也叫精简版只有最基本的功能
      Premium -- 贵价版
      Professional -- 专业版
      Express -- 特别版
      Deluxe -- 豪华版
      Regged -- 已注册版
      CN -- 简体中文版
      CHT -- 繁体中文版
      EN -- 英文版
      Multilanguage -- 多语言版
      Rip 是指从原版文件(一般是指光盘或光盘镜像文件)直接将有用的内容(核心内容)分离出来,剔除无用的文档,例如PDF说明文件啊,视频演示啊之类的东西,也可以算做是精简版吧…但主要内容功能是一点也不能缺少的!另:DVDrip是指将视频和音频直接从DVD光盘里以文件方式分离出来。
      trail 试用版(含有某些限制,如时间、功能,注册后也有可能变为正式版)
      RC 版。是 Release Candidate 的缩写,意思是发布倒计时,该版本已经完成全部功能并清除大部分的BUG。到了这个阶段只会除BUG,不会对软件做任何大的更改。
      RTM 版。这基本就是最终的版本,英文是 Release To Manufactur,意思是发布到生产商。
      Original Equipment Manufacturer (OEM)
      You may license products through an Original Equipment Manufacturer (OEM). These products, such as Windows operating systems, come installed when you purchase a new computer.
      OEM软件是给电脑生产厂的版本,无需多说。
      Full Packaged Product (FPP)-Retail
      Physical, shrink-wrapped boxes of licensed product that can be purchased in a local retail store or any local software retailer.
      FPP就是零售版(盒装软件),这种产品的光盘的卷标都带有"FPP"字样,比如英文WXP Pro的FPP版本的光盘卷标就是WXPFPP_EN,其中WX表示是Windows XP,P是Professional(H是Home),FPP表明是零售版本,EN是表明是英语。获得途径除了在商店购买之外,某些MSDN用户也可以得到。
      Volume Licensing for Organizations (VLO)
      You may enjoy potentially significant savings by acquiring multiple product licenses. Depending on the size and type of your organization.
      团体批量许可证(大量采购授权合约),这是为团体购买而制定的一种优惠方式。这种产品的光盘的卷标都带有"VOL"字样,取"Volume"前3个字母,以表明是批量,比如英文WXP Pro的VOL版本的光盘卷标就是WXPVOL_EN,其中WX表示是Windows XP,P是Professional(VOL没有Home版本),VOL表明是团体批量许可证版本,EN是表明是英语。获得途径主要是集团购买,某些MSDN用户也可以得到。
    这种版本根据购买数量等又细分为“开放式许可证”、“选择式许可证”、“企业协议”、“学术教育许可证”等以下5种版本
      Open License
      Select License
      Enterprise Agreement
      Enterprise Subscription Agreement
      Academic Volume Licensing
      由此可见,平时说的什么select/corp是许可证授权方式,他的出现是为了用若干种不同级别的优惠政策卖同一种软件,通过select/corp许可证授权方式得到的xxx的光盘都是VOL这一种、是并不是有很多种,只不过是相同的VOL光盘配以不同的许可证方式;而Volume Licensing (Product) Keys,即VLK,它所指的只是一个Key(密匙),仅仅是一个为证明产品合法化、以及安装所使用的Key,因为根据VOL计划规定,VOL产品是不需要激活的!
      或者说,VLK不是指一种版本,而是指这种版本在部署(deploy)过程中所需要的Key,而需要VLK这种Key的版本应该叫做VOL!只不过在实际中,没有必要强调这种叫法、称呼的准确性,加之很多人的VOL版本光盘是通过企业的选择式许可证、企业协议等方式得到的等等原因,所以才会有很多人叫他为“选择版”等等。
    官方网站有一个表格,上面有一句话:“Different products require different Volume Licensing Keys (VLKs). Refer to the table below to make sure you have the correct VLK for your Microsoft product.”,我想这就很好的说明了VLK指的是Key而不是产品了。 很明显的,FPP需要激活,VOL不需要激活。
    20. 黑、白盒测试

    白盒测试和黑盒测试不是决然分开的,单独做黑盒测试或白盒测试都是做了测试的一个方面,很难保证发现了软件中大部分缺陷。在测试过程中往往把两者结合起来进行测试,从代码逻辑结构上保证正确,再从功能和非功能特性上保证正确,经过这两方面的测试,才能最大可能的保证软件质量。在测试过程中,采用这两种测试技术的时间有所不同。

    单元测试、集成测试、系统测试是按照测试的阶段来进行划分的,而白盒测试、黑盒测试是从测试技术的角度来划分的。一般来说,单元测试阶段进行的测试基本上以白盒测试技术为主,系统测试阶段进行的测试基本上以黑盒测试技术为主,而集成测试所采用的技术是介于白盒和黑盒之间的,有的技术文献也称之为灰盒技术

    软件测试是一个过程,一个完整的软件测试过程又分为三个阶段,分别是单元集成和系统(当然还有写别的测试过程),而黑盒和白盒只是在这些过程中所采用的测试方法罢了。

    个人意见
    1. 黑盒测试
    黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。
    黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。
    2. 白盒测试
      白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
      “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。
    3. 灰盒测试
    灰盒测试,确实是介于二者之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。
    灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
    灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识盒与之交互的环境,能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
      灰盒测试涉及输入和输出,但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。
    21.Software Testing 10 Rules
    1. Test early and test often.
    尽早测试,经常测试
    2. Integrate the application development and testing life cycles. You'll get better results and you won't have to mediate between two armed camps in your IT shop.(这后半句怎么理解?)
    整合应用程序开发和软件测试生命周期,你将得到更好的结果,并且不必要在程序开发和软件测试两者之间左右为难。
    3. Formalize a testing methodology; you'll test everything the same way and you'll get uniform results.
    形成一套完整的测试方法;你将用同样的方法开展测试工作,并且可以得到始终如一的结果
    4. Develop a comprehensive test plan; it forms the basis for the testing methodology.
    开发一套完整、全面的的测试计划;作为软件测试方法论的基础部分
    5. Use both static and dynamic testing.
    采用静态测试和动态测试相结合的方法(可以采用静态代码检查工具作静态测试)
    6. Define your expected results.
    定义测试预期结果(在测试用例中,这是比不可少的项目)
    7. Understand the business reason behind the application. You'll write a better application and better testing scripts.
    理解应用背后的商业动机,找出真正的需求根源,你将写出更好的应用程序和测试脚本。
    8. Use multiple levels and types of testing (regression, systems, integration, stress and load).
    采用多层面和多类型的软件测试(回归测试、系统测试、集成测试、压力测试和负载测试)
    9. Review and inspect the work, it will lower costs.
    多工作评审和检视,可以降低成本(检视和评审可以提早发现问题,规避问题,避免造成不必要的损失,因此,可以降低成本)
    10. Don't let your programmers check their own work; they'll miss their own errors.
    不要让程序员检查自己的工作产品,程序员会忽略自己犯的错误。

    展开全文
  • 1.测试新手从何处入手 2.测试计划的前提是什么? 3.测试计划模版 4.单元测试,集成测试和系统测试 5.测试工具: ...6. 软件测试中的基本词汇 ...11.如何设计编制软件测试用例(一~三)
    1.测试新手从何处入手   
    2.测试计划的前提是什么?   
    3.测试计划模版   
    4.单元测试,集成测试和系统测试   
    5.测试工具:   
    6. 软件测试中的基本词汇   
    7. 软件测试步骤   
    8.我想问到底软件测试的流程是什么?   
    9.请问Bug曲线是怎么会事?   
    10.负载测试与压力测试有何区别?   
    11.如何设计编制软件测试用例(一~三)   
    12.软件测试的14种类型   
    13.软件开发全过程检测及测试自动化   
    15.微软的测试题   
    16. 多线程与多进程   
    17.回归测试   
    18.测试大纲和测试计划   
    19.测试版本大全-转贴   
    20. 黑、白盒测试   
    21.Software Testing 10 Rules   
    1.测试新手从何处入手
    学习,努力学习,没有别的捷径的
    给大家提供一个我们的培训提纲,按照这些内容学吧
    8、 软件测试技术概论
    9、 测试管理
    10、系统测试计划和方案
    11、系统测试用例设计
    12、集成测试计划和方案
    13、集成测试用例设计
    14、单元测试计划和方案
    15、单元测试用例设计
    16、单元测试执行
    17、集成测试执行
    18、系统测试执行
    19、WEB项目测试专题
    20、C/S架构项目测试专题
    21、测试工程师职业素质
    当你刚被聘用到一个测试小组时,作为新手,可能你应该按别人指定的测试计划执行测试。这并不是说你没有能力制定这样的计划,而是别人制定的测试计划可能比你的好(这是一个公认的事实)。按别人的计划执行,并记下那些可以用不同方式完成的部分和优秀之处。用不了多久,你就有自己作主的权利了,最开始要从你负责组件的测试计划作起。充分利用你的笔记和经验,这有助于你在第一次就能够写出一个高效、专业的测试计划。
    当你在执行其他人的计划时,你可以考虑另外可尝试的测试用例。有一些可能不适用,但对于软件其他部分仍是好的测试用例,只是不是你负责的而已。不要低估自己作为测试人员的能力,要相信自己也能发现好的测试用例。
    制定测试计划时应该考虑可用的资源和需要组织涉及参与的活动。不管是低级别的计划还是高级别的计划,都需要详细地规定工作的责任人、各人的工作任务,以及任务完成的时间。没有经过彻底交流过的计划是不可能有效的。最无效的计划就是那些没人知道其存在的计划。
    2.测试计划的前提是什么?
    当然是项目计划,作为整个项目来说测试是一个非常重要的步骤,如果pm都没有这个意识,那么你的工作就没有立足的根本了。
    在了解了项目需求和开发计划后,你就可以根据项目开发时间来制定你的测试计划
    1.test plan 整个测试需要那些资源,时间安排,需要产生哪些文档
    2.test case 根据需求编写对应功能模块的测试案例,熟悉系统
    3.test report 对每一个完成的模块进行详尽的测试,完成test report
    4.bug 跟踪,并且进行数据统计和回归
    一般来说只要1个人跟一个项目,这些事情基本还是能够完成的,不敢说多高质量,但是比没有还是好得多 
    3.测试计划模版
    a.
    “无忧测试”QQ整理——jzhao的测试计划

    感谢jzhao和大家分享!

    测试计划6月份--7月份

    制定人   开始时间   结束时间   测试阶段   修订   
      2004-06-21   2004-07-22           

    一、   测试类型及目标
    Win 32 Release 1.0:构建测试和集成测试
    a)   构建测试目标:
    正确实现需求特性;
    界面规范正确无误。
    b)   集成测试目标:
    正确实现本阶段的需求特性;
    界面规范正确无误;
    回归测试,对整个产品进行全面的测试
    国际化测试
    安装测试
    二、   测试策略
    l   使用测试用例。
    l   可以使用WinRunner测试工具,从而减少回归测试的工作量。
    l   使用Buggit作为缺陷管理工具,对缺陷进行分类管理,并且需要做出缺陷分析
    三、   资源安排

    B.这里给一份模板大家看看如何?

    1.简介   3
    1.1目的   3
    1.2背景   3
    1.3范围   3
    2.   测试参考文档和测试提交文档   3
    2.1测试参考文档   3
    2.2测试提交文档   3
    3.测试进度   3
    4.测试资源   3
    4.1人力资源   3
    4.2测试环境   3
    4.3测试工具   3
    5.系统风险、优先级   3
    6.测试策略   3
    6.1数据和数据库完整性测试   3
    6.2接口测试   3
    6.3集成测试   3
    6.4功能测试   3
    6.5用户界面测试   3
    6.6性能评测   3
    6.7负载测试   3
    6.8强度测试   3
    6.9容量测试   3
    6.10安全性和访问控制测试   3
    6.11故障转移和恢复测试   3
    6.12配置测试   3
    6.13安装测试   3
    7.问题严重度描述   3
    8.附录:项目任务   3


    1.   简介
    1.   1目的
    <项目名称>的这一“测试计划”文档有助于实现以下目标:

    [确定现有项目的信息和应测试的软件构件。
    列出推荐的测试需求(高级需求)。
    推荐可采用的测试策略,并对这些策略加以说明。
    确定所需的资源,并对测试的工作量进行估计。
    列出测试项目的可交付元素]
    1.   2背景
    [对测试对象(构件、应用程序、系统等)及其目标进行简要说明。需要包括的信息有:主要的功能和性能、测试对象的构架以及项目的简史。]
    1.3范围
    [描述测试的各个阶段(例如,单元测试、集成测试或系统测试),并说明本计划所针对的测试类型(如功能测试或性能测试)。
    简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。
    如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施,则列出所有这些假设。
    列出可能会影响测试设计、开发或实施的所有风险或意外事件。
    列出可能会影响测试设计、开发或实施的所有约束。]


    2.   测试参考文档和测试提交文档
    2.1测试参考文档
    下表列出了制定测试计划时所使用的文档,并标明了各文档的可用性:
    [注:可适当地删除或添加文档项。]
    文档(版本/日期)   已创建或可用   已被接收或已经过复审   作者或来源   备注
    可行性分析报告   是□ 否□   是□ 否□       
    软件需求定义   是□ 否□   是□ 否□       
    软件系统分析(STD,DFD,CFD,DD)   是□ 否□   是□ 否□       
    软件概要设计   是□ 否□   是□ 否□       
    软件详细设计   是□ 否□   是□ 否□       
    软件测试需求   是□ 否□   是□ 否□       
    硬件可行性分析报告   是□ 否□   是□ 否□       
    硬件需求定义   是□ 否□   是□ 否□       
    硬件概要设计   是□ 否□   是□ 否□       
    硬件原理图设计   是□ 否□   是□ 否□       
    硬件结构设计(包含PCB)   是□ 否□   是□ 否□       
    FPGA设计   是□ 否□   是□ 否□       
    硬件测试需求   是□ 否□   是□ 否□       
    PCB设计   是□ 否□   是□ 否□       
    USB驱动设计   是□ 否□   是□ 否□       
    Tuner BSP 设计   是□ 否□   是□ 否□       
    MCU设计   是□ 否□   是□ 否□       
    模块开发手册   是□ 否□   是□ 否□       
    测试时间表及人员安排   是□ 否□   是□ 否□       
    测试计划   是□ 否□   是□ 否□       
    测试方案   是□ 否□   是□ 否□       
    测试报告   是□ 否□   是□ 否□       
    测试分析报告   是□ 否□   是□ 否□       
    用户操作手册   是□ 否□   是□ 否□       
    安装指南   是□ 否□   是□ 否□       
    2.2测试提交文档
    [下面应当列出在测试阶段结束后,所有可提交的文档]
    3.测试进度
    测试活动   计划开始日期   实际开始日期   结束日期
    制定测试计划           
    设计测试           
    集成测试           
    系统测试           
    性能测试           
    安装测试           
    用户验收测试           
    对测试进行评估           
    产品发布           


    4.测试资源
    4.1人力资源
    下表列出了在此项目的人员配备方面所作的各种假定。
    [注:可适当地删除或添加角色项。]
    角色   所推荐的最少资源(所分配的专职角色数量)   具体职责或注释
          
          
    4.2测试环境
    下表列出了测试的系统环境
    软件环境(相关软件、操作系统等)

    硬件环境(网络、设备等)


    4.3测试工具
    此项目将列出测试使用的工具:
    用途   工具   生产厂商/自产   版本


    5.系统风险、优先级
    [简要描述测试阶段的风险和处理的优先级]


    6.测试策略
    [测试策略提供了对测试对象进行测试的推荐方法。
    对于每种测试,都应提供测试说明,并解释其实施的原因。
    制定测试策略时所考虑的主要事项有:将要使用的技术以及判断测试何时完成的标准。
    下面列出了在进行每项测试时需考虑的事项,除此之外,测试还只应在安全的环境中使用已知的、有控制的数据库来执行。]
    注意:不实施某种测试,则应该用一句话加以说明,并陈述这样的理由。例如,“将不实施该测试。该测试本项目不适用”。
    6.1数据和数据库完整性测试
    [要<项目名称>中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统(DBMS),还需要进行深入的研究,以确定可以支持以下测试的工具和技术。]

    测试目标:   [确保数据库访问方法和进程正常运行,数据不会遭到损坏]
    测试范围:   
    技术:   [调用各个数据库访问方法和进程,并在其中填充有效的和无效的数据(或对数据的请求)。检查数据库,确保数据已按预期的方式填充,并且所有的数据库事件已正常发生;或者检查所返回的数据,确保正当的理由检索到了正确的数据]
    开始标准:   
    完成标准:   [所有的数据库访问方法和进程都按照设计的方式运行,数据没有遭到损坏。]
    测试重点和优先级:   
    需考虑的特殊事项:   [测试可能需要DBMS开发环境或驱动程序在数据库中直接输入或修改数据。进程应该以手工方式调用。应使用小型或最小的数据库(记录的数量有限)来使所有无法接受的事件具有更大的可视度。]


    6.2接口测试
    测试目标   确保接口调用的正确性   
    测试范围:   所有软件、硬件接口,记录输入输出数据
    技术:   
    开始标准:   
    完成标准:   
    测试重点和优先级:   
    需考虑的特殊事项:   接口的限制条件


    6.3集成测试
    [集成测试―主要目的检测系统是否达到需求对业务流程及数据流的处理是否符合标准,检测系统对业务流处理是否存在逻辑不严谨及错误,检测需求是否存在不合理的标准及要求。此阶段测试基于功能完成的测试。]
    测试目标   检测需求中业务流程,数据流的正确性
    测试范围:   需求中明确的业务流程,或组合不同功能模块而形成一个大的功能。
    技术:   [利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。]
    开始标准:   在完成某个集成测试时必须达到标准
    完成标准:   [所计划的测试已全部执行。所发现的缺陷已全部解决。]
    测试重点和优先级:   测试重点指在测试过程中需着重测试的地方,优先级可以根据需求及严重来定
    需考虑的特殊事项:   [确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)]


    6.4功能测试
    [对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面(GUI)与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。以下为各种应用程序列出了推荐使用的测试概要:]

    测试目标   [确保测试的功能正常,其中包括导航,数据输入,处理和检索等功能。]
    测试范围:   
    技术:   [利用有效的和无效的数据来执行各个用例、用例流或功能,以核实以下内容:在使用有效数据时得到预期的结果。在使用无效数据时显示相应的错误消息或警告消息。各业务规则都得到了正确的应用。]
    开始标准:   
    完成标准:   
    测试重点和优先级:   
    需考虑的特殊事项:   [确定或说明那些将对功能测试的实施和执行造成影响的事项或因素(内部的或外部的)]


    6.5用户界面测试
    [用户界面(UI)测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI测试还可确保UI中的对象按照预期的方式运行,并符合公司或行业的标准。]

    测试目标   [核实以下内容:通过测试进行的浏览可正确反映业务的功能和需求,这种浏览包括窗口与窗口之间、字段与字段之间的浏览,以及各种访问方法(Tab键、鼠标移动、和快捷键)的使用窗口的对象和特征(例如,菜单、大小、位置、状态和中心)都符合标准。]
    测试范围:   
    技术:   [为每个窗口创建或修改测试,以核实各个应用程序窗口和对象都可正确地进行浏览,并处于正常的对象状态。]
    开始标准:   
    完成标准:   [成功地核实出各个窗口都与基准版本保持一致,或符合可接受标准]
    测试重点和优先级:   
    需考虑的特殊事项:   [并不是所有定制或第三方对象的特征都可访问。]


    6.6性能评测
    [性能评测是一种性能测试,它对响应时间、事务处理速率和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件(例如工作量或硬件配置)的一种函数来进行评测和微调。
    注:以下所说的事务是指“逻辑业务事务”。这种事务被定义为将由系统的某个Actor通过使用测试对象来执行的特定用例,添加或修改给定的合同。]

    测试目标   [核实所指定的事务或业务功能在以下情况下的性能行为:正常的预期工作量预期的最繁重工作量]
    测试范围:   
    技术:   [使用为功能或业务周期测试制定的测试过程。通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务的迭代数量。脚本应该在一台计算机上运行(最好是以单个用户、单个事务为基准),并在多个客户机(虚拟的或实际的客户机,请参见下面的“需要考虑的特殊事项”)上重复。]
    开始标准:   
    完成标准:   [单个事务或单个用户:在每个事务所预期时间范围内成功地完成测试脚本,没有发生任何故障。][多个事务或多个用户:在可接受的时间范围内成功地完成测试脚本,没有发生任何故障。]
    测试重点和优先级:   
    需考虑的特殊事项:   [综合的性能测试还包括在服务器上添加后台工作量。可采用多种方法来执行此操作,其中包括:直接将“事务强行分配到”服务器上,这通常以“结构化语言”(SQL)调用的形式来实现。通过创建“虚拟的”用户负载来模拟许多个(通常为数百个)客户机。此负载可通过“远程终端仿真(Remote Terminal Emulation)工具来实现。此技术还可用于在网络中加载“流量”。使用多台实际客户机(每台客户机都运行测试脚本)在系统上添加负载。性能测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。性能测试所用的数据库应该是实际大小或相同缩放比例的数据库。]


    6.7负载测试
    [负载测试是一种性能测试。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。]
    [注:以下所说的事务是指“逻辑业务事务”。这各事务被定义为将由系统的某个最终用户通过使用应用程序来执行的特定功能,例如,添加或修改给定的合同。]

    测试目标   [核实所指定的事务或商业理由在不同的工作量条件下的性能行为时间。]
    测试范围:   
    技术:   [使用为功能或业务周期测试制定的测试。通过修改数据文件来增加事务数量,或通过修改脚本来增加每项事务发生的次数。]
    开始标准:   
    完成标准:   [多个事务或多个用户:在可接受的时间范围内成功地完成测试,没有发生任何故障。]
    测试重点和优先级:   
    需考虑的特殊事项:   [负载测试应该在专用的计算机上或在专用的机时内执行,以便实现完全的控制和精确的评测。负载测试所用的数据库应该是实际大小或相同缩放比例的数据库。]
    6.8强度测试
    [强度测试是一种性能测试,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。]
    [注:以下提到的事务都是指逻辑业务事务。]
    测试目标   [核实测试对象能够在以下强度条件下正常运行,不会出现任何错误:服务器上几乎没有或根本没有可用的内存(RAM和DASD)连接或模拟了最大实际(实际允许)数量的客户机多个用户对相同的数据或帐户执行相同的事务最繁重的事务量或最差的事务组合(请参见上面的“性能测试”)。注:强度测试的目标可表述为确定和记录那些使系统无法继续正常运行的情况或条件。客户机的强度测试在“配置测试”的第3.1.11节中进行了说明。]
    测试范围:   
    技术:   [使用为性能评测或负载测试制定的测试。要对有限的资源进行测试,就应该在一台计算机上运行测试,而且应该减少或限制服务器上的RAM和DASD。对于其他强度测试,应该使用多台客户机来运行相同的测试或互补的测试,以产生最繁重的事务量或最差的事务组合。]
    开始标准:   
    完成标准:   [所计划的测试已全部执行,并且在达到或超出指定的系统限制时没有出现任何软件故障,或者导致系统出现故障条件的并不在指定的条件范围之内。]
    测试重点和优先级:   
    需考虑的特殊事项:   [如果要增加网络工作强度,可能会需要使用网络工具来给网络加载消息或信息包。应该暂时减少用于系统的DASD,以限制数据库可用空间的增长。使多个客户机对相同的记录或数据帐户同时进行的访问达到同步。]


    6.9容量测试
    [容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库。检验该软件是否正常运行并生成了正确的报表。]

    测试目标   [核实测试对象在以下高容量条件下能否正常运行:连接或模拟了最大(实际或实际允许)数量的客户机,所有客户机在长时间内执行相同的、且情况(性能)最坏的业务功能。已达到最大的数据库大小(实际的或按比例缩放的),而且同时执行多个查询或报表事务。]
    测试范围:   
    技术:   [使用为性能评测或负载测试制定的测试。应该使用多台客户机来运行相同的测试或互补的测试,以便在长时间内产生最繁重的事务量或最差的事务组合(请参见上面的“强度测试”)创建最大的数据库大小(实际的、按比例缩放的、或填充了代表性数据的数据库),并使用多台客户机在长时间内同时运行查询和报表事务。]
    开始标准:   
    完成标准:   [所计划的测试已全部执行,而且达到或超出指定的系统限制时没有出现任何软件故障。]
    测试重点和优先级:   
    需考虑的特殊事项:   [对于上述的高容量条件,哪个时间段是可以接受的时间?]


    6.10安全性和访问控制测试
    [安全性和访问控制测试侧重于安全性的两个关键方面:
    应用程序级别的安全性,包括对数据或业务功能的访问。
    系统级别的安全性,包括对系统的登录或远程访问。
    应用程序级别的安全性可确保:在预期的安全性情况下,Actor只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新帐户,但只有管理员才能删除这些数据或帐户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”看见同一客户的统计数据。
    系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。]
    测试目标   应用程序级别的安全性:[核实Actor只能访问其所属用户类型已被授权访问的那些功能或数据。]系统级别的安全性:[核实只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。]
    测试范围:   
    技术:   应用程序级别的安全性:[确定并列出各用户类型及其被授权访问的功能或数据。][为各用户类型创建测试,并通过创建各用户类型所特有的事务来核实其权限。]修改用户类型并为相同的用户重新运行测试。对于每种用户类型,确保正确地提供或拒绝了这些附加的功能或数据。系统级别的访问:[请参见以下的“需考虑的特殊事项”。]
    开始标准:   
    完成标准:   [各种已知的Actor类型都可访问相应的功能或数据,而且所有事务都按照预期的方式运行,并在先前的应用程序功能测试中运行了所有的事务。]
    测试重点和优先级:   
    需考虑的特殊事项:   [必须与相应的网络或系统管理员一直对系统访问权进行检查和讨论。由于此测试可能是网络管理可系统管理的职能,可能会不需要执行此测试。]


    6.11故障转移和恢复测试
    [故障转移和恢复测试可可确保测试对象能成功完成转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件可网络故障中恢复。
    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出(I/O)故障或无效的数据库指针和关键字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。]

    测试目标   [确保恢复进程(手工或自动)将数据库、应用程序和系统正确地恢复到预期的已知状态。测试中将包括以下各种情况:客户机断电服务器断电通过网络服务器产生的通信中断DASD和/或DASD控制器被中断、断电或与DASD和/或DASD控制器的通信中断周期未完成(数据过滤进程被中断,数据同步进程被中断)。数据库指针或关键字无效数据库中的数据元素无效或遭到破坏]
    测试范围:   
    技术:   [应该使用为功能和业务周期测试创建的测试来创建一系列的事务。一旦达到预期的测试起点,就应该分别执行或模拟以下操作:²   客户机断电:关闭PC机的电源。²   服务器断电:模拟或启动服务器的断电过程。²   通过网络服务器产生的中断:模拟或启动网络的通信中断(实际断开通信线路的连接或关闭网络服务器或路由器的电源)。²   DASD和DASD控制器被中断、断电或与DASD和DASD控制器的通信中断:模拟与一个或多个DASD控制器或设备的通信,或实际取消这种通信。²   一旦实现了上述情况(或模拟情况),就应该执行其他事务。而且一旦达到第二个测试点状态,就应调用恢复过程。²   在测试不完整的周期时,所使用的技术与上述技术相同,只不过应异常终止或提前终止数据库进程本身。²   对以下情况的测试需要达到一个已知的数据库状态。当破坏若干个数据库字段、指针和关键字时,应该以手工方式在数据库中(通过数据库工具)直接进行。其他事务应该通过使用“应用程序功能测试”和“业务周期测试”中的测试来执行,并且应执行完整的周期。]
    开始标准:   
    完成标准:   [在所有上述情况中,应用程序、数据库和系统应该在恢复过程完成时立即返回到一个已知的预期状态。此状态包括仅限于已知损坏的字段、指针或关键字范围内的数据损坏,以及表明进程或事务因中断面未被完成的报表。]
    测试重点和优先级:   
    需考虑的特殊事项:   ²   [恢复测试会给其他操作带来许多的麻烦。断开缆线连接的方法(模拟断电或通信中断)可能并不可取或不可行。所以,可能会需要采用其他方法,例如诊断性软件工具。²   需要系统(或计算机操作)、数据库和网络组中的资源。²   这些测试应该在工作时间之外或在一台独立的计算机上运行。]


    6.12配置测试
    [配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件 例如,应用程序、驱动程序等 而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。]

    测试目标   [核实测试可在所需的硬件和软件配置中正常运行。]
    测试范围:   
    技术:   ²   [使用功能测试脚本。²   在测试过程中或在测试开始之前,打开各种与非测试对象相关的软件(例如Microsoft应用程序:Excel和Word),然后将其关闭。²   执行所选的事务,以模拟Actor与测试对象软件和非测试对象软件之间的交互。²   重复上述步骤,尽量减少客户机工作站上的常规可用内存。]
    开始标准:   
    完成标准:   [对于测试对象软件和非测试对象软件的各种组合,所有事务都成功完成,没有出现任何故障。]
    测试重点和优先级:   
    需考虑的特殊事项:   ²   [需要、可以使用并可以通过桌面访问哪种非测试对象软件?²   通常使用的是哪些应用程序?²   应用程序正在运行什么数据?例如,在Excel中打开的大型电子表格,或是在Word中打开的100页文档。²   作为此测试的一部分,应将整修系统、Netware、网络服务器、数据库等都记录下来。]


    6.13安装测试
    [安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下 例如,进行首次安装、升级、完整的或自定义的安装 都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。]
    测试目标   核实在以下情况下,测试对象可正确地安装到各种所需的硬件配置中:²   首次安装。以前从未安装过<项目名称>的新计算机²   更新。以前安装过相同版本的<项目名称>的计算机²   更新。以前安装过<Project Name>的较早版本的计算机
    测试范围:   
    技术:   ²   [手工开发脚本或开发自动脚本,以验证目标计算机的状况 首次安装<项目名称>从未安装过;<项目名称>安装过相同或较早的版本。²   启动或执行安装。²   使用预先确定的功能测试脚本子集来运行事务。]
    开始标准:   
    完成标准:   <项目名称>事务成功执行,没有出现任何故障。
    测试重点和优先级:   
    需考虑的特殊事项:   [应该选择<项目名称>的哪些事务才能准确地测试出<项目名称>应用程序已经成功安装,而且没有遗漏主要的软件构件?。]


    7.问题严重度描述
    问题严重度   描述   响应时间
    高   例如使系统崩溃   程序员在多长时间内改正此问题
    中       
    低       
          
          
    8.附录:项目任务
    以下是一些与测试有关的任务:
    ²     制定测试计划
    n   确定测试需求
    n   评估风险
    n   制定测试策略
    n   确定测试资源
    n   创建时间表
    n   生成测试计划
    ²   设计测试
    n   准备工作量分析文档
    n   确定并说明测试用例
    n   确定测试过程,并建立测试过程的结构
    ²   复审和评估测试覆盖
    ²   实施测试
    n   记录或通过编程创建测试脚本
    n   确定设计与实施模型中的测试专用功能
    n   建立外部数据集
    ²   执行测试
    ²   执行测试过程
    ²   评估测试的执行情况
    ²   恢复暂停的测试
    ²   核实结果
    ²   调查意外结果
    ²   记录缺陷
    ²   对测试进行评估
    ²   评估测试用例覆盖
    ²   评估代码覆盖
    ²   分析缺陷
    ²   确定是否达到了测试完成标准与成功标准

    评论:单元测试/测试环境/过于复杂可针对公司不同情况精简/一个太简单,一个太复杂了,就要靠自己扩充和提炼了
    4.单元测试,集成测试和系统测试
    单元测试关注软件单元内部的逻辑结构和控制流程;
    集成测试关注软件模块之间的接口和模块集成后整体功能的实现;
    系统测试完全不考虑软件内部结构,只从需求出发进行验证。
    评论:
    单元测试应该是程序员自己做比较好。其他的测试应该以测试工程师为主,程序员、用户配合,这样效果比较好个人意见啊/很多不同意这个观点

    5.测试工具:
    winRunner ,Loadrunner, Rational等测试工具

    6. 软件测试中的基本词汇

    软件测试中的基本词汇 
    ü     黑盒测试 (Black box testing) ── 不考虑内部设计和代码,根据需求和功能进行测试。 

    ü     白盒测试 (White box testing) ── 根据应用软件的代码的内部逻辑,按照代码的语句、分支、路径和条件进行测试。 

    ü     功能测试 (functional testing) ── 对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。(这一原则适用于所有的测试阶段。) 

    ü     系统测试 ── 针对全部需求说明进行黑盒测试,包括系统中所有的部件。 

    ü     端到端测试 (end-to-end testing) ── 类似于系统测试,但测试范围更“宏观”一些。模仿实际应用环境,对整个应用软件进行使用测试。例如与数据库进行交互作业、使用网络通信、与其他硬件、应用程序和系统之间的相互作用是否满足要求。 

    ü     回归测试 (regression testing) ── 每当软件经过了整理、修改、或者其环境发生变化,都重复进行测试。很难说需要进行多少次回归测试,特别是是到了开发周期的最后阶段。进行此种测试,特别适于使用自动测试工具。 

    ü     负荷试验 (load testing) ── 在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况,以确定在什么情况下系统响应速度下降或是出现故障。 

    ü     压力测试 (stress testing) ── 经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况:在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询,等等。 

    ü     性能测试 (performance testing) ── 经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试) 都应在质量保障和测试计划的文档终予以规定。 

    ü     可用性测试 (usability testing) ── 是专为“对用户友好”的特性进行测试。这是一种主观的感觉,取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。 

    ü     恢复测试 (recovery testing) ── 在系统崩溃、硬件故障、或者其他灾难发生之后,重新恢复系统的情况。 

    ü     安全测试 (security testing) ── 测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。 

    ü     α 测试 (alpha testing) ── 在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。 

    ü   β 测试 (beta testing) ── 当开发和测试已基本完成,需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试,而不是由程序员和测试人员来进行。 
    ST系统测试
    IT集成测试
    UT单元测试
    SRS软件需求规格说明书
    HLD概要设计
    LLD详细设计
    CMO配置管理员
    RC需求变更
    REVIEW评审
    Alpha和Beta测试简介

    大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试,目的是从实际终端用户的使用角度,对软件的功能和性能进行测试,以发现可能只有最终用户才能发现的错误。

    Alpha测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。

    Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。因而,Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中,由用户记下遇到的所有问题,包括真实的以及主管认定的,定期向开发者报告,开发者在综合用户的报告后,做出修改,最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性,包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后,才能开始Beta测试。由于Beta测试的主要目标是测试可支持性,所以Beta测试应该尽可能由主持产品发行的人员来管理。

    由于Alpha和Beta测试的组织难度大,测试费用高,测试的随机性强、测试周期跨度较长,测试质量和测试效率难于保证,所以,很多专业软件可能不再进行Beta测试。随着测试技术的提高,以及专业测试服务机构的大量涌现,很多软件的Beta测试外包给这些专业测试机构进行测试。 

    7. 软件测试步骤

    软件测试步骤 
    •   测试过程按4个步骤进行,即单元测试、集成测试、确认测试和系统测试及发版测试。 
    •   开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。 
    •   集成测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。 
    •   确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。 
    •   系统测试把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。 
    单元测试 (Unit Testing) 
    •   单元测试又称模块测试,是针对软件设计的最小单位 ─ 程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。 
    •   单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。 
    1. 单元测试的内容 
    •   在单元测试时,测试者需要依据详细设计说明书和源程序清单,了解该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理的输入和不合理的输入,都能鉴别和响应。
    (1) 模块接口测试 
    •   在单元测试的开始,应对通过被测模块的数据流进行测试。测试项目包括: 
    –   调用本模块的输入参数是否正确; 
    –   本模块调用子模块时输入给子模块的参数是否正确; 
    –   全局量的定义在各模块中是否一致;
    •   在做内外存交换时要考虑: 
    –   文件属性是否正确; 
    –   OPEN与CLOSE语句是否正确; 
    –   缓冲区容量与记录长度是否匹配; 
    –   在进行读写操作之前是否打开了文件; 
    –   在结束文件处理时是否关闭了文件; 
    –   正文书写/输入错误, 
    –   I/O错误是否检查并做了处理。


    (2) 局部数据结构测试 
    •   不正确或不一致的数据类型说明 
    •   使用尚未赋值或尚未初始化的变量 
    •   错误的初始值或错误的缺省值 
    •   变量名拼写错或书写错 
    •   不一致的数据类型 
    •   全局数据对模块的影响 
    (3) 路径测试 
    •   选择适当的测试用例,对模块中重要的执行路径进行测试。 
    •   应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。 
    •   对基本执行路径和循环进行测试可以发现大量的路径错误。 
    (4) 错误处理测试 
    •   出错的描述是否难以理解 
    •   出错的描述是否能够对错误定位 
    •   显示的错误与实际的错误是否相符 
    •   对错误条件的处理正确与否 
    •   在对错误进行处理之前,错误条件是否已经引起系统的干预等 
    (5) 边界测试 
    •   注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例,认真加以测试。 
    •   如果对模块运行时间有要求的话,还要专门进行关键路径测试,以确定最坏情况下和平均意义下影响模块运行时间的因素。





    2. 单元测试的步骤 
    •   模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块。 
    –   驱动模块 (driver) 
    –   桩模块 (stub) ── 存根模块 




    •   如果一个模块要完成多种功能,可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作,对关键模块还要做性能测试。 
    •   对支持某些标准规程的程序,更要着手进行互联测试。有人把这种情况特别称为模块测试,以区别单元测试。 
    集成测试(Integrated Testing) 
    •   集成测试 (集成测试、联合测试) 
    •   通常,在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是: 
    –   在把各个模块连接起来的时侯,穿越模块接口的数据是否会丢失; 
    –   一个模块的功能是否会对另一个模块的功能产生不利的影响;



    –   各个子功能组合起来,能否达到预期要求的父功能; 
    –   全局数据结构是否有问题; 
    –   单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。 
    在单元测试的同时可进行集成测试, 
    发现并排除在模块连接中可能出现 
    的问题,最终构成要求的软件系统。





    •   子系统的集成测试特别称为部件测试,它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。 
    •   通常,把模块集成成为系统的方式有两种 
    –   一次性集成方式 
    –   增殖式集成方式


    1. 一次性集成方式(big bang) 
    •   它是一种非增殖式组装方式。也叫做整体拼装。 
    •   使用这种方式,首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统。 

    2. 增殖式集成方式 
    •   这种集成方式又称渐增式集成 
    •   首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统 
    •   在集成的过程中边连接边测试,以发现连接过程中产生的问题 
    •   通过增殖逐步组装成为要求的软件系统。


    (1) 自顶向下的增殖方式 
    •   这种集成方式将模块按系统程序结构,沿控制层次自顶向下进行组装。 
    •   自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。 
    •   选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能。 

    (2) 自底向上的增殖方式 
    •   这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。 
    •   因为模块是自底向上进行组装,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。



    •   自顶向下增殖的方式和自底向上增殖的方式各有优缺点。 
    •   一般来讲,一种方式的优点是另一种方式的缺点。 
    (3) 混合增殖式测试 
    •   衍变的自顶向下的增殖测试 
    –   首先对输入/输出模块和引入新算法模块进行测试; 
    –   再自底向上组装成为功能相当完整且相对独立的子系统; 
    –   然后由主模块开始自顶向下进行增殖测试。 

    •   自底向上-自顶向下的增殖测试 
    –   首先对含读操作的子系统自底向上直至根结点模块进行组装和测试; 
    –   然后对含写操作的子系统做自顶向下的组装与测试。 
    •   回归测试 
    –   这种方式采取自顶向下的方式测试被修改的模块及其子模块; 
    –   然后将这一部分视为子系统,再自底向上测试。 
    关键模块问题 
    •   在组装测试时,应当确定关键模块,对这些关键模块及早进行测试。 
    •   关键模块的特征:
    ① 满足某些软件需求;
    ② 在程序的模块结构中位于较高的层次(高层控制模块);
    ③ 较复杂、较易发生错误;
    ④ 有明确定义的性能要求。


    确认测试(Validation Testing) 
    •   确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。 
    •   对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。 

    1. 进行有效性测试(黑盒测试) 
    •   有效性测试是在模拟的环境 (可能就是开发的环境) 下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书列出的需求。 
    •   首先制定测试计划,规定要做测试的种类。还需要制定一组测试步骤,描述具体的测试用例。 

    •   通过实施预定的测试计划和测试步骤,确定 
    –   软件的特性是否与需求相符; 
    –   所有的文档都是正确且便于使用; 
    –   同时,对其它软件需求,例如可移植性、兼容性、出错自动恢复、可维护性等,也都要进行测试 

    •   在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类: 
    –   测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而这部分程序被接受。 
    –   测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。


    2. 软件配置复查 
    n   软件配置复查的目的是保证 
    u 软件配置的所有成分都齐全; 
    u 各方面的质量都符合要求; 
    u 具有维护阶段所必需的细节; 
    u 而且已经编排好分类的目录。 
    n 应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查这些文档资料的完整性和正确性。 
    验收测试(Acceptance Testing) 
    •   在通过了系统的有效性测试及软件配置审查之后,就应开始系统的验收测试。 
    •   验收测试是以用户为主的测试。软件开发人员和QA(质量保证)人员也应参加。 
    •   由用户参加设计测试用例,使用生产中的实际数据进行测试。 

    •   在测试过程中,除了考虑软件的功能和性能外,还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。 
    •   确认测试应交付的文档有: 
    –   确认测试分析报告 
    –   最终的用户手册和操作手册 
    –   项目开发总结报告。


    系统测试(System Testing) 
    •   系统测试,是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。 
    •   系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。
    α测试和β测试 
    •   在软件交付使用之后,用户将如何实际使用程序,对于开发者来说是无法预测的。 
    •   α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。 

    •   α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。 
    •   α测试可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。



    •   β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。 
    •   测试时,开发者通常不在测试现场。因而,β测试是在开发者无法控制的环境下进行的软件现场应用。 
    •   在β测试中,由用户记下遇到的所有问题,包括真实的以及主观认定的,定期向开发者报告。 

    •   β测试主要衡量产品的FLURPS。着重于产品的支持性,包括文档、客户培训和支持产品生产能力。 
    •   只有当α测试达到一定的可靠程度时,才能开始β测试。它处在整个测试的最后阶段。同时,产品的所有手册文本也应该在此阶段完全定稿。 
    测试类型 
    •   软件测试是由一系列不同的测试组成。主要目的是对以计算机为基础的系统进行充分的测试。 
    功能测试 
    功能测试是在规定的一段时间内运行软件系统的所有功能,以验证这个软件系统有无严重错误。 

    强度测试 

    强度测试是要检查在系统运行环境不正常乃至发生故障的情况下,系统可以运行到何种程度的测试。例如: 
    –   把输入数据速率提高一个数量级,确定输入功能将如何响应。 
    –   设计需要占用最大存储量或其它资源的测试用例进行测试。



    –   设计出在虚拟存储管理机制中引起“颠簸”的测试用例进行测试。 
    –   设计出会对磁盘常驻内存的数据过度访问的测试用例进行测试。 
    •   强度测试的一个变种就是敏感性测试。在程序有效数据界限内一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现,或者导致极度的性能下降的情况发生。此测试用以发现可能引起这种不稳定性或不正常处理的某些数据组合。



    性能测试 
    •   性能测试是要检查系统是否满足在需求说明书中规定的性能。特别是对于实时系统或嵌入式系统。 
    •   性能测试常常需要与强度测试结合起来进行,并常常要求同时进行硬件和软件检测。 
    •   通常,对软件性能的检测表现在以下几个方面:响应时间、吞吐量、辅助存储区,例如缓冲区,工作区的大小等、处理精度,等等。 

    恢复测试 
    恢复测试是要证实在克服硬件故障(包括掉电、硬件或网络出错等)后,系统能否正常地继续进行工作,并不对系统造成任何损害。 
    •   为此,可采用各种人工干预的手段,模拟硬件故障,故意造成软件出错。并由此检查: 
    –   错误探测功能──系统能否发现硬件失效与故障; 

    –   能否切换或启动备用的硬件; 
    –   在故障发生时能否保护正在运行的作业和系统状态; 
    –   在系统恢复后能否从最后记录下来的无错误状态开始继续执行作业,等等。 
    –   掉电测试:其目的是测试软件系统在发生电源中断时能否保护当时的状态且不毁坏数据,然后在电源恢复时从保留的断点处重新进行操作。



    配置测试 

    •   这类测试是要检查计算机系统内各个设备或各种资源之间的相互联结和功能分配中的错误。 
    •   它主要包括以下几种: 
    –   配置命令测试:验证全部配置命令的可操作性(有效性);特别对最大配置和最小配置要进行测试。软件配置和硬件配置都要测试。



    –   循环配置测试:证明对每个设备物理与逻辑的,逻辑与功能的每次循环置换配置都能正常工作。 
    –   修复测试:检查每种配置状态及哪个设备是坏的。并用自动的或手工的方式进行配置状态间的转换。 

    安全性测试 
    安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用,有无漏洞。 
    •   力图破坏系统的保护机构以进入系统的主要方法有以下几种: 
    –   正面攻击或从侧面、背面攻击系统中易受损坏的那些部分; 
    –   以系统输入为突破口,利用输入的容错性进行正面攻击;



    –   申请和占用过多的资源压垮系统,以破坏安全措施,从而进入系统; 
    –   故意使系统出错,利用系统恢复的过程,窃取用户口令及其它有用的信息; 
    –   通过浏览残留在计算机各种资源中的垃圾(无用信息),以获取如口令,安全码,译码关键字等信息; 
    –   浏览全局数据,期望从中找到进入系统的关键字; 
    –   浏览那些逻辑上不存在,但物理上还存在的各种记录和资料等。 

    可使用性测试 

    •   可使用性测试主要从使用的合理性和方便性等角度对软件系统进行检查,发现人为因素或使用上的问题。 
    •   要保证在足够详细的程度下,用户界面便于使用;对输入量可容错、响应时间和响应方式合理可行、输出信息有意义、正确并前后一致;出错信息能够引导用户去解决问题;软件文档全面、正规、确切。 

    安装测试 
    安装测试的目的不是找软件错误,而是找安装错误。 
    •   在安装软件系统时,会有多种选择。 
    –   要分配和装入文件与程序库 
    –   布置适用的硬件配置 
    –   进行程序的联结。 
    •   而安装测试就是要找出在这些安装过程中出现的错误。 


    •   安装测试是在系统安装之后进行测试。它要检验: 
    –   用户选择的一套任选方案是否相容; 
    –   系统的每一部分是否都齐全; 
    –   所有文件是否都已产生并确有所需要的内容; 
    –   硬件的配置是否合理,等等。



    容量测试 

    •   容量测试是要检验系统的能力最高能达到什么程度。例如, 
    –   对于编译程序,让它处理特别长的源程序; 
    –   对于操作系统,让它的作业队列“满员”; 
    –   对于信息检索系统,让它使用频率达到最大。 
    在使系统的全部资源达到“满负荷”的情形下,测试系统的承受能力。



    文档测试 

    这种测试是检查用户文档(如用户手册)的清晰性和精确性。 
    •   用户文档中所使用的例子必须在测试中一一试过,确保叙述正确无误。 

    自动测试 
    •   认识自动测试 
    •   什么时候使用自动测试

    8.我想问到底软件测试的流程是什么?
    具体情况具体定,大体上是:
    测试计划-测试设计-测试用例-测试执行-测试报告。
    有些人把设计和用例放在一起,有些公司是讲test case 积累,下个项目可以继续累加,增加了覆盖率。
    测试开发包括测试用例的实现/测试代码的编写等等;测试设计实现测试方案的写作

    《面向对象的软件测试》,作者 John D.McGregor

    整个测试过程来说比较复杂,在这只说一下系统测试阶段的流程,首先是开发人员的需求分析阶段,在需求分析的同时,测试人员可以提出 可测试性需求,然后需求分析初步定搞后,测试人员可以参加需求评审,当需求经过评审纳入到配置库中后,测试人员就可以开始写测试计划了,测试计划主要是规划这次测试活动,角度是从管理方面,测试计划一般都有模版,然后在根据测试计划以及需求规格说明书来写测试方案,测试方案是从技术的角度来规划本次测试活动,有了方案了我们就可以根据它和SRS来写测试用例(这些都是有模版的),测试用例是最重要的!!测试用例写好了就可以进行测试的执行了,在这些过程中都会产生一些文挡,这些文档一般是需要经过评审的。当所有的测试用例都执行完了并且相关的测试文挡都通过了评审的话,那么本次测试活动就可以结束了。。。。

    测试流程
    转眼间来了公司一个多月了,工作时间应该算是很短的了,但是测试部门就我和勇斌两个人,我还算长的了,呵呵。由于以前公司没有测试人员,所以测试流程很不完善,估计大家对测试也不是很了解。以下是我个人的一些看法。
    测试部门的职责:
    今年的主要目标有三个, 
     第一个是严格把关产品质量,所谓严格并不意味着测试会在软件项目和用户不需要的前提下,建立不合理和难以实现的质量目标。而是会进一步完善我们的现有的测试规范,严格按照规范办事。比如说,问题单改到%之多少才可以提交测试版本等等,这一点希望各位项目经理和开发人员能够理解。 如果改一个问题就出一个版本的话,我们的测试很难做的。这只是一个目标,呵呵.
     第二个要达到的目标是提供及时的测试服务,因为我们测试需要承担公司内所有项目的测试工作,而目前测试部人员缺少(就两个人),在有些情况下,开发已经完成编码工作,测试部由于人员等情况,我们可能将测试执行工作或是文档工作推后。在今后我们会尽量克服这个问题,做到能及时进行测试分析、及时执行测试、及提时提交问题单、及提交测试报告、及时编写测试用例。
     第三个目标是提高我们测试的服务水平 
      因为现在需要测试公司内的所有项目,为了更好的达到测试的目标,测试必须设法适用于我们所面对的所有项目,这样对测试人员的水平也是一个挑战(怎样部署不同的项目的测试环境、怎样对于不同的操作系统下的项目进行测试,)这些都是我们有待提高的技术;另外现在公司的同事们对测试人员已非常尊重,这一点很好,其实测试与开发一样都同一个目标就是做好每一个项目,这些也是我们今后努力的目标。 
    测试流程的定义:
    首先向大家介绍一下我理解的测试流程是什么,流程在词典上的解释是“工艺程序,从原料到制成品的各项工序安排的程序”,那测试流程就是指从软件测试开始到软件测试结束经过的一系列准备、执行、分析的过程。所以我认为测试流程并不是只存在于有完整测试团队的公司,它分布在每一个对软件执行测试的公司中,哪怕像我们这样的只有一两个测试人员的公司。
    下边是我根据咱们 公司做的一个关于bug管理的描述(公司内暂时没有bug管理工具,我正在寻找比较好的免费工具)
      测试人员(Tester)只要发现问题就立即新建一个Bug予以跟踪并发送给相关的开发小组长(Dev Lead)现在主要是通过excel表格来发送,,不好控制和管理, 
    开发小组长会判断这个Bug属于某个特定的开发人员(Dev)并指派给他处理
    开发人员会根据Bug的详细描述信息找到问题所在,修改程序解决这个Bug并把Bug返回给当初的测试人员;希望开发发送给我们版本的时候,把以前的测试报告也发送给我们,最好注明那些问题已经修改,怎么修改的。那些问题依然存在。那些问题存在争议,争议的焦点。(备注:存在争议如何处理,)
    测试人员在看到某个Bug被解决后,就去验证这个Bug是否真的不存在了,根据最初的发现步骤去证实问题真的解决了就关闭这个Bug;若还能重现,或者不同意开发人员的解法,可以激活这个Bug,返还给当初的开发人员做进一步调查处理.
    下边的这些是我自己思考的一些问题: 
    各个项目的需求,项目的完成时间,计划安排。我希望能够让我们了解更多的关于产品的信息,如果我们什么也不知道就拿一个产品进行测试,这样很难发现一些问题,甚至是一些表面的问题。我们知道了项目的安排和计划,便于我们能够合理的安排测试。
    当一个新的版本出现时,必须标明是哪个版本,修改了那些问题 。这样我们可以进行有针对性地测试。
    开发大概多长时间出一个版本,有些问题越到最后越麻烦。我希望我们能够及时地拿到版本,不要很长时间才测试一次,有些问题越到最后越难管理。
    编写测试用例。我正在考虑我们是不是需要编写一些简单的测试用例。
    这个问题是我们自己思考的,希望大家给点意见的。
    就是测试,什么叫测试完毕呢。
    我的理解就是首先你的按照正常的操作步骤,把所有的路径走一遍。我的正常的操作步骤就是客户肯定会用到的,经常用到的。然后再进行一些自由的测试,把自己能够想到的都测试一遍。

    9.请问Bug曲线是怎么会事?

    Bug曲线具体是如何定义的?

    是怎么制作出来的?

    意义是什么?

    它能反映出那些问题?(
    1)偶是这样认为的:
    从测试开始,bug被不断发现,那么这些bug与测试的日期等都有对应的关系,可以通过bug管理工具进行绘图,绘好就很容易看出bug随测试时间的变化趋势,不同的绘图方式,还能体现出什么类型的、什么级别,那个功能,谁负责的部份,由于什么原因等bug的趋势情况,这样就可以有针对性的加强那个部分,比如:bug图随着项目的逐步稳定,显示开发员A模块中的bug不断增加,没有任何递减的趋势,而其它相关开发员的模块bug不断下降,这时就要研究一下A开发员的工作了,是什么原因造成的,还是个人编码习惯等问题喽。。又比如:通过整体bug走势,可以一定程度上预测产品会达标的大概日期,因为bug曲线终归要近似趋零或达到可允许的范围(严重级别与个数)
    -在TD中可以绘制bug图附件中(有两幅刚截的参考图)
    -在testtrack中也可以.(我只发现表格形式的)

    2)严格来说,一个项目过程中的BUG走向应该是符合一定规律的,但由于我们外部条件和内部条件的因素,导致我们的曲线与书上所介绍的曲线有很大差异。 
    3)大家应该更加注重的是这个曲线有何实际意义,对于测试、开发、以及成本等有何影响,就目前的测试的环境来看,研究这个曲线意义不大。测试人员可能还管不了那许多,还有即使有权力干涉开发人员的工作,但这也不能说明什么问题,反而招来非议,程序的编写主观性与客观性都存在,从这个曲线中不能反应任何关于开发人员的问题。对开发人员的评价自有另外的方法。而这个曲线的不正常,也可能与测试人员有关,很难保证所有测试人员一直都能保持一个正常的发挥其测试能力。

    一句话:这个曲线中看不中用!最多只能直观的说明某阶段发现了多少BUG。其它什么都说明不了。
    4)我是这么看的,
    BUG曲线纵轴是Bug数,而横轴根据你自己的定义,可以产生好多种类的曲线图,你可以将横轴定义为时间,或定义为人力资源,或定义为用例数等等,根据横轴定义的不同可以产生好多Bug曲线图.就看你怎么定义,怎么发明了.当然,你的定义肯定对你以后的度量工作产生积极的意义,那你的"发明"也真正有意义和作用 
    5)如果你们的测试部门绝对独立,过程绝对严格,那这个曲线很能反映情况,否则。。。 
    6)Bug 的曲线有很多种,就拿ClearQuest中来说,你可以根据自己的需要进行定制
    一般我用的比较多的有下面几种:
    新Bug的产生曲线:主要看每天新增bug的情况,理想情况应该是开始的时候不是很多,然后很快达到高峰,急剧减少,但是中间会有小的波动,这样的曲线是比较理想的
    系统中总的Bug曲线:这个是去掉解决完的bug的图,理想的情况和尚一个差不多,只是减少的会慢一点,波动也会大一些
    Bug的修复趋势:这个土我一般拿系统中的新增Bug,当天Close的bug放在一起看
    当然还有其它很多的图,我们会根据需要进行设定。其实我的意思就是大家不要拘泥于别人的形式,要根据自己的情况来做。
    我们这里每天一个项目大概每个人能报到7-10个bug,算是挺多了。
    CQ的功能很强大,可以定制各种反应软件不同指标的表格或者曲线。至于说到如何考核的问题,也是不能依葫芦画瓢。不同的公司,不同的系统架构,不同的企业文化,对考核的指标都会有不同的看法。
    Bug的修复率本身这个指标在不同的时期,我想期望值应该不同。而且这些指标并不能反映项目的好坏,就像我们公司现在实行SQA一样,稽核没有抓住实质的东西,没有细致的曲分析,相当于是为了稽核而稽核,就失去了意义了。每次老总问他们,这个项目的异常点这么多,是不是这个项目就是做的不好?他们总是回答不出。
    我建议你可以拿以前做的一个较好的项目,统计一下它的各项指标,然后可以把这些作为一个参考值,在后面的项目中发现这个指标不合理就及时调整。

    尽信书则不如无书,很多软件测试的专业资料上的指标是一种很理想的指标,或者是很成熟的公司,体制下的指标,我们如果生搬硬套,会很痛苦。
    10.负载测试与压力测试有何区别?
    1)压力测试是在一定的负荷条件下,长时间连续运行系统给系统性能造成的影响。
    负载测试:在一定的工作负荷下,给系统造成的负荷及系统响应的时间。
    从概念上区别他们,可以看出压力测试有个长时间运行,而负载测试负载类型可能是其他类型的。
    压力测试主要是为了发现在一(任意)定条件下软件系统的性能的变化情况。通过改变应用程序的输入以对应用程序施加越来越大的负载(并发,循环操作,多用户)并测量在这些不同的输入时性能的改变,也就是通常说的概念:压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。其实这种测试也可以称为负载测试,但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。
    比如实际中我们说从比较小的负载开始,逐渐增加模拟用户的数量, 直到应用程序响应时间超时,就是说的负载测试。
    2)负载测试更多的是在正常的工作条件下,验证系统的容量是否达到要求
    例如,一个服务器,能支持10万人同时访问,那么负载测试就是要测出在用户为10万人时,服务器是否还在正常工作的状态下,例如CPU的占用,内存的占用等。
    压力测试呢一般指在超过正常负载的情况下系统的能力,例如CPU占用正常工作应该低于50%,那么如果在一定的负载下,CPU的占用率达到80%,甚至100%,那么整个系统是否还能工作,而不是down机。还有,压力测试还应该包括在大负载下的异常处理能力。
    3)负载测试主要测试在给定的负载情况下,检测系统是否达到系统预期的性能目标。
    压力测试主要是在通过系统给定的预期的性能目标情况下,在逐渐给系统进行加压,测试系统在什么样的情况下,系统会产生异常。 
    4)简单总结一下:
    压力:长时间连续运行,增加超负荷(并发,循环操作,多用户),什么时候系统会产生异常,以及异常处理能力,验证系统可靠性,找出瓶颈所在。
    负载:一个很短时间内,处理一个巨大的数据量或执行许多功能调用上的能力,验证系统预期的性能目标,响应时间等。
    11.如何设计编制软件测试用例(一~三)
    这是我们公司的培训资料,我看文件的保密级是大众级,发上来应该没事,希望对大家有点帮助,特别是新人.
    一、测试用例是软件测试的核心 
    软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。 

    影响软件测试的因素很多,例如软件本身的复杂程度、开发人员(包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等等。因为有些因素是客观存在的,无法避免。有些因素则是波动的、不稳定的,例如开发队伍是流动的,有经验的走了,新人不断补充进来;一个具体的人工作也受情绪等影响,等等。如何保障软件测试质量的稳定?有了测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全,随着测试的进行和软件版本更新,也将日趋完善。 

    因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导,是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。 

    二、什么叫测试用例 
    测试用例(Test Case)目前没有经典的定义。比较通常的说法是:指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档。 

    不同类别的软件,测试用例是不同的。不同于诸如系统、工具、控制、游戏软件,管理软件的用户需求更加不统一,变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。 

    三、编制测试用例 
    着重介绍一些编制测试用例的具体做法。 

    1、测试用例文档 
    编写测试用例文档应有文档模板,须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。 
    软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位,形成一个测试用例文档,但并不是绝对的。 

    测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息:用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果(含判断标准)、出口准则、注释等。以上内容涵盖了测试用例的基本元素:测试索引,测试环境,测试输入,测试操作,预期结果,评价标准。
    如何设计编制软件测试用例(二)

    2、测试用例的设置 
    我们早期的测试用例是按功能设置用例。后来引进了路径分析法,按路径设置用例。目前演变为按功能、路径混合模式设置用例。 

    按功能测试是最简捷的,按用例规约遍历测试每一功能。 

    对于复杂操作的程序模块,其各功能的实施是相互影响、紧密相关、环环相扣的,可以演变出数量繁多的变化。没有严密的逻辑分析,产生遗漏是在所难免。路径分析是一个很好的方法,其最大的优点是在于可以避免漏测试。 

    但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块,这些模块相互有关联。再采用路径分析法,其路径数量成几何级增长,达5位数或更多,就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。 

    3、设计测试用例 
    测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例,应该参照用例规约(或设计规格说明书),根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能,覆盖率达100%。 

    设计备选事件和异常事件的用例,则要复杂和困难得多。例如,字典的代码是唯一的,不允许重复。测试需要验证:字典新增程序中已存在有关字典代码的约束,若出现代码重复必须报错,并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件,并同时尽量发现其中的软件缺陷。 

    可以采用软件测试常用的基本方法:等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例,并最终实现暴露隐藏的缺陷,全凭测试设计人员的丰富经验和精心设计。 

    四、测试用例在软件测试中的作用 
    1、指导测试的实施 
    测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准,测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中,以便自动生成测试结果文档。 

    根据测试用例的测试等级,集成测试应测试那些用例,系统测试和回归测试又该测试那些用例,在设计测试用例时都已作明确规定,实施测试时测试人员不能随意作变动。
    如何设计编制软件测试用例(三)

    2、规划测试数据的准备 
    在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据,以及标准测试结果。尤其象测试报表之类数据集的正确性,按照测试用例规划准备测试数据是十分必须的。 
    除正常数据之外,还必须根据测试用例设计大量边缘数据和错误数据。 

    3、编写测试脚本的"设计规格说明书" 
    为提高测试效率,软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书,那么测试脚本的设计规格说明书就是测试用例。 

    4、评估测试结果的度量基准 
    完成测试实施后需要对测试结果进行评估,并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例:测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少,等等。以前统计基准是软件模块或功能点,显得过于粗糙。采用测试用例作度量基准更加准确、有效。 

    5、分析缺陷的标准 
    通过收集缺陷,对比测试用例和缺陷数据库,分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善,应立即补充相应测试用例,最终达到逐步完善软件质量。而已有相应测试用例,则反映实施测试或变更处理存在问题。 

    五、相关问题 
    1、测试用例的评审 
    测试用例是软件测试的准则,但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审,需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成,也可邀请客户代表参加。 

    2、测试用例的修改更新 
    测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故:第一、在测试过程中发现设计测试用例时考虑不周,需要完善;第二、在软件交付使用后反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成;第三、软件自身的新增功能以及软件版本的更新,测试用例也必须配套修改更新。 

    一般小的修改完善可在原测试用例文档上修改,但文档要有更改记录。软件的版本升级更新,测试用例一般也应随之编制升级更新版本。

    12.软件测试的14种类型
    软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

    1 数据和数据库完整性测试

    数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
    数据库完整性原即:
    主码完整性:主码不能为空;
    外码完整性:外码必须等于对应的主码或者为空。
    数据合理性指数据在数据库中的类型,长度,索引等是否建的比较合理。
    在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支1持测试的工具和技术。

    比如,有两张表:部门和员工。部门中有部门编号,部门名称,部门经理等字段,主码为部门编号;员工表中有员工编号,员工所属部门编号,员工名称,员工类型等字段,主码为员工编号,外码为员工所属部门编号,对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空,他就违反主码完整性原则。如果某个员工所属部门的编号为##,但是##在部门编号中确找不到,这就违反外码完整性原则。
    员工类型如下定义:0:职工,1:职员,2:实习生。但数据类型为Int,我们都知道Int占有4个字节,如果定义成char(1).就比原来节约空间。


    2 白盒测试

    白盒测试是基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
    2.1 静态白盒测试
    利用眼睛,浏览代码,凭借经验,找出代码中的错误或者代码中不符合书写规范的地方。比如,代码规范中规定,函数必须为动宾结构。而黑盒测试发现一个函数定义如下:
    Function NameGet(){
    ….
    }
    这是属于不符合开发规范的错误。
    有这样一段代码:
    if (i<0) & (i>=0)

    这段代码交集为整个数轴,IF语句没有必要
    I=0;
    while(I>100){
    J=J+100;
    T=J*PI;
    }
    在循环体内没有I的增加,bug产生。

    2.2 动态白盒测试
    利用开发工具中的调式工具进行测试。比如一段代码有4个分支,输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
    看一段代码
    if(I<0){
    P1
    }else{
    P2
    }
    在调试中输入I=-1,P1程序段通过, P2程序段未通过,属于动态黑盒测试的缺陷

    3.功能测试

    功能测试指测试软件各个功能模块是否正确,逻辑是否正确。
    对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
    比如一个对电子商务系统,前台用户浏览商品-放入购物车-进入结账台,后台处理订单,配货,付款,发货,这一系列流程必须正确无误的走通,不能存在任何的错误。

    4.UI测试

    UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等
    用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观,与测试人员的喜好有关
    比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。

    5.性能测试

    性能测试主要测试软件测试的性能,包括负载测试,强度测试,数据库容量测试,基准测试以及基准测试
    5.1负载测试
    负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
    在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
    比如,在B/S结构中用户并发量测试就是属于负载测试的用户,可以使用webload工具,模拟上百人客户同时访问网站,看系统响应时间,处理速度如何?
    5.2强度测试
    强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
    实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
    比如:一个系统在内存366M下可以正常运行,但是降低到258M下不可以运行,告诉内存不足,这个系统对内存的要求就是366M。
    5.3数据库容量测试
    数据库容量测试指通过存储过程往数据库表中插入一定数量的数据,看看相关页面是否能够及时显示数据。
    数据库容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录,计算相关页面的调用时间。
    比如,在电子商务系统中,通过insert customer 往user表中插入10 000数据,看其是否可以正常显示顾客信息列表页面,如果要求达到最多可以处理100 000个客户,但是顾客信息列表页面不能够在规定的时间内显示出来,就需要调整程序中的SQL查询语句;如果在规定的时间内显示出来,可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
    5.4基准测试
    基准测试与已知现有的系统进行比较,主要检验是否与类似的产品具有竞争性的一种测试。
    如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据,你可以测试你这套系统,看看哪些地方比用友财务系统好,哪些地方差?以便改进自己的系统,也可为产品广告提供数据。
    5.5竞争测试
    软件竞争使用各种资源(数据纪录,内存等),看他与其他相关系统对资源的争夺能力。比如:一台机器上即安装您的财务系统,又安装用友财务系统。当CPU占有率下降后,看看是否能够强过用友财务系统,而是自己的系统能够正常运行?

    6. 安全性和访问控制测试

    安全性和访问控制测试侧重于安全性的两个关键方面:
    应用程序级别的安全性,包括对数据或业务功能的访问
    系统级别的安全性,包括对系统的登录或远程访问。
    6.1应用程序级别的安全性
    可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客户的统计数据。
    比如B/S系统,不通过登入页面,直接输入URL,看其是否能够进入系统?
    6.2系统级别的安全性
    可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。
    比如输入管理员账户,检查其密码是否容易猜取,或者可以从数据库中获得?

    7.故障转移和恢复测试

    故障转移和恢复测试指当主机软硬件发生灾难时候,备份机器是否能够正常启动,使系统是否可以正常运行,这对于电信,银行等领域的软件是十分重要的。
    故障转移和恢复测试可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。 
    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
    比如电信系统,突然主机程序发生死机,备份机器是否能够启动,使系统能够正常运行,从而不影响用户打电话?
    8.配置测试

    又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。(如浏览器版本,操作系统版本等)
    下面列出主要配置测试
    8.1浏览器兼容性
    测试软件在不同产商的浏览器下是否能够正确显示与运行;
    比如测试IE,Natscape浏览器下是否可以运行这套软件?
    8.2操作系统兼容性
    测试软件在不同操作系统下是否能够正确显示与运行;
    比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件?
    8.3硬件兼容性
    测试与硬件密切相关的软件产品与其他硬件产品的兼容性,比如该软件是少在并口设备中的,测试同时使用其他并口设备,系统是否可以正确使用.
    比如在INTER,舒龙CPU芯片下系统是否能够正常运行?
    这样的测试必须建立测试实验室,在各种环境下进行测试。

    9.安装测试

    安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
    安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    10.多语种测试

    又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。
    本地化测试还要考虑:
    l 当语言从A翻译到B,字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”,翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
    l 要考虑同一单词在各个国家的不同意思,比如football在英文中为足球,而美国人使用中可能理解为美式橄榄球。
    l 要考虑各个国家的民族习惯,比如龙个美国中被理解邪恶的象征,但翻译到中国,中国人认为为吉祥的象征。

    11.文字测试

    文字测试测试软件中是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否有出入等等,包括图片文字。
    比如:“比如,请输入正确的证件号码!”何谓正确的证件号码,证件可以为身份证,驾驶证,也可为军官证,如果改为“请输入正确的身份证号码!”用户就比较容易理解了。

    12.分辨率测试

    测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

    13发布测试

    主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试

    13.1说明书测试
    主要为语言检查,功能检查,图片检查
    语言检查:检查说明书语言是否正确,用词是否易于理解;
    功能检查:功能是否描述完全,或者描述了并没有的功能等;
    图片检查::检查图片是否正确
    13.2宣传材料测试
    主要测试产品中的附带的宣传材料中的语言,描述功能,图片
    13.3帮助文件测试
    帮助文件是否正确,易懂,是否人性化。最好能够提供检索功能。
    13.4广告用语
    产品出公司前的广告材料文字,功能,图片,人性化的检查

    14 文档审核测试

    文档审核测试目前越来越引起人们的重视,软件质量不是检查出来的,而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料:

    文档审核测试主要包括需求文档测试,设计文档测试,为前置软件测试测试中的一部分。

    14.1需求文档测试

    主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;

    14.2设计文档测试

    测试设计是否符合全部需求以及设计是否合理。

    总结

    据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计,得出这样一个结论:软件缺陷在开发前期发现比在开发后期发现资金,人力上节约90%;软件缺陷在推向市场前发现比在推出后发现资金,人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的,可以根据产品的具体情况进行组装测试不同的类型。

    参考文献
    《Rational统一过程模型》
    《软件测试》 
    bug管理主要有VSS,TD,TD专业点,VSS常用在版本和文档管理
    测试软件针对不同的测试环节也分很多种
    不过,个人认为,测试新手不要把眼光盯在各种测试软件上
    首先必须对测试理论和公司的软件产品要有个基本的概念
    然后熟悉一下测试流程
    在自己写几个测试计划
    当你对测试有个比较深刻的认识后
    在去考虑应用WR.CUINT等测试软件
    我觉得这样可能更有利个人的发展

    13.软件开发全过程检测及测试自动化

      首先谈谈软件测试。这可以说是一个非常令人捉摸不定的领域。“应该怎样对我们的产品进行测试?”和“怎样才算对产品进行了足够的测试?”等问题,对于不同企业的不同类产品、同一企业的不同类产品、或不同企业的同一类产品,实际操作上都会有很大的不同。

      SEI的SW-CMM在它的成熟度第三级的“软件产品工程”关键过程域中,把软件开发周期中不同阶段的测试作为实施活动中的关键实践。(在SW-CMM版本2.0 的讨论过程中,曾经有过提议,在成熟度第二级设立一个关键过程域“软件测试管理”。但在版本2.0 的讨论稿C 中,并没有这样做。从这里我们也可以看出,SW-CMM本身也是一个人为地制定的“软件”。) 

      一般地,基于开发周期中不同阶段对不同对象所进行的测试,可划分为: 

      单元测试(unit test ):

      由编程的开发人员自行计划与完成的,针对单个或相关联的一组程序单元的测试。 

      组装测试(inegration test ):

      计划于设计阶段,由开发人员与测试人员合作完成的,针对结合起来的不同单元以及它们的接口的测试。 

      系统测试(system test ):(可认为包括“可用性与图形用户界面测试”)

      测试整个系统,以证实它满足要求所规定的功能、质量和性能等方面的特性。 

      回归测试(regression test ):

      用于验证改变了的系统或其组件仍然保持应有的特性。 

      验收测试(acceptance test ):

      测试整个系统,以保证其达到可以交付使用的状态。 

      关于上述各阶段的测试的具体内容及实现的方法,读者可参考SW-CMM及有关软件工程和软件测试的书籍。千万不要停留在只参考SW-CMM,因为该文件只讲述要做些什么,而没有介绍怎样做。同时,所有的资料中谈及的内容及方法,都是一般化的。对于一个特定软件的测试,必须经过使用者对通用的测试方法的改变及改进,才能有效和达到高效率。 

      下面,谈谈软件测试的其他方面的一些问题。 

      一个被人忽略的软件测试目的 

      在谈到测试时,许多作者都引用了Grenford J. Myers 就软件测试目的提出的以下观点: 

      1.测试是程序的执行过程,目的在于发现错误;

      2.一个好的测试用例在于能发现至今未发现的错误;

      3.一个成功的测试是发现了至今未发现的错误的测试。 

      这是一种比较狭窄的观点。作为一个清醒的、纵观全局的软件开发人员或管理者,我们应当从软件过程的角度来看测试。 

      一个被人忽略的软件测试目的是:测试可以帮助发现当前开发工作所采用的软件过程(也是一个“软件”)的缺陷,以便进行改进。(在以下的讨论中,“错误”与“缺陷”基本上认为代表相同意义。) 

      怎样理解这种说法呢? 

      首先,测试并不仅仅是为了要找出错误。分析错误产生的原因和错误在开发的哪一个阶段产生,具有非常重要的意义。 

      通过分析错误的原因,我们可以立即在开发行动中对其进行改正。同时,这种分析也能帮助我们推理出 与所分析的错误有关联的潜在错误,从而有针对性地设计出检测的方法。 

      通过分析错误产生于哪一个开发阶段、而又在哪一个阶段被发现,我们可以判断从错误的产生到错误的发现,跨越了多少个开发阶段。软件开发的一条重要原则是尽早发现与修正错误。(当然,更高的一条原则是尽量预防错误的出现。)一个错误能够超越本开发阶段而不被发现,就指明了该开发阶段的检测手段有缺陷,从而也不难有针对性地制定出加强的措施与办法。这也就是软件过程改进的一项重要内容。如果能做到在同一开发阶段发现及修正错误,该开发机构就可以预期有一个高质量的产品及一个低成本、高效率的软件过程。 

      有些项目的主持人,认为以尽快的速度把测试之前的所有开发阶段完成(实际并没有完成),早日开始测试,以图达到快速和高质量(因为似乎有更长的时间可用于测试)。实际的效果将会是俗语所说的“欲速不达”。从常识就可以知道,花开发时间去继续扩大发展前面阶段引入的错误,得出的只能是更大量的需要耗时修正的错误。 

      因此,正确分析与利用测试的结果,我们可以非常有效地进行软件过程改进。 

      软件开发全过程检测,力争本阶段修正错误 

      从上面的讨论,我们很自然的就能领会到,软件错误的发现绝不能等到测试才开始(按常规,最早的测试就是编码后的单元测试)。因此,笔者提出一个软件工程的守则:软件开发全过程检测,力争本阶段修正错误。单元测试是在软件开发的“实现阶段”才开始的,在此之前的“可行性研究与计划阶段”,“需求分析阶段”,“概要设计阶段”,和“详细设计阶段”,都必须有非常明确切实的手段与措施对开发结果进行检验,以保证阶段的正确完成。 

      怎样判断一个软件过程的优劣,怎样进行软件过程改进,都可以在这个守则的指导下进行。这个守则是简单明确的,但因企业背景、条件的不同,开发环境条件的不同,项目产品的不同,实际的软件过程的实现方法就会变化无穷。考虑实现这个原则的方法的时候,可以尽量多参考各种理论及经验,但在选择制定本企业开发实践中使用的软件过程时,就必须处处根据是否能给自身的项目带来好处,以及自身的条件进行考虑。千万不要仅仅为了满足某个“标准”的提法而做一些无实际意义的工作。要尽量避免烦琐,争取做到简单、有条理和有最大的效果。 

      软件测试的自动化 

      软件测试的工作量很大(据统计,会用到40% 的开发时间;一些可靠性要求非常高的软件,测试时间甚至占到总开发时间的60% ),但测试却是在整个软件过程中极有可能应用计算机进行自动化的工作,原因是测试的许多操作是重复性的、非智力创造性的、需求细致注意力的工作。计算机就最适合于代替人类去完成这些任务。企业在这方面的投资,会对整个开发工作的质量、成本、和周期带来非常明显的效果。 

      一些适于考虑进行自动化的测试操作为: 

      1.测试个案的生成(包括测试输入,标准输出,测试操作指令等)。

      2.测试的执行写控制(包括单机与网络多机分布运行;夜间及假日运行。测试个案调用控制;测试对象、范围、版本控制等。)。 

      3.测试结果与标准输出的对比。

      4.不吻合的测试结果的分析、记录、分类、和通报。

      5.总测试状况的统计,报表的产生。 

      测试自动化与软件配置管理是密不可分的。与测试有关的资源都应在配置管理中进行统一的计划考虑。另外,测试工具的采用也是一个提高质量的关键,有些专用的测试工具能帮助发现一些用任何测试个案都难以触及的错误。 
    14.安装与卸载测试-我的学习总结

    前几天发表了“如何进行卸载测试”的贴子,得到很多回复,这里表示感谢!
    通过认真地学习与总结前辈们的宝贵经验,现整理一部分如下,主要是加深自己对它们的理解,还有希望大家继续补充与给出建议,谢谢!
    软件安装与卸载测试是相辅相成,通过互相补充,会发现更多的测试角度,谢谢

    ============卸载测试==============
    文件----安装目录里的文件及文件夹(如:程序安装在几处的)
          非安装目录(向系统其它地方添加的文件及文件夹)
        它们包括(exe,dll,配置文件等)
    快捷方式-(桌面,菜单,任务栏,系统栏,控件面板,系统服务列表等)
    复原方面-卸载后,系统能否恢复到软件安装前的状态(包含目录结构、动态库,注册表,系统配置文件,驱动程序,关联情况等)
    卸载方式--程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具(如:优化大师)
    卸载状态--程序在运行/暂停/终止等状态时的卸载
    非正常卸载情况-卸载软件过程中,取消卸载进程,然后,观察软件能否继续正常使用
    冲击卸载--在卸载的过程中,中断电源,然后,启动计算机后,重新卸载软件,如果软件无法卸载,则重新安装软件,安装之后再重新卸载。
    卸载环境--不同的(操作系统,硬件环境,网络环境等)下进行卸载
    卸载后,该系统是否对其他的应用程序造成不正常影响(如操作系统,应用软件等)
    ==========安装测试============
    一:基本目标
    1.安装程序能正确运行
    2.程序安装正确
    3.程序安装后能正确运行
    4.完善性安装后程序能正确运行
    二:一些方面
    0、安装手册给的所有步骤得到验证;
    1、安装过程中所有缺省选项得到验证;
    2、安装过程中典型选项得到验证;
    3、测试各种不同的安装组合,并验证各种不同组合的正确性(包括参数组合,控件执行顺序组合,产品安装组件组合,产品组件安装顺序组合(如b/s)等)
    4、安装过程中异常配置或状态(非法和不合理配置)情况进行了测试(如:断电;数据库终止,网络终止等)
    5、安装后是否能产生正确的目录结构和文件,文件属性正确;
    6、安装后动态库是否正确;
    6、安装后软件能否正确运行;
    7、安装后没有生成多余的目录结构,文件,注册表信息,快捷方式等;
    9、安装测试应该在所有的运行环境上进行验证(手册上指定如:操作系统,数据库,硬件环境,网络环境等);
    10、自动安装还是手工配置安装
    11、至少要在一台笔记本上进行安装/卸载测试,因为有很多产品在笔记本中会出现问题,尤其是系统级的产品
    13、安装,该系统是否对其他的应用程序造成不正常影响(如操作系统,应用软件等)
    15.微软的测试题

    Test Paper for Software Design Engineer

    (Test time: 60 minutes)

    Name:         Date:         Location:



    Part 1: Technical Skills Set

    (请将 “ ● ”paste在您所掌握的技能程度表格内,并注明您的使用时间和相关的证书)

    技能列表 精通   熟练   掌握   了解   使用时间(月) 所获证书

    English (oral)

    English (written)

    OOP programming skills

    C/C++ (pointer, memory)

    Java

    C#

    NET

    算法&数据结构

    Win API experience –plus


    Part 2 : Technical Test

    1. 实现二分查找的递归算法的函数。(使用C++,不建议用伪码) 











    2. 请指出该程序的错误。

    #include <iostream.h>



    int *p;



    void Function();

    {

    int n;

    n = 25; 

    p = &n;

    }



    void main()

    {

    Function(); 

    cout<<"value of *p: "<<*p<<endl;

    }













    3. 英语写作

    Question: Please describe your career path in the next two years.
    16. 多线程与多进程
    线程的外壳是进程,进程管理线程;
    线程不占用系统资源,而进程占用系统资源;
    什么叫进程?进程同程序有什么区别? 
    答:进程是程序在计算机上的一次执行活动。当你运行一个程序,你就启动了一个进程。显然,程序是死的(静态的),进程是活的(动态的)。进程可以分为系统进程和用户进程。凡是用于完成操作系统的各种功能的进程就是系统进程,它们就是处于运行状态下的操作系统本身;用户进程就不必我多讲了吧,所有由你启动的进程都是用户进程。进程是操作系统进行资源分配的单位。 
    在Windows下,进程又被细化为线程,也就是一个进程下有多个能独立运行的更小的单位。
    在同一个时间里,同一个计算机系统中如果允许两个或两个以上的进程处于运行状态,这便是多任务。现代的操作系统几乎都是多任务操作系统,能够同时管理多个进程的运行。 多任务带来的好处是明显的,比如你可以边听mp3边上网,与此同时甚至可以将下载的文档打印出来,而这些任务之间丝毫不会相互干扰。那么这里就涉及到并行的问题,俗话说,一心不能二用,这对计算机也一样,原则上一个CPU只能分配给一个进程,以便运行这个进程。我们通常使用的计算机中只有一个CPU,也就是说只有一颗心,要让它一心多用,同时运行多个进程,就必须使用并发技术。实现并发技术相当复杂,最容易理解的是“时间片轮转进程调度算法”,它的思想简单介绍如下:在操作系统的管理下,所有正在运行的进程轮流使用CPU,每个进程允许占用CPU的时间非常短(比如10毫秒),这样用户根本感觉不出来CPU是在轮流为多个进程服务,就好象所有的进程都在不间断地运行一样。但实际上在任何一个时间内有且仅有一个进程占有CPU。 
     如果一台计算机有多个CPU,情况就不同了,如果进程数小于CPU数,则不同的进程可以分配给不同的CPU来运行,这样,多个进程就是真正同时运行的,这便是并行。但如果进程数大于CPU数,则仍然需要使用并发技术。 
      在Windows中,进行CPU分配是以线程为单位的,一个进程可能由多个线程组成,这时情况更加复杂,但简单地说,有如下关系: 

      总线程数<= CPU数量:并行运行 

      总线程数> CPU数量:并发运行 

      并行运行的效率显然高于并发运行,所以在多CPU的计算机中,多任务的效率比较高。但是,如果在多CPU计算机中只运行一个进程(线程),就不能发挥多CPU的优势。 

    这里涉及到多任务操作系统的问题,多任务操作系统(如Windows)的基本原理是:操作系统将CPU的时间片分配给多个线程,每个线程在操作系统指定的时间片内完成(注意,这里的多个线程是分属于不同进程的).操作系统不断的从一个线程的执行切换到另一个线程的执行,如此往复,宏观上看来,就好像是多个线程在一起执行.由于这多个线程分属于不同的进程,因此在我们看来,就好像是多个进程在同时执行,这样就实现了多任务.Whoops,真绕口.

    所以结合楼上的答复,不知道楼主是否可以满意!

    关于多线程,多进程的问题,楼主可以看看操作系统方面的书,可以得到更多的启示! 


      如上,多线程和多任务是有很明显的区别的.但是再想一下,在一个应用程序内实现多线程不也是靠CPU分配时间片吗?既然原理是相同的,那么多线程也可以说是多任务的. 

    17.回归测试
    回归测试和验证修复的bug不是等同的.回归测试要求在新的版本中,重新遍历测试用例,因为开发人员在解决问题时可能会影响到相关的模块,只验证修复的问题是否已经解决不能叫做回归测试.
    我们最新采用的回归测试的方法是:把所有的测试说明中的用例全部执行一遍!(很麻烦的说)
    然后对于初次测试出问题的地方及其边缘重点测试!
    1、关于Bug的状态前面有帖子楼主可以看看,开发人员如果认为Bug已修复,应把Bug的状态改成Resolved,测试人员发现有Resolved的Bug就要进行回归测试以验证Bug是否真的解决,如验证通过则将Bug的状态改成Verified Pass,然后再由相关人员(如测试负责人)把Bug的装体改成Closed;如验证失败则将Bug的状态改成Verified Fail,让开发人员再去解决。
    2、关于楼主提到的“但是在测试用例很多的情况下,自己可能也不记得那些测试用例中有实际结果与期望结果不一致的用例”说明Bug的提交和记录存在问题,Bug所对应的测试用例编号是肯定要包含在Bug报告中的,这样回归测试的时候就不会搞不清楚了。
    3、现在开源的Bug管理工具也是有的,如bugzilla,最好还是去装一个吧。

    Bug的状态各个公司会不同,多少也不一样,我原来在德公司就有30来种状态。呵呵!
    一般只要能够区分下面几种情况,并且不让人误解就好了
    1,新提交的Bug
    2,开发正在修改的Bug
    3,已经修改好并且等待测试人员验证的Bug
    4,验证通过的Bug
    5,验证没有通过的Bug(这个要和新提交的Bug同样处理,不过有的公司需要记住没有改好的次数,用来考评开发的绩效)
    6,设计问题
    7,测试人员报错
    8,暂时不修改的Bug
    回归测试的方法具体问题具体分析,可能有人说我这样等于什么都没说,可是每个项目不同,不同时期也不同,甚至可能测试的人员都换了,如果以一种固定的方法来做,未免显得有点死板。个人认为,在测试的时候,最好能够边测试,边在测试用例上加上备注,说明实际结果。并且最好用颜色标记,如果你够仔细,能够把有问题的测试用例再标注上Bug的编号就更好了,这样在复查bug时,就知道修改好的bug是由哪个用例引起的,可以执行一下相关的用例,看是否真的改好并且没有影响到其他部分,这样就可以放心的Close了。如果有人觉得这样太过麻烦或者中途有人员的变动,也可以只看Bug的描述,按照bug的说明进行验证就够了,但是要记住最好能够对相关的模块进行一下测试,看看流程是否还能走通。不过这就要求Bug的描述要写得比较清晰,明了。
    18.测试大纲和测试计划

    测试大纲只是简单的描述如何开展测试,而测试计划是针对测试中的每个环节的。单元测试、集成测试、系统测试等一般都写测试计划,写的重点不同。而大纲只是简要的写一下测试策略是什么,需要做哪些测试,测试过程如何组织,测试人员包括哪些。可以说管理人员写测试大纲,而测试人员写测试计划。 

    19.测试版本大全-转贴

    alpha 内部测试版
      beta 外部测试版
      demo 演示版
      Enhance 增强版或者加强版 属于正式版
      Free 自由版
      Full version 完全版 属于正式版
      shareware 共享版
      Release 发行版 有时间限制
      Upgrade 升级版
      Retail 零售版
      Cardware 属共享软件的一种,只要给作者回复一封电邮或明信片即可。(有的作者并由此提供注册码等),目前这种形式已不多见。
      Plus 属增强版,不过这种大部分是在程序界面及多媒体功能上增强。
      Preview 预览版
      Corporation & Enterprise 企业版
      Standard 标准版
      Mini 迷你版也叫精简版只有最基本的功能
      Premium -- 贵价版
      Professional -- 专业版
      Express -- 特别版
      Deluxe -- 豪华版
      Regged -- 已注册版
      CN -- 简体中文版
      CHT -- 繁体中文版
      EN -- 英文版
      Multilanguage -- 多语言版
      Rip 是指从原版文件(一般是指光盘或光盘镜像文件)直接将有用的内容(核心内容)分离出来,剔除无用的文档,例如PDF说明文件啊,视频演示啊之类的东西,也可以算做是精简版吧…但主要内容功能是一点也不能缺少的!另:DVDrip是指将视频和音频直接从DVD光盘里以文件方式分离出来。
      trail 试用版(含有某些限制,如时间、功能,注册后也有可能变为正式版)
      RC 版。是 Release Candidate 的缩写,意思是发布倒计时,该版本已经完成全部功能并清除大部分的BUG。到了这个阶段只会除BUG,不会对软件做任何大的更改。 
      RTM 版。这基本就是最终的版本,英文是 Release To Manufactur,意思是发布到生产商。
      Original Equipment Manufacturer (OEM) 
      You may license products through an Original Equipment Manufacturer (OEM). These products, such as Windows operating systems, come installed when you purchase a new computer. 
      OEM软件是给电脑生产厂的版本,无需多说。 
      Full Packaged Product (FPP)-Retail 
      Physical, shrink-wrapped boxes of licensed product that can be purchased in a local retail store or any local software retailer. 
      FPP就是零售版(盒装软件),这种产品的光盘的卷标都带有"FPP"字样,比如英文WXP Pro的FPP版本的光盘卷标就是WXPFPP_EN,其中WX表示是Windows XP,P是Professional(H是Home),FPP表明是零售版本,EN是表明是英语。获得途径除了在商店购买之外,某些MSDN用户也可以得到。 
      Volume Licensing for Organizations (VLO) 
      You may enjoy potentially significant savings by acquiring multiple product licenses. Depending on the size and type of your organization. 
      团体批量许可证(大量采购授权合约),这是为团体购买而制定的一种优惠方式。这种产品的光盘的卷标都带有"VOL"字样,取"Volume"前3个字母,以表明是批量,比如英文WXP Pro的VOL版本的光盘卷标就是WXPVOL_EN,其中WX表示是Windows XP,P是Professional(VOL没有Home版本),VOL表明是团体批量许可证版本,EN是表明是英语。获得途径主要是集团购买,某些MSDN用户也可以得到。 
    这种版本根据购买数量等又细分为“开放式许可证”、“选择式许可证”、“企业协议”、“学术教育许可证”等以下5种版本 
      Open License 
      Select License 
      Enterprise Agreement 
      Enterprise Subscription Agreement 
      Academic Volume Licensing 
      由此可见,平时说的什么select/corp是许可证授权方式,他的出现是为了用若干种不同级别的优惠政策卖同一种软件,通过select/corp许可证授权方式得到的xxx的光盘都是VOL这一种、是并不是有很多种,只不过是相同的VOL光盘配以不同的许可证方式;而Volume Licensing (Product) Keys,即VLK,它所指的只是一个Key(密匙),仅仅是一个为证明产品合法化、以及安装所使用的Key,因为根据VOL计划规定,VOL产品是不需要激活的! 
      或者说,VLK不是指一种版本,而是指这种版本在部署(deploy)过程中所需要的Key,而需要VLK这种Key的版本应该叫做VOL!只不过在实际中,没有必要强调这种叫法、称呼的准确性,加之很多人的VOL版本光盘是通过企业的选择式许可证、企业协议等方式得到的等等原因,所以才会有很多人叫他为“选择版”等等。 
    官方网站有一个表格,上面有一句话:“Different products require different Volume Licensing Keys (VLKs). Refer to the table below to make sure you have the correct VLK for your Microsoft product.”,我想这就很好的说明了VLK指的是Key而不是产品了。 很明显的,FPP需要激活,VOL不需要激活。
    20. 黑、白盒测试

    白盒测试和黑盒测试不是决然分开的,单独做黑盒测试或白盒测试都是做了测试的一个方面,很难保证发现了软件中大部分缺陷。在测试过程中往往把两者结合起来进行测试,从代码逻辑结构上保证正确,再从功能和非功能特性上保证正确,经过这两方面的测试,才能最大可能的保证软件质量。在测试过程中,采用这两种测试技术的时间有所不同。

    单元测试、集成测试、系统测试是按照测试的阶段来进行划分的,而白盒测试、黑盒测试是从测试技术的角度来划分的。一般来说,单元测试阶段进行的测试基本上以白盒测试技术为主,系统测试阶段进行的测试基本上以黑盒测试技术为主,而集成测试所采用的技术是介于白盒和黑盒之间的,有的技术文献也称之为灰盒技术

    软件测试是一个过程,一个完整的软件测试过程又分为三个阶段,分别是单元集成和系统(当然还有写别的测试过程),而黑盒和白盒只是在这些过程中所采用的测试方法罢了。 

    个人意见
    1. 黑盒测试
    黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。
    黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。 
    2. 白盒测试
      白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。
      “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。
    3. 灰盒测试
    灰盒测试,确实是介于二者之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。
    灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
    灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识盒与之交互的环境,能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
      灰盒测试涉及输入和输出,但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。
    21.Software Testing 10 Rules
    1. Test early and test often.
    尽早测试,经常测试
    2. Integrate the application development and testing life cycles. You'll get better results and you won't have to mediate between two armed camps in your IT shop.(这后半句怎么理解?)
    整合应用程序开发和软件测试生命周期,你将得到更好的结果,并且不必要在程序开发和软件测试两者之间左右为难。
    3. Formalize a testing methodology; you'll test everything the same way and you'll get uniform results.
    形成一套完整的测试方法;你将用同样的方法开展测试工作,并且可以得到始终如一的结果
    4. Develop a comprehensive test plan; it forms the basis for the testing methodology.
    开发一套完整、全面的的测试计划;作为软件测试方法论的基础部分
    5. Use both static and dynamic testing.
    采用静态测试和动态测试相结合的方法(可以采用静态代码检查工具作静态测试)
    6. Define your expected results.
    定义测试预期结果(在测试用例中,这是比不可少的项目)
    7. Understand the business reason behind the application. You'll write a better application and better testing scripts.
    理解应用背后的商业动机,找出真正的需求根源,你将写出更好的应用程序和测试脚本。
    8. Use multiple levels and types of testing (regression, systems, integration, stress and load).
    采用多层面和多类型的软件测试(回归测试、系统测试、集成测试、压力测试和负载测试)
    9. Review and inspect the work, it will lower costs.
    多工作评审和检视,可以降低成本(检视和评审可以提早发现问题,规避问题,避免造成不必要的损失,因此,可以降低成本)
    10. Don't let your programmers check their own work; they'll miss their own errors.

    不要让程序员检查自己的工作产品,程序员会忽略自己犯的错误。

    转:http://blog.csdn.net/xyky_gxm/article/details/1652660

    展开全文
  • web测试点1.1 输入框1.1.1 字符型输入框1.1.2 数值型输入框1.1.3 日期型输入框1.1.4 信息重复1.2 搜索功能1.2.1 功能实现1.2.2 组合测试1.3 添加,修改功能1.3.1 特殊键1.3.2 提示信息1.3.3 唯一性1.3.4 数据正确性...

    1. web测试点

    1.1 输入框

    1.1.1 字符型输入框

    1. 字符型输入框:英文全角、英文半角、数字、空或者空格、特殊字“~!@#¥%……&*?[]{}”特别要注意单引号和&符号。禁止直接输入特殊字符时,使用“粘贴、拷贝”功能尝试输入。
    2. 长度检查:最小长度、最大长度、最小长度-1、最大长度+1、输入超工字符比如把整个文章拷贝过去。
    3. 空格检查:输入的字符间有空格、字符前有空格、字符后有空格、字符前后有空格。
    4. 多行文本框输入:允许回车换行、保存后再显示能够保存输入的格式、仅输入回车换行,检查能否正确保存(若能,检查保存结果,若不能,查看是否有正常提示)。
    5. 安全性检查:输入特殊字符串(null,NULL,javascript,)、 doucment.write(“abc”)、hello)。

    1.1.2 数值型输入框

    1. 边界值:最大值、最小值、最大值+1、最小值-1。
    2. 位数:最小位数、最大位数、最小位数-1最大位数+1、输入超长值、输入整数。
    3. 异常值、特殊字符:输入空白(NULL)、空格或"~!@#$%^&*()_+{}|[]:"<>?;’,./?;:’-=等可能导致系统错误的字符、禁止直接输入特殊字符时,尝试使用粘贴拷贝查看是否能正常提交、word中的特殊功能,通过剪贴板拷贝到输入框,分页符,分节符类似公式的上下标等、数值的特殊符号如∑,㏒,㏑,∏,+,-等、输入负整数、负小数、分数、输入字母或汉字、小数(小数前0点舍去的情况,多个小数点的情况)、首位为0的数字如01、02、科学计数法是否支持1.0E2、全角数字与半角数字、数字与字母混合、16进制,8进制数值、货币型输入(允许小数点后面几位)。
    4. 安全性检查:不能直接输入就copy。

    1.1.3 日期型输入框

    1. 合法性检查:(输入0日、1日、32日)、月输入[1、3、5、7、8、10、12]、日输入[31]、月输入[4、6、9、11]、日输入[30] [31]、输入非闰年,月输入[2],日期输入[28、29]、输入闰年,月输入[2]、日期输入[29、30]、月输入[0、1、12、13]。
    2. 异常值、特殊字符:输入空白或NULL、输入~!@#¥%……&*(){}[]等可能导致系统错误的字符。
    3. 安全性检查:不能直接输入,就copy,是否数据检验出错?

    1.1.4 信息重复

    1. 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。

    1.2 搜索功能

    若查询条件为输入框,则参考输入框对应类型的测试方法

    1.2.1 功能实现

    1. 如果支持模糊查询,搜索名称中任意一个字符是否能搜索到。
    2. 比较长的名称是否能查到。
    3. 输入系统中不存在的与之匹配的条件。
    4. 用户进行查询操作时,一般情况是不进行查询条件的清空,除非需求特殊说明。

    1.2.2 组合测试

    1. 不同查询条件之间来回选择,是否出现页面错误(单选框和多选框最容易出错)。
    2. 测试多个查询条件时,要注意查询条件的组合测试,可能不同组合的测试会报错。

    1.3 添加,修改功能

    1.3.1 特殊键

    1. 是否支持Tab键
    2. 是否支持回车键。

    1.3.2 提示信息

    1. 不符合要求的地方是否有错误提示。

    1.3.3 唯一性

    1. 字段唯一的,是否可以重复添加,添加后是否能修改为已存在的字段(字段包括区分大小写以及在输入的内容前后输入空格,保存后,数据是否真的插入到数据库中,注意保存后数据的正确性)。

    1.3.4 数据正确性

    1. 对编辑页的每个编辑项进行修改,点击保存,是否可以保存成功,检查想关联的数据是否得到更新。
    2. 进行必填项检查(即是否给出提示以及提示后是否依然把数据存到数据库中;是否提示后出现页码错乱等)。
    3. 是否能够连续添加(针对特殊情况)。
    4. 在编辑的时候,注意编辑项的长度限制,有时在添加的时候有,在编辑的时候却没有(注意要添加和修改规则是否一致)。
    5. 对于有图片上传功能的编辑框,若不上传图片,查看编辑页面时是否显示有默认的图片,若上传图片,查看是否显示为上传图片。
    6. 修改后增加数据后,特别要注意查询页面的数据是否及时更新,特别是在首页时要注意数据的更新。
    7. 提交数据时,连续多次点击,查看系统会不会连续增加几条相同的数据或报错。
    8. 若结果列表中没有记录或者没选择某条记录,点击修改按钮,系统会抛异常。

    1.4 删除功能

    1.4.1 特殊键

    1. 是否支持Tab键
    2. 是否支持回车键。

    1.4.2 提示信息

    1. 不选择任何信息,直接点击删除按钮,是否有提示
    2. 删除某条信息时,应该有确认提示。

    1.4.3 数据实现

    1. 是否能连续删除多个产品
    2. 当只有一条数据时,是否可以删除成功
    3. 删除一条数据后,是否可以添加相同的数据
    4. 如系统支持批量删除,注意删除的信息是否正确
    5. 如有全选,注意是否把所有的数据删除
    6. 删除数据时,要注意相应查询页面的数据是否及时更新
    7. 如删除的数据与其他业务数据关联,要注意其关联性(如删除部门信息时,部门下游员工,则应该给出提示)
    8. 如果结果列表中没有记录或没有选择任何一条记录,点击删除按钮系统会报错。

    如:某一功能模块具有最基本的增删改查功能,则需要进行以下测试
    单项功能测试(增加、修改、查询、删除)
    增加——>增加——>增加(连续增加测试)
    增加——>删除
    增加——>删除——>增加(新增加的内容与删除内容一致)
    增加——>修改——>删除
    修改——>修改——>修改(连续修改测试)
    修改——>增加(新增加的内容与修改前内容一致)
    修改——>删除
    修改——>删除——>增加(新增加的内容与删除内容一致)
    删除——>删除——>删除(连续删除测试)


    1.5 注册、登录模块

    1.5.1 注册功能

    1. 注册时,设置密码为特殊版本号,检查登录时是否会报错;
    2. 注册成功后,页面应该以登陆状态跳转到首页或指定页面;
    3. 在注册信息中删除已输入的信息,检查是否可以注册成功。

    1.5.2 登录功能

    1. 输入正确的用户名和正确的密码;
    2. 输入正确的用户名和错误的密码;
    3. 输入错误的用户名和正确的密码;
    4. 输入错误的用户名和错误的密码;
    5. 不输入用户名和密码(均为空格);
    6. 只输入用户名,密码为空;
    7. 用户名为空,只输入密码;
    8. 输入正确的用户名和密码,但是不区分大小写;
    9. 用户名和密码包括特殊字符;
    10. 用户名和密码输入超长值;
    11. 已删除的用户名和密码;
    12. 登录时,当页面刷新或重新输入数据时,验证码是否更新。

    1.6 上传图片测试

    1.6.1 功能实现

    1. 文件类型正确、大小合适;
    2. 文件类型正确,大小不合适;
    3. 文件类型错误,大小合适;
    4. 文件类型和大小都合适,上传一个正在使用中的图片;
    5. 文件类型大小都合适,手动输入存在的图片地址来上传;
    6. 文件类型和大小都合适,输入不存在的图片地址来上传;
    7. 文件类型和大小都合适,输入图片名称来上传;
    8. 不选择文件直接点击上传,查看是否给出提示;
    9. 连续多次选择不同的文件,查看是否上传最后一次选择的文件。

    1.7 查询结果列表

    1.7.1 功能实现

    1. 列表、列宽是否合理;
    2. 列表数据太宽有没有提供横向滚动;
    3. 列表的列名有没有与内容对应;
    4. 列表的每列的列名是否描述的清晰;
    5. 列表是否把不必要的列都显示出来;
    6. 点击某列进行排序,是否会报错(点击查看每一页的排序是否正确);
    7. 双击或单击某列信息,是否会报错。

    1.8 返回键检查

    1. 一条已经成功提交的记录,返回后再提交,是否做了处理;
    2. 检查多次使用返回键的情况,在有返回键的地方,返回到原来的页面多次,查看是否会出错。

    1.9 回车键检查

    1. 在输入结果后,直接按回车键,看系统如何处理,是否会报错。

    1.10 刷新键检查

    1. 在Web系统中,使用刷新键,看系统如何处理,是否会报错。

    1.11 测试点检查

    直接URL链接检查:

    在Web系统中,在地址栏直接输入各个功能页面的URL地址,看系统如何处理,是否能够直接链接查看(匿名查看),是否有权限控制,是否直接执行,并返回相应结果页;

    n 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。可以使用一些工具,如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。

    n HTML Link Validater只能测试以Html或者htm结尾的网页链接;

    n Xenu无需安装,支持asp、do、jsp等结尾的网页,xenu测试链接包括内部链接和外部链接,在使用的时候应该注意,同时能够生成html格式的测试报告。

    相关性检查:

    功能相关性:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确,常见的情况是,增加某个数据记录以后,如果该数据记录某个字段内容较长,可能会在查询的时候让数据列表变形。

    数据相关性:下来列表默认值检查,下来列表值检查,如果某个列表的数据项依赖于其他模块中的数据,同样需要检查,比如,某个数据如果被禁用了,可能在引用该数据项的列表中不可见。

    检查按钮的功能是否正确:

    如新建、编辑、删除、关闭、返回、保存、导入,上一页,下一页,页面跳转,重置等功能是否正确。常见的错误会出现在重置按钮上,表现为功能失效。

    字符串长度检查:
    输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。还要检查需求规定的字符串长度是否是正确的,有时候会出现,需求规定的字符串长度太短而无法输入业务数据。

    字符类型检查:
    在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型。

    标点符号检查:
    输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理,可能添加的时候,将空格当作一个字符,而在查询的时候空格被屏蔽,导致无法查询到添加的内容。

    特殊字符检查:
    输入特殊符号,如@、#、$、%、!等,看系统处理是否正确。常见的错误是出现在% ‘ \ 这几个特殊字符

    中文字符处理:
    在可以输入中、英文的系统输入中文,看会否出现乱码或出错。

    检查信息的完整性:
    在查看信息和更新信息时,查看所填写的信息是不是全部更新,更新信息和添加信息是否一致。要注意检查的时候每个字段都应该检查,有时候,会出现部分字段更新了而个别字段没有更新的情况。

    信息重复:
    在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理。

    检查删除功能:
    在一些可以一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除, 看是否正确处理。如果有多页,翻页选,看系统是否都正确删除,并且要注意,删除的时候是否有提示,让用户能够更正错误,不误删除。

    检查添加和修改是否一致:
    检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

    检查修改重名:
    修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

    重复提交表单:
    一条已经成功提交的纪录,返回后再提交,看看系统是否做了处理。对于WEB系统来说,可以通过浏览器返回键或者系统提供的返回功能。

    检查多次使用返回键的情况:
    在有返回键的地方,返回到原来页面,重复多次,看会否出错。

    搜索检查:
    有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.如果可以输入多个搜索条件,可以同时添加合理和不合理的条件,看系统处理是否正确,搜索的时候同样要注意特殊字符,某些系统会在输入特殊字符的时候,将系统中所有的信息都搜索到。

    输入信息位置:
    注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。

    上传下载文件检查:
    上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。下载文件能否打开或者保存,下载的文件是否有格式要求,如需要特殊工具才可以打开等。上传文件测试同时应该测试,如果将不能上传的文件后缀名修改为可以上传文件的后缀名,看是否能够上传成功,并且,上传文件后,重新修改,看上传的文件是否存在。

    必填项检查:
    应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加“*”;对必填项提示返回后,焦点是否会自动定位到必填项。

    快捷键检查:
    是否支持常用快捷键,如Ctrl+C、 Ctrl+V、 Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。

    回车键检查:
    在输入结束后直接按回车键,看系统处理如何,会否报错。这个地方很有可能会出现错误。

    刷新键检查:
    在Web系统中,使用浏览器的刷新键,看系统处理如何,会否报错。

    回退键检查:
    在Web系统中,使用浏览器的回退键,看系统处理如何,会否报错。对于需要用户验证的系统,在退出登录后,使用回退键,看系统处理如何;多次使用回退键,多次使用前进键,看系统如何处理。

    直接URL链接检查:
    在Web系统中,直接输入各功能页面的URL地址,看系统如何处理,对于需要用户验证的系统更为重要。如果系统安全性设计的不好,直接输入各功能页面的URL地址,很有可能会正常打开页面。

    空格检查:
    在输入信息项中,输入一个或连串空格,查看系统如何处理。如对于要求输入整型、符点型变量的项中,输入空格,既不是空值,又不是标准输入。

    输入法半角全角检查:
    在输入信息项中,输入半角或全角的信息,查看系统如何处理。如对于要求输入符点型数据的项中,输入全角的小数点(“。”或“.”,如4.5);输入全角的空格等。

    密码检查:
    一些系统的加密方法采用对字符Ascii码移位的方式,处理密码加密相对较为简单,且安全性较高,对于局域网系统来说,此种方式完全可以起到加密的作用,但同时,会造成一些问题,即大于128的Ascii对应的字符在解密时无法解析,尝试使用“uvwxyz”等一些码值较大的字符作为密码,同时,密码尽可能的长,如17位密码等,造成加密后的密码出现无法解析的字符。

    用户检查:
    任何一个系统,都有各类不同的用户,同样具有一个或多个管理员用户,检查各个管理员之间是否可以相互管理,编辑、删除管理员用户。同时,对于一般用户,尝试删除,并重建同名的用户,检查该用户其他信息是否重现。同样,提供注销功能的系统,此用户再次注册时,是否作为一个新的用户。而且还要检查该用户的有效日期,过了有效日期的用户是不能登录系统的。容易出现错误的情况是,可能有用户管理权限的非超级管理员,能够修改超级管理员的权限。

    系统数据检查:
    这是功能测试最重要的,如果系统数据计算不正确,那么功能测试肯定是通不过的。数据检查根据不同的系统,方法不同。对于业务管理平台,数据随业务过程、状态的变化保持正确,不能因为某个过程出现垃圾数据,也不能因为某个过程而丢失数据。

    系统可恢复性检查:
    以各种方式把系统搞瘫,测试系统是否可正常迅速恢复。

    确认提示检查:
    系统中的更新、删除操作,是否提示用户确认更新或删除,操作是否可以回退(即是否可以选择取消操作),提示信息是否准确。事前或事后提示,对于Update或Delete操作,要求进行事前提示。

    数据注入检查:
    数据注入主要是对数据库的注入,通过输入一些特殊的字符,如“’”,“/”,“-”等或字符组合,完成对SQL语句的破坏,造成系统查询、插入、删除操作的SQL因为这些字符而改变原来的意图。如select * from tablewhere id = ‘’ and name = ‘ ’,通过在id输入框中输入“12’-”,会造成查询语句把name条件注释掉,而只查询id=12的记录。同样,对于update和delete的操作,可能会造成误删除数据。当然还有其它一些SQL注入方法,具体可以参考《SQL应用高级SQL注入.doc》,很多程序都是基于页面对输入字符进行控制的,可以尝试跳过界面直接向数据库中插入数据,比如用Jmeter,来完成数据注入检查。

    刷新检查:
    web系统中的WebForm控件实时刷新功能,在系统应用中有利有弊,给系统的性能带来较大的影响。测试过程中检测刷新功能对系统或应用造成的影响(白屏),检查控件是否回归默认初始值,检查是否对系统的性能产生较大影响(如每次刷新都连接数据库查询等)。

    事务检查:
    对于事务性操作,断开网络或关闭程序来中断操作,事务是否回滚。

    时间日期检查:
    时间、日期验证是每个系统都必须的,如2006-2-29、2006-6-31等错误日期,同时,对于管理、财务类系统,每年的1月与前一年的12月(同理,每年的第1季度与前一年的第4季度)。另外,对于日期、时间格式的验证,如2006年2月28日、2006-2-28、 20060228等。日期检查还要检查日期范围是否符合实际的业务,对于不符合时间业务的日期,系统是否会有提示或者有限制

    多浏览器验证:
    越来越多的各类浏览器的出现,用户访问Web程序不再单单依赖于IE,而是有了更多的选择:Chrome、Firefox、Safari等,考虑使用多种浏览器访问系统,验证效果。

    安装测试:
    对于C/S架构的系统,安装程序的测试是一个重要方面,安装程序自动化程度、安装选项和设置(验证各种方案是否都能正常安装)、安装过程中断测试、安装顺序测试(分布式系统)、修复安装及卸载测试。

    文档测试:
    主要是对用户使用手册、产品手册进行测试,校验是否描述正确、完整,是否与当前系统版本对照,是否易理解,是否二义性等。

    测试数据检查:
    事实告诉我们,测试数据比代码更有可能是错的,因此,当测试结果显示有错误发生的时候,怀疑代码错误前要先对测试数据检查一遍。

    请让我的机器来运行:
    在某些项目中,出现一个病态的问题:系统没有问题呀,它在我的机器上是能够通过的。这就说明了其中存在着和环境相关的BUG。 “是否所有的一切都受到了版本控制工具的管理?”、“本机的开发环境和服务器的环境是否一样?”、“这里是否存在一个真正的BUG,只不过是在其他的机器里偶然出现?”。所有的测试必须在所有系统要求的机器上运行通过,否则的话,代码就可能存在问题。

    Ajax技术的应用:
    Ajax有很多优点,但也有很多缺点,如果利用优点、避免缺点,是我们对新的Web2.0应用的一个挑战。而Ajax的应用最直接的问题就是用户体验,用户体验的效果直接关系到是否使用Ajax技术。“会做,并不意味着应该做、必须做”,这就是对Ajax技术的很重要的注解。

    Ajax技术的应用:
    Ajax采用异步调用的机制实现页面的部分刷新功能,异步调用存在异常中断的可能,尝试各种方法异常中断异步的数据调用,查看是否出现问题。在这里遇到的一个问题就是对日期控件的操作,已经如果页面数据较多的时候的刷新。

    脚本错误:
    随着Ajax、IFrame等异步调用技术的发展,Javascrīpt技术也越来越受到开发人员的重视,但Javascrīpt存在调试困难、各浏览器存在可能不兼容等问题,因此在Web系统中,可能会出现脚本错误。同时,脚本错误造成的后果可大、可小。


    1.12 界面和易用性测试

    1. 风格、样式、颜色是否协调
    2. 界面布局是否整齐、协调(保证全部显示出来的,尽量不要使用滚动条)
    3. 界面操作、标题描述是否恰当(描述有歧义、注意是否有错别字)
    4. 操作是否符合人们的常规习惯(有没有把相似的功能的控件放在一起,方便操作)
    5. 提示界面是否符合规范(不应该显示英文的cancel、ok,应该显示中文的确定等)
    6. 界面中各个控件是否对齐界面中各个控件是否对齐
    7. 日期控件是否可编辑日期控件是否可编辑
    8. 日期控件的长度是否合理,以修改时可以把时间全部显示出来为准
    9. 查询结果列表列宽是否合理、标签描述是否合理
    10. 查询结果列表太宽没有横向滚动提示
    11. 对于信息比较长的文本,文本框有没有提供自动竖直滚动条对于信息比较长的文本,文本框有没有提供自动竖直滚动条
    12. 数据录入控件是否方便
    13. 有没有支持Tab键,键的顺序要有条理,不乱跳
    14. 有没有提供相关的热键
    15. 控件的提示语描述是否正确
    16. 模块调用是否统一,相同的模块是否调用同一个界面
    17. 用滚动条移动页面时,页面的控件是否显示正常
    18. 日期的正确格式应该是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX
    19. 页面是否有多余按钮或标签
    20. 窗口标题或图标是否与菜单栏的统一
    21. 窗口的最大化、最小化是否能正确切换
    22. 对于正常的功能,用户可以不必阅读用户手册就能使用
    23. 执行风险操作时,有确认、删除等提示吗
    24. 操作顺序是否合理
    25. 正确性检查:检查页面上的form, button, table,header, footer,提示信息,还有其他文字拼写,句子的语法等是否正确。
    26. 系统应该在用户执行错误的操作之前提出警告,提示信息.
    27. 页面分辨率检查,在各种分辨率浏览系统检查系统界面友好性。
    28. 合理性检查:做delete, update, add,cancel, back等操作后,查看信息回到的页面是否合理。
    29. 检查本地化是否通过:英文版不应该有中文信息,英文翻译准确,专业。

    1.13 兼容性测试

    兼容性测试不只是指界面在不同操作系统或浏览器下的兼容,有些功能方面的测试,也要考虑到兼容性,包括操作系统兼容和应用软件兼容,可能还包括硬件兼容比如涉及到ajax、javascript等技术的,都要考虑到不同浏览器下的兼容性问题。


    1.14 连接测试

    主要是保证链接的可用性和正确性,它也是网站测试中比较重要的一个方面。
    可以使用特定的工具如XENU来进行链接测试。

    导航测试
    导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?
    在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。
    导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。
    Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

    图形测试
    在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:
    (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。
    (2)验证所有页面字体的风格是否一致。
    (3)背景颜色应该与字体颜色和前景颜色相搭配。
    (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩,最好能使图片的大小减小到30k以下
    (5)最后,需要验证的是文字回绕是否正确。如果说明文字指向右边的图片,应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
    通常来说,使用少许或尽量不使用背景是个不错的选择。如果您想用背景,那么最好使用单色的,和导航条一起放在页面的左边。另外,图案和图片可能会转移用户的注意力。


    1.15 业务流程测试(主要功能测试)

    业务流程,一般会涉及到多个模块的数据,所以在对业务流程测试时,首先要保证单个模块功能的正确性,其次就要对各个模块间传递的数据进行测试,这往往是容易出现问题的地方,测试时一定要设计不同的数据进行测试。


    1.16 安全性测试

    1. SQL注入(比如登陆页面)
    2. XSS跨网站脚本攻击:程序或数据库没有对一些特殊字符进行过滤或处理,导致用户所输入的一些破坏性的脚本语句能够直接写进数据库中,浏览器会直接执行这些脚本语句,破坏网站的正常显示,或网站用户的信息被盗,构造脚本语句时,要保证脚本的完整性。
      document.write(“abc”)
    1. URL地址后面随便输入一些符号,并尽量是动态参数靠后
    2. 验证码更新问题
    3. 现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。
    4. Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
    5. 为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
    6. 当使用了安**接字时,还要测试加密是否正确,检查信息的完整性。
    7. 服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

    1.17 性能测试

    连接速度测试
    用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。
    另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

    负载测试
    负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

    压力测试
    负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。
    进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。
    压力测试的区域包括表单、登陆和其他信息传输页面等。

    备注:
    1、负载/压力测试应该关注什么
    测试需要验证系统能否在同一时间响应大量的用户,在用户传送大量数据的时候能否响应,系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到 “系统忙”的信息,他们可能放弃,并转向竞争对手。系统检测不仅要使用户能够正常访问站点,在很多情况下,可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因,测试人员应该知道当系统过载时,需要采取哪些措施,而不是简单地提升系统性能。

    1)瞬间访问高峰
    如果您的站点用于公布彩票的抽奖结果,最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟X个用户同时访问测试站点。
    2)每个用户传送大量数据
    网上书店的多数用户可能只订购1-5书,但是大学书店可能会订购5000本有关心理学介绍的课本?或者一个祖母为她的50个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址)系统能处理单个用户的大量数据吗?
    3)长时间的使用
    如果站点用于处理鲜花订单,那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于web的email服务,那么点最好能持续运行几个月,甚至几年。可能需要使用自动测试工具来完成这种类型的测试,因为很难通过手工完成这些测试。你可以想象组织100个人同时点击某个站点。但是同时组织 100000个人呢。通常,测试工具在第二次使用的时候,它创造的效益,就足以支付成本。而且,测试工具安装完成之后,再次使用的时候,只要点击几下。
    采取措施:采用性能测试工具WAS、ACT,LR等协助进行测试


    1.18 测试中应该注意的其他情况

    1. 在测试时,与网络有关的步骤或者模块必须考虑到断网的情况
    2. 每个页面都有相应的Title,不能为空,或者显示“无标题页”
    3. 在测试的时候要考虑到页面出现滚动条时,滚动条上下滚动时,页面是否正常
    4. URL不区分大小写,大小写不敏感
    5. 对于电子商务网站,当用户并发购买数量大于库存的数量时,系统如何处理
    6. 测试数据避免单纯输入“123”、“abc“之类的,让测试数据尽量接近实际
    7. 进行测试时,尽量不要用超级管理员进行测试,用新建的用户进行测试。测试人员尽量不要使用同一个用户进行测试
    8. 提示信息:提示信息是否完整、正确、详细
    9. 帮助信息:是否提供帮助信息,帮助信息的表现形式(页面文字、提示信息、帮助文件),帮助信息是否正确、详细
    10. 可扩展性:是否由升级的余地,是否保留了接口
    11. 稳定性:运行所需的软硬件配置,占用资源情况,出现问题时的容错性,对数据的保护
    12. 运行速度:运行的快慢,带宽占用情况

    2 App测试点

    安装、卸载测试
    在应用市场上安装卸载

    启动app测试

    升级测试
      升级覆盖安装、下载后手动覆盖安装、跨版本升级、升级后可以正常使用。
      覆盖安装要确保数据库有字段更新的话,能正常更新,否则就容易导致app异常。

    接口兼容验证

    功能测试

    • 包括功能点、业务逻辑、关联性(主要测试客户端与PC端的交互,客户端处理完后,PC端与客户端数据一致)、
    • 服务端接口测试(主要通过访问服务端接口来验证服务端业务逻辑功能点是否正确)
    • 配置文件修改、定时任务执行、数据sql执行

    数据对比测试
      可在模拟器或真机上进行,同时与数据库中实际的插入记录做对比(例如:状态、时间等)。还要对比主站的相同流程

    性能
    启动时间,响应时间

    安全

    • 敏感信息传输过程中是否加密,如登录密码,支付密码,银行卡信息等

    • 界面切换过程中是否假象处理,切换程序到后台时,界面是否朦胧处理

    • 单点登录/长时间不处理自动注销/保持登录等

    android特性测试
    横竖屏,home键, 源键、返回键等

    各种网络状态下进行的测试
    网络切换及弱网环境数据加载处理方式

    中断性测试

    • 如突然来电
    • 短信弹出
    • 低电量等时app能否正常使用
    • 蓝牙数据传输
    • 连接电脑

    app切换测试(最小化、多个app切换)
    目前IOS有企业版和appstore版本,俩版本之间切换数据是否能够刷新

    关机、待机后app能否正常使用

    兼容性测试

    • android各种版本
    • 各种分辨率QVGA、WVGA、HWVGA等
    • 与其他第三方app的兼容,特别是第三方手机助手,包含的一般是号码短信拦截

    app在清空数据或强制退出后还能正常运行否

    api,包括在app内跳转到另一个界面,在返回来,以及跳转到系统api

    app对资源的占用(cpu、内存、耗电、流量等)

    app本身涉及的权限

    • 通讯录、相册、蓝牙、麦克风、位置、相机(在IOS较为明显)
    • 程序安装时,在相应的涉及到该内容时,会提示用户

    长时间开机且开app,看是否会出现异常情况

    互动分享:如果程序里面包括分享功能,那么检测点击分享的时候是否会正常给出分享提示,点击分享后所填写的分享内容是否正确


    原博链接

    展开全文
  • 软件测试初学者

    2011-04-21 10:51:00
    软件测试中的基本词汇 7. 软件测试步骤 8.我想问到底软件测试的流程是什么? 9.请问Bug曲线是怎么会事? 10.负载测试与压力测试有何区别? 11.如何设计编制软件测试用例(一~三) 12.软件测试的14种类型 13....
  • 针对web系统的常用测试方法如下: 1. 页面链接检查: 每一个链接是否都有对应的页面,并且页面之间切换正确。可以使用一些工具,如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不...
  • 测试分类 按开发阶段划分 单元测试(Unit Testing) 单元测试是对软件组成单元进行测试。其目的是检验软件基本组成单位的正确性。...测试内容:模块接口测试、局部数据结构测试、路径测试、错误...
  • 软件测试:在规定条件下对程序进行操作,以发现错误,对软件质量进行评估,包括对软件形成过程的文档、数据以及程序进行测试 软件质量:软件特性的总和,软件满足规定或潜在用户需求的能力 2.软件测试与质量保证 ...
  • ZZ 软件测试入门

    2012-05-02 15:48:23
    6. 软件测试中的基本词汇 7. 软件测试步骤 8.我想问到底软件测试的流程是什么? 9.请问Bug曲线是怎么会事? 10.负载测试与压力测试有何区别? 11.如何设计编制软件测试用例(一~三) 12.软件测试的...
  • 笔试——软件测试

    2015-07-17 09:53:13
    1、根据关键的原则进行等价类划分:边界条件、次边界条件(ASCII码、2的幂问题)、空值(默认、空白、零值、无)、错误输入(非法、垃圾数据) 2、测试必须测试程序的状态及其转换。 3、动态黑盒测试:数据测试、...
  • 功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能,以下是测试时需要考虑的一些测试点:1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。...
  • 1. 经常会遇到页面中内容或数据显示错误,甚至不显示回答是:我会进一步了解这个BUG的问题出在那里,并且简单的使用浏览器自带开发者工具或者数据库工具配合去排查 2.测试过程中发现某一功能点在产品需求和开发设计...
  • 1. 页面链接检查:每一个链接是否都有对应的页面,并且...Xenu无需安装,支持asp、do、jsp等结尾的网页,xenu测试 链接包括内部链接和外部链接,在使用的时候应该注意,同时能够生成html格式的测试报告。如果
  • 针对web系统的常用测试方法如下:  1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。可以使用一些工具,如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不
  • 机器学习—— SVM分类垃圾短信 Python语言凭借其强大的特性,其众多的外部库支持下,在机器学习和数据挖掘等领域发挥着强大的作用。本文基于python的机器学习库scikit-learn和完备的中文分词工具jieba 来对垃圾短信...
  • 单元测试(Unit Testing): 集成测试(Integration Testing): 系统测试(System Testing): 冒烟测试(smoke testing): 回归测试(Regression Testing): 验收测试(Acceptance Testing): 按测试实施组织: α...
1 2 3 4 5 ... 20
收藏数 16,522
精华内容 6,608
关键字:

垃圾数据 英文 软件测试