您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 其他 > 正文

关于测试过程中各种细节与资料的管理

发表于:2018-06-15 作者:知识在于点滴的积累 来源:博客园 点击数:

在一个产品的开发生命周期中,测试一直伴随左右。

测试工作本来就是很难度量的,测试人员也为此受到了不少的冷眼相待。(别问我,我肯定也受到过)

如果在这过程中,测试人员没有管理好各种测试成果,那么你的价值肯定会受到一定程度上的减损。

测试过程中主要要管理好哪些资料与细节呢?

一、文档类,这些首先是测试人员的劳动成果,可视化很强。
 

文档的种类,(评审后的需求文档,需求原型,测试计划,测试报告,测试总结),这些文档按照不同日期归类到不同文件夹中管理,这样,产品的任何一次变更,

自己对需求的理解,都会有迹可查。当然,SVN,GIT中也会有记录。自己辛苦手动备份一份,更稳妥一些。

我一般都会把需求文档打印出来,更改部分,都在纸张上标注清楚。这样查看非常方便。

需求变更太频繁,自己千万不要以此为借口,不做管理,不然,吃亏还是自己。

另外,对于需求,稍有遗漏测试,就会造成产品质量下降。朝着一个合格的测试人员靠拢,特别是产品人员有时变更需求,只是口头说说,没有落于纸上的情况下,测试人员更要及时把这部分需求记录下来,有记录总比脑子记要好些。(先记录在管理工具里,当天下班前,再复写到纸上,也行。)

测试计划与测试报告,这两种文档很容易管理,变更少,一经成型,很少改变。无非是多出几份报告,注明一下日期,这样就没有问题了。

二、用例类,
 

我没有把这类归到测试文档这块,因为用例类的管理也是非常麻烦的,当产品需求频繁变更后,用例能不能及时补齐,是判断一个合格测试人员的指标。还是那句话,不要找理由,什么…………,愿意不愿意及时补充,修改,在于自己,领导其实也管理不到这么详细。相信我,当你能及时补充后,带给你的好处一定大于你认为带给你的麻烦。这个时间花的很值。

别指望大脑记,落地的用例,比在脑海中更清晰,更能让你思路,场景考虑的全面。

写用例时,多看需求文档,每次审查时,你都会有新的灵感。

这点,我个人也需要提高,一方面需要提高用例的覆盖率,另一方面,提高用例的质量,多审查需求文档。

目前我所在的公司是用EXCEL表格管理用例,也可以用BUG管理工具管理。

对于用例我补充一点,当理解需求后,尽量画出思维导图或写出功能点,业务逻辑后,再写用例,进一步深入。

三、BUG优化建议类。
 

这个目前大部分公司都会有用例管理工具,如:禅道,testlink,bugfree等。这些工具很实用。尽量用活这些工具,它们有很多的功能,能帮助我们管理用例,有助于我们写测试报告。

也有用EXCEL表格管理BUG,都行。管好,用好。 对待BUG,能跟踪到位吗?直到它消失,是简单的回归一下,还是慎重的多次回归,测试没有侥幸。

四、产品上线后的维护。
 

这一点也可以纳入测试的工作范围,这些问题什么场景下产生的,能不能复现。当时是自己漏测试了,还是开发改动带出来的等,找到原因更好,最主要的是先解决它。对于客户反馈的事情,做到事事有回应,样样有反馈。客户付给公司的钱,70%是买你的产品,剩下的是买你公司的服务的。维护公司的信誉是公司每个人的职责。

客户反馈的问题都必须有记录,可以是客服,运维,测试都行,如果不是测试人员,就把客户向你咨询的问题,反馈给对应的记录人员,让他们记录在案。

并定期向客户汇报一次问题改善的进展,让客户心中有底。

五、如果一个测试人员负责多个项目的测试工作,工作量很大,测试任务很重。
 

如何管理好这些资料与反馈信息,考验一个测试人员的工作效率与工作能力。

我个人建议,先用笔记录下这些资料的地址,项目结束后,再统一整理好这些资料。

人都要珍惜自己的劳动成果。你遗漏的资料与信息都是你的劳动成果,不要轻易放弃它们。

测试技术有很多种,我也一直在学习。如:性能,自动化,安全。

但无论测试技术如何发展,一个好的自身管理水平不会逊色于测试技术。

当某一天你当上了管理人员,你面对的将是如何提高被测试系统的质量的重任。你完全可以把以前你自己的自身管理经验,复制到对下属同事的管理上。

管理---管人与理事。事理清了,安排给合适的人去做。并让他们反馈结果。