zoukankan      html  css  js  c++  java
  • 软件测试的13项原则

    软件测试过程中,我们应注意和遵循一系列的具体原则,在ISTQB 软件测试基础认证大纲上,列出了7 项原则,但其中最后一项原则“不存在缺陷(就是有用系统)”的谬论不能算是一项合格的原则,所以可以认可的原则是6 项。除此之外,在这里还列出作者认为比较重要的7 项原则,合起来共13 项原则。

      1、ISTQB 的6 项原则

      1)原则1——测试显示缺陷的存在,但不能证明系统不存在缺陷。测试可以减少软件中存在未被发现缺陷的可能性,但即使测试没有发现任何缺陷,也不能证明软件或系统是完全正确的。

      2)原则2——穷尽测试是不可能的。由于有太多的输入组合、有太多的路径,而且时间是有限的,无法做到完全的测试(100%测试覆盖率)。通过运用风险分析和不同系统功能的测试优先级,来确定测试的关注点,从而替代穷尽测试。

      3)原则3——测试尽早介入。软件项目一启动,软件测试就应开始,也就是从项目启动的第一天开始,测试人员就应参与项目的各种活动和开展对应的测试活动。测试工作进行得越早,软件开发的劣质成本就越低,并能更好地保证软件质量。例如,在代码完成之前,可以进行各种静态测试,主导或积极参与需求文档、产品规格说明书等的评审,将问题消灭在萌芽阶段。

      4)原则4——缺陷集群性。版本发布前进行测试所发现的大部分缺陷和软件运行失效是由于少数软件模块引起的。一段程序中发现的错误数越多,意味着这段程序的质量越不好。错误集中发生的现象,可能和程序员的编程水平、经验和习惯有很大的关系,也可能是程序员在写代码时情绪不够好或不在状态等。如果在同样的测试效率和测试能力的条件下,缺陷发现得越多,漏掉的缺陷就越多。这也就是著名的Myers 反直觉原则:在测试中发现缺陷多的地方,会有更多的缺陷没被发现。假定测试能力不变,通过测试会发现产品中90%的缺陷。如果在模块A 发现了180 个缺陷,在模块B 发现了45 个缺陷,意味着模块A 还有20 个缺陷没被发现,而模块B 只有5个缺陷未被发现。所以,对发现错误较多的程序段,应进行更深入的测试。

      5)原则5——杀虫剂悖论。采用同样的测试用例多次重复进行测试,最后将不再能发现新的缺陷。为了克服这种“杀虫剂悖论”,测试用例需要进行定期评审和修改,同时需要不断地增加新的不同的测试用例来测试软件或系统的不同部分,从而发现潜在的更多的缺陷。

      6)原则6——测试活动依赖于测试背景。针对不同的测试背景,进行的测试活动也是不同的。比如,对要求安全放在第一位的软件进行测试,与对一般的电子商务软件的测试是不一样的。

      2、其他重要的7 项原则

      1)持续地测试、持续地反馈。软件测试贯穿着整个软件开发生命周期,随时发现需求、设计或代码中问题,及时将发现的问题反馈给用户、产品设计人员、开发人员等,主动、积极地交流,持续提高软件产品质量,这在敏捷测试中更为重要。

      2)80/20 原则。在有限的时间和资源下进行测试,找出软件中所有的错误和缺陷是不可能的,因此测试总是存在风险的。测试的一个重要目标是尽量减少风险,抓住重点进行更多的测试。根据80/20 原则,即帕累托法则(Pareto Principle),用户80%的时间在使用软件产品中20%的功能。“重点测试”就是测试这20%的功能,而其他80%的功能属于优先级低的测试范围,占测试20%的资源。

      3)建立清晰的阶段性目标。饭要一口一口地吃,不能一口就吃成胖子。测试的目标也要逐步达到,不可能在某一瞬间就达到。根据软件开发生命周期的不同阶段性任务,我们要决定相应的测试目标和任务。如在需求分析阶段,要参与需求评审以全面理解用户需求、发现需求的问题;在功能测试执行阶段,测试人员不仅要对新功能进行测试,而且要有效地完成回归测试。

      4)测试独立性。测试在一定程度上带有“挑剔性”,心理状态是测试自己程序的障碍。同时,对于需求规格说明的错误理解也很难在程序员本人进行测试时被发现。程序员应避免测试自己的程序,为达到最佳的效果,应由独立的测试小组、第三方来完成测试。

      5)确保可测试性。事先定义好产品的质量特性指标,测试时才能有据可依。有了具体的指标要求,才能依据测试的结果对产品的质量进行客观的分析和评估,才能使软件产品具有良好的可测试性。例如,进行性能测试前,产品规格说明书就已经清楚定义了各项性能指标。同样,测试用例应确定预期输出结果,如果无法确定所期望的测试结果,则无法进行正确与否的校验。

      6)计划是一个过程。虽然通过文档来描述软件测试计划,并最后归档,但计划是一个过程,是指导各项软件测试活动的持续过程。在项目开始时很难将所有的测试点、测试风险等都了解清楚,随着时间推移,通过需求和设计的评审和探索式测试,对产品的理解越来越深,对测试的需求和风险越来越了解,可以进一步细化、不断丰富测试计划。其次,计划赶不上变化,软件产品的需求常会发生变化,测试计划不得不因此做出调整。所以,测试计划是适应实际测试状态不断变化而进行调整的一个过程。

      7)一切从用户角度出发。在所有测试活动的过程中,测试人员都应该从客户的需求出发,想用户所想。正如我们所知,软件测试的目标就是验证产品开发的一致性和确认产品是否满足客户的需求,与之对应的任何产品质量特性都应追溯到用户需求。测试人员要始终站在用户的角度去思考、分析产品特性,多问问类似下面这样的问题:

      这个新功能对客户的价值是什么?

      客户会如何使用这个新功能?

      客户在使用这个功能时,会进行什么样的操作?

      按目前设计,用户觉得方便、舒服吗?

      如果发现缺陷,去判断软件缺陷对用户的影响程度,系统中最严重的错误是那些导致程序无法满足用户需求的缺陷。软件测试,就是揭示软件中所存在的逻辑错误、低性能、不一致性等各种影响客户满意度的问题,一旦修正这些错误就能更好地满足用户需求和期望。

    转载自http://www.51testing.com/html/50/n-813650.html

  • 相关阅读:
    POJ 1015 Jury Compromise【DP】
    POJ 1661 Help Jimmy【DP】
    HDU 1074 Doing Homework【状态压缩DP】
    HDU 1024 Max Sum Plus Plus【DP,最大m子段和】
    占坑补题。。最近占的坑有点多。。。
    Codeforces 659F Polycarp and Hay【BFS】
    Codeforces 659E New Reform【DFS】
    Codeforces 659D Bicycle Race【计算几何】
    廖大python实战项目第四天
    廖大python实战项目第三天
  • 原文地址:https://www.cnblogs.com/sunshine2016/p/5577793.html
Copyright © 2011-2022 走看看