什么是软件测试 在一定的条件下，执行程序，比较实际结果与预期结果的过程

测试与调试的区别 测试 - 由测试人员完成 - 破坏性的 调试 - 由开发人员完成 - 建设性的

测试的七大原则 通过测试可以显示缺陷的存在 穷尽测试是不可能的 测试要尽早介入 缺陷的集群效应 杀虫剂悖论 测试依赖于具体的商业背景 没有缺陷的系统并不代表是有用的系统

测试过程/测试流程/测试生命周期 制定测试计划 - 测试组长/主管/经理 - 测试任务，时间，人员的安排 制定测试方案 - 测试管理人员/测试工程师 - 如何测试的指导性文档 分析测试需求 - 测试工程师 - 基于软件需求文档，分析测试点 设计并编写测试用例 - 测试工程师 - 将分析的测试点转换为企业标准的测试用例 评审测试用例 - 开发+测试+需求人员 搭建测试环境(Linux，Windows) 执行测试用例，提交并跟踪缺陷 - 测试工程师 撰写测试报告 - 测试工程师 测试总结 - 测试管理人员

软件生命周期计划阶段 - 项目经理 - 任务，时间，人员安排需求分析 - 需求工程师/产品经理 - 分析并整理前端收集到的零散需求，并形成文档概要设计 - 架构人员 - 对系统整体框架的设计，确定系统模块，模块与模块之间的关系，编写核心代码，确定系统与子系统的关系详细设计 - 开发人员 - 对模块内部的算法及逻辑结构进行详细设计，包括类，方法，函数，数据库，表等编码 - 开发人员 - 编写代码测试 - 测试团队 - 参见测试流程发布 - 发布负责人 - 程序+数据+文档运维 - 运维人员 - 负责客户或用户使用软件过程中的问题

软件开发模型边做边改模型瀑布模型 - 把生命周期中的各个环节确定下来，但是环节不可逆，测试滞后快速原型模型 - 在需求阶段，通过原型不断和客户沟通需求，最终确定需求，再进行系统的整体设计与开发V模型 - 为每个开发活动对应相关测试活动用户需求                                 验收测试    需求分析                    系统测试        概要设计         集成测试             详细设计 单元测试                        编码W模型 需求分析                   系统实施     测试需求分析                     系统测试    概要设计           系统的集成                测试概设             集成测试         详细设计 模块的集成                          测试详设    单元测试                     编码                                                    编码 增量模型 - 按照功能点开发 每一个增量是一个流程，开发，测试，需求可以并行工作

