《软件测试质量体系》培训总结与思考

此次培训，不同于理论知识的讲解，更多的是微软测试思想、方法与技巧的传达。通过培训，了解了微软的测试思想及过程，很多思想、方法值得我们学习。

1         对软件测试的理解

1)       测试的目的

Ø 不仅是为了将测试做好，更是为了将项目做好

Ø 测试不仅仅是发现bug,测试的最高境界是建立起一套软件测试质量体系，使得项目按照既定的方向（进度）和标准（如质量）前进

Ø 开发过程中的质量，不仅仅最终代码存在质量，开发的工作方式、过程中的方法、产物同样是质量

 

思考：微软是没有QA的，微软人人都是QA，质量意识是微软人最基本的素质，由测试人员制定项目轨道，并在过程中执行推进。重要的一点：该踩刹车时要及时刹车

     我们目前有专业的QA团队，负责项目过程中的质量管控，QC负责工程产物的质量，由两个角色来达成该目标，按国内软件企业的现状，由两个角色，专业化分工，开展起来确实更为有效。

2)       测试的原则：尽早的、不间断的进行测试

Ø 尽早的测试

ü 测试人员在需求阶段就介入，在项目前期预防和纠正需求及设计问题，做好缺陷的预防

ü 开发阶段：尽快的、尽可能的、极早的告诉开发代码是有效的

思考：

a)      目前我们已经做到了测试人员在需求阶段就参与，参与需求、设计文档的评审，但参与的效果还有待提升。

b)     “不明确的需求是项目效率的第一杀手”，测试设计人员应更多的从上游发力，加深自己对业务、对客户实际需求的理解，从实际应用、用例设计的角度参与业务需求、设计文档的评审，预防缺陷的发生。

c)      以前我们经常到项目后期了又发现重大BUG，这时给项目带来的极大风险，往往就是项目延期，再严重点的导致质量不可控，如何“尽快、极早的告诉开发代码是有效的”这是我们应该追求的目标，测试的依据是测试用例，还是应从测试用例设计上下功夫。

 

Ø 不间断的测试：微软采用“每日构建、自动化测试”的方式

ü 微软建立了一套自动化测试平台（据讲师介绍微软全部是自己开发的测试工具，花了5年多时间，各类工具有40多种，再由总控平台统一控制）

ü 采用自动化测试后，任何时候都执行所有用例（微软亚洲工程院的项目每天对3万多条测试用例重复开展自动测试，产生300万条测试结果）

思考：

a)      我们目前全是手工测试，不可能做到任何时候执行所有用例。项目过程中分为多个测试工序，不同测试工序选取不同级别的测试用例执行，手工执行重复测试容易疲劳，带来的风险是修复BUG引起的新BUG可能被遗漏，或对未修改功能产生的影响被忽视。对影响点的识别与评估是我们需要加强的。

b)     微软的“任何时候执行所有用例”是一种理想状态，虽然自动化测试是行业的发展趋势，但我们不可能做到100%覆盖，可挑选出基本用例开发自动化，做到每日构建的基本用例验证，避免最基本、最不可接受的程序BUG。

 

 2         测试计划与用例设计

1)       制定计划的原则

Ø 将项目切分为多个里程碑，分别进行管理。

ü 确保当前盖的这层楼是想清楚、明确后再去盖的

ü 确保已完成的是绝对可靠的

Ø 提前定好项目标准

ü 在每个里程碑节点完成后进行回顾

ü 最终标准达成后即发布

ü 微软的发布评估标准（Release Criteria）：

○         95%的测试用例通过率，且持续时间>5天。

（不是累计达到95%，而是5天每天达到95%）

○         允许有5%的case不通过，但级别不能是重要的case..

○         代码覆盖率>85%（指测试用例执行的代码覆盖率）

○         ZBB零bug边界，保持5天

（微软在ZBB后，会安排全员大扫除，连续5天时间未发现BUG，才可发布）

Ø 关注模块间的依赖

ü 确保每个模块及所有边界都有人测试，避免重复和无人测的情况

ü 边界出存在小范围重复测试是允许的

2)       制定测试计划中，发现人员不充分，经验不足怎么办？

Ø 从工程的角度考虑问题，不仅仅是要求测试人员之间分享经验，还需要有效的标准

ü 将有经验成员的能力转化为形式：将有能力者的思维方式形成模板

ü 一个好的模板，是节约人力成本的好办法。还能弱化对每个人的依赖度。

ü 重视过程文档：写文档，重在思考的过程。强调起清楚，再干活

