转测试、测试、测试——软件测试的理论和实践2

smartbaby

2 基本路径测试

在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。包括以下5个方面：
2.1 程序的控制流图：描述程序控制流的一种图示方法。
2.2 程序环境复杂性：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界。
2.3 导出测试用例
2.4 准备测试用例，确保基本路径集中的每一条路径的执行
2.5 图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。

程序的静态分析方法：

1 生成各种引用表、静态错误分析

2 人工测试：桌前检查、代码评审等

3 软件测试工具：包括静态分析工具、动态测试工具、测试数据自动化生成工具、模块测试台、测试合成环境

3.1 静态分析工具：语言程序的预处理器、数据库工具、错误分析器和报告生成器。直接扫描所测试的正文，对程序的数据流和控制流进行分析，然后送出测试报告。

3.2 动态测试工具：通过选择适当的测试用例，实际运行所测程序，比较实际运行结果和预期结果，发现错误。

3.3 测试数据自动化生成工具：包括路径测试数据生成程序、随机测试数据生成程序以及根据数据规格说明生成测试数据

3.4 模块测试台是一种专门的测试用例描述语言，负责将输入数据传送到所测试模块中，然后将实际输出结果与在描述测试用例的语言中所表述的期望结果进行比较，发现错误。另外，也包括其它的功能：语句跟踪、动态断句、覆盖度量、用户自定义符号表、内容表和输出格式。

3.5 测试合成环境：包括环境模拟程序，代码检查程序，测试文档生成程序，测试执行严整程序，输出比较程序，程序正确性证明程序等，以及各种调试工具。而且还有集成系统，集成了多种工具，如SADAT、Microsoft Test for Windows和PureArtria等。

　

***********************************************************

　

测试的管理

作为项目或产品开发的一个必要的组成部分，需要良好的组织和管理。使用软件质量规范，编写和实现测试用例和模型，可以有效地组织测试。

一般的测试工作过程也可以是：计划-->配置（必要的软硬件资源下）-->开发（构造或配置测试工具、创建测试套件和测试方案库、准备适当的报告工具并记录测试系统如何运转）-->测试执行（进行测试、记录测试条件和问题，报告结果）。

测试管理也可以从测试经理和测试小组2个方面去看：

测试经理要管理好团队，很多人认为测试是枯燥乏味的事情，而且似乎低级的事情，所以测试经理应该不断地激励小组成员，为他们争取利益。在时间进度上保证稳步前进。就象赛跑，一开始就加班加点，只会导致极限的过早到来。
作为测试经理，应该有足够的质量意识。评价质量风险的方法是“失败模式和效果分析”(Failure Mode  and Effect Analysis, FMEA)。这种方法可以允许您在特定的质量风险和结果上映射需求、规范，以及项目小组假设。然后，按照风险级别进行分类，并按序排列。
实际上如果能得到充分的资源已是很困难的了，能用好临时的测试人员也已经不错了。一般企业的主管和技术经理都并不怎么真正重视测试工作的意义和价值。也许他们认为临时的投入一次性的强力测试足以发现绝大部分问题，而实际上这对产品的长远发展，以及质量改进都没有太大好处。

测试过程中软件功能可能进行调整和变化，测试发现问题也会导致变化，需要重新的测试。对这些变更也需要进行管理。
另外，由于上层管理部门的不重视，必须想办法与之进行清楚而有效的沟通；同开发部门的沟通也非常重要，因为开发和测试在性质上是有些对立的，很容易在相互之间产生一些不必要的矛盾。和开发部门不同的是，一般质量或测试部门和市场或销售部门的立场倒是比较一致的，如果双方都认为高质量的产品是市场战略中重要的品牌战略，彻底的测试对于达到这样的目标来说意义重大。因此，有必要和市场部门保持协作和交流。

测试经理可以经常问自己一些问题：

计划做哪些测试？实际完成了哪些测试？使用了多少用例？其中多少没有通过？管理部门是否有足够的支持？他们是否向你要过测试报告？开发部门的联络是否及时？等等。如果你是测试管理人员，应该可以想到更多的问题。


测试小组：

测试小组有多大的规模，一般取决于项目规模、测试人员与开发人员的比例、项目经理对质量保证的认识和期望等，也取决于你的准确的测试计划。
对一些项目来说，最好是在开始阶段就有测试人员有所介入。

如本文一开始所提到的，在测试小组中测试人员必须具备的素质包括：有效的坦率真诚的交流的能力、清晰简明的表达能力、一定的好奇心（但不至于太强，以至于花太多精力去探究一个微小的问题），不应害怕提出尖锐问题引起麻烦，一定的责任心，
注意力能够高度集中，是职业悲观主义者（但不是抱怨和憎恶）。

以下是一些测试的方法和基本工具：

