Chatopera质量保证之系统测试

本文共计6112字，预计阅读时间18分钟，本文是由Chatopera质量管理人员撰写的。

1.        前言            

2019年国庆节后，开始帮助某企业开发定制的客服系统，到1月份经过验收完成交付，历经多个测试版本迭代，伴随着很多辛苦的付出，项目成功上线离不开团队的协作，更离不开客户的及时反馈，客户发现问题后会及时在即时通讯工具联系我们，告诉我们问题的复现步骤，影响到的功能，可以让我们更快的定位出现问题的原因，更快的解决问题。当我们的客户自己部署产品遇到问题时会即时联系我们的技术人员帮忙排查问题，有效的沟通解决问题，每周至少保证两次状态同步会，记录会议纪要。

成功上线并稳定运营一段时间后，我们开始反思，我们在质量管理上的工作是怎么开展的，怎么样优化这个过程？Chatopera团队之前已经发布过文章《Chatopera软件开发方法》来描述整个过程，今天我们将更加详细的审视我们的质量管理体系，尤其是系统测试部分的工作方法论。 

   2.  质量管理的重要性  

当管理与质量有关时，则为质量管理。质量管理是在质量方面指挥和控制组织的协调活动，通常包括制定质量方针、目标以及质量策划、质量控制、质量保证和质量改进等活动。实现质量管理的方针目标，有效地开展各项质量管理活动，必须建立相应的管理体系，这个体系就叫质量管理体系。不同组织的质量管理体系有不同的特点，但是质量管理的重要性在产品开发中，无一例外的是最关键的，严格的质量管理体系可以研发出高溢价能力的产品，比如戴森吸尘器，当大多数吸尘器只有几百或者几千时，戴森吸尘器是上万元，而且还是爆款热销，这其中的秘密就是在质量上追求极致。

图：戴森爵士

戴森爵士在推出吸尘器产品之前，历经15年时间的磨砺和坚持，打造了5000多个原型机器，正因为其对质量的坚持，才有了后来的成功。这个案例中，戴森产品溢价能力强，所以它的产品都是同类产品价格的十几倍，戴森爵士被称为“英国设计之王”，并于2019年成为英国首富。我们再来看另外一个案例，优衣库在产品质量方便也是有着极高的追求，尤其是在新材料上的创新，进行大量的测试，比较，才有了廉价同时舒适的服饰，它的价格不高但是每个单款都能有超高的销量。

图：优衣库测试布料

无论是戴森，还是优衣库，都在质量管理中斥巨资打造实验室，模拟各种环境，怪不得人家站在各自领域的龙头。

3.  质量管理标准

管理标准是规范人的行为、规范人与人的关系、规范人与物的关系，是为提高工作质量、保证产品质量服务的。它包括产品工艺规程、操作规程和经济责任制等。企业标准化的程度，反映企业管理水平的高低。

企业要保证产品质量，首先要建立健全各种技术标准和管理标准，力求配套。二是要严格执行标准，把生产过程中产品的质量、人的工作质量给予规范，严格考核，奖罚兑现。三是要不断修订改善标准，贯彻实现新标准，保证标准的先进性。

4.  质量控制结果

项目质量的改进

项目质量的改进是指通过项目质量管理与控制所带来的项目质量提高。项目质量改进是项目质量控制和保障工作共同作用的结果，也是项目质量控制最为重要的一项结果。

对于项目质量的接受

对于项目质量的接受包括两个方面，其一是指项目质量控制人员根据项目质量标准对已完成的项目结果进行检验后对该项结果所做出的接受和认可，其二是指项目业主/客户或其代理人根据项目总体质量标准对已完成项目工作结果进行检验后做出的接受和认可。一旦做出了接受项目质量的决定，就表示一项项目工作或一个项目已经完成并达到了项目质量要求，如果做出不接受的决定就应要求项目返工和恢复并达到项目质量要求。

返工

返工是指在项目质量控制中发现某项工作存在着质量问题并且其工作结果无法接受时，所采取的将有缺陷或不符合要求的项目工作结果重新变为符合质量要求的一种工作。返工既是项目质量控制的一个结果，也是项目质量控制的一种工作和方法。

  5.  春松客服的质量管理环节  

