【笔记】软件测试01——基础

一、发展阶段

 

二、软件测试

一）软件测试的定义

        软件测试是使用人工或自动的手段来测试某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差距。

eg：

拿手机打游戏

不是测试，没有检验是否满足需求，没有了解其需求；没有刻意去弄清预期结果与实际结果的差距。

把一个app应用安装到手机上以后再卸载   ——不是测试

一个不知道再怎么用的软件上随便点点点，看看会不会出现什么问题

不是测试，未知需求

找个类似于按摩精灵 的工具录制操作步骤，自动化地帮我抢红包

不是测试，没有弄清预期结果于实际结果之间的差距。没有比较的自动化，是自动化操作而不是自动化测试。

二）软件测试的特点

三）软件生命周期

MCP：Minmal Concept Principie(最小概念原则)

软件生命周期：

1. 计划
2. 需求分析
3. 设计
4. 编码：根据概要说明书及详细设计说明书编写程序代码
5. 测试：

• 单元测试：对程序的最小单元进行测试的过程，最小单元指函数或者是一个类的代码
• 集成测试：对模块与模块之间调用的接口进行的测试叫集成测试
• 系统测试：对完成编译的系统整体进行测试的过程。
• 验收测试：交付给客户或者最终用户时，和客户一起完成的测试。

1. 运行和维护

四）软件测试模型

模型：将比较抽象的事物用比较形象的方式表现出来

• 传统的瀑布模型：古老，很少用
• V模型：经典
• W模型
• 敏捷测试模型：最流行，最广泛

1）瀑布模型

特点：

• 阶段间具有顺序性和依赖性
• 推迟实现
• 质量保证的观点

瀑布模型是文档驱动的模型，遵守这个约束可使软件维护变得比较容易，从而显著降低软件预算。

优点：

• 开发的各个阶段比较清晰。
• 强调早期计划及需求调查。
• 适合需求稳定的产品开发。

缺点：

• 依赖于早期的需求调查，不适应需求的变化。
• 单一流程不可逆。
• 风险往往延至后期才显露，失去及早纠正的机会。
• 问题在项目后期才开始暴露。
• 前面未发现的错误会传递并扩散到后面的阶段，可能导致项目失败。

最大的问题：

        测试工作后置，呆滞整改项目开发完成之后如果发现比较验证的问题，修改的成本巨大。风险后期才发现，难以回溯。

2）V模型

• 测试阶段划分得很清楚
• 每个测试阶段都有对应的开发文档支持
• 测试与开发是串行进行的而不是并行，也就是测试需要等到开发完成后再开始
• 测试对象只有程序，而不包括需求等文档
• V模型是瀑布模型的变种，瀑布模型存在的问题V模型也存在

V模型主要的特点：

将测试过程细化，分为了单元测试、集成测试、系统测试和验收测试四个不同的阶段，但仍然是测试后置，没有解决风险问题。

3）W模型

Verification：验证，针对过程的正确性（正确地做某事）

Validation：确认，针对最终产品的正确性（做正确的事）

W模型特点：

将测试和开发过程分离出来，对整个项目过程中的需求文档、设计文档同样要进行测试，将测试工作前置，大大降低整个项目的质量风险。

4）敏捷模型

敏捷模型主要的特点：

就是为了适应现代互联网公司“短频快”的开发节奏而设计的一种测试和开发的模型。

过程：

Product Backlog：产品需求

迭代：每次迭代叫做一个sprint，每个sprint里面选出来要实现的需求会安排到sprint backlog里面。每个sprint一般是以一个月作为一个周期。

Product Owner：相当于产品经理。整理出项目的所有需求，并且按照需求的优先级来将需求排列到product backlog

Scrium Master：相当于组长，team manager，他统一管理组员。

组员不会直接和Product Owner进行沟通。

daily meeting：每日会议，一般是站会形式（stand meeting）。每个人发言一般不会超过1分钟，主要开发内容包括三点：昨天你做了什么，今天准备做什么，有什么风险和问题。

sprint burndown：迭代燃尽图，记录剩余的工作量有多少。

sprint review meeting：迭代的回顾会议。主要回顾在本轮迭代中存在的问题有哪些，后面如何去改进。

