测试理论
常见英文单词一
工作中经常遇到的单词：
bug（漏洞） percent（百分比） release（发布） test UAT(验收测试) build（构建）code 代码 list清单 deploy（发布） status（状态） login（登陆） logout 退出mail（邮件）URL（网址）account （账号） password（密码） leader (老大) not found （未找到）fail （失败）error （错误） success（成功）edit（编辑） product（产品）system（系统） admin/administrator（管理员） keyword（关键词，关键字） case（案例） user/username(用户名) ip 地址 host 主机 port 端口 submit 提交 firefox 火狐 chrome 谷歌 ie 微软 Web 网页 app 手机段 PC 电脑端
BAT 百度、腾旭、阿里
安装软件常用单词：
Setup 安装 accept 接受 agreement协议 license 许可证 next 下一步 back 返回，上一步 cancel 取消 install 安装 uninstall 卸载 finish 完成 agree 同意 ok 完成 close完成 download 下载
数据库常用单词：
database（数据库） use（使用） select(查询) from（从…） show 展示 table（表格） where（条件）or(或者)and（并列）like（像…）in（在…里）between（两者之间） limit限制top（顶部） order by（排序）distinct（区别）desc（降序） asc（升序） sum（求和）avg（平均） max（最大） min（最小） count（统计） group by （分组） having(条件) null（空值） not 不是is 是 insert into（插入） values（值）update（更新） set（设置）create（创建） primary 主要的 key 钥匙 关键 int（整数型） char（字符型） delete（删除） view（视图）drop 删除 truncate 清空 join 连接 inner 内部的 outer 外部的 left 左边 right 右边 alter（改变）Column（列）add（添加）modify 修改 change 修改 rename 重命名to 到 index（索引） boolean 布尔型
Linux 操作系统：
copy 复制 move 移动 grep过滤 kill 杀死 find 查找 tail 尾巴 head 头 type类型
英语单词二
python编程语言： code 代码 print 打印 Numbers（数字）（int，num）String（字符串）(str) List（列表） Tuple（元组） Dictionary（字典） （dict） delete 删除（del） Append 添加 remove 删除 reverse 颠倒，反转 if 如果 else 否则 range 区间，范围 While 当 break 跳出，暂停 continue 继续 pass 通过 default 默认 class 类 Definition 定义(def) return 返回 file 文件
open 打开 input 输入 Row 行 column 列 read 读 write 写
close 关闭 Import 导入 from 从哪来 max 最大 min 最小 type 类型 Try 尝试 except exception 异常 length 长度（len）True 真 false 假 bool 布尔值 UI自动化单词： driver 驱动 get 获得，拿 find 查找 element 元素 by 通过 link 连接 partial 部分的text 文本 tag 标签 click 点击 send 发送 keys 关键词 s elector 选择器 window 窗口 time 时间 sleep 睡眠 back 返回 forward 向前refresh 刷新 quit 退出 attribute 属性 display 展示 size 大小 location 位置clear 清空waite 等待 implicitly 暗中的 不明显的 until 直到。。。为止 lambda 匿名函数title 标题 current当前的 double 双倍的switch 切换 to 到 frame 表单 default 默认的
content 内容 handle 手柄alert 警报 accept 接受 dismiss 去除 消除 confirm 确认 prompt 提醒 system 系统 execute 执行 script 脚本 document 文档 set 设置 scroll 滚动 visible 可见的 value 值 screenshot 屏幕截图 image 图像 width 宽度 height 高度 save 保存crop 裁剪 剪切 connect 连接 cursor 指针 random 随机数 assert 断言 equal 相等 suit 集合 run执行 add 添加 year 年 month 月 day 天 hour 时 minute 分钟 second 秒 report 报告 input 输入 object 对象 page 页面 model 模型 login 登陆 logout退出 main 主函数 data 数据 common 共同的 case 案例 expect 期待
第一章软件测试基础知识介绍
软件software：是一系列按照特定顺序组织的计算机数据和指令集合。是电脑中的非有形部分；电脑中的有形部分称为硬件，由电脑的外壳及各零件，电路所组成。电脑软件需要硬件才能运作，反之亦然，软件和硬件都无法在不相互配合的情形下进行实际的运作。 一、计算机程序的定义 计算机程序computer program：是指一组计算机执行动作或做出判断指令，通常用某种程序设计语言编写，运行某种目标体系结构上。 二、软件测试的相关概念 QC品质控制：quality contrl QA：quality assurance QA是提供足够的信任，对外表明物质能够满足品质的要求。 软件测试的名词：产品（需求）、架构、开发、测试、运维。 测试：是根据需求进行检测的，但是软件测试并不仅是根据需求，也进行检查常识的错误。 测试大纲：为了防止检查遗漏而把每一个检查点用一个文件记录下来，就是测试大纲。 测试用例：把每一项是怎么进行检查的，记录到一个文件（excel）中，就是测试用例。 Bug单（缺陷报告）：测试中出现的问题，记录到一个文件里让做这个开发改好，记录问题的文件就叫bug单 软件测试的项目流程：首先产品经理提出需求，开发，测试，产品进行评审，然后开发架构师会依据需求文档设计架构设计文档，之后开发再根据架构文档分别分配各自模块同时产出详细文档；进行开发开发人员进行开发的同时，测试编写测试用例，编写完成后，开发、测试、产品同样进行评审。开发完成后，测试依据测试用例执行测试。发现bug就让开发去解决，当所有问题都解决后，进行回归测试，然后让运维发布到预发布环境中，然后在进行回归测试，然后再发布到生产环境，再看下有没有问题，没有问题就说明上线完成了。
三、用到的文档范围 四、软件的定义：使用人工和自动手段来运行或测试某个系统的过程；其目的在于检验它是否满足规定需求或弄清预期结果和实际结果之间的差别。
五、软件测试的检查内容 1. 保证程序与相应规范说明一致 2. 发现软件中的缺陷 3. 确保软件不做不必要的事情 4. 确保系统合理的执行 5. 明确在系统失败之前可以让系统正常运行运行到何种程度 6. 明确发布给用户的系统有哪些风险
六、软件测试的一般内容 1. 制定测试计划 2. 设计测试用例 3. 实施软件测试 4. 提交缺陷单（缺陷报告或bug单） 5. 测试总结
七、软件测试目的 从用户角度出发，希望通过软件测试来暴露软件隐藏的错误和缺陷，从而考虑是否接受该产品。从软件开发者角度出发，希望表明软件产品不存在错误和缺陷，验证软件能正确的实现用户的需求，确立人们对软件质量的信心。从软件管理者角度出发，希望花费有限的资源达到该软件的质量要求，经费和进度是其首要考虑的焦点。 1. 一个成功的软件测试的案例在于发现了至今为发现的错误 2. 一个成功的软件测试时发现了至今未发现的错误的测试 3. 测试不仅是为了要找出错误 4. 没有发现错误的测试也是有价值的，完整的测试是评估软件质量的一种方法 软件测试的根本目的：是交给用户的产品符合用户的需求，是产品在用户使用之前尽可能多的发现问题，并改正问题，最终把一个高质量的软件系统交给用户使用。
八、测试与调试 1. 软件测试是找出软件已经存在的错误，而调试是定位错误，修改程序以修改错误。 2. 测试的对象可以是文档和代码，而调试的对象只能是代码。 3. 调试是随机性的，由程序员完成，为了程序可运行。 4. 测试是有目的性的，由测试人员完成，为了程序可完成指定功能。
九、软件测试人员必备素质 1. 责任心 2. 团队合作精神 3. 理解能力，表达能力 4. 时时保持怀疑的态度，并且有缺陷预防的意识 5. 具备一定的编程经验
第二章Bug的定义及分类
一、软件缺陷产生的原因有哪些： 1. 人员与人员的沟通交流不够，交流上有误解或者根本不进行交流 2. 程序本身就有错误 3. 软件的复杂性 4. 需求的不断变化 5. 工期短，任务重，时间压力大 6. 参与人员的过度自信 7. 文档的不完善
二、缺陷=bug，软件bug并不仅仅指系统的错误 Bug的定义：在软件使用过程中所出现的任何问题（或是导致软件不符合设计要求或者不满足消费者需求的问题都可以成为bug）
三、缺陷的分类 按照严重级划分： 影响测试进度的问题：死机、功能问题、界面问题、优化和建议等 按优先级划分：应立即修复的问题、在产品发布前必须修复的问题、如果时间允许应该修复的问题、可以在版本中存在的问题。 严重级高的问题不一定是优先级高的问题，因为有些问题会退后解决，但是影响进度的问题一定是优先级高的问题。
四、寻找bug的经验 1. 可以将工作中用到的文档（需求说明书），作为识别和判断的标准。 2. 通过和开发人员沟通可以获知软件设计的逻辑过程，分析可能存在的潜在问题。 3. 对软件产品的行业背影知识的了解及同行业一般用户的操作习惯来发现问题。 4. 善意使用手机，学习和分享其他人判断缺陷的方法和经验。
五、如何保证软件中缺陷的重现 1. 不要相当然的接受任何假设，要善于记录操作步骤 2. 要善于查找缺陷重现的规侓，是否在特定的时刻出现 3. 关注硬件失效问题，硬件可能不按照预定的方式工作 4. 关注软件失效问题，对缺陷的修改，可能会产生新的缺陷
六、随机错误（无法重现的缺陷）的处理方法 对于无法再现的缺陷，应对这样的缺陷应该做好详细的记录，并尽快提交给开发人员，对于难以再现的缺陷要合理的安排时间不能因小失大。
七、怎么有效的记录bug 1. 保证重现缺陷 2. 分析故障，使用最少的步骤重现缺陷 3. 包含所有的重新缺陷的必要步骤 4. 方便阅读，尽量简单，一个缺陷一个报告 5. 注意自己的语气
八、Bug单内容 1. 所属产品 2. 所属的模块 3. 影响版本 4. Bug类型 5. Bug的标题 6. Bug的严重程度 7. Bug的优先级【高，中，低】 8. 重现步骤包括三个方面：操作步骤，预期结果，实际结果。 9. Bug的重现上传对应的文件（如操作时发现的截图）
严重级分为三个等级： 严重：严重影响系统的，导致系统不能进行操作的。 一般：需求分析提到的基本功能没有达到，基本功能没有按要求的实现，等等。 轻微：操作不方便，界面错误，错误字等等其它错误。 优先级： （说明：紧急相当于执行前的准备工作，重要相当于后续的工作。） 重要且紧急：优先级最高，一定要做的 重要不紧急：暂时可以先缓一缓 但一定要做的 紧急不重要：可以先准备下，随时准备做的 不紧急不重要：可以忽略不计的 修改分为三个状态： 已改：已修改的错误。 未改：没有修改的错误。 无需修改：暂时不修改的错误
第三章bug的处理流程及状态
一、Bug的处理流程： 首先测试提交缺陷报告给开发经理，然后开发经理分配缺陷报告给对应的开发人员，开发人员处理缺陷报告，处理完毕后，测试进行反测，反测不通过，直接打回，反测通过，就关闭缺陷报告。 一般工作中，测试人员直接提交缺陷报告给对应的开发人员。 反测：某一个功能的缺陷被开发修改后，测试人员重新测试看这个问题是否存在。 回归测试：是指开发修改完成这个bug后，不仅要验证这个bug还要看下是否影响到其他的功能，对这个bug相关的功能进行回归测试。一般上之前要对上线的所有功能以及影响点进行回归测试。 影响点是如何得出的：一般在测试之前开发和测试都会进行一个影响点分析会议，开发会详细描述本次更新的影响范围。
 二、缺陷报告的分类 按照处理状态分类： 新提交的 已分配的 待确认的 问题未解决 已解决的 待返测的 已关闭的 待归档的 已归档的 按处理意见： 已修改的 不是问题 无法修改 以后版本解决 保留 重复 无法重新 Bug状态及状态流程图 Bug状态status：指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed closed及Rejected等。 New：测试人员新问题提交所标志的状态。 Open：任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。Bug解决中的状态，由任务分配人改变。对没有进入此状态的bug，程序员不用管。
