目录
1.知识总结……………………………………4
1. 1基础理论知识…………………………4
1.1.1课堂理论知识………………………5
1.1.2软件测试的基本流程………………5
1.1.3软件测试的定义原则………………6
1.1.4白盒测……………………………7
1.1.5黑盒测试试……………………………7
1.1.6灰盒测试……………………………8
2实验总结……………………………………9
2.1Testlink的使用归纳…………………9
2.1.1熟悉TestLink的工作流程…………9
2.1.2.Testlink的步骤……………………9
2.1.3.Testlink中遇到的问题……………10
2.2Mantis的使用归纳………………………11
2.2.1 Mantis的流程………………………11
2.2.2.Mantis的步骤…………………………11
2.2.3.Mantis中遇到的问题 ………………12
2.2.4.集成Testlink与Mantis………………12
2.3黑盒测试的三种方法…………………12
2.31等价类的示例…………………12
2.32划分等价类的注意事项………………12
2.33因果图的示例…………………13
2.34因果图的注意事项…………………13
2.35边界值的示例…………………14
2.36边界值的注意事项…………………14
2.4飞机订票系统…………………15
2.41飞机订票系统的测试要点…………………15
2.42测试要点的注意问题…………………15
2.43飞机订票系统的测试用例…………………15
2.44测试用例的注意问题…………………16
2.45飞机订票系统的缺陷报告…………………17
2.46缺陷报告的注意事项…………………17
3.问题. ………………………………………18
3.1.TestLink及Mantis错误总结……………18
3.2黑盒测试方法的错误总结……………18
3.3飞机订票系统的错误总结……………18
3.4.问题反馈…………………………………19
4.学习规划…………………………………………19
一．知识点总结：
第一章：
1.软件的定义：软件由程序，数据和文档组成，开发人员通过的写入代码形成了一个个程序，整个过程会有数据的输入和输出，从而会形成不同的文档。
2.软件的生命周期：需求分析——设计——编码——测试——运行和维护。
第二章：
1. 软件的生命周期的模型：
（1）瀑布模型：
（2）V模型：横着看V模型是一一对应的。
（3）W模型：两个V模型组成的。
2.软件测试的七个原则：（1）测试显示缺陷的存在；（2）穷尽测试是不可能的 ；（3）测试尽早介入；（4） 缺陷集群性（80-20原则）;(5) 杀虫剂悖论 ;(6) 测试活动依赖于测试背景 ;(7) 不存在缺陷（就是有用系统）的谬论。
第三章：
软件测试的生命周期：计划测试——需求分析——设计测试用例——开发测试用例——执行测试用例——测试报告评估。
第四章：
1.是否关心内部结构：（1）白盒测试：又称为结构测试或者逻辑驱动，只关心内部结构。
（2）黑盒测试：功能性测试，不关心程序的内部结构，关系其功能性。
（3）灰盒测试：介于白盒和黑盒测试之间的，既要关心内部结构又要关心功能。
2. 开发过程级别：
（1）单元测试：对应于白盒测试，是软件开发过程中要进行的最低级别的测试，由程序员自己负责。
（2）集成测试：对应于灰盒测试，好多单元测试集合而成。
（3）系统测试：对应黑盒测试，不关心内部结构。
（4）验收测试：分为组内测试和用户测试。
3. 是否执行程序：
静态测试：在不运行程序的情况下进行分析，检查程序的正确性。
动态测试：通过运行被测程序，检查运行结果。
4. 执行是否需要人工干预：手工测试；自动化测试.
5. 测试实施组织：开发测试; 用户测试; 第三方测试。
第五章：
缺陷的流程：发现缺陷——测试人员提交——分配——开发人员修正——测试人员——closed或reject——评审委员会
第六章：
W模型：两个V模型组成的。
第七章：
1.同行评审：是由开发软件产品作者以外的其他人检查工作产品，以发现缺陷并寻找改进的机会。
2. 同行评审一般包括审查、小组评审、走查、桌面评审、临时评审五种类型。从成本，正式程度，人员等方面来说明五种类型的不同，其中经常会用到的是小组评审和走查。
3.调试和白盒测试的不同。
调试：开发人员在开发软件过程中发现问题，并且解决问题。
白盒测试：测试人员根据一定计划，发现问题，从而提交给开发人
4.软件质量概念：反映软件产品满足规定需求和潜在需求能力的特征和特性的总和；所有描述计算机优秀程度的特性的组合； 与软件产品满足需求所规定的隐含的能力有关的特征和特性的全体。
5.软件质量的特性：功能性，可靠性，可用性，效率，维护性，可移植性。
6.FCM三程质量模型：
第八章：
一、白盒测试
1.“白盒”测试又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。
2.调试与白盒测试的区别;调试是由开发人员在编程过程中自我发现问题，并改正错误；白盒测试是由测试人员有计划的进行发现缺陷，并把缺陷提交，由开发人员改正。
3. 逻辑覆盖的种类：
• 语句覆盖：语句覆盖是最起码的测试要求，使得每一条语句至少被执行一次
• 判定覆盖：要求设计足够的测试用例，使得程序中的每一个分支至少通过一次
• 条件覆盖：不仅每一个语句至少执行一次，使得判定中的每个条件获得各种可能的结果。
• 判定/条件覆盖：至少能够获取一次，同时每个判断的所有可能的判定结果至少执行一次。
• 条件组合：满足条件组合覆盖标准的测试用例，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。
• 路径覆盖：要求设计足够多的测试用例，使得程序中所有的路径都至少执行一次 。
逻辑覆盖的六种方法
语句覆盖：每一条语句至少被执行一次。
判定覆盖：每一条分支语句的“真”值和“假”值都至少执行一次。
条件覆盖：每个判定的每个条件的所有可能取值至少执行一次。
判定/条件覆盖：同时满足判定覆盖和条件覆盖。
条件组合覆盖：每一个判定的所有可能的条件取值组合至少执行一次。
路径覆盖：设计若干个测试用例，运行被测程序，覆盖程序中的所有可能路径。
•
二、黑盒测试
（一） 黑盒测试又称功能测试或数据驱动测试，把被测软件看做成一个封闭的盒子
把测试对象当作看不见内部的黑盒，在完全不考虑程序内部结构和处理过程的情况下 测试的
（二）. 黑盒测试主要用于发现以下情况
①是否有不正确或遗漏了的功能
②在接口上，能否正确地接受输入数据，能否产生正确地输出信息
③访问外部信息是否有错
④性能上是否满足要求
⑤界面是否错误，是否不美观
⑥初始化或终止错误
（三）.等价类划方法的理论知识
1.等价类划分是把所有可能的输入数据,即程序的输入域划分成若*分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。
2.等价类的划分分为两种：
（1）有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合 。
（2）无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合
3.划分等价类的规则
（1）.输入条件的取值范围，可以划分出一个有效等价类和两个无效等价类
（2）. 如果输入条件规定了输入值的集合，或者是规定了“必须如何”的件，这时可确立一个有效等价类和一个无效等价类
（3）. 如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。
（4）.如果规定了输入数据的一组值(假设N个)，而且程序要对每个输入值分别进行处理。
(5).如果规定了输入数据必须遵守的规则，则可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)
(6)在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
(四)．边界值分析方法的理论知识
1.定义：
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法,稍高于其边界值及稍低于其边界值的一些特定情况
2.边界值分析方法 ：
选取正好等于，刚刚大于，或刚刚小于边界的值为测试数据的方法
3.等价分类法与边界值分析法的比较：
(1).边界值分析法使用范围更广，更复杂，找到的缺陷也更多，需要测试人员有更多的经验和耐心
(2).等价分类法的测试数据是在各个等价类允许的域内任意选取的
(3).边界值分析法的测试数据必须在等价类的边界值附近选取
(4).边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
（五）因果图
1.定义：
是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系。
2.适用范围
（1）.适合检查程序输入条件的各种组合情况
（2）.产生背景
（3）.等价类法、边界值法分析着重考虑输入条件，未考虑输入条件之间的关系
(六).区别：
（1）等价类划分法的测试数据是在各个等价类允许的值域内任意选取的。
（2）边界值分析法的测试数据是在等价类的边界值附近选取，它是对等价类划分法的补充，使用范围更广，更复杂，找到的缺陷也更多。
（3）等价类划分法、边界值分析法都着重考虑输入条件，但未考虑输入条件之间的关系。而因果图充分考虑了输入情况的各种组合与输入条件之间相互制约的关系。
(七). 测试用例设计
1.测试用例主要元素
测试用例编写要素
2.测试用例要素与模板
编写测试用例注意事项 - -功能检查
三.灰盒测试
是一种综合测试方法，他将黑盒测试、白盒测试、回归测试和变异测试结合在一起，构成一种无缝测试技术。
四、测试用例
÷ 1、创建项目“白盒”测试
÷ 2、创建测试需求树
÷ 3、创建测试用例
÷ 4、为需求指派用例
÷ 5、创建测试计划
÷ 6、为计划添加用例
÷ 7、分配测试任务
÷ 8、执行测试/报告BUG 并跟踪
÷ 9、查看分析结果
÷ 10、测试报告：结果-报告格式-MS word
二．实验
（一）testlink的步骤重现：
Testlink的使用
Testlink 问题及解决方法
1 testlink 怎么设置中文？ 简单的方式是设置角色的语言改成简体中文，刷新一下即可 2.设置测试用例的所有者（给测试人员分派测试任务）（找不到） 3.实验一需要和 mantis 集成吗？
实验一暂时不需要和 mantis 集成，到实验二 mantis 的时候再集成
4.逗号分隔值（Comma-Separated Values，CSV，有时也称为字符分隔值，因
为分隔字符也可以不是逗号），其文件以纯文本形式存储表格数据（数字和文本）。 5.文档中的“产品”也就是“测试项目” 6.怎样查看需求的覆盖率？
点击-需求-找到具体的模块点开，在右侧显示需求 7.版本管理在哪？
版本管理就是构建管理 8.怎样查看和保存分析结果测试报告 结果-报告格式-MS word，会自动弹出保存框 9.执行的时候怎样判断一个测试是通过还是失败？
一个测试用例如果是只有一个步骤的话，该步骤的通过或失败可以直接判断； 如果一个测试用例有多个步骤，则如果其中有任意一个步骤的执行失败的话，该 测试用例的结果就是失败，只有全部步骤都通过该测试用例才是通过。
如：一个包含 4 步的测试用例，第 2 步执行结果失败了，那么该测试用例就是失 败的，后 2 步不用再执行了。这 4 步全对，该测试用例才是通过的。
简化步骤指导
首先需要配置好 Testlink
创建项目(产品) 创建需求 创建测试用例 创建计划 给计划添加测试用例 分配测试任务 执行测试/报告 bug
1、创建项目：（测试项目管理-新建项目，勾选下面所有复选框）（FR）
用户管理：创建用户
产品设置：（测试计划在特定时间里描绘产品的测试。这句话的意思就是说所有的测试 计划需要根据产品测试用例来创建。） 这里的产品也就是项目
2、创建测试需求规格、需求
创建需求规格:需求-在测试产品中下拉选择对应的项目-需求规约-选中项目-点击-新建需求规约（客户端、服务器）
创建需求：选中产品下的需求规格点击-创建新需求（状态、类型、需要的测 试用例数）（登录、订票）
3、创建测试用例
创建测试集：（测试套件(Test Suites)）主页-测试规约-选中产品点击-右侧新建测试集 创建测试用例：选中测试集点击-创建测试用例-点击保存-创建步骤（注意每次创建一步，
写完之后再接着写下一步） 例如：
需求关联：主页-需求-指派需求-选中测试树中的一个测试用例（左侧）-选中需求指派 （包含有效需求和已指派的需求） 需求-选中需求-可以查看需求覆盖情况
4、为需求指派用例
需求关联：主页-需求-指派需求-选中测试树中的一个测试用例（左侧）-选中需求指派（包 含有效需求和已指派的需求） 需求-选中需求-可以查看需求覆盖情况
5、创建测试计划
测试计划是执行测试用例的基础，测试计划由测试用例组成 主页-测试计划管理-创建(勾选活动和公共两个复选框) 创建测试里程碑：（明确每个测试阶段的开始与结束时间）-测试管理-编辑/删除里程碑 版本管理（Builds/Release）（本版本叫构建管理）：主页-测试计划管理-构建管理 安排测试人员：测试计划管理-指派用户角色
6、为计划添加用例
添加测试用例到测试计划：选择当前测试计划（列表）-选择添加/删除测试用例到测试计划 选择测试集（左侧）-选择用户、构建、测试用例-添加选择的测试用例（成功变色、也
可删除）
7、分配测试任务设置测试用例的所有者：主页-测试集-
指派执行测试用例-选中左侧测试集-保存（可以指派给多人），指派给相应的人员以后，可 以让该人员使用其用户名和密码登陆 testlink 来执行测试用例；也可以由 admin 来执行，例 如：我们将一部分测试用例的执行任务分配给了用户 chang1，我们使用 chang1，密码 123 登陆以后，就可以执行该测试用例。
8、执行测试/报告 BUG 并跟踪
执行测试
9、查看分析结果测试报告：结果-报告格式-MS word
用到的理论知识
| 1 |
软件测试管理基本流程；测试需求，测试计划，测试设计（测试用例），测试执行，最后分析，总结，导出测试报告 |
| 2 |
Testlink的使用，创建项目，创建需求，创建测试用例，创建测试计划，给计划分配测试用例，分配测试任务，执行测试，导出报告 |
| 3 |
掌握testlink中各角色职责；tester是测试人员，执行测试，guest只能浏览数据，admin执行一切可操作。 |
| 4 |
使用管理员权限创建项目可执行一切可操作 |
| 5 |
使用testlink导出需要的相关文档。 |
| 6 |
掌握软件缺陷管理基本流程，测试人员提交缺陷，项目经理分配给开发人员，开发人员进行修正，在提交，评审人员进行评审，关闭 |
| 7 |
会使用mantis，录入缺陷并设置缺陷的问题等级、优先级等要素，清晰填写问题描述及重现步骤；先创建项目，在创建用户，有开发员，有测试员，分配任务，最后导出报告 |
| 8 |
掌握mantis中各角色职责；测试人员寻找缺陷。开发人员改正缺陷。 |
| 9 |
使用mantis导出需要的相关文档； |
÷
（二）Testlink 问题及解决方法
1 testlink 怎么设置中文？
简单的方式是设置角色的语言改成简体中文，刷新一下即可
2.怎样查看需求的覆盖率？
点击-需求-找到具体的模块点开，在右侧显示需求
3.版本管理在哪？
版本管理就是构建管理
4.怎样查看和保存分析结果测试报告
结果-报告格式-MS word，会自动弹出保存框
5.执行的时候怎样判断一个测试是通过还是失败？
一个测试用例如果是只有一个步骤的话，该步骤的通过或失败可以直接判断；
如果一个测试用例有多个步骤，则如果其中有任意一个步骤的执行失败的话，该测试用例的结果就是失败，只有全部步骤都通过该测试用例才是通过。
6. testlink的问题:testlink配置完以后，下次开机在通过网址进入，就进不去了（解决方案打开xampp文件夹--htdocs把my_db后面的空格去掉。
7.指派时会不经意间出现一个指派多个，一个覆盖多个的情况。（原因：操作错误或系统运行慢
（三）Testlink实验的体会：
通过testlink的实验，我熟悉testlink的安装步骤，再启动testlink之前要先开启xmapp，理解了testlink实验的流程，学会了TestLink 的初始配置、确定测试需求、测试用例管理、制定测试计划、测试报 告与度量以及与缺陷管理系统的集成等方面。
（四）Mantics重现步骤：
1. 进入mantis后，在管理员权限下创建项目，可对项目添加分类，设置、修改版本信息、自定义字段等。
2. 创建用户帐号和密码，分别担当测试员和开发员的角色。
3. 测试员登录系统，发现缺陷问题并提交，在这里我们要对缺陷进行详细描述比如缺陷的严重性，优先级，出现的频率，他所在的操作平台，操作系统，操作系统的版本重现步骤等等。
4. 开发员登录系统，查看缺陷并确认。
5. 管理员登录系统，认可缺陷，并将缺陷分配给开发员，以修改缺陷。
6. 开发员登录系统，修改缺陷，并提示已解决。
7. 测试员登录系统，查看缺陷，验证是否已解决。
8. 管理员登录系统，查看缺陷状态并关闭缺陷。
9. 导出缺陷报告。
做testlink和mantis实验遇到的问题
| testlink |
1.指派时会不经意间出现一个指派多个，一个覆盖多个的情况。（原因：操作错误或系统运行慢） 2testlink的问题:testlink配置完以后，下次开机在通过网址进入，就进不去了（解决方案打开xampp文件夹--htdocs--testlink--config_db.inc.php,把my_db后面的空格去掉
|
| Mantis |
3.Mantis在本机中已经安装过一次，但不能运行。重新安装覆盖后，能够打开mantis，但是用户管理时会出现数据错误。（原因：原来的软件包没有没有完全覆盖，应该重装前彻底删除） |
(五)mantis注意事项：
1. 怎样将mantis改成中文版的?
要找到mantis安装路径，如D:\xampp\htdocs\mantis/ config_inc.php文件，打开-在文件的末行添加如下代码，保存后，刷新一下浏览器，mantis就成中文的了
$g_default_language='chinese_simplified';
2.在mantis中创建项目的时候，项目模块中创建项目必须为管理员，一些选项也必须勾选到。
3.在用mantis生成缺陷报告的过程中，记得切换自己所创建的项目这个模块。
4.生成报告文件的过程中，可能会出现无法勾中自己所要打印的报告。可以点查看问题中P按钮显示出可以勾选的打印报告！
5. 使用mantis创建不同的用户，并以此用户进入mantis时，输入密码显示不正确，原因，没有复制第一个用户。
（六）等价类
（七）等价类应注意的问题：
（八）因果图
1.原因结果示意表
2.因果图图示
3. 真值表
4. 测试用例设计
（九）边界值
（九）测试项目
1.需求分析
2.需求分析的注意问题：
1.0
1）需求分析不全面导致遗漏需求点
2）测试点太笼统，未细分
2.0
1）测试点不细致
3.0
继续完善
3.测试要点
4.测试要点需要注意的问题：
1.0
1）无优先级
2）需求分析不完善
3）测试要点与测试点理解有误
4）测试点无编号
2.0
1）测试要点有些表示不准确
2）测试点无编号
3.0
1）测试点无编号
4.0
继续完善
5．测试用例
6.测试用例的注意问题。
1.0
1）名称和描述不规范
2）优先级写错
3）双击进入系统而非通过浏览器进入
4）缺少返回步骤
2.0
1）主题描述不标准
2）优先级有些偏高
3）缺少关闭提示对话框按钮
3.0
继续完善
7.缺陷报告
8.缺陷报告的注意事项:
1.0
1）问题标识不正确
2）存在冗余缺陷
3) 有些步骤不简洁
2.0
继续完善
2 实训问题反馈
（a）.testlink及mantis实验中遇到的问题及解决方法
表1 重点难点问题列表
| 序号 |
问题描述 |
解决方法 |
| 1 |
testlink的问题:testlink配置完以后，下次开机在通过网址进入，就进不去了 |
解决方案打开xampp文件夹--htdocs把my_db后面的空格去掉。
|
| 2 |
指派时会不经意间出现一个指派多个，一个覆盖多个的情况。 |
操作错误或系统运行慢 |
| 3 |
生成报告文件的过程中，可能会出现无法勾中自己所要打印的报告。 |
可以点查看问题中P按钮显示出可以勾选的打印报告！ |
| 4 |
使用mantis创建不同的用户，并以此用户进入mantis时，输入密码显示不正确。
|
，原因，没有复制第一个用户。
|
（b）测试用例设计中需注意的问题
等价类划分：
（1）注意隐含需求，如电话号码，地区码、前缀、后缀三者间默认存在间隔符，否则系统很难区分三者的关系；输入个数时默认为非负整数等。
（2）无效等价类不能合并；
（3）空白与空格的区别；测试用例设计中需注意的问题
边界值分析法：
（1）在写边界值时略大略小都要举例说明
（2）解决问题依赖于测试背景
因果图分析法：
（1）输入条件即原因，输出条件即结果，条件与条件之间也有联系，分析时要理清条件之间的关系，是互斥、包含……
（2）当条件比较多时，使用中间节点更加清晰
边界值分析：
（1）在写边界值时略大略小都要举例说明。
（2）解决问题依赖于测试背景，如每月最高返现问题，当本月累计返现不到500时，再次消费后，能否累加到500要根据银行的具体需求。
因果图：
（1）输入条件即原因，输出条件即结果，条件与条件之间也有联系，分析时要理清条件之间的关系，是互斥、包含……
（2）当条件比较多时，使用中间节点更清晰
（c）编写测试用例需注意的问题
（1）一个用例对应一个主题，不要合并单元格。正确格式如下：
（2）描述部分要有前提条件。正确格式如下：
（3）要重视优先级。
（4）测试步骤要完整。正确格式如下：
3 学习规划
时间过得飞快，转眼间，第一阶段实训已经结束，在这段时间里，经历了很多事情，认识了很多朋友，学会了很多知识，每天过的非常充实，也很开心，老师教的非常认真，虽然只有短短的一个月，但产生了深厚的感情。老师，虽然你并不教我们了，我们依然会记得你的，
一个月来，我们遇到了很多的问题，但是在我们的努力下，一一克服，最重要的是老师一遍又一遍不厌其烦的给我们讲方法，老师，您辛苦了
在接下来的时间里，我会更加努力的学习，争取在四个月以后，找到一份稳定的工作。