《笑傲测试》笔记

笑傲测试 魏伟

 

第一式庐山面目：测试及其核心价值

第二式蓬门始开：测试人员的素质

第三式仙源何处：测试的主要门类和方法

第四式矫如龙翔：如何开发测试用例

第五式浮云蔽日：如何定义测试流程

第六式伯仲伊吕：写测试计划

第七式语报平安：写测试报告

第八式春寒锦袍：管理和激励测试团队

第九式江上鼓颦：产品上市之后的测试角色定义

 

第一式庐山面目

所谓软件测试，就是出于正常合理的目的，在特定的时间环境，用事先制定的标准衡量一种软件产品和特性是否符合预期。

测试本身并不是在创造什么东西，而是由确认、验证、保证、评估、审核、报告等动作组成的统一体。

测试有两个主要作用，第一是确认我们在做一个正确的东西，正确的标准是软件的特性说明书（specification）。当说明书有遗漏或忽略时，标准来源于大家的约定俗成或者高层人士的判断。第二是确保开发活动的方向是正确的。为了保证方向正确，提供测试报告。

 

软件测试报告的主要内容

报告元素	作用
软件成熟度的定量评估	通过一种算法得出一个定量的数字来标示当前软件的成熟度。这种算法不同的软件有不同的定义方式，但总体来说和问题的严重性、数量、出现频率、新模块的数量和规模等等因素相关。
测试用例通过率和不通过率	最简单最一目了然的方式来了解当前软件的状况。通过率越高不通过率越低，软件越稳定，但缺点是无法与那些测试用例以外的问题匹配
软件成熟度的变化趋势	通过变化趋势，我们能看出软件变成熟的趋势，可以帮助管理者预测项目还需运行多久
今后可能的问题和成熟度走向	与变化趋势相关的信息，尤其适用于当开发进行中，一些新的不稳定模块即将加入到软件基线中，那么在可预期的将来这些模块会带来新的问题，从而影响软件的成熟度
严重问题的列表	最实际的反映当前软件的风险在何处，尤其当讨论产品是否可以上市的时候，这一内容尤为重要。
一些关键问题的风险评估	有问题不一定严重，问题严重但用户不见得关心，这些信息需要借助测试人员的经验和判断，管理者也会参考这些信息做出正确的决定。

 

第二式蓬门始开

七大素质：

1.       自信自尊，充分热爱测试

2.       尽职尽心，以质量为己任

3.       有大局观，不为名利所扰

4.       孜孜不倦，刻苦钻研技术 （测试技术，测试工具，测试对象）

5.       悲观工作，但不悲观生活

6.       心细如发，绵密绝无破绽

7.       发散思维，习惯剑走偏锋

五大学识：

1.       经济学

2.       心理学

3.       统计学

4.       刑侦学

5.       逻辑学

其他：职场之“道”：诚实，正直，志向远大，热情。

 

第三式仙源何处：测试的主要门类和方法

在测试项目中设计最适合的方法能在很大程度上加快测试的进度，达到事半功倍的效果。

测试种类：自动测试，手工测试，压力测试，协议一致性测试，互操作性测试，现场测试，用户界面测试，文档测试等等。对于不同的项目和不同的阶段来说，往往需要用到不同的测试手段。测试人员需要在平时积累这些测试手段的特点和适用范围。

白盒测试：从程序的内部结构设计入手。早期进行，修改成本低。但是很难做到全面覆盖，无法发现程序逻辑的错误或者是对需求的遗漏等问题。

黑盒测试：很难覆盖所有的代码，问题定位难度较大（要求相应提高软件可测性设计）。黑盒测试更适于给出全局性的判断。黑盒测试对技术要求不高，如何在不了解系统结构的条件下系统的机会、组织和设计整个测试过程才是黑盒测试的关键所在，也就是说，怎样做测试才是最系统化和最有效地。

自动测试：优点是可重复性，执行的速度和效率（适合疲劳性测试，压力测试）。缺点是前期投入较大（买工具，培训，脚本开发），过于机械呆板。

自动和手工测试的应用场合

	适合自动测试	不适合自动测试
