什么是软件测试及软件测试基本原则

一、软件测试: 测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题,另一方面对产品质量进行客观的评价。 测试目的:简单地说,就是替用户

一、软件测试

测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题,另一方面对产品质量进行客观的评价。

测试目的:简单地说,就是替用户受过,测试的最终目的是确保最终交给用户的产品的功能符合用户的需求,把尽可能多的问题在产品交给用户之前发现并改正。

具体地讲,测试一般要达到下列目标:

(1)确保产品完成了它所承诺或公布的功能,并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。

产品缺少明确的书面文档,是厂商一种短期行为的表现,也是一种不负责任的表现。

所谓短期行为,是指缺少明确的书面文档既不利于产品最后的顺利交付,容易与用户发生矛盾,影响厂商的声誉和将来与用户的合作关系;同时也不利于产品的后期维护,也使厂商支出超额的用户培训和技术支持费用。从长期利益看,这是很不划算的。

当然,书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难,也是最容易被忽略的。

最后,书面文档的不健全甚至不正确,也是测试工作中遇到的最大和最头痛的问题,它的直接后果是测试效率低下、测试目标不明确、测试范围不充分,从而导致最终测试的作用不能充分发挥、测试效果不理想。

 (2)确保产品满足性能和效率上的要求。

 

使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。

 用户最关心的不是你的技术有多先进、功能有多强大,而是他能从这些技术、这些功能中得到多少好处。也就是说,用户关心的是他能从中取出多少,而不是你已经放进去多少。

(3)确保产品是健壮的和适应用户环境的。健壮性即稳定性,是产品质量的基本要求,尤其对于一个用于事务关键或时间关键的工作环境中。另外就是不能假设用户的环境

(某些项目可能除外)。

 

二、测试的原则--Good Enough

对于相对复杂的产品或系统来说,zero-bug是一种理想,good-enough是我们的原则。

Good-enough原则就是一种权衡投入产出比的原则:

不充分的测试是不负责任的;过分的测试是一种资源的浪费,同样也是一种不负责任的表现。我们的操作困难在于:如何界定什么样的测试是不充分的,什么样的测试是过分的。目前状况唯一可用的答案是:制定最低测试通过标准和测试内容,然后具体问题具体分析。

在软件测试过程中,应注意和遵循的具体原则,可以概括为十大项:

1.所有测试的标准都是建立在用户需求之上。

正如我们所知,软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求,所以测试人员要始终站在用户的角度去看问题、去判断软件缺陷的影响,系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。

2.软件测试必须基于“质量第一”的思想去开展各项工作,当时间和质量冲突时,时间要服从质量。

质量的理念和文化(如零缺陷的“第一次就把事情做对”)同样是软件测试工作的基础。

3.事先定义好产品的质量标准。

有了质量标准,才能依据测试的结果对产品的质量进行正确的分析和评估,例如,进行性能测试前,应定义好产品性能的相关的各种指标。同样,测试用例应确定预期输出结果,如果无法确定测试结果,则无法进行校验。

4.软件项目一启动,软件测试也就是开始,而不是等程序写完,才开始进行测试。

在代码完成之前,测试人员要参与需求分析、系统或程序设计的审查工作,而且要准备测试计划、测试用例、测试脚本和测试环境,测试计划可以在需求模型一完成就开始,详细的

测试用例定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作为测试人员的座右铭。

5.穷举测试是不可能的。

甚至一个大小适度的程序,其路径排列的数量也非常大,因此,在测试中不可能运行路径的每一种组合,然而,充分覆盖程序逻辑,并确保程序设计中使用的所有条件是有可能的。

6.第三方进行测试会更客观,更有效。

程序员应避免测试自己的程序,为达到最佳的效果,应由第三方来进行测试。测试是带有”挑剔性” 的行为,心理状态是测试自己程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。

7.软件测试计划是做好软件测试工作的前提。

所以在进行实际测试之前,应制定良好的、切实可行的测试计划并严格执行,特别要确定测试策略和测试目标。

8.测试用例是设计出来的,不是写出来的,所以要根据测试的目的,采用相应的方法去设计测试用例,从而提高测试的效率,更多地发现错误,提高程序的可靠性。

除了检查程序是否做了应该做的事,还要看程序是否做了不该做的事;不仅应选用合理的输入数据,对于非法的输入也要设计测试用例进行测试。

9.不可将测试用例置之度外,排除随意性。

特别是对于做了修改之后的程序进行重新测试时,如不严格执行测试用例,将有可能忽略由修改错误而引起的大量的新错误。所以,回归测试的关联性也应引起充分的注意,有相当一部分最终发现的错误是在早期测试结果中遗漏的。

10.对发现错误较多的程序段,应进行更深入的测试。

一般来说,一段程序中已发现的错误数越多,其中存在的错误概率也就越大。错误集中发生的现象,可能和程序员的编程水平和习惯有很大的关系。

标签: 软件测试 文档