2019-04-27 10:26:48 sylan15 阅读数 520
  • 软件测试入门视频教程

    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试、回归测试、验收测试等。本课程以接地气的语言来讲解,让你听的懂,学的会!本课程以全新的方式为你呈现教学内容,清新脱俗独具特色的授课方式将带给你新的体验。

    2158118 人正在学习 去看看 李晓鹏

乔布斯曾经说过「每个人都应该学习编程,因为它会教你如何思考」,看,乔帮主都觉得所有人都应该学编程,那你说做测试的要不要学?当然要。

作为测试人员,除了上面这个原因,我觉得如果会编程,还有下面 3 个好处。

1、知道技术实现,可以设计更有针对性的用例

比如我在《需求评审之实战演练》中提到的关于计算器的测试,有些人会写一条用例是「测试一个超大的数」。

但是问到多大数算大?100000 算不算?很多人回答不上来。

也就是说,很多人知道需要测试边界值的情况,但是没人知道这个边界值到底是多少。

当然也不是所有人都不知道。

比如有人说,是 int 类型的最大值,得,能说出来这个就已经很靠谱了,试想下,如果你不会编程,你能知道什么是 int 类型?你能知道用 int 的最大值去做针对性测试?

2、更容易和开发进行逻辑层的沟通,更好的拓展测试思路。

比如一个同学发现一个 bug:
如果在 windows 的系统盘根目录丢一个 program.exe 的文件,某些程序在执行进程创建时,就会出错,把 program.exe 执行起来了。

于是这个同学就去找开发沟通。

第一个同学的沟通过程是这样的:
测试:「xgg,这个问题是什么原因导致的?」
开发:「目标进程路径带有空格,我代码中没有加引号,所以就出问题了。」
测试:「噢,好滴。」

另一个同学觉得还是有疑问,于是再次找到开发。
测试:「xgg,具体是哪个实现的问题?是我们内部的函数实现?还是调用的系统 API 有问题?」
开发:「我用的 CreateProcess API,他的第二个参数如果带有空格,又没有加引号,就会出这个问题。」
测试:「CreateProcess API 使用的地方很多,能否搜一下看看每个地方本次都做了修改?」
开发:「好,马上看。」
测试:「同样功能的 CreateProcessAsUser、CreateProcessWithLogon、CreateProcessWithToken 应该有类似的问题,可以一起搜一下看看都处理了没有。」
开发:「好,立刻看。」

如果你是开发,你喜欢和哪一位测试配合?

如果你是测试,你希望自己前面那位同学还是后面这位?

3、更好的自动化思维,把提效落实到实处。

现在很多功能,都会在逻辑中加一些日志,如果是调试版文件,日志输出就更多了,对于客户端产品来说,很多日志输出在 dbgview 里,我们可以通过一些过滤条件进行过滤,甚至设置高亮,但如果是输出的纯本地的文本日志,那么每次查看日志就必须要 Ctrl+F 然后输入关键字逐个去确认了。

我们看看手工操作的步骤:
第一步:找到日志文件并打开;
第二步:Ctrl+F 调起搜索框并输入关键字;
第三步:回车-检查-回车-检查,如此反复;

这时候如果有一个同学,会一些简单的脚本技术,可能会考虑对这个过程做一个优化,比如提供一个工具,只需要在工具中输入关键字,工具就会自动找到日志文件,并把所有关键字相关的记录都提取出来,会不会爽很多?

我们看看使用这个工具的操作步骤:
第一步:打开工具并输入关键字(工具自己查找日志路径,并且在每次操作时都保证获取的是最新的日志);
第二步:检查结果(结果中全都是相关性内容);

看起来只是节省了一步吧,但是工具这两步操作中,都隐含了大量的重复操作的优化。

比如第一步「打开工具并输入关键字」,其实工具是自己查找日志路径,并且在每次操作时都保证获取最新的日志,这样就避免了手工操作时每次都要重新打开日志的麻烦。

比如第二步「检查结果」,之前是在所有日志里面去一个个检查搜索结果,现在工具出的结果是只显示和关键字相关的上下文信息,可以极大地减少其他信息干扰,更快更准地找到自己需要的信息。

如果你不会编程,你会考虑用这个简单的工具去提效?

就算你考虑到能用工具提效,你能快速准确的把自己的需求提出来并找到人帮忙实现?

就算实现了,碰到一些小的体验问题你能总是不断找人帮忙优化?

最后再总结下我的结论。