测试分类 - 按照不同维度分类1、测试阶段划分（按测试执行顺序）：　　● 单元测试（Unit Testing）--UT　　定义：针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的工作；　　测试目的：检测软件模块对《详细设计说明书》的符合程度。　　● 集成测试（Integration Testing）--IT　　定义：在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作；　　测试目的：检测软件模块对《概要设计说明书》的符合程度。　　● 系统测试（System Testing）--ST　　定义：将已经集成好的的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他元素组合在一起，

                 在实际运行（使用）环境下，对计算机系统进行的一系列的测试工作。　　测试目的：与《需求规格说明书》做比较，发现软件与系统需求定义不符合或与之矛盾的地方。　　● 回归测试（Regression Testing）--RT　　定义：软件在测试或其他活动中发现的缺陷经过修改后，进行的测试；　　测试目的：验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能；　　特点：回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试；　　策略：　　①、完全重复测试：重新执行前期建立的所有测试用例，并确认缺陷解决和修改的扩散影响性；　　②、选择性重复测试：　　——覆盖修改法：选择直接影响的用例；　　——周边影响法：选择间接影响的用例；　　——指标达成方法：达到指标的覆盖率等。　　流程：　　1）制定回归测试策略　　2）确定测试的版本　　3）按照回归测试策略执行回归测试　　4）回归测试通过，关闭缺陷跟踪单（问题单）　　5）回归测试不通过，缺陷跟踪单返回开发人员，经开发人员修改后再次进行回归测试　　回归测试自动化：（需考虑的问题如下）　　1）回归测试是一个重复的以前测试的测试，所以自动化是回归测试的追求；　　2）自动化法包括：程序的自动运行、自动配置，用例的管理、自动输入，测试自动执行，测试结果自动采集、比较及结论的自动输出；　　3）对比较稳定的可采用QTP、Robot、SilkTest等工具的“捕捉回放”工具；　　4）为了能实现自动化需要用到脚本语言，如：TCL、Python、Perl等；　　5）对比较复杂的过程，无法借助工具的需要自己开发专用工具；　　6）尽早考虑回归测试的自动化，形成工具化、可继承和推广的。　　●　　其他测试阶段　　○　　α测试：用户在开发环境下进行的测试，评价软件FLURPS　　○　　β测试：多用户在实际使用环境下进行的测试　　○　　验收测试：用户根据合同、《需求规格说明书》或《验收测试计划》对产品进行的验收测试　　注：FLURPS即：功能、局域化、可用性、可靠性、性能、技术支持2、单元测试、集成测试、系统测试的比较：　　●　　测试方法:　　单元测试属于白盒测试范畴；　　集成测试属于灰盒测试范畴；　　系统测试属于黑盒测试范畴；　　●　　考察范围：　　单元测试主要测试内部数据结构、逻辑控制、异常处理等；　　集成测试主要测试模块间的接口与接口数据传递关系，以及模块组合后的整体功能；　　系统测试主要测试整个系统相对于需求的符合度；　　●　　评估基准：　　单元测试主要通过逻辑覆盖率来评估；　　集成测试主要通过接口覆盖率来评估；系统测试主要通过测试用例对需求规格的覆盖率来评估；

