想问一下就是软件测试思维导图的测试图和测试统计表怎么写

很多软件测试人员的薪资都卡在6k-9k这个阶段,很想过万却始终迈不过去这个坎。

出现这个问题的原因一方面是自己的认知和思维出现了瓶颈,另一方面就是自己的能力在一些关键节点上有很大的缺失,但是自己觉察不到。

那么如何解决这两个问题呢?希望我整理的自己多年的经验能够给你们一些启发。

先放一下文章的思维导图

软件测试月薪过万十条建议

图片上传可能不太清晰,需要原图的直接私信我

这篇文章主要还是解决软件测试从业者思维思想的一些问题,说白了,技术上的问题好解决,认知和思维上的问题不好解决。

文章主题《年轻测试人员薪资过万的十条建议》,共计3500字左右,预计阅读时间4分钟

个人工作经验总结,绝对原创!

1.出现问题解决后知道是如何解决的

比如出现bug要知道是什么类型的bug,是什么类型的问题引起的。

2.对不清楚的需求要问清楚再去测试

3.对于bug修改进度的跟进

对于严重级比较高的bug,要每天跟踪修改的进度,改成什么样了,还需要多长时间。

4.难以再现的问题,给予绝对的关注

不能因为又一个问题无法重现,就直接放弃。

这个问题解决了可以直接导致项目质量很大提升,如果一个测试是”差不多“的态度,第一领导不会放心,第二项目质量一定不会高。这样的人升职加薪也就无望了,同时也没有办法提升自己。

技术的问题好解决,唯独思想思路的问题不好解决

项目周期时间把控非常重要,如果说来不及了,合理的安排一些加班,并且要每天的去跟进这个项目的进展

2.每个测试阶段的时间把控

测试过程中,会分为很多的阶段,都要提前的给它设置好时间节点,然后再去控制它,让这个测试周期确实是在这个测试时间节点之内

3.学习工作休息娱乐时间比例的把控

上班时间中把这些时间合理划分,工作一定要站在50%以上,如果工作时间占了每天8个小时的50%以下,那么就是一个不合格的测试工程师了,离开除就不远了,在合适的时间偷个懒是可以的。

如果一个人的时间观念非常差,在工作中会体现的非常明显。比如上班经常迟到,比如领导交代的任务总是不能按时完成。

表达能力在与开发人员沟通过程中以及在面试中都非常的重要,如果一个人的表达能力不行,那么这样的人是做不了领导的,向上的空间也会很受限制。当然,不爱说话,不代表表达能力不好

一个是认真的倾听别人的意思,比如产品经理讲需求文档,要准确理解他的意思;在一个就是在别人说话的时候不要打断,思路一断很难接上来。很多人在职场中被人排挤,却并不知道原因,都是细节的原因。

主要是指能够提出建设性的意见建议。当然这一点需要注意的一定不能总是为了凸显自己而去特立独行的唱反调,这样会死的很快。

另一种就是认真倾听别人的发言,然后最后能够总结并延伸出新的观点,这样的一看就是有leader的潜质。

决策能力就是拿出有效的依据和理由去说服对方。

别人已经提出来了一套方案的时候,能够拿出有效的理由和依据,告诉他,你是错的,为什么是错的,能够把理由跟依据说得非常的详细,而且确实最后的结论确实是错的。这样的话,领导会高看你的,为什么不给你加薪。

有效的沟通能够帮助你很好的理解别人的思想和意图,并且提出不一样的观点和看法,同时也能够让别人去接受你的观点和方案,让同时更好的接纳你,让领导更加的认可你

主要是关于逻辑和业务流程,这个不多讲

2.提高测试用例的编写速度和有效性

别人写一个测试用例需要两天,我只需要半天,完全可以把他开掉,然后给我涨工资。

3.能够快速进入测试的状态

很多人刚接手任务的时候,很长时间都进入不了测试的状态,只有越测发现的问题越多,形成机械化的模式,就进入状态了。这也就是很多人测试的时候特别讨厌别人打断。

首先要说,很多测试人员去跟进开发人员改bug,都不是有效的,因为他们只会一味的在群里催。

首先要问开发这个问题是什么原因,为什么会出现这么严重的错误,这个问题修改需要动多少模块,需要动多少代码,这个问题问清楚,需要多长时间自己心里就有数了。

很多测试人员表面上看到问题出现了,实际牵扯很多的页面,越催开发反而越紧张