春松客服质量管理包括功能测试，构建测试，系统测试，压力测试和验收测试。

功能测试是开发人员根据需求或软件缺陷，提交代码后，进行功能点的测试，通常是在代码进入产品代码库之前；构建测试是产品代码库有了变更后，自动构建软件包并在测试环境部署，然后执行自动化的冒烟测试，这个过程是通过自动化工具完成；系统测试是通过建立测试用例，测试单，使用人工的方法进行测试，覆盖产品所有功能，和需求进行一一确认；压力测试是针对软件性能，通过设计一个有代表性的应用场景，然后针对一个特定配置的春松客服实例进行大规模的请求，模拟多个用户同时使用，然后通过请求响应时间、春松客服的负载情况、目标服务器的网络、硬盘读写I/O，数据库请求响应等进行分析后，得出春松客服在不同配置下能支持多少并发访问的过程；验收测试则是针对客户部署的测试环境进行系统测试，主要是客户通过Chatopera团队培训和辅助完成。

下文我们将主要围绕系统测试展开介绍，其他内容我们后续再和大家分享。

  6.  系统测试目标管理  

Chatopera团队的系统测试参考了很多成熟的模型，然后选定禅道来执行，在禅道中进行产品管理、设计测试用例、创建测试单。整个软件开发的生命周期可以用下面这张图概述。

图：Chatopera软件研发流程

可以看到，质量保证是客户与开发人员之间的一道安全阀，严格的管控产品质量和抵抗软件开发的不确定性风险。Chatopera团队自主开发了Chatopera Sync服务，将禅道、Wiki、Gitlab、Jenkins和企业微信及邮箱连通，让状态信息能同步到企业微信，这个服务内部也为大家津津乐道，因为这个系统是一个“副产品”，也是Chatopera团队付出很多心血的地方。

产品管理

当我们研发一个新的项目，项目经理会在禅道中添加产品名称、代号、负责人、产品描述等信息。

图：添加产品

项目进入研发期，会有研发工程师完成系统测试环境的升级，每次版本升级会在禅道中创建版本号以及此次版本更新的功能。

图：创建版本

测试用例管理

在项目研发前期我们的QA人员会根据需求设计测试用例，设计测试用例是质量把控中重要的一步，设计尽可能完善的测试用例，严格按照测试用例步骤去执行，可以尽早发现产品的缺陷，进而提高产品的质量，降低风险。

测试用例概念

测试用例，即执行测试工作之前编写的指导测试过程的文档，主要包括：用例编号、测试目的、用例描述、预期结果。

测试用例的重要性

• 便于测试计划的实施

一般测试用例主要适用于集成测试、系统测试和回归测试，根据测试用例，我们可以一步一步的进行测试，并清楚知道测试的进度。

• 规划测试数据的准备

根据测试用例的设计，我们能够提前设计好需要的数据，比如测试一个注册功能，我可能需要提前准备好这些：手机号码，实名认证的身份证号码，不重复的用户名，QQ邮箱，等等。

• 编写测试脚本的根本

为提高测试效率，软件测试已大力发展自动化测试，自动化测试的中心任务就是编写测试脚本，测试脚本就是以测试用例为基础的，因为瞎写是写不出啥东西的，就失去了自动化测试的意义。

测试单管理

测试单用来记录每次版本升级更新的功能，当我们研发工程师升级版本后，QA负责人会创建测试单，测试单关联测试用例，针对版本升级更新的功能进行测试，测试完成后创建SVT报告，评估产品开发顺利退出的风险。

图：创建测试单

有了测试单，QA人员就可以按照测试用例说明，一步一步的执行测试，遇到问题后创建BUG，然后联系开发人员进行确认，判断是不是一个真正的BUG，QA人员负责标记严重程度，项目经理或开发人员负责标记优先级。

BUG管理

当我们测试过程中发现bug首先会进行记录，然后多次验证确定bug的复现率，确保研发人员可以稳定复现bug，进而解决bug，下面来看一下bug是如何创建的。