做测试要不要学编程?我的答案是,要,会编程的测试可以往业务线的测试开发方向努力。

我不会编程能不能做测试?我的答案是,能,不会编程的测试可以继续在业务专家方向深耕。

以上,你会编程不?目前什么水平?自己团队小伙伴的编程技术都什么水平?你认为做测试到底要不要学编程呢?欢迎留言和我讨论。

当然,如果你支持我上面的观点,请点个「在看」让更多人来一起看。

本文首发于公众号「sylan215」,十年测试老司机的原创干货,关注我,一起涨姿势!

sylan215

2018-03-26 19:58:41 test_xhz 阅读数 6082
  • 软件测试入门视频教程

    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试、回归测试、验收测试等。本课程以接地气的语言来讲解,让你听的懂,学的会!本课程以全新的方式为你呈现教学内容,清新脱俗独具特色的授课方式将带给你新的体验。

    2158118 人正在学习 去看看 李晓鹏

首先你对软件测试是否足够了解, 软件测试是目前的热门行业,薪资也比一般的行业高,工资的增长幅度也比较快,这些都是光鲜得有里面,但是软件测试的工作压力还是比较大的, 技术更新也比较快, 软件测试是一分付出一分收获,薪资就是对你最好的肯定。

如果你做好了选择,决定从事软件测试,那就接着往下看

自学

优势:金钱成本较低,能够按照自己设定的学习计划进行学习,时间安排也比较自由。

劣势:自学消耗的时间比较长,如果没有基础的话,想要自学也是比较难的,相对于有一定基础的,现在网上的软件测试资料也比较多, 需要自己去识别哪些是自己要学习的, 不然很容易陷入迷茫。

培训

优势:学习时间相对较短,整体学习比较全面,学习内容也比较集中。而且有老师给指导,学习的范围也是目前行业的热门技术,学习更有针对性,转行的效率更高

劣势:相对于自学,培训是需要金钱成本,一般的培训机构学习费用都在一万五到三万不等左右,还要加上学习期间的生活费,学习成本比较高,

如果你不是一个自制能力很强的人(你自己也觉得不是),那还是选择培训比较靠谱一些

如何选择培训机构

1、就业薪资虚假宣传,薪资动不动就达到一两万,不务实,你让公司里那些做了几年还没这个数的前辈们情何以堪。

2、就从老师来说吧,选择授课老师的实战经验比较足的机构,这些老师讲的内容基本都是行业的热门技术,现在有些机构还在讲QTP这种业界目前不太流行的工具,简直就是误人子弟。

3、选择小班教学的机构,最好不要超过15个人一个班的机构,这样老师才能够照顾到每一个学生,让每一个学生听懂,把知识学扎实, 学生太多就算是名师也不能照顾到每一个人。

4、行业内口碑比较好,业界没有学生的负面新闻,学生对培训机构比较认可,这种机构把精力放在了学生身上的机构,才是做教育的应有态度。

2018-04-01 16:25:35 qq_41248484 阅读数 1106
  • 软件测试入门视频教程

    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试、回归测试、验收测试等。本课程以接地气的语言来讲解,让你听的懂,学的会!本课程以全新的方式为你呈现教学内容,清新脱俗独具特色的授课方式将带给你新的体验。

    2158118 人正在学习 去看看 李晓鹏

最近碰到一些做程序员想转行测试的小伙伴。

程序员到底要不要转行软件测试?

其实这个现象一直存在,各行各业转行的例子不在少数,厨师都有可能转行做程序员,那程序员转行做测试也没什么大不了的。

更何况程序员转行做测试比其他人多多少少会有一些优势。

既然有想转行测试总归是有自己的理由,但不管什么原因,这都是自己的选择。

在这篇文章里我不去建议程序员到底应不应该转测试,我只把我了解的测试行业、测试人员的现状说出来,让想转行的程序们对测试有个大概的了解,也希望能让这些迷茫的程序员们能好好考虑一下转行的优劣。

最好的不一定适合自己,但适合自己的一定是最好的。

程序员到底要不要转行软件测试?

软件测试的定义是:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。

这也是我们熟知的测试人员“找bug”的工作职责。其实想真正了解软件测试还是要去看它的发展历程,在软件测试的早期,通常是开发人员把测试等同于“调试”。

后面软件和IT行业迅猛发展,软件测试也越来越受重视,软件测试工程师也就应运而生。这里大家可以去看《软件测试》—佩腾《软件测试的艺术》—梅耶,这两本是非常好的入门书籍。网上也有pdf版本的电子书。

