开发模型
一:瀑布模型
优点:开发阶段,各个阶段比较清晰;强调早期计划及需求调查;适合稳定需求的的产品开发
改良:每个阶段都可以融入小的迭代工作
二:快递原型模型
实现一个基本原则,让用户对原型进行评价,逐步调整,使其满足用户最终需求
优点:适合不能确定需求的软件
缺点:不适合开发大型系统
测试模型
一: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的“版本库浏览器”,随意拖拽文件的位置即可实现文件的移动效果;注意:如果是在服务器的版本库浏览器设置,直接可以实现一个默认的提交,如果不是在服务器的版本浏览器设置,就必须回到上级目录点击提交才可以
更新至版本:右键-更新至版本-显示日志-找到想要的版本,点击确定即可