|
当前文档测试的方法没有什么特别的形式,还缺乏测试工具支持,通常是通过静态审查方式――“走查”来进行的,主要查看文档的可读性,内容真实性、可靠性、全面性。另外,在项目里程碑时期召集相关领域专家对重要文档进行集中审核,也是一种检查方式。
3、 单元测试应引入交叉测试方法;
单元测试是对软件基本组成单元进行的测试,测试对象是软件模块。通常,单元测试是由开发人员来完成,而且往往是各人测各人的。这存在问题隐患。
为什么呢,技术人员是软件模块的制造者,自己来测自己的软件的话,角色便从制造者变成了审查者,而前一个角色的目的是为了保证软件正确,后一个角色的目的是为了发现更多的缺陷,让一个人同时来扮演两种目的不同的角色,好比让他既当裁判员又当运动员,怎么能做好呢?
解决方法通常有两种,一种是:由测试人员来进行单元测试,这种方式要求测试人员要有较高的软件技术知识;另一种是:将软件人员分组,在模块开发告一段落时进行交叉测试,这种方法只需要测试者了解被测方的软件需求,不需要另外的知识培训,而且测试出发点较为客观,所以被较普遍的推广使用。
4、 测试在开发基本完成才启动;
在传统的瀑布型开发模式中,软件测试位于编码阶段之后,是作为一个独立阶段存在的,许多人便一刀切地认为应该将所有的测试工作在编码完成后再开始。这个观点要不得,原因有二:
首先,若将测试工作细分,有许多工作是可以提前先期执行的,如:需求书与设计书的学习、测试计划的制定、测试人员的培训、测试脚本的建立、测试资源的搭建、测试模板的创建、测试工具的选择等等,都是可以与其他阶段并行处理的,这将大大缩短项目开发时间,为测试提供充分的时间保障,提高测试质量。
其次,软件缺陷发现的越晚,修改、补救所耗费的成本越高。引用Boehm在《Software Engineering Economics》一书中的话――“平均而言,如果在需求阶段修证一个错误的代价是1,那么,在设计阶段就是它的3-6倍,在编程阶段是它的10倍,在内部测试阶段是它的20—40倍,在外部测试阶段是它的30-70倍,而到了产品发布出去时,这个数字就是40-1000倍。”由此可见,测试目标的最佳定位应该是:在错误第一次出现的时候就捕捉到它。所以,在尽可能的情况下,测试越早展开越好。
在项目的各个进行阶段,都有不同的项目产品产生,他们质量的好坏,对后续开发影响重大,所以,现在国际上比较流行的做法是:将测试融合到各个开发环节中去,尽早测试。
<<上一页
1
2
3
4
5
6
7
下一页>>
|