首先，Product Owner整理出项目的所有需求，并且按照需求的优先级来将需求排列到product backlog，整理出来后，Product Owner会决定每一轮要实现什么需求，将其归置到sprint backlog中，每个sprint会花四周的时间，期间会有一个daily meeting，daily meeting主要是快速的组建交流，所有人汇报自己每天做了什么，今天在准备做什么，有什么风险和问题，需要什么帮助；同时可以通过sprint burndown迭代燃尽图去看当前剩余的工作量有多少；经过四周的sprint 后需要有一个产出给客户；同时，组员会进行一个sprint review meeting，迭代的回顾回忆，主要回顾在本轮迭代中存在的问题有哪些，后面如何去改进。一个迭代完成后，将未完成的需求选出下一批sprint blacklog进行迭代，直到需求完成。

五）软件质量模型

1. 质量模型是基于ISO25000和国标GB/T25000制定的可用于测量产品质量的模型，该模型提供了从不同维度考量产品质量属性的依据。

1. 质量模型规定的各种不同质量属性和不同的测试类型之间具有映射关系，所以可以用不同的测试类型来测试不同的质量属性。

蓝色的六个为内部的质量属性：（测试关注）

• • 功能性

• • 可靠性

• • 易用性：满足法律法规，合规，eg：苹果地图事件

• • 性能效率

• • 兼容性：共存性、互操作性、兼容性的依从性

• • 安全性

黄色的六个为内部的质量属性：（开发和运维关注）

• • 可移植性

• • 维护性

关于以上第一点：

eg：如何测试一个水杯的质量

1. 功能性，测试可不可以用
   • 装一半容量的水

• • 装最大安全容量的水

• • 水倒满流出来，是否影响使用

• • 水杯的刻度和国标是否一致

• • 水杯是否可以装冷水、热水，是否烫手或者冷手

• • 水杯是否保温

• • 杯盖拧紧到什么程度水倒不出来

1. 可靠性，最大的承受能力
   • 掉到地上不易破坏

• • 保温时长

• • 杯子的耐热性

• • 杯子的耐寒性

• • 杯子上防止重物达到什么程度杯子被损坏

• • 杯子和包装（有填充物），检查产品是否能对应恶劣的铁路/公路/航空运输

1. 易用性，好不好用
   • 外观是否完整，美观

• • 大小与设计是否一致

• • 喝水时是否容易漏水

• • 是否方便携带

• • 拿着舒服

• • 倒水方便

• • 喝水方便

• • 使用简单，任意操作

• • 防滑措施

1. 安全性，对人体是否有害
   • 材质是否符合国家标准

• • 杯子使用材质是否有毒或细菌

• • 高温无毒性

• • 低温无毒性

• • 装其他物体是否容易产生毒性

1. 可移植性，不同环境下使用是否有问题
   • 水杯是否能在高压或低压环境下使用

• • 水杯是否可以在高温/低温条件下使用

• • 水杯是否可以在水中使用

• • 水杯是否可以在特殊作业条件下使用

1. 兼容性，在不同环境下是否可以使用
   • 能容纳果汁、白水、酒精、汽油等

1. 性能效率
   • 使用的最大次数或时间

• • 长时间放置，放水不会漏出来

• • 往水杯倒入水的时长

• • 水杯中的倒出来的时长

1. 可维护性
   • 水杯是否容易修复

• • 水杯是否容易分解

凡是问到一个产品怎么测（不管是软件还是硬件），都必须从产品质量模型所规定的8大质量属性去考虑。

关于以上第二点：

测试类型

1. 常见测试类型及其与质量属性的关系表

名称	说明	对应的质量属性
功能测试	验证产品能否满足用户特定功能要求并做出正确响应	功能性
安全性测试	验证产品是否有保护数据的能力，并能在合适的范围内承受恶意攻击	功能性
兼容性测试	验证产品是否能够和其他相关产品顺利对接	功能性
配置测试	验证产品是否能够在推荐配置上流畅运行；验证产品为了完成特定功能的输入是否会出现故障	功能性，易用性
可靠性测试	验证产品在长时间运行下能否满足保证系统的性能水平；在存在异常的情况下系统是否依然可靠	可靠性
易用性测试	验证产品是否易于理解、易于学习和易于操作	易用性
性能测试	测试产品提供某项功能时的时间和资源使用情况	效率
安装测试	测试产品能否被正确安装并运行	可移植性

