铁岭专业软件测试培训机构,达内软件测试
软件测试培训达内荣誉：2004年5月，荣获《中国计算机报》年度评选“最具影响力培训机构奖”.


软件测试工程师每天都做什么？

软件测试工程师每天都做什么？软件测试并不陌生，因为软件测试学习门槛低，所以很多小伙伴选择学习软件测试开发，但是参加完软件测试培训之后我们做什么工作呢？每天的工作内容是什么呢？
一、初始软件测试
“这是一个杯子，主要用来喝水的，它的质量应该如何考量？”
这是在进入上家公司面试时，测试主管问我的题目，相关的回答已经有点模糊，但从这个问题可以大概了解到，测试主管在考察我的测试思维。
首先，这个杯子的质量包含哪些方面？即通常所说的需求是什么？如显性需求，首先应该是杯子，不是瓶子、罐子等，用途是喝水的;隐性需求呢？那就比较笼统了，如大小、高度、容积、制作材料、温度承受范围，还有一些其他细节如颜色、边角圆滑等。
其次，如何去准确获取、表现这些需求，即相关指标数据是多少。如要知道大小、高度、容积，得用到相关测量工具，如尺子、圆规。要知道温度承受范围，可能要用到温度计等。
在完成测试工作期间，测试设计、执行之前必须清晰了解原始需求(包括隐性需求)，再之后需要有对应的测试方案，需要执行哪些类型测试，要用到什么测试工具等。
很感谢当初测试主管对我测试工作的指导，不仅仅是在具体的技能培训上，还在其他的工作当中对我测试思维的引导。
二、功能测试实践
面试过后进入公司，最开始接触的项目是国税门户网站，所进行的测试工作是主要是功能测试，如测试用例编写、执行，测试报告反馈。当时对所谓的软件生命周期都很模糊，感觉我只要做好自己的测试任务就好了，其他的东西由上级安排就好。现在想想真的好白，白痴的白。
在接下来的一年时间，让我真正接触到了项目开发、交付的实际生产过程，简而言之就是，工作任务是无止境的，永远有数不尽的需求要开发、测试，有茫茫多的Bug要跟踪。如何在这中间保持自己清晰的定位显得至关重要。由于在项目组中只有我一个测试人员，那么结果就是，“测试的事情就都是我的”，好像很厉害的样子。但我还只是小白啊。
“某某某，过来一下，这是这个版本修改的内容，大概是要在某月某日完成，你过(看)一下。”
“哦”。
到了测试执行，发现问题后提交给开发同事，开发回复：“设计如此。”
“哦”。
快要上线了，项目经理问：“某某某，现在系统的测试情况怎么样，能不能上线？”
“应该差不多吧”......
三、项目实践后续
测试主管了解之后，跟我强调了几点：
1、测试的依据，需求基线要清楚，要尽早参与;
2、测试要有计划方案，要有用例设计，不能随意的开展;
3、Bug的跟踪，要有自己的主见、原则;
4、测试结果的把握，要有结果分析。
项目的上线，要综合你的以上测试过程，结合目前的情况总结报告，甚至是项目经理也要听取你的意见。你的角色不仅是测试，也是质量保证。
当然，以上的情况只是测试中遇到问题的一点点，如沙漠中的一粒沙(这孩子究竟怎么过来的)，但也让我认识到测试是独立的、重要的。
在后来的项目测试工作中，践行测试主管传递的思想原则的同时，我并行了解相关测试书籍、工具、技能，结合工作进行相关实践，逐渐地我的测试能力越来越强。
在省国税外派了一年，之后测试过程中更加有条理、原则、规范。但也仅是个人自觉的约束，很多过程并没有按照软件开发周期的标准来执行，如测试用例、测试报告有时候会在发布版本后才编写(虽然公司也通过了CMMI3)，即测试的质量保证更多的依赖个人的素质。
并且，当时个人认为测试的业务熟练更多决定于对系统功能本身的熟悉和测试设计执行的熟悉，认识到错误并且有意识改变是在地税的定点联系企业管理系统和电子办税服务厅的测试过程。
之后，进入到地税的定点联系企业管理系统项目组进行测试。当时项目已快要进入验收阶段，甲方要求的功能基本都有实现，但在交付时甲方却不满意，在一些功能的易用性和系统界面展示上提了很多要求，导致整个系统最后框架、原型都换了一遍，而且限定修改的时间很短(又是一个加班加点的开始)，最后甚至项目负责人都换了。
四、总结工作中的问题
1、既定清晰的需求都有按要求实现，只不过实现方式不合甲方胃口，如图表不够丰富，只有概要，没有详细。
2、系统界面没有统一的样式，甲方不客气的说像草稿。
3、流程没有体现甲方日常工作内容、步骤。
4、风控系统很肤浅，指标不实用。
走过堤岸，有依依杨柳，迈入田野，是无边麦浪。人总会经历不同的旅途风景，在变化之间获得不同的成长见识。
第一份工作经历形成了我对测试的基本认识及工作方式，接到测试任务之后就会条件反射的设想需要开展的测试类型，相关方案。但对于这些工作是否可以更标准化、工程化的开展还只是一个朦胧的概念。
之后重新更换测试工作，工作开始并没有什么不同，只是测试执行之前要求必须编写测试用例。但随着时间的推移，让我体验到了不一样的氛围。
测试要尽早开始，并且排除随意性，有计划的进行，这是软件测试基础理论的原则之一。在公瑾，软件开发过程有比较完善的流程，期间测试人员要经过需求评审、测试用例评审、预测试评审(提交测试前的评审，由开发演示实现的功能)、测试报告评审等。在需求评审之后，要有详细的测试分析、用例，并且列入任务计划进行监控，用例的执行结果也可随时查看，了解测试进度。
落地手工功能测试的同时，我们在持续进行自动化功能测试和性能测试工作。
五、测试观点分享
很容易发现，以前是一个人在摸索中战斗，不断的爬坑的测试过程，现在是工程化、自动化的在持续推进优化改进的过程。个人对体系趋势，优劣不言而喻。
以下是个人测试经验中的一些观点：
1、尽量把测试往前推，尽早发现，降低修复成本;
2、测试的目的不是发现Bug，而是预防Bug的发生;
3、通过各种技术手段和流程改进，逐步的解放公司内部测试人员，让他们把精力放在对产品的把握上。
当然，不管有多好的工作起点平台，测试人员的素质才是决定最终测试质量的保证。在从原有重复的工作方式中解放后，测试人员的综合素质如所处行业知识、测试思维、测试设计方案都影响到具体的测试结果，这些都是工具、平台无法取代的。达内软件测试培训学校励志语录：不要配不上自己的野心，也不要辜负了曾经所受的苦难！.
铁岭专业软件测试培训机构,达内软件测试


