背景简述，多个前端和后端协同开发一个权限管理系统，技术栈是java + vue + element
我的bug
bug数量19,冒烟测试：无bug，严重：4，一般：7，提示：8，
bug分解
4个严重bug
- 用户管理、添加用户时没有默认密码
- 用户管理-编辑用户信息后，留在选择的页面。
- 用户管理、添加用户页面的角色框和设计不一致
- ……
7个一般bug
- 用户管理、编辑密码后再次点击密码框，密码消失
- 用户管理、用户列表中无角色用户不能启用
- 用户管理、添加用户时，选择角色超过一行时弹框拉长，不要混动条
- 用户管理、用户列表只有一个用户时，点击查询报500错误
- 用户管理、该模块所有按钮的hover颜色不符合设计稿
- 用户管理、添加用户的弹框位置不正确
- ……
8个提示bug
- 用户管理、用户列表不要自适应
- 用户管理、用户列表在1366*768时出现混动条
- 布局问题。
- 权限设置、权限管理的展开箭头位置不正确（360浏览器）
- 用户管理、用户列表的查询按钮点击后颜色变化
- ……
能记得的bug就这么多了，从上面可以看到，bug的种类很多，有ui问题比如没有还原设计稿，有交互问题，还有的是自找麻烦
具体分析部分bug产生原因
交互的bug
-
用户管理、添加用户时没有默认密码
产生问题原因：第一版产品稿要有默认密码，后来被产品否掉这个功能，而且通过邮件通知了开发，只是原型没改，而我看过之后忘记了这茬，按照原型开发所以产生了bug
主要是差了一点细心 -
用户管理-编辑用户信息后，留在选择的页面
产生问题的原因：交互体验问题，用户管理是一个列表，在那一页编辑后还应该停留在操作之前的页面而不应该刷新跑到第一页，
其实这可以算一个bug也可以算一个优化，因为产品没有明确的规定，应该如何交互，但是我个人感觉测试提出来的这个交互确实要优于每次编辑后跑到第一页 -
用户管理、用户列表只有一个用户时，点击查询报500错误
产生问题原因：修改了一个问题而产生的另一个问题，更改一个问题后没有再次冒烟测试
ui还原的bug
-
用户管理、添加用户页面的角色框和设计不一致
产生问题的原因：不是同一个人开发的模块，一个用的是button一个用的是el-botton
这个问题确实是很多中小公司普遍存在的一个问题，原因是不同的开发同时开发同一个项目的不同模块，而且没有统一的开发标准很规范，导致会有1~2个像素的偏差 -
用户管理、用户列表不要自适应 / 用户管理、用户列表在1366*768时出现混动条 / 布局问题
产生问题的原因：自作聪明
上面的三个bug都是ui还原的bug
都是自找的问题，根据之前的惯性思维对表格做了适配希望在不同的屏幕上看到的bug都是一屏展现，而不需要滚动条，ui看过之后表示不需要做适配，从而导致了后面的两个布局的问题 -
用户管理、该模块所有按钮的hover颜色不符合设计稿
产生问题原因：ui频繁的更改产品色调，而我没有及时调整更新规范文档，还有就是样式的层级问题element不同的类型hover颜色不一样，所以需要有一个更高层级的东西覆盖原来的样式一劳永逸
兼容性问题
- 权限设置、权限管理的展开箭头位置不正确（360浏览器）
产生问题原因：element自带的bug,而我没有测试到360浏览器，自我测试的问题
插一个开发和产品,ui争执的一个点
image.png
看上图产品在规划的时候是有跳转功能的，但是ui设计的时候是没有这个跳转的
开发在第一版的时候也是添加了这个跳转功能的，但是看了ui图之后又去掉了，测试的时候给我们提了一个bug
但是ui和开发都不认为是自己的问题，ui认为这些实现细节需要按产品的来而且这个是常识性问题，他们只是出样式。而开发认为这属于样式问题，产品怎么画，开发就怎么实现，应该是ui的锅
其实这个引申出来一个问题就是我们开发的时候细节是看产品还是ui设计稿，关于这一点是有一个很明确的答案，一切按照产品文档来，至于ui没有画跳转框是可以给ui提bug的，如果ui认为这是常识性问题，那么ui应该把这个常识性的东西写到ui开发规范文档里，一劳永逸。
总结
-
产品评审的时候，脑子里一定要有产品实现的交互细节，不清楚的地方一定要和产品沟通清楚
-
ui评审的时候如果有必要一定要拉着ui问一下他想要什么样的布局，好的布局在产品体验上还是很有优势的，而且ui在提测后也会参与ui验收，你的布局不一定是设计师想要的效果（极端情况下，如很小的屏幕，滚动条出现的位置等等），这个时候在来讨论是谁的锅已经不重要，因为大家都想要完成一个优秀的产品，所以需要把这种情况扼杀在摇篮里
-
不要自作聪明将别的项目的风格习惯带到新的产品中来，如上述bug表格的屏幕适配问题，要不然后果就是你发费时间做出来的功能，ui会否掉，并且增加一个bug。开发在ui评审会上可能不能想到所有的细节，开发过程中也是可以沟通的，要在模糊的问题上做好沟通工作
-
不要相信什么常识性问题，因为每个人对于常识性问题的认知不一定一样，当然我们要相信专业的人做专业的事情，如果ui认为是常识性的东西，记得要让他更新到ui开发规范文档里，避免扯皮问题的发生
网友评论