六）测试类型分类

测试阶段不同	代码是否可见	执行手段不同	测试目的不同	其他测试类型
单元测试 集成测试 系统测试 验收测试	黑盒测试 白盒测试 灰盒测试	手工测试 自动化测试	GUI测试 接口测试 性能测试	回归测试 冒烟测试 探索性测试

1. 黑盒测试：指在不知道被测代码结构的基础上根据产品的需求、站在最终用户的角度来对软件的输入和输出进行测试的过程。

1. 白盒测试：指基于被测软件的代码和结构，对被测软件的代码和结构本身进行测试的过程。（一般开发工程师做）

1. 灰盒测试：介于白盒和黑盒之间 ，一般来说灰盒是针对接口来进行测试。比如只知道函数的函数名、参数以及返回值，并不知道函数内部的实现结构。

探索性测试：即不依赖于测试用例，根据自己的经验、感觉进行测试

七）项目相关的文档

1. 开发阶段主要文档
   • 需求规格说明书

• • 概要设计

• • 详细设计

1. 测试阶段主要文档
   • 测试计划和方案（一般工作了几年）

• • 测试用例

• • 缺陷报告

• • 测试报告

八）测试流程

1. 分析：需求评审、测试需求分析——得到测试点

1. 计划：测试计划和方案文档编写

1. 设计：测试用例设计

1. 实现：编写测试用例、测试脚本等

1. 执行：搭建测试环境，执行测试脚本、编写测试报告

按照以上步骤一：步步实现

1）需求评审

需求的来源：

1. 合同型项目（外包，有甲乙方）
   • 用户业务需求->产品需求

1. 产品型项目（没有明确用户）
   • 协议/标准/规范

• • 继承性需求

• • 竞品分析

1、需求评审

1. 需求从哪里来，如果没有需求怎么办
2. 需求评审怎么评

需求评审表：

2、测试需求分析

1. 为什么要做需求分析
2. 测试需求分析流程

为什么要做测试需求分析：

1. 在做任何系统的测试之前，我们都需要思考以下的问题：

1. 你知道要测试的系统是干什么的吗

1. 你了解系统有哪些特点吗

1. 你知道系统有哪些功能吗

1. 你知道系统的业务的流程是什么吗

1. 系统在这个版本上，哪些需要测试，哪些不需要测试？

1. 系统对性能、安全性上有没有什么要求？

3、需求分析流程

1. 根据产品需求提取系统的测试点
2. 编写需求跟踪矩阵
3. 根据测试点利用适当的测试用例设计方法设计测试用例

4、测试设计与用例编写

测试设计的概念

将测试点转化为测试用例的过程，就叫测试设计。

测试用例的概念

测试用例就是一种用来说明具体如何进行测试操作并验证结果的文档

测试用例模板

1. 用例编号：TC：Test case，系统名，模块名，自然编号
2. 用例标题：用一句话来表述该测试用例测试哪个测试点
3. 优先级：高中低。作用是在项目时间不够或人员不充足的时候，我们可以优气测试重点的测试用例
4. 预置条件：在执行该条用例时，系统必须达到的一个状态或者条件。可选，不要全部都写
5. 创建人
6. 创建时间
7. 所属模块
8. 测试步骤：详细描述测试此条用例时，需要进行哪些操作
9. 预期结果：来自于需求，要求我们达到的一个结果
10. 实际结果：实际操作系统之后的结果
11. 测试结果：Fail / pass / NA。N/ A指当前用例不适用或无法操作。必填。
12. 备注

九）测试用例设计方法

等价类、边界值、判定表、流程分析法（场景分析法）、错误猜测法

世界上最好的测试方法是什么？穷举法

1 )等价类法

定义：某个输入域的集合，在这个集合中每个输入条件都是等效的．如果其中某一个输入不会导致问题，则集合中其他输入条件进行测试也不可能发现问题。

有效等价类：有效等价类对程序有意义、正确的输入数据。

无效等价类：无效等价类对程序无意义、不正确的输入数据。

基本原则：

1. 如果输入条件规定了取值范围或者值的个数，则可以确定一个有效等价类和两个无效等价类

eg:要求输入年龄在18~25之间

则18~ 25就是一个有效价类，小于18和大于25就是两个个无效等价类。