Reopen：测试人员对修改问题进行验证后没有通过所标志的状态，或者已经修改正确的问题又重新出现错误。由测试人员改变。 Fixed：开发人员修改问题后所标志的状态，修改后还未测试。 Closed：测试人员对修改的问题进行验证后通过所标志的状态。由测试人员改变。 Rejected：开发人员认为不是bug，描述不清、重复、不能复现、不采纳所提意见建议，或虽然是个错误但还没到非改不可的地步，故可忽略不计，或者是测试人员提错，从而拒绝的问题。由bug分配人或者开发人员来设置。
三、几乎所有的bug都可以转化为未解决的
第四章—软件测试相关模型
一、软件测试的生命周期 瀑布模型：  各阶段产生的文档 1. 计划阶段：项目计划、开发计划、测试计划 2. 需求分析：需求文档、（需求说明书）、产品模型 3. 设计阶段：架构文档（架构设计说明书），详设文档、接口文档一般是开发人员编写 4. 编码 ：开发提出的代码文件，系统部署文档 5. 测试阶段：测试大纲（一般有leader编写）、测试计划、测试用例（case）、缺陷报告、测试总结  螺旋模型的每一次迭代（更新）都包含了以下六个步骤： 1. 确定目标可选方案 2. 识别和解决项目风险 3. 评估技术方案和替代解决方案 4. 开发本次迭代的交付物和验证迭代产生的正确性 5. 计划下一次迭代 6. 提交下一次迭代的步骤和方案 螺旋模型又叫迭代，螺旋模型是软件行业中一种标准开发规范，如果项目没办法一次性完成，则采用分批次完成，每一次迭代都必须按照螺旋方案走。
二、软件测试的生命周期 1. 制定测试计划 2. 测试设计和研发 3. 实施软件测试 4. 编写测试报告 5. 版本发布 6. 测试总结 [image:3AAC7037-F9CB-4B60-A629-A33814EE80BC-275-00014D441F5242E9/图片10.png]
三、软件测试的流程 当我们拿到需求之后，首先产品、开发、测试、产品经理会一起对需求进行评审，评审通过后，我们会根据需求文档先列出测试大纲，然后在编写测试用例，同时开发人员也会进行代码的开发。当然测试用例编写完成之后会进行组内，组外的评审，评审通过后。开发完成后提交测试版本（提测），我们依据测试用例执行测试，测试中发现Bug,就把Bug提交给对应开发，开发修改之后进行返测，验证OK关闭Bug,否则继续修改，当所有问题修复完成之后进行回归测试，运维发布到预发布环境中，在进行回归测试，然后运维在发布到生产环境中，在进行回归测试，最后上线无问题后编写测试总结。
四、测试计划的内容 1. 项目背景 2. 测试目的 3. 测试起止时间 4. 测试参与人员 5. 测试范围 6. 测试环境要求 7. 任务分配 8. 测试里程碑 9. 测试策略
五、测试报告内容 测试报告一般由邮件在执行测试过程中每天下班时发送，由测试负责人发送给测试、开发、产品，并抄送相关领导，主要包括测试范围、测试人员、测试执行时间（经过了几轮测试，经过了几天测试），测试过程中发现的问题（致命多少、严重多少、一般多少、微小多少、建议多少、延期处理的问题等），另需附带Bug list（Bug的清单） 注：阻塞问题，一定要在工作日报中体现，有风险造成延期！！！
六、测试总结的内容 测试总结一般在上线之后由邮件发送，主要包括测试项目、背景、目的、测试环境（软件和硬件环境）、测试用例、测试分几个阶段、测试结果、测试覆盖率、发现Bug的数量及Bug的分布（多少Bug严重、一般、微小、致命等等）、遗留的问题、结论建议以及典型Bug的原因分析。
七、常见测试策略（测试方法） 1. 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行的测试。 2. 功能测试：对软件需求规格说明书中的功能逐项进行的测试，以验证功能是否满足要求（针对峰值较高类，内部软件一般不需要）。 3. 性能测试：对软件需求规格说明书中的功能逐项进行的测试，以验证功能是否满足要求。 4. 压力测试：在系统资源较低的情况下软件系统的运行情况，目的是找到系统在哪里失效以及如何失效的地方。 5. 负载测试：系统在超负荷环境中运行，程序是否能够承担。 （3-4-5都属于性能测试） 6. 接口测试：对软件需求说明书中的接口需求逐项进行的测试。 7. 界面测试：对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户需求。 8. 兼容性测试：测试软件在不同操作系统，不同系统版本，不同载体上能否正常运行。 9. 可靠性测试：在真实或仿真的环境中，为做出软件可靠性预估而对软件进行的功能测试。 10. 易用性测试：指用户在使用软件过程中是否感觉方便，如：操作鼠标三次即可到达用户目的。 11. 配置测试：对被测系统软硬件的调整，了解各种不同环境对系统性能的影响程度，从而找到系统各项资源的最优分配原则。 12. 安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效【（具有专业性）黑客】。 13. 安装测试：对安装过程是否符合安装规程的测试，以发行安装过程中的错误。 14. 加密测试：如：一些敏感信息。 15. 交叉测试：把测试人员所测试的模块交换测试。 16. 文档测试：是针对相关设计报告和用户使用说明进行检测。设计报告主要测试程序与设计报告中的设计思想是否一致，而对用户使用说明的测试主要是验证用户使用说明书中对程序操作方法的描述是否正确，重点对用户使用说明中提出的操作列子进行测试，保证采用的操作方法能够在程序中正确完成操作。
八、敏捷测试敏捷开发 1. 敏捷开发的最大特点是高速迭代、有周期性，并且能够及时的响应客户的频繁反馈。 敏捷测试特点： 1. 每日站会（会议） 2. 极限编程 3. 测试驱动开发 敏捷测试与传统测试的区别： 1. 开发与测试同时进行 2. 工作任务划分比较清晰 3. 耗时或者比较难以解决的问题会在以后版本中解决 4. 测试贯穿于整个软件的生命周期 第五章—软件测试的流程 一、测试的环境要求 1. 符合软件运行的最低要求 2. 营造相对简单独立的测试环境 3. 无毒的测试环境
二、软件测试的模型
[image:ECFCD377-B71E-4F58-BA51-7C68B4AD62B4-275-00014D327C4EF00E/图片9.png]
 软件测试V模型 V模型中从左到右的过程，描述了基本开发过程和测试行为。V模型的价值在于它非常明确的标明了测试过程中存在的不同级别，并且清楚的描述了测试阶段和开发过程期间各阶段的对应关系。 局限性：把测试作为编码后的最后活动，需求分析等前期产生的错误直到后期验收测试才能发现。  [image:DCAFDBEC-2576-4B7B-9112-4B51173492B3-275-00014D2DE28B8CD4/图片8.png]
