文档状态:编辑....
软件测试员的目标是尽可能尽早找出软件缺陷并确保其得以修复
[修复]: 这是一个用户与产品相互适应的过程,并非说一定要软件开发人员对缺陷部分重新编码,我们也可以通过修改产品说明说或者培训用户使用方法来达到修复目的!
此时对修复理解有误解的可以看一看软件缺陷的定义的五大概念
要搞清软件产品的组成部分,下面写了几个
在软件行业中,用于描述制造出来并交付他人的软件产品组件的术语是可交付部分(deliverable)
解释所有可交付部分的内容的最简便方法就是分门别类
软件产品的一个关键部分就是进度表
常见表格类型[Gantt]
软件设计文档
[结构文档] 主要部分描述以及相互之间的交互
[数据流图] 表示数据在程序中如何流动正规示意图
[状态转换图] 把软件分解为基本状态或者条件的另一种正规示意图
[流程图] 图形描述程序逻辑的传统方式(不常用)
[代码注释] 便于维护
测试文档
[测试计划]
[测试用例]
[缺陷报告] 存在数据库或者写在纸上
[测试工具]/[自动测试] 不管是买的还是自己做的都要有文档
[度量/统计/总结] 测试过程的汇总,illustrate/report/graphic
编写产品说明书管理进度进行重大决策设计整个系统体系架构与程序员关系密切编写代码和修复软件与项目经理和架构师合作开发与项目经理和测试员合作修复软件负责找出并报告软件产品的问题注意测试员与QA的区别编写产品附带文件和联机文档负责组装代码和文档合为软件包注意是开发生命周期
几乎不需要测试员,避免争吵边写边改模式
> 也可以认为是快速原型模式
没有时间做好,总有时间完成
测试和编码人员陷入无尽的迭代直至想发布了
- 瀑布模式
瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行
注重软件定义的精准性
无法回溯
步骤分离没有交加
测试在最后,基本型错误可能最后才发现,软件的修复费用被拉长
从设计到编码,从编码到测试,从测试到提交,要求每一个开发阶段都要做到最好.
过于依赖前期的完美性
- 迭代式开发
迭代式开发也被称作迭代增量式开发或迭代进化式开发,是一种与传统的瀑布式开发相反的软件开发过程,它弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率
[what]每次只设计和实现这个产品的一部分, 逐步逐步完成的方法叫迭代开发
[how] 在迭代式开发方法中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试
[why] 采用这种方法,开发工作可以在需求被完整地确定之前启动,并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求,并开始新一轮的迭代。
迭代式开发的优点:
1、降低风险
2、得到早期用户反馈
3、持续的测试和集成
4、使用变更
5、提高复用性
螺旋模式
看图
[1] 它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统
[2] 螺旋模型”刚开始规模很小,当项目被定义得更好、更稳定时,逐渐展开
[3] “螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵,定义最重要的功能,实现它,然后听取客户的意见,之后再进入到下一个阶段。如此不断轮回重复,直到得到您满意的最终产品
很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估
1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件
2)风险分析:分析评估所选方案,考虑如何识别和消除风险
3)实施工程:实施软件开发和验证
4)客户评估:评价开发工作,提出修正建议,制定下一步计划
- 敏捷开发
人和交互 重于过程和工具。
可以工作的软件 重于求全而完备的文档。
客户协作重于合同谈判。
随时应对变化重于循规蹈矩。
其中位于右边的内容虽然也有其价值,但是左边的内容最为重要。
人员彼此信任 人少但是精干 可以面对面的沟通
项目的敏捷开发:
敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果;
关注业务优先级; 检查与调整。
最重要的因素恐怕是项目的规模。规模增长,面对面的沟通就愈加困难,
因此敏捷方法更适用于较小的队伍,40、30、20、10人或者更少。
大规模的敏捷软件开发尚处于积极研究的领域。