提交bug表单时要选择bug的类型，所属的产品、模块，指派给谁，bug的严重程度，bug标题，使用的操作系统以及浏览器，最重要的是bug的重现步骤一定要写详细，QA人员提交bug后由开发人员进行确认，开发人员确认bug时可以设定bug的优先级，当开发人员解决bug以后会在禅道中点击解决，QA人员进行验证，验证通过以后，就关闭这个bug，如果验证没有通过会重新激活这个bug指派给开发人员继续修复，直到bug验证通过进行关闭。

图：提交bug

测试报告内容介绍

测试报告数据：用例结果统计、bug严重级别分布、bug模块分布数据，简单讲述产品已经实现的功能、优化中功能、未实现功能，以及产品推出最大的风险是什么。

图：测试报告

测试报告每天晚上8点会由QA人员整理，创建测试报告后在群中@团队所有人员，便于团队其他成员了解项目当前的进度与风险，根据项目现状安排接下来的工作。

  7.  测试用例设计指南

测试用例设计原则：

1）每一个测试需求至少有一个测试用例与之对应；

2）每个测试用例包含的测试步骤尽量不要超过10个；如果过多就进行拆分；

3）每一步只包含有一种情况，不能将多种情况塞在一个用例里；

4）每个测试用例包含的测试步骤不得少于2个；

5）测试用例设计时应该包含功能的边界情况、等价类等方法；

6）对于流程尽量实现每个路径的覆盖；

7）关注需求中特别提出的权限、必填项、初始值和计算结果等内容；

8）功能测试时，根据界面、业务、数据流变化进行用例划分；

9）测试用例设计根据测试范围进行评审检查，覆盖全部范围；

10）测试集合根据模块以及对应的需求变更建立集合，每个集合包含对应的测试需求和测试用例；

11）公用性比较强的测试用例，需要单独出来，以便引用。比如输入日期查询；

12）界面验证，业务验证，数据流验证的用例应该分开来写，不能放在一个测试集合里；

13）在系统测试阶段，如果可以通过前台界面可以验证的，最好不要通过查询表的方式来验证。

测试用例的粒度

 在设计测试用例工作中，把握测试用例粒度的粗细是很伤神的事，测试用例写的很细，会带来很多问题：首先是效率问题，测试人员的首要任务是有效地测试产品，尽可能多的发现产品缺陷，如果测试用例写的过细，在设计测试用例时势必要花费大量时间，这些时间中很大一部分是应该用在有效的测试产品上的，其次，测试用例设计得过于详细，测试执行人员就成了执行用例的机器，只能按照用例步骤去操作而缺少了思考空间，使测试执行人员的思维局限于测试用例中，再就是如果这些用例要复用在其他版本中时，产品功能稍微改动，就需要修改大量的测试用例，从而使用例的维护代价大大提高。但是测试用例写的太粗就会包含太多验证点，当用例在执行到某一个验证点被卡住时，这个用例就被标记为无法通过，下面的验证点可能就不再执行，直接标记用例无法通过，同时也为定位bug增加了难度，测试用例粒度过大还容易遗漏测试项。

测试粒度该怎么划分呢？通常系统测试会综合考虑功能点，测试步骤，数量级和数据覆盖程度。测试用例的粒度粗细多大算粗多小算细没有一定标准，每个人、每个机构判定测试用例粗细的标准都不一样，没有标准答案，还需要在工作中不断地实践积累。

决定测试用例粒度的因素

• 时间、资源因素

时间短、项目紧、编写用例评审时间较短时，而且人手短缺，适合粗颗粒度用例。项目周期较长时，人员配备充足，适合细颗粒度用例。

• 执行测试用例的人员

测试人员都是思路和基础技能扎实的有多年测试经验的高手，他们都有高度的责任心而且对产品十分熟悉可以采用粗颗粒度用例。测试人员新手多，没有经验，对产品几乎不了解，需要在指导下进行基础测试工作，或责任心一般时，需采用细颗粒度用例。

• 需求变更

需求变更较多时，建议采用粗颗粒度的用例，可较灵活的覆盖需求。经过一轮轮的评审，等需求基线化之后，在实际的滚动测试中，在逐步细化用例。需求变更较少时，或需求变更波及较小，系统设计框架不会频繁改动，可对应较大的细化测试用例变更量。