待测软件成熟度	适合软件比较稳定，功能比较成熟的软件。比如已上市软件的版本升级测试。	开发阶段的软件，功能不够完善，自动测试无法顺利运行很长时间，效率无法得到体现。此外开发阶段如果设计有时变更，会严重打乱自动测试的进度。
待测软件测试周期	测试的轮次越多越好。如果某单一产品测试轮次不够多，而其后续产品能够继承绝大多数的测试脚本，也在适合之列	产品单一，测试轮次很少，没有后续产品。功能点无法有效重用
测试数据量	在大业务量测试时有时需要营造巨大的测试数据或测试输入。	数据量很小的功能验证
待测软件输出类型	自动测试的核心难点是测试结果和期望结果的自动比较，所以软件的输出结果必须是机器可识别的，如数字文本等	输出结果是未经数字化的图像，震动，声音等。

压力测试stress testing：为某个单一的目的，大强度的重复性的使用软件的某一功能，以期发现该功能在压力条件下的性能指标。当测试软件长时间运行的性能时，可能叫疲劳测试；当聚焦在某一特定功能的循环使用时，可能叫专项测试Focus test。适用场合：1产品上市前对不够自信的功能进行集中专项的压力测试，俗称大猩猩测试。2产品上市后对客户反馈的模糊信息进行集中地测试以精确定位问题。

协议protocol一致性测试：主流的协议有协议分析仪等测试工具和设备，此外还可以组建实际测试网络来验证协议的规范。测试人员要做的首先是理解协议，其次把协议的设计语言翻译成测试语言，营造测试环境以创造协议定义的条件，最好执行测试。

互操作性测试Interoperability test: 验证自己的产品和其他的设备是不是能够正常通信。

现场测试：着重考察通信终端设备和不同网络设备之间信号特性相匹配的测试，如无线通信系统。因为没有时间和金钱去覆盖全部的实际网络，因此做现场测试的一个先决条件是了解已有网络的配置，选取一些典型的区域。

用户界面测试：指标：1.界面的有效性，即执行特定操作所需的时间或步骤越少越好。2界面连贯性。3界面传统性。

第四式矫如龙翔：如何开发测试用例

设计和构思测试用例时，要像织网一样把测试点设计周密、分布均匀，使之有效和有意义。（简明扼要、分布均匀、不能有太多重复的用例、又不能有明显的疏漏）

标准的测试用例，一般包含这样一些内容：编号，测试模块，标题，测试目的，级别，先决条件，输入，期望输出。

要能写出高质量的测试用例，需要测试工程师们认真思考这样的问题：

1.        如何保证合适的测试用例覆盖率：需求跟踪矩阵。让测试用例均匀覆盖功能点的核心是没有重大疏漏。一个测试用例应该对应至少一个功能点，那么要保证测试用例覆盖率尽可能完整，首先要明确待测功能中有哪些功能点，其次才是如何是测试用例对这些功能点进行覆盖。需求跟踪矩阵是对功能点进行有效管理和密切跟踪的一种工具。

2.        如何确保紧跟开发文档的变化: 眼观六路耳听八方，盯紧开发中的任何变化，及时更改。项目管理中最难做到的就是可视性Visibility

3.        如何把测试用例的重复率限定在适度的范围：1）优化测试用例数据库的结构，分类要细致，关键词要准确；2）简单或重要的功能点要容忍一定的冗余；3）花费时间长，执行复杂的测试用例，对重复的检查要严格一些；4）夸口测试用例的数量是没有意义的。

4.        如何实现“以测养测”式的测试用例更新：及时补充新的有趣的值得测试的测试用例。建立定期评审Review的机制来弥补被忽略的功能点和根据实践中遇到的各种情况来更新补充测试用例。

5.        如何实现测试用例在不同产品间重用：1）避免设计过于特定化的测试用例；2）尽量缩小单一测试用例的覆盖范围（短小精悍）

 

第五式浮云蔽日：如何定义测试流程

测试过程中如果没有一个清晰地流程，测试项目实施起来就像身在浮尘中一样隐约混沌看不清楚。好的测试流程必须满足一柔一刚两种要求。柔（流畅）：测试的所有活动能够被组织和定义得平滑高效，实施起来没有阻滞和混乱。刚（严格）：组织中的每个人能够充分了解自己工作的输入条件和输出准则，大家既有检查上一步工作是否到位的权利，又有按时保质保量完成工作地义务。在测试流程中，好的定义仅仅是成功的开始。

柔性要求：先看看有哪些测试活动，看有哪些是相互冲突的（必须有先后次序），哪些是互为因果的。然后把所有测试活动画成工作流程图，以便控制流程和总结经验。

