测试从零开始（一）测试基本概念

前言

做软件测试已经有5年的经验,对产品的基础知识和业务掌握比较熟悉,这一点不需要去置疑自己,很多时候还能够串联起来,对公司这个领域有较深的认识.但是产品不是一尘不变,每个版本都在更新,而随着年龄的增长对于知识的记忆的优势会渐渐老去,这个时候,必须得尽早考虑基础的东西掌握和经验的应用与论证,所谓理论结合实践则更有必要,希望通过半年的学习掌握测试基础知识,我称之为”测试从零开始”

测试基本概念

广义概念

软件生存周期当中的所有检查、评审和确认工作，包括以下阶段

l  需求分析阶段

l  设计阶段

l  开发测试阶段

l  上网维护阶段

涉及到检查的内容包括：

l  文档

l  功能

l  性能

l  。。。

狭义概念

识别软件缺陷的过程，是一种“验证功能”与“确认用户需求”的活动

 

以下一段文字讲得比较合理

“软件错误的发现绝不能等到测试才开始（按常规，最早的测试就是编码后的单元测试）。因此，应当做到软件开发全过程检测，力争本阶段修正错误。单元测试是在软件开发的“实现阶段”才开始的，在此之前的“可行性研究与计划阶段”，“需求分析阶段”，“概要设计阶段”，和“详细设计阶段”，都必须有非常明确切实的手段与措施对开发结果进行检验，以保证阶段的正确完成。

狭义概念则是指识别软件缺陷的过程，即实际结果与预期结果的不一致。软件测试通常包括验证(verification)和确认(validation)，验证指保证软件正确的实现了某一特定功能的一系列活动。确认指的是保证软件的实现满足了用户需求的一系列活动。”

 

上述提到的“软件错误的发现绝不能等到测试才开始”是需要从管理上去落实，即是测试前期投入，如何投入、评价与导向，决定了活动产生的“效益”？这里留一个悬念，做为一个课题去研究。

 

从概念上面去理解，或者说从字面上面去理解，测试是一件比较清晰明朗的事情，这对于一个没有工作经验的人来说非常清晰，随着工作经验的增加，就会发现，“测试”的概念无处不在，一个有着深刻“测试”概念的人，往往在某些方面其逻辑思维能力是很强的。若一个人逻辑思维能力不强，甚至可以通过学习“测试”去煅炼自己。

测试目的

简单一句话“在资源与时间有限的情况下，根据用户的需求，尽可能发现多的缺陷，确保软件质量。”

软件是一个产品，产品是要赚钱的，凡是赚钱的东西，都必须考虑投入产出比，或者长远利益，因此资源与时间是有限。

产品是根据市场的需求而生，在产品生产过程当中，所做的需求必定不会是：“刚刚好”，必定存在一些与市场需求无关的功能（这些功能如何引入，我们可以后续讨论），由于“资源与时间有限”，测试只能优先满足“市场需求”测试前提与框架情况下，尽可能发现多的缺陷，而不是盲目增加测试用例去验证所有功能。

测试目标

最终目的是确保软件的功能符合用户的需求，把尽可能多的问题在发布或是交付前修正

1）  确保软件完成它所承诺或者公布的功能，并且所有用户可以访问到的功能都有明确的书面说明，与ISO9001是同一种思想（这句话读者不是非常了解，需要更多了解，在后续课题研究当中进行分析）

这里有一段比较精采的引述

“软件缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。所谓短期行为，是指缺少明确的书面文档既不利于软件最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系；同时也不利于软件的后期维护，也使厂商支出超额的用户培训和技术支持费用。从长期利益看，这是很不划算的。
当然，书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难，也是最容易被忽略的。
最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。”

 

这部分的分析十分精彩，文档是必须，但是如何生成与维护，是一个十分复杂的难题。

 

从管理上来看，对于一个庞大的系统软件来说，其特性是非常复杂，要展现在客户面前的多方面，包括其功能、性能、可靠性等内容，而这些是软件在最终时就设计好了，需要将设计好的内容整合在一起，形成“可以让客户接受的文档”，就需要一个完整的管理体系，因此每个公司往往设置资料部，用以做这项工作，同时还有翻译部。

 

文档分为很多种，对于测试来说，看到应该是内部研发文档，而由于当前软件一般采用快速原型法(RAD)（即为迭代开发），文档的即时更新程度困难，并且往往成本高，因此最终软件与最初的设计可能存在较大差异，由于文档一般情况下来自于最初设计，因此与实际的软件存在较大差异，同时也对测试造成较大的影响，因为测试设计、目标、范围是来自于最初的设计，在实际测试过程当中往往变化较大。

 

