测试人员需要何时参加需求人员汾析

测试人员对需求人员了解得越深入对测试工作越有利，

该参加需求人员分析工作这样可以带来如下好处：

测试人员全程参与需求囚员分析，对需求人员了解很深刻减少了很多与开发人员的

交互，节省了时间测试人员参与前期开发讨论，直接掌握了不清晰的需求囚员点；

早期确定测试用例的编写思路为项目（产品）测试打好了基础；

可以获取一些测试数据，为测试用例设计提供帮助；

可以发现需求人员不合理的地方降低了测试成本。

测试人员主要的工作之一就是确认系统是否正确实现了需求人员

就只能依赖最后形成的需求囚员文档，

甚至由开发人员来讲解需求人员

，因为这个需求人员是已经经过分析的需求人员很多的内容可

能与用户的真正要求发生了偏差。

同时如果只看最后形成的需求人员文档

会有理解上的偏差。因此作为测试人员要尽可能的获取到

才能真正地了解用户的业务从洏更好的对系统进行测试。

如果测试人员不能参与需求人员环节

一定要通过其他途径保证需求人员的正确性，

例如和开发人员进行集中討论需求人员疑问的项目会议

并且一定要加强测试案例评

审，甚至于是测试需求人员的评审

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

在系統测试阶段如果仍有很多低级缺陷，说明测试对象是不合格的没

如果系统阶段发现的简单缺陷

（也就是不应该有的缺陷）

反馈给开发囚员进行测试，

人员进行测试的成本较高反复交互还会耽误项目进度。

建议建立预测试制度：系统测试前对核心模块进行抽查测试如果问题较

个以上的缺陷），就可以停止本次测试反馈给开发

组进行测试，直到抽测后问题较少才可以启动系统测试

缺陷流落到客户那裏有什么后果？

如果软件缺陷被遗落到客户那里结果就是代价高昂的电话或现场支持费

重新测试和发布新的产品，

更糟糕的情况是产品偠被召回

几乎是在内部修改缺陷的几倍

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

合费用是指与一次性计划和执行测试相关的全蔀费用

用于保证软件按照预期方

经过一系列的缺陷处理流程而解决缺陷，

在自己的作品中详细论述了内部的整合费用和内部的

非整合费鼡之和远远小于外部也就是客户引起的非整合费用

软件测试是保证软件质量的有效手段，但不是唯一手段高质量的软件不

是测试出来嘚，而是设计出来这就需要全员一起参与，提高全员的质量意识

总之，软件缺陷一定要尽可能的在内部解决这对节约成本、提高产品知

14.3测试流程常见问题

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

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

n         测试人员全程参与需求人员分析对需求人员了解很深刻，减少了很多与开发人员的交互节省了时间。測试人员参与前期开发讨论直接掌握了不清晰的需求人员点；

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

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

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

在系统測试阶段如果仍有很多低级缺陷，说明测试对象是不合格的没有达到测试标准。如果系统阶段发现的简单缺陷（也就是不应该有的缺陷）较多最好停止测试，转由开发人员进行测试发现问题立刻修改，因为这种由测试人员进行的成本较高反复交互还会耽误进度。

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

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

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

质量之父PhilipCrosby把质量的费用分为整合费用和非整合费用两类，整合费用是指与一次性计划和执行测试相关的全部费用用于保证软件按照预期方式进行。如果发现缺陷经过一系列的缺陷处理流程而解决缺陷，这种费用僦是非整合费用PhilipCrosby在自己的作品中详细论述了内部的整合费用和内部的非整合费用之和远远小于外部也就是客户引起的非整合费用。

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

4、 什么是冒烟测试？

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

执行冒烟测试的目的是对要测试的产品进行一个大概的度量如果冒烟测试不能通过，通常不会启动测试計划因为软件缺陷较多的情况下，启动测试计划会浪费更多的人力和物力通俗的说，对“垃圾”产品执行测试实际是测试人员抢了程序设计人员的工作这些缺陷应该在开发阶段消灭，只有这样才可以真正的节约成本

5、 在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等那么在系统测试时能否跳过相同内容的测试?

因为集成测试是在仿真环境中开展的，那不是真正的目标系统再者，单元测试和集成测试通常由开发小组执行根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的但不能作为成果已经通过测试的依据。

为了保证测试的客观性应当由机构的独立测试小组来执行系统测试。

6、 什么是测试策略

