测试学习笔记

一，测试用例

测试用例是什么

为特定目的而设计的一组测试输入、执行条件和预期结果
内容
测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等
是软件测试执行的最小实体

高质量测试用例特点

准确性
完整性
涵盖功能、性能等
清晰、简洁
可重用性
可维护性
根据需求更新、增加、删除

测试用例设计方法

等价类划分，边界值，因果图，场景法，错误猜测法

需求

分类

需求挖掘

需求挖掘的过程
是将软件需求中的那些具有可测试性的需求或特性提取出来，形成原始测试需求
需求挖掘的方法
通过列表的形式对软件需求进行梳理，形成原始测试需求列表

需求分析过程

1.对每条需求进行细化分解，形成可测试的分层描述的测试要点
原始测试需求列表→分层为
功能点
测试要点
测试点
覆盖全部业务流程
挖掘隐含需求
2.对形成的每一条测试要点，从软件产品的质量需求来分析，确定测试执行时需要实施的测试类型

需求评审

1.完整性检查
应保证测试需求能充分覆盖软件需求的各种特征
重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面
还应关注是否覆盖开发人员遗漏的、系统隐含的需求
2.准确性检查
应保证所描述的内容能够得到相关各方的一致理解
各项测试需求之间没有矛盾和冲突
各项测试需求在详尽程度上保持一致
每一项测试需求都可以作为测试用例设计的依据

用例设计

测试用例设计原则

1. 基于测试需求
2. 基于测试方法（不同的测试方法）
3. 兼顾测试充分性和效率
4. 测试用例的代表性
5. 测试结果的可判定性
6. 测试执行的可再现性
7. 一个测试用例对应一个功能点
8. 测试用例易读
9. 步骤清晰
10. 结果明确
11. 尽量将具有相类似功能的测试用例抽象并归类

测试用例编写要素

测试用例的管理载体

Word文档

Excel文档

Testlink管理软件

禅道管理软件

测试用例分级

重要性
第一级：基本
系统基本功能，该用例执行的失败会导致多处重要功能无法运行的
第二级：重要
系统的重要功能，主要包括一些功能交互相关、各种应用场景、使用频率较高的用例
第三级：一般
系统的一般功能，使用频率低于2级用例
第四级：生僻
对应较生僻的预置条件和数据设置的用例

测试用例评审

1.定义
通过需求的分析讲解，明确测试用例的业务逻辑是否正确
分析软件需求规格评审测试用例是否与规格一致
开发方面会针对测试用例的步骤判断设计的合理性
2.原因
测试用例是软件测试的准则，但并不是开发完成就能成为3.准则
由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异
4.步骤
在用例的初步设计完成之后进行评审
在整个详细用例全部完成之后进行二次评审

测试用例更新完善

软件产品功能新增或更新需求
测试执行过程中，测试用例考虑不周
软件交付后，客户反馈缺陷
软件上线后，测试人员自己发现的缺陷
维护阶段，其他人员反馈的缺陷

用例设计方法

等价类划分

1.等价类划分就是把所有可能的输入数据，即程序的输入域划分成若干部分
2.从每一部分中选取少数有代表性的数据做为测试用例
代表性数据等同于该类中的其他值
3.分类
有效等价类
合理的、有意义的输入数据构成的集合
无效等价类
不合理的、无意义的输入数据构成的集合
作用域
输入数据
输出数据
4.等价类划分方法
按区间划分
按数值划分
按数值集合划分
按限制条件或规划划分
按处理方式划分
5.原则

 1. 输入条件的取值范围，可以划分出一个有效等价类和两个无效等价类
 2. 如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类
 3. 如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类
 4. 如果规定了输入数据的一组值(假设N个)，而且程序要对每个输入值分别进行处理
	每个允许的输入值是一个有效等价类
			即N个有效的
	这组值确立一个无效等价类
			所有不允许的输入值的集合
5.如果规定了输入数据必须遵守的规则
	一个有效等价类（符合规则）
	若干个无效等价类（从不同角度违反规则）
6.在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类

6.测试用例

1.为每个等价类规定一个唯一的编号
2.设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类
3.重复这一步，最后使得所有有效等价类均被测试用例所覆盖
4.设计一个新的测试用例，使其只覆盖一个无效等价类
重复这一步使所有无效等价类均被覆盖