　　主要的测试文档：　　●　　测试计划：测试范围、方法、资源，以及相应测试活动的时间进度安排表的文档；　　●　　测试方案：为完成软件集成特性的测试而进行的设计测试方法的细节文档；　　●　　测试用例：为完成一个测试项的测试输入、预期结果、测试执行条件等因素的文档；　　●　　测试规程：执行测试时测试活动序列的文档；　　●　　测试报告：执行测试结果的文档；       ●　　测试日报：每天测试执行情况的记录和总结。3、软件测试过程规范　　首先来看看软件最权威的规范CMM（capability maturity model 能力成熟度模型）关于过程的要素的描述有哪些？　　●　　角色（rolse）：执行者、工作者　　●　　入口准则（entry criteria）：过程执行的前提条件　　●　　输入（input）：过程所需资源　　●　　活动（activities）：过程执行　　●　　输出（output）：过程执行结果　　●　　出口准则（exit criteria）：过程结束的条件　　●　　评审和审核（reviews and audits）：监督活动　　●　　可管理和受控的工作产品（work products managed controlled）：标准性的东西　　●　　测量（measurements）：可以度量的　　●　　书面规程（documented procedures）：计划文档类　　●　　培训（training）：业务培训等　　●　　工具（tools）：过程执行采用的工具　　这些要素已经全面囊括了一个过程的方方面面，如果在软件流程中的每一个过程都按照这样的规范执行，那么软件质量就能得到一定的保证！　　那么作为软件测试工作，在整个软件开发流程中的每一个过程中有哪些工作要做的呢？下面我将分角色、分阶段的来学习。4、系统测试过程　　在这里主要研究软件系统测试过程中的输入和输出，了解我们应该根据什么来做、要做什么以及我们做的先后顺序是怎么安排的过程。　　系统测试计划阶段：　　输入：软件开发计划、软件测试计划、需求规格说明书　　输出：系统测试计划　　系统测试设计阶段：　　输入：需求规格说明书、系统测试计划　　输出：系统测试方案　　系统测试实现阶段：　　输入：需求规格说明书、系统测试计划、系统测试方案　　输出：系统测试用例、系统测试规程、系统测试预测试项　　系统测试执行阶段：　　输入：系统测试计划、系统测试方案、系统测试用例、系统测试预测试项、系统测试规程　　输出：系统预测试报告、系统测试报告、缺陷报告5、集成测试过程　　同样这个过程将研究集成测试过程各个阶段的输入及输出。　　集成测试计划阶段：　　输入：软件测试计划、概要设计说明书　　输出：集成测试计划　　集成测试设计阶段：　　输入：概要设计说明书、集成测试计划　　输出：集成测试方案　　集成测试实现阶段：　　输入：概要设计说明书、集成测试计划、集成测试方案　　输出：集成测试用例、集成测试规程　　集成测试执行阶段：　　输入：集成测试计划、集成测试方案、集成测试用例、集成测试规程　　输出：集成测试报告、缺陷报告6、单元测试过程　　同样这个过程将研究单元测试过程各个阶段的输入及输出。　　单元测试计划阶段：　　输入：详细设计说明书、软件测试计划　　输出：单元测试计划　　单元测试设计阶段：　　输入：详细设计说明书、单元测试计划　　输出：单元测试方案　　单元测试实现阶段：　　输入：详细设计说明书、单元测试计划、单元测试方案　　输出：单元测试用例、单元测试规程　　单元测试执行阶段：　　输入：单元测试计划、单元测试方案、单元测试用例、单元测试规程　　输出：单元测试报告、缺陷报告7、需求分析阶段　　每个阶段有每个阶段的任务，这里将了解需求分析阶段的任务，及其软件项目各工作人员的任务所在。　　需求分析阶段任务：　　●　　需求分析，完成SRS　　●　　软件需求规格说明书的评审：检查遗漏和存在问题　　●　　进行需求跟踪　　●　　系统测试计划　　●　　系统测试计划的评审8、概要设计阶段　　概要设计阶段任务：　　●　　软件系统各层设计，完成HLD　　●　　HLD的评审　　●　　更新需求跟踪　　●　　系统测试方案、用例的设计　　●　　系统测试方案、用例的评审　　●　　集成测试计划　　●　　集成测试计划的评审 9 、详细设计阶段　　详细设计阶段任务：　　●　　软件详细模块的设计，完成LLD　　●　　详细设计的评审　　●　　更新需求跟踪　　●　　集成测试方案、用例的设计　　●　　集成测试方案、用例的评审　　●　　单元测试计划　　●　　单元测试计划的评审10、编码阶段　　编码阶段任务：　　●　　软件编码　　●　　对代码进行静态质量检查　　●　　代码评审　　●　　单元测试方案、用例的设计　　●　　单元测试方案、用例的评审11、测试阶段　　测试阶段的任务：　　●　　系统预测试项执行　　●　　系统预测试报告工作　　●　　执行各阶段测试用例　　●　　各阶段的缺陷记录、修复　　●　　各阶段日志报告　　●　　各阶段缺陷的回归测试　　●　　各阶段测试报告　　●　　测试报告的评审

系统测试的类型：　　　　　　　　功能测试-手工 　　　　　　　　功能测试-自动化 　　　　　　　　性能测试 　　　　　　　　兼容性测试 　　　　　　　　安全测试 　　　　　　　　接口测试 　　　　　　　　健壮性测试 　　　　　　　　安装卸载升级测试 　　　　　　　　文档测试

按照测试技术分： 　　　　　　　　白盒测试 　　　　　　　　灰盒测试 　　　　　　　　黑盒测试

按照是否运行程序： 　　　　　　　　静态测试 　　　　　　　　动态测试

其他测试相关开概念： 　　　　　　　　回归测试 　　　　　　　　冒烟测试 　　　　　　　　国际化测试 - I18N 本地化测试 - L10N 　　　　　　　　随机测试 　　　　　　　　探索性测试

