说明:该篇博客是博主一字一码编写的,实属不易,请尊重原创,谢谢大家!
接着上一篇博客继续往下写 :https://blog.csdn.net/qq_41782425/article/details/103496007
文章目录
- 一、 软件测试的原则
- 1.所有的测试都应追溯到用户需求
- 2.尽早启动测试工作
- 3.早做测试计划
- 4.穷尽测试不可能 & 软件测试有风险
- 5.测试工作的 Good-enough 原则
- 6.Pareto 法则应用于软件测试
- 7.尽可能使用分阶段测试
- 8.为了达到最佳效果,应该由独立的第三方来构造测试
- 9.测试旨在发现存在的缺陷
- 10.为了保证测试的有效性和高效性,测试必须是破坏性、系统化的
- 11.找到的软件缺陷越多,说明软件隐含的缺陷越多
- 12.杀虫剂怪事
- 13.并非所有软件缺陷都要修复
- 14.使用木桶原理
- 15.前进两步,后退一步
- 16.软件测试是一个迭代的过程
- 17.测试需要遵循标准
- 18.其他的一些测试理念
- 二、软件测试行业概述
- 三、 软件测试工程师的要求
一、 软件测试的原则
1.所有的测试都应追溯到用户需求
1.1 缺陷的源头
- 根据相关调查,软件缺陷出现最多的地方是软件需求规格说明书(即软件需求定义),而不是程序代码。
1.2 如何应用此原则
- 测试第一个任务是需求分析
- 测试需求分析要做好
- 时刻都要提醒自己考虑用户需求
- 制造缺陷的罪魁祸首不是程序员
- 做好需求评审
√ 审查所做的内容是否符合用户的需求
2.尽早启动测试工作
2.1 缺陷雪崩
2.2 测试的成本
2.3 如何应用此原则
- 测试应该早进行。
- 测试应该是与软件开发或维护工作并行进行的一个过程,测试应该持续进行。
3.早做测试计划
- 软件测试不仅仅是测试执行。
- 应该在测试工作真正开始前的较长时间内就进行测试计划。
4.穷尽测试不可能 & 软件测试有风险
- 完全测试、完美测试、充分测试。
4.1 无法穷尽测试的主要原因
- 测试数据输入量太大、时间不够等。
4.2 如何应用此原则
- 如果决定不去测试所有的情况,那么我们就面临了很大的风险。
- 如果时间不够,无法进行充分的测试怎么办?
✰ 使用风险分析,确定测试的重点和优先级,控制测试的开销(时间、成本、资源)。
✰ 风险分析需要判断技能、常识、感觉和经验。
5.测试工作的 Good-enough 原则
5.1 含义
- 既不要做过多测试,也不做不充分的测试。
5.2 如何应用此原则
- 解决办法是通过需求分析和风险分析(时间、费用、资源)找到测试重点,制定最低测试通过标准和测试内容,然后具体问题具体分析。
6.Pareto 法则应用于软件测试
6.1 含义
- Pareto(帕累托)法则由意大利经济学家帕累托提出,又称为 28 效率法则。
√ 一般情况下 80%的缺陷聚集在 20%的关键核心业务模块中。
√ 在分析、设计、实现阶段的复审和测试工作能够发现和避免 80%的缺陷,而系统测试又能找出其余缺陷中的 80%,最后的 4%的缺陷可能只有在用户的大范围、长时间使用后才会曝露出来。
6.2 如何应用此原则
- 做好测试需求分析和测试计划,分清测试重点。
- 尽早测试。
- 持续测试。
7.尽可能使用分阶段测试
- 单元测试→集成测试→系统测试→验收测试
√ 代码规模不断加大
8.为了达到最佳效果,应该由独立的第三方来构造测试
- “最佳效果”指最有可能发现错误的测试。
√ 程序员从来都不会承认自己写的程序有错误。
√ 程序员测试自己的编码是一件很糟糕的事,但是让他们测试别人的编码却成了最好的测试人员。
√ 程序员的测试思路有明显的局限性。
√ 多数程序员没有经过严格正规的职业训练。
√ 程序员无良好的 BUG 跟踪和回归测试习惯。
9.测试旨在发现存在的缺陷
- 软件测试可以报告软件缺陷存在,却不能报告软件缺陷不存在;
- 既使在测试过程未发现软件的失效,也不能证明被测软件没有错误。
10.为了保证测试的有效性和高效性,测试必须是破坏性、系统化的
- 充分、有效、系统的测试可以减少软件中未被发现缺陷的可能性;
- 测试既要验证软件的正确性,更要通过破坏软件,发现缺陷的不正确性。
11.找到的软件缺陷越多,说明软件隐含的缺陷越多
- 缺陷具有群集效应。
√ 应该在发现缺陷的地方继续找找。
12.杀虫剂怪事
- 用于描述软件测试越多,其对测试的免疫力越强的现象。
- 程序员对测试人员的“惯用伎俩”已经可以主动躲避了!
√ 为了克服杀虫剂怪事,软件测试员必须不断编写不同的、新的测试程序,对程序的不同部分进行测试,以找出更多软件缺陷。
13.并非所有软件缺陷都要修复
- 没有足够的时间;
- 不算真正的软件缺陷;
- 修复的风险太大;
- 不值得修复。
14.使用木桶原理
- 木桶原理在软件产品生产方面就是全面质量管理(QTM)的概念。
- 团队合作。
15.前进两步,后退一步
- 测试中的一个基本问题是——缺陷修复总会以(20-50)%的机率引入新的缺陷。
- 每次修复之后,必须做确认测试和回归测试。
√ 再测试/确认测试
✰ 测试人员提交缺陷,开发人员修复缺陷以后,测试人员需要重新测试,验证之前的提交的缺陷是否真正修复。
√ 回归测试
✰ 测试人员提交缺陷,开发人员修复缺陷以后,测试人员需要重新测试,确保对程序修改改没有给软件其他未改变部分带来新的缺陷。软件修改或者环境变更后,必须进行回归测试。
16.软件测试是一个迭代的过程
- 无论项目采用何种开发模型,测试人员总是一个版本接一个版本地测试,其测试活动总是迭代向前的
√ 测试版本 1->提交缺陷->修复缺陷->测试版本 2->提交新缺陷->修复新缺陷->测试版本 3->…
17.测试需要遵循标准
17.1 什么是标准
- 你家的某个电器或家具脱落了一个螺丝钉,你可能会很随意地到街市买一个回家安上,这说明什么——制造业的标准在起作用。家用电器是依据标准制造的,所以随之而来的各种标准配件也会很容易找到。
17.2 标准的分类
- 国际标准:如 ISO、CMM(Capability Maturity Model,软件能力成熟度模型)、
- IEEE(国际电气电子工程师协会)
- 国家标准:GB、GB/T
- 行业标准
- 公司标准
- 用户规定
17.3 案例
- 测试 5 层居民楼的电梯
- 1+0.1=?
18.其他的一些测试理念
- 思路决定测试
- 具体问题具体分析
- 无责任心不成测试
- 测试不能靠猜测
二、软件测试行业概述
1.乐趣
- 破坏程序纯粹的快乐
- 破坏行为具有价值
- 体现出魔术般的力量
- 学习的乐趣
2.烦恼
- 必须追求完美
- 由他人来设定目标,供给资源,提供信息
- 测试往往是线性收敛
- 投入了大量辛苦,用户发现的致命缺陷将否定全部工作
3.第三方测试
- 是指独立于软件公司自身测试的测试,所谓的第三方是指在软件公司和软件用户之间的另一方。
4.机遇
- 微软公司的测试
- 国内的测试
- 在认识上重开发、轻测试;
- 在管理上随意、简单,没有建立有效、规范的软件测试管理和评判体系;
- 缺少自动化工具的支持。
三、 软件测试工程师的要求
1.行业知识与软件测试
- 高效的测试团队应该由具备各种专门技术的成员(具备行业知识、专业技能、测试技术等)组成,同时也应该由具备各种经验的成员(测试新手和测试专家)组成。
√ 目前被测软件正在变的多元化,各个行业的软件都有可能会碰到,如何判断需求是否已经包含所有可能的细节?
√ 如何高效准确的进行测试,在最短的时间内确定问题的所在?
2.优秀的软件测试工程师品质
- 态度
√ 有责任心
√ 破坏的态度
√ 对事不对人 - 三心二意
√ 细心、信心、耐心
√ 团队合作的沟通意识、时刻保持怀疑的态度(即缺陷预防意识) - 具备一定的开发技能
√ 了解开发原理
√ 便于与开发沟通
√ 习惯打破砂锅问到底(善于思考)
3.改善测试员和其他小组成员之间的沟通和相互关系的方法
- 以合作而不是争斗的方式开始项目
√ 时时提醒项目的每位成员:共同目标是追求高质量的产品。 - 对产品中发现的问题以中性的和以事实为依据的方式来沟通
√ 不要指责引入这个问题的小组成员或个人。比如,客观而实际地编写缺陷报告和评审发现的问题。 - 换位思考
√ 尽量理解其他成员的感受,以及他们为什么会有这种反应。 - 有效沟通
√ 开发与测试具有不同的思维方式,确信其他成员已经理解你的描述,反之亦然。 - 提高开发技能