自动化测试工程师/手机测试工程师。.
什么样的测试用例算好的测试用例?如何设计一个好的测试用例?

今天达内软件测试培训想要给大家解决的问题很简单：什么样的测试用例算好的测试用例?如何设计一个好的测试用例?如果你也不了解，那就跟我一起来学习吧：
什么样的测试用例算好的测试用例,如何设计一个好的测试用例
什么样的测试用例算好的测试用例呢?
1、不要以为“发现了软件缺陷的测试用例就是好的用例”
2、也不要以为“发现软件缺陷可能性大的测试用例就是好用例”
3、更不要以为“发现至今未被发现的软件缺陷的测试用例就是好用例”
其实，是你定义“好的”测试用例的思路错了，这就有点像“傻子吃烧饼”，连吃五个不饱，吃完第六个终于饱了，于是他说：早知道吃了第六个就会饱，何必吃前面五个呢。细想，他吃的六个烧饼其实是一个整体，一起吃下去才会饱，而你无法找到吃一个就能饱的“好”烧饼。
对于测试用例其实也是同样的道理，“好的”测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而跟能否发现缺陷无关。
如果把被测试软件看作一个池塘，软件缺陷是池塘中的鱼，建立测试用例集的过程就像是在编织一张捕渔网。“好的”测试用例集就是一张能够覆盖整个池塘的大渔网，只要池塘里有鱼，这个大渔网就一定能把鱼给捞上来。
如果渔网本身是完整的且合格的，那么捞不到鱼，就证明池塘中没有鱼，而渔网的好坏与池塘中是否有鱼无关。
“好的”测试用例必须具备哪些特征?如何设计一个好的测试用例?
1. 整体完备性：“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
2. 等价类划分的准确性：指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
3. 等价类集合的完备性：需要保证所有可能的边界值和边界条件都已经正确识别。
做到了以上三点，就可以肯定测试是充分且完备的，即做到了完整的测试需求覆盖。
从理论层面来讲，设计用例的方法有很多，如果你去翻阅测试图书或网络教程，会发现一堆让人眼花缭乱的测试方法，比如等价类划分法、边界值分析法、错误推测方法、因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方法、形式化方法、扩展有限状态机方法等等，但是从软件企业实际的工程实践来讲，真正具有实用价值并且常用的只有前三种方法。
等价类划分方法
现在，我给你看一个具体的例子：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是0~100之间的整数，考试成绩及格的分数线是60。
为了测试这个输入项，显然不可能用0~100的每一个数去测试。通过需求描述可以知道，输入0~59之间的任意整数，以及输入60~100之间的任意整数，去验证和揭露输入框的潜在缺陷可以看做是等价的。
那么这就可以在0~59和60~100之间各随机抽取一个整数来进行验证。这样的设计就构成了所谓的“有效等价类”。
你不要觉得进行到这里，已经完成了等价类划分的工作，因为等价类划分方法的另一个关键点是要找出所有“无效等价类”。显然，如果输入的成绩是负数，或者是大于100的数等都构成了“无效等价类”。
在考虑了无效等价类后，最终设计的测试用例为：
• 有效等价类1：0~59之间的任意整数;
• 有效等价类2：59~100之间的任意整数;
• 无效等价类1：小于0的负数;
• 无效等价类2：大于100的整数;
• 无效等价类3：0~100之间的任何浮点数;
• 无效等价类4：其他任意非数字字符。
边界值分析方法
边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包括：-1，0，1，59，60，61，99，100，101。
错误推测方法
错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。
错误推测法和目前非常流行的“探索式测试方法”的基本思想和理念是不谋而合的，这类方法在目前的敏捷开发模式下的投入产出比很高，因此被广泛应用。但是，这个方法的缺点也显而易见，那就是难以系统化，并且过度依赖个人能力。
比如，Web界面的GUI功能测试，需要考虑浏览器在有缓存和没有缓存下的表现;Web Service的API测试，需要考虑被测API所依赖的第三方API出错下的处理逻辑;对于代码级的单元测试，需要考虑被测函数的输入参数为空情况下的内部处理逻辑等等。由此可见，这些测试用例的设计都是基于曾经遇到的问题而进行的错误推测，很大程度上取决于个人能力。
在软件企业的具体实践中，为了降低对个人能力的依赖，通常会建立常见缺陷知识库，在测试设计的过程中，会使用缺陷知识库作为检查点列表(checklist)，去帮助优化补充测试用例的设计。
对于中小企业，可能最初的方法就是建立一个简单的wiki页面，让测试工程师完成测试用例的最初设计后对应这个wiki页面先做一轮自检，如果在后续测试中发现了新的点，就会继续完善这个wiki页面。
对于测试基础架构比较成熟的中大型软件企业，通常会以该缺陷知识库作为数据驱动测试的输入来自动生成部分的测试数据。
感谢您的阅读，以上是达内软件测试培训今天教给大家的：辨别什么样的测试用例算好的测试用例，了解好的测试用例的特征，学会如何设计一个好的测试用例，不知道你学会了吗?更多软件测试相关的内容尽在达内软件测试培训机构，敬请关注!达内软件测试培训学校励志语录：哪有那么多的一夜成名，其实都是百炼成钢。。