边界值分析

1.经验
大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部
针对各种边界情况设计测试用例，可以查出更多的错误
2.含义
1.对输入或输出的边界值进行测试的一种黑盒测试方法
2.测试数据选取原则
正好等于边界的值
刚刚大于边界的值
刚刚小于边界的值
3.原则
1.如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围的边界值作为测试的输入数据
2.如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据
3.根据规格说明的每个输出条件，使用原则一
4.如果程序的规格说明给出的输入域或输出域是有序集合
应选取集合的第一个元素和最后一个元素作为测试用例
5.分析规格说明
找出其他可能的边界条件

因果图

• 一.适用范围
  适合于不同条件组合对应不同的结果状态
  根据条件不同组合的情况输出不同的测试用例
  二.产生背景
  等价类法、边界值法分析着重考虑输入条件，未考虑输入条件之间的关系
  三.步骤

• 1.分析软件规格说明找到哪些是原因，哪些是结果
  1.原因:
  输入或输入条件的等价类
  2.结果:
  输出条件
  3.给每个原因和结果赋予一个标识符，根据这些关系，画出因果图

• 2.因果图上用一些记号表明约束条件或限制条件

• 3.对需求加以分析并把它们表示为因果图之间的关系图

• 4.把因果图转换成判定表

• 5.将判定表的每一列作为依据，设计测试用例 因果图标识

四.原因和结果之间的关系

1. 恒
   等若C1是1，则E1也是1；否则E1为0
2. 非
   若C1是1，则E1是0；否则E1是1
3. 或
   若C1或C2是1，则E1是1；否E1为0，“或”可有任意个输入
4. 与
   若C1和C2都是1，则E1为1；否则E1为0, “与”也可有任意个输入
5. 输入条件的约束类型

1.E约束（互斥/异）
a和b中至多有一个可能为1
2.I约束（或）
a、b和c中至少有一个必须是1
3.O约束（唯一）
a和b必须有一个，且仅有1个为1
4.R约束（要求）
a是1时，b必须是1

用例

1.需求说明

“货币转换程序”作为案例，假定系统需求如下
输入需要转换的货币类型：只容许输入美元和日元
输入需要转换的人民币金额：必须是数字
如果输入正确，显示对应外币金额
如果输入货币类型错误，提示“输入货币类型错误”
如果输入需要转换的人民币金额错误，提示“人民币金额输入错误”

2.分析确定原因（输入）和结果（输出）

2.1.原因两个

c1，输入货币类型正确，可以对c1进行细分：

c11，输入美元正确
c12，输入日元正确

c2，输入人民币金额正确（数字）

2.2.结果三个

e1，显示对应外币金额
e2，提示“输入货币类型错误”
e3，提示“人民币金额输入错误”
3.确定逻辑关系

货币类型正确（c1），人民币金额正确（c2），逻辑与的结果是显示对应外币金额（e1）
货币类型不正确（c1），逻辑非的结果提示“输入货币类型错误”（e2）
人民币金额不正确（c2），逻辑非的结果提示“人民币金额输入错误”（e3）
货币类型正确（c1）是由输入美元正确（c11）和输入日元正确（c12）逻辑或构成的

4.确定约束关系

1.原因c11和c12不可能同时为真，但可以同时为假，因此满足E约束
2.这三个结果之间没有M约束

场景法

1.概念
软件用事件触发来控制流程

事件触发时的情景便形成了场景
同一事件不同的触发顺序和处理结果就形成事件流

场景法就是通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法

2.原理

基本流：

1.采用直黑线表示，是经过用例的最简单的路径
2.程序无差错的从开始直接执行到结束

备选流：

1.采用不同颜色表示
2.一个备选流可以从基本流开始，在某个特定条件下执行，然后重新加入基本流中
3.也可以起源于另一个备选流，或终止用例，不在加入到基本流中

3.步骤

1.根据说明描述出程序的基本流及各项备选流
2.根据基本流和各项备选流生成不同的场景
3.对每一个场景生成相应的测试用例
4.对生成的所有测试用例重新复审：

去掉多余的测试用例

测试用例确定后，对每一个测试用例确定测试数据值

4.用例

在线购物系统作为案例，系统需求如下

