1 知识总结
一．第一章 软件工程要点
1. 软件的组成：程序、文档、数据。
2. 软件危机：落后的软件生产方式无法满足迅速增长的计算机软件要求，从而导 致软件开发与维护过程中出现的问题。
3. 软件工程：方法 + 工具 + 过程。
4.软件生命周期：
瀑布模型：
V模型：
二．软件测试基础
1.软件测试是对软件需求分析、设计、编码的最终复查的一系列过程，是软件质量保证的关键步骤
目的：发现缺陷，提高质量
验证是否满足需求
建立软件质量的信心
2.软件测试7大原则：1）测试显示缺陷的存在；
2）穷尽测试是不可能的；
3）测试尽早介入；
4）缺陷集群性（80-20原则）；
5）杀虫剂悖论；
6）测试活动依赖于测试背景；
7）不存在缺陷（就是有用系统）的谬论。
三．基于生命周期的软件测试
1. 软件测试过程包括：测试计划、测试方案、测试要点、开发用例、执行用例、测试报告评估。
2. 软件测试的生命周期流程：计划测试-需求分析-设计用例-开发用例-执行用例-缺陷追踪-测试报告评估
3. 生命周期基本概念：
4. 基于开发生命周期的测试特点：
1）在软件开发过程中持续的进行测试；
2）在尽可能早的阶段点去介入；
3）需要正式的开发流程来支持；
4）组建专门的测试团队；
5）当软件整体开发活动开始的时候，测试活动就可以开始
四．软件测试分类与分级
1.对于软件测试，可从不同角度进行分类：
是否关心内部结构： 白盒测试；黑盒测试；灰盒测试；
开发过程级别：单元测试；集成测试；系统测试；验
收测试。
是否执行程序：静态测试；动态测试。
执行是否需要人工干预：手工测试；自动化测试；
测试实施组织：开发测试；用户测试；第三方测试。
2.软件测试分级：单元（组件）测试、集成测试、系统测
试、验收测试。
3. 非功能测试包括：负载测试、压力测试、文档测试、性能测试、稳定性测试、容量测试、兼容性测试
五．软件缺陷管理
1. 软件缺陷管理定义：
软件未实现产品说明书要求的功能。
软件出现了产品说明书指明不应该出现的错误。
软件实现了产品说明书未提到的功能。
软件未实现产品说明书虽未明确提及但应该实现的目标。
软件难以理解，不易运行或运行缓慢。
2. 软件缺陷产生的原因：
3. 软件缺陷描述 ：
1）可追踪信息——缺陷ID
（唯一的缺陷ID，可以根据该ID追踪缺陷）
2）缺陷基本信息
1.缺陷标题； 2.标识； 3.报告人； 4.报告日期；
5.程序的名称； 6.版本号； 7.配置； 8.缺陷的类型；
9.严重性； 10.先级； 11.关键词； 12.缺陷描述；
13.重新步骤； 14.结果对比。
4. 缺陷管理基本流程：
5. 缺陷管理一般流程：
6. 缺陷状态定义
| 缺陷状态 | 描述 |
| 已关闭 | 缺陷确认者（一般为问题生成人）验证后认为问题已解决属实 |
| 已拒绝 | 被拒绝的缺陷经缺陷确认者确认，确实不需要修复或不是缺陷 |
| 被拒绝 | 测试人员认为是系统缺陷或者是需要对系统进行优化，开发人员认为不是缺陷或者不需要优化的问题 |
| 延迟 | 问题的分析者认为是缺陷，但是不影响业务办理的进行延迟处理。 |
6. 缺陷严重程度定义
| 严重等级 | 描述 |
| 严重 | 缺陷对进度的影响可能是非常致命的，或者可能是一个停止器——即终止用户继续使用系统；或者影响测试工作继续进行的缺陷。 |
| 较严重 | 系统基本能正常工作但同一错误现象频繁出现或者问题不解决时会给后续工作带来较大风险（如需求描述不正确导致系统设计错误）。 |
| 一般 | 不属于“严重”、“较严重”、“微小”之外的缺陷。 |
| 微小 | 不影响系统功能，但影响系统的易用性（如界面美观问题、操作建议等）或产出物的一些非技术性质量问题（如文档版本、错别字等）。 |
六．软件测试过程及测试过程
1.软件开发和测试模型
2.W模型：
3.W 模型特点：
1）增加了软件各开发阶段中应同步进行的验证（verification）和确认（validation）活动。
2）基于“尽早地和不断地进行软件测试”的原则。
4.H 模型
5.H 模型特点：
1）软件测试是一个独立的流程
2）贯穿产品的整个生命周期，与其他流程并发的进
行
3）软件测试要尽早准备、尽早执行
4）软件测试分层次进行的，不同层次的测试按照某
个次序先后进行，也可以重复进行
七．软件静态测试
1. 静态测试：通常是指不执行程序代码而寻找代码中可能存在的错误或评估程序代码的过程。
2. 静态测试对象：各种与软件相关的有必要进行测试的产物，比如各类文档、源代码等。
3. 静态测试的特点：不必动态的运行程序；
可以人工进行，充分发挥人的思维优势；
不需要特别的条件，容易展开；
对测试人员要求比较高。
4.评审：对软件元素或项目状态进行评估的活动，用以
确定与预期结果之间的偏差和相应的改进意见。
5.评审包括：培训评审、预备评审、同行评审。
6.同行评审：由开发软件产品作者以外的其他人检查工
作产品，以发现缺陷并寻找改进的机会。
1） 方法：评审者通过采用一行一行仔细阅读。
2） 时间：在工作产品到达了一个完成的里程碑并即 将进入下一个开发阶段时。
3）包括：审查、小组评审、走查、桌面评审、临时评审。
7.同行评审的规格：
8.代码检查：定义：是以组为单位阅读代码，是一系列规程
和错误检查技术的集合。
代码评审开展时间：代码全部或部分完成后。
测试目的：及早发现缺陷。
具体方法：一般采用静态“白盒”测试的方法。
代码检查输出的信息：度量标准、易产生错误的代码、代码规则的执行、流图和调用图的分析。
9.代码检查方法：
八．动态测试
1.动态测试：指通过运行被测程序来检查运行结果与预期结果的差异，并分析运行效率和健壮性等指标；这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。
2.白盒测试：是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法，因此又称为结构测试或逻辑驱动测试。一般分为静态测试和动态测试。
1）静态测试：1.代码检查；2.编码标准和规范等等；
2）动态测试：（1）逻辑覆盖（包括语句覆盖、判定覆盖、条件覆盖、判定\条件覆盖、条件组合覆盖、路径覆盖）；
（2）路径测试；
（3）数据流测试；
（4）信息流分析；
（5）覆盖率分析；
1）语句覆盖：a.语句覆盖是最起码的测试要求，要求设计足够多的测试用例，使得每条语句至少被执行一次；
b.另外语句覆盖对程序的逻辑覆盖很少，只关心判定表达式的值，是很弱的逻辑覆盖标准。
2)判定覆盖：要求设计足够多的测试用例，使得程序中的每一个分支至少通过一次，即每一条分支语句的“真”值和“假”值都至少执行一次。
3)条件覆盖：a.不仅每一个语句至少执行一次，使得判定中的每一个条件获得各种可能的结果。
b.判定覆盖只关心整个判定表达式的结果，条件覆盖关心的则是每个条件各种取值的结果。
4)判定/条件覆盖：是设计足够的测试用例，使得判定中每个条件的所有可能取值至少能够执行一次，同时每个判断的所有可能的判定结果至少执行一次.
5)条件组合覆盖：要求设计足够多的测试用例，使得每个判定中条件的各种组合至少出现一次。
6)路径覆盖：要求设计足够多的测试用例，使得程序中所有的路径都至少执行一次。
3.逻辑覆盖度：
4.黑盒测试:把测试对象当作看不见内部的黑盒、在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性
5.黑盒测试方法：
等价类划分法：它是把所有可能的输入数据,即程序的输入域划分成若干部分,再从每一部分中选取少数有代表性的数据做为测试用例
边界值分析法：是一种补充等价类划分法的测试用例设计方法，它不是选择等价类的任意元素，而是选择等价类边界的测试用例
因果图法 ：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系
随机数法：能够获得大量的测试数据，测试人员只需规定输入变量的取值区间、在需要的时候提供必要的变换机制，使产生的随机数服从预期的概率分布
猜错法：是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法
6.划分等价类的原则:
(1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；
(2)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类；
(3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
(4)在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。
(5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；
(6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。
7.基于边界值分析方法选择测试用例的原则
(1)如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。
(2)如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
(3)将规则(1)和(2)应用于输出条件，即设计测试用例使输出值达到边界值。
(4)如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。
(5)如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。
(6)分析规格说明,找出其它可能的边界条件。
8.采用因果图法设计测试用例的步骤：
(1)分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
(2)分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。(3)由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
(4)把因果图转换为判定表。
(5)把判定表的每一列拿出来作为依据,设计测试用例。
9.理解猜错法、场景法
(1)错误猜测法的定义：有经验的测试人员往往可以根据自己的工作经验和直觉推测出程序可能存在的错误，从而有针对性的进行测试。它的要素共有三点，分别为：经验、知识、直觉。
(2)场景法定义
场景法是通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。
场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。
10.采用等价类划分方法列出的测试点充分，不冗余，覆盖所有的需求；
划分等价类的标准：
1)完备测试、避免冗余;
2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合;
3)并是整个集合：完备性;
4)子集互不相交：保证一种形式的无冗余性;
5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。
11.设计测试用例
在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：
1)为每一个等价类规定一个唯一的编号；
2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；
3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。
12.采用边界值方法完成对等价类的补充，结果无缺漏无冗余
由于等价类和边界值经常配合使用，因此两者可以合并为一个用例设计方法，下面总结一下使用等价类边界值设计测试用例的思路和方法。
1)分析需求，挖掘隐式条件，确认边界值，划分等价类
2)将划分出的等价类填入表格，进行编号
3)对有效等价类，用一条用例尽量多的覆盖
4)对于无效等价类，一对一的覆盖，最终得到测试用例
13.心得：在设计测试用例时，首先要把测试需求点整理清楚，划分好类别，不明白不清楚的地方一定要及时跟项目经理、客户沟通，解决问题。千万不要置之不理，否则后续会陷入不断修改测试用例的恶性循环。另外，在整理需求的时候，不要嫌麻烦，将测试点一条一条罗列清楚，这样在后面写测试用例的时候条理也更加清楚明确。俗话说的好，好的开始是成功的一半！加油！
14.mantis和Testlink集成
（1）.在C:\xampp\htdocs\testlink下找到config.inc,php文件把文件中interface_bugs=’NO’把其中的NO改成MANTIS
（2）. 在C:\xampp\htdocs\testlink\cfg文件下找到文件mantis，inc。php，把里面的文件全部替换成下图所示
文件替换
这样就能完成testlink和mantis的集成，然后只需要登录到testlink找到为通过的项目，通过点击虫子，进入问题编号输入框就能与mantis进行连接了。
15.Testlink简化步骤：
创建项目(产品)
创建需求
创建测试用例
创建计划
给计划添加测试用例
分配测试任务
执行测试/报告bug
1）创建项目（产品）
① 单击“测试项目管理”来创建新项目，输入项目名称、前缀以及项目描述。
② 单击“用户管理”选择编辑用户，单击“创建”创建一个新的用户，并将语言设为中文。
2）创建测试需求
① 单击主页上的“产品需求”，新建一个需求规约，输入文档ID、标题。若仍要继续创建需求规约，则依据此方法
② 选择你要编辑的需求规格，点击该页面上的“创建新产品需求”按钮，开始新建测试需求。
3)创建测试用例
（1）创建测试用例集
点击主页上的“测试用例”菜单下的“编辑测试用例”，填写好相关的内容后，单击“创建测试用例集”按钮，创建该用例集
（2）创建测试用例
选择创建好的测试用例集，点击页面右侧的“创建测试用例”按钮，输入标题后单击“创建”按钮
（3）删除测试用例
经过主管许可后，通过“删除”按钮可以将测试用例集和测试用例从一个测试计划中删除。 当第一次创建一个测试计划时，由于其中还没有包含任何结论，删除数据也许是有益的。但是在 大部分情况下，删除测试用例会导致与它们相关联的所有结果都丢失。因此，使用这项功能时一定要十分谨慎。
4）添加测试用例
选择创建好的测试用例集，点击该页面右侧的“创建测试用例”按钮，新建一个测试用例，测试用例创建成功后，点击“创建步骤”按钮，输入数据，点击“保存”。
5）制定测试计划
1）创建测试计划
点击主页“测试计划管理”模块下的“测试计划管理”菜单。在出现的页面点击“创建” 按钮，进入测试计划创建页面。
2）创建里程碑
单击主页面“测试计划管理”模块下的“编辑/删除里程碑”菜单，创建一个新的测试里程碑。测试里程碑的内容包括：名称、日期、优先级。
3）版本管理
点击主页“测试计划管理”模块下的“版本管理”菜单，创建一个新的测试版本。
4）指派用户角色
单击主页面“测试计划管理”模块下的“指派用户角色”菜单，为测试计划指派用户。
在为测试计划指派用户页面，可以选择测试计划，选择好需要指派权限的测试角色后， 点击更改按钮，则可以更改测试计划。选择好测试计划后，可以将该测试计划以不同的角色 分配给不同的用户，通过角色列表，可以选择用户对该测试计划的操作角色，选择结束后， 点击更新按钮，可以保存结果。
6）添加测试用例到测试计划
在主页上选择测试计划单机“测试用例集” 下的“添加/删除测试用例到测试计划” 按钮进入测试计划添加到测试用例。
7）给测试人员分配测试任务
单击主页面“测试用例集”模块下的“指派执行测试用例”菜单，进入指派测试用例页面，可以为当前测试计划中所包含的每个测试用例指定一个具体的执行人员。
8）执行测试并导出报告
1）执行测试用例
在菜单栏中单机“执行”按钮进入“测试用例执行”界面 ，执行测试用例，观察测试结果。
2）导出报告
在主菜单上单击“结果”这一选项进入测试结果报告页面，报告格式选择“HTML”选择要导出的测试报告，单击“导出报告”按钮将报告导出。
16.Testlink中默认的角色包括：
admin--管理员：最高级别，拥有所有的权限
leader--项目责任人：除了产品权限、自定义字段权限、用户权限（用户管理和角色管理）外，其他均有权限
senior tester--高级测试人员：拥有测试用例管理、测试计划管理权限和需求和关键字查看权限
tester--测试人员：仅用户测试计划执行和查看权限
guest--匿名用户：只有查看权限
test disnger--测试设计人员：编辑和查看测试用例的权限，关键字管理权限。
testlink的默认角色基本按照职能进行划分，首先是拥有最高权限的管理员。 然后是项目负责人，拥有对整个项目所有测试相关的权限；接着是高级测试人员，可以管理测试用例，编写测试计划等； 下一个普通的测试人员，按照测试计划，执行测试用例； 还有一个测试设置人员，可以创建和编辑测试用例。
这样的角色和权限基本与实际工作中的情况一致，但个人觉得测试用例设计的角色不太实用，接触的公司基本都没有单独设计这样的人员。 一般情况下，测试用例编写者也是测试执行者，同时也是测试计划编写者。
当然，testlink的各个角色的权限可以自定义设置，用户可以按照公司实际的情况设置角色和权限。
17.使用管理员权限创建项目
创建项目：点击测试项目管理—点击新建项目
系统为TestLink 创建了一个默认的管理员账号，用户名/密码为admin/admin。可以使用这个账号访问TestLink，如果是第一次访问，访问后TestLink会要求您创建一个新的测试项目，只有在创建了测试项目之后，页面上才会出现功能栏。
18.掌握软件缺陷管理基本流程
1.一种抽象的模型，用于定义软件测试的流程和方法。
2. 测试过程的质量，将直接影响测试结果的准确性和有效性。
3. 遵循基本原理，测试过程遵循软件工程原理，遵循管理学原理。
19．熟练使用mantis，录入缺陷并设置缺陷的问题等级、优先级等要素，清晰填写问题描述及重现步骤
1.创建项目
2可以添加分类，设置、修改版本信息、自定义字段
3.创建2 个用户账号和密码，测试人员（即报告员）和开发人员
a.创建好这两个用户之后，使用测试人员登陆mantis，发现了stock 的缺陷问题，进行提交
b.使用开发人员登陆mantis，将缺陷状态修改为已确认（不用进行缺陷复现）
c.使用administrator 登录mantis，将缺陷分配给卡发人员
d.使用开发人员登陆mantis，将缺陷状态修改为已解决
e.使用测试人员登陆mantis，对bug 进行验证
f.使用administrator 登录mantis，查看缺陷状态，关闭该缺陷
4.用admin 登录mantis，导出缺陷报告。
20．掌握mantis中各角色职责
测试人员：发现，提出问题；
开发人员：确认，修改问题；
管理员（经理）：确认，指派，关闭问题
2330
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