1. 输入条件规定了输入值的集合，或是规定了必须如何的条件，则可以确定一个有效等价类和个无效等价类。
2. 在输入条件是一个布尔值的情况下，可以确定一个有效等价类和一个无效等价类
3. 如果我们确知，已经划分的等价类中各个元素在程序中的处理方式不同，则应该将此等价类进一步划分
4. 在规定了输入数据必须遵守的规则情况下，可以确立一个有效等价类（遵守规则）和若干个无效等价类（从不不同角度违反规则）

等价类划分法设计步骤：

        编写等价类表，为每个输入划分等价类，得到等价类表，为每个等价类规定一个唯一编号。

        设计一个测试用例，使其尽可能多的覆盖所有尚未覆盖的有效等价类，重复这一步骤，使得有效等价类均被测试用例所覆盖。

        设计一个测试用例，使其只覆盖一个无效等价类。重复这一步骤石得所有无效等价类均被覆盖。

2）边界值法

       对于程序的输入和输出边界进行测试的一种黑盒用例设计方法，常与等价类设计法结合使用，此时它的用例来自于等价类的边界。

       边界值分析法的理论基础是假定大多数的错误发生在各种输入条件的边界上，如果再边界附近的取值不会导致程序错误，那么其他的取值导致程序错误的可能性也很小，

       边界值使用条件（重点：可度量）

输入条件明确了一个值的取值范围，或是规定了值的取值个数

输入条件明确了一个有序集合

1. 上点：边界上的点

1. 离点：离边界最近的点

1. 内点：取值域内的任意一个点

如何使用括号法快速判断离点？

上点：范围中你看到的那两个点一定是上点（不管等于还是是<、>、=）

离点：

离括号更近的点，比如59，60）61 所以离点是61

一个数不可能是上点又是离点

Eg:

20

       19，20，（21   79），80，81

       20和80已经是上点了，所以21和79是离点

边界值法设计用例步骤

       分析输入参数的类型：从测试规格中分析得到输入参数类型

       等价类划分（可选）：对于输入等价类划分方法进行等价类的划分确定边界：运用域测试分析方法确定域范围的的边界（上点域内点）

       形成测试项：选择这些上点，离点与内点或者这些点的组合形成测试项

等价类和边界值使用场景

把输入条件分成多个不同的子条件，条件与条件之间相对独立，没有制约关系

3）判定表法

判定表是分析和表达多种输入条件下系统执行不同动作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确

       条件装（Condition Stub）

       动作桩（Action Stub）

       条件项（Condition Entry）

       动作项（Codition  Entry）

判定表的设计步骤．

• • 确定规则的个数。如这里有3个条件，每个条件有两个取值，故应有2*2*2= 8种规则

• • 列出所有条件桩和动作桩

• • 填入条件项

• • 填入动作桩和动作项

• • 化简，合并相似规则

• • 将每条规则转化为用例

判定表的合并

化简工作是以全并相似规则为目标。如果表中有两条或多条规则具有相同的动作，并且其条件项之间存在极为相似的关系，我们便将其合并

eg

前4列不能合并，因为动作桩有一列不一样。后4列，只要条件－为o,后面也为o

两条规则：

规则一：原密码输入正确，新密码达到复杂度要求，密码修改成功且出现相应提示信息

规则二：：原密码输入正确，新密码不符合复杂度要求，密码修改不成功且不出现提示

4）流程分析法

流程分析法（又名场景设计法）是将软件系统的某个流程看成路径，用路径分析法来设计测试用例。根据流程的顺序进行组合，使得流程的各个分支都能走到。这是从白盒测试中路径覆盖分析法中推广到黑盒测试中来的测试分析法

基本流：指所有操作都正确的主流程

备选流：指部分操作不正确的流程分支

流程分析法用例设计步骤：

1. 画出业务流程图

1. 设置公里路径优先级

1. 确定测试数据

1. 构造测试用例

eg：

推荐网站：draw.io、processon

流程图法eg.drawio

基本流：ACEF

备选流：AB，ACD

5）错误猜测法

错误猜测法就是根据经验猜测可能有什么问题并依此设计测试用例

错误猜测法智能作为测试用例的补充，而不能单独用来设计测试用例，否则可能会造成测试的不充分

错误猜测不是瞎猜，不是没有根据和目的的猜测，它需要一句对系统薄弱地方的了解和开发人员盲点的了解。