用户进入在线购物网站进行购物，选购物品后，如果想购买，需要使用帐号登录
登录成功后，进行付钱交易
交易成功后，生成订购单，完成整个购物过程

根据基本流和备选流来确定场景

设计用例

猜错法

猜错法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法

猜错法的基本思想

列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例

1.常用猜错法用例参考

数字输入验证
分别输入数字(正数、负数、零值、单精度、双精度)、字符串、空白值、空值、临界数值

日期、时间输入验证
分别输入任意字符、任意数字、非日期格式的数据、非正确日期(错误的闰年日期)、空值、空白值

重复提交表单
一条已经成功提交的记录，在浏览器中回退后再提交，看系统是否做了处理

登录名输入
注意登录名是否区分大小写和空格

软件缺陷

存在于计算机程序中的错误、失效，或者由于程序中的故障令计算机无法正常工作或产生不正确的结果
1.如何识别缺陷

• 软件未实现产品说明书要求的功能
• 软件出现了产品说明书指明不应该出现的错误
• 软件实现了产品说明书未提到的功能
• 软件难以理解、不易使用、运行缓慢或者从用户的角度体验不好
  2.原因

1.沟通不够
2.程序设计错误
3.软件的复杂性
4.工期短，任务重
5.软件与系统软硬件支持不匹配
6.需求分析不到位
7.需求变动后没有及时沟通
8.研发后期还有新的需求

工作中的软件缺陷

大部分客户不懂软件开发技术

• 提出的需求不明确
• 提出的需求本身是矛盾的

软件产品制造商无法100%收集到用户需求

在软件需求调研和设计阶段存在的各种问题会导致用户需求被错误地理解和传递

随着工作或使用环境的变化以及时间的推移，用户需求也会随之改变

软件技术的发展落后于不断复杂的用户需求

3.常见场景
1.功能未实现或与规格说明不一致
2.不能工作（死机、无响应）
3.边界条件未处理
4.界面、消息、提示、帮助不够准确
5.屏幕显示、打印结果不正确
6.软件有尚未完成的功能
7.与其他软、硬件的不兼容

4.属性

1.缺陷标识(Identifier)
标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识
2.缺陷类型(Type)
根据缺陷的自然属性划分的缺陷种类
3.缺陷严重程度(Severity)
指因缺陷引起的失效对软件产品的影响程度
4.缺陷优先级(Priority)
指缺陷必须被修复的紧急程度
5.缺陷状态(Status)
指缺陷通过一个跟踪修复过程的进展情况
6.缺陷起源(Origin)
指缺陷第一次被检测到的阶段

缺陷类型(Type)

1.代码错误
需求中的功能没有在系统中实现
2.系统错误
存在或产生于所开发的系统之外的软硬件错误
3.需求变更
由设计和需求变动引起的问题
4.界面优化
排版不整齐，不美观，相同或相近功能风格不统一等
5.其他
测试人员误操作却认为发现了问题

严重程度(Severity)

1.Critical（致命） 主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用如：1. 系统崩溃；2.功能设计与需求严重不符；3.系统无法登录

2.Major（严重） 影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误

3.Minor（一般） 界面、性能缺陷如：1.边界条件下错误；2.容错性不好；3.大数据测试容易无响应；4.大数据操作时，没有提供进度条

4.Cosmetic(建议) 易用性及建议性问题
如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范

优先级(Priority)

1.严重性越高，优先级越高，但并非绝对
2.严重性高，优先级低
比如出现时非常严重，但出现的概率非常低

3.严重性低，优先级高
比如影响产品或公司形象的界面错误、公司名称、公司Logo这类缺陷必须立即修改

报告缺陷的基本原则

1.尽快报告缺陷
2.有效描述缺陷

2.1短小
只解释事实和演示、描述缺陷必需的细节

2.2单一
每一个报告中针对一个缺陷

2.3步骤清晰
要清楚地描述出缺陷的发生场景，包括前置条件和操作的详细步骤

2.4使用IT业界惯用的表达术语和表达方式

2.5明确指明错误类型

3.报告缺陷时客观陈述，不做任何评价
4.确保缺陷可以重现

缺陷报告撰写标准

1.缺陷报告遵守“5C”准则