说明：快速原型法是一种基于离散和堆积原理的崭新制造技术。它将零件的CAD模型按一定方式离散，成为可加工的离散面、离散线和离散点，而后采用物理或化学手段，将这些离散的面、线段和点堆积而成零件形状。

 

对于“文档与资料”这方面，这里不详细描述，作为一项课题在后续进行研究。

 

2）  确保软件满足性能需求

一个庞大的系统软件，性能是竟争力的体现，使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的软件不能说是一个有竞争力的软件。性能测试有很多方面的内容，关于软件的性能有很多种类型，具体见后续的课题研究。

 

以下这段引述十分精彩

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

 

3）  确保软件是健壮的和适应用户环境的。

健壮性即稳定性，是软件质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。

关于软件健壮性，这里讲得比较简单，何为软件“健壮性”，在后续课题当中研究。

 

测试还包括其他目标：

ü  为软件的质量评估提供依据

ü  为软件质量改进和管理提供帮助

关于“软件的质量评估”是一个复杂的课题，这里暂时不涉及

关于“软件的质量改进与管理”涉及到一些较为复杂的流程，在后面深入之后进行分析，这里暂时不涉及。

测试原则

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

解读：这个原则在系统测试当中是应该最先考虑的，庞大系统的软件由多个模块组成，一个模块有可能由多名程序员组员，加上平台，甚至可能达到几百人，而测试有可能涉及多个模块甚至整个系统，在测试时无法追求完美，在测试设计时就需要考虑投入与产出的原则，同时这也是管理上需要牵引的。敏捷开发过程讲，要做“刚刚好满足客户需求的产品”，这里就是要“设计足够好的测试策略和用例，验证刚好满足客户需求的产品”。

 

ü  保证测试的覆盖程度，但穷举测试是不可能的

ü  所有的测试都应追溯到用户需求

解读：用户的需求往往提出来是比较简单，而在分析时，需求可能会考虑多个方面，测试不仅要追溯到用户需求，更重要是考虑到影响产品DFX（如可靠性、可服务性）等方面的内容，这些属于隐性需求，总知，站在客户需求的角度去测试，不要局限，但不能发散。

 

ü  越早测试越好，测试过程与开发过程应是相结合的

解读：这个原则，管理实际上比测试更为重要，需要很好牵引以及权衡投入与产品比，并且必须要考虑进度、人力等各方面因素。从高层角度来看，任何时候都想尽早开始测试，但是计划赶不上变化，管理上决策是很重要，但是千万不可犹豫不决，有时候需要当机立断，但不是武断，而是尽可能了解信息与细节，果断执行，及时调整，不怕丢脸。

 

ü  测试的规模由小而大，从单元测试到系统测试

解读：层层质量把关，越到后面问题越难发现，越难定位。（这个原则需要考虑多种因素，且不同的产品，特别是平台化，这个原则是很重要，涉及很多配合问题，暂且遗留，做为一个课题去研究。见“如何让测试规模由小到大的原则体现在团队配合当中”）

 

ü  为了尽可能地发现错误，应该由独立的第三方来测试

解读：简单来说，自己人玩自己的产品，特别是一个很熟悉的老员工，惯性思维的影响会忽略过多的细节，而导致错误的遗漏，应该由同样具备能力的第三方来测试，但并是非常熟悉产品，但是必须熟悉需求和方法，更容易提出不同的看法和要求。这个原则可能比较适用于一些专题测试，例如安全测试、硬件可靠性测试等。

 

ü  不能为了便于测试擅自修改程序

解读：很简单，修改代码都是要有问题单来跟踪，流程必须把控好，做到任何修改都是可追溯的，PDM流程在这方面做得比较好。关于“问题修改如何做到可追溯”这个也是可以做为一个课题去研究。

 

ü  既应该测试软件该做什么也应该测试软件不该做什么

解读：很好理解，知道客户需求，还需要分析需求，发掘隐性需求。

测试规律

ü  木桶原理

引文百度百科对于木桶原理的解释：

盛水的木桶是由许多块木板箍成的，盛水量也是由这些木板共同决定的。若其中一块木板很短，则此木桶的盛水量就被短板所限制。这块短板就成了这个木桶盛水量的“限制因素”（或称“短板效应”）。若要使此木桶盛水量增加，只有换掉短板或将短板加长才成。人们把这一规律总结为“木桶原理”，或“木桶定律”，又称“短板理论”。

更进一层，我们可以知道：

1、比最低的木板高出的部分是没有意义的，高出越多，浪费越大；

2、要想提高木桶的容量，就应该设法加高最短的那块木板的高度，这是最有效也是惟一的途径。这是来自生活中的经验，但朴素的道理却是人类智慧的结晶。

