开发模型
一：瀑布模型
优点：开发阶段，各个阶段比较清晰；强调早期计划及需求调查；适合稳定需求的的产品开发
改良：每个阶段都可以融入小的迭代工作
二：快递原型模型
实现一个基本原则，让用户对原型进行评价，逐步调整，使其满足用户最终需求
优点：适合不能确定需求的软件
缺点：不适合开发大型系统
测试模型
一：V模型
步骤：需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试
1：单元测试：又称模块测试，针对单一的程序模块进行测试
2：集成测试：又叫组装测试，在单元测试的基础上，对所有模块进行测试
3：验收测试
（1）内测版(alpha)，内部交流版本，可能存在很多bug，不建议用户安装
（2）公测版(beta)，面向所有用户，通过用户的反馈再去修改细节
（3）候选版(gamma)与正式软件相差无几
优点：包含了底层测试（单元测试）和高层测试（系统测试）；清楚的标识了开发和测试的各个阶段；自上而下逐步求精，每个阶段分工明确，便于整体项目的把控；
缺点：自上而下的顺序导致了，测试工作在编码之后，就导致错误不能及时的进行修改，在实际工作中，需求经变化，导致v模型步骤反复执行返工量很大，灵活度较低
改良：每个步骤都可以进行小的迭代工作
二：W模型
定义：开发一个v，测试一个v组合起来的模型（w模型也叫双v模型）
优点：开发伴随着整个开发周期，需求和设计同样要测试；更早的介入测试，可以发现初期的缺陷，修复成本低；分阶段工作，方便项目整体管理
缺点：开发和测试依然是线性的关系，需求的变更和调整，依然不方便，如果没有文档根本无法执行W模型，对于项目组成员的技术要求更高！
三、H模型（了解）
总结：v模型适用于中小型企业，w模型适用于中大型企业（因为人员要求高），h模型人员要求非常高，很少有公式使用
等价类划分法
属于黑盒测试，它将不能穷举的测试过程进行分类，从而保证完整性和代表性
思考步骤：
1.确定有效等价类和无效等价类
2.有效等价类划分（题目条件，还要注意边界值（极值），中间再随意找个值）
3.无效等价类划分（跟有效等价类相反，其他特殊情况（中文、英文、特殊符号、空格空））
注：有效是说测试结果预期是正确的，无效是说明测结果预期是错误的
等价类细节
1：考虑输入长度
2：考虑输入类型
3：组成规则
4：是否为空
5：是否区分大小写
6：是否重复
7：是否去除空格
边界值
在测试过程中，一定要小心边界值（极值），因为在程序中这些便捷，最容易出问题
具体测试用例书写思路，找到边界值和它两端的值，分表进行测试
总结：边界值思想应该选到边界和刚超过的值来进行测试，也要根据实际情况来选择；边界值和等价类是相辅想成的关系，配合使用
的
因果图
因：输入条件
过：输出条件
适用于输入条件之间有相互制约、相互依赖的情况
因果图中的符号
1：恒等---有因就有果，没有因就没有果
2：非---有因没有果，没有因有果
3：或---条件有一个是真，结果就是真，条件都是假，结果都是假
4：且（与）---条件都为真，结果才是真，一个条件为假，结果就是假
判定表
根据因果图来制定判定表（因果图可以不画）
组成部分：
1：条件桩（所有条件）
2：动作桩（所有结果）
3：条件项（针对条件桩的取值）
4：动作项（针对动作）
书写步骤：
1：列出所有条件和动作桩
2：填写条件和动作桩中的项目
3：简化判定表
注：如果出现“-”，代表此选项不影响最终结果
场景法
主要用来测试业务流程：分为基本流（正确流程）和备选流（错误流程）
注：还要补充一些异常情况
在冒烟测试中主要采用场景法来测试
流程分析法
适用于有先后顺序的测试：常用于业务流程，安装流程等等，每个流程就是一条测试用例，它只是在测试整体流程是否正确，细节还需要使用等价类、边界值等方法进行完善
错误推断法
凭直觉和经验来设计测试用例，是根据之前项目相关的bug数据总结来的
正交表
从全面试验中挑选出有代表性的点进行测试（均匀分散，整齐可比）；高效率，快递，经济的方法
正交表使用方法
1：根据控件和取值数选择一个合适的正交表
2：列举取值并编号，生成取值表
3：把取值表与选择的正交表进行映射
例：测试小程序，里面有五个选项需要选择，选项类目就是叫控件，而映射表的意思就是，每个控件的值的代表数字，在正交表中都是用数字来填写，不会写中文，然而映射表的内容就是这些数字的代表意思
L9（34）：有4个控件，每个控件有3个取值，9为需要测试的组合个数，叫4因素3水平
混合正交表工具
在实际工作中，很多情况都是因素和水平不同，我们在现成的正交表中找不到对应的表格，此时我们就需要使用混合正交表工具来生成混合正交表，allpairs工具是上课时老师提到的工具
使用步骤
1：制作取值表（不需要编号，列出数据即可）
例如：
| 体型 | 年龄端 | 性别 |
| 瘦 | 老年 |
男 |
| 适中 | 青年 | 女 |
| 胖 | 儿童 |
2：复制表格中的数据放在一个新建的txt文本文档中，保存到allpairs文件夹中（例如：txt2.txt），只复制数据，其他格式不改，保存就好
3：win+r再输入cmd进入控制台界面
4：使用控制台代码进入allpairs文件夹中（例如：e：回车 cd复制文件夹路径回车）
5：再输入allpairs.exe test2.txt >chenggong.txt；就会生成一个chenggong.txt的混合正交表 (test2.txt是我们刚新建的文件，chenggong.txt是我们最终生成的混合正交表)
测试用例方法的选择
1：如果测试功能和流程，要使用场景法
2：需要输入数据的地方，我们要使用等价类划分法，要注意配合边界值法来做详细测试
3：如果有条件组合的情况，我们要使用因果图制作出判定表
4：配置类软件，组合比较多的，我们要使用正交表来科学的选择测试用例
5：如果没有达到覆盖标准，就要增加一些测试用例
6：依靠经验追加一些测试用例（错误推断法）
软件缺陷
定义：缺陷就是软件的问题，最终表现为没有满足客户的需求
那些属于软件缺陷
1：用户未达到规格说明书表明的功能
2：软件出现了规格说明书中指明不会出现的错误
3：软件功能超出了规格说明书指明的范围
4：软件为达到规格说明书虽未指明但应该达到的目标
5：软件测试人员或用户觉得不好
缺陷的表现形式
1：功能、特性没有实现 或者部分实现
2：设计不合理、功能不明确、逻辑不清楚或存在矛盾
3：实际结果和期望结果不同
4：没有达到规格说明书要求的性能指标
5：运行出错、崩溃、中断和界面混乱
6：数据不正确、精度不够、不完全或格式不统一
7：用户不能接受的其他问题，如存取时间过长，界面不美观
8：硬件或软件存在其他问题
缺陷的状态
1：提交---测试人员提交了一个缺陷给程序员
2：打开---待处理
3：拒绝---程序员认为不是缺陷或者重复，就可以修改状态为拒绝
4：修复---程序员修复缺陷后提交的一个状态
5：关闭---测速人员经过回归测试后，认为此缺陷已经解决，将其关闭
6：推迟---可以放在后续版本解决的问题，但是要详细写出修复的日期或版本
软件缺陷的严重程度划分
1：low---表面性错误，如错别字
2：medium---影响一个相对独立功能、仅仅发生再特定条件上，与需求定义不一致、断断续续出问题
3：High---功能点没有实现、不符合用户需求、导致数据丢失
4：VeryHigh---频繁死机、大部分功能不能使用
5：Critical---系统瘫痪、异常退出、死循环、严重的计算错误
软件测试的优先级
1：low---时间和资源运行的情况下修复
2：medium---不会延迟发布，会在以后修复
3：High---会制约开发和测试的进行、需要在发布之前修复
4：VeryHigh---影响系统、产生严重影响
5：Critical---导致系统几乎不可用
软件缺陷的分类
1：系统缺陷
2：数据缺陷
3：数据库缺陷
4：接口缺陷
5：功能缺陷
6：安全性缺陷
7：兼容性缺陷
8：性能缺陷
9：界面缺陷
10：简易
缺陷报告注意事项
1：尽量保证缺陷可以重现
2：简洁、准确、完整
3：一个缺陷报告只写一个缺陷
缺陷书写规范
1：标题简洁、提供缺陷的本质信息即可
2：复现的步骤要详细，用数字编号
3：实际结果要描述清楚复现后的结果
4：列出期望结果
5：提供附件
6：提供严重性属性和其他公司需要填写的属性
注意：要避免一些常见错误
（1）避免使用情绪化语言和强调标点符号
（2）避免使用模糊的词语
（3）避免使用自认为幽默的语言，直接描述问题即可
（4）避免提交不确定的缺陷
缺陷的跟踪
新提交的缺陷为“新建”状态，在确认有效之后变为“打开”，开发人员修改后变为“已修复”状态，此时测试人员需要回归测试，如果验证问题已解决，状态为“已修复”，如果问题依然存在，状态为“打开”；如果开发人员认为此缺陷可以延期修改，状态为“延期”；注意此时必须由项目相关人员讨论确定后才可以延期处理，否则状态继续为“打开”
缺陷密度
每千行代码的缺陷数
缺陷密度=1000*缺陷个数/代码行数
svn基本操作
添加文件：找到随便一个手svn空值的文件夹，在里面放你的文件，然后在这个受控制的文件上右键，提交即可实现
删除文件：右键选择文件，点击删除（是tsvn的删除按钮），必须返回上级文件夹右键-提交
改名：右键选择改名
文件移动：找到tsvn的“版本库浏览器”，随意拖拽文件的位置即可实现文件的移动效果；注意：如果是在服务器的版本库浏览器设置，直接可以实现一个默认的提交，如果不是在服务器的版本浏览器设置，就必须回到上级目录点击提交才可以
更新至版本：右键-更新至版本-显示日志-找到想要的版本，点击确定即可