软件测试

二．测试人员的角色

“有的人喜欢创造世界，他们做了程序员

有的人喜欢拯救世界，他们做了测试员"

三．软件测试过程

软件测试贯穿于整个软件开发生命周期，测试过程可以分成几个阶段，每个阶段都各有特点，都是一个成功的测试不可或缺的组成部分。

那么每个阶段的基本功有哪些？

3.1 需求分析

需求文档乃测试用例的设计之本。

在测试活动中，首先需要明确测试需求（what），才能决定怎么测（how），测试时间（when），多少人（who），测试环境是什么（where），测试中需要的技能、测试工具以及相应的背景知识、测试中可能遇到的风险等等。

进行需求分析时，基本功要诀：需求检查Checklist。

?需求检查Checklist

测试人员可以根据自己的产品和项目具体情况, 列出适用的需求检查

Checklist, 帮助自己在需求阶段介入测试。

一份参考的例子（来自KM）：

3.2 测试计划

测试计划是测试过程的整体设计。

包括对测试范围、测试风险进行分析，对测试用例、工作量、人力和时间等进行估算，对测试采用的策略、方法、环境、资源、进度等做出合理的安排。

制定测试计划步骤如下：

下图是测试计划的例子：

3.3 测试用例设计

测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

用例涉及的方法主要有：基本路径分析、等价类划分、边界值、因果图、正交实验法、组合覆盖设计法、分类树设计法、场景设计、错误猜测法、决策表。以上方法网上介绍很齐全，在这里笔者不做赘述。若需要再出一期介绍。

3.3.1 如何打造高逼格用例？

怎样打造一份高质量用例？

基本功要诀：善用工具——excel与MindManager的完美结合。

1）拿起需求，需要考虑测试策略，而不是急于实现用例

测试策略，简单理解，就是开展测试工作的关键行为。比如一次测试，需要进行功能测试、性能测试以及适配测试，则这些都应该先形成一个清晰的测试策略，去指导测试工作的进行。

2）测试策略可在Mindmanager等其他方便改动的软件上记录

Mindmanager即思维导向图，用于书写测试思路，方便用例修改和位置等调整，使用时自由无拘束，故建议测试策略可在这个工具上得以实现。

测试策略可从以下几个方面进行考虑：功能点、异常、边界、极限条件、适配测试以及性能测试。（参考下图：以快捷悬浮窗为例）

3）根据测试策略，将功能点测试罗列到excel中并具体化用例

永远记得Excel是写用例的一个工具，不是构造思路的工具。写的格式可以参照下方：

每一项的写法：

四级模块（原则：名词，简洁）

一级：产品名称

二级：模块名称或特定测试项（版本更新、升级测试、云指令等）

三级：子模块名称或某一关注项

四级：测试项，关注点

●用例简要

用例简要包含该用例的测试目的，会有非常简要的前置条件和测试结果，会具体化一些。是唯一的，可以跟其他用例辨析出来。绝对不是一级到四级模块的简单组合。

●“测试步骤”与“预期结果”

每条用例都是一个完整的测试过程，有操作，有结果生效，尽可能形成闭环。

对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，需要在操作步骤中详细列出，用简洁但清晰的描述，避免太口语化或啰嗦。

单条用例中，测试步骤及需要检查的结果不宜过多。

●执行结果

在测试条件下按操作步骤进行操作后实际的输出结果。实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

●用例优先级

?同类的测试点取一个为1级

?交叉选择，如A、B两个页面测试点类似，A的aa检查项为1级，那么B的aa检查下就可以降低级别，改bb检查项为1级

●用例最后更新版本

用于管理每个迭代用例。

4）利用checklist进行用例设计

可以根据自己的产品及项目实际情况，列出用例checklist。这里提供一些参考如下：

3.4 测试的执行

当测试用例编写完成，就进入到软件测试最主要的阶段——执行测试用例。

3.4.1 测试开始标准

1）测试计划已制订好；

2）测试用例已编写完成，并已通过评审；

3）存在已提交的可测试的系统/软件；

4）测试环境已搭建完毕。

3.4.2 测试退出标准

1）测试用例全部通过；

2）存在的问题已得到合理的处理。

3.4.3 测试停止标准

1）近半数以上主路径测试用例无法执行；

2）测试环境与要求不符；

3）开发中需求频繁变动。

3.5 缺陷纪录及跟踪

用例执行过程，遇到缺陷时需要记录下来并做跟踪，直到问题被解决。那么如何去记录一个bug呢？

