1、软件测试的背景
1、缺陷是什么(缺陷的官方定义)
产品说明书:对开发的产品进行定义,给出产品的细节、如何做、做什么、不做什么。
只有至少满足下列5个规则之一才称发生了一个软件缺陷:
- 软件未实现产品说明书要求的功能
- 软件出现了产品说明书指明不会出现的错误
- 软件实现了产品说明书未提到的功能
- 软件未实现产品说明书虽未明确提出但应该实现的目标
- 软件难以理解,不易使用,运行缓慢或者–从测试员的角度看–最终用户会认为不好
注意:软件测试员在运用第5条测试规则时,要全面,最重要的是要客观评价,并非所有测试发现的缺陷都要修改。
2、缺陷产生的原因
最大原因:产品说明书(说明书–没有写或者不够全面、经常更改、沟通不足);
第二:设计(程序员规划软件的过程–随意、易变、沟通不足);
其次:把本来正确的当成缺陷、测试错误。这类缺陷只占极小的比例,不必担心。
最大原因:需求规格说明书;第二:设计方案;其次:编写代码,其他
1) 需求理解错误,编写过程中引起的错误
2) 需求不断变更:项目失败的最大杀手,会引起重新设计,工程重新安排
3) 开发过程中缺乏有效的沟通,或没有进行沟通:导致设计不正确
4) 编程中产生错误
5) 软件开发工具本身隐藏的问题:选择较为成熟的产品
6) 不重视开发文档
7) 软件复杂度越来越高
8) 项目进度的压力
3、软件测试员的目标
尽可能早地找出软件缺陷、并确保其得以修复。(注意:修复缺陷并非一定要改正软件。可以是指在用户手册中增加一段注释或为用户提供特殊的p)
4、测验
1、在千年虫例子中,dave有错吗?
如果dave是个好的程序员,他应该对这个‘显然的’疏忽产生疑问而不是仅仅将程序涉及到只能有效工作到1999年,由于他没有这样做,软件测试源就应该测试并发现该缺陷,然后又开发小组确定是否修正。
2、判断是非:公司或开发小组用户称呼软件问题的术语很重要。
错。这虽然不重要,但使用什么术语常常反映了小组的个性及其寻找、报告、确定问题的方法。他们提及软件问题的方式反映出他们处理整个开发过程的方式。他们是谨慎、小心、直接,还是简单生硬。
3、仅仅测试程序是否按预期方式运行有何问题?
这最多只能算测试问题的一半。用户不一定遵守规则,软件测试员需要证实不按标准操作有何后果。此为,如果测试员进行测试没有打破砂锅问到底的态度就会遗漏某些软件缺陷。
4、产品发行后修复软件缺陷比项目开发早期这样做的费用要高出多少?
10~100倍,甚至更高。
5、软件测试员的目标是什么?
尽可能早一些找出软件缺陷,并确保其得以修复
6、判断是非:好的测试员坚持不懈地追求完美。
错。他们力求完美