第一部分 软件测试综述

软件工程专业<<软件测试>>第一部分 软件测试综述读书笔记思维导图。

第一部分 软件测试综述

软件测试背景

臭名昭著的软件错误用例研究

软件缺陷是什么

软件失败的术语

缺点-defact 偏差-variance 故障-fault 失败-failure 问题-problem 矛盾-inconsistency 错误-error 特殊-feature 事件-incident 缺陷-bug 异常-anomaly

异常报告Product Anomaly Reports PARs

产品事件报告Product Incident Reports PIRs

软件缺陷的官方定义

只要至少满足5个之一称为软件缺陷(Software bug)

软件未实现产品说明书要求的功能

软件出现了产品说明书指明不应该出现的错误

软件实现了产品说明书未提到的功能

软件未实现产品说明书虽未明确提及但应该实现的目标

软件难以理解、不易使用、运行缓慢或者-从测试员的角度看-最终用户会认为不好

为什么会出现软件缺陷

软件缺陷的修复费用

软件测试员究竟做些什么

软件测试员的目标:尽可能早的找出软件缺陷，并确保缺陷得以修复。

优秀的软件测试员应具备的素质

他们是群探索者

他们是故障排除员

他们不放过任何蛛丝马迹

他们具有创造性

他们是群追求完美者

他们判断准备

他们注重策略和外交

他们善于说服

小结

软件发开过程

产品的组成

软件产品需要多少投入

客户需求

产品说明书

进度表

目的:了解哪项工作完成了，还有多少工作要做，何时全部完成

软件设计文档

结构文档

描述软件整体设计的文档

数据流图

数据在程序中如何流动的正规示意图

状态转化图

把软件分解为基本状态或者条件的另一种正规示意图，表示不同转台间转换的方式

流程图

描述程序逻辑的传统方式

代码注释

测试文档

测试计划(test plan)

描述用于验证软件是否符合产品说明书和客户需求的整体方案。包括质量目标、资源需求、进度表、任务分配、方法等。

测试用例(test cases)

例举测试的项目，描述验证软件的详细步骤

缺陷报告(bug reports)

描述执行测试用例找出的问题。可以记录在纸上，但通常记录在数据库中

测试工具和自动测试(test tools and automation)

度量、统计和总结(metrics,statrics,summaries)

测试过程的汇总。采用图形、表格和报告等形式

软件产品由那些部分组成

软件测试员检查:帮助文件 用户手册 样本和示例 标签和不干胶 产品支持信息 图标和标志 错误信息 广告和宣传材料 安装 说明文件

软件项目成员

项目经理、程序经理或者监制人员及其职责

自始至终驱动整个项目。通常负责编写产品说明书、管理进度、进行重大决策。

体系架构师或者系统工程师

是产品小组中的技术专家。一般经验丰富，可以胜任设计整个系统的体系架构或软件。

程序员、开发人员或者代码制作者设计、编写软件并修复软件中的缺陷

与项目经理和设计师密切合作制作软件，然后与项目经理和测试员密切合作修护缺陷。

测试员或质量保证(Quality Assurance,QA)员

负责找出并报告发现的问题。

技术作者、用户协助专员、用户培训专员、手册编写员或者文案专员

编制软件产品附带的文件和联机文档.

配置管理员或构建员

负责把程序员编写的代码及技术作者写的全部文档资料组合在一起，合成一个软件包。

软件开发生命周期模式

定义:从最初构想到公开发行的过程

大瀑布模式

图片

优点:简单，计划、进度安排和正规开发过程几乎没有，所以精力都花在开发软件和编写代码上。

多数情况下，大爆炸模式几乎没有什么测试。

边写边改模式

图片

定义:项目小组在未刻意采用其他开发模式时默认的开发模式

步骤:典型的非正规说明书->编码、修改，反复直到?->最终产品

适合意在快速制作而且用完就扔的小项目

瀑布模式

图片

定义:采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每个步骤结束时项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来直到准备好。

步骤:构思->分析->设计->开发->测试->最终产品

强调三点

瀑布模式非常强调产品的定义。注意，开发或者代码编制阶段只是其中单独的一块

瀑布模式各步骤是分立的、没有交叉。

