青帝小说

第6章 测试用例bug指派和质量管理（第1页）

对项目的整体架构和主要业务流程有了基本的认识后，再研究系统和本轮的需求文档，就有了新的理解，理解了各个功能模块里的具体功能，对于投诉赠送的审批流程中的每个节点也清晰多了，YD的产品经理在需求评审会后更新的需求文档也已经发出来了，结合廖工已完成的概要设计说明书，温婉开始梳理测试用例的思路。

正如当初她跟穆总提出写测试用例的好处，测试用例是指导测试的文档，它能提高测试效率，防止漏测，还能提前准备测试数据，同时对领导和测试人员本身评估工作量都是一个重要的参考，其实还有一个作用就是减少交接成本，听连婷说过，在温婉入职之前其实测试部还有一名老员工，手头上负责的几个项目在那人走了之后，她接手过来花了很长时间才能上手。如果当时离职者负责的项目都有测试用例，那接任者将她主流程的测试用例执行一遍后，就更容易理解系统。

而测试用例到底是什么呢？

测试用例（TestCase）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，即为了某个目标而编写一组测试输入、执行条件和预期结果，用以核实是否满足某个特定的软件需求。

为了保证全面覆盖需求，温婉严格参照需求说明书、原型图和UI设计图来将用例点一一列出，遵循“总分总”的思路，从需求说明书里提取出项目的大模块，然后将大模块拆分成小模块，一直拆到可以照此直接写用例的点，最后把相关的业务流程串联起来设计用例。

她使用excel表格将测试用例标题按模块和业务逻辑列成树状，然后共享到测试群里，同事们给提出了一些建议后她再作对应的修改。

此事穆总也很关注，他看了之后提出了两点：第一、测试用例的标题要简单明了，测试点明确，即是除了用例编写者本人，其他人一看标题就能清楚要测什么功能点。第二，希望用例编写者能更加理解客户的心态，能站在用户的角度来思考问题。

温婉在此基础上再作调整，发出来后大家的认可度提高了，然后开始写具体的步骤和预期结果，由于项目时间较紧，用例的颗粒度她没有写得太细，写完之后，又发给整个项目组，开发们有时间也会看一下，如果对她的预期结果有不同意见也会提出来，她再去跟YD的产品经理沟通，确定后再修改用例，最后再放到原来只用来报bug的项目管理系统里，如此一来，所有有该项目权限的人员都能看到这些用例，后面任意一个测试人员都可以执行这些用例。

等项目提测后，连婷作为主测试人员，开始与温婉分工合作，一起执行测试用例，每一轮执行都有记录，比如说一条用例，第一次执行，实际结果与预期结果不一致，即不通过，会将用例置为执行失败，并且说明有什么问题，下一轮提交代码回归测试时，如果实际与预期一致，执行成功。这样子按用例优先级全部执行完，至少能保证每一个模块都测到，不会出现之前的某一个模块重复多次测试，某一个模块完全不留意的情况。

其中连婷最喜欢的一个好处就是当上线之后出现问题，不再被开发质疑她没有测到。之前就吃过几次这样子的亏，线上反馈回来的bug，测试往往是背锅的那一个，非常憋屈。

以用例指导测试执行了一段时间之后，温婉遇到了新的问题，就是她时不时会指派错bug给开发，张冠李戴几次之后，开发们开始吐槽。温婉找张海涛了解每个模块对应的开发工程师，然后区分每个问题是java代码造成的还是静态代码（HTMLCSS）造成的，或者是设计图本身的问题。

08年的时候，前后端分离的趋势还不明显，但是静态代码是公司的UI设计师梁健写的，因此这方面的bug要提给他，设计图本身的问题也是提给他。

但是知道提bug给谁，这事还没完，有些开发人员在温婉提bug给他好几天后都不会处理，如果她在QQ上催了，就敷衍一下就后面改后面改，然后就不管了，还有些开发，提了bug给他，只要不是一级二级bug，他直接以“不是bug”为理由，或者“不予解决”将bug打回来，也没有任何的解释，她是后辈，那些人是前辈，人家也没有恶言相向，就是敷衍，温婉一时不知所措，连婷有时候看不下去，也会在群里提一下还有多少个bug没有改，让大伙们赶紧改。除此之外也没啥办法。

温婉绞尽脑汁，bug标题明确写明哪个模块出了什么问题，一目了然，哪个测试环境测出来的问题，使用什么账号登录，所有重现步骤都描述清楚，必要时还以图文结合的方式记录，就是不想给别人借口说她写的bug不清楚，但是效果不明显。她问过连婷是否会遇到这种事情，连婷说刚入职那会会遇到，后面跟开发们混熟了就少见了一些，但是日常交流上，还是感觉到有一些开发人员明里暗里的蔑视测试人员，觉得她们没事找事。