探索性测试即基于错误猜测法。

两个因素：

业务熟悉程度、编程经验的丰富度

eg：

一致一段程序能够对任意输入的列表进行排序，试根据错误猜测法写出测试点

列表eg：

a=[3,5,6,2,9]

测试点eg：

1. 重复参数：[1,1,1,1]

1. 出现非数字：[1,3,5,a,4]

1. 列表为空或长度为1：[]、[1]

1. 顺序问题：[1,2,3,4,5]、[6,5,4,3,2,1]

6）测试用例设计总结

测试用例设计方法很多，需清楚每种方法的使用场景：

1. 等价类和边界值法是任何其他测试设计方法的基石，必须首先考虑使用等价类和边界值进行用例设计

1. 当输入域和输出域之间有月数关系，必须使用判定表来进行组合

1. 在考虑了所有测试用例方法后，最后还要使用错误猜测法进行补充，以免遗漏

1. 在测试某一个字段时，应保证其他字段的取值是一个正常值

十）测试点分析和提取

测试需求分析流程

1. 根据产品需求提取系统的测试点

1. 编写需求跟踪矩阵

1. 根据测试点利用适当的测试用例设计方法设计测试用例

1）测试点提取思路

1. 首先检查界面元素的显示是否正确
2. 测试页面的基本功能。如果页面既有表单也有列表，则优先测试表单功能是否正常
3. 针对表单在测试时，需要依据表单里面的每个字段依次进行测试。凡是用户可输入的输入域，都要使用等价类和边界值根据字段的约束来进行考虑
4. 如果多个字段之间有关联关系和约制关系，那么在测试完单个字段的等价类和边界值之后，应该继续使用判定表等测试方法进行组合的测试
5. 表单测试完后，再测试列表中的功能
6. 当单个页面的内容都测试完毕后，再来结合流程分析法（场景法）测试流程相关的内容
7. 流程分析测试完后，最后再使用错误猜测法来确保没有遗漏的测试点

表单：既有输入域又有提交按钮的页面都叫做表单页面

测试点提取例子：

在企业内，一般测试点的提取有两种记录方式：

1. 在word或者excel表格中记录测试点

1. 使用思维导图来记录测试点

在很多企业内，如果测试时间短，无法完整地设计和熟悉额测试用例时，一般会直接写测试点来替代测试用例。

2）测试需求分析

建立需求跟踪矩阵：指跟距产品需求和测试点以及测试用例，建立一个三者映射的列表，这个列表叫做需求跟踪矩阵。

eg：

需求跟踪矩阵的作用：

1. 建立产品需求、测试需求与测试用例之间的映射关系，方便进行用例需求覆盖率的统计

1. 如果需求发生变更，可以根据需求跟踪矩阵快速定位哪些测试用例需要更新

十一）缺陷定义以及生命周期管理

缺陷的定义：

1. 软件没有实现产品的说明书所描述的功能

1. 软件实现了产品说明书描述不应有的功能

1. 软件执行了产品说明书没讲的操作

1. 软件没有实现产品说明书没讲但应该实现的功能

1. 从软件测试员的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对

缺陷管理：

1. 掌握软件缺陷的生命周期

1. 掌握高质量缺陷报告的填写方法

1. 掌握i软件缺陷的相关属性

1. 了解软件缺陷管理的常用工具

1. 了解缺陷冲突中一些常见的问题

1）缺陷生命周期

当测试工程师发现一个新的缺陷，提交到测试经理，是否有效的测试缺陷，测试经理检查缺陷是否重复，若是重复了则Abandon，即作废，若是未重复，则将缺陷的状态改为open，将缺陷发送到开发，开发的组长/经理确定优先级，确定是否推迟，若是则postpone即推迟，否则assign（分配），分配给对应的开发工程师。开发修复后，缺陷改为fixed状态，bug管理系统将缺陷自动的发送给测试工程师，测试validate（验证）缺陷是否修改好，若是则改为closed状态，否则开为reopen状态，将缺陷自动返回给当时的开发进行修改，修改后重复上一步骤。

描述缺陷管理流程或者生命周期，必须要写清楚两点：

1. 缺陷管理里面每一步是如何进行流转的，并且负责人是谁