1.简明扼要的缺陷标题
2.精确的问题描述
3.优秀重现步骤的特点

3.1步骤精简，没有冗余
3.2其他工程师可以稳定的复现所描述的缺陷
3.3每一步骤只描述一个操作
3.4使用客观语言描述操作步骤和客观事实，避免使用带有主观色彩的文字

完整的缺陷报告

1.简单描述
用一句话简单的描述问题

2.详细描述
2.1.描述问题的基本环境
2.2使用最少步骤去重现测试工程师的操作步骤和使用的数据
2.3测试工程师根据上述信息可以给出对问题的简单分析
2.4被测试软件版本
2.5状态、严重级别、优先级别
2.6提交日期、提交人
3.相关附件
3.1如果从图形界面上反映出软件的异常，最好采用截屏的方式
3.2被测软件运行时的相关日志文件

发现缺陷的方法

1.检查系统日志（log），看有没有异常出现
2.检查数据库配置、网络、硬件配置是否与开发环境有差异
3.状态缺陷是否仅在特定软件状态中显露
4.检查被测对象的版本信息，确认测试的版本是否是正式的软件测试版本
5,借助于其他工具，如使用fiddler工具去分析

缺陷的常用管理工具

缺陷管理工具mantis安装使用教程

1.Mantis主要功能

1.多项目管理
2.问题录入
3.问题更新
4.Bug状态跟踪
5.统计分析、报表生成和输出
6.用户管理

安装教程

2. 用户权限

3.项目管理

1.创建项目
填写项目信息，点击‘添加项目’保存
查看权限两个选项“公共”和“私有”。一旦选择私有，则别的项目组成员是无法看到的
2.项目编辑
点击项目名称，打开项目编辑页面，可以更改项目的基本信息、管理项目的分类、版本、用户等
3.添加用户至项目

1. 点击要添加至项目的用户
2. 选择该用户在项目中的权限
3. 点击‘添加用户’完成操作
   子项目
   可以按照功能将某些模块单独出来，但是又不脱离该项目，便于统计分析

版本
开发过程中会历经多个内部版本，便于缺陷报告的统计

4.缺陷管理流程

1.报告员提交缺陷

1. 分类：创建项目时配置的分类
2. 出现频率：总是、有时、随机、没有试验、无法重现
3. 严重性：新功能、小错误、严重、崩溃、宕机
4. 优先级：无、低、中、高、紧急、非常紧急

2.经理确认缺陷并指派给开发员
6. 使用经理账号登录
7. 点开问题详情页，选择要分派的开发人员，点击‘分派给’，

3.开发人员修正缺陷并指派给报告员

4.报告员验证缺陷

1.验证通过
关闭该缺陷

2.验证不通过
重启该缺陷

TestLink的使用

1.简介

一款开源的测试管理工具
1.主要用于进行测试过程的管理
2.可以将测试过程从测试需求、测试设计、到测试执行完整的管理起来
3.提供了多种测试结果的统计和分析

2.主要功能

1.测试计划的管理
2.测试需求管理
3.测试用例的管理
4.测试执行
5.测试结果的分析
6.基于角色的用户管理

优点

1.支持多个项目
2.易于导出导入测试用例
3.易于与多种缺陷管理工具集成
4.可使用版本、关键字和测试用例ID进行筛选
5.易于向多个用户分配测试用例
6.易于生成各种格式的测试计划和测试报告
7.可向多个用户提供凭据并向其分配角色

测试管理流程

用户角色
Guest
浏览测试规范、关键词、测试结果，编辑个人信息
Tester
浏览测试规范、关键词、测试结果，编辑测试执行结果
Test Designer
编辑测试规范、关键词和需求规约
Senior Tester
编辑测试规范、关键词、需求，测试执行和创建发布
Leader
编辑测试规范、关键词、需求、测试执行、测试计划
Admin
一切权力，包括用户管理

1.初始设置

1.登录页面
用户是安装时设置的用户名、密码

2.创建用户
填写账号的具体信息，选择用户权限，点击‘保存’即可成功添加用户
3.创建项目
填写项目相关信息，点击‘保存’

2.需求管理

1.创建测试需求
点击【产品需求】【新建产品需求规格】打开‘创建产品需求规格’页面

2.创建测试用例集
填写测试用例集相关信息：
名称、描述、关键字等
点击‘保存’，创建用例集成功