测试方案、测试模型和测试用例
测试就象是做实验一样，实验对于象我这样的理工科毕业生来说真是太熟悉不过了。做实验之前必然有实验的方案、内容和步骤，测试似乎也是同样的。另外，基于测试用例的测试和常见的随机性的测来测去也是完全不同的，尽管习惯于随机性测试的人，如果注意力集中的话，他的头脑里也是有一些测试用例的。

关于测试实验室，进行测试工作首先要争取到尽可能好的环境。如果可能，应该建立测试实验室，实验室包括必要的装备、工具软件（包括测试工具）和各种操作系统平台，保持实验室的实用、整洁，避免他人干扰甚至破坏测试环境。

关于测试跟踪软件，制作一个简单的测试问题跟踪软件，记录测试的结果，将测试发现的问题分类，并对测试发现的问题和模块、开发人员进行关联，有助于分析问题，并可有效记录测试的结果，形成测试报告，并从中找出一些规律性的东西来。因此测试问题跟踪软件还是有一定的价值的。

关于测试自动化，有一定的风险。对一个稳定的系统，甚至可以自己开发自动化软件，而对于正处于快速变形中的软件开发过程，接口、主要功能和支持环境在发展变化中。为测试配置环境也要付出很多的时间。

以下是关于测试的一些技巧和经验：

在制定测试计划的时候，就要考虑到测试的风险，并抉择要执行哪些测试，并放弃哪些测试；测试计划的评审应该让开发人员参与；
测试模型的制作应该尽可能贴近用户，或者站在用户的使用立场上来观测软件，此时应该能发现更多的问题。

由于测试发现问题，在解决问题后还要重新测试，因此测试的时间可能会比实际更长一些

识别和注意少数重要的方面，而忽略多数次要的方面，有时候少数的问题足以致命，这些问题将是软件测试结果中重要性最高的错误。

错误的定位有时是很难的，要找出必然发生的前因后果，而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题。解决办法之一是在错误报告中给予说明。

对错误的描述，应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解，其后果是可以想见的。

有时有经验的测试人员凭借直觉就可以发现一些问题，这可称为“错误猜测”。

测试人员容易犯2种错误：一是测试人员发生判断错误，将本没有错误的系统行为报告为错误，或者将错误指定了过高的严重级别，或者过高估计了问题的严重性，这样会引起开发人员的不信任，产生一种象“狼来了”一样的效果；二是测试人员将错误的严重性或优先级定得过低，从而产生“测试逃逸”，这样会造成产品质量的风险。以上两种错误应该尽量避免。

　最后，我忽然想，测试实际上可以覆盖到硬件，甚至非计算机产品的测试，也许可以相互借鉴。

还有一种很奇特的感想，这种感想使我反而有些困惑不清了。我发现对测试来说，理论和实践的距离好象非常遥远，我先看了一本软件工程的书，然后写下了前面的一半内容，然后我又匆匆翻看了一本美国人的书，叫做《测试流程管理》，然后整理出了本文后一半的内容，该书中有着比本文多得多的各方面的实践经验。歌德说过，理论是苍白的，生命之树常青。我稍稍改变一下，就变成了：理论是苍白的，实践之树常青。也许测试是一种实践性很强的工作，大学教授们一般也不可能热衷于参加测试工作吧。

yangxuesong

同意~我做手机客户端及手机应用软件的~大部分BUG都是软硬件兼容问题~硬件缺陷很多~

燕子东南飞

测试工作有时候觉得很乏味无聊，那是你站的层次不一样，测试工作有时就是那样反反复复不停的做，例如回归测试，看看那些开发人员，觉得自己一无是处，总想提高自己，但又不知从何下手，就各一个去研究那些测试工具，性能测试 安全测试 等，但是没有人给你指点，自己只能学的很浅，想找个高手学学，到时都没有找到！无奈、悲哀！

blueteer

学习了，感觉不错

板砖

有理论有实践,可还是觉得自己仍然在测试门外.

yjr2008

说的好

yuxuan555269

都是些论坛前辈啊

Cynthia

我也认为统一定义严重性的优先级，这一点，我印象比较深，在做BUG 提交时，常常不知道Severity 选那一个，这样常常就会“狼来了"的情况。

snowfox

不错，不错，很有见地
但是不致到大家在具体的工作中，都感受到了多少？

wind

Originally posted by jackei at 2004-7-8 02:50 PM:
“最后，我忽然想，测试实际上可以覆盖到硬件，甚至非计算机产品的测试，也许可以相互借鉴。”

其实恰恰相反，软件测试本来就是属于质量检查工作，在工业领域，在制造业，这种工作已经开展了非常非常久，我们倒 ...

说的对，软件的发展其实正在向传统行业学习，比如软件工厂概念，构件化编程，偶以前是做机械产品设计的，在机械设计中，一张图纸就可以表达所有信息，无论技术人员、质量人员、生产人员都可以只凭它就能正常工作，但在软件里，不知需要多少文档来交流，即使是UML这样复杂的语言，目前也还起不到一张图纸的功效。