1. 缺陷管理每一步对应的缺陷的状态

2）如何填写缺陷报告

1. 缺陷编号（若没有则NA）

1. 预置条件

1. 缺陷标题（一句话概况缺陷）

1. 测试步骤（尽可能详细）

1. 严重程度

1. 优先级

1. 重现率

1. 缺陷状态

3）缺陷严重程度分类

严重性：软件缺陷对软件质量的破坏程度，即软件缺陷的存在将对软件的功能和性能产生怎样的影响。

1. 致命：eg，软件的意外退出甚至操作系统的崩溃，造成数据丢失

1. 严重：eg，由于单功能导致多个相关功能均失效

1. 一般：eg，软件的单个功能失效

1. 提示：软件界面的细微缺陷，eg，某个空间没有对齐，某个标点符号丢失等

4）缺陷的状态分类

New	缺陷的初始状态
Open	开发人员开始修改缺陷
Fixed	开发人员修改缺陷完毕
Closed	回归测试通过
Reopen	回归测试失败
Postpone	推迟修改
Rejected	开发人员认为不是程序问题，拒绝状态
Duplicate	与已经提交的Defect重复
Abandon	被Reject和Duplicate的Defect，测试人员确认后的确不是问题，将Defect置为此状态，Abandon是一种特殊意义的Closed

缺陷状态迁移表：

5）缺陷管理中常见的问题

1. 提交的缺陷开发人员不认可怎么办

依据需求，若是没有需求，则找产品经理，没有产品经理则找项目经理，说明为什么会觉得它是个缺陷，列举依据。

1. 如何出来不能重现的缺陷
   • 一定要提交到缺陷管理库！！！

• • 一定要详细描述遇到缺陷的过程和环境的配置。如果有日志的话，一定要附上相关的操作日志或者系统运行的日志。

• • 对于不可重现的缺陷，一定要尽量描述清楚复现率是多少。

• • 对于不可重现的缺陷，当开发人员将缺陷设置为fixed之后，在验证时，不能只在一个版本上去验证缺陷是否修复，必须至少在3个以上的版本上验证后都没有重现过，才能将缺陷关闭。

1. 如何处理好开发人员及其他相关人员的关系

平时多交流；提升自己的能力，加强专业化

1. 缺陷太多怎么办
   • 可能是开发对需求理解的问题，或者是技术的问题

• • 重复出现了bug，若是老的bug，询问开发是什么原因，为什么之前关闭掉的bug重现了，属于质量问题了。

1. 找不到缺陷怎么办

两个可能性：

• • 这个产品很成熟

• • 能力技术原因

如何区分：

观察队友，若是别人都找的到bug，那么就是第二种情况

1. 如何处理缺陷跟踪中的扯皮现象

通过开会去评审，或者通过上级去评审处理

十二）回归测试和验收测试

1）回归测试

回归测试（regression testiong）：

回归测试是指修改旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试可以发生在任何一个阶段 ，包括单元测试、集成测试和系统测试。

目的：

• • 检查缺陷是否真的被修复了

• • 程序员在修复缺陷的过程中有没有引入新的缺陷。

回归测试的流程：

1. 在测试策略制定阶段，制定回归测试策略
2. 确定需要回归测试的版本Version，哪个版本上bug被修改了就在哪个版本上回归
3. 回归测试版本发布，按照回归测试策略执行执行回归测试
4. 回归测试通过，关闭缺陷报告单
5. 回归测试不通过，缺陷报告单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

回归测试的策略：

1. 完全回归
   • 重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改扩散局部影响性。（工程比较小的时候，即工作量不大的时候可以选择）

1. 选择性回归
   • 即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序。

选择性回归的三种方法：

1. 覆盖修改法

针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。（一般只用在时间不充足的情况）

1. 周边影响法

该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对哪些受到修改间接影响的部分选择测试用例，验证它没有受到不良影响。该方法比覆盖修改法更充分一点。（大部分情况使用此方法）

1. 指标达成方法

这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。（用于修改的bug，影响面比较大，时间不足，工作量大）

2）验收测试

1. 在通过了内部系统测试在之后，就可以开始验收测试

1. 验收测试是以用户为主的测试，验收组应该由项目组成员，用户代表等组成

1. 验收测试原则上在用户所在地进行，但如京用户同意也可以在公司内模拟用户环境进行

