系统质量管理

小小鲁班

很多创业公司的产品迭代非常快，而又对系统质量意识要求不高，导致产品上线经常出现各种问题。针对产品质量造成的问题，屡见不鲜，给企业的发展带来严重影响，甚至会导致产品失败公司倒闭。作为一家企业的产品研发部门，我们该如何去提高和保障产品系统质量，我们认为可以从以下五个维度去着手。

• 测试用例
  % }4 c$ @; \4 T1 L' c4 f

测试用例是测试工作的核心，是测试工作的指导，同时也是软件测试质量稳定的根本保障，它是一组为了某个特殊目标而精心编制的测试输入、执行条件和预期结果，以便测试某个软件是否满足某个特定的需求。测试用例一般包含编号、用例名称、所属模块、前置条件、优先级、测试数据、测试步骤、预期结果、实际结果、使用阶段、备注。传统一般都是采用Excel或者Word工具管理测试用例，随着开源工具的不断推出，目前流行一般是用禅道或者TestLink工具进行在线管理，也方便多人同时协作开展工作。

测试用例编写的流程主要分为需求分析、设计和编写测试用例、测试用例评审3部分。

" [5 n7 }1 W9 r6 w0 D- @1 测试需求分析该阶段我们需要充分理解需求，吃透需求规则，从而提炼出测试需求点，为编写测试用例提供依据和思路。当产品提供了详细的需求说明文档时，需求分析可以从这两个方面去把握：（1）需求是否满足业务规则，且清晰，无歧义；（2）需求是否存在需求规则遗漏的情况。当产品提供的需求模糊或者没有需求时，这种情况，我们可以从这2个方面进行分析确认：（1）收集整理已有需求，同时跟产品经理逐条确认需求；（2）参考同类型的产品，获取相关需求。2编写和设计测试用例该阶段主要是采用不同方法设计测试用例。常用的测试用例设计方法有等价类划分法、边界值分析法、错误推测法、因果图法。

2.1等价类划分

是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。

等价类划分的设计思路如下：

2.1.1 划分等价类

（1）在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

（2）在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。

（3）在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。

（4）在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。

（5）在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

2.1.2 确定测试用例

（1）为每一个等价类编号。

（2）设计一个测试用例，使其尽可能多地覆盖尚未被覆盖过的合理等价类。重复这步，直到所有合理等价类被测试用例覆盖。

（3）设计一个测试用例，使其只覆盖一个不合理等价类。

2.2 边界值分析法

边界值分析是对输入或输出的边界值进行测试的一种方法，通常边界值分析法是作为等价类划分法的补充，其测试用例来自等价类的边界，选取正好等于、刚刚大于或刚刚小于边界值的测试数据设计测试用例。

边界值分析的设计思路如下：

（1）确定测试边界

比如测试聊天功能的内容输入框，输入值的范围是【1，100】字符，测试边界为1,100，我们可以选取0，1，2，99，100，101等值作为测试数据，设计测试用例。

（2）确定测试用例

根据确定的边界，按照选取的边界值，每个边界值设计一个测试用例。因此针对聊天功能的内容输入框分别输入0，1，2，99，100，101字符，检查系统的处理情况。

2.3 错误推测法

在测试程序时，人们可以根据过往经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例。

错误推测法的设计思路如下：

根据经验列举出程序中可能出错的和容易发生错误的特殊情况，根据他们编写测试用例。例如以前产品测试中经常出错的地方, 文本框输入特殊字符，文本框输入空格情况等，这些都是容易发生错误的情况。选择这些情况下的例子作为测试用例。实例：修改工程师的属性，将兼职工程师修改为外包工程师，输入所属服务商姓名时，服务商名字前面多一个空格，系统经常处理错误，我们根据经验，可以有针对性对这个地方设计一个测试用例。

* |! P* r% p, h! n

2.4 因果图法

通过分析因（输入）与果（输出），从而找出输入与输入、输入与输出、输出与输出之间的关系，画出便于观察的图示，来设计测试用例的方法。

因果图法的设计思路如下：

（1）分析需求，确定哪些是原因、结果。

（2）标明约束条件，因果图中，使用若干标准的符号标明约束条件。