测试用例设计方法

• 等价类划分法

等价类划分法就是把输入域的可输入值进行等价性划分，然后在每一个等价域中取少量的能代表这个等价域的值作为测试用例的输入数据。根据每个等价类值是否对程序有作用，分为有效等价类和无效等价类。

有效等价类：此类中的值对于我们执行用例的程序来说是有意义且合理的，可以有效的检验程序是否实现了需求规格说明中规定的功能。

无效等价类：此类中的值正好相反，对程序来说是不合理的、无意义，输入此类中值程序无法实现相应的功能和性能，但是不是说程序不会对此类中值有反应，从程序的健壮性来考虑，程序也应该对此类中的值做出正确的反应。

• 边界值分析法

边界值分析法我们一般用于对等价类划分法完成之后作补充，但是这也是必不可少的，原因在于程序的很多错误都是发生在输入或者输出的范围的边界上的，而不是在输入范围的内部，所以针对各种边界情况进行测试用例的设计通常都会有很好的测试效果。所谓的边界是指输入域中，稍高于或者地域边界值的一些特定情况，边界值分析不仅要考虑输入条件，还要考虑空值时的测试情况。空格，null，""等都是比较特殊，在设计测试用例的时候需要特别注意一下。

• 错误推断法

错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

此外还有因果图法、判定表法、场景设计法等，在此不一一表述。

设计用例注意项

在测试用例设计时，首先根据需求设计基本功能测试用例；接着进行设计边界值测试用例、状态转换测试用例和错误推测测试用例；然后进行设计异常测试用例；最后再进行设计性能和压力测试用例。

较好的测试用例一定是一个完备集合，能够使其覆盖所有等价类、边界值，尽大可能地运用等价类划分、边界值分析以及错误推测方法，而能否发现软件缺陷并不是衡量测试用例的好坏标准。

在设计用例时，不仅需要从软件功能需求出发，全面无遗漏地识别出测试需求非常重要；而且必须深入理解被测软件的架构设计、深入软件内部的处理逻辑，需求覆盖率、代码覆盖率能很好衡量测试执行的完备性。

  8.  春松客服系统测试执行过程

春松客服模块划分

春松客服包含了的模块有：系统设置、客服设置、智能机器人等等模块，每个模块又分为不同的子模块，如下图

图：春松客服模块

图：春松客服子模块

模块用例维护

我们在禅道中创建春松客服的模块以及子模块，在每个模块以及子模块下创建该模块的测试用例，便于查找维护该模块的测试用例

图：用例模块维护

春松客服各个模块的用例：渠道管理52个，坐席工作台13个，会话历史22个，目前春松客服共有196个用例，在此就不一一介绍，力求以最少的用例覆盖到更多的功能点。我们的产品在不断的迭代，用例也随之完善。

图：按测试单执行

执行过程描述

建立好测试用例后，执行测试的过程就变简单了，QA人员需要理解需求，然后根据软件设计，利用测试用例展开测试工作，系统测试需要针对所有功能进行，测试开始后先创建测试单，测试单计划了一次工作的内容并绑定某个版本的软件，测试单可以选择多个测试用例，也可以将测试用例组合为测试套件，方便快速建立测试单；创建测试单后，根据软件表现可以设置测试目标通过或不通过，不通过时可以自动创建BUG。

  9.  总结

以工匠精神审视我们的工作，发布高质量的产品离不开各个阶段的测试，测试期间发现越多的缺陷，发布的产品质量越高。所以，在Chatopera，质量管理伴随产品上线始终，我们严格遵守下面的流程开展工作：

1）进行市场调研整理需求；

2）进行需求评审，确认需求；

3）制定项目计划；

4）进行任务分解；

5）进入产品研发阶段；

6）进行产品测试阶段；

7）进行验收测试；

8）完成项目交付；

9）收集客户反馈。

以上是我们产品从开始到上线以及后续收集反馈的过程，其中最重要的还是要与客户进行沟通，充分理解需求，这样研发出的产品才能让客户更满意。