1. 验收测试根据合同、《需求规格说明书》和《验收测试计划》对成品进行验收测试

1. 对于产品型的项目，验收测试一般又Alpha测试和Bata测试两种

Alpha测试(内测)：

1. Alpha测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户模拟实际操作环境下进行的测试

1. Alpha测试时，软件在一个自然设置状态下使用。开发者坐在用户旁，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试。

1. Alpha测试的目的主要是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和技术支持）

Bata测试(公测)：

1. Bata测试是由软件的多个用户在一个或多个用户的实际使用环境（生产环境）下进行的测试

1. 与Alpha测试不同的是，Bata测试时开发者通常不在测试现场。因而Bata测试时在开发者无法控制的环境下进行的软件现场应用

1. 目前在很多互联网公司也成为灰度测试。

特邀用户进行的测试。

十三）生命周期各测试方法对比

一般冒烟测试和回归测试用例，是从系统测试用例这个大类里选择出来。

十四）测试报告编写

了解模板。

十五）禅道的基本使用

安装过程：

使用方式： 

十六）测试执行的过程流程

测试执行工作流程：

1. 确定测试用例优先级

1. 创建测试数据，同时也可以准备测试工具和设计自动化测试脚本

1. 创建本次测试的测试套件，以提高测试执行效率

1. 确认已经正确搭建了测试环境

1. 根据计划的执行顺序，通过手工或使用测试工具来执行测试套件内的用例

1. 记录测试执行的结果，以及被测软件、测试工具和被测软件的标识和版本

1. 对比实际结果和预期结果之间的差异，如果确认是缺陷需要填写缺陷报告

1. 缺陷被开发人员修改后，重新进入下一轮测试

十七）MMS系统环境搭建

系统运行原理：

1）服务器环境搭建

1. JDK的安装，主要是为了提供java的运行环境。（Tomcat服务器是由java写的，所以要运行tomcat首先要配置好java环境）
   • JAVA_HOME：安装JDK的路径

• • CLASS_PATH：.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar(.代表当前目录)

• • PATH：%JAVA_HOME%\bin 、 %JAVA_HOME%\jre\bin

• • 检查：在cmd中输入java看是否可以返回对应的信息，或者java -version查看java 的版本

1. Tomcat的安装，tomcat作为主要的web服务器，负责处理客户端发送的所有请求。
   • 把tomcat压缩包解压到一个不含中文或者特殊符号的路径下

• • 在CATALINA_HOME：配置tomcat的路径

• • PATH：添加%CATALINA_HOME%\bin

双击bin目录下的，start.bat运行tomcat。若是一闪而过，有可能环境变量配置有问题。

1. Mysql数据库的安装，mysql数据库主要用于管理系统数据。
   • 可以直接安装wampserver工具，通过其启动mysql和apache服务器

搭建与使用参考：WampServer 安装使用详解 - Selier - 博客园

先关闭tomcat，再把mms.war放入webapp，再打开tomcat（bin目录中）

2）被测系统相关的配置

1. 将被测系统的war包放置到tomcat制定的目录中

1. 将数据库对应的sql文件导入到数据库中，并且修改mysql数据库默认的密码

1. 启动服务器，访问被测系统

环境变量：实际上是一种的设置，通过这些设置可以告诉电脑我们要运行的目标文件在什么位置

十八）MMS药品管理系统项目实战

拿到一个项目之后，你进入一个项目组之后，需要做的事情：

• • 根据实际情况，如果公司被测系统已经可用，则首先搭建系统环境（在公司的话，需要找相关的人员给安装包和安装步骤）；若不可用，则需要拿到产品原型图 ，根据产品原型做下一步分析。

• • 理解和分析需求。若没有需求规格说明书，则需要自己去通过使用被测系统或者产品原型了解需求。若有专门的需求规格，则必须根据需求规格进行分析。（必须熟悉需求！！）对于需求规格上已经定义的需求，必须严格按照需求规格定义的要求来测，如果需求没有定义，如果从测试角度需要关注，则尽量考虑进去，然后利用缺陷反推让产品需求更加完善。

• • 根据需求分析测试点

• • 根据测试点，设计测试用例

• • 根据设计好的测试用例，执行测试，报告bug

• • 编写测试报告

Alp说明: 图片 图像 小部件