“。。。。。。”原来职场有这么多的糟心事的吗？

后来经过多轮测试后，有一部分顽固bug还是没有修复，温婉找测试经理李云报告了一次，李云一直在另一个驻场上班，很少与她们碰面，温婉也不想事事都找她“出头”，而且经过这一次的事情，她发现测试经理出帮她出不了头，因为她也叫不动那些开发，温婉追问那如果上线了客户发现了这些bug怎么办？李云说只要不是太严重的问题，他们都是等客户反馈回来，再更新一版。

这样子客户都能忍受？

温婉好像有点理解了穆总想要改变现状的心情，他耗费时间，不断的到高校寻找一个班科出身的测试人员，也许就是因为公司的项目质量受到了客户的质疑，他强烈的想改变现状，但是他是学开发出身的，对测试的理解也不深刻，目前公司内部的测试地位太低，开发人员对测试的工作不够尊重，质量管理工作无法有效展开，他想通过一个新鲜的血液去撬开一个缺口。温婉不确定穆总是不是有这样子的想法，她碍于实习生的身份，很多问题不敢提出来，怕得罪人，但是如果穆总确实是这样子想的，那她如此作为，岂不是又成为毫无主动权的测试人员中的一员，对于现状无补于事？

纠结于此事期间，她和连婷合作经过了七轮回归测试后，项目进入收尾阶段，对于遗留的bug，连婷记录到测试报告里，说明存在风险。但是这份测试报告往往也只是作为验收工件提交，实际会去看的人基本没有。温婉决定冒一次险。

“廖工，有时间吗？我有事情找你帮忙。”温婉想到一个稍微折中一点的办法。就是找研发二部的部门经理去说这件事情，请他帮忙打听老板的口风，对这种现象到底是要任其发展，还是要改善。

“行，我们去小会议室。”廖工显然也是有所察觉的，或者说，去高校招一个专业培养的本科生，本就是他和穆总共同讨论出来的办法，他们都在尝试，以图打破局面。

“廖工你看这个bug列表，现在一级二级bug还有2个没解决，三级的普通bug被置为不予解决的有十五个，四级的有二十八个，然后还有标为不是bug的，我与产品经理请教过之后确定是bug的，也将聊天记录贴到bug里重新打开了，但还是没有改。”温婉将屏幕推向廖工，“还有两天就上线了，这里面的bug也许还有部分是会被修复的，但是不予解决和置为不是bug的，我打开过两次还是被关闭了的，是开发人员不愿意改的，我听说以前也有这种情况，只要不是客户受不了了要求改的，基本就任其带bug使用了，而我作为一个人微言轻的实习生，明知道这样子是对项目的质量影响很大的，也不知道该不该提出来，不知道这种事情是不是领导默许的，这件事情我纠结挺久了，不知道怎么办，也不敢去找穆总，所以今天我先跟你说，想请你指点一下我。”

“这些bug你重新打开的时候，有主动跟对应的开发人员私聊过吗？”

“一般都有，也有一些确实与需求很不符的bug，我是直接贴上需求原文，然后重新打开的。”。

“你可以在重新打开的时候私聊一下开发，说明需求文档是这样子的，开发的实现有所差异，影响客户的使用，我们可以再把它完善一下之类的。”廖工说，“开发不愿意改bug的现象确实存在，之前在会议上也有说过，要求二级以上的bug必须优先处理。但是三级四级bug，他们会有比较多的理由不想改，然后测试人员妥协，导致上线后客户会看到不少bug，有些不好的反馈回来。现在我们在想办法改善，所以想让你尝试一下沟通，如果还是不行，我们会考虑采取更强硬一点的措施。”

“那其实这种情况并不是公司乐见其成的，对吗？”温婉求证，“我现在的行为，并不是多余的，对吗？我这几天都纠结死了，不说出来我憋屈，说出来又有背后打小报告的嫌疑。”

“没错，我和穆总一直在等你找我们，但是确实等了挺久了。”廖工轻笑，“当初去高校招人，穆总一直觉得不满意，找到你的时候，也是觉得把握不大，毕竟你的专业水平并不顶尖，笔试成绩平平，面试的时候技能也不算突出，只能算是思路还算清晰，文档写得还行，但是对我们的现状影响不大。因此对于招你进来是否‘有用’，我们真的是没把握。”

“那我尝试着沟通一下吧，不过之前在群里也催过好几次了。。。。。好吧，我知道催是没有用的，需要有效沟通。”温婉又要开始发愁，到底什么样的沟通才是有效沟通呢？