目录
1.知识总结
2.实训问题反馈
3.学习规划
1.知识总结
软件工程要点
1.软件生命周期：定义 设计 实施 测试 部署 运行 维护
2.模型：①瀑布模型
计划 需求分析 设计 编码 测试 运行维护
②“V”模型
需求分析 验收测试
概要设计 系统测试
详细设计 集成测试
编码 单元测试
③ 迭代模型
3. “C/S”结构： 客户机 服务器结构
“B/S”结构： 浏览器 服务器结构
Web应用三层架构模式：用户界面表现层 业务逻辑层 数据访问层
二章 软件测试基础
1.软件测试的原则：①测试显示缺陷的存在
②穷尽测试是不可能的
③测试应尽早介入
④80-20原则
⑤杀虫剂悖论
⑥测试用例依赖于测试背景
⑦“不存在缺陷就是有用系统”的悖论
2.软件测试目的：发现缺陷，提高质量 验证用户需要 建立软件质量的信心
三章 基于生命周期的软件测试
生命周期各个阶段的测试：1需求阶段测试
2设计阶段测试
3编码阶段测试
4测试阶段测试
5安装阶段测试
6验收阶段测试
7维护阶段测试
软件测试的分类和分级
² CSCI（软件配置项）：在软件开发过程中，产生的所有信息构成软件配置。代码、文档、报告等都成为配置项。
² WBS(工作分解结构)：分单元写测试需求，测试用例根据需求产生。
² 基线（重要阶段节点）：到达某一阶段结束点时已经经过正式审核和同意软件成分的技术状态。
² 软件测试分类 1. 是否关心内部结构：黑盒测试 白盒测试 灰盒测试
2. 开发过程级别：单元测试 基层测试系统测试 验收测试
3.是否执行程序：静态测试 动态测试
4.执行是否需要人工参与：自动化测试 手工测试
5.测试实施组织：开发测试 用户测试 第三方测试
软件缺陷管理
² 软件缺陷定义规则
1软件未实现产品说明书要求的功能
2软件出现了产品说明书指明不应该出现的结果
3软件实现了产品说明书未提到的功能
4软件为实现产品说明书虽未明确提及但应该实现的目标
5软件难以理解、不易使用、运行缓慢——从测试员的角度看——最终用户认为不好
² 软件缺陷报告
缺陷属性 缺陷ID 标题 报告人 报告日期 程序名称 版本号 配置 缺陷类型 严重性 优先级 关键词 缺陷描述重现步骤结果对比
² 软件缺陷管理一般流程
六章 软件测试过程及测试过程管理
² 软件测试过程模型
“V”模型：不同测试阶段和开发过程期间各阶段的对应关系
“W”模型：增加了软件各开发阶段中应同步进行的验证和确认活动。 基于尽早的和不断进行测试的原则
“H”模型
² 软件测试过程的关键活动
提取测试需求 制定测试计划 制定测试策略和方案 开展测试设计 执行测试用例 分析测试结果。
² 软件测试一般流程
七章 软件静态测试
² 静态测试的概念、特点：
概念：指不执行代码程序而寻找代码中可能存在的错误或评估错误代码的过程。
特点：（1）不必动态地运行程序。（2）可以人工进行，充分发挥人的思维优势。（3）不需要特别的条件，容易展开。（4）对测试人员要求比较高。
² 同行评审
包括审查、小组评审、走查、桌面评审、临时评审
² 圈复杂度计算：
1. 圈复杂度等于程序图中判定节点的数目加1；
2. 圈复杂度等于强连通程序图在平面上围成的区域的个数。
动态测试
² 白盒测试：
1.概念：“白盒”测试又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。
2.特点：可以构成测试数据使特定程序部分得到测试
有一定的充分性度量手段
可获得较多工具支持
通常只用于单元测试
3.基本测试内容：1对程序模块的所有独立执行路径至少测试一次
2对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次
3在循环的边界和运行的边界限内执行循环体
4测试内部数据结构的有效性
4.逻辑覆盖：
1语句覆盖
1)语句覆盖是最起码的测试要求，使得每一条语句至少被执行一次
2)对程序的逻辑覆盖很少，只关心判定表达式的值，是很弱的逻辑覆盖标准。
2判定覆盖（分支覆盖）
要求设计足够的测试用例，使得程序中的每一个分支至少通过一次即每一条分支语句的“真”值和“假”值都至少执行一次。
3.条件覆盖
1）每个条件的所有可能取值至少能够获取一次
2）关心的则是每个条件各种取值的结果。
4判定/条件覆盖
1）设计足够多的测试用例，使得判定中每个条件的所有可能取值至少能够获取一次
2）每个判断的所有可能的判定结果至少执行一次
5条件组合覆盖
设计足够多的测试用例，使得每个判定中条件的各种组合至少出现一次。
6路径覆盖
要求设计足够多的测试用例，使得程序中所有的路径都至少执行一次
² 黑盒测试
1.标准
1）测试用例数量为达到合理测试所需要设计的最少数
2)测试用例要能够指明是否存在某些类型的错误，而不是仅仅指出与特定测试有关的错误是否存在
2.等价类划分原则
1）输入条件的取值范围，可以划分出一个有效等价类和两个无效等价类
2）输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，可确立一个有效等价类和一个无效等价类
3）输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类
4）规定了输入数据的一组值(假设N个)，N个有效等价类，一个无效等价类（所有不允许的输入值的集合）
5）规定了输入数据必须遵守的规则，则可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)
6）在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
3边界值划分规则
1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围的边界值作为测试的输入数据。
2）如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为册数数据。
3）根据规格说明的每个输出条件，使用原则 1）
例如：某程序的功能是计算折扣量，最低折扣是0元，最高折扣是1000元。则设计一些测试用例，使他们刚好产生0元和1000元的结果。
4）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
5）分析规格说明，找出其他可能的边界条件。
4因果图
定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系
原因结果的关系
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, 与”也可有任意个输入。
约束条件
A.输入条件的约束有以下4类：
1） E约束（互斥/异）：a和b中至多有一个可能为1，即a和b不能同时为1。
2） I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。
3） O约束（唯一）；a和b必须有一个，且仅有1个为1。
4） R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。
B.输出条件约束类型
输出条件的约束只有M约束（屏蔽/强制）：若结果a是1，则结果b强制为0。
² 测试用例
1.覆盖内容：1）正确性测试 2）容错性(健壮性)测试
3)完整(安全)性测试 4)接口测试
5)数据库测试 6)边界值测试
7)压力测试 8）等价划分测试
9)错误推测 10)效率
11)可理解(操作)性测试 12）可移植性测试
13）回归测试 14）比较测试
2.测试用例编写要素
名称和标识 唯一的索引标识（序列号），用例名称
测试追踪/来源 涉及的参考资料，如用户的需求、涉及文档等
用例说明 测试对象，采用的方法
测试的初始化要求 哪个测试对象？在什么硬件/软件—平台？
测试的输入 输入数据
测试结果 期望测试结果
评价测试结果 精度等
操作过程 测试步骤
前提和约束 约束
测试终止条件 正常终止或异常终止
软件手动测试与自动化测试
² 手工测试和自动化测试在软件测试过程中的具体实施
1）测试策划 2)测试设计 3）测试实施 4）测试执行 5)测试 评估
² 常用自动化测试框架类型
1）测试脚本模块化框架
2）测试库框架
3）数据驱动测试框架
4）关键字驱动或者表驱动的测试框架
5）混合测试自动化框架
² 自动化常用技术
1）脚本技术
2）录制/回放技术
3）基于数据驱动的自动化测试技术
4）关键字驱动的自动化测试技术
5）基于预期结果分析比较技术
2 实训问题反馈
| 序号 | 问题描述 | 解决方法 |
| 1 | 对于白盒测试理解不够全面 | 没文化，多读书 |
| 2 | 对于需求理解还不够全面，测试点会有遗漏 | 练习！练习！再练习!!! |
| 3 | 测试用例写的不好，没有条理，思绪很乱 | 练习！练习！再练习!!! |
| 4 | 圈复杂度没搞清楚 | 没文化，多读书 |
3 学习规划
有时候觉得时间真是一件磨人的东西，有时候感觉它过得很快，大学的前三年如白驹过隙，来也去也，每天反复的过着一样的日子，好像生活没了劲头。来到这里的一个月真的感觉到了自己的变化，像是一个干瘪的气球慢慢的又膨胀起来了，我慢慢又感觉到了以前那股不服输的劲。对于规划，其实我的想法很简单，我只想好好学习，慢慢的让学到的知识变成自己的，拥有20几岁年轻人该有的自信，努力的和谐的生活下去。
最后附上我到基地之后最喜欢的一句话：If you find a path with no obstacles,it probably does not leadanywhere。
722
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