刚性要求：做一个模块的测试需要提供的输入条件：

1）   测试用例：需求跟踪矩阵，定期Review and update

2）   测试分工：测试经理下达书面的测试任务书，让测试人员清楚地了解自己的任务

3）   测试工具：一要好用（确实能帮助测试）。方法—制定一个规范的测试工具评估表，按照测试需求把测试工具的表现做定量的评估。二要大家都会用，方法—制定完备的培训计划，让每位成员学到工具的使用方法和各种规则，同时管理者能够。一目了然的看到培训的组织和参加情况。

4）   提交物的模版。简单清晰，用形式来约束内容。但是在模版推行之前，在设计阶段一定要严格的评审，保证模版的内容得到大多数使用者的认可。要让使用模版的人也参加评审。

模块测试的输出：

1）   测试结果：当测试粒度均匀时，能够定量的描述当前软件的稳定程度。制定有针对性的工作流程来降低不可测率。从失败率看出软件缺陷的纠正趋势。

2）   问题报告：清晰、详尽，目的是让开发人员能够得到足够的信息去重现并解决问题。可以用问题报告模版来避免遗漏信息，由测试团队中的QA来抽查问题报告的质量，由问题管理员对问题报告进行初步分析，看是否重复和可忽略，在按模块分给对应的开发小组（可行？）

3）   调试信息：测试开始之前就要有深入的培训，明确哪一类问题需要提交哪一类调试信息。获取调试信息的手段、工具、配置等。但复杂的数据量大的调试信息，默认情况下可以不输出或者只输出一些简略的，但是测试人员要做好工具的配置。建议测试人员自己也学会读懂这些调试信息，明白错误的根源在哪。

4）   模块测试报告：及时，内容既粗且细，有简明扼要的总结陈词，尽量提供模块的稳定程度（如测试用例通过率）、稳定趋势（通过率的变化）、严重问题的列表

5）   修改的验证Bug-fix  validation：对测试人员应该是优先级最高的。

对测试过程进行理性科学的评估是必要的（测试人员的自省，及时发现并纠正测试过程中出现的问题）。测试过程评估的关键是不走极端，评估的方案必须是可执行的。可行的一种方案是组织一个兼职的监督小组，成员包括测试项目组长，若干测试工程师和独立的软件QA。由他们按照事先约定的项目和内容定期评估测试过程。不仅评估测试用例执行的结果，还要评估测试过程的合理性和效率。

项目评估方法

序号	项目	推荐的评估方法
1	衡量测试计划制定得是否合理	计算测试计划执行率：执行时没有被更改的条目/计划定义的总条目
2	测试人员的能力和经验	统计测试团队中相关测试经验的平均时间
3	测试人员的培训	统计测试流程和技术的培训条目和培训的覆盖率
4	衡量测试用例开发/重用的策略是否合理	测试用例开发/维护的人力占总测试项目人力投入的百分比。用例的开发是在准备期，如果准备期的投入太大说明用例开发和重用的策略有问题
5	衡量测试执行的人力分配是否合理	通常需要看每一种测试任务中（执行测试用例，自由测试等），投入的人力和产出物（bug数）的比例是否合理。
6	测试报告的种类和频率	测试人员每周花在测试报告上的时间一定不能高于2%。事先制定好清晰简单的模版，切忌中途修改。
7	测试流程的遵守程度	通常由QA来监督流程的执行情况，统计发现的流程不遵守的次数（抽查）。原因可能是测试人员的疏忽，更大可能是流程的不合理
8	测试手段和工具是否合理	由不可执行的测试用例比例来衡量
9	测试执行结果抽查正确率	抽查失败的数目/抽查总数目，建议不要过于紧盯细节，这样会降低测试效率。要更多的侧重发现某类问题，而不是某个问题。
10	测试用例修改率	从项目开始到结束有多少测试用例被修改过
11	挑选测试用例所花时间	从数据库中挑出适合本项目的用例。衡量测试用例的开发策略
12	测试用例的执行时间	与不同测试轮次的对比可以看出当前测试轮次是否出现了问题
13	Bug的深度挖掘	如果给测试人员的任务压得过重，我们往往会忽略对低重现率的严重问题的深度挖掘
14	错误报告	错误报告的模版和格式能保证测试人员在第一时间把绝大多数重要的信息报上去。统计在平均情况下，一个bug的解决需要测试工程师和开发工程师往返几次的沟通。

 

