15.8测试心得--吐槽版

  做为一个版本发布背后的男人,本来每次发版本后只需深藏功与名,留下孤寂的背影。奈何交稿日期要到了,部门又无稿可交,怎么办…怎么办!!!只有让他们一人交一份15.8测试总结(邪恶笑…),然后就有了此文。

  如果让我用一个词形容15.8,就是“突破”,设计上面终于有所突破。做为一个终日活在终端下面的男人,其实已经对UI麻木。15.5,15.6,15.7 曾经多个历史版本摆在我面前,我都毫无感觉,直到15.8,终于让人怦然心动。于是乎赶紧试试新托盘,拖动…不支持!隐藏…为什么输入法总怪怪的!咦…dock呢!!!蹦了(开玩笑),总得来说设计已经非常让人惊艳了。然后是控制中心导航页设计的变动,额…想一想好像没什么好吐槽的,该吐槽的论坛已经把槽吐成大坑了。

  咳咳…进入正题,让我走进测试同学们的内心世界,感受他们来自灵魂深处的呐喊(tuicao)。排名不分先后,首先就以z同学开始吧。

  代码管控依然不够精确,代码冻结依然不够彻底

  一个产品的周期,从产品需求->设计->开发->测试。一般在开发完成之后,提交测试的时候,代码就应该冻结了,以确定形态的release转测试。这次版本测试毫不意外的,测试执行过程中依然伴随着少量的代码合入以及需求变更。这对于系统漏测来说,简直就是原罪。因为我们的代码开发完成之后,没有单元测试,其直接合入的代码造成的影响,没法准确评估。还是希望产品、开发、测试相关的负责人,在以后的版本转测试的时候,尽量的避免变更,把有疑问的需求能够提早的确定清楚,避免转测试之后造成测试盲点。

  代码管控这个话题其实是一个老生常谈的话题,一直存在从未被解决。怎么说呢?好坏全凭运气,当然这个问题开发同学一直在致力解决,打个比方,就像科学家攻克癌症一样,梦想总是要有的…
  
  下面是w同学

    第一轮全量测试正常,后面更新版本又不正常
    修复问题而引入其他bug
    grub事件

  【A1】deadline+提升专业知识
  碰到这个问题主要有3个原因:其一,第一轮测试时,打入iso的包并非最新版本,即开发的功能并没做完,只完成部分功能,后续需要更新版本;其二,修复某个bug引入了隐式bug;其三,测试人员第一轮未发现该问题。
  对于原因一,本质问题是时间到了,但是某个模块还没做完、还未进行过彻底测试。故大家尽量完成上述各个阶段任务:
开发/测试需守住deadline,在ISO开测之前,保证所负责模块代码完成且经过彻底测试。
  原因二、原因三均可理解为专业素养不高,故可从以下方面展开:
理解代码实现逻辑及背景知识
  故所周知,需求文档其实写的很简单,主要告诉大家,我需要实现什么样的功能,具体怎样实现、采用什么样的技术方案,均没出现。但是我们的测试方案、测试用例均来自于需求文档,想想看,这样的用例覆盖能全吗?怪不得出现上述二(不能及时发现隐式bug)、三(靠运气碰bug,不能复现某些bug)问题。
  个人认为,开发要做一个东西,还需要进行背景调研、技术选型以及代码逻辑,测试同样需要做这些工作。背景知识,可以通过开发拿到的原始资料+网络搜索进行了解;代码内部逻辑实现,可以通过代码文档进行理解。在此基础上,我们才能设计出有针对性的用例,不然一切都是盲测、盲测、盲测……
ps:值得表扬的是,开发已经有相应开发文档,一般在tower“开发项目文档管理”,或者项目代码的README里面。鼓励开发大佬们多输出文档。
  【A2】代码合并控制+重要模块针对性测试
  这个问题防不猝防,纵然测试人员有三头六臂,也不能提高产出ISO的质量,需要从源头控制,即代码合入量控制+代码合入质量的把控,外加重大模块针对性测试,该项问题基本能够解决。
  二轮ISO生成,开发只合入重要bug修复的提交,且合入需确保代码质量。假如“ISO测试之前、测试已经针对各个模块进行过彻底测试”的条件成立,此项方案就能够开展。
  二轮测试重点为基本冒烟测试+更改包的测试。如果合并了更改量大的模块,或者发现问题较多,需针对该模块,进行相关的全量测试。注意,此种场景的模块不宜多!!!
  【A3】方案验证
  据悉,grub分辨率之前并不是固定的,由于测试期间,出现grub选项不显示、位置不居中等问题,所以临时决定分辨率定为1024768。改后方案,作为开发/测试来说,应该预测到不同显示器会有显示不清楚、发虚的现象。既然如此,该方案就不该问世,果断回退之前正常版本,保住最后底线。
  此处只提及了grub事件,但代表此类问题,对于这种位置显眼、又特别重要的功能项,在做需求方案+技术选型时,需要多人进行反复验证得出结论,大胆想象、小心求证,尽量避免开发完成代码再去修改方案。再次强调下,方案不能一个人拍了脑袋算,需要多人反复验证。

  L同学

    Github不好用

  额…这个没啥好说的,肯定不(巨)好(难)用,但是github替换tower给我们带来的益处,不是短时间可以体现的,相信大家都是知道的。

  最后是我们的y同学:

...
...
...
...

  咦…怎么是空的?对!y同学是个善良的妹子,基本全篇没有看到什么吐槽,都是总结性的建议。
简单抄录一下:
  在测试过程中,有些时候遇到的一些问题,可能会被测试忽略,因为之前版本可能一直就是这样,就被默认为是正常的。还有一点问题是,测试对需求的了解除了需求文档外,可能更多的是从开发处获知 ,即测试为最终知晓需求的人,希望产品在和开发讲解需求的时候,也能够通知到测试。
  测试内部如果发现了不属于自己模块的问题,提单的时候可以@相关人员,或者选择让对方提单。可以提醒对方是否测试过程中遗漏了问题,或者避免提重复的问题。

  当然质量部门同学总结的心得不仅仅这么多,后面有机会可以再写一遍文章来分享分享。

5 条思考于 “15.8测试心得--吐槽版

  1. wangyaohua

    deadline 意识确实是每一个成熟的开发都应该有的意识,没有做好不做过多解释,虚心接受。不过,滚动更新以后这个影响会小一点 🙂

    单元测试等DTK文档做得差不多就会开始推进;

    需求变动的问题在上次“挂载插件没有当做托盘”事件以后我也想了一下,以前做得需求讲解似乎一直都被忽略了,是时候再捡起来,保证需求都被充分解释给了开发和测试。

    代码合并控制这里需要说一下,这对于某一个人来管控十几个项目的代码合并并不是一个特别现实的事情,所以我一直在把很大的控制权利交还给每个项目的开发者,当然这比较理想化,希望大家都是成熟的程序员,能拿捏分寸,懂得取舍……不太现实,但是这是必须要向着去努力的方向。中间过程的这些问题,确实都是问题,但是如果能换回来一个好的结果,就是很值得的经历。多次犯错的开发,肯定就不会再享有这项权利。

发表评论

电子邮件地址不会被公开。 必填项已用*标注