W模型是V模型的发展，强调测试伴随着整个软件开发周期，而且测试对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发同步进行，从而有利于尽早的发现问题。 W模型局限性：其与V模型都把软件的开发视为需求、设计、编码等一系列的串行活动，无法支持迭代、自发性以及变更调整。
[image:1B9CB3F5-C7CB-4AD3-BDE0-EAB549E837EF-275-00014D277552FB93/图片7.png]
 H模型中，软件测试活动过程完全独立，贯穿于整个产品周期，与其他流程并发进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行，并且依据被测物的不同而分层次进行。
三、软件测试的过程 单元测试：主要测试程序代码，为的是确保各单元模块功能正常。有具体到模块的测试，也有具体到类、函数的测试等。————一般是由开发在开发阶段完成。 集成测试（联调测试）：在单元测试的基础上，将单元组成完整的体系，测试软件单位之间的接口是否准确，数据能否正常传递。—————比如注册和充值这两个功能是否联通。 系统测试（ST测试）：是将经过测试的子系统装配成一个完整系统进行测试。他是检验系统是否能提供需求中指定功能的有效方法。系统测试的目的是对最终软件系统进行全面测试，确保最终软件系统满足产品需求且遵循系统设计。【对系统进行全面测试】 验收测试（UAT测试）：是以用户为主的测试，一般情况下产品、开发、测试经理都要参加，其目的是向客户证明产品是可靠的，符合需求的，必须有用户代表参加（或需求方）。 （集成测试、系统测试、验收测试为测试工程师一般工作内容） 验收测试又分为α测试和β测试 Α测试：是验收测试前期，模拟用户的真实环境，全体测试人员和用户代表参与，开发同在现场，发现问题及时解决。 Β测试：是验收后期（上线），在用户环境下运行，部分测试人员和全体用户参与，开发不在现场，发现问题后期解决。 单元测试、集成测试、系统测试之间的区别就如：句子－－段落——文章。 运行维护（运维）：是生命周期中持续时间最长的阶段，为了延长软件的使用寿命，适应用户需求，就必须对软件进行维护。包括纠错性维护和改进性维护。
四、静态策略的分类 静态测试：不运行被测程序本身，而是通过直观的审阅代码去寻找程序中可能出现的错误或评估程序代码的过程。 动态测试：实际运行被测程序本身，输入相应的测试用例，检查预期结果与实际结果之间的差异。 黑盒测试（功能测试）：数据驱动测试或基于需求说明书的测试（手工测试）；测试过程中把被测程序看成一个黑色盒子，不考虑程序内部结构，只需知晓该程序输入和输出之间的关系。 白盒测试（结构测试）：逻辑驱动测试或基于程序本身的测试，测试过程中把被测程序看成一个白盒子，打开盒子依据程序内容设计编写测试用例。 灰盒测试：是介于白盒测试黑盒测试之间的一种测试，其多用于集成测试阶段，不仅关注输入、输出的正确性，同时又需关注被测程序的内部情况。 随机测试：是指测试中所有的数据都是随机生成的，其目的是模拟用户的真实操作，用来发现一些边缘性错误。 常见白盒测试方法： 1. 语句覆盖 2. 分支覆盖或判断覆盖 3. 条件覆盖 4. 判断/条件覆盖 5. 路径覆盖 ＊＊＊＊＊ 冒烟测试（版本确认测试）：冒烟测试占测试用例10%，是每一个阶段必须首要进行的步骤，主要针对软件的主功能及关键功能的测试。在软件测试前，开发和测试都会对提交测试的版本进行冒烟测试，确保程序主功能没有问题，以确保测试工作能够正常进行。 手工测试：由测试人员执行测试用例的一种传统测试方法，比较预期结果与实际结果的差异。 自动化测试：是在手工测试的基础上进行的测试，运用自动化测试工具执行测试用例。
五、按照测试阶段分类 ＊＊＊ 单元测试→~接口测试~→联调测试→系统测试→验收测试 接口测试是测试各个模块互相调用的一种测试。主要用于检验外部系统与系统之间及内部各子系统间的交互。其重点检查数据的交换和系统间的相互逻辑依赖关系等。 （接口测试在单元测试之后，集成测试之前）
第六章软件测试的认识 一、软件测试的原则 1. 应尽早执行软件，并且把软件测试贯穿于软件的整个生命周期 2. 软件测试应追溯需求 3. 测试应该由第三方完成 4. 不做不充分测试，不做过多测试，因为Bug是不可穷举的 5. 必须彻底检查每个测试结果 6. 充分注意Bug集群现象
二、缺陷的二八定理 在分析、设计、实现阶段的复审和测试工作能够发现并规避80%的缺陷，而系统测试又能找出其余缺陷的80%，最后4%的缺陷可能只有在用户大范围、长时间使用后才会暴露出来。 响应时间的2-5-10原则： 1. 就是用户在2秒以内得到响应，会感觉系统响应速度很快 2. 当用户在2-5秒之间得到回应时，会感觉系统的响应速度还可以 3. 当用户在5-10秒以内得到响应，会感觉系统响应速度很慢，但是还可以接受 4. 而当用户在超过10秒后仍无法得到响应，会感觉系统糟透了，或者认为系统已失去响应，而选择离开这个Web站点，或是发起第二次请求 C/S架构与B/S架构 C/S架构：（需安装，APP性质）需要安装客户端才能够使用的软件。每次更新都需要更新服务端和客户端。如：超市收银系统，每次更新每台电脑都必须重装客户端，有分店则更加麻烦，及其耗费人力、物力、财力。 B/S架构：（网站性质）只需要一个浏览器就可以访问服务，只需更新服务端，不需要更新浏览器，用户主动性高。如：天猫、京东。 评审目的：是否存在不正确的、有冲突的、有歧义或有遗漏的地方 如：需求文档的评审（开发、测试、产品经理） 测试用例的评审（开发、测试、产品经理） 新项目：测试点有无遗漏，测试规范 项目中任何环节产生的文档都是需要评审的 三、怎样正确认识软件测试 1. 软件的质量不是靠测出来的，其只是一种有效提高软件质量的手段 2. 软件测试并不比开发容易 3. 软件测试需开发和测试共同努力 4. 软件测试并不软件开发后期的一个阶段 四、如果没有需求文档如何执行测试 有无需求文档，都一定会存在需求人，首先应与其确定需求点，同开发和产品经理分析，通过讨论得出需求的一些~分支和细节~，开发会讲解他们是如何实现需求，以及测试是应该注意的点，依据以上信息作出思维导图，并根据思维导图编写测试用例，最后执行测试。 五、如果测试时间不够怎么办 首先向测试经理申请安排同事支援，加急测试；如果没有，则反馈项目经理，看是否可以增加时间；若是确实不够，我们首先保证核心业务和主要功能的测试OK，确保正常流程无问题，同时在开发阶段督促开发自测、单元测试；以及列出的测试点，依据每个功能的优先级进行测试，更要细化每天测试任务，加班进行测试，并且要产出每日测试报告，发送项目人员并评估出风险等。 六、上线前发现一个Bug 首先要分析Bug严重程度，不严重就是开发加班修改，然后上线；若是较为严重，先看开发加班能否修改完成，如果不能，就像项目经理申请是否可以延期上线。一般情况下我们经过几轮测试，在上线前是不会出现此问题的。 七、上线后发现一个Bug 如果在线上（生产环境）发现Bug后，首先查看 Bug严重程度，较为严重，则滚回上一个版本，然后进行Bug修改，无问题后再进行上线；如果不是很严重，我们需上一个紧急“”（测试），并要求开发打一个补丁上去。测试时仍要先布测试环境进行测试，在发布预发布环境，最后到生产环境。一般情况下，我们测试会经过单元、集成、系统、预发布的几轮测试，上线后是不会出现这个问题的。 八、测试时发现一个Bug，怎么处理 发现Bug首先进行截图保存，在提交正式Bug单给对应的开发人员，然后开发人员进行处理。 九、发现一个Bug，开发认为不是Bug怎么办？ 首先从需求文档寻找证据，说服开发；若是需求文档没有描述清楚或者没有描述，则找产品经理或者需求人，有他们判定是否是Bug。 十、单元测试辅助测试模块 驱动模块：用以模拟待测模块的上级模块 功能：在集成测试中接受测试数据，把相关数据传送给待测模块，启动待测模块并打印出相应结果。 桩模块：用以模拟待测模块工作过程中所调用的模块 功能：有待测模块调用，其一般只进行很少的数据处理，以便于检验待测模块与其下级模块的接口。 十一、集成测试方法 1. 增式集成法：自顶向下集成，自底向上集成 2. 非增式集成法，也叫整体集成方法 十二、软件测试人员如何保证版本质量 ＊＊＊ 1. 首先开发提交测试之前都会进行自测和冒烟测试 2. 测试过程中经过集成测试、系统测试、验收测试来保证质量 3. 测试用例都会进行评审 4. 上线之前一般都会进行交叉测试和回归测试 十三、系统发布上线的标准 1. 系统满足用户所规定的功能及性能需求 2. 关闭且修复所有Bug 3. 通过用户验收测试 4. 执行所有测试用例
CMMI模型
Capability Maturity Model Integration
CMMI模型：能力成熟度模型集成（也称为：软件能力成熟度集成模型），是美国国防部的一个设想，1994年美国国防部与卡内基-梅隆大学下的软件工程研究中心以及美国国防工业协会共同开发和研制的，他们计划把现在所有现存实施的与即将被发展出来的各种能力成熟度模型，集成到一个框架中去，申请此认证的条件是该企业具有有效的软件企业认定证书。 1. 初始级 软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力，管理是反应式的。 2. 可管理级 建立了基本的项目管理过程来跟踪费用、进度、和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 3. 已定义级 已将软件管理和工程两方面的过程文档化、标准化，并综合成该软件组织的软件过程。所有项目均使用经批准、裁剪的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 4. 量化管理级 分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个做出结论的客观依据，管理能够在定量的范围内预测性能。 5. 优化管理级 过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。