3.创建测试用例
点击创建好的测试用例集，新建测试用例，填写测试用例的标题、描述、前提，创建测试步骤即可编写测试用例

4.创建测试计划
填写项目的测试计划名称、描述，点击"创建"

5.创建测试版本
填写测试版本的标识、说明、发布日期，点击‘创建’

6.添加测试用例到测试计划
选择已经设计完成的测试用例，点击‘增加选择的测试用例’，将测试用例添加到测试计划中

7.指派测试用例执行人
在指派给列选择要执行测试用例的人员，点击‘Save Assignments’

8.指派用户角色
点击【用户管理】【指派测试计划的角色】可以调整用户在测试计划中的权限

9.设置测试结果
点击【测试执行】选择相应的测试计划和版本，点击要执行的测试用例，打开测试用例执行页面，填写测试结果，设置测试状态

禅道

1.专业的项目管理软件
2.基于敏捷项目管理方法Scrum

3.主要功能
3.1产品管理
产品、需求、计划、发布、路线图

3.2质量管理
Bug管理、测试用例、测试任务、测试结果

3.3文档管理
产品文档库、项目文档库、自定义文档库

禅道项目管理流程图

1.产品经理创建产品
2.产品经理创建需求
3.项目经理创建项目
4.项目经理确定项目要做的需求
5.项目经理分解任务，指派到人。
6.测试人员测试，提交bug。

软件项目管理

1.什么是项目

1.权威版本
在既定的资源和要求的约束下，为实现某种目的而相互联系的一次性工作任务

2.通俗版本
一些人在规定的时间里面完成一些事情

敏捷开发

1.敏捷开发(Agile Development)——一种以人为核心、迭代、循序渐进的开发方法
2.常见敏捷方法论
2.1.Scrum
2.2.极限编程（XP）、MSF、OpenUP(RUP敏捷版)、水晶方法、精益开发…

产品

1.将庞杂混乱的产品细分成若干小型发布
2.release offen，release early
3.完成比完美更重要

团队

1.精简金字塔式管理，实现自我管理团队

1.1.过分强调控制，势必会产生各种各样的流程
1.2.完全没有控制，就放羊了
1.3.放而不乱

2.借助群体的力量提升个体的技能和效率

周期

1.通过小步快跑的方式，建立产品、研发、客户、市场的节奏
2.时间片管理
3.节奏可以产生效率
4.节奏可以带来预期
5.节奏可以带来信任
6.节奏可以带来创新

过程

1.持续改进研发过程和实践
2.定期总结和反馈，每一轮迭代都改进一点
3.持续的改进软件的架构，找到最佳解决方案
4.简洁实现
5.事情做得很复杂很容易，但做得很简单很难

客户

1.和客户沟通合作

• 有谈判，更要有合作
• 面对面改成背靠背
• 挖掘客户真正的需求
• 现场客户
• 客户的反馈是调整前进路线的最佳指导

分之而后治之

1.将复杂的产品分解为细致的用户故事
2.将复杂的团队分解为多个的敏捷团队
3.将长期的研发过程分解为多个短期的冲刺
4.将复杂的程序分解为的对象，方法，用例
5.分之而后明之，明之而后有序，有序则治也

软件配置管理

1.又称软件形态管理或软件构建管理

2.工作内容
2.1版本控制（VersionControl）
2.2变更控制（ChangeControl）
2.3过程支持（ProcessSupport）

3常用的工具
SVN、VSS

配置管理的意义

1.及时了解团队中其他成员的进度
2.轻松比较不同版本间的细微差别
3.记录每个文件的修改日志
4.资料共享，避免以往靠拷贝文件造成的版本混乱
5.所有成员维护同一个版本库，无需专人维护所有文件的最新版本

VSS与SVN比较

VSS悲观锁（串行）
1.有人在编辑相关文件时，此文件处于锁定状态，其他人如果想编辑这个文件只能处于等待状态
2.模式：锁定编辑解锁

SVN乐观锁（并行）
1.多个人可以同时签出一个文件，编辑然后提交，如果多人都修改了同一文件的某一行的话，就会发生冲突需要手工解决冲突
2.模式：修改冲突合并

SVN

简介