上面是关于软件测试的基础理论知识,花点时间都是可以掌握的。

在市场和公司对软件质量重要性的认识逐渐加强的今天,尽管软件测试在软件项目实施过程中的重要性日益突出,但是还是有很多人对软件测试的认识存在误区。

误区之一:软件开发完成后进行软件测试

软件测试贯穿于软件项目的整个生命过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动,以保证各个阶段的正确性。

误区之二:软件发布后如果发现质量问题,那是软件测试人员的错

软件中的错误可能来自软件项目中的各个过程,软件测试只能确认软件存在错误,不能保证软件没有错误,因为从根本上讲,软件测试不可能发现全部的错误。

误区之三:软件测试要求不高,随便找个人做都行

软件测试包括测试技术和管理两个方面,完全掌握这两个方面的内容,需要很多测试实践经验和不断学习的精神。

误区之四:软件测试是测试人员的事情,与程序员无关

开发和测试是相辅相成的过程,需要软件测试人员、程序员和系统分析师等保持密切的联系,需要更多的交流和协调,以便提高测试效率。

误区之五:项目进度吃紧时少做些测试,时间富裕时多做测试

这是不重视软件测试的表现,也是软件项目过程管理混乱的表现,必然会降低软件测试的质量。

误区之六:软件测试是没有前途的工作,只有程序员才是软件高手

软件测试将会成为一个具有很大发展前景的行业,软件测试大有前途,市场需要更多具有丰富测试技术和管理经验的测试人员,他们同样是软件专家。

软件测试行业的薪资水平?

目前来说,功能测试的测试岗位已经饱和了,也是软件测试行业薪资最低的岗位

程序员到底要不要转行软件测试?

自动化测试是现在比较火的测试岗位,薪资非常可观

程序员到底要不要转行软件测试?

不管是后面的接口测试、自动化测试还是性能测试,都需要非常扎实的功能测试基础知识,而且学习都是逐渐深入的,没人能一口吃成一个大胖子。

软件测试行业是否比程序员更轻松?

从某种程度上来说,测试工作可能会比开发工作轻松,但我觉得这是一个人到底适合做开发还是测试的问题。如果都不适合,那肯定做什么都累。

其次你真的理解测试是贯穿于整个软件项目的生命流程的话,也许就没有这种想法了。从测试从业人数的性别比例来看的话,测试比起开发确实是适合女孩子一些。

软件测试行业找工作比程序员找工作简单?

在IT行业找工作难易程度永远是和你自己本身的技术知识联系在一起的。其次再是简历的编写能力,一份好的简历往往能帮你吸引到面试官的目光,从而增加面试的机会。

测试要学的知识比开发要少,比开发更简单?

可以参考我写的这篇文章https://www.toutiao.com/i6536440885725364750/

当然也可以把文章中提到的技术作为一个长期目标慢慢把自己缺少的部分填上。

不管是测试还是开发都不是很轻松就能做好的工作。

进入软件测试行业是否要参加系统的软件测试培训?

存在即合理,培训机构是有其价值的。有些人对培训嗤之以鼻可能是真被坑过也可能只是盲目跟风。至于能不能学到东西还是看自己个人。

如果培训费用扛得住,不需要通过贷款的方式学习,可以考虑。

结语

以上是我个人的一些经验,希望能帮助到大家。

如果还有什么其他的问题,欢迎加我的软件测试交流群680748947,我会一一为大家解答。

2005-04-14 15:11:00 emag_testage 阅读数 2292
  • 软件测试入门视频教程

    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试、回归测试、验收测试等。本课程以接地气的语言来讲解,让你听的懂,学的会!本课程以全新的方式为你呈现教学内容,清新脱俗独具特色的授课方式将带给你新的体验。

    2158118 人正在学习 去看看 李晓鹏

软件测试要不要追究Bug发生的原因