3.5.1 bug涵盖内容

一个缺陷要机型记录时，需要涵盖以下内容：

1）标题：

格式：【版本＋机型＋模块】bug描述。

2）条件

机型、Android版本、是否覆盖安装、覆盖前版本、网络类型等信息、服务器类型（正式／测试）等。

3）详细步骤

发现bug需要的步骤。在提交bug之前，先进行几次尝试，尽量找到必现路径，并把步骤缩减到必要执行才能出错的几个步骤。

4）现象

测试结果与预期结果不一致的地方，客观反映事实。

5）重现规律

必然重现、随机重现或很难重现。亦可写上具体操作几次出现几次。

6）预期结果

描述本应该出现的正确现象

7）严重程度与对应处理优先级

3.5.2 如何提交一个高质量bug

了解bug涵盖的内容还不够，到底怎么样才算是提交了一个高质量的bug？1）不要出现错别字；

2）不要重复提交bug

路径不同，问题现象相同——视根因而定，如不同路径导致的crash问题，很可能是不同原因导致的，分开提交bug；如果是同个功能点从不同入口执行都出错，很可能是相同的原因导致。

路径相同，问题现象不同——合并到一个bug中，把问题现象分点描述清楚。

3）附加必要的截图和文件

一图胜千言，把错误界面截图，上传到bug描述中，必要时在截图中用笔画圈出需要关注的地方或加上文字注解。对CRASH、ANR问题，添加Log、traces文件等，方便开发人员定位问题。

4）录完bug自己检查一遍

对于新手测试，在录完bug之后，自己先检查一遍，语意是否通顺，是否有歧义，表达是否简洁清晰。

5）当面沟通

如果这个bug涉及比较复杂的背景或其他原因较难用书面表达清楚，可以在提交bug 之后马上找到相应的开发口头解释，而不是等待开发来找自己了解，提高bug解决效率。或者这个bug会阻塞一部分用例的执行，应及时与开发沟通促进解决。

3.6 让你的测试报告高大上

一份出色的测试报告的标准：准确、清晰、价值。

那么，如何让你的测试报告变得高大上？

（1）突出关键点，结论先行

利用金字塔原理，把关键信息如测试结论放在报告开头，直接说明突出的问题，需要谁关注。提炼关键信息，分一二三点描述，内容清晰易懂、简明扼要。永远记住TOP3是最关键的信息，把你的关键信息在几十秒内展现给阅读者。

（2）发现问题是基本，给出解决方案更有价值

仅仅给出问题只是完成任务，但如果还能给出可行的解决方案，那会让人刮目相看。

比如做电量测试，发现了耗电异常，如果能具体定位哪里出问题甚至提出修改建议，那么无疑这是一份超出预期的测试报告。这条原则也适用于与老板的工作汇报或沟通上。

（3）图表分析

能用图，不用表；能用表，不用字。

（4）数据描述

虽说数据可以对问题做量化描述，但直接摆出未经提炼的数据，会让看报告的人，难以一下抓住重点。

（5）纵向对比

纵向对比（与以往版本对比）可反映产品质量的演进，让读者对测试报告结果有更好的认知。比如在性能报告、一些迭代数据总结中，经常需要纵向对比。

（6）细节和专业度

如果一份报告中，错别字、用词不当、格式混乱、信息不明确等，那么它的专业度将受到质疑。作为一个测试人员，细节是专业素养的体现之一，新人应特别注意这一点。

在报告中增加必要的说明，比如测试机型、环境、测试方法、测试版本、如何取值（如三次取平均值）等，可以让阅读者更易接受你的测试结果。

（7）收起原始数据

报告篇幅有限，在突出重点问题后，请记得把原始数据、过程数据等最好通过附件或链接的形式引用，避免在报告中占用大量的篇幅。

（8）完美的结尾

依据报告类型而定，可以是下一步工作方向、经验和个人心得等。

一个参考例子：

一、角色定位

1.项目方向指引

在敏捷项目中，测试要找到丰富的信息，使得项目组基于这些可靠的信息做出正确的决定，往哪个方向走。

2.职能转变

除了做好自己本职的测试工作，还愿意并能帮助团队的其他成员解决问题，以实现团队的共同目标为己任。在敏捷团队中，还要求测试人员在项目时间紧迫的情况下能转变职能，完成其他角色的一些任务，达成团队的最终目标。当然，敏捷也要求开发人员在测试任务紧要时也能转变角色去帮助完成测试任务。其实，这样的要求无论对团队还是对团队成员都很有帮助。因为大家在职能转变的过程中, 自身的各项技能可以得到锻炼和增强，从而获得更大的发展。