第六式伯仲伊吕：写测试计划

测试经理在测试项目的计划阶段要像三军统帅一样，了解你的任务，构建你的团队。

测试经理要综合考虑以下影响测试的因素：

1.        测试组建立：1）测试设计和执行组；2）技术支持组--测试工作平台（包含测试用数据库）和测试环境（测试项目需要的环境，测试执行的环境，如自动测试工具，数据采集工具）；3）问题管理组；4）质量监控组

2.        测试范围的选择：本项目需要的测试类型和执行人

3.        测试组的培训：技术类（制定培训需求，请求其他部门支持）和流程类（每一个测试活动都有相应的流程指导书）

4.        测试平台的选择和配置：测试平台管理测试用例、测试计划、测试报告、问题跟踪数据库。需要考虑平台的安装，培训，维护等

5.        测试技术和工具的选择：了解自己的项目需要什么测试，了解每种测试技术适合的范围。之后得出结论，在本项目中，哪种技术是最有效地，以及针对这种技术需要做哪些资源和人力方面的准备。

6.        测试执行的日程和进度：明确清楚地回答这几个问题：什么时间，在什么版本上，出于什么目的，做哪些与测试相关的活动。测试项目至少进行四轮：1）验证功能，2）验证问题是否被修改，3）验证性能，4）全面验证所有待测点。

项目里程碑：

M0 软件项目启动，需求定义阶段：测试人才储备期（人力和培训）

M1 分布式开发阶段：测试的技术流程准备期，计划，技术，工具，环境，团队，流程等

M2 总体联调阶段：测试的全速实施期

M3 产品上市：根据市场反馈，帮助开发人员尽快复现问题。

在实际层面上，测试日程的制定需要根据两个文档，第一是总体的项目时间表，第二是项目的软件版本发布计划，然后基于这个版本发布计划和每个版本的特殊性，还有测试团队的人员配备情况，遵循这样的一些原则来制定测试日程：第一，每个软件版本一定要有一个版本基本测试release test，看是否值得一测；第二，在所有功能集成起来之前不需要系统测试，但应该按照集成模块的次序进行各个子系统的测试；第三，现场测试和互操作性测试要在系统测试至少两轮之后才开始，以保证最基本的功能性问题已经被发现并解决；第四，压力测试发生在上市之前的一两个版本上，主要目的是试图复现那些影响较大但复现率较低的问题。

7.        测试用例的设计、维护和更新：测试用例开发遇到的问题有需求变动或不够明确、对功能不够理解，解决办法是和开发达成共识，每天开发抽出半小时回答测试人员疑问，任何变化都要在需求变更数据库中存档。

测试用例更新：1）需求变动；2）内部评审时发现测试用例覆盖不够全面，需添加新的；3）自由测试发现问题。

8.        测试环境的设计和搭建：        

9.        测试文档的格式和提交时间：问题报告和测试报告（某子模块测试报告、项目测试报告、测试任务书、测试日志），测试计划要清楚地写明对这些报告内容和时间上的要求。

10.     测试入口/出口的checklist：入口和出口准则清楚地定义什么情况下可以开始测试和什么情况下应该结束。

测试循环开始的Checklist:

1)       版本的发布是否遵循了《项目软件版本发布计划》

2)       随着版本的发布，是否一起提交了版本发布说明Release notes

3)       版本发布说明中是否详细描述了此版本与上一版本的区别

4)       改动部分是否执行了单元测试和集成测试，是否有测试报告

5)       版本发布前是否对简单功能（开机、打电话等）进行了基本验证

6)       版本发布说明中是否包含解决问题的列表和未解决问题的列表？

测试循环结束的checklist：

1）   该版本的测试报告是否已提交？

2）   测试报告中是否对软件的状态下了结论？

3）   各子模块测试的报告是否已提交？

4）   是否100%完成了更改问题的验证工作，是否有验证结果的汇总？

5）   该版本上新发现问题的列表是否已提交？

6）   所有遗留问题的列表是否已提交？

7）   所有遗留问题中最严重的top10是否已提交？

8）   以上所有输出物是否都是按照标准化文档模版书写的？

11.     测试组成员的管理和激励机制

12.     测试过程的流程和定义：测试并不是技术驱动的工作，更多的是管理和流程驱动的活动。测试计划中可描述两大流程，测试管理流程（计划、实施、报告）和问题管理流程（如何管理、维护和跟踪问题）。