作者:kpxl
                                                                   
     软件测试到底要不要追究BUG发生的原因呢?这个问题的争议很多,有人认为寻找BUG的原因是开发的事情,软件测试只要能发现BUG就够了;还有人认为软件测试可以尽自己所能尽可能的去寻找BUG的原因。到底哪个观点正确?我个人认为这个问题是仁者见仁,智者见智,站在一个产品不同的层面看,会有不同的看法。这里所谈到的观点,也仅代表个人看法。
    要搞清楚这个问题,先要明确几个定义,首先要明确什么是QA?简单从字面上理解是Quality Assure(质量保证),CMM对QA的要求主要有下面几点:保障制度体系;促使过程改进;指导项目实施;增加透明度;评审项目活动;审核工作产品;协助问题解决;提供决策参考;进行缺陷预防;实现质量目标。其次什么是软件测试,软件测试是根据软件开发各个阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期结果),并利用这些测试用例去执行程序,以发现程序错误的过程。而软件测试人员就是这一过程的执行者。
    从上面的定义可以看到,QA重点关注的不仅仅是质量,而是整个软件过程,保证的首先是过程和体系,也就是说只有规范了过程和体系,才有可能做出好的产品。而软件测试就是通过自己的活动,来给QA人员提供尽可能的有效的信息和数据,使他们能够发现过程上的异常或者制度上的不妥之处。可见软件测试的任务不仅仅是测试,还要把项目的异常情况向QA报告,所以只能报出BUG是不够的。
    其实QA和软件测试的目的都是一样的,就是尽可能的使发布出去的产品更加符合用户的需要,尽可能的没有bug。不同之处只是一个关注的是整个软件过程,一个只是关注最终的质量。所以为了搞清楚软件测试要不要追究BUG发生的原因,先要明确的是弄清楚BUG发生的原因对整个软件过程有什么好处,或者说对最终的质量有什么好处?
    对于开发来说,一般是能够重现这个BUG就够了,这样对于那些发生几率在100%的bug来说,软件测试人员只要详细清晰的描述出bug发生的步骤,写明bug的发生条件,执行这些操作的用户的角色以及权限,使用的操作系统和浏览器,然后写清楚实际结果和期望结果,基本上就差不多了,开发根据这些描述能够知道是如何出现的问题,并且知道应该改成什么样。到时候软件测试人员(可能不是原来报BUG的那个人了)进行回归测试时根据BUG的描述,也可以很清楚的知道这个BUG是否真的改好了。但是如果一个BUG的发生几率不是100%,或者说在某些特定的条件下的发生几率是100%,但是一般情况下都不存在。测试人员可能只是偶然发现这个问题,却会认为是100%出现,报BUG时也就没有指明这个问题出现的条件,开发看到这种BUG,根本无法重现,再打给测试人员,如此反复几次,虽然最终问题得以解决,但是对于整个项目来说,却是浪费了很多的时间。如果在发现问题时。能够多试几下,或者换个环境试试,可能就会找到发生几率不是100%的原因,比如非法数据,特殊字符,特殊用户权限,特殊日期,或者在系统中还有其他自己不知道的参数的影响,或者是操作系统的问题,又或者是浏览器的设置问题,还有可能是浏览器的版本问题等等,寻找这些原因的过程,是一个自我提高的过程,也是积累自己测试经验的过程,同时也是证明测试角色重要的过程,是证明测试人员价值的过程。
    当然目前国内的软件公司中测试人员的水平还不是很高,想看懂开发的代码并且进行测试难度还比较大,所以我也不主张去看着开发的代码进行测试,只需要在测试的时候,多考虑一下,尤其是出现问题的时候,多想想这个问题为什么会发生,会影响到系统中其他什么地方,还会有其他哪些地方有可能存在这样的问题,这样等到开发修改好之后,提交测试进行回归检测时也可以做到有的放矢,尤其是在回归测试时间很短的情况下,如何进行有效的回归测试,并且保证不漏掉重大隐患,我想和开发水平固然有关,但是关系最大的还是测试人员对系统的熟悉程度,以及是否具有软件开发的思想。
    追究bug的原因,不是一朝一夕的事,需要长期的摸索和总结,开始会很烦,可能还会很郁闷,但是慢慢的你会发现其中的乐趣,想一想当你报给开发一个Bug的时候,随着bug的报告还有一个详尽的发生这个bug的条件数据,以及测试平台等数据,开发根据这些很容易重现这个问题,会对测试人员的专业度有很大的认可,那时我想自己心里的成就感不是几句话可以说完的了!
2005-01-04 12:44:00 kpxl 阅读数 868
  • 软件测试入门视频教程

    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试、回归测试、验收测试等。本课程以接地气的语言来讲解,让你听的懂,学的会!本课程以全新的方式为你呈现教学内容,清新脱俗独具特色的授课方式将带给你新的体验。

    2158118 人正在学习 去看看 李晓鹏