技术： 　　高级测试工程师 　　自动化测试工程师 　　性能测试工程师 　　安全测试工程师 　　接口测试 　　单元测试 　　数据库管理员DBA 　　Linux系统运维 　　开发 　　运维　　管理 　　测试组长、主管、经理 　　测试总监 　　项目经理 　　运维经理 　　质量部经理业务： 　　需求工程师 　　产品经理 　　行业专家（电信，银行，证券，供应链）

一个优秀的测试工程师需要具备的技能素质：专业、性格、逻辑、情感能力：测试基础、标准与规范、测试流程、测试工具、测试方法管理：管人、理事行业经验：业务、测试与行业背景结合越来越紧密英语：外企、国外项目性格：开朗、交流、团队合作、追求完美、怀疑精神、善于说服

==========用例规范==========测试用例的概念：是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

为什么要写测试用例： 　　　　　　　　　　便于可视化管理 　　　　　　　　　　避免测试点的遗漏 　　　　　　　　　　可以提高测试效率 　　　　　　　　　　统一标准 　　　　　　　　　　便于重复测试 　　　　　　　　　　便于团队交流 　　　　　　　　　　便于统计跟踪

测试用例的八要素及其他要素： 用例编号 – Test case no 测试项目/模块 – Project name / Section 用例标题 – Test case name 优先级 - Priority 预置条件 – Pre-condition 输入数据 - data 操作步骤 - Step 预期结果 – Expected result 作者 - author 版本 - version 日期 - data 测试结果 result 通过 - passed 失败 - failed 阻碍 – blocked 未执行 - NA

-----------------P1: 系统的基本功能，case数量应受到控制 15~20% 划分依据：该用例执行失败，会导致多处重要功能不可用；发生概率较高的，经常使用的功能 该类用例需在每一轮版本测试中执行 P2: 系统的重要功能，case数量较多 30~50% 划分依据：各种应用场景，使用频率较高的正常功能。功能交互相关。 在非回归的系统测试版本中都要执行，系统所有的重要功能都必须实现 P3: 系统的一般功能，case数量较多 30~50% 划分依据：使用频率低于P2，比如超长字符串，边界值，事物完整性等 非回归的系统测试版本中不用都进行验证，在系统测试的中后期不一定每个版本都验证 P4：可有可无 10% 划分依据：比较生僻的输入，使用频率非常低得功能 在版本测试中，有某些正常原因，经过和产品经理进行沟通确认可以不执行 -----------------

测试用例的完整写作过程 基于需求规格说明书分析测试需求-》设计测试用例-》写作测试用例-》评审测试用例用例如何评审？当测试工程师完成用例的编写后，先会通知开发与需求，开发和需求可提前查看测试用例，测试工程师会安排评审会议，并发送会议邀请给相关开发，需求，项目经理，测试及开发组长。测试，开发，需求等人员一起开会，测试主导评审会议，并讲解用例写作相关内容，开发，需求及其他人员可以提出建议及相关补充，会议通过后，测试再对用例进行最终整理。

什么样的用例是好的测试用例 从三个维度分析，第一个，用例设计角度，第二个，用例写作角度，第三个，用例维护的角度 对需求的覆盖 对被测试对象设计的了解 对具体的方法的使用 用例写作符合5C原则 正确（correctness）：数据输入 清楚（clarity）：操作步骤 简洁（concision）：标题 完整（completion）：预期结果检查完整 一致性（consistency）：用例编号 用例易于维护

==========缺陷管理==========缺陷的属性：创建者 reporter创建时间 date缺陷版本 version缺陷类型 type缺陷所属的产品/项目/模块 product, project, feature指派给 assign to缺陷编号 no标题 title 缺陷严重程度 serverity缺陷优先级 priority缺陷状态 status 状态： 激活active，已解决fixed, 已关闭closed； 【新建new,正在修改inprogress, 打开open, 重新激活reopened】详细描述 description 系统环境 OS (服务器环境和客户端环境) 测试环境（用户名/密码）test environment 重现率 预置条件 pre condition 步骤 steps 实际结果 actual result 期望结果 expected result 其他信息 additional information用例编号 testcase no*附件 attachment （截图，视频，文件-log日志）==================解决者解决方案：已修复fixed, 重复duplicated, 不能重现cannot reproduced, 无效Invalid(设计如此by design，外部原因external issue), 不修复won't fix, 推迟修改postpone)