这里举一个管家红包闹钟项目的例子，从产品idea讨论，到灰度上线，仅仅用了21小时！如何做到的？团队所有角色参与需求讨论、确定产品形态、补充细节，全员参与测试，开发帮忙切图，开发测试一起运营发布产品。

总而言之，就是测试人员对产品的影响力增强。

二、测试介入时机

在传统的开发模式中，测试人员经常需要较长的等待，产品功能开发完毕，才能进入测试阶段。而在Scrum敏捷开发中，测试人员需要尽可能早的开展工作，而不是“等待”。测试人员在故事设计阶段就需要从各种角度来寻找系统需求，探索隐藏的假设。

三、测试面临的挑战

1. 需求文档敏捷化

在敏捷项目中，需求文档往往不像传统模式中那么详尽，在缺乏需求文档的环境下，测试如何开展工作？如在红包闹钟项目中，是如何做到测试用例大纲与需求文档同步输出？

一起讨论需求、讨论设计，寻找和挖掘关于软件的信息来指导我们的测试。

2．频繁地组织用例评审

故事拆解后，每一个故事都需要进行用例评审，频繁地组织用例评审会花很多时间？

在传统模式中，整个项目组的人全部坐在一个会议室，对测试用例进行评审，用例包含所有模块，过到某个模块时，对应的开发及产品人员重点关注，整个用例往往需要两三个小时才能评审完，这种方式大大浪费大家的时间。在敏捷用例评审中，只有与“故事”相关的人员参与评审，并视用例量、需求明确度决定是否直接在座位快速评审，极大地提高了用例评审效率。

3.测试不完整的应用

每个story的测试包都是不完整的，测试人员如何测试这些不完整的代码呢？

故事拆解不合理，对测试人员的影响比对开发人员的影响还要大。测试人员需要从自己的角度提供信息，帮助定义“故事”。

4.“故事验证”测试范围

测试人员如果只是验证“故事”是否完整，是否足够？

根据每个“故事”的特点，决定是否需要额外的测试，而不仅仅是局限于验证“故事”的完整性。

5.没有充裕的测试时间

测试人员需要根据项目和产品的风险来调整测试。基本上测试的优先级应该跟“故事”的优先级一致。

6. bug快速生命周期与系统跟踪的矛盾

敏捷过程强调简单而高效，要求bug的快速修复，在敏捷开发中，测试人员和项目组坐到一起，往往是测试发现一个bug，直接在座位上口头同步到开发，开发确认后很快就修复了。那么，是不是就不需要tapd缺陷跟踪系统了呢？

四、测试过程

敏捷测试认为要持续地测试、快速测试。那么如何开展敏捷测试？

1.用例与精准测试

?用例优先级

用例优先级可参考笔者另外一篇文章《测试朝花夕拾》，这里不再赘述。

?用例粒度

视项目情况而定，如果项目时间紧张，可以采用较粗颗粒度的测试用例，列出主要的测试点及简要步骤、预期结果，并使用MM等思维导图工具来写，便于灵活调整用例及思维发散。

红包闹钟快速用例案例：

?用例精简与精准测试

用例精简及精准测试方法，可参考shellnalu《用例精简+精准测试实践》，这里不再赘述。

在沸点中的实践后续再详细补充。

2.冒烟

故事开发完成后提测前，开发组织项目组进行冒烟，能快速有效地消灭大部分明显缺陷及体验问题。

如管家发现项目中，冒烟发现有效bug7个，产品采纳建议1个。

3.探索性测试

探索性测试强调测试设计和测试执行的同时性，抛弃繁复的测试计划和测试用例设计过程，在测试过程中发散思维，不断地出现很多关于测试的新注意，可以有效地发现埋藏较深的缺陷。在敏捷测试中，应更多地采用探索性测试方法。

管家发现项目探索性测试实践：

4.回归测试

?基于风险和操作面分析来减少回归测试的范围

例如回归测试只是保证主要功能点没有问题，而忽视一些细节的问题。

?自动化回归

? Code Diff

通过执行Code Diff 来了解代码变动的所有地方，再做代码关联分析，就可以明确知道要进行哪些地方的回归测试，回归测试范围会大大缩小。?持续测试

只要有时间，就进行测试，包括开发人员、产品人员都参与到日常的试用和测试中来。

?众测