一、 软件测试的原则
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. 测试需要遵循标准
- 测试 5 层居民楼的电梯
- 1+0.1=?
需要了解不同行业的标准
18. 其他的一些测试理念
- 思路决定测试
- 具体问题具体分析
- 无责任心不成测试
- 测试不能靠猜测
二、 软件测试行业概述
1. 乐趣
- 破坏程序纯粹的快乐
- 破坏行为具有价值
- 体现出魔术般的力量
- 学习的乐趣
2. 烦恼
- 必须追求完美
- 由他人来设定目标,供给资源,提供信息
- 测试往往是线性收敛
- 投入了大量辛苦,用户发现的致命缺陷将否定全部工作
3. 第三方测试
- 是指独立于软件公司自身测试的测试,所谓的第三方是指在软件公司和软件用户之 间的另一方。
4. 机遇
- 微软公司的测试
- 国内的测试
- 在认识上重开发、轻测试;
- 在管理上随意、简单,没有建立有效、规范的软件测试管理和评判体系;
- 缺少自动化工具的支持。
三、 软件测试工程师的要求
1. 行业知识与软件测试
- 高效的测试团队应该由具备各种专门技术的成员(具备行业知识、专业技能、测试 技术等)组成,同时也应该由具备各种经验的成员(测试新手和测试专家)组成。
- 目前被测软件正在变的多元化,各个行业的软件都有可能会碰到,如何判断需 求是否已经包含所有可能的细节?
- 如何高效准确的进行测试,在最短的时间内确定问题的所在?
2. 优秀的软件测试工程师品质
- 态度
- 有责任心
- 破坏的态度
- 对事不对人
- 三心二意
- 细心、信心、耐心
- 团队合作的沟通意识、时刻保持怀疑的态度(即缺陷预防意识)
- 具备一定的开发技能
- 了解开发原理
- 便于与开发沟通
- 习惯打破砂锅问到底(善于思考)
3. 改善测试员和其他小组成员之间的沟通和相互关系的方法
- 以合作而不是争斗的方式开始项目
- 时时提醒项目的每位成员:共同目标是追求高质量的产品。
- 对产品中发现的问题以中性的和以事实为依据的方式来沟通
- 不要指责引入这个问题的小组成员或个人。比如,客观而实际地编写缺陷报告 和评审发现的问题。
- 换位思考
- 尽量理解其他成员的感受,以及他们为什么会有这种反应。
- 有效沟通
- 开发与测试具有不同的思维方式,确信其他成员已经理解你的描述,反之亦然。
- 提高开发技能