铁岭专业软件测试培训机构,达内软件测试
软件测试培训机构达内经典语录：强烈的信仰会赢取坚强的人，然后又使他们更坚强。。如何确定自己适合软件测试还是开发

突然发现好像挺多人想投测开和测试的，很多人面试的时候也会被问到这几个职位的区别，然后有测试经历或者说有系统学习过测试的人蛮少的，楼主去年投这个岗位的时候也很迷茫，中间在牛客网请教过好几位大佬and前辈，这里做一个小小的总结，主要内容来自于和大佬们的谈话以及《How Google Test Software》这本书也希望和我当时一样迷茫的朋友们能有所收获。
首先明确一下简称吧，毕竟这几个名字太像了，中文容易搞混。软件开发工程师(SWE),测试开发工程师(SWT),测试工程师(TE)。
一、区别
1、SWE也需要做测试的工作，SWE需要编写测试驱动的设计、单元测试、参与构建各种大小规模的测试等(简单说开发其实需要对自己的代码负责，并不是很多人理解的代码写出来扔给SWT和TE去测)
2、SWT也是一个开发者角色，只是工作重心在可测试性和通用测试基础框架上。(SWT也要会写代码，代码要求并不比开发低，他们写代码的聚焦点是测试，PS：以字节为例，大部分的测开是技术序列，代码要求和开发一致，薪资也一致(当时宣讲会听的))。
3、SWE和SWT不是敌人(不是一个生产BUG，一个挑刺的)，更多是合作伙伴，SET写代码的目的是可以让SWE测试自己的功能。
4、TE把用户放在第一位来思考，组织整体质量的实践，分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试。(SWT和TE工作有很多交织，SWT更多是要构建测试框架，编写测试工具。TE更多是脚本，测试用例，以及点点点........，以字节为例，TE对代码的要求会相对较低，但是也需要写代码(宣讲会听的))。
5、国内很多大厂的测开其实做的是测试的活，也要很多测开干的就是开发的活，这些都取决于你的组，不是一概而论的。
6、SWT和TE对于知识广度的要求会更高，SWE你也许只需要在一个角度仔细钻研就可以了，SWT和TE则需要你是“万能博士”，正如推荐的那本书的作者所说，招一个好的SWT和TE往往比SWE还难。
7、SWT的天花板也许相对SWE会低(毕竟国内的事实是SWT和TE做主程的很少)，但是SWT越来越受重视是不争的事实，同时SWT的平均待遇不低。
二、特征
最后选择SWT还是TE引用推荐的那本书里的几个标准(节选)(这也是交流的几个大佬也反复的提到是否真的喜欢测试类的工作)。
1、你可能是一个SET，如果你有以下的特征：
a.你编程时，会内疚的想到还有很多单元测试用例没有完成。随后，你又会考虑各种生成测试代码和验证的方法，而不是手工 编写每个单元测试用例。
b.看到编译器警告时会焦虑不安。
c.当被要求测试一个产品时，你会打开源码，开始思考需要模拟的东西。
d.你心目中领导力是：建立一个伟大的底层单元测试框架，供所有人来使用，或者在测试服务器上每天数百万次的运行。
e.当被问到产品是否可以上线时，你可能会说：所有的测试都通过了。
2、你可能是一个TE，如果你有以下的特征：
a.你能在已有的代码段中快速找到错误，迅速理解软件失效的模式，但是并不关心从头编写代码或者做修改。
b.你更愿意到一些开源网站上去阅读别人的源码。
c.在现实世界里你很愿意和其他人交流。
d.你心中的领导力是：扶助其他工程师的创意，用更高数量级规模的应用场景来挑战他们的创意。
e.当被问到产品是否可以上线时，你可能会说：我觉得可以了。
三、总结
综上(大概率是这样的，大家别钻牛角尖，没有优劣之说)：
代码能力要求：SWE=SWT>TE
知识广度要求：SWT,TE>SWE
沟通能力要求：TE>SWT>SWE
知识深度要求：SWE>SWT>TE
薪资待遇：SWE=SWT>TE(纯粹意义的开发，测开和测试，当然国内很多公司自己都搞不清这几个Title区别)。软件测试培训达内荣誉：2014年4月，达内科技成功登陆美国上市。
铁岭专业软件测试培训机构,达内软件测试


软件测试培训网格言：生命苦短，只是美德能将它传到遥远的后世。——莎士比亚.