软件测试的疑惑（二）

测试流程问题

 

1、测试人员要需要何时参加需求分析？

原则上，测试人员对需求了解得越深入对测试工作越有利，所以最好一开始就应该参加需求分析工作。这样可以带来如下得好处：

1. 测试人员全程参与需求分析，对需求了解很深刻，减少了很多与开发人员的交互，节省了时间。测试人员参与前期开发讨论，直接掌握了不清晰的需求点；
2. 早期确定测试用例的编写思路，为测试打好了基础；
3. 可以获取一些测试数据，为测试用力设计提供帮助；
4. 可以发现需求不合理的地方，降低了测试成本。

测试人员主要的工作之一就是确认系统是否正确实现了需求。测试人员不参与前期的工作，就只能依赖最后形成的需求文档，甚至由开发人员来讲解需求，而这些缺求可能发生了“问题”，因为这个需求是已经经过分析的需求，很多的内容可能与用户的真正要求发生了偏差。同时如果只看最后形成的需求文档，对需求也会有理解上的偏差。因此作为测试人员要尽可能的获取到“第一线”的需求资料，才能真正地了解用户的业务，从而更好的对系统进行测试。

当然，如果测试人员不能参与需求环节，一定要通过其他途径保证需求的精确性，例如和开发人员进行集中讨论需求疑问的项目会议，并且一定要加强测试案例评审，甚至于是测试需求的评审。

2、什么是冒烟测试？

    冒烟测试从操作上是一个随机的测试，操作对象通常是核心业务模块。测试员任意操作，要是发现多数功能走不下去（大概20％），那么这个冒烟测试就算是结束了。

冒烟测试一般不用参照测试用例。

执行冒烟测试的目的是对要测试的产品进行一个大概的度量。如果冒烟测试不能通过，通常不会启动测试计划。因为软件缺陷较多的情况下，启动测试计划会浪费更多的人力和物力。

 

通俗的说，对“垃圾”产品执行测试实际是测试人员抢了程序设计人员的工作，这些缺陷应该在开发阶段消灭，只有这样才可以真正的节约成本。

3、系统测试阶段低级缺陷较多怎么办？

在系统测试阶段，如果仍有很多低级缺陷，说明测试对象是不合格的，没有达到测试标准。

如果系统阶段发现的简单缺陷（也就是不应该有的缺陷）较多，最好停止测试，转由开发人员进行测试，发现问题立刻修改，因为这种由测试人员进行的成本较高，反复交互还会耽误进度。

建议建立预测试制度：系统测试前对核心模块进行抽查测试，如果问题较多（例如平均每个核心模块发现10个以上缺陷），就可以停止本次测试，直到抽测后发现问题较少才可以启动系统测试。

 

4、缺陷流落到客户那里有什么后果？

如果软件缺陷被遗落并流落到客户那里，结果就是代价高昂的电话或者现场支持费用，还可能需要修复、重新测试和发布新的产品，更糟糕的情况是产品要被召回甚至被客户起诉。这种成本付出非常高，几乎是在内部修改缺陷的几何级数倍。

质量之父PhilipCrosby把质量的费用分为整合费用和非整合费用两类，

整合费用是指与一次性计划和执行测试相关的全部费用，用于保证软件按照预期方式进行。

非整合费用是指如果发现缺陷，经过一系列的缺陷处理流程而解决缺陷。

PhilipCrosby在自己的作品中详细论述了内部的整合费用和内部的非整合费用之和远远小于外部也就是客户引起的非整合费用。

总之，软件缺陷一定要尽可能的在内部解决，这对节约成本、提高产品知名度都大有裨益。

5、回归测试中未解决的缺陷如何处理？

软件的后期测试就是一个反复回归的工作，有些问题可能修改多次才能解决，尤其是那些在开发环境下不存在的问题，这些问题很容易被程序员忽视，拖到最后才解决。因此大部分回归测试就是和开发人员反复配合解决那些上次测试中没有解决的缺陷。

这里重点讨论的是最后一次回归测试后，仍然发现有些缺陷没有解决时测试经理应该如何做。在管理不规范的组织中，由于进度或者其它方面的压力，开发工作已经停止，通常会将这些问题置之不理。

正确的做法时把这些没有解决的问题形成一个未解决缺陷报告，然后召开项目会议进行讨论，对不同的问题采取不同的处理方式：

(1) 严重性的问题：有些问题较难解决，往往会被拖到最后，如果这类缺陷导致软件功能发生障碍，则必须解决，这也是质量控制的职责所在；

(2)功能性的问题：可以考虑升级时解决；

(3)一般性问题：不影响使用，可以不解决或者升级解决。

这类项目会议通常需要技术总监或者更高级别的人来参加。最后，需要对最终讨论没有解决的缺陷列表进行签字并存档，形成一个基线。特别要注意的某些缺陷是否修改不能由程序员或者测试人员来决定，这样有可能带来严重的后果——导致缺陷失控，最终形成没有人对质量负责的局面。

 

文章为准备面试时，朋友分享的问题，添加自己的理解和体会，希望可以帮助到大家。