5.能够快速判断问题的位置

必须写出直观的缺陷报告,一定要简捷、清晰、易懂。

什么叫问题位置,当你们发现页面当中存在一个缺陷的时候,能够快速的知道这个问题是什么原因引起的。不用看代码,那个属于白盒测试。同时要知道通过什么样的操作能够重现这个问题,并且能够用禅道或者至少能够把它清晰的编写出来。

只有工作的效率提高了,每天干的事情才会越来越多,这样才能越来越值钱。千万不要觉得自己现在的工作效率很高很牛。

1.能够站在开发的角度思考问题

第一个,千万不要发现一个严重级的bug就大呼小叫,让全公司的人都觉得你很厉害,这样会深深的伤害开发人员,因为代码都是他们写出来的。

第二个,千万不要非常强硬的催开发人员,因为开发们该bug也是非常苦恼的,同时还要面对领导的压力,同时要面临你们的压力

2.能够站在产品的角度思考问题

对需求文档或者是业务出现了一些争议的时候,不能把主观的只考虑咱们测试的角度,我认为这个功能不合理,我认为这个模块多余,我认为这个流逻辑不通,我认为这个优惠卷就设计的不对,那么当你们确实认为这个东西不对的时候,我希望你们也能够理智地去探讨的话,去跟他聊

3.能够站在用户的角度思考问题

讲到用户的角度,就是用户体验这一块,每一个测试出来的项目,都一定要站在用户的角度上去感受一下这个项目好不好用,能不能达到我的需求,易用程度就是站在用户角度,你们会发现更多的问题

4.能够站在领导的角度思考问题

当你们能够站在领导的角度思考问题了,我觉得你们已经离领导不远了,因为一般的公司的员工,他们只考虑的就是自己能够怎么样,我能够做什么,然后我能够为公司带来什么,但是有一些员工的他们就想着我能帮领导解决什么问题,我能帮领导分担多少压力。

当你们自以为是总是以自我为中心的时候,你们永远都不会站在其他人的角度上去思考这个问题。你们只会适得其反,遭到别人的批评或者是指责。当你们学会了去站在对方的角度去想这个事情的时候,你会觉得自己有很多话都不该说,有很多事情可能都不该做了,这样的话你们的为人处世,包括你们的这个公司的氛围越来越好

1.想问题的出发点一定要越来越高

只有出发点高了,想问题才会全面

2.做事情的态度一定要越来越严谨

做测试过程中的一些表现,包括跟进缺陷的一些表现,包括做性能测试、自动化测试的时候的一些态度,包括一些细致的报告,这些东西都能体现出来你们做事严谨不严谨。严谨的人写出来的报告是非常的完美的。不严谨的人,他们的报告漏洞百出。

3.判断逻辑的思路一定要越来越清晰

一个功能别人测能考虑到10种可能性,让你来测你只能考虑到5个可能性,这就是差距为什么别人挣的比你多,因为思维水平太差.

举个例子:业务里边有一个积分的功能,小白想到就是积分能不能用,这积分是怎么来的,怎么能获取到积分,到了多少才能使用,有没有商品达到了一千积分才能用的,积分能够换商品能够换什么商品,这是小白能够一眼看到了一些需求。但是一个资深的测试呢,他的判断逻辑判断能力思路非常的高,非常的活跃,那么这时他会想了积分,跟优惠券能不能一起用对不对,我用了积分之后,如果退了退款了那么还是不是这些问题,一般小白想不出来了。

4.具备为达目标而解决难题的能力

千万不要抱有出现难题有主管,有经理去解决的想法,不要总想着把这些问题去推给别人。

想别人没有想到的问题,做别人不愿意做的事情,解决别人解决不了的问题

技术性的不多说,缺什么补什么。就一句话,2018年功能测试点点点会越来越不好混了。关于技术的成长路线可以参照我的另一篇回答,里面有详细的技术成长路线图。 我的知乎回答。

不断学习最新的技术工具

不断探寻最先进的测试思想

快速掌握技术的核心,快速达到实战的能力

尽可能节省时间学习,追求快速奏效,再继续提高

努力在测试中找出别人找不出来的问题

努力去解决别人解决不了的疑惑

努力去担当别人不愿意担当的任务

努力去完成别人完成不好的工作

把能做好的事情做到极致,把能力范围外的事情努力做到最好

思考在别人眼中你的问题

思考如何做的更好,如何解决已知问题

