软件测试理论基础
一、软件工程：从管理、技术两方面来研究如何更好的开发、维护计算机软
件的学科。
七条基本原理：
1、用生命周期计划严格管理
生命周期：可以概括为定义、开发、应用和维护四个时期
需求提出→可行性分析→高度化设计(HLD) →详细化设计(LLD) →coding（编码）→test（测试）→上线→售发
生命周期中的计划：
项目概要计划
里程碑计划
项目控制计划
产品控制计划
验证计划
运行维护计划
项目具有特定性，产品不具有特定性
2、坚持进行阶段评审
评审：（做质量保证的人）提前发现错误减少软件的损失
QA 质量保证quality assurance
QC 质量控制quality control
3、产品一致性控制
及时的更新变更
CCB 控制变更委员会(control changing )
基准配置管理：（变动控制）文档、代码打上标签如：配置管理工具VSS
4、采用最新的软件设计技术
5、清楚地审查软件产品
6、人员应该少而精
7、不断改进软件工程的实践性
持续改进：不断的在工作、测试中发现bug并且改进的过程
测试体系、测试咨询常用的术语
文档的英文名称
软件需求说明书
HLD 概要设计
LLD 详细设计
Coding 编码
Unite test 单元测试
System test 系统测试
UAT 验收测试
1、瀑布模型：
软件生命周期的阶段和工作内容：
阶段研究问题给出的标准和文档
问题定义问题是什么？目标个规模报告书
可行性研究有可行的方法吗？高层逻辑模型、数据流图、成本效益分析需求分析系统做什么逻辑模型、数据流图、数据字典、算法描述总体设计如何解决问题？系统流程图、系统结构层次图
详细设计怎样具体实现？编码规格说明、HIPO图或PDL
编码和单元测试给出正确的程序模块源程序清单、单元测试方案和结果
综合测试给出符合要求的软件综合测试方案和结果、一致的软件配置
维护持久的满足用户需求完整地维护记录、文档、软件新版本
2、‘V’模型：
需求分析验收测试（UAT) 概要设计系统测试
详细设计单元测试
Coding
二、软件质量
1、质量与质量模型
因素（特性）：如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等。
2、质量保证
软件测试概念
验证程序是否符合需求的一个过程
测试：1、它能做什么2、它不应该做什么
概念;
广义：软件生存周期中所有的检查、评审和确认工作，其中包括了对分析、设计阶段、以及完成开发后维护阶段的各类文档、代码的审查和确认。
狭义：识别错误
测试目的：为了度量和提高被测试软件的质量，对测试软件进行工程设计、事实和维护的整个生命周期。
测试分类：1按阶段分：单元测试：
集成测试：
系统测试：
验收测试：
2.按目的分
（1）功能测试
（2）非功能测试：A.性能:a.并发（响应时间）b.稳定性（7*24 5*8查找内存泄漏）c.容量测试，d.压力测试。*测试数据的准备1.编造数据2.从项目组或生产
环境中获取。
B．安全测试（复制链接，回退）
C．界面测试（布局要合理，色调风格一致）
D．易用性测试，安装/卸载测试
E．本地化测试，兼容性测试，恢复/备份测试（实时系统）
F．健壮性测试，可靠性测试（少）
3透明度分
白盒测试
黑盒测试
灰盒测试
4执行方式
静态测试
动态测试
二．测试要点
1.测试规律
BUG的80-20的原则
1.在分析，设计，实现阶段的复审和测试工作能够发现和避免80%的Bug。
2.而系统测试又找到其余Bug的80%。
3.最后的5%的Bug只可能再有用户的大范围，长时间使用后才会暴露出来。
木桶原理
软件质量不是只有软件测试一个方面决定的它是由各个方面共同决定的。2.测试的重点
1.良好的用例设计，
2.好的测试工作管理（使工作有条不紊的进行减少风险）
3.独立的测试环境
4.软件测试的质量
可以发现以下软件缺陷：
1软件实现的功能的不正确
2.‘缺少’软件没有实现的某个功能
3.’多余”软件实现的某项功能在需求中没有定义。
软件测试本身的质量在于：
发现软件缺陷并能区分其类型，
提供关于软件质量和开发过程质量的信息。
5.软件测试度量
A测试覆盖率：（
a有多少需求被测试用例所覆盖。被覆盖的需求/总需求*100%
b被执行需求/总有效需求*100% 需求执行率或被测率
c执行用例数/总用例数*100% 用例执行率（考察测试人员工作效率）d通过的用例/总的执行的用例*100% 用例通过率（评价软件质量）) B缺陷发现率：1.缺陷数目（1）统计个数（按严重级别按功能分布按开发人员按缺陷状态等统计）
缺陷修复率=修复并已经通过的缺陷/发现的有效缺陷总数*100%
缺陷遗留率=上线后发现有效缺陷/测试发现的有效缺陷*100%（考核测试人员）
C测试成功率
2008-8-5笔记
一、测试分类
1、阶段分：
单元unite test （测试单元：把整个代码分成小的单元）最靠近编码
集成integration test （自上而下、自下而上、宽度、深度四种集成方式）
系统system test （把整个被测系统放到大的系统中测试）
验收user acceptance test （由客户组织或委托第三方的测试，测试具有合同
约定性质如果通过意味着客户接受了这个系统。
包括性能、功能的测试以及文档）
前三个是开发商主导测试只有验收是用户来执行
性能performance test
功能functional test
『Weblogic 中间件(Bea公司开发被Oracle收购) middle ware websphere (IBM公司的)Oracle DB2 用于大型企业SQL server 用于中小型企业Data base administrator 数据库管理员大型企业才会有』
2、目的分：
功能：检测功能好不好使。
非功能：
性能：【性能测试即测试软件处理事务的速度，一是为了
检验性能是否符合需求，二是为了得到某些性能
数据供人们参考（例如用于宣传）。】
性能测试涉及--测试数据的准备：编造、从项目
组或生产环境中获取
并发：多人在线操作，响应时间，要求尽可能的短。
稳定：7*24或5*24小时，不当机不停机，正确执行。
容量测试：大数据的处理。
压力测试：即负荷测试，获取系统能正常运行的极限
状态。
界面测试：网站，布局合理。色调、风格的统一，不能出
现窜行、错别字，图片不要过大等。
易用性：用户使用着方便。
安装/卸载（uninstall）：大部分软件都需要安装後才能使用。
安全测试：不允许绕过登录界面，进入系统中来。
本地化：汉化。
兼容性：测试软件运行在不同操作系统下，硬件环境下是
否正常
恢复/备份：
健壮性：在异常情况下，软件还能正常运行的能力。（含义：
1、容错性
可靠性测试：一定环境下，在给定的时间内，系统不发生
故障的概率。
3、按透明度分：
黑盒测试：black box 只注重输入输出，不管里面的实现情况，
将整个系统当成一个黑盒子
常用方法：等价类、边界值、因果图、错误推测法白盒测试：white box 更注重内部的逻辑结构分支。
灰盒测试：gray box 介于二者之间，即关心输入输出，也关心
内部逻辑
4、按执行方式分：
静态测试：指不实际运行软件，主要是对软件的编程格式、结构
等方面进行评估
动态测试：运行程序，输入各种值来进行测试。
Alpha测试Beta测试
回归测试：regression test 关联性
冒烟测试：在测试之前对主功能和主路径的测试
前哨测试：
确认测试：
嵌入式测试：主要测试和硬件有直接联系的软件如路由器
二、测试的一些要点
1、测试的规律
Bug的80-20原则
（1）、在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的BUG。
（2）、而系统测试也能找出其余BUG中的80% 。
（3）、最后的5%的Bug可能只有在用户的大范围、长时间使用后才会暴露出来。
80/20原则
1、80%的工程量用在20%的需求上
2、80%的开发成本花费在20%的部件上
3、80%的错误是由20%的部件引起的
4、80%的延期或返工
木桶原理
（1）软件质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会最终
软件的质量
（2）
2、软件测试的重点
（1）、测试用例的良好设计：用例覆盖是否全面用例是否有效- 测试用例的设计是整个软件工作的核心
- 测试用例反映对被测对象的质量要求，决定对测试对象的质量评估（2）、测试工作的管理：工作有条不紊的进行减少风险
- 尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提
（3）、测试环境的建立：（或独立的测试环境）
测试环境应该与实际测试环境一致
功能测试：中间件数据库一致
性能测试：中间件数据库程序硬件都要一致
（4）、软件测试的质量：
软件测试可以发现以下软件缺陷
-软件实现的功能不正确
-“缺少”，软件没有实现某项功能
-“多余”，软件实现的某项功能在需求中没有定
发现第一类软件缺陷的过程---“验证validate”
发现後两类软件缺陷的过程---“确认verification”
软件测试本身的质量在于：
-发现软件缺陷并能区分其类型
-提供冠以软件质量和开发过程质量的信息
缺陷的数量+ 严重级别+ 功能分布来评判软件的质量
缺陷的数量+ 严重级别+ 功能分布+ 开发人员来评价开发人员的开发质量。缺陷严重级别共分5级
（5）、软件测试度量
测试覆盖率：
-有多少需求被测试用例所覆盖，代码已经被测试了。
测试覆盖率=已被覆盖/ 总数（有效）×100%
需求的执行率=已被执行的/总数*100% 测试执行
用例执行率=已执行的测试用例/总数*100% 工作效率
用例的通过率=已通过的/总的已执行数*100% 软件质量
缺陷修复率=已修复的缺陷/ 发现有效的缺陷×100%
缺陷遗留率=上线后发现的有效缺陷/ 测试有效缺陷×100%
缺陷发现率
-缺陷是何时被发现，并且有多少缺陷已经被发现。
缺陷：
按严重性来分类
- 缺陷数目
- 缺陷的严重性
按功能分布
按开发人员
按缺陷状态
测试成功率：
3、测试的原则
(1)、所有的测试都应追溯到用户需求
(2)、应该在测试工作真正开始前的较长时间内就进行测试计划
(3)、8/2 原则应用于软件测试
(4)、测试应从“小规模”开始，逐步转向“大规模”。
(5)、穷举测试是不可能的。
(6)、为了达到最佳效果，应该有独立的第三方来构造测试。
(7)、不充分的测试是不负责任的；过分的测试是一种资源浪费，同样
也是一种不负责任的表现。
1.应当把“尽早和不断的测试”作为开发者的座右铭。
2.程序员应当避免检查自己的程序，测试工作应当由独立的专业的软件测
试机构来完成。
3.设计测试用例时应当考虑到合法的输入合不合法的输入以及各种边界
条件，特殊情况下要制造极端状态和意外状态，比如网络异常中
断；电源断电情况。
4.一定要逐一测试中的错误集中发现现象，这和程序员的编程水平和习惯
有很大的关系。
5.对测试错误结果一定要有一个确定的过程，一般有A测试出来的错误，
一定要有一个B来确认，严重的错误可以召开评审会进行讨论和
分析。
6.制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短
的时间内完成一个高水平的测试。
7.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的
错误出现的情况并不少见。
8.妥善保存一切测试文档，意义是不言而喻的，测试的重现性往往要靠测
试文档。
4、测试人员的基本素质
（1）、沟通能力：表达和获取别人表达的信息
（2）、移情能力
（3）、技术能力
（4）、自信心
（5）、外交能力
（6）、幽默感
（7）、很强的记忆力
（8）、耐心
（9）、怀疑精神
(10)、自我督促
(11)、洞察力
5、测试人员的服务对象
（1）项目经理
（2）程序员
（3）技术文档编写人员
（4）技术支持
（5）市场开发
（6）管理层和项目相关人员
（7）用户
测试人员关注失效，客户才能关注成功
6、缺陷报告 Bug Report FAQ常见问题解答
用途：
1、报告提示大家注意缺陷，并帮助程序员定位内部问题
2、报告提示大家注意规格说明和测试文档、用户文档或开发工具
中的问题
3、为技术文档编写愿提供背景信息，编写元要编写手册或公司网
站中的问题定位部分
4、报告提示需要通过客户培训解决的问题
5、报告为客户售后技术人员提供关键的信息，他们会了解到产品
上线后还没有被解决或没有完全解决的问题
6、报告向管理层提供正在开发的产品的状态和质量
7、报告在开始计划产品下一个版本是，提供初始改进建议
永远不要假设明显的程序缺陷已经写入报告
明确严重等级和优先级的差别
严重级别（sevenity）表示程序错误的影响后果
优先级别（priority）
一般情况下严重级别和优先级别成正比。
1、为每一步编号
2、不要跳过重现缺陷的人和步骤
3、精简缺陷重现步骤
4、通过空行提高报告的可读性。
8.6号集成测试：
集成测试的任务：
1模块连接起来检查模块互相调用数据是否会丢失。
2组合后是否能达到预期功能。
3模块间是否相互影响。
4全局的数据结构是否会有问题会不会被一场修改。
5单个模块误差累计错误是否会放大。
集成测试方法：
1.非增量式测试方法。一步到位进行测试。
2.增量式测试方法（1）自顶向下增量测试
（2）自底向上增量式测试
三．系统测试
需求：功能需求和非功能需求。
在需求分析阶段要确定软件的可测性（通过某种方式进行验证），保证有效完成系统测试工作。
需求具有准确性没有二义性。
系统测试内容：功能测试
所有性能要求得到满足。
其它需求（）
系统测试的任务：
1.功能测试
2.性能测试
3.恢复测试
4.安全测试
5.强度测试
6.其它限制条件的测试
系统测试技术和测试数据：完全采用黑盒测试，测试数据尽可能像真实数据一样精确和有代表性，也必须和真实数据的大小和复杂性相当。测试用例Test Case（TC）要求复用性。
四.验收测试
一般也是黑盒测试，数据用生产环境的备份数据。
验收的四类内容：
1.功能需求
2.性能需求
3.交互质量需求
4.全面的软件质量需求
五，回归测试（R）
可以采用人工也可以使用工具（QTP）来执行。
分类：全回归工作量大耗人力
部分回归工作量小功能肯能有遗漏
测试流程：
1.测试文档及作用
测试文档是对要执行的软件测试及测试的结果进行扫描，定义，规定和报告的任何书面或图示信息。
测试文档的作用
1促进项目组的成员的交流沟通
2便于对测试项目的管理
3决定测试的有效性
4检验测试资源
5明确任务的风险
6评价测试结果
7饭便在测试
8验证需求的正确性。
测试文档分类：前置作业文档和后置作业文档
日常测试情况汇报包括：周报和日报。
测试流程
测试计划 *工作规划（资源使用安排进度风险预估及规避方法
测试范围）测试计划测试方案
测试设计测试需求分析测试需求文档
用例设计 TC
测试准备及实现测试环境测试数据测试脚本 SQL语句
模拟客户端等产生脚本(script)文件数据文件程序测试执行执行测试用例发现缺陷产生文档：测试日报周报
和缺陷报告
测试评估对软件进行质量评估分析报告
在以上每个阶段完成进行评审以保证质量。测试前评审获取相关部门的认可。2测试人员沟通使认识没有偏差3. 4分析报告的评审对软件最后能否上线达成一致。
测试方案（既怎么做）
制定测试计划目的：
1.是测试工作更顺利
2.促进项目参加人员彼此沟通
3.是软件测试工作更易于管理。
制定测试计划的原则：（时间1.5倍预测时间）
1.制定测试计划应尽早开始
2.保持测试计划的灵活性
3.保持测试计划简洁易读
4.尽量争取多渠道评审测试计划
5.计算测试计划的投入。
制定测试计划是面对的问题：(解决办法多沟通)
1.与开发者意见不一致
2.缺乏测试工具
3.培训不够
4.管理部门缺乏对测试工作的理解和支持
5.缺乏用户的参与
6.测试时间不足
7.过分依赖测试人员
8.测试人员处于进退两难的状态
9.不得不说“不”
property 属性：作者（author）
覆盖状态（cover status）not completed(没有测试用例
覆盖)NO Run 与用例关联但没有被执行
Passed 所有测试用例都通过
failed 测试用例有没有通过的
not Iomplete 3个用例两个测试通过一个还没有测
创建时间 Creation Date修改时间 modified
测试需求：优先级priority需求ID Req ID 产品Product
名称Name 类型 Type 复查Reviewed（蓝字必须有）
来源于业务需求或软件需求
测试设计：
测试用例：一般指对一项特定的软件产品进行测试任务的描述体现测
试方案，方法技术和策略。
测试用例的设计：1.为实施一次测试而向被测系统提供的输入数据操作和各种环境设置，期望结果的一个特定的集合。
2.控制着软件测试的执行步骤
3.是对测试方案中每个测试项的进一步实例化。
测试用例属性：创建日期描述（Description）设计者（Designer）估计开发时间(Estimated DevTime) 执行状态(Execution Status) 修改（Modified）状态（Status）步骤（Steps）主题(Subject) 模板(Template) 测试名称(Test Name) 类型（Type）
前置条件输入数据输出数据
测试用例的编写原则
1.测试用例的代表性
2.测试结果的可判定性
3.测试结果的可再现
4.准确性
5.简洁性（3-9步之内）
6.可重用性
7.可跟踪性
8.适用性
复用的意义：1.减少工作量2.易于维护3.易于复审。
对测试数据的要求：
1.功能测试不需要大量数据
2.功能测试需要数据覆盖率高
3.功能测试的测试数据要求尽量真实
4.性能测试需要大量的数据
5.性能测试的测试数据应尽可能的达到符合实际的数据分配。
测试执行：是执行所有的的或选定的一些测试用例，并观察其测试结果的过程。其过程由四部分组成
1.输入
2.执行过程
3.检查过程
4.输出
软件测试的执行内容：
-执行测试用例
-记录原始测试数据
-记录缺陷
-多所有的缺陷进行跟踪，管理和监控。
测试集 test set(存在有TD工具中的再测试纯理论中不存在)
作用可以重复TC ，执行结果
执行流：execute flow. 具有先后顺序的一些测试用例的组合。
执行条件状态：Finish完成做了不管结果
Pass 通过做了必须做对。
实际结果：用来和预期结果进行对比的。
缺陷：就是与需求不符的地方。
不符合下面五个规则里的一个就叫做缺陷：
1.软件未达到软件规格说明书中行规定的功能
2.软件超过软件规格说明书知名的范围
3.软件未达到软件规格说明书中指出的应达到的目标
4.软件运行出现错误
5.软件测试人员认为软件难于理解，不易使用，运行速度慢，或者
最终用户认为软件使用效果不好。
软件缺陷的种类：
1.功能不正常
2.使用上不方便
3.软件的结构为做到良好的规划
4.功能不充分
5.与软件操作者的互动不良
6.使用性能不佳
7.为做好错误处理
8.边界错误
9.计算错误
10.使用一段时间所产生的错误
11.控制流程的错误
12.在大数据量压力之下所产生的错误
13.在不同硬件环境下产生的错误
14.版本控制不良所产生的错误
15.软件文档错误
缺陷分类：操作级和结果级的
缺陷的属性：实际修复时间
分配给
关闭日期
注释
缺陷ID
描述
检测者
检测版本
检测日期
修改日期
计划关闭版本
优先级
可重现
状态
主题
概要
8.7号缺陷的生命周期
缺陷的生命周期：缺陷从发现到修复（关闭）的全部过程。
缺陷状态：1.新2.打开3.修复4.重新打开5.关闭6.否决
缺陷是独立的，缺陷管理分为缺陷跟踪和缺陷管理（除了追踪还包括汇总分析缺陷种类的定义，市面上有专门的管理工具如bugziller和jira）。
TD(测试管理工具)
测试评估与报告
测试评估是在测试结束后对整个测试过程与产品进行评估的过程。
评估过程包括：工作总结，过程评估，缺陷分析，（结论，留给上司）测试评价主要包括覆盖评价和及质量和性能评价。
测试评估：1.结合量化的测试覆盖率及缺陷跟踪报告
2.对软件项目的质量和开发团队的工作进度及工作效率（最好别写）进行综合评价
3.生成相应的报告或报表
评估包括：1测试工作的评估—测试覆盖面，用力执行，工作完成情况
2软件质量的评估：需求通过，用例通过，缺陷情况，
测试报告的意义：
1.以测试报告的形式像整个软件开发部门报告测试结果既发现的缺
陷或错误。
2.撰写测试报告的目的是为了让整个软件开发部门了解软件开发的
进展情况以使缺陷能够迅速得到修复；
3.测试报告的格式并无定义，要求能够完整，清楚的反应当前的测
试进展情况，明白易懂，无二义性。
测试计划模板：
1.测试计划标识
2.介绍
3.测试项
4.需要测试的功能
5.不需要测试的功能
6.方法
7.测试项的通过/失败准则
8.暂停准则和恢复准则
9.测试完成所提交的材料
10.测试任务分配
11.环境需求
12.职责和分工
13.人员及培训要求
14.时间表
15.风险及规避方法（应急措施1.增加人员2.延时3.增加预算4.减少工作量）
16.审批人
17.策略两种标准一.以时间为目标二.以质量为目标
*制定策略考虑以下内容：
a 要使用的测试方法
b.确定质量风险
c.测试完成和测试成功所采用的评价标准
d.有关资源要求或涉及进度的特殊考虑
e.测试类型，评估标准以及测试方法
f.确定资源
测试需求：
软件需求完整的话直接转为测试需求。
按照以下步骤来执行：
1.确定软件提供的主要任务
2.对每个任务，确定完成该任务所要进行的任务
3.对于对时间有要求的交易，确定所要的时间和条件
4.确定会产生大量意外的压力测试，包括内存硬盘空间高的交易率
5.确定应用需要处理的数据量
6.确定需要的软件和硬件配置
7.确定其他与应用软件设置没有直接关系的商业交易
8.确定安装过程
9.确定没有隐含在功能测试中的用户界面要求。
用功能分解的方法做测试需求
含义：把软件分解为相对独立的功能单元。
首先按系统来分例STTE分为七个模块，每个模块下还有子模块；再往下，功能，比如知识点管理，增删改。
性能测试培训（一） ——基础知识 1.软件性能测试的概念 1.1软件性能与性能测试 软件性能：覆盖面广泛，对一个系统而言，包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。 性能测试：为保证系统运行后的性能能够满足用户需求，而开展的一系列的测试组织工作。 1.2不同角色对软件性能的认识 用户眼中的软件性能： ?软件对用户操作的响应时间 如用户提交一个查询操作或打开一个web页面的链接等。 ?业务可用度，或者系统的服务水平如何 管理员眼中的软件性能：
开发人员眼中的软件性能： 1.3性能测试的对象 服务器端： ?负载均衡系统； ?服务器（单机、双机热备、集群）； ?存储系统、灾备中心； ?数据库、中间件。 网络端： ?核心交换设备、路由设备； ?广域网络、专线网络、局域网络、拨号网络等； 应用系统： 由此可见，性能测试是一个系统性的工作，被测对象包括系统运行时使用的所有软硬件。但在实际操作时，将根据项目的特点，选择特定的被测对象。 1.4性能测试的目标 评价系统当前的性能：
?系统刚上线使用，即处于试运行时，用户需要确定当前系 统是否满足验收要求； ?系统已经运行一段时间，如何保证一直具有良好的性能。分析系统瓶颈、优化系统： ?用户提出业务操作响应时间长，如何定位问题，调整性能； ?系统运行一段时间后，速度变慢，如何寻找瓶颈，进而优 化性能。 预见系统未来性能、容量可扩充性： ?系统用户数增加或业务量增加时，当前系统是否能够满足 需求，如果不能，需要进行哪些调整？提高硬件配置？增 加应用服务器？提高数据库服务器的配置？或者是需要对 代码进行调整？ 1.5性能测试的分类 按照测试压力级别： ?负载测试； ?压力测试； 按照测试实施目标： ?应用在客户端的测试； ?应用在网络的测试； ?应用在服务器端的测试； 按照测试实施策略：
软件测试中的43个功能测试点 功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能，针对web系统我们有哪些常用测试方法呢？今天我们一起来了解了解~~ 1. 页面链接检查 每一个链接是否都有对应的页面，并且页面之间切换正确。可以使用一些工具，如：LinkBotPro、File-AIDCS、HTMLLink Validater、xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码；HTMLLink Validater只能测试以Html或者htm结尾的网页链接；xenu无需安装，支持asp、do、jsp等结尾的网页，xenu测试链接包括内部链接和外部链接，在使用的时候应该注意，同时能够生成html格式的测试报告。 2.相关性检查 功能相关性：删除/增加一项会不会对其它项产生影响，如果产生影响，这些影响是否都正确，常见的情况是，增加某个数据记录以后，如果该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形。 3.检查按钮的功能是否正确 如新建、编辑、删除、关闭、返回、保存、导入、上一页、下一页、页面跳转、重置等功能是否都正确。常见的错误会出现在重置按钮上，表现为功能失效。 4.字符串长度检查 输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度。还要检查需求规定的字符串长度是否都正确，有时候会出现，需求规定的字符串长度太短而无法输入业务数据。 5.字符类型检查 在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型）看系统是否检查字符类型。 6.标点符号检查 输入内容包括各种标点符号，特别是空格，各种引号，回车键。看系统处理是否正确。常见的错误是系统对空格的处理，可能添加的时候，将空格当作一个字符，而在查询的时候空格被屏蔽，导致无法查询到添加的内容。
软件测试工程师笔试理论题库1
理论题库 1 2 3 4 5 6 7 8 9 10 C C DBC C D A B D B C 11 12 13 14 15 16 17 18 19 20 C D B B C B B D A D 21 22 23 24 25 26 27 28 29 30 D B B A A AC C D D C 31 32 33 34 35 36 37 38 39 40 B C D C DBC D A C C D 41 42 43 44 45 46 47 48 49 50 BAA B ADD B B A D B B D 51 52 53 54 55 56 57 58 59 60 C D B D C B A C A B 61 62 63 64 65 66 67 68 69 70 C B A D A C B B C C 71 72 73 74 75 76 77 78 79 80 A A D D D A D B D B 81 82 83 84 85 86 87 88 89 90 B A D C D B C B C B 91 92 93 94 95 96 97 98 99 100 A B B A BA AD A C A C 单选题 1．是常见的接受电子邮件协议。A．HTTPS B.ET C.POP3 D.DNS
2．系统中有四个作业，它们的到达时间、运行时间、开始时间、完成时间和周转时间如表1所示，该系统采用的作业调度算法是。 表1 作业到达 时间 计算时 间（分） 开始 时间 完成 时间 周转时 间（分） J1 8:00 60 8:00 9:00 60 J2 8:10 20 9:10 9:30 80 J3 8:20 10 9:00 9:10 50 J4 8:40 15 9:30 9:45 65 A、先来先服务 B、短作业优先 C、响应比高者优先 D、不能确定 3．数据库系统实现数据独立性是因为采用了 (1) 。 当两个子查询的结果 (2) 时，能够执行并、交、差操作。 SELECT语句中“SELECT DISTINCT”表示查询结果中 (3) 。 (1) A、层次模型 B、网状模型 C、关系模型 D、
选择2*10 1、以下哪个情况最能够代表出现了性能问题（D ） A：网络延迟达到15ms以上 B：DNS没有完成解析 C：WEB服务器的可用内存降到了1GB以下 D：用户体验超过了预期的系统响应时间 2、关于C语法规则中下面那个说法是正确的（ A ）： A：在C语言中，允许用一个变量来存放指针 B：分号“；”代表一段程序语句的结束 C：/t后面的内容都是注释 D：C语言是不区分大小写的 3、LoadRunner实现合并图的过程中一般不包括（D ） A：叠加 B：平铺 C：关联 D：替换 4、影响WEB前端页面性能一般不包括下面那个（ C ） A. 服务器数据返回延迟 B. 网络传输速率 C. 磁盘空间不够 D. 页面渲染 5、选出下列那个不是系统性能监控的指标（C ） A：CPU利用率 B：磁盘空间大小 C：内存空间使用率 D：网络吞吐量 6、下面哪个LoadRunner的组件生成运行Vuser的负载？（ D ） A: VuGen B: Controller C: Analysis D: Load Generator 7、在用LoadRunner进行性能测试过程中Run-Time Setting常用的超时设置不包括（ B ） A：HTTP-request connect timeout(sec) B：Call to Copy of Action C：HTTP-request receive timeout(sec) D：Step download timeout 8、C语言数据类型不能遵循下面那个规则（C ）： A：char指的是字符型数据 B：int指的是基本整型 C：float指的是双精度实数 D：指针是一种特殊的同时又是具有重要作用的数据类型 9、通过疲劳强度测试，最容易发现问题的问题是（ B） A．并发用户数 B．内存泄露 C．系统安全性 D．功能错误 10、如下哪些测试场景不属于负载压力测试: （A ） A．恢复测试 B．疲劳强度测试 C．大数据量测试 D．并发性能测试
第一章基础知识 1.1、软件 1)、软件=程序+文档 2)、分类 功能：系统+应用 架构：单机+C/S+B/S 用户：产品+项目 规模：小型+中型+大型 1.2、Bug 1)、类型一(广义上，软件生命周期，与用户需求不符的问题)： 完全没有实现的功能 基本实现功能，但有功能上或性能上的问题 实现了用户不需要的功能 2)、类型二(测试执行阶段的问题) Defect---------Requirements&Design Error-----------Development Bug------------Testing Failure---------Post production 1.3、测试 1)、概念： 测试是为了检验实际的软件是否符合用户需求，所以不能为了发现错误而发现错误。使用人工或自动手段，来运行或测试某个系统的过程。 2)、测试环境：硬件+软件+网络 要求：真实(项目、产品)+干净+无毒+独立(测试与开发) 1.4、测试用例 测试用例=输入+输出+测试环境 便于团队交流，便于重复测试，便于跟踪统计，比纳与用户自测 开发生命周期 需求分析→概要设计→详细设计→编码→维护 测试生命周期 测试计划→测试设计→测试执行→测试评估 需求分析和测试计划完成后，根据《系统需求规格说明书》和软件原型(DEMO)写测试用例 1.5 其他 1)、测试人员素质要求：细心、耐心、信心、服务意识、团队合作意识、沟通能力 2)、如何成为优秀的测试工程师：1、不断学习充电2、阅读原版书籍3、阅读缺陷管理系 统中的缺陷报告4、阅读高手写的测试用例5、学习产品相关 的业务知识
1.6 软件测试的基本规则 1) Zero Bug 与Good Enough Good Enough原则：不充分测试是不负责任，过分的测试是一种资源浪费。 参考：*遗留bug不超过10个，严重的不超过5个 *测试用例执行率为100%，通过率为95% *单元测试，关键模块语句覆盖率达到100%，分支覆盖率达到85% 2) 不要视图穷举法 3) 开发人员不能既是运动员又是裁判员 4) 软件测试要尽早执行 一般情况下，软件80%的缺陷集中在20%的模块中。 7) 缺陷具有免疫性 缺陷具有免疫性，需要根据新版本修改维护测试用例，另外，有一个值得注意的经验：没修复3-4个bug，可能会产生一个新bug。 第二章测试分类 2.1、是否运行程序 Static Testing------------代码规范、界面、文档 Dynamic Testing--------运行程序 2.2、根据阶段分类 Unit Testing(单元测试)----------10% 最小模块，依据源程序和《详细设计》 白盒测试人员||开发人员 编译代码→静态测试→动态测试 桩模块(Stub)、驱动模块(Driver) Integration Testing(集成测试)----------20% 模块间的接口，依据单元测试的模块和《概要设计》 白盒测试人员||开发人员 一般单元和集成同步进行 System Testing(系统测试)----------40% 整个系统(功能、性能、软硬件环境)，依据《需求规格说明书》 黑盒测试工程师 Acceptance Testing(验收测试)----------20% 整个系统(功能、性能、软硬件环境)，依据《需求规格说明书》和验收标准
性能测试基础知识 一、性能测试概述 1、性能测试定义 所谓性能，有狭义和广义两种含义。狭义的性能指运行速度的快慢。广义的性能涉及很多内容，如可靠性、可用性、功耗、环境适应性、兼容性、安全性、保密性、可扩充性、可移植性、利用率、性能价格比、速度等。 性能测试是通过自动化的测试程序或工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。 2、性能测试目的 真实环境下检测系统性能，评估系统性能以及服务等级的满足情况 预见系统负载压力承受力，在应用实际部署之前，评估系统性能 分析系统瓶颈，优化系统 二、主要性能指标 响应时间、吞吐量、并发、点击率、资源利用率 1、响应时间 响应时间指的是客户端发出请求到得到响应的整个过程所经历的时间。 响应时间=网络传输时间*2+服务器处理时间+客户端显示时间。 2、吞吐量 单位时间内流经被测系统的数据流量，一般单位为b/s,即每秒钟流经的字节数。吞吐量是指单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力。 TPS的概念，每秒事务数。确实TPS会随着负载的增加而逐渐增加，但不会无限制的一直增加。比如，到了300用户后就会出现连接服务失败，那可能说明系统进入了繁忙期，从而产生了失败的事务，从而使得每秒的事务数不再增加，甚至会减少。 TPS就像是一个抛物线，可分为3部分，轻负载区、重负载区、负载失效区。 一开始上升的部分就是轻负载区，最顶端的部分就是TPS的峰值（重负载区），然后随着负载的继续增加，TPS会慢慢下降，从而进入我们所谓的负载失效区。 3、并发用户数 指在某一给定时间内，某个特定点上进行会话操作的用户数。是陆陆续续交替执行的。 随着用户数的增加，HIT PER SECOND开始逐渐减少，说明系统已经开始有失败的VUSER 和事务出现。 4、资源利用率 CPU利用率、内存利用率、磁盘利用率、网络带宽利用率
软件性能测试结果分析总结 平均响应时间：在互联网上对于用户响应时间，有一个普遍的标准。2/5/10秒原则。 也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。 定义：指的是客户发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被称为“TTLB”(Time to laster byte) ,意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。 错误状态情况分析：常用的HTTP状态代码如下： 400 无法解析此请求。 401.1 未经授权：访问由于凭据无效被拒绝。 401.2 未经授权: 访问由于服务器配置倾向使用替代身份验证方法而被拒绝。 401.3 未经授权：访问由于ACL 对所请求资源的设置被拒绝。 401.4 未经授权：Web 服务器上安装的筛选器授权失败。 401.5 未经授权：ISAPI/CGI 应用程序授权失败。 401.7 未经授权：由于Web 服务器上的URL 授权策略而拒绝访问。 403 禁止访问：访问被拒绝。 403.1 禁止访问：执行访问被拒绝。 403.2 禁止访问：读取访问被拒绝。 403.3 禁止访问：写入访问被拒绝。 403.4 禁止访问：需要使用SSL 查看该资源。 403.5 禁止访问：需要使用SSL 128 查看该资源。 403.6 禁止访问：客户端的IP 地址被拒绝。
403.7 禁止访问：需要SSL 客户端证书。 403.8 禁止访问：客户端的DNS 名称被拒绝。 403.9 禁止访问：太多客户端试图连接到Web 服务器。 403.10 禁止访问：Web 服务器配置为拒绝执行访问。 403.11 禁止访问：密码已更改。 403.12 禁止访问：服务器证书映射器拒绝了客户端证书访问。 403.13 禁止访问：客户端证书已在Web 服务器上吊销。 403.14 禁止访问：在Web 服务器上已拒绝目录列表。 403.15 禁止访问：Web 服务器已超过客户端访问许可证限制。 403.16 禁止访问：客户端证书格式错误或未被Web 服务器信任。 403.17 禁止访问：客户端证书已经到期或者尚未生效。 403.18 禁止访问：无法在当前应用程序池中执行请求的URL。 403.19 禁止访问：无法在该应用程序池中为客户端执行CGI。 403.20 禁止访问：Passport 登录失败。 404 找不到文件或目录。 404.1 文件或目录未找到：网站无法在所请求的端口访问。 需要注意的是404.1错误只会出现在具有多个IP地址的计算机上。如果在特定IP地址/端口组合上收到客户端请求，而且没有将IP地址配置为在该特定的端口上侦听，则IIS返回404.1 HTTP错误。例如，如果一台计算机有两个IP地址，而只将其中一个IP地址配置为在端口80上侦听，则另一个IP地址从端口80收到的任何请求都将导致IIS返回404.1错误。只应在此服务级别设置该错误，因为只有当服务器上使用多个IP地址时才会将它返回给客户端。404.2 文件或目录无法找到：锁定策略禁止该请求。 404.3 文件或目录无法找到：MIME 映射策略禁止该请求。
第1章软件测试概述 1.简述软件测试的意义。 解：随着计算机技术的迅速发展和广泛深入的应用，软件质量问题已成为开发和使用软件人员关注的焦点。而由于软件本身的特性，软件中的错误是不开避免的。不断改进的开发技术和工具只能减少错误的发生，但是却不可能完全避免错误。因此为了保证软件质量，必须对软件进行测试。软件测试是软件开发中必不可少的环节，是最有效的排除和防治软件缺陷的手段，是保证软件质量、提高软件可靠性的最重要手段。 2.什么是软件缺陷？它的表现形式有哪些？ 解：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需实现的某种功能的失效或违背。 它的表现形式主要有以下几种：（1）软件未达到产品说明书中已经标明的功能；（2）软件出现了产品说明书中指明不会出现的错误；（3）软件未达到产品说明书中虽未指出但应当达到的目标；（4）软件功能超出了产品说明书中指出的范围；（5）软件测试人员认为软件难以理解、不易使用，或者最终用户认为该软件使用效果不良。 3.简单分析软件缺陷产生的原因，其中那个阶段引入的缺陷最多，修复成本又最低？ 解：软件缺陷产生的主要原因有：需求规格说明错误；设计错误；程序代码有误；其他。其中在需求分析阶段引入的缺陷最多，修复的成本又最低。 4.当用户登录某网站购物完毕并退出后，忽然想查查购物时付账的总金额，于是按了浏览器左上角的“退回”按钮， 就又回到了退出前的网页，你认为该购物软件有缺陷吗？如果有，属于哪一类？ 解：有缺陷。其所属类别与软件产品说明书的要求有关。 5.什么是软件测试？简述其目的与原则。 解：软件测试是为了尽快尽早地发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期，对软件产品（包括阶段性产品）进行验证和确认的活动过程。 测试目的：（1）证明：获取系统在可接受风险范围内可用的信心；尝试在非正常情况和条件下的功能和特性；保证一个工作产品是完整的并且可用或可被集成。（2）检测：发现缺陷、错误和系统不足；定义系统的能力和局限性；提供组件、工作产品和系统的质量信息。（3）预防：澄清系统的规格和性能；提供预防或减少可能制造错误的信息；在过程中尽早检测错误；确认问题和风险，并且提前确认解决这些问题和风险的途径。 测试过程中应注意和遵循的原则：（1）测试不是为了证明程序的正确性，而是为了证明程序不能工作。（2）测试应当有重点。（3）事先定义好产品的质量标准。（4）软件项目一启动，软件测试也就开始，而不是等到程序写完才开始进行测试。（5）穷举测试是不可能的。（6）第三方进行测试会更客观，更有效。（7）软件测试计划是做好软件测试工作的前提。（8）测试用例是设计出来的，不是写出来的。（9）对发现错误较多的程序段，应进行更深入的测试。（10）重视文档，妥善保存一切测试过程文档。 6.件测试阶段是如何划分的？ 解：软件测试的阶段划分为：规格说明书审查；系统和程序设计审查；单元测试；集成测试；确认测试；系统测试；验
基于LoadRunner的性能测试培训课程 适用于：性能工程师，操作人员，QA工程师 需要对应用进行负载测试的LoadRunner 新用户 概述： LoadRunner是自动化负载测试工具，允许用户在应用实施前、实施中或实施后对其进行负载测试。 本课程的设计目标是帮助用户打下良好的负载测试知识基础。 LoadRunner的组件——LR Controller和LR Virtual User Generator用于计划和创建高效的负载测试。您将会使用LRController来创建和运行负载测试场景。LR Analysis组件用于对负载测试结果进行分析，您将会学习到如何分析LR Analysis 图表，满足负载测试目标。所有的课题都会有实验课程，帮助您掌握使用LoadRunner进行对系统进行负载测试的所需知识。 VuGen 是用来记录和运行用户在被测应用上面的操作的脚本工具。在脚本生成器的讲解和演练中，着重在Web和winsock、Database、Tuxedo、Java等环境中如何计划、创建和增强虚拟用户（Vuser）的脚本。 课程目标： 在课程结束后，您将能够： ?负载测试的价值 ?计划高效的负载测试 ?了解当前软件企业中的性能测试实践 ?建立负载测试目标 ?运行负载测试场景 ?执行场景时创建不同级别的负载 ?分析和解释负载测试结果 ? 使用VuGen录制脚本 ?了解http、winsock、Database、Tuxedo等协议的脚本处理方式 ? 度量特定业务流程事务时间 ? 增加内容检查 ? 使用参数化的脚本处理用户输入数据 ? 如何通过增加VuGen函数定制脚本 ? 关联脚本处理服务器动态返回的数据 ?其他的一些高级技巧 ? LoadRunner调用Diagnostics进行测试 预备知识： 具有微软Windows 2000 或NT操作系统的使用经验 具有较深入的Web 应用或C/S 应用环境方面的知识 具有一定的C语言编程知识更佳
浅谈耳机生产工艺和性能测试(耳机基础知识五） 耳机基础知识五 上节聊了耳机的核心部件音圈和振膜对音质的影响。喜欢听音乐的朋友你们知道耳 机是怎样生产出来的吗？耳机生产过程有哪个重要的项目需要管控呢？为了保证高品质音 质性能测试有哪个项目呢？我都经历过德系、日系、欧美等国际顶尖品牌耳机生产线管理，基本上按以下品质基准和测试基准来生产的。当然不同的耳机生产工艺或测试是不同的， 不同客户测试标准和品质水准也是不一样的，不同类型的耳机工艺上会有增加或删减，但 是性能测试基本的还是不变的。今天简单聊聊的这话题，让大家对耳机工艺和测试有一个 了解，当然国际品牌为了保证耳机品质，测试设备比较齐全，国一些小加工厂或山寨厂只 有一台音频扫频仪，其它测试设备都免了，大家俗称的做出来的耳机只要有声音就行了。 由于大、中耳机工艺比较复杂，今天举例一款简单带MIC入耳式耳机（如sennheiser mm30i），但以下工艺可能有少许偏差。 一、耳机生产（组装）工艺流程： 1.半成品加工：(1)电线半成品加工（电线插头生产、MIC控制盒组装加工）(2)SPK前壳加工（贴调纸、点胶水）(3)后壳加工（穿SR/贴调音纸/加工装饰片等）----（篇幅有限加 工部分详细流程略） 2.耳机组装工艺流程：1.检查电线+投入流水线 >> 2. 电线穿耳机后壳+打结（R、L）>> 3.焊接喇叭（R、L）>> 4.检查焊点品质（R、L）>> 4.耳机前壳+后壳组装（点胶水或超声波）>> 5.装耳套 >> 6.耳机/MIC测频响曲线 >> 7.耳机听音测试 >> 8.MIC听音测试 >> 9.控制盒按键功能测试 >> 10.检查耳机外观 >> 11.包装 （注：不同的耳机组装和包装工艺略有些不同） 二、耳机生产所需性能测试所用仪器及测试项目： 电声测试仪很多种：比较知名如:丹麦B&K(全球最牛电声测试仪，也是公认的标准，一般 用于无响室，价格昂贵不利于用于生产线上测试)、德国DAAS、美国soundcheck/美国LMSSA、意大利CLIO、、国品牌较多，如吉高（原浙大电声）、佳宏等等。 扫频仪：、国品牌较多，如吉高、中策等。 极性机：、国品牌比较多，如吉高、中策等。
Official Test Report正式的测试报告 测试项目：软件性能测试 Project Information项目信息: Project Code: 项目代码 072V24S Project Phase: 项目阶段 研发 Software Version: 软件版本 V1.2 Sample Information样品信息: Sample Level: 样品类型 BMS Quantity: 数量 1 Serial Number: 序列号 020151025 Test Operation Information测试信息: Location: 地点上海博强 Start Date: 开始日期 2015-12-18 Finish Date: 完成日期 2015-12-21 Conclusion结论: Pass通过Fail 不通过 Other其它: Performed by测试: 樊佳伦Signature Date: 2015-12-22 Written by撰写: 邓文签名：日期：2015-12-23 Checked by核查: 董安庆2015-12-24 Approved by批准: 穆剑权2015-12-25
Revision History修订履历 SN 序号Report No. 报告编号 Report Version 报告版本 Contents 变更内容 Release Date 发行日期 1 BQ-72V-BMS-0007 V1.0 New release. 2015-12-25 2 BQ-72V-BMS-0007 V1.1 RTC时间再次验证2015-1-7
软件测试基础教程 测试的基本概念 测试是软件生存周期中十分重要的一个过程，是产品发布、提交给最终用户前的稳定化阶段。 1、测试的分类： 从测试方法的角度可以分为手工测试和自动化测试。 手工测试：不使用任何测试工具，根据事先设计好的测试用例来运行系统，测试各功能模块。 自动化测试：利用测试工具，通过编写测试脚本和输入测试数据，自动运行测试程序。目前最常用的自动化测试工具是基于GUI的自动化测试工具，基本原理都是录制、回放技术。 从整体的角度可以分为单元测试、集成测试、系统测试、确认测试。 单元测试：是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。一般包括逻辑检查、结构检查、接口检查、出错处理、代码注释、输入校验、边界值检查。 单元测试的依据是系统的详细设计；一般由项目组开发人员自己完成。 集成测试：在单元测试的基础上，将所有模块按照设计要求组装进行测试。一般包括逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查、外部接口检查。 系统测试：系统测试是在所有单元、集成测试后，对系统的功能及性能的总体测试。 确认测试：模拟用户运行的业务环境，运用黑盒测试方法，验证软件系统是否满足用户需求或软件需求说明书中指明的软件特性（功能、非功能）上的。 从测试原理上分为：白盒测试、黑盒测试和灰盒测试。 白盒测试：是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。 黑盒测试：是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。在测试时，把程序看作一个不能打开的黑盆子， 在完全不考虑程序内部结构和内部
性能测试项目名称 拟制日期 审核日期 批准日期
修订记录
目录 介绍 (4) 1 目的 (4) 2 总览 (4) 表 1.1 –软件性能测试计划内容 (4) 3 范围 (4) 性能测试方法 (5) 4 负载测试流程 (5) 4.1 系统分析 (5) 4.1.1 创建虚拟用户脚本 (5) 4.1.2 创建负载测试场景 (5) 4.1.3 测试用例执行和性能监控 (5) 4.1.4 分析结果 (5) 5 远景目标和近期目标 (5) 业务流程&测试用例 (5) 6 业务流程 (6) 6.1.1 高容量/高负载流程 (6) 6.1.2 低容量/低负载流程 (6) 7 数据准备 (6) 8 LoadRunner 事务（Transactions） (6) 9 LoadRunner 脚本（Scripts） (6) 10 Load Runner 场景（Scenarios） (6) 11 LoadRunner 监控器（Monitors） (7) 11.1 具体的监控器 (7) 11.2 具体的监控器 (7) 负载测试需求 (7) 12 Checklist (7) 13 测试入口标准 (8) 14 测试结束标准 (8) 应用程序环境 (8) 15 应用程序软件环境 (8) 16 应用程序硬件环境 (8) 17 LoadRunner 环境 (8) 测试结果和版本管理 (9) 18 缺陷/版本管理 (9) 19 发现 (9) 20 详细测试结果 (9) 20.1 场景1 (9)
介绍 1 目的 目的介绍 2 总览 本文档表格中第二部分到第七部分为重要部分。 表 1.1 –软件性能测试计划内容 项目序号名字内容项目内容 1介绍 2性能测试方法 3业务流程&测试用例 4负载测试需求 5应用程序开发环境 6Load Runner 环境 7测试结果 & 版本管 理 3 范围 计划适用范围. 软件需求规格说明书(Software Requirements Specifications - SRS) 软件详细设计文档（Software Detail Design - SDD) 软件测试计划 (SoftWare Test Plan - STP) White Paper: Load Testing to Predict Web Performance. Mercury Interactive Corp.
软件测试中的43个功能测试点软件测试功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。针对web系统的常用测试方法如下： 1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。可以使用一些工具，如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码;HTML Link Validater只能测试以Html或者htm结尾的网页链接;Xenu 无需安装，支持asp、do、jsp等结尾的网页，xenu测试链接包括内部链接和外部链接，在使用的时候应该注意，同时能够生成html格式的测试报告。如果系统用QTP进行自动化测试，也可以使用QTP的页面检查点检查链接。 2. 相关性检查：功能相关性：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确，常见的情况是，增加某个数据记录以后，如果该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形。数据相关性：下来列表默认值检查，下来列表值检查，如果某个列表的数据项依赖于其他模块中的数据，同样需要检查，比如，某个数据如果被禁用了，可能在引用该数据项的列表中不可见。 3. 检查按钮的功能是否正确：如新建、编辑、删除、关闭、返回、保存、导入，上一页，下一页，页面跳转，重置等功能是否正确。常见的错误会出现在重置按钮上，表现为功能失效。 4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。还要检查需求规定的字符串长度是否是正确的，有时候会出现，需求规定的字符串长度太短而无法输入业务数据。 5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型,看系统是否检查字符类型。 6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理，可能添加的时候，将空格当作一个字符，而在查询的时候空格被屏蔽，导致无法查询到添加的内容。 7.特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。常见的错误是出现在% ‘ " 这几个特殊字符 8. 中文字符处理: 在可以输入中、英文的系统输入中文,看会否出现乱码或出错。 9. 检查信息的完整性: 在查看信息和更新信息时,查看
软件测试技术基础教程(第2版)-习题答案
第一章软件测试理论 一、选择题 1、C 2、A 3、D 4、B 5、D 6、 D 7、B 8、B 二、简答题 1． 参考答案： 软件测试是伴随着软件的产生而产生的。在软件行业发展初期，没有系统意义上的软件测试，更多的是一种类似调试的测试，测试用例的设计和选取也都是根据测试人员的经验随机进行的，大多数测试的目的是为了证明系统可以正常运行。 到了20世纪70年代以后，很多测试理论和测试方法应运而生，逐渐形成了一套完整的体系。在产业界，从20世纪70年代后期到20世纪80年代中期，很多软件企业成立了QA或者SQA部门。后来QA的职能转变为流程监控(包括监控测试流程)，而测试(Testing)则从QA中分离出来成为独立的组织职能。 到了20世纪80年代初期，一些软件测试的基础理论和实用技术开始形成，软件测试作为软件
质量保证（SQA）的主要职能，包含软件质量评价的内容。软件测试已有了行业标准（IEEE/ANSI ）。 在我国，软件测试目前还没有形成一个真正的产业，尚处于起步阶段。 但是，在国内，现在在软件测试行业中各种软件测试的方法、技术和标准都还在探索阶段。 总之，国内软件测试行业与一些发达国家相比还存在一定的差距。 2. 参考答案： 软件缺陷造成的修复费用随着时间的推移呈指数级地增长，如下图所示。 3． 参考答案： 软件测试的复杂性体现在：
?不可能对程序实现完全测试。 ?杀虫剂现象，即为了克服被测试软件的免疫力，软件测试员必须不断编写新的测试程 序，对程序的各个部分进行不断测试，以避 免被测试软件对单一的测试程序具有免疫 力而使软件缺陷不被发现。 ?软件测试的代价不容易掌握，因为随着测试量的增加，测试成本将呈几何数级上升，而 软件缺陷数量降低到某一数值之后将没有 明显的变化，寻求最优测试点，掌握好测试 工作量是至关重要的。 ?在实际操作过程中，测试人员要进行正确的判断，合理的取舍，根据风险分析来决定哪 些故障需要修复，哪些故障可以不修复，即 并不是所有的软件缺陷都需要被修复。 4． 参考答案： 软件测试是软件生命期中费用消耗最大的环节。测试费用除了测试的直接消耗外，还包括其他的相关费用。影响测试费用的主要因素有：（1）软件的功能，软件产品需要达到的标
第一章软件性能概述 1.1软件性能基础 1.1.1软件性能的概念 软件性能是与软件功能相对应的一种非常重要的非功能特性,表明了软件系统对时间及时性与资源经济性的要求。对于一个软件系统,运行时执行速度越快、占用系统存储资源及其他资源越少，则软件性能越好。 软件性能与软件功能是软件能力的不同体现，以一个人的工作能力来比喻，“功能”是某个人能够做的事情，“性能”指此人完成这件事情的效率。在功能相同的情况下，性能是衡量事情完成效果的一个重要因素。 1.1.2 不同角色对软件性能的理解 1）从系统用户角度看软件性能 系统用户指实际使用系统功能的人员。系统用户看到的软件性能就是软件的响应时间，即当用户在软件中执行一个功能操作后，到软件把本次操作的结果完全展现给用户所消耗的时间。 系统响应时间的影响因素有：功能的粒度、客户端网络情况、服务器当前忙闲情况等。从系统用户角度看，软件响应时间越短，系统性能越好。 2）从系统运维人员角度看软件性能 系统运维人员指负责软件系统运行维护的工作人员。
运维人员在关注系统响应时间的同时，还需要关注系统的资源利用率、系统最大容量、系统访问量变化趋势、数据量增长幅度、系统扩展能力等，并在此基础上制定合理的系统维护计划，以保障系统能够为用户提供稳定可靠的持续服务。 运维人员关注的性能问题： 运维人员关心的问题软件性能描述 应用服务器和数据库服务器的资源使用状况合理吗资源利用率 系统是否能够实现扩展系统可扩展性 系统最多能支持多少用户的访问系统容量 系统最大的业务处理量是多少系统容量 系统性能可能的瓶颈在哪里系统可扩展性 更换哪些设备能够提高系统性能系统可扩展性 系统能否支持7X24小时的业务访问系统稳定性 3）从系统开发人员角度看软件性能 系统开发人员指系统软件的设计和开发人员。 开发人员关注的性能问题： 开发人员关心的问题问题所属层次 数据库设计是否存在问题数据库设计 代码是否存在性能方面的问题代码 系统中是否有不合理的内存使用方式代码
软件测试技术基础教程 软件测试技术基础教程。近来，软件测试行业发展迅速，企业越来越重视测试了。越来越多的人加入了测试大军中，很多人也想通过自学来学习软件测试技术加入这个行业，更多的人开始关注软件测试案例教程，那么软件测试案例教程哪里好呢？软件测试案例教程内容有什么？软件测试案例教程学什么？下面我为大家简要介绍一下软件测试案例教程——黑盒测试和白盒测试 黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。 白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。 软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误： 1、是否有不正确或遗漏的功能？ 2、在接口上，输入是否能正确的接受？能否输出正确的结果？ 3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？ 5、是否有初始化或终止性错误？ 软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查： 1、对程序模块的所有独立的执行路径至少测试一遍。 2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性，等等。
软件测试理论基础测试题（一） （2012年11月14日） 说明：试题共分两大题目总分150，本试题请闭卷。 一、选择题（每题1分） 1、下列文档中不是文档测试需要测试的内容是（）A A．合同文档B．管理文档C．开发文档D．用户文档 2、下列逻辑覆盖测试方法中，覆盖能力最强的是（D） A．语句覆盖B．判定覆盖C．条件覆盖D．条件组合覆盖 3、关于软件测试的原则，下列说法错误的是（AB）（选择两项） A．软件测试应该从代码完成后开始 B．程序员测试自己编写的代码有助于测试的深入广泛进行 C．软件测试必须确定预期输出结果 D．测试过程中要注意测试中的缺陷群集现象 4、下列关于测试和调试的说法中正确的是C A．测试和调试没有本质区别。目的都是为了发现软件系统中的错误。 B．测试只是测试人员的职责，在整个测试活动中不需要开发人员的参与。 C．调试一般不能确定程序中潜在错误发生的原因 D．调试主要在软件的开发阶段进行。 5、下列关于正确选择自动化测试工具的说法中错误的是（B） A．选择适合自己公司项目的自动测试工具，可以从测试工具的功能，集成能力，操作系统和开发工具的兼容性等几个方面来考虑。 B．引入工具时不需要考虑工具引入的连续性和一致性 C．尽量选择主流测试工具 D．如果需要多种工具，尽量选择同一公司的产品。 6、下列关于测试用例的设计说法中正确的是（D） A．只有发现了到目前为止没有发现的缺陷的测试用例才是有价值的用例。 B．测试用例设计应该遵循从简单的原则，以便节约测试时间 C．测试用例的设计经常耗时很大。所以已设计好的测试用例不能变化 D．测试用例的设计依据需求说明书。应该覆盖用户需求 7、下列各选项的文件扩展名代表可执行文件的是（）B A．EXE ,COM B．EXE,BA T C．COM,DLL D．DLL,BA T 8、关于黑盒测试与白盒测试的区别，下列说法正确的是（A） A．白盒测试侧重于程序结构，黑盒测试侧重于功能 B．白盒测试可以使用自动测试工具，黑盒测试不能使用工具 C．白盒测试需要开发人员参与，黑盒测试不需要。 D．黑盒测试比白盒测试应用更广泛 9、使用正交排列方式设计测试用例的最大好处在于（B ） A．对所有的输入组合创建测试用例, B．使用最少的测试用例获得最大的测试覆盖率. C．不用写测试用例 D．便于进行兼容性测试. 10、一般情况下，当一个软件新版本提交测试时，要有1-2名测试人员首先进行（C）可
通过对软件测试中性能测试的初步了解，总结软件性能指标中的几个术语：响应时间、并发用户数，吞吐量，性能计数器，TPS，HPS。在使用性能测试工具进行测试时，还会接触到“思考时间（Think Time）”的概念。供以后学习使用。 1、响应时间 根据个人理解，响应时间指的是“系统响应时间”，定义为应用系统从发出请求开始到客户端接收到响应所消耗的时间。把它作为用户视角的软件性能的主要体现。它包括网络上的传输时间，web服务器上处理时间，APP服务器上处理时间，DB服务器上处理时间，但不包括浏览器上的内容显示时间，即“呈现时间”，这是因为呈现时间在很大程度上取决于客户端的表现，例如，一台内存不足的客户端机器在处理复杂页面的时候，其呈现时间可能就很长，而这并不能说明整个系统的性能。 许多描述性能测试的书或者工具把“响应时间”定义为“应用系统从请求发出开始到客户端接收到最后一个字节数据所消耗的时间”。造成这种差异的原因是，对用户体验来说，可以采用一些技巧在数据尚未完全接收完成时进行呈现来减少用户感受到的响应时间。当然，针对Web 应用的测试（因为浏览器行为是既定的），我们仍然采用后一种定义方式来描述响应时间。
关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受是带有一定的用户主观色彩，也就是说，响应时间的“长”和“短”没有绝对的区别。因此，在进行性能测试时，“合理的响应 时间”取决于实际的用户需求，而不能依据测试人员自己的设想来决定。 2、最大并发用户数 有两种理解方式，一种是从业务的角度来模拟真实的用户访问，体现的是业务并发用户数，指在同一时间段内访问系统的用户数量。另一种是从服务器端承受的压力来考虑，这里的“并发用户数”指的是同时向服务器端发出请求的客户数，该概念一般结合并发测试（Concurrency Testing）使用，体现的是服务端承受的最大并发访问数。 在实际的性能测试中，经常接触到“并发用户数”、“系统用户数”和“同时在线用户数”的概念，下面引用一本书的例子来说明它们之间的差别。