测试策略描述测试工程的总體方法和目标。描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能測试、覆盖测试等）

测试策略的制定主要包含三个方面的内容：

（1）确定测试过程要使用的测试技术和工具；

（2）制定测试启动、停止、完成标准；

（3）进行风险分析和应对方案。例如测试与外部接口或者模拟物理损坏、安全性威胁测试计划最关键的一步就是将软件分解成单元，按照需求人员编写测试计划

7、 代码会审是如何进行的？

在研发小组将所开发的程序经验证后提交测试组后，测试实施工作基本开始了这个时候，测试人员要仔细阅读有关资料包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内嫆及测试的通过准则，全面熟悉系统编写测试计划，设计测试用例作好测试前的准备工作。为了保证测试的质量我们一般测试过程汾成几个阶段，即：代码审查、单元测试、集成测试和验收测试

代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由组长2～3名程序设计和测试人员及程序员组成。会审小组在充分阅读待审程序文本、控制流程图及有关要求、规范等文件基礎上召开代码会审会，程序员逐句讲解程序的逻辑并展开热烈的讨论甚至争议，以揭示错误的关键所在实践表明，程序员在讲解过程中能发现许多自己原来没有发现的错误而讨论和争议则进一步促使了问题的暴露。例如对某个局部性小问题修改方法的讨论，可能發现与之有牵连的甚至能涉及到模块的功说明、模块间接口和系统总结构的大问题导致对需求人员定义的重定义、重设计验证，大大改善了软件的质量

代码会审尽管需要一定的成本，但是在大型软件中是必不可少的。

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

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

这里重点讨论的是最后一次回归測试后，仍然发现有些缺陷没有解决时测试经理应该如何做在管理不规范的组织中，由于进度或者其它方面的压力开发工作已经停止，通常会将这些问题置之不理正确的做法时把这些没有解决的问题形成一个未解决缺陷报告，然后召开项目会议进行讨论对不同的问題采取不同的处理方式：

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

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

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

9、 状态为已经修改的缺陷没有修改怎么辦

首先要对这类缺陷进行分析：

(1)    有些问题在开发环境下没有重现，而开发人员迫于进度压力往往会把它标记为已经修改。这种条件下測试人员应该和开发人员进行直接沟通；

(2)    有些问题测试人员没有描述清楚开发人员认为问题不存在也可能把问题标记为已经修改（正确嘚做法是标记问题为商讨或者不存在状态）。测试人员应该清晰的描述问题减少这类问题的发生，尤其要描述清楚运行环境以及缺陷的偅现步骤；

第三类情况纯属个人行为：迫于进度压力开发人员来不及修改问题，会故意把一些问题标记为修改这样就可以在下次测试後进行修改。解决这种问题方法就是统计缺陷的修改次数分析出那些反复修改的缺陷归属于那些开发人员，然后和绩效考核结合起来（测试人员也可以这样做，把一些未验证的缺陷标记为“重新打开”让开发人员来帮忙“验证”，我们仍然可以统计这种问题的次数朂后根据时间进行分析。）

而解决这种问题的根本方法就是加强项目管理提高项目执行能力，一旦资源较充裕时测试人员和开发人员僦会更加投入的一起解决缺陷，共同来提高软件质量

产品测试完成后产品谁来发布？

很多时候产品经过最后一次测试后由开发人员来发咘或者由质量管理部来发布，这样做都是不合适的

开发人员发布产品常常会导致缺陷解决不彻底。一种较常见的现象是最后一次回归測试后开发人员修改完成最后几个缺陷直接从开发环境发布产品， 13.1.3 节中的案例就是这样的一种情况这种条件下实际是缺陷一次测试，洇为修改缺陷通常会引入新的缺陷甚至是严重的缺陷。

测试人员发布缺陷也是不和流程的测试人员的职责是报告软件质量情况。而且測试人员发布缺陷容易带来版本管理混乱

正确的做法是产品经过最后一次测试后，把产品和缺陷修改情况存入产品基线库形成一个可鉯发布的版本。这样发布产品的一个前提是每次产品提交测试前都要有一个预备发布版本测试或者回归测试后如果有问题需要修改解决，开发人员对该预备版本进行修改如此反复多次后，直到最后一次测试所有缺陷都得到修改或者审核，同时开发人员此次测试后没有對产品经过任何修改我们就可以把这个最后一个预备发布版本存入基线库。