按照这样的方式去查找自身存在的问题,相信一定可以突破自身的瓶颈。我的另一篇回答详细说了关于一个优秀软件测试工程师必备的8个能力。

码字不易,做思维导图更不易,走之前麻烦点个赞喽!

XMind软件一直是一个比较受欢迎的软件,之前的zdfans的时候就备受关注,但是也是各方面收到警告等等问题,所以很多软件破解者都将此软件作为收费的软件或者做了一些设置,导致很多人都不能下载,今天有幸在吾爱破解论坛看到苦瓜甘甜大佬发布了这个软件的特殊版本,赶紧分享给大家,有兴趣的用户赶紧下载收藏吧。

下面附上几张来自吾爱破解论坛的图片:

同时附上原文链接以及相关说明:

资源地址为软件作者分享,失效请自行解决。


原标题:测试人员必知的14个软件测试文档,写测试报告不再迷茫!

在我的测试生涯中,我注意到很少人对测试文档有足够的重视。俗话说“好记性不如烂笔头”, 事实上,详细的文档可以节省项目的时间,提高工作效率,减少费用支出。这就是为什么各种认证中,都强调记录文档。下面我与大家分享文档在软件测试中的重要性:

那软件测试文档到底是什么?

测试工作的角度,测试文档大致分为两类:产品和工具。产品是供他人阅读和使用的文档。工具是测试小组的内部文档或测试人员的个人文档,目的是帮助测试人员更好地测试。测试文档是形式化测试过程的一个重要组成部分,也是质量管理过程的一部分。如何使用测试文档才能对我们的工作真正带来价值呢?

想要解决问题有个原则就是先研究问题的原因,在选用模板这个问题上这个原则同样适用。可以从这几方面分析来分析测试文档的需求:

1. 测试小组的使命是什么,测试这个产品的目标是什么?

2. 自己的测试文档是产品还是工具?

3. 设计变更有多频繁

4. 反映设计变更的规格书变更有多频繁

5. 测试时是希望证明与设计不一致,还是与客户期望不一致?

6. 要采用的测试风格更依赖于用例还是探索式测试?

7. 测试文档应该关注测试什么(目标)还是怎么测试(过程)?

8. 需要用文档控制测试项目吗?如果是,那么如何控制,初期or后期?

9. 测试文档的目标读者是哪些人?他们的关注点是?这些读者有多重要?

10.需要多强的跟踪性?是否需要跟进哪些文档?

11.测试文档要在多大程度上支持项目状态与测试进展的跟踪和报告?

12.测试组成员能力如何?测试人员懂得越多,文档可以省略的越多。

13.测试时需要做的三方面工作(预防、检测、预测)哪方面占比更多?是否需要舍弃一些?

在软件测试生命周期中,有数以百计的文档。功能主要有3个:为完成技术任务提供便利;改善测试任务和测试过程之间的联系;为组织、规划和管理测试项目提供结构。

下面我列出需要用到且比较重要的软件文档。

测试计划是一组指导测试过程的想法。制定良好的测试计划需要深入评估项目情况,充分利用测试资源,合理安排测试任务。其中测试过程是核心,测试任务决定了测试过程的目标。包含五个元素:需求(产品获得成功的条件)、开发(产品开发的环境)、测试团队(测试小组的特点)、测试实验室(测试小组可使用的软硬件资源)、任务(测试小组要提供的服务);测试过程是完成测试任务所需要执行的活动,其要点是测试策略、保障条件、工作产品。只有符合项目情况的测试方案才能有效地工作。

ACC是谷歌测试团队使用的一种建模方法,快速的建立产品模型,以指导下一步的测试设计。

第一步是确定产品的属性。包括社交、表现力、自如、相关、可扩展、隐私。

第二步是确定产品的资料。包括个人资料、人脉、信息流、圈子、通知、视频群聊、帖子、评论、照片。

第三步是确定产品的能力。能力通常是面向用户的,反映了用户视角的产品行为。基本思路就是专注于核心属性、核心功能和核心能力,省略一切不必要的细节。

测试设计规约记录了测试人员的测试设计。

第一,测试规约是一个容器,可以容纳各种测试模型和资料。

第二,测试人员需要建立测试设计的框架。

第三,测试想法优于测试用例。

第四,合理地使用文档模板。