ü 新老员工之间产物的区别，应转化为中间评审打回返回次数的区别，最终文档的质量应该是完全一致的

ü 文档质量的高低：50%取决于作者，50%取决于对该文档抓质量的程度

Ø 检查需求细不细

ü 避免主观语句（性能高，响应速度快等这样的形容词），速度响应快，快到多少秒。

ü 一定要量化需求，而不是主观感受。

Ø 凡事以数据说话，这样才能有说服力。

 

思考：

   目前我们的流程、体系，与上面的大部分原则不谋而合，有些点我们现在是做了，但还做的不到位，应彻底落实。

a)      微软的发布标准是非常清晰，且完全是用数据说话，从中可以看出微软对质量的重视程度。我们目前的发布标准虽然也会依据质量目标的达成，但标准较为模糊，更多的还是测试团队的感知，测试人员测到最后阶段，也都很疲劳希望能够尽快发布了。这也是导致我们产品发布后立即频繁发补丁的原因之一。

如何清晰定义发布标准，使用有效的数据说话，是我们需要改进点之一。

b)     一直没太搞清楚“代码覆盖率”用什么方法来测算，现在我们只能测算到对功能点的覆盖率（颗粒度太粗），如果能够测算对代码的覆盖率会更准确，有助于用例设计覆盖率、测试质量的有效提升。

老师介绍一种方法是在代码中所有分支处设置数字标识，测试执行时验证该分支就会弹出标识，最终检查是否所有分支标识均进行了验证。这对开发人员要求较高，有一次与金碟的同行交流，他也提到他们会在代码里埋探针，来检测执行的代码覆盖率。不太清楚这样做会给开发带来多少工作，在我们团队中是否可行？

c)      我们对模块间的关系影响也有考虑，但对影响的识别、评估能力欠缺，对系统间的边界识别容易遗漏，计划中没有明示对边界的处理。

在设计阶段，会对所有接口进行梳理，进行接口设计。测试人员在设计用例前，也应对系统与系统间、模块与模板间的边界进行分析识别、统一梳理，并落实至具体计划中。

 

3)       如何提高测试用例的编写水平

Ø 积累测试素材：建立内部的测试素材库

比如对于文本框的验证，一般都是验证那几项，有效数值，无效数值，空格，空等等，这些测试用例在每个项目中都可以反复使用。

Ø 任何情况下都必须使用边界值分析法

这种方法设计测试用例发现程序错误的能力最强

Ø 必要时用等价类划分方法补充一些测试用例

Ø 用错误推测法再追加一些测试用例

Ø 不要因为实现的困难程序而影响设计用例

Ø 测试方法的复用

对于有继承性的项目来说，用之前编写的测试脚本或自动化测试工具以达到测试方法的复用

Ø 自动生成测试用例

依据用例设计的常用方法，找出规律，用技术实现思维

 

思考：

a)      目前专业的设计方法非常多：等价类、边界值、因果图、判定表、正交法等，但真正设计用例时，不是挑选一种设计方法就能设计出好的用例，也没有时间去依据这些方法的步骤进行一步步分析，更多的是一种牢记于心的设计思想，需要测试人员依据设计思想直接编写用例。

b)     当然，对于核心业务、复杂功能必须先进行设计分析，设计分析时主要是对客户应用场景的分析，再结合用例设计方法补充各类分支、异常场景。

c)      测试素材的积累，我们目前已经梳理了通用测试用例，但执行并未到位，测试过程中往往忽略了通用用例的执行，通用用例都是有规律可循，要考虑用技术手段实现通用用例的自动执行。

d)     我们目前的测试用例只描述到特征，不会编写测试数据，不同经验的测试人员执行相同用例结果会出现不一致，差异在于实际使用的测试数据不一致，有经验人员使用的一组测试数据更容易发现程序问题。特征与业务、设计相关，不具备通用性，但可以考虑依据特征自动生成测试用例数据，并不断完善生成的规则，将经验转化为技术。单字段的测试数据易实现，难点在于组合数据的生成，输入之间存在各类业务逻辑、控制，虽然很难，后续在自动化测试层面还是值得做一些尝试，实现自动化的前提是要有清晰的输入、输出数据，手工准备测试数据的工作量是相当巨大的。

 

1         自动化测试

1)       对自动化测试的理解

Ø 自动化测试，它是软件质量的保障体系，自动化测试最大的优点就是把重复性的劳动交给计算机去做，包括review静态代码，每个版本更新后都需要重复测试的功能，或者是大量的数据的重复操作。这些如果在项目之前都开发完成的话，对于软件的效率会有极大的提高。