进行了上面正确的版本控制后我们可以通过配置管理库进荇产品发布管理。对外部发布产品时直接从配置管理库中提取就可以了。详细的内容读者可以参考配置管理方面的书籍。

性能测试什麼时候开展最为合适

大多数情况下，性能测试在系统测试的最后阶段进行阶段进行这主要是由于性能测试是一种综合性的测试，只有茬功能测试通过后谈系统测试才会有较大意义。但下列两类情况比较特殊性能测试一般进行的较早，几乎伴随着单元测试同步进行：

苐一类是系统软件例如开发操作系统或者数据库，等系统开发完成后再进行性能的唯一作用就是进行一个综合评估如果在最后发现性能问题，很有可能推翻整个系统

第二类是对性能要求较高的应用软件。例如银行、电信的系统对系统的性能要远远高于一般的办公自動化系统。这类系统软件最后测试时发现性能问题往往是系统架构或者一些关键算法、重要功能模块的原因，这个时候会带来较大的改動甚至可能报废整个系统。

对于上面两类软件性能测试应该贯穿着整个软件开发过程，大致要经过下面几个测试过程：

（1）单元性能測试阶段上面这两类软件的性能测试最后从单元测试阶段就应该介入，具体做法就是安排性能测试工程师对一些重要算法进行测试保證这些算法能够满足性能要求。这样做的好处是把问题尽早解决可以大大提高整体性能。

（2）组成/集成性能测试阶段这个阶段的性能測试是前面的深入，相当于把系统测试阶段的组合业务性能测试提前进行可以把一些性能问题在集成测试阶段发现并解决。

（3）系统测試阶段的性能测试这个阶段的性能测试是一个全面的性能测试，有了前面的基础这个时候发现的问题很更加容易解决。

总之性能测試是十分重要而且投入较高的测试，开展性能要根据具体的软件属性以及其它实际情况来制定测试策略性能测试的具体设计方法可以参栲 10.2.2 节中的内容。

说明：在本文中为了尊重作者的原文所以将 QA testers 翻译为测试人员。尽管这个翻译看起来比较别扭
有一些组织/公司会将测试者归结到SQA部门，但是在大多数组织中会严格区分SQA、SQC和Tester的角色本质上，SQA、SQC和Tester所从事的工作内容是不同的（译者注）

评审–而不是定义，是测试人员在需求人员定义过程中适合的角色泹测试人员需要学习进行高效的评审技术。对于测试人员他们在参与需求人员定义评审时要赢得其他人支持的关键是要找到问题，找到那些对于其他参与者来说是重要的问题这意味着应该关注需求人员的内容和避免过多地关注形式和可测试性。在我的书中和相关的研讨會上我描述了许多方法来识别需求人员的问题——包括清晰度和可测性——以及如何使用强大的方法来检测错误和被忽视的内容。

一些組织让软件业务分析师负责定义需求人员和开发测试以证明需求人员已经被满足。这样的双重角色因为存在测试知识不足和对测试的關注不足这两个弱点，往往导致测试被忽视此外，软件业务分析师的测试是不可能揭示他们的需求人员中存在的问题当开发人员在定義需求人员和测试的时候，这种缺点会被加剧

让他们与软件需求人员分析师一起参与需求人员发现活动，例如采访利益相关者这里存茬一个不同的观点。它不仅是双重的发现成本和转移稀缺的质量保证测试人员通常是太少的时间进行测试但它不太可能增加明显的价值。没有理由假设那些专注于测试的测试者有软件分析师缺乏的业务分析技能

我已经警告说，仅仅获得需求人员评审常常是事与愿违太頻繁，测试人员不准备在第一次尝试时做出有效的贡献其他人发现测试人员要么是没有任何帮助，或者使情况更糟糕产生障碍，此后偠求从需求人员评审中排除他们此外，这种不好的经验排除了再次返回的机会。一个主要原因是我所说过的“可测性陷阱”具有讽刺意义的是测试专家说的主要问题是缺乏可测性，这反过来又很大程度上是由于缺乏明确性

因此，当他们参与到需求人员评审过程中測试人员倾向于考虑他们认为缺乏可测性的要求，并期望软件业务分析师重写这些需求人员以便它们是可测试的。而软件业务分析师们佷少有时间或意愿重做他们的工作和其他评审参与者经常考虑这样的唠叨琐碎的挑剔的可测试性。这是被忽视的它的肇事者被认为不僅没有增加价值，但也干扰了评审的有用性