功能列表是一种功能测试的建模方法,通过将产品的功能分解为层次结构,为功能覆盖提供指导。功能列表与漫游测试可以相互支持。一方面,功能列表为功能漫游提供了有益的信息。另一方面,倘若测试人员不了解被测产品,可以通过功能漫游建立功能列表。

漫游测试是一个个很好的学习过程,功能列表是一个有意的学习成果。另一种更有效的方法是综合功能列表中的多个元素,来测试功能的协作。在回归测试中,功能列表是很好的参考。

思维导图的一些重要特点:

与大纲一样,思维导图提供了清晰的层次结构;思维导图用词语来记录测试设计,使得测试人员专注于思考;拥有注释,包含更详细的测试设计;与大纲相比,思维导图更引人注目;思维导图可以使用其它标识,激发大脑的兴趣;思维导图还可以使用视觉元素表达语义,提高了信息传达的效率。

表格适合表达两个变量之间的关系或两个变量共同作用的结果。此外,表格还用于表达业务规则。表格即是测试设计的产物,又是测试执行和测试报告的工具。在实际的测试工作中,测试计划、测试笔记和测试报告应该紧密联系,在一些情况下,它们可能来源于同一份文档。

测试指南是针对特定领域,阐述被测对象的特征和相应的测试策略,帮助测试人员了解基本的领域知识,并实施针对性的测试。

像是想法列表是一种简化的测试指南,列出了一组测试想法,帮助测试人员构思具体的测试。每一个测试想法都用简单的词汇、短语或实例来说明,测试人员能够快速知晓,立即应用。9.质量特性列表

质量特性列表记录了软件需要考虑的质量因素。质量特性列表是一种测试覆盖率检查工具,它可以帮助测试人员发现测试设计的不足,并提示新的测试策略。

为了帮助测试人员完成任务,测试小组可以编写一批操作文档。随着软硬件的发展,视频录像成为新形式的操作文档。

为完成一项复杂的任务时,人们需要分析并处理多个细节。检查列表是一种提示物,帮助测试人员在面对复杂产品时不会遗漏重要的工作事项。

收集并整理典型缺陷有助于吸取教训、对症下药,是一项有价值的活动。可以多角度的利用该文档:浏览缺陷目录,标注出产品可能出现的缺陷;将缺陷目录作为攻击指南,根据典型缺陷和产品的特点,来做快速测试;提炼出特定领域的缺陷,作为测试指南等文档的附录;分析缺陷目录,找出可能发生的缺陷,与程序员交流这些潜在的问题;在测试小组内讨论这些缺陷,从而帮助测试小组建立团队测试策略。

为了有效地管理测试,测试经理需要评估测试团队的生产力、当前的测试进度、测试覆盖的范围、已经暴露的风险、测试人员是否需要帮助等因素。

一个测程包括4个要点:主题(一个测程需要完成的任务,主题是测程的指南针,好的主题阐述了探索的对象、要达成的目标、可利用的资源)、时间盒(是一段不受打扰的测试时间)、可评审的结果(测程的产出,内容包括主题、测试人员、测试所覆盖的区域、测试设计和测试发现、测试所发现的缺陷、测试所发现的问题、测试所使用的数据文件、测试活动的时间统计)和简报(面对面的交流将测试情况传递给测试经理)。测程表的本质是测试报告,向团队提供有关产品和测试的信息。

测试人员离开项目时,可以考虑撰写移交文档,帮助接手其工作的同事尽快上手。移交文档更注重于回顾和总结。主要包含如下:被测对象概述;文档链接;基本测试想法;经验与技巧;已知局限;测试自动化;测试数据。

总结:测试文档是项目团队或测试人员实施测试的工具。

测试文档的根本价值在于帮助测试人员更有效地测试;偏离此价值的文档过程将浪费资源,危害项目。

在复杂的软件开发中,测试文档并不是一份文档,而是一组文档,测试人员要根据项目语境,决定测试文档的类型、内容和形式。

测试文档要为读者服务,在许多情况下,测试文档最重要的读者是测试人员自己。

用核心文档组织测试素材,构成测试文档集,让多份文档相互支持、彼此参考。

首先建立测试设计的框架,然后在测试学习、测试设计、测试执行、测试评估的迭代中,注重实效地发展测试文档。

了解不同形式的测试文档,收集不同内容的测试资料,有助于全面思考、灵活应用。

关注51Testing软件测试网,提升it技能,从不会到熟练只差一步。

我要回帖

更多关于 软件测试流程图 的文章

 

随机推荐