（3）根据分析结果画出因果图。

（4）根据因果图画出判定表、人为删去判定表中不可能发生的情况。

（5）根据判定表的每一列设计出一条测试用例。

因果图法设计实例：

7 x& b2 I1 P2 z( w  m1.3测试用例评审

测试用例是软件测试的准则，它并不是一经编写完成就成为准则。当测试用例编写完后，需及时对大家编写的测试用例进行评审，目的是减少测试人员后续执行阶段做无效工作（执行无效case，提交无效问题）；避免开发、测试双方需求理解不一致。 通过评审，可以发现每个人测试用例的不足、是否存在测点遗漏、方便改进测试用例从而提高系统测试质量。

1.3.1用例评审时机

测试评审一般会有两个时间点。第一，是在用例的初步设计完成之后进行评审；第二是在整个详细用例全部完成之后进行二次评审。如果项目时间比较紧张，尽可能保证对用例设计进行评审，提前发现其中的不足之处。

1.3.2用例评审人员

测试评审一般包括小组评审，部门评审，三方评审。

（1）小组评审，主要是测试小组内部组织参与的评审。  

（2）部门评审，主要有研发部对应的开发、测试人员一起参与的评审。  

（3）三方评审，主要是项目组涉及的产品经理、项目经理、开发人员、测试人员三方参与的评审。

6 a0 W& A, S! I$ R

1.3.3用例评审过程

（1）测试人员提前发出测试用例初稿，发给相关评审人员；

（2）编写人员对照测试用例，从上而下，从左到右，逐条讲解自己编写的测试用例；

（3）评审人员在编写人员讲解用例过程中给出意见和建议，同时记录下评审会议记录；

（4）编写人员根据评审结果再次完善测试用例；

（5）测试人员再次将完善后测试用例，发给相关人员进行二次评审。

1.3.4用例评审内容

测试用例评审的内容主要表现在以下几个方面：

（1）用例设计的结构安排是否清晰、合理。

（2）优先级安排是否合理。

（3）是否覆盖测试需求上的所有功能点。

（4）用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和预期结果是否清晰、正确。

（5）是否已经删除了冗余的用例。

（6）是否包含充分的负面测试用例。

（7）是否从用户层面来设计用户使用场景和使用流程的测试用例。

（8）是否简洁，复用性强。例如可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。

1.3.5用例评审主要事项

（1）测试用例切记含糊用语，每个用例评审都应该确定最终版，稍有矛盾或疑惑的需求点，都应该记录下来。

（2）避免杂乱无章的评审，需有顺序有逻辑的进行评审。

• 内测环节
  # d/ a. f  f  d) l" m1 y0 A

当产品完成研发，正式进入到提测，这个阶段通常是我们研发测试组投入时间最多的环节，也是保障系统质量最关键的环节，如何才能更有效的进行内测，发现更多系统问题。我们认为需要做好以下节点步骤：

; j& `6 b9 m* T

1 单元测试

该阶段主要由开发人员对自己负责的模块，编写一小段测试代码进行单元测试，主要测试类里面的每一个方法是否都已经满足了对应的功能需求。只有当单元测试通过以后，才交付给测试组进行下一步的测试。

2 第一轮内测

在进行第一轮内侧，需要做好两个方面：

（1）冒烟测试：对产品进行冒烟测试（即冒烟测试就是完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通），如果测试不通过，则打回开发那边重新开发；如果通过测试，才会进行下一步的测试。该阶段主要用于验证开发提交的版本是否满足测试要求，如果不满足需及时打回给开发进行修复。

（2）第一轮测试：当冒烟测试通过以后，测试负责人开始组织项目组的测试人员，根据各自负责的模块，开始进行第1轮系统测试。第1轮测试重点是需要测试产品的每一个需求细节，需要测试人员将准备好的每一个测试用例，按照测试用例的优先级一一进行测试，发现问题及时反馈到禅道管理里面。在测试过程中，测试负责人需要根据测试排期表，定期进行测试进度跟进，当出现进度拖延，需及时进行原因分析，并给出解决措施。

3第二轮内测

相对于第1轮内测，第2轮测试不会像第一轮测试那样，会再次对每一个测试用例一一进行测试，第2轮的测试重点一般是要筛选测试用例优选级为1,2级的用例再进行一遍测试，同时对禅道的Bug进行跟进与验证。

; N# u7 x! x1 I4 E

4内测把控

把控环节主要包含上线前一天Bug情况同步、项目经理安排人员解决问题，测试人员验证问题，该阶段主要确保项目过程中发现的问题，能够及时修复，以免造成系统上线延误。

) e# r4 g; K' H6 z

（1）上线前一天Bug情况同步

在产品上线前一天，测试负责人需要在研发部钉钉群里面同步产品Bug处理情况，每隔2小时同步一次数据，同时提醒开发人员及时修复问题。

（2）项目经理安排人员处理问题

当发现某个开发人员待修复的问题比较多，项目经理需要及时跟进，评估项目风险，是否存在项目上线延误的情况，如果存在的话，项目经理需安排其他开发人员配合一起修复问题。

（3）测试人员验证Bug

当开发人员修复好对应的Bug后，对应的测试人员需及时进行验证，测试过程中发现问题，及时反馈给到开发人员，直到所有问题修复完毕，达到上线标准。

5回归测试

产品上线之前，测试组需做最后一道把控，回归测试。在进行回归测试的同时，测试组负责人需发邮件通知产品经理对系统进行验收。回归测试阶段，测试的重点注意是是筛选测试用例优选级为1级的用例再进行一遍测试，以及测试过程中之前经常出现Bug的地方，再次进行测试。回归测试结束后，测试负责人需输出一份测试报告，告知当前项目的测试情况。

测试报告模板：

( ^3 w$ Z0 Z( \+ o6 M

• Bug分类
  

测试阶段我们会发现很多不同类型的Bug，每个Bug对系统的影响程度也是不一样的，有些Bug直接影响测试，如何保证我们发现后提交的Bug都能够快速得到处理，需要对这些Bug进行分类，通过制定Bug分类标准，测试、开发人员共同遵守这个标准，从而更好地配合工作，提高工作效率。

; L7 j3 u, y) X

1 等级划分

产品Bug根据问题严重程度，通常划分为4级，具体等级划分参考如下列表：

级别

描述

举例

一级

致命问题：通常表现为:主流程无法跑通，系统无法运行，崩溃或死机，应用模块无法启动或异常退出，主要功能模块无法使用。

1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出；7.用户数据丢失。

二级

严重问题：通常表现为：系统的主要功能部分失效，数据不能保存，系统的次要功能完全全部丧失，系统所提供的功能或服务受到明显影响。

1. 主要功能存在部分业务逻辑未实现或遗漏；2.系统未做异常处理，前端直接抛出错误代码；3.轻微的数值计算错误。

* d6 U( v) Z9 b5 V% t) D( i

三级

一般性问题：通常表现为：系统的次要功能没有完全实现，但不影响用户的正常使用。如提示信息不准确或用户界面差，操作时间长等。

1.次要功能没有完全实现，但不影响用户使用本产品；2.界面存在明显缺陷，设计不友好；3.一般性能问题；4.边界条件下错误；5.容错性不好。

2 u1 a  r. E9 y0 E. {- M) }

四级

提示&建议&新需求：通常表现为:易用性及建议性问题，使操作者使用不方便或遇到麻烦，但不影响功能的操作和执行，如个别不影响理解的错别字，排布不整齐等。

1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范；5.新需求。

. ~+ D3 [- X& O1 c8 n% u$ r

2 Bug响应方式

针对不同级别的Bug，不管是线上还是线下，我们都需要采用不同响应方式去处理，具体如下表：

级别

响应等级

响应角色

一级

需要在2小时内修复。

部门负责人、项目经理

二级

需要在4小时内修复。

项目经理、测试负责人

三级

需要在48小时内修复。

测试负责人

四级

需要在一周内内修复。

测试人员

: ~3 T) f4 T- \

• 线上跟踪
  

产品发布上线，投入到生产环境正式使用后，随着生产环境跟测试环境的差异，系统会暴露出各种问题：研发方面的问题，需求方面的问题，用户体验的问题，如何快速响应这些问题，降低他们对线上生产环境的影响，提高客户的满意度，对于我们来说同样非常重要。对于如何做好线上产品跟踪，我们认为可以做好以下几个方面：

) j7 H* _; v9 O5 c" D- u

1 每天收集线上系统问题

每天收集各种渠道（如：Bug反馈群，业务部门直接反馈，跟客户沟通回访）反馈过来的线上系统问题，并对这些问题进行归类整理，分析问题原因，吸取教训，总结经验，后续在开发、测试中需对这类问题加以重视。

问题收集列表：

) b" [. b+ [9 ]- w: B

2 跟进出现2次以上的同一类问题

针对线上累计出现2次以上的研发、需求问题，每周五邮件反馈给到对应的问题负责人，通知他们反馈问题解决方案，避免该问题再次发生。研发类的问题发给开发负责人，需求类的问题发给产品负责人。

问题反馈列表：

4 V4 k5 t2 X1 R4 [( @
+ [4 w& Z; z. r; {% @1 m/ ~

# y$ O! _, `- N  `% _; t% [

3 运维监控&预警

（1）运维人员每天监控线上系统作业脚本是否正常高效执行，当发现异常及时通知相关人员进行处理。

（2）运维人员高峰期需保障线上系统服务器CPU，内存，硬盘等硬件资源的占用率正常，系统负载正常，当系统出现访问延迟打开缓慢现象时，需快速定位故障原因，及时解决故障。

（3）运维人员每周及时更新服务器漏洞或安全补丁，保障生产服务器安全高效运转。

4 每月反馈一次线上问题处理情况

测试负责人需每个月1号（遇到节假日延后到当月第一个工作日），将上个月线上出现的问题解决处理情况，通过邮件的形式反馈给到研发部各个成员，同时抄送给相关部门负责人。

1 m+ w; ?5 Q- X7 E2 b! p
! A8 ]: R, K4 I1 D4 Z

• 应急机制
  2 i; a. z, b' b6 v+ s# \6 d" m

为了应对线上生产环境在不同时段可能出现的问题，研发第一时间都有人及时进行响应并妥善处理，根据以往经验，我们制定了日常Bug处理机制跟周末线上Bug应急机制2套不同的应急措施，保障线上出现问题能够第一时间恢复。

1 日常Bug处理机制

收集方式：钉钉在线

处理流程：业务部门系统使用人发现线上生产环境出现Bug时， 先分析问题是否第1次出现，如果是第1次出现，按照Bug登记模板填写后，通过钉钉在线提交问题，将问题指派给产品经理对接人，否则指派给测试组负责人，待问题修复上线后，需及时通知对应的问题反馈人。

* t( B8 ]: t, V

问题反馈模板：

7 N% r5 A$ M- |! @0 [) {
7 e) H. K) G7 e' J1 W' T2 Y

2 周末线上Bug应急机制

研发部全体：当发现有用户反馈线上问题，本人能处理的需及时解答处理；处理不了的问题需及时转发到部门工作群（钉钉跟微信工作群），同时告知项目经理。

项目经理：收到线上反馈的问题，如果是属于1，2级的问题，需及时协调安排相关人员，处理线上的问题，如果在家处理不了的问题，安排人员到公司一起处理，需全程跟进，直到问题成功修复上线。

相关问题开发人员：收到线上的问题，如果是属于1，2级的问题，需要当天修复好并上线。如果是属于3，4级的问题，不强制周末修复好，可以放到工作日再修复上线。

测试人员：收到线上待验收的问题，需及时到测试环境进行验证，验证通过以后，通知开发人员发布上线；同时需要到线上再次进行验证，如果验证通过，通知项目经理跟系统运维人员。

系统运维人员：收到问题上线通知后，需第一时间反馈给用户，同时发布上线通知给到相关人员。

( [: X) S  \1 f8 y; H. @
, k( I6 ^6 c: @

小结

对于系统质量管理，我们需编制好预期结果的测试用例；在内测环节做好要求的节点步骤测试系统质量；根据Bug分类的等级做出对应的及时响应；分析线上产品出现的问题和跟踪反馈；落实好Bug应急机制，若出现问题能够第一时间恢复；把控好这五方面，那么就能提高和保障产品系统质量。

Sky_wm

系统质量管理非常重要