软件测试到底要不要追究BUG发生的原因呢?这个问题的争议很多,有人认为寻找BUG的原因是开发的事情,软件测试只要能发现BUG就够了;还有人认为软件测试可以尽自己所能尽可能的去寻找BUG的原因。到底哪个观点正确?我个人认为这个问题是仁者见仁,智者见智,站在一个产品不同的层面看,会有不同的看法。这里所谈到的观点,也仅代表个人看法。

要搞清楚这个问题,先要明确几个定义,首先要明确什么是QA?简单从字面上理解是Quality Assure(质量保证),CMM对QA的要求主要有下面几点:保障制度体系;促使过程改进;指导项目实施;增加透明度;评审项目活动;审核工作产品;协助问题解决;提供决策参考;进行缺陷预防;实现质量目标。其次什么是软件测试,软件测试是根据软件开发各个阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期结果),并利用这些测试用例去执行程序,以发现程序错误的过程。


而软件测试人员就是这一过程的执行者。


从上面的定义可以看到,QA重点关注的不仅仅是质量,而是整个软件过程,保证的首先是过程和体系,也就是说只有规范了过程和体系,才有可能做出好的产品。而软件测试就是通过自己的活动,来给QA人员提供尽可能的有效的信息和数据,使他们能够发现过程上的异常或者制度上的不妥之处。可见软件测试的任务不仅仅是测试,还要把项目的异常情况向QA报告,所以只能报出BUG是不够的。


其实QA和软件测试的目的都是一样的,就是尽可能的使发布出去的产品更加符合用户的需要,尽可能的没有bug。不同之处只是一个关注的是整个软件过程,一个只是关注最终的质量。所以为了搞清楚软件测试要不要追究BUG发生的原因,先要明确的是弄清楚BUG发生的原因对整个软件过程有什么好处,或者说对最终的质量有什么好处?


对于开发来说,一般是能够重现这个BUG就够了,这样对于那些发生几率在100%的bug来说,软件测试人员只要详细清晰的描述出bug发生的步骤,写明bug的发生条件,执行这些操作的用户的角色以及权限,使用的操作系统和浏览器,然后写清楚实际结果和期望结果,基本上就差不多了,开发根据这些描述能够知道是如何出现的问题,并且知道应该改成什么样。到时候软件测试人员(可能不是原来报BUG的那个人了)进行回归测试时根据BUG的描述,也可以很清楚的知道这个BUG是否真的改好了。但是如果一个BUG的发生几率不是100%,或者说在某些特定的条件下的发生几率是100%,但是一般情况下都不存在。测试人员可能只是偶然发现这个问题,却会认为是100%出现,报BUG时也就没有指明这个问题出现的条件,开发看到这种BUG,根本无法重现,再打给测试人员,如此反复几次,虽然最终问题得以解决,但是对于整个项目来说,却是浪费了很多的时间。如果在发现问题时。能够多试几下,或者换个环境试试,可能就会找到发生几率不是100%的原因,比如非法数据,特殊字符,特殊用户权限,特殊日期,或者在系统中还有其他自己不知道的参数的影响,或者是操作系统的问题,又或者是浏览器的设置问题,还有可能是浏览器的版本问题等等,寻找这些原因的过程,是一个自我提高的过程,也是积累自己测试经验的过程,同时也是证明测试角色重要的过程,是证明测试人员价值的过程。


当然目前国内的软件公司中测试人员的水平还不是很高,想看懂开发的代码并且进行测试难度还比较大,所以我也不主张去看着开发的代码进行测试,只需要在测试的时候,多考虑一下,尤其是出现问题的时候,多想想这个问题为什么会发生,会影响到系统中其他什么地方,还会有其他哪些地方有可能存在这样的问题,这样等到开发修改好之后,提交测试进行回归检测时也可以做到有的放矢,尤其是在回归测试时间很短的情况下,如何进行有效的回归测试,并且保证不漏掉重大隐患,我想和开发水平固然有关,但是关系最大的还是测试人员对系统的熟悉程度,以及是否具有软件开发的思想。

追究bug的原因,不是一朝一夕的事,需要长期的摸索和总结,开始会很烦,可能还会很郁闷,但是慢慢的你会发现其中的乐趣,想一想当你报给开发一个Bug的时候,随着bug的报告还有一个详尽的发生这个bug的条件数据,以及测试平台等数据,开发根据这些很容易重现这个问题,会对测试人员的专业度有很大的认可,那时我想自己心里的成就感不是几句话可以说完的了!

没有更多推荐了,返回首页