Fuli

好

smartbaby

我认为合适的介入时间分为两个部分：
1.高级测试人员：需求开始设计一段时间后，需求的初稿基本成形，此时高级测试人员进入。
2.普通测试人员：进行单元测试开始时介入。
所做工作相应分为两个部分：
1.高级测试人员：高级测试人员参与需求评审和需求熟悉及相应的文档测试，以及测试计划、本项目的测试约束。
2.普通测试人员：单元测试开始时，开始熟悉模块需求、设计；单元测试结束时，进入集成测试、系统测试等测试阶段。

当开发组不能提供相应的文档时，测试需要进行相应的测试需求分析，并按照测试需求进行测试。

由于各个公司的测试人员职责划分不一致，因此就笼统的说成高级测试人员和普通测试人员之分而已～

fuzengbin

文中提到：“对一些项目来说，最好是在开始阶段就有测试人员有所介入。”
请问如何介入？在什么时候介入？介入的深度？介入后做那些工作？领导总是担心测试人员介入到开发组中会无所事事，但是开发组又不能提供足够详细的文档来使测试人员全面了解测试对象。真是令人为难！

skinapi

“其实恰恰相反，软件测试本来就是属于质量检查工作，在工业领域，在制造业，这种工作已经开展了非常非常久，我们倒是可以从他们的工作中汲取一些营养。”
看来还要关注工业领域呀。

jackei

“最后，我忽然想，测试实际上可以覆盖到硬件，甚至非计算机产品的测试，也许可以相互借鉴。”

其实恰恰相反，软件测试本来就是属于质量检查工作，在工业领域，在制造业，这种工作已经开展了非常非常久，我们倒是可以从他们的工作中汲取一些营养。

smartbaby

回答archonwang的一般程序做了修改，那么修改后的简短更新日志由谁来编写比较合适？

我认为这个更新日志应该由修改程序的人来做，因为只有他自己知道都改了哪些地方，改了啥，什么时候改的。
我的建议是，这个更新日志出来以后，应该放入VSS或者CC中进行控制和管理，同时让相关的开发、测试人员每天都要看这个日志，就像看变更一样。
这样才能让这个更新日志发挥作用。否则就会流于形式～～

smartbaby

Originally posted by skinapi at 2004-7-5 11:22 AM:
文中提到
“测试人员容易犯2种错误：一是测试人员发生判断错误，将本没有错误的系统行为报告为错误，或者将错误指定了过高的严重级别，或者过高估计了问题的严重性，这样会引起开发人员的不信任，产生一种象“狼 ...

这两种错误的原因我分析一下：
1.由于对需求不了解、不熟悉，造成判断错误不准确
2.由于缺少测试经验，不能正确分析错误和判断错误
3.缺少统一的级别定义标准，每个人都主观地的填写严重级别和严重性

每一种原因对应的解决方法：
1.找需求、设计人员给测试人员讲解需求、设计，让测试人员熟悉需求、设计
2.加强测试培训，提高测试人员的经验和素质
3.定义统一的级别标准，出现什么问题对应什么级别的缺陷，让大家都有标准可以参考，而不再是随便定义的！
4.加强测试与开发的沟通！

不知道这样是不是对你有帮助～～

archonwang

测试人员容易犯2种错误：一是测试人员发生判断错误，将本没有错误的系统行为报告为错误，或者将错误指定了过高的严重级别，或者过高估计了问题的严重性，这样会引起开发人员的不信任，产生一种象“狼来了”一样的效果；二是测试人员将错误的严重性或优先级定得过低，从而产生“测试逃逸”，这样会造成产品质量的风险。以上两种错误应该尽量避免。


刚刚开始着手的时候，狼来了的情况很多，最主要的问题是对于将要测试的项目内容不够深入了解．错误优先级通常先设置为高，这不仅仅只是为了提醒开发人员编写代码需要谨慎，也是为了对用户负责．

在这里有个问题需要问大家：一般程序做了修改，那么修改后的简短更新日志由谁来编写比较合适？

skinapi

文中提到
“测试人员容易犯2种错误：一是测试人员发生判断错误，将本没有错误的系统行为报告为错误，或者将错误指定了过高的严重级别，或者过高估计了问题的严重性，这样会引起开发人员的不信任，产生一种象“狼来了”一样的效果；”
对于这种错误，我觉得可以通过测试人员和开发人员的及时沟通来尽量避免。当然提高自身对错误的判断能力也是一方面。

文中还提到
“最后，我忽然想，测试实际上可以覆盖到硬件，甚至非计算机产品的测试，也许可以相互借鉴。”
我也这么认为，软件测试是一门科学，里面蕴涵着不少方法学的东西，还有就是思维方式。而这些东西都是可以推广的。