1.全称Subversion，是开源的项目版本管理软件
2.组成
服务端
客户端

3.多用户管理

用户、用户组管理
为用户分配权限（读、写）

作用

1.管理随时间改变的数据和文档
2.数据和文档放置在一个中央资料档案库中，档案库像一个普通的文件服务器，不过会记住每一次文件的变动
3.可以把档案恢复到旧的版本，或是浏览文件的变动历史
4.档案库可以通过网络进行访问

工作流程

集中式管理
核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突、提交。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的。

配置库

1.SVN的核心是配置库，储存所有的数据
2.配置库按照文件树形式储存数据——包括文件和目录
3.任意数量的客户端可以连接到配置库，读写这些文件
4.通过写数据，别人可以看到这些信息
5.通过读数据，可以看到别人的修改
6.记录配置库中的每一次更改，不仅针对文件也包括目录本身，包括增加、删除和重新组织文件和目录

工作副本

1.工作副本（WorkSpace）

1.1.每个项目组成员工作的地方
1.2.项目组成员从配置库拿到源文件，放在本地作为工作副本

1.2.1.在工作副本上进行查看、修改、编译、运行、测试等操作，并把新版本的文件从这里提交回配置库库中

SVN服务端简介

1.版本库（Repositories）
是一个仓库，可以存储多个项目

2.用户（Users）
可以指派负责管理哪个项目

3.用户组（Groups）
1.可以把用户组织成一个小组
2.可以指派该组负责哪些项目

创建用户

1.在Users处右键->Create User…
2.新建用户

2.1.用户名
2.2.密码
2.3.确认密码

创建用户组

1.在Groups处右键->Create Group…
2.新建用户组

2.1.用户组名
2.2.选择用户

创建版本库

1.在Repositories右键->Create New Repository…
2.创建新版本

2.1.输入项目名称
2.2.选择版本结构
2.3.选择合适的权限

Checkout(检出)

1.将版本库中的内容检出到本地工作副本
2.步骤

2.1新建空文件夹，如D:\working
2.2在目录中点击右键->SVN Checkout…

3.注意事项
1.检出深度

1.1.全递归（默认选择）
检出完整的目录树，包含所有的文件或子目录

1.2直接节点，包含目录
检出目录，包含其中的文件或子目录，但是不递归展开子目录

1.3仅文件子节点
检出指定目录，包含所有文件，但是不检出任何子目录

1.4仅此项
只检出目录

Update（更新）

1.更新工作副本，获取其他用户对文件进行的修改，使工作副本与版本库中的最新版本保持一致
2.SVN将显示出更新的文件和更新的次数，修改本地文件前，需先进行更新

3.操作
3.1选择要更新的文件目录->右键-> SVN Update

Add（增加）

1.将新增的文件添加到版本库
2.操作

2.1选中本地新建文件->右键->TortoiseSVN->Add
2.2执行Add操作后，文件图标变成’’
所示，然后下面步骤二选一
2.21.Undo add（取消添加）来选择取消添加文件
2.23Commit（提交）来上传文件

Commit（提交）

1.将对工作副本的修改发送给版本库Repository
2.操作

1.本地副本选择文件或文件夹->右键->TortoiseSVN -> Get lock（获得锁定），编辑文件
2.选择文件或文件夹->右键->TortoiseSVN->SVN Commit（提交文件）
3.本地副本选择文件或文件夹->右键->
TortoiseSVN->Release lock（解锁）

Update to revision（更新至特定版本）

1.修改当前文件版本到某一历史版本
2.操作

本地副本选择文件或文件夹->右键->TortoiseSVN -> Update to revision…

测试计划

项目管理简介

1.项目管理概念

1.1指在项目活动中运用专门的知识、技能、工具和方法
1.2使项目能够实现或超过项目干系人的需要和期望

软件测试计划概念

1.测试计划概念

1.描述要进行测试活动的范围、方法、资源和进度的文档
2.测试计划<>测试计划文档

软件测试计划准备工作

人力准备、环境搭建、工具选择,执行测试的必备条件：参考文档、测试测试确定等。

软件测试计划作用

1.内部作用

1.1作为测试计划的结果，让相关人员和开发人员来评审
1.2存储计划执行的细节，让测试人员进行同行评审
1.3存储计划进度表、测试环境等信息