瀑布模式无法回溯。一旦进入某一步骤，就要完成该步骤的任务，然后才能向下继续-无法回溯。

优点

编写代码之前解决所有的未知问题并明确所以细节

所有一切都有完整细致的说明。测试小组得以制定精确的计划和进度。测试对象非常明确。

缺点

在这个迅速变化、在互联网上开发产品的时代，当软件产品还在细细考虑和定义时，当初制造它的理由都可能会变。

因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现。

螺旋模式

图片

定义;总体思想:一开始不必详细定义所以细节。从小开始，定义重要功能，努力实现这些功能，接受客户反馈，然后进入下一阶段。重复上述过程，直到得到最终产品。

步骤:明确目标、可选方案和限制条件->明确并化解分享->评估可选方案->当前阶段开发和测试->计划下一阶段->确定进入下一阶段的方法

总结

软件测试的实质

测试的原则

完美测试程序是不可能的

输入量太大

输出结果太多

软件执行路径太多

软件说明书是主观的可以说从旁观者来看是缺陷

完全测试一个程序是不可能的

软件测试是有风险的行为

图片

子主题

如果试图测试所有情况，费用将大幅增加，而软件缺陷漏掉的数量在到达某一点后没有显著变化

如果减少测试或者错误的确定测试对象1，虽然费用很低，但会漏掉大量软件缺陷

图3-2说明:测试量和发现的软件缺陷数量之间的关系。

我们的目标:找到最优的测试量，使测试不多不少

如何设计和选择测试用例以减少风险，优化测试的技术。后面章节介绍

测试无法显示潜伏的软件缺陷

可以报告软件缺陷存在，却不能报告软件缺陷不存在

可以进行测试，发现并报告软件缺陷，但是任何情况下都不能保证软件缺陷没有了

唯一的方法是继续测试，可能还会找到一些

找到的软件缺陷越多，就说明软件缺陷越多

程序员也有心情不好的时候

程序员往往犯同样的错误

某些软件缺陷实乃冰山一角

杀虫剂怪事

用于描述软件测试越多，其对测试的免疫力越强的现象。

例如农药杀虫，老用一种药，害虫最后就有了抵抗力，农药再也发挥不了效力

为了克服杀虫剂怪事，软件测试员必须不断编写不同的、新的测试程序，对程序的不同部分进行测试，以找出更多软件缺陷。

并非所以软件缺陷都要修复

不需要修复软件缺陷的原因

没有足够的时间

不算真正的软件缺陷

修复的风险太大

不值得修复

什么时候才叫缺陷难以说清

产品说明书从没有最终版本

产品说明书变化的原因

整个行业变化太快，去年还很先进的产品今年就已过时

软件变得更庞大、更复杂，功能越来越多，导致软件开发周期越来越长

解决方案

进行产品开发过程中，重新讨论产品功能，重写产品说明书，开发经过修订的产品

软件测试员必须想到产品说明书肯改变。未曾计划测试的功能会增加，经过测试并报告软件缺陷的功能可能发生变化甚至被删除。这些都有可能会发生。

软件测试员在产品小组中不受欢迎

保持小组成员和睦的建议

早点找出缺陷

控制情绪

不要总是报告坏消息

软件测试是一项讲究条理的技术专业

大多数软件都采用井然有序的方式开发，并把软件测试员当作必不可少的核心小组成员。

现在软件测试成为一个职业选择-需要训练和规范，而且有发展空间。

软件测试的术语和定义

精确的准确

图片

软件测试要精度还是准度很大程度上取决于产品使什么，最终取决于开发小组的目标（请诉直言）

确认和验证

确认:保证软件符合产品说明书

验证:保证软件满足用户要求的过程

确认说明书并对最终产品进行验证

质量和可靠性

质量:软件功能的多少、在自己的旧PC上运行的能力、软件公司的服务

可靠性：质量和产品多长时间崩溃的问题

为了确保程序质量高而且可靠性强，软件测试员必须在整个产品开发过程中进行确认和验证。

测试和质量保证(QA)

软件测试员的目标:尽可能早的找出软件缺陷，并确保缺陷得以修复。

软件质量保证人员的主要职责:创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法。

后面介绍“软件质量保证”

子主题

总结

软件测试总结 2019年4月4日完成