缺陷引发的原因 root cause代码改动范围影响范围解决日期==================验证人验证环境验证范围结果---------缺陷的等级划分：紧急 - 导致系统运行中断，程序崩溃，核心业务未完成，测试工作无法进行，核心金额计算错误严重 - 主要流程无法进行，功能与需求不符，轻微的金额计算错误一般 - 次要功能出错，提示信息不符，体验差，微小 - 很细小的问题，几乎对功能没有影响需要增强的功能Enhancement - 需要增强的功能界面（UI）bug：有可能是比较严重的问题，也有可能是比较微小的问题--------------缺陷管理流程中的几个角色开发测试开发组长测试组长

缺陷处理流程/缺陷的生命周期测试人员在执行测试用例的过程中发现bug，将其上报到缺陷管理系统，并指派给开发，开发初步判断缺陷，如果是缺陷并需要修复的，开发修改代码后将代码提交到服务器上，并将bug解决为 已解决，同时回指给测试。测试环境通过最新代码更新后，测试人员验证bug，如果确定已经修复，测试关闭bug；否则，测试重新激活bug。如果开发认为缺陷是重复缺陷，开发会将缺陷解决为重复缺陷，并回指给测试，测试要确定是否确实重复，如果是，测试关闭bug，否则，测试重新 激活 bug。如果在开发环境不能重现bug，开发会将缺陷解决为 不能重现，并回指给测试，测试要确定是否确实不能重现，如果是，测试关闭bug，否则，测试重新 激活 bug。如果开发认为是无效bug，开发会将缺陷解决为 无效【外部原因，设计如此】，并回指给测试，测试要确定是否确实无效，如果是，测试关闭bug，否则，测试重新 激活 bug。如果开发认为缺陷不需要修复，开发会召集产品经理，开发组长，测试人员及测试组长一起讨论，如果大家一致同意该缺陷不需要修复，开发会将缺陷解决为 不予修复，并回指给测试，测试关闭bug。如果讨论之后确定该缺陷需要修复，开发会修改缺陷如果缺陷需要推迟到下一个版本修改，在产品经理，项目经理及其他相关人员同意之后，开发可以将缺陷解决为推迟修改，并回指给测试。

--------------------XAMPP部署禅道系统 Windows+Apache+Mysql+PHP

XAMPP是一个集成工具，具体安装过程如下：1、下载 xampp安装包到自己的电脑，解压后双击进入到安装界面，所有步骤均默认安装2、安装完成后，打开xampp，打开方式：XAMPP -> XAMPP Control Panel， 此时会打开xampp的面板。3、修改Apache的端口号80，修改方法为：XAMPP面板上面点击Apache后面的Config按钮，在显示出来的菜单中点击 Apache(httpd.conf)， 此时会打开httpd.conf文件，找到 Listen 80，将80改为8008之后的端口，如8008，修改之后保存该文件并退出。点击Apache后面的Config按钮， 在显示出来的菜单中点击 Apache(httpd-ssl.conf)，打开该文件，找到 Listen 443，将443改为其他端口，如4437，修改之后保存该文件并退出。4、启动Apache，启动的方法：点击 Apache后面的 Start 按钮，如果启动成功，则变为 Stop，如果启动时报ports之类的错误信息， 则表明第3步所修改的两个端口号可能被占用，需要重新修改端口号。5、启动Mysql数据库，启动的方法：点击 Mysql 后面的 Start 按钮，启动之后，则变为 Stop， Mysql的默认端口号为3306，不需要修改。6、将禅道的代码布署在环境当中，过程如下，拷贝 禅道安装包到本机的C:\xampp\htdocs，拷贝完成后在该压缩文件上面点击右键，选择解压到当前文件夹， 解压完成之后会生成一个新的文件夹，名称为 zentaopms。7、安装禅道环境：在浏览器中输入 http://localhost:端口号/zentaopms/www/，进入安装禅道界面，点击 开始安装 按钮，进入授权界面，点击下一步按钮， 进入系统检查界面，全部为通过时，点击 下一步 按钮，进入生成配置文件界面， 默认语言选择 简体，数据库服务器内输入数据库所在电脑的IP地址 【如果数据库服务器在本机，输入 127.0.0.1或localhost】,服务器的端口为 数据库服务的端口，默认为3306，数据库的用户名默认为 root 【root用户为mysql数据库最高权限的管理员用户】，数据库的密码默认为空【安装完mysql之后，如果没有设置 root用户的密码，则其密码默认为空】， PMS使用的库为正在安装的禅道系统的数据库名称，建表前使用的前缀 默认即可，不需要勾选择 清空现有数据 ，点击保存，进入保存配置文件页面， 点击下一步按钮，进入设置帐号界面，输入公司名称，管理员帐号及密码【注意：此处需要牢记管理员帐号与密码】，不需要勾选择 导入demo数据， 点击保存按钮。进入安装成功界面，点击 登录禅道管理系统 按钮，进入禅道系统的登录界面，输入用户名与密码之后即可登录。