Ø 微软自动化测试体系的最核心价值：每天都可以对所用的用例进行覆盖（日覆盖），不是常规企业的月覆盖或者周覆盖，其发现缺陷周期降到按天来计算。

（我们目前是一个发布版本累计才能做到用例的完整覆盖）

2)       自动化测试的局限性

Ø 自动化测试前期投入很大，包括编写自动化测试工具，开发自动化测试脚本。如果项目周期短，没有可持续性不适合自动化测试。

Ø 自动化测试的技术门槛相对较高，测试团队整体水平不高的情况下无法完成工具的发开，心有余而力不足。

Ø 对于没有预期结果的测试，不适合自动化。

Ø 对于用户体验的测试，主观性比较强的不适应自动化

3)       自动化测试用例设计有关原则性要点

Ø 每个case都可独立运行；

Ø 每个用例执行完毕后，清理产生的垃圾，恢复用例执行前的环境；

Ø 数据驱动、本地文件驱动

Ø 用例设计要考虑复用素材库，素材库内容包括各种对象（保存在本地文件或者数据库中）和函数(DLL库）；

Ø 自动化测试过程，既要处理测试发现的产品bug,也要处理自动化测试代码本身的bug(自动化脚本代码本身的bug)。

4)       自动化测试涉及的技术（这些技术具体实现讲师没有详细讲解）

Ø 测试探针技术

Ø 代码注射技术:修改目标码，对目标码中增加测试运行代码，包括错误注射（Fault Injection）等

Ø 单进程封装:测试代码和应用代码封装在一个进程中运行

Ø 用程序读程序（用一个懂的人将读程序的思路写成一个读程序的程序：白盒测试中的静态代码检查，检查规范、定义）

 

思考：

a)      微软的测试工程师都具备很强的开发能力，都可以编写自动化测试代码，我们并不具备这样的能力，目前是借助商业的自动化测试工具，开发一套自动化测试框架，采用数据驱动+关键字驱动的技术，合理的规划、封装，尽可能让测试人员易用，理想状态测试人员就像写用例一样，由框架后台解释为可自动执行的脚本。框架设计过程中可借助培训中设计原则的一些思想。

b)     将通用用例测试实现自动化是重要要考虑的一个点，通用用例在每个功能、每个页面都需要重复执行，测试的方法、标准一致或有规则可循，目前手工测试并没有完全执行，如果全部执行，工作量是非常大。这一块能够实现自动化测试，将给测试效率带来很大提升。

c)      从开发层面，可以考虑采用一些静态代码检查的工具，对代码规范、严谨性进行检查。

 

2         测试管理

1)       管理理念

Ø 流程就是一个无处不在的管理者

微软软件研发通过使用流程管理制度化的工作方式，代替经理们进行日常经常性的工作管理，经理可以有更多经理用于团队重要工作任务的规划

Ø 管理是为了面向现在和未来，而不是追究过去

Ø 不可能事事尽美，但要将每件事情弄清楚

Ø 认定目标必须要有结果

Ø 当某件事推动不力，特别是涉及协作时，管理者要考虑建立流程机制

Ø 很多事情看起来很难，但注意只是很难，不是无解的

Ø 人员永远不可能足够的，投资回报率的问题，人员不够要加人时，考虑以下几个问题

ü 现有的人有没有充分应用？

ü 加人是为了解决什么问题？

ü 可能通过提升效率、通过技术手段去解决？

ü 加人怎么用？现在加了，后续能够持续使用吗？

2)       让数据说话：通过对测试用例和BUG的追踪统计，看出项目组发生了什么、正在发生什么、甚至将会发生什么

Ø 建立测试度量体系

微软自主开发了一套测试平台，测试过程、结果全部统一管理，自动获取各类分析数据

ü 缺陷库建立、缺陷追踪体系

ü 用例库建立

ü 测试结果库建立

ü 数据统计与分析系统

用例库、缺陷库和结果库是数据分析、辅助决策的支撑平台

 

目前我们只是建立了缺陷管理系统，测试用例还是用EXCEL文档维护，测试结果库更是缺失，测试用例的维护、复用、统计都存在问题，下一步有必要建立测试用例管理系统，之前也研究过TD、QC等商业管理工具，与我们目前的用例结果、管理方式差异很大，建立考虑自主开发用例管理系统，并与BUG管理系统、自动化测试集成为同一平台。

用例库建立基础上，以后再逐步考虑结果库的建立，用于数据统计、决策分析。