【综述】工作总有规范——测试执行和bug

关于测试工作的规范，上次讨论了用例部分。

本次将继续聊下测试执行期间的规范标准，是主要需要测试执行人员关注的部分。

 

【测试执行】

 

测试执行规范或标准，主要是为了确保测试人员“在正确的环境做正确的验证”，并且能“留下相关记录、准确及时地暴露出问题”。

 

这里会包含可测性确认、测试记录、问题/风险判断与提交、异常情况处理等；

也就是主要与测试执行期关联的要求。

 

 

可测性确认算可测评估的一部分，是其中的初步执行验证部分。

它通过冒烟检查指定环境、提测版本、功能范围的实现情况，确认对应提测内容是否可以继续测试。

 

关于此类判断标准，可以看看这些示例：

对于环境，是环境不可用即不可测，还是允许协调/共用其他环境测试；

提测版本需要核对哪几个数据，是必须等于某个版本还是高于某个build即可；

功能范围是否要求包含所有需求点，是否必须包含核心提测需求，或是否需要全应用核心功能可用；

实现状态验证上，是要求冒烟功能主流程，还是确认清单中入口可进入即可，或需要验证到需求所述优化表现。

 

以上这些，都属于执行可测性验证时候会涉及到的规范或标准；

执行测试的人员，需要参考这些要求，结合实际功能情况来评估本次可测/不可测范围。

 

 

测试记录部分，通常会被要求和测试用例分离。

 

至于具体要求，就是各个团队或项目的要求了。
 

 

可能出现的规范方向，例如：

需要记录哪些内容，使用什么格式；

执行同时记录还是每日更新；

本地记录、在线表格还是专用平台；

如何存档，是否定期回顾；

以及等等。

 

测试记录，通常也代表了测试进度。

相关要求也可能包括进度更新/沟通，比如测试完成后是否要实时标记完成，是否要实时与PM或相关产品研发沟通。

 

 

问题的判断与提交，也可以认为是bug相关规范或标准。

在这里，我指的是什么样的问题会被判定需要提交。

 

比如：

上个版本存在的问题是否需要重新提交；

是否需要忽略特定模块的问题；

特定机型的问题是同步给适配团队还是直接提交；

特定类型的问题除提bug外是否还要做其他操作；

以及等等。

 

这部分要求通常阶段性比较强

——可能只是本次提测这样要求，下个版本就变化了

——若是如此，这是需要在每次测试前确认清楚的。

 

 

异常情况处理，是指在异常状态下，要求测试执行人员做出怎样的反馈。

 

异常情况通常包括：

进入测试后遇到的，例如环境不稳定/受意外因素影响出现无法测试/测试无效；

质量与预期差异过大，导致进度和预估不符合；

单点阻断，或某些入口阻断其它功能验证；

以及等等。

 

而测试人员被要求做的，或者说相关规范，可能包括：

报给测试接口人；

直接与阻断对应研发人员沟通；

需要用什么形式沟通，提供哪些信息，给到谁；

是否在进度表或用例表有对应记录格式；

哪些问题要发现后第一时间上报；

以及等等。

 

 

---

 

 

 

 

【BUG】

 

bug相关的规范或标准，主要是为了让bug可以被高效理解和流转。

通常主要包括bug的内容要求，以及bug流转、流程要求。

 

 

内容要求方面，比较直观的规范例如，字段有哪些、是否必填、填写什么内容。

这些规范，通常是在测试可提供信息，和处理人需要信息间权衡的结果

——要求信息过多会给测试人员增加工作量，提供信息不足会影响处理人判断问题情况。

 

比较常见的要求，例如：

标题格式包含问题简述，加上该项目重要区分维度如模块、类型、环境、版本，以便看到bug标题可以快速归类或找责任人；

内容要求有版本号、发现时间、账号信息、前置条件、操作步骤、问题现象、预期结果、重现概率、对应截图或视频等；

额外字段可能有模块、类型、严重程度、优先级、重现情况、版本、基线、处理人等；

常见bug系统当然还有创建人、创建时间、处理时间等自动生成的字段，但这通常不需要填写时关注；

除此之外，提交bug还经常会被要求，附件上传特定方式获取的log。

 

 

关于内容的要求，除了bug提交时的格式、内容，也包括各字段相关的判断标准；

比如：

如何判断是哪个模块、哪种类型的bug；

如何区分bug的严重级别和优先级；

偶现bug需要尝试复现几次；

以及等等。

 

 

bug的流程要求，通常包括提单流程和回归流程

——实际bug规范还有与研发、产品策划、PM等角色有关部分，此处仅描述测试有关部分。

 

提单部分除了前文描述的内容，还包括一些其它要求，例如：

提单初步处理人选谁，什么情况给测试接口人，什么时候给PM、相关研发或产品策划；

除提单外，是否需要其他通知操作，或哪些bug，要求什么形式的额外通知；

对于bug，是发现就提，还是需进行指定复验/定位，或要求非阻断问题每日统一提单；

以及等等。

 

在回归流程中，测试方面通常会有重新打开流程和回归关闭流程。

 

针对不同流程，会分别规定不同情况需提供的信息。

都要提供的如验证版本，重新打开单独需要的如：

描述现象，提供新的截图/视频/log，如果现象有变化可能需要提供更多信息。

 

回归重新打开的流程，还可能涉及类似提单的流转人判断、通知等流程要求。

 

 

 

 

 

 

规范和标准类型还没有讨论完。

在用例、执行、bug之外，测试流程上还有一些可能的规范，下次会做一些补充性说明。

声明：

本号对所有原创、转载文章的陈述与观点均保持中立，推送文章仅供读者学习和交流。文章、图片等版权归原作者享有，如有侵权，联系删除。

北京汉通达科技主要业务为给国内用户提供通用的、先进国外测试测量设备和整体解决方案，产品包括多种总线形式（台式/GPIB、VXI、PXI/PXIe、PCI/PCIe、LXI等）的测试硬件、相关软件、海量互联接口等。经过二十年的发展，公司产品辐射全世界二十多个品牌，种类超过1000种。值得一提的是，我公司自主研发的BMS测试产品、芯片测试产品代表了行业一线水平。