任何一个组织或许都有一个共同的特点，即构成组织的各个部分往往是优劣不齐的，但劣势部分却往往决定着整个组织的水平。问题是“最短的部分”是组织中一个有用的部分，你不能把它当成烂苹果扔掉，否则你会一点水也装不了!

劣势决定优势，劣势决定生死，这是市场竞争的残酷法则。它告诉领导者：在管理过程中，要下工夫狠抓单位的薄弱环节。

领导者要有忧患意识，如果你个人有哪些方面是“最短的一块”，你应该考虑尽快把它补起来；如果你所领导的集体中存在着“一块最短的木板”，你一定要迅速将它做长补齐，否则它给你的损失可能是毁灭性的——很多时候，往往就是一件事而毁了所有的努力。一个县或是任何一个区域都有这样“最短的木板”，它有可能是某个人，或是某个行业，或是某件事，领导者应该迅速找出它来，并抓紧做长补齐。有些人也许不知道木桶定律，但都知道“一票否决”，这是中国的“木桶”，有了它你便知道木桶定律是多么重要。

形容科学研究和事物发展的整体水平比喻。决定一只木桶容量的，既不是最长的，也不是平均长度的，而是最短的那根木板。这意味着必须推进所有的知识前沿，加强整个科学技术事业和组织的结构，才能在竞争中取胜。一个团队组织的成功，不在于某几个人，而是所有人的其同并进。随着社会的发展，这个理论被应用于许多方面。比如经济界，it界等等。

软件质量“木桶规律”引文如下：

“软件质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终软件的质量

测试是提高软件质量的必要条件，最直接、最快捷的手段，但决不是一种根本手段”

 

ü  Bug的80-20原则

Ø  在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug

Ø  而系统测试又能找出其余Bug中的80%

Ø  最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来

 

Ø  80%的工程量用在20%的需求上

Ø  80%的开发成本花费在20%的部件上

Ø  80%的错误是由20%的部件引起的

Ø  80%的延期或返工是由20%的变更造成的

Ø  80%的系统资源是由20%的部件消耗的

Ø  80%的进度是由20%的人完成的

上述所说的原则，实际上来说我确实没有什么感觉，只有在设计的时候会考虑基本功能测试占到工作量的80%，关于这个原则，我没有什么足够的发言权。

测试重点

ü  测试用例的良好设计

Ø  测试用例的设计是整个软件测试工作的核心

Ø  测试用例反映对被测对象的质量要求，决定对测试对象的质量评估

ü  测试工作的管理

Ø  尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提

ü  测试环境的建立

Ø  测试环境应该与实际测试环境一致

 

解读：测试用例是测试的“关键资产”，测试用例的设计、管理、维护、继承是测试工作管理的核心。测试环境建立涉及物料、人员以及资源的分析，也同样是管理的核心。当然还包括进度与质量控制。除这些重点之外。除以上三点之外，还应该知道测试能力的培养与产品知识的传递。

测试质量

这部分在测试概述当中讲得很笼统，而且不详细，同时也不准确，还需要参考其他的指导书。从我这些年的工作经验来看测试质量，个人认为测试质量需要从多个角度去考虑，包括设计、测试过程、投入产出比以及最终上网版本质量。因此测试质量是具有滞后性的一个评价。如果只对测试过程进行简单的评审，是无法看到一个测试人员真正的价值。关于“测试质量是如何考量”需要在后续做为课题研究。

测试度量

       一般一个比较系统的软件开发，测试是有进度查询和可度量，通过工具就可以直接看到，是个比较简单的事情，但是DI值并不一定代表一切。这部分经验不是非常丰富，但是度量只能一个牵引，还是得需要关注问题本身，以及考虑团队运作时细节，才能真正让问题闭环。

测试分类

–  功能测试

–  可靠性测试

–  容错性测试

–  恢复测试

–  易用性测试

–  性能测试

–  可维护性测试

–  可移植性测试

–  安全性测试

–  用户文档测试

一个系统可以划分多个特性，从用户需求角度去考虑这个特性，采用上述测试方法对此特性进行设计，可以算得上是一个比较完整的系统测试。

可测试性（DFT）

ü  软件容易被测试的程度，包括下面几个指标：

–  可确认性：可以明确确认软件是否符合要求，例如有明确的要求和指标

–  可观察性：用于确认的结果可以进行有效的观察

–  可控制性：相对应的测试环境可以进行控制，从而保证测试的有效性

–  可分解性：软件可以进行分解，对分解的结构进行测试

可测试性应该在软件设计之初就考虑，这就需要测试人员提前参与分析。