六、测试人员的必备素质
- 责任心
- 沟通能力
- 团队合作精神
- 耐心、细心、信心
- 时刻保持怀疑的态度，并且有缺陷预防意识
- 具备一定的编程经验
七、软件缺陷
- 什么是缺陷？
1 不符合设计要求。
2 不满足用户确定需求。
- 产生缺陷的原因：
1 人员之间的沟通交流不够，交流上有误解或者根本不进行交流
2 文档不完善
3 需求不断的变化
4 参与人员的过度自信
5 程序设计本身有错误
6 软件复杂性
7 工期短，任务重，时间压力大
8 软件开发工具或系统软硬件自身含有缺陷
- 判断发现的问题是否是缺陷的方法
1 通过参考文档来确认缺陷
2 通过了解软件产品的行业背景（或参考同类典型软件）来发现缺陷
3 通过沟通来确认和识别缺陷
- 再现与优化缺陷
1 再现（又叫重现）
2 优化缺陷不是优化缺陷本身，而是优化重现缺陷的步骤。
3 随机缺陷
怎样有效记录缺陷？
- 保证重现缺陷。
- 写步骤前做一个故障分析—使用最少步骤来复现故障。
- 包含所有重现缺陷的必要步骤。
- 方便阅读即可。
- 尽量简单 —— 即1个缺陷1个报告。
- 交流时注意自己的语气。
- 其他值得注意的经验：
》报告不能重现的缺陷。
》不要夸大缺陷。
》小缺陷（甚至建议）也应该报告。
》引用别人的报告时，不能修改，可以添加批注之类的补充评论。
》 缺陷报告的用途是什么？
记录缺陷
记录分类
缺陷跟踪
-
为什么要尽早的报告缺陷？
1 尽早报告的话记忆相对清晰，报告细节方面会相对完善。
2 尽早报告给开发，有助于项目整体的推进速度。 -
是不是所有的缺陷都会被修复？
不一定，在实际项目中会存在一部分缺陷没有被修复，这是正常的。
从哪些角度给缺陷分类？
- 按问题引出不同
- 按功能（模块）
- 按缺陷的严重程度
》影响进度的问题
》死机
》功能问题
》界面问题
》建议- 按修复缺陷的优先级
》应立即修复的问题
》在产品发布前必须修复的问题
》如果时间允许应该修复的问题
》可以在发布版本中存在的问题
*备注：缺陷的具体严重程度根据公司实际情况来决定。
| 按照缺陷所处的状态分类 | 按处理意见 |
|---|---|
| 待确认的 | 已解决的 |
| 新提交的 | 不是问题 |
| 已分配的 | 无法修复 |
| 问题未解决的 | 延迟解决 |
| 待返测的 | 重复bug |
| 已关闭的 | 无法实现 |
- 缺陷报告的处理流程
- 关于处理缺陷
》 注意缺陷报告的处理成本。
》 修改缺陷要量力而行。
》 关注被推迟修改的缺陷。
（例如当版本未修改留到下版本的缺陷）
》 如果决定据理力争就一定要赢。
八、软件质量
- 经“软件质量”定义：软件质量特性的总和，软件满足规定或潜在用户需求的能力。简单来说，就是客户满意度。
- 软件质量的组成成分：
》 软件产品的质量，即满足使用要求的程度（软件质量特性）
》 软件开发过程的质量，即能否满足开发所需要的成本、时间和风险等等。
软件测试与软件质量
- 软件质量与软件过程的关系
》软件质量：软件产品的特性可以满足用户的功能、性能需求的能力。
》软件过程：软件生命周期中的活动，一般包括软件需求分析、软件设计、软件编码、测试、交付、安装和维护等等。
》过程决定质量，软件过程决定软件质量，软件质量是在软件开发过程中逐渐建立起来的
》软件过程的优劣决定了软件质量的高低，好的过程是高效高质量的前提。人员和过程是决定软件质量的关键因素，高质量的人员和好的过程应该得到好的产品。- 在软件过程中注意把握测试的对象
- 软件测试在软件生存周期中的位置
》软件测试在软件生存周期中占有非常重要的位置，是对软件规格说明、设计和编码的最后终审。（即评审）
*软件质量不是依靠软件测试来保证的，而是靠 不断提高技术水平和改进软件的开发过程来保证。只有不懈改进过程中的问题才是提高软件产品质量的根本出路。
正确认识软件测试
- 软件的质量不是靠测出来的
- 软件测试真的比开发容易么？
》测试人员发现缺陷只是第一步，还要分析定位缺陷；而且测试人员需要发现潜在的难以被发现的缺陷。
》测试人员需要开发测试工具和自动测试脚本
》测试人员必须精通整个业务- 软件测试需要开发与测试人员的共同努力
软件质量特性
》 功能性：软件在制定调价年使用时，满足用户明确和隐含需求的功能的能力
- 适合性：软件是否提供了相应的功能
- 准确性：软件提供的功能是否正确（用户需要的）
- 互操作性：产品与产品之间交互数据的能力，例如word对其他文档的支持能力
- 安全性：允许经过授权的用户和系统能够正常的访问相应的数据和信息，禁止未授权的用户访问等
- 功能性的依从性：软件遵循与功能性相关的标准、约定或发奎以及类似规定的能力。
》 可靠性：软件在制定条件下使用时，维持规定的性能级别的能力。平均故障修复时间（mean time to repair,MTTR）、平均无故障时间（mean time between failures,MTBF）
- 成熟性：软件产品为避免软件内部的错误扩散而导致系统失效的能力（主要是队内错误的隔离），异常等的处理。
- 容错性：软件防止外部接口错误扩散而导致系统失效的能力
*易恢复性：系统失效后，重新恢复原有的功能和性能的能力。- 可靠性的依从性：软件遵循与可靠性相关的标准、约定或法规的能力。
》 易用性：在指定使用条件下，产品被理解、学习、使用和吸引客户的能力
- 易理解性:软件交互给用户的信息时，要清晰、准确且要易懂，使用户能够快速理解软件。
- 易学性：软件使用户能学习其应用的能力。
- 易操作性：软件产品使用户能易于操作和控制它的能力。
- 吸引性：软件吸引用户的能力
- 易用性的依从性：软件遵循与易用性相关的标准、约定、风格指南和法规的能力。
》效率性：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。
- 时间特性：在固定条件下，软件执行其功能时，提供适当的相应和处理时间以及吞吐率的能力，即完成用户的某个功能需要的响应时间。
- 资源利用性：在规定条件下，软件执行其功能时，使用合适的资源数量和类别的能力。如：CPU、内存、磁盘、网络宽带等
- 效率依从性：软件遵循与效率相关的标准或约定的能力
》可维护性：软件可被修改的能力。修改可能包括修正、改进，或软件对环境、需求、功能规格说明变化的适应。
- 易分析性：软件诊断软件中的缺陷、失效原因或识别待修改部分的能力
- 易改变性： 软件产品使制定的修改可以被实现的能力
- 稳定性： 软件避免由于软件修改而造成以外结果的能力
- 易测试性：使已修改软件能被确认的能力
- 维护性的依从性：软件遵循与维护性相关的标准或约定的能力
》可移植性：软件从一种环境迁移到另一种环境的能力。
- 适应性：适应不同平台
- 易安装性：在指定环境中被安装的能力
- 共存性：软件在公共环境中同与其分享公共资源的其他独立软件共存的能力
- 易替换性： 软件产品在同样的环境下，替代另一个用途的软件产品的能力
- 可移植性的依从性：软件遵循与可移植性相关的标准或约定的能力
【2021.01.07补充部分】
》CMM（Capability Maturity Model）：能力成熟度模型，是美国卡耐基梅隆大学，软件研究所（SEI）提出的一种用于评价软件承包商能力并帮助改善软件质量的模型
其精髓在于：过程决定质量
CMM的五个等级：
- 初始级（等级1）：软件过程的特点是无秩序的，偶尔甚至是混乱的。几乎没有什么过程是经过定义的，成功依赖于个人的努力。
- 可重复级（等级2）：已建立基本的项目管理过程去跟踪成本、进度和功能性。必要的过程纪律已经就位，使具有类似应用的项目，能重复以前的成功。
- 已定义级（等级3）：管理活动和工程活动两方面的软件过程均已文档化、标准化、并集成到组织的标准软件过程。全部项目均采用供开发和维护软件的组织标准软件过程中的一个经批准的剪裁本。
- 已管理级（等级4）：已采集详细的有关软件过程和质量的度量。无论软件过程还是产品均得到定量了解和控制。
- 优化级（等级5）：利用来自过程和来自新思想、新技术先导性试验的定量反馈信息、使持续过程改进成为可能。
扫一扫
549
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