==========敏捷开发==========敏捷体现的是一个字：快 - 在比较短的时期内发布可工作的软件产品Scrum流程：客户/市场/高层 提出一些创意/新功能/缺陷，由产品负责人[产品经理]对其进行整理成产品功能列表[产品需求清单]【产品需求清单中的每一个功能点，也称之为需求点或故事-story】，产品负责人从产品需求清单中挑选出一个版本(迭代)需要完成的功能点，交由开发团队，此时，开发团队和产品负责人一起开迭代计划会，确定一个迭代的详细计划，并对开发任务进行分解及分配，当完成计划会后，开发人员分别按照计划开发各自负责的任务，当所有任务完成之后，团队内部会进行 迭代评审会议，

会议的内容为该迭代是否能够正常发布，如能发布，则在发布之后，团队进行 回顾会议。

三大角色： 产品负责人/产品经理：需求+相关管理工作 流程管理员/项目经理：大多数情况下由项目经理或开发组长承担 开发团队：开发+测试

其他概念： 版本：与传统开发模式的版本类似 迭代- sprint：有可能一个版本有一个迭代，有可能一个版本有多个迭代 故事-story：需要开发的功能点 任务看板：将未开始的任务，已开始的任务及已完成的任务分类汇总 燃烬图- burn down chart：以任务和时间为Y与X轴，绘制每天的任务完成情况，形成具体的图形。五大会议： 迭代规划会议 每日站立会议 演示会议：产品经理演示需求的原型，开发人员演示功能点，所有开发的功能完成后的整体功能演示。 评审会议 回顾会议

里程碑 - mile stone基线 - base line最后期限 - dead line

==========软件质量==========质量的定义：实体的特性对需求的满足程度

软件质量的三个层次： 符合需求规格 符合用户显式需求 符合用户实际需求【显式需求+隐式需求】

影响软件质量的三大因素[软件质量的铁三角] 技术 流程 组织 问题：你是如何确保你所负责的功能模块的质量的? 你们项目组是如何确保所测项目的质量的?

三大质量管理体系 ISO9000：八项质量管理原则 【以顾客为中心，以顾客的需求为导向】 CMM/CMMI：Capability Muturity Model/ Integration - 能力成熟度模型 初始级 可重复级 已定义级 已管理级 优化级 CMM与CMMI的区别： 表达方式：CMM阶段式，CMMI可阶段，可连续 关键过程域不同：第三级的关键过程域 六西格玛：起源于制造业-摩托罗拉 核心：百万样本3.4个缺陷

软件质量模型：内部质量与外部质量 - 六大特性，二十七大子特性