报bug可能的问题：1）描述不够全面准确；2）重复提交同一问题；3）测试人员对功能理解不够；4）验证问题的效率和准确性不够。解决办法：1）QA抽查问题单的输入质量；2）提交问题前需要搜索相关问题已确定没有重复提交；3）增强培训，减少误报；4）在流程上保证验证问题的优先级。

13.     测试过程的质量监控：六个关键点1）测试计划的风险评估；2）测试文档的质量；3）计划实施的质量；4）测试报告的质量；5）问题管理的质量；6）测试范围和覆盖率的完备性。

 

第七式语报平安：写测试报告

测试报告读者是项目管理者，他们的特点是忙，故报告应言简意赅，图文并茂。原则：

1）   字数要够少够精炼。为节省自己和读者的时间，用最少的篇幅和最简单的结构同时传达出所有的关键信息。首先减少说废话套话，其次要避免过于细节，可用附件提供细节；最后信息要分层派送，标题+展开+结论和评价。

2）   图表要够多够通俗。

l          饼图比大小（各因素之间百分比的关系）；如各模块剩余bug数

l          柱图比高矮（数字的大小）；如测试用例的通过率，问题发现的个数等

l          曲线图上蹿下跳（数字的变化趋势）；如软件稳定度的变化，问题解决率的变化

l          面积图比胖瘦（多个因素叠加起来的变化趋势）；遗留问题的解决趋势

l          图表要用得正确才有效（适用的场合、范围和用法）。项目管理者关注的大部分东西都有合适的图表来表示：1）总体成熟度和子模块的成熟度；2）缺陷分布；3）缺陷趋势，成熟度趋势；4）问题解决趋势。

3）   颜色鲜艳，通俗易懂。

4）   既报喜又报忧，汇总出最严重的问题。

5）   报告时间要及时

6）   罗列的数据准确有力。可以建立一种避免错误的机制：抽查（持续，比例事先约定，抽查执行人有经验或够权威），参考以往的趋势。

7）   逻辑（结论和评价）要经得起推敲

第八式春寒锦袍：管理和激励测试团队

建立良好的团队气氛，需要考虑四大因素：

1）   管理者的威信。“威”指权力和能力。最考验能力的地方无非是工作任务的分派（人尽其才、物尽其用）和人员绩效的评定（一视同仁，不被主观印象所左右）。“信”指人有信誉，讲信用，做事公平（凡事按流程步骤来，不能一味的通融和糊涂）。员工对团队的忠诚度取决于公司和团队的长远发展，取决于自己获得的短期和长期回报，最后还取决于团队管理者的个人魅力。

2）   团队的目标和发展方向。目标不空洞。生存的唯一有效途径就是不断地学习、培训、总结、充实、提高。测试团队有很多独特的技能需要具备，因此管理者要始终把培训放在一个相当的高度去重视并监督实施。

3）   团队优先，个人次之。

4）   科学的绩效评估和奖励体系。 建立一套鼓励先进，鼓励合作的激励机制，保证团队中每个人对其都比较在意但又不能过度追求。考核测试工程师的工作效果，通常体现在这么几个方面：一是数量，包括测试用例设计的数量，执行的数量，发现问题的数量；二是质量， 测试用例设计和执行的质量，问题报告和其他报告的质量；三是团队工作。对每一个项目，需要两个输入，加权值和得分。测试经理要做的就是公布一张表，事先列出这些元素。考评体系的复杂性一定要控制在可接受的范围内。重奖团队，轻奖个人，照顾到突出贡献者和进步最快的新成员。预留一些预算对项目后期严重问题的重现进行奖励。还可以引入外包增加竞争。

 

第九式江上鼓颦：产品上市之后的测试角色定义

处理投诉的三个原则：问题准确，快速定位和解决问题，安全的解决方案。

测试团队的四个主要任务：1）搜索历史，2）重现问题（压力测试），3）去伪存真，简化重现步骤，4）更新版本的测试。

产品上市后要把反馈体系和调查问卷准备好。调查问卷内容（一般性产品）：用户的联系方式，产品编号，用户购买产品的时间，出现问题的版本，用户再投诉的版本，出现问题的频率，出现问题的基本重现步骤，出现问题后的一些基本症状，出现问题后如何复原。对网络相关产品，容易出现问题的地点，问题开始出现的时间，出现问题时其他产品反应如何。