2.外部作用
2.1.为客户提供一种信心
交代有关测试过程、人员的技能、资源、使用的工具等

软件测试计划目的

1.为各项活动制定一个现实可行的、综合的计划
1.1每项测试活动的对象、范围、方法、进度和预期结果

2.为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容

2.1开发有效的测试模型，能正确地验证正在开发的软件系统
3.确定测试所需要的时间和资源
3.1保证其可获得性、有效性

4.确立每个测试阶段测试完成以及测试成功的标准、要实现的目标
5.识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失

软件测试计划要素

1.why
2.what
3.when
4.where
5.who
6.how

软件测试计划——简介

1.简介
1.1 测试目的
1.2 背景
1.3 适用范围
1.4 产品流程图
2.文档
2.1 参考文档
2.2 提交文档
3.测试进度
表格形式
4.测试资源
4.1 人力资源
4.2 测试环境
4.3 测试工具
5.系统风险和优先级
5.1 系统风险
5.2 优先级
6.测试策略
6.1 功能测试
6.2 界面测试
6.3 兼容性测试
6.4 安装/卸载测试

风险频率

罕见：一些静态页面。即使页面的HTML或脚本发生崩溃，也很容易发现和恢复
少见：例如Chrome上的Forward按钮。这个按钮使用的频率远远小于Back按钮。从历史记录看，它很少出现问题，即使发生了，也能比较早的发现，因为是一个相当明显得问题
偶尔：
如chrome的Sync功能。Chrome会在不同客户端之间同步书签、主题、表单填写、历史和其他用户资料数据，涉及不同的数据类型及多个操作平台，而且变更合并是是一个复杂的计算问题，该功能也是用户提交关注的，特别是数据变化时。

常见：页面渲染。页面渲染各种HTML、CSS和Javascript代码等，特别是一个高流量的网站，发生问题的风险较大。经常会出现的页面元素不能完全对齐，或者某些元素没有显示出来

软件测试计划注意事项

1.认识测试项目不止一个测试计划
1.1单元测试计划
1.2集成测试计划
1.3系统测试计划

2.避免不分析直接进行测试阶段日程安排
3.避免测试任务的安排超前于开发任务
4.避免有些系统测试类型无法按期进入测试

1.不正确的变更测试计划
2.测试计划里明确更新周期和暂停测试原则
3.测试计划不是一成不变的

测试总结报告

测试总结报告概述

1.软件测试人员对整个系统测试工作进行总结
2.测试领导了解被测试产品的质量情况
3.软件开发经理了解项目过程中的问题
4.对外发布产品的重要参考依据

测试总结报告分类

1.按照测试里程碑

1.1单元测试总结报告、集成测试总结报告、系统测试总结报告

2.按照测试类型
2.1功能测试总结报告、性能测试总结报告、安全性测试总结报告

3.按照工作周期
3.1测试日报、测试周报、测试完成确认报告

软件测试总结报告内容

测试总结报告——简介

1.简介
1.1 编写目的
1.2 参考资料
1.3 术语定义

2.测试背景
2.1 项目背景
2.2 测试环境

3.测试计划进度执行情况
3.1 测试人员安排情况
3.2 测试时间
3.3 测试版本信息

4.测试执行阶段情况报告
4.1 测试用例分布情况
4.2 测试用例执行情况

5.缺陷的统计与分析
5.1 测试结果汇总
5.2 测试缺陷状态分析
5.3 测试结果分析
5.4 重要缺陷摘要
5.5 残留与未解决问题

6.测试结论和建议
6.1 测试结论
6.2 建议

测试结果及缺陷分析

1.测试需求覆盖情况
需求功能项、功能项的用例数量、用例覆盖的情况

2.测试过程统计
1.每轮未处理的缺陷个数统计
2.每轮新提交的缺陷个数统计

3.测试结果统计
1.按照缺陷的严重性
2.按照缺陷所属的功能模块
3,按照开发人员的回复意见

测试报告的注意事项

1.两个核心内容

1.1.评估测试的覆盖率
1.2.基于软件缺陷的质量评估

2.内容简介
2.1说话抓重点、不说废话，简单易懂
2.2能用图形、表格的尽量用图形、表格来展示

3.分析结果要清晰明显