精华内容
下载资源
问答
  • 测试开发需要学习的知识结构

    万次阅读 多人点赞 2018-04-12 10:40:58
    努力成为一个优秀的测试开发从业者,加油!!! 一些视频链接:我这有一些软件测试的视频,你可以点开看看。转行互联网测试需要哪些技能? - 假装在测试的回答 - 知乎作为一名软件测试人员,有哪些网站是你应该多多...

     努力成为一个优秀的测试开发从业者,加油!!!   

    目录

    一、白盒与黑盒测试什么区分

    1、黑盒测试

    2、白盒测试

    3、白盒测试&黑盒测试对比

    4、白盒测试&黑盒测试详细介绍

    黑盒测试

    白盒测试

    二、测试相关经验

    三、测试能力培养

    一、业务分析能力

    二、缺陷洞察能力

    三、团队协作能力

    四、专业技术能力

    五、逻辑思考能力

    六、问题解决能力

    七、沟通表达能力

    八、宏观把控能力


    借楼发个招聘信息:
    【2021 MEGQA-用户质量效能部校园提前批开始啦】
    工作职责:
    -负责百度核心产品的测试工作,如信息流、搜索、百度APP、小程序、好看视频、贴吧等
    -参与产品需求、系统设计和程序代码的评审工作并提出改进意见
    -评估项目质量风险并制定项目测试方案,设计并执行测试用例,跟踪定位产品软件中的缺陷或问题,保证项目质量和进度
    -根据产品和项目特点,提出合理的自动化解决方案,并负责产品线特色化的测试框架和测试工具,运用技术手段提升代码交付的质量和效率
    -参与互联网产品整个工程生产、发布过程中的技术创新,包括研发敏捷研发工具、线上监控系统、性能测试和监督工具等精确评估线上系统表现,以创新的工作模式提升产品的用户价值
    职位要求:
    -计算机相关专业,本科及以上学历
    -能熟练地应用以下一门或几门技术进行相关开发:C/C++/Java/object-c、Linux/Unix Shell、Perl/Python/PHP、JavaScript/Html/Ajax、MySql/Oracle及相关数据库技术等
    -具备快速的产品及业务学习能力,敏捷全面的逻辑思维能力
    -有责任心、敢于担当,工作积极主动,具备良好的团队合作精神,能融入多功能团队并与其他部门同事进行良好的沟通及合作
    -热爱互联网,对互联网相关业务或技术充满好奇及热情;在软件测试领域,对发现、分析及解决问题的工作有浓厚兴趣

    感兴趣的同学可以将简历投递至liujunping@baidu.com

     

    ========================================================================================

    一些视频链接:我这有一些软件测试的视频,你可以点开看看。

    转行互联网测试需要哪些技能? - 假装在测试的回答 - 知乎

    作为一名软件测试人员,有哪些网站是你应该多多关注的,哪些书籍是你必须要看的? - 假装在测试的回答 - 知乎

    一、白盒与黑盒测试什么区分

    1、黑盒测试

    黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和内部特性的情况下,测试者在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数锯而产生正确的输出信息,并且保持外部信息(如数据库或文件)的完整性。黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等,主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,人们不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。

    2、白盒测试

    白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能,白盒测试的主要方法有逻辑驱动、基路测试等,主要用于软件验证。

    “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时,测试者必须检查程序的内部结构,从检查程序的逻辑着手,得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一,穷举路径测试决不能查出程序违反了设计规范,即程序本身是个错误的程序。第二,穷举路径测试不可能查出程序中因遗漏路径而出错。第三,穷举路径测试可能发现不了一些与数据相关的错误。

    软件人员使用白盒测试方法,主要想对程序模块进行如下的检查:
    – 对程序模块的所有独立的执行路径至少测试一次;
    – 对所有的逻辑判定,取 “ 真 ” 与取 “ 假 ” 的两种情况都至少测试一次;
    – 在循环的边界和运行界限内执行循环体;
    – 测试内部数据结构的有效性,等。
    具体包含的逻辑覆盖有: – 语句覆盖 – 判定覆盖 – 条件覆盖 – 判定-条件覆盖 – 条件组合覆盖 – 路径覆盖。

    3、白盒测试&黑盒测试对比

    白盒测试技术 (White Box Testing) : 深入到代码一级的测试,使用这种技术发现问题最早,效果也是最好的。该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段,开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主,在 JAVA 平台使用 Xunit 系列工具进行测试, Xunit 测试工具是类一级的测试工具对每一个类和该类的方法进行测试。

    黑盒测试技术( Black Box Testing ):黑盒测试的内容主要有以下几个方面,但是主要还是功能部分。主要是覆盖全部的功能,可以结合兼容,性能测试等方面进行,根据软件需求,设计文档,模拟客户场景随系统进行实际的测试,这种测试技术是使用最多的测试技术涵盖了测试的方方面面,可以考虑以下方面:

    1正确性 (Correctness) :计算结果,命名等方面

    2可用性 (Usability) :是否可以满足软件的需求说明。

    3边界条件 (Boundary Condition) :输入部分的边界值,就是使用一般书中说的等价类划分,试试最大最小和非法数据等等。

    4性能 (Performance) : 正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间在可以接受范围内。 J2EE 技术实现的系统在性能方面更是需要照顾的,一般原则是 3 秒以下接受, 3-5 秒可以接受, 5 秒以上就影响易用性了。如果在测试过程中发现性能问题,修复起来是非常艰难的,因为这常常意味着程序的算法不好,结构不好,或者设计有问题。因此在产品开发的开始阶段,就要考虑到软件的性能问题

    5压力测试 (Stress) : 多用户情况可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具 , 查看服务器 CPU 使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息。如果有必要的话必须进行性能优化 ( 软硬件都可以 ) 。这里的压力测试针对的是某几项功能。

    6错误恢复 (Error Recovery) :错误处理,页面数据验证,包括突然间断电,输入脏数据等。

    7安全性测试 (Security) :这个领域正在研究中,防火墙、补丁包、杀毒软件等的就不必说了,不过可以考虑。破坏性测试时任意看了一些资料后得知 , 这里面设计到的知识 内容可以写本书了 , 不是一两句可以说清的,特别是一些商务网站,或者跟钱有关,或者和公司秘密有关的 web 更是需要这方面的测试,在外国有一种专门干这一行的人叫安全顾问,可以审核代码,提出安全建议,出现紧急事件时的处理办法等,在国内没有听说哪里有专门搞安全技术测试的内容。

    4、白盒测试&黑盒测试详细介绍

    黑盒测试

      · 等价类划分方法
      · 边界值分析
      · 错误推测
      · 因果图方法
      · 判定表驱动分析方法
      · 正交实验设计方法:取正交的测试用例组合
      · 功能图分析方法
    1)等价类划分:
      把所有可能的输入数据,即程序的输入域划分成若干部分,然后从每一个子集中选取少数具有代表性的数据作为测试用例,该方法是一种重要的,常用的黑盒测试 用例设计方法。等价类划分可有两种不同的情况:有效等价类和无效等价类。
      有效等价类:对于程序的规格说明来说是合理的,有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
      无效等价类:与有效等价类的定义相反。
    2)边界值分析法:
      边界值分析方法是对等价类划分方法的补充。长期的测试 工作经验告诉我们,大量的错误是发生在输入或者输出范围的边界上,而不是发生在输入输出范围的内部,因此针对各种边界情况设计测试用例,可以查出更多的错误。
      使用边界值分析方法设计测试用例,首先应确定边界情况,通常输入和输出等价类的边界,就是应着重测试的边界情况,应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取边界类中的典型值或任意值作为测试数据。
    3)错误推测法:
      基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。
      列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。例如,在 单元测试时列出的许多在模块中常见的错误,以前产品测试中经常发现的错误等,这些就是经验的总结。还有,输入数据和输出数据为零的情况;输入表格为空格或者输入表格只有一行,这些都是容易发生错误的情况,可选这些情况下的例子作为测试用例。
    4)因果图方法:
      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系。考虑输入条件之间的相互组合,可能会产生一些新的情况,但要检查输入条件的组合意识一件容易的事情,因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例,这就需要利用因果图。
    因果图方法最终生成的是判定表,它适合于检查程序输入条件之间的各种组合情况。
    利用因果图生成测试用例的基本步骤:
      (1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.
      (2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.
      (3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.
      (4) 把因果图转换为判定表.
      (5) 把判定表的每一列拿出来作为依据,设计测试用例.
      从因果图生成的测试用例(局部,组合关系下的)包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.
      前面因果图方法中已经用到了判定表.判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.
    5)判定表通常由四个部分组成.
      条件桩(Condition Stub):列出了问题得所有条件.通常认为列出得条件的次序无关紧要.
      动作桩(Action Stub):列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.
      条件项(Condition Entry):列出针对它左列条件的取值.在所有可能情况下的真假值.
      动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作.
      规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.
       判定表的建立步骤:(根据软件规格说明)
      ①确定规则的个数.假如有n个条件.每个条件有两个取值(0,1),故有 种规则.
      ②列出所有的条件桩和动作桩.
      ③填入条件项.
      ④填入动作项.等到初始判定表.
      ⑤简化.合并相似规则(相同动作)
      B. Beizer 指出了适合使用判定表设计测试用例的条件:
      ①规格说明以判定表形式给出,或很容易转换成判定表.
      ②条件的排列顺序不会也不影响执行哪些操作.
      ③规则的排列顺序不会也不影响执行哪些操作.
      ④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.
      ⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

    白盒测试

    白盒测试的方法:总体上分为静态方法和动态方法两大类。

    静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。

    动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 , 对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。

    本文介绍六种白盒子测试方法:(强度由低到高)语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

    1)所谓语句覆盖:就是设计若干个测试用例,运行被测程序,使得每一可执行语句至少执行一次。这里的“若干个”,意味着使用测试用例越少越好。语句覆盖率的公式可以表示如下:

    语句覆盖率=被评价到的语句数量/可执行的语句总数 x 100%

    2判定覆盖:使设计的测试用例保证程序中每个判断的每个取值分支(t or f)至少经历一次

    [优点]:判定覆盖具有比语句覆盖更强的测试能力,而且具有和语句覆盖一样的简单性,无需细分每个判定就可以得到测试用例。

    [缺点]:往往大部分的判定语句是由多个逻辑条件组合而成(如,判定语句中包含AND、OR、CASE),若仅仅判断其整个最终结果,而忽略每个条件的取值情况,必然会遗漏部分测试路径。

      例如:

      int a,b;

      if(a || b)

      执行语句1

      else

      执行语句2

    要达到这段程序的判断覆盖,我们采用测试用例:1)a = true , b = true ;2)a = flase, b = flase

    3条件覆盖:条件覆盖是指选择足够的测试用例,使得运行这些测试用例时,判定中每个条件的所有可能结果至少出现一次,但未必能覆盖全部分支

    条件覆盖要检查每个符合谓词的子表达式值为真和假两种情况,要独立衡量每个子表达式的结果,以确保每个子表达式的值为真和假两种情况都被测试到。

    4 判定条件覆盖:判定-条件覆盖就是设计足够的测试用例,使得判断中每个条件的所有可能取值至少执行一次,同时每个判断的所有可能判断结果至少执行,即要求各个判断的所有可能的条件取值组合至少执行一次。

    5) 条件组合覆盖:在白盒测试法中,选择足够的测试用例,使所有判定中各条件判断结果的所有组合至少出现一次,满足这种覆盖标准成为条件组合覆盖。

    6路径覆盖:是每条可能执行到的路径至少执行一次;

     说明:其中语句覆盖是一种最弱的覆盖,判定覆盖和条件覆盖比语句覆盖强,满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖和语句覆盖,条件组合覆盖是除路径覆盖外最强的,路径覆盖也是一种比较强的覆盖,但未必考虑判定条件结果的组合,并不能代替条件覆盖和条件组合覆盖。

    举例:

    if A and B then Action1

    if C or D then Action2

    1)语句覆盖最弱,只需要让程序中的语句都执行一遍即可 。上例中只需设计测试用例使得A=true B=true C=true 即可。

    2)分支覆盖又称判定覆盖:使得程序中每个判断的取真分支和取假分支至少经历一次,即判断的真假均曾被满足。上例需要设计测试用例使其分别满足下列条件即可(1)A=true,B=true,C=true,D=false(2)A=true,B=false,C=false,D=false。

    3)条件覆盖:要使得每个判断中的每个条件的可能取值至少满足一次。上例中第一个判断应考虑到A=true,A=false,B=true,B=false第二个判断应考虑到C=true,C=false,D=true,D=false,所以上例中可以设计测试用例满足下列条件(1)A=true,B=true,C=true,D=true(2)A=false,B=false,C=false,D=false。

    4) 路径覆盖:要求覆盖程序中所有可能的路径。所以可以设计测试用例满足下列条件(1)A=true,B=true,C=true,D=true(2)A=false,B=false,C=false,D=false(3)A=true,B=true,C=false,D=false(4)A=false,B=false,C=true,D=true。

    二、测试相关经验

          测试流程方面我的组长是一位经验丰富的老测试了,到目前已经9年了,我在她的带领下,从最开始的分析需求开始,逐步地跟着项目走完整个测试流程,包括纯手工测试,包含了自动化的测试流程,包含了性能测试的测试流程,直至每一个测试报告的最终形成。使我完全理解了一个科学,正确,严谨,正规化的测试流程。

           测试方法方面我个人特别注重理论知识和实际操作相结合,在理论知识方面,我主要是购买一些书籍,从最基础的软件测试理论到各种各样的程序设计语言,再到自动化测试,包括Java语言的自动化测试,Python语言的自动化测试,到性能测试的各项性能指标的分析,数据分析都是我自己提供书籍上的知识来获得的,在淘宝上面有各种各样的书籍和视频教程,我基本上都看了个遍,到目前为止,我的各种学习资料用了1T的移动硬盘来装,书籍也有一百多本了,在实际操作方面,我主要向我的组长请教,她是因为女生,特别注重细节,当我有不懂得地方就去请教她,我会问她为什么要这么操作,然后我会对比理论和实际的区别,为什么有这种区别。就这样我就通过一个个的项目来夯实理论知识和实际操作,每一次做完项目我都会进行一个总结,自己学到了哪些新的技术和方法?遇到了哪些新的问题?以后再遇到怎么处理?

           新的知识补充方面:随着项目的不同,所运用的知识也不同,每一次学习不同的知识既是工作项目的需要,也是自己学习新知识的契机,比如说学习python语言,本来我们测试人员是不用写代码的,或者说可以用Java写,但是目前市面上都在用python语言来写自动化测试脚本,肯定是有它的道理的,那么我当时给自己的目标并不是仅仅为了满足写自动化脚本那么简单,我还想把python语言全部学会,我下定决心之后就立即着手执行,因为我本来就是开发出身,会代码,所有的语言都是相通的,都有变量,流程控制语句,和方法三大内容。JavaScript和Python都是弱类型,解释性的语言,所以在学习的时候我就在对比起来学习,很快学会了这门语言,所以我个人觉得,不管做什么,我们不仅仅要会用它,而且要知道它为什么这样用?最好是能够精通,对我们的测试工作是十分有利的。

           知识结构方面我们作为一个测试人员,不仅仅要做好本职工作,把自己的测试技术练好,而且还要一个广泛涉猎,对前台,后台,硬件知识,网络知识都应该去学习,对我们快速定位bug,提出有效针对性的修改硬件非常有好处,如果有条件的话,尽量向全栈发展。开发的发展方向是向深度和精度发展,而测试是一个向广度发展的岗位,需要不同的知识来融合,因为我们测试的是一个集成的,有多种技术融合而成的系统项目,就需要我们广泛涉猎和学习,所以从职业规划和寿命度上面来看,测试的工作也是非常的不错,所以不断的学习才是硬道理!

           团队的氛围方面我本人是军人出身,历来重视团结的重要性,所以和开发人员,测试人员,需求人员以及上级相处要从大局出发,我们的每一个人员都是一个项目不可或缺的一份子,必须团结起来,才能为最后产品的顺利交付打好基础条件,所以同事之间的相处是最需要拿捏分寸的,特别是开发人员,人和人都是相互的,只要讲道理,相信别人是会理解的,总之一句话:从整个项目的大局出发,把工作做好。

           回首测试经历,我总结了以下几点:

           1.不断学习,不能丧失对新知识学习的渴望,对旧的知识形成体系,夯实基础,测试理论知识基本上这么多年以来没有变过,主要是一些方法和工具的改变和升级,广泛涉猎相关知识,为测试工作服务;

           2.搞好内部团结,建立起亲密的同事关系,不仅是对个人社交能力还是对自己的工作上的能力都是一个提升,都是百利而无一害的!

    三、测试能力培养

    一、业务分析能力

    1.分析整体业务流程

    不了解整个公司的业务,根本就没办法进行测试

    2.分析被测业务数据

    了解整个业务里面所需的数据有哪些?哪些是需要用户提供的?哪些是自己提供的?有哪些可以是假数据?有哪些必须是真数据?添加数据的时候可以用哪个库?

    明白了整个软件的数据库架构,才能知道哪一个数据是从哪一个表里头带出来的,它的逻辑是什么,有没有连带关系。

    3.分析被测系统架构

    用什么语言开发的?用的是什么服务器?测试它的话需要用什么样的环境进行测试?整体的测试环境是什么样的?

    如果缺少了,需要进行环境搭建,架构搭建。一般去一家新公司之后,架构是搭建好的,了解它即可,熟悉之前的这些老员工们使用什么样的架构去做的。

    4.分析被测业务模块

    整个软件有哪些模块,比如说首页面、注册页面、登录页面、会员页面、商品详情页面、优惠券页面等等

    明白有多少个模块需要测试,每个模块之间的连带关系,进而怎样进行人员分工

    5.分析测试所需资源

    我需要几台计算机,需要几部手机,手机需要什么样的系统,什么样的型号。

    比如测一个网站的性能的时候,电脑的配置达不到测试并发5000人的标准,要么升级电脑的硬件配置,要么多机联合,多机联合时需要几台电脑,都需要提前筹划。

    6.分析测试完成目标

    我的性能目标是什么样的?我的功能目标是什么样的?我要上线达到的上线标准是什么样的?

    性能目标,比如我要达到并发5000人的时候,CPU占用率不能高于70%,内存占用率不能高于60%,响应时间不能超过5秒

    功能目标,比如整体的业务流程都跑通,所有的分支流程都没有问题,所有的接口都能够互相调用,整体的UI界面没有问题,兼容性没有问题等

    把这些问题都弄清楚,测试的思路会非常的清晰

    二、缺陷洞察能力

    1.一般缺陷的发现能力

    至少你要满足一般缺陷的发现能力,这个是最基本的,如果要连最简单的一般的缺陷都发现不了的话,别说优秀测试工程师了,你说你是测试我都不信

    2.隐性问题的发现能力

    在软件的测试过程当中有一些缺陷藏的比较深,有的是性能方面的问题,有的是功能方面的问题,它需要有一些设定特定的条件的情况下才会出现这样的问题。

    比如说买双鞋必须选择的是什么品牌,必须选择是红颜色,必须选择44号,而且必须选择用特定的支付方式才会出现这样的bug的时候,那么这种就属于特别隐性的bug,对于这样的问题的发现能力一定要比别人更强,要找到一些别人可能发现不了的bug

    3.发现连带问题的能力

    当发现了一个缺陷之后,能够想到通过这个缺陷可能会引发其他哪个地方出现问题,这就叫做连带的问题。而不是说发现这一个bug之后提了这一个就算完了,一定要有一个察觉,可能其他地方也存在这样的问题。

    4.发现问题隐患的能力

    有些软件里边可能有一些操作模块,或者是代码写的接口,表面上没有什么问题,但是它是有隐患的,比如说这个接口写的不稳定,当他传的数据有一些问题的时候,可能它最后返回的结果就是报错就是报404或者报乱码。

    5.尽早发现问题的能力

    如果你只能停留在界面级别的话,那你根本就没有办法达到尽早发现问题的这个能力

    你必须要等到前端人员把每个界面都做好了之后才能进入测试,而我能比你早一个月进入测试了,然后我比你结束测试时间快一个月,而你又比我晚一个月,那么咱俩的薪资一下就拉开了

    6.发现问题根源的能力

    需要知道这个缺陷它到底是由什么原因产生的,是属于什么类型的缺陷,是ui前端人员做的问题,还是后台接口人员做的问题?

    不仅要找到这个bug,还要知道这个bug产生的原因,这样的测试人员是非常棒的,而且很是受人尊敬,提bug的方式也就不一样了

    三、团队协作能力

    1.合理进行人员分工

    合理的进行人员分工是提高效率的重要保证

    2.协助组员解决问题

    比如说测试在赶进度,或者这个软件项目的质量把控是一个团队来把控的,协助组员解决问题就显得尤为关键

    3.配合完成测试任务

    一个团队里边的人员分工,他们的任务都是不一样的,这就是咱们说的配合。你的东西做完了,要轮到我了,我的性能测完了之后该轮到你了,所以整个的一个流程下来之后,大家应该是各司其职,配合得非常紧密的一个过程

    4.配合开发重现缺陷

    我给你提bug,你改我的bug,咱们的目的只有一个,就是让这个软件变得更好,所以在这样的情况下,咱们就一定要配合开发

    5.督促项目整体进度

    既然是一个团队协作的过程,就一定要互相的去督促对方,包括督促开发去改bug,因为开发人员他们有时候工作很忙,他们不知道要先改哪些问题,要后改哪些问题,但是往往有一些缺陷,它影响了测试的这个时间,影响了测试的进度,那么这个时候就需要测试员去督促开发人员,让他尽快的去解决你棘手的问题。这个东西能够提高咱们的测试效率

    6.出现问题勇于承担

    愿意背锅的最后都成为了领导,不愿意背锅的最后依然是员工

    四、专业技术能力

    1.掌握测试基础知识

    基础知识就是根基,根基打好了,你才能够更有效地往后期发展,也就是为了以后的学习做一个铺垫。如果根基都没打好,功能测试不会,就想直接学性能,那性能是做不好的

    2.娴熟运用测试工具

    熟悉工具和熟练使用工具完全是两个概念,熟悉工具基本上等同于不会,遇到过很多简历上写会使用什么什么工具,都没有实际能力。比如loadrunner只会一个简单的录制,增强一下脚本,觉得会用了,那知识会用了1/5,其他4/5 都不会。

    3.了解工具操作原理

    它是怎么样给服务器发送请求的,是用什么样的方式去发送请的,是用什么样的方式去监控的,它的操作原理是什么样的,咱们要把这件事情搞清楚,这样的话能有助于更好的去使用这些东西。包括一些请求的协议,每个协议代表什么意思,它是用来干什么的。

    4.自主完成测试任务

    一定要能够自己完成一个独立的内容,独立的工作,这件事情领导你交给我好了,放心我能给你搞定,要的是这样的人

    5.找出问题出现原因

    找出缺陷的时候,不仅要看它的表面,还要看它的本质

    6.提供问题解决方案

    发现问题不是能力,发现问题并提出解决方案才是真的能力

    7.提供完整测试报告

    测试报告能够说明你表达的清不清楚?领导能不能看懂?还有就是能不能够把你整个测试的过程给它梳理得非常详细,人家能够通过你的报告,能够了解到整个的项目的情况,而不是只了解一个片面的情况

    8.了解相关技术领域

    触类旁通

    五、逻辑思考能力

    1.判断逻辑的正确性

    面试官也经常会给测试人去出一些逻辑题,逻辑题能够分析出来你这个人思维有没有?活跃不活跃?还有他的维度,包括他想的问题的全面性,都能够判断得出来。

    比如说去买一样商品,它的里边逻辑就会经常会出现很多问题,比如说它的会员的级别,什么样的级别去买什么样的商品,它的价格不一样,什么情况下会给优惠券,什么样的情况下不给优惠券?达到多少钱的情况下才能够使用优惠券?如果说这里边的逻辑出现了问题的话,那么整个的业务不用再测了

    2.对可行性逻辑分析

    要去测一个网站的逻辑的时候,一定要先思考这一个业务流程可能会涉及到哪些逻辑,这些逻辑哪些是可行的,有些是正向逻辑,有些是逆向逻辑,都要考虑全面,而不是说只是把正向的逻辑测试全面了,逆向逻辑不考虑。其实往往更容易出错的地方就是逆向逻辑

    3.思维导图梳理思路

    思维导图工具能够起到什么作用,能够让你更有效的进行测试,能够让你的思路更清晰

    4.站在客观角度思考

    去测试的时候,不要仅仅只是站在测试人员的角度上去对整个网站进行测试,还更多的要站在用户的角度,要替用户考虑

    六、问题解决能力

    1.技术上的问题

    把自己的个人能力提升起来,多跟别人虚心请教,多去自己想办法解决问题

    2.工作中的问题

    在任何的企业里边去工作,肯定会遇到一些工作当中的一些不愉快的事情,而不是什么事情都会让你很顺心。所以要去处理工作上的一些不顺心的事情,不要把它带到你的工作上,或者是你的生活上,尽可能的去跟别人沟通,去解决这个工作上遇到的麻烦

    3.同事间的问题

    在工作当中可能会涉及到跟开发人员的沟通,跟产品人员的沟通,跟ui人员的沟通,跟这三方的人员去沟通的时候,就要用不同的沟通方式

    4.领导层的问题

    如果你觉得你的领导不好,或者说你觉得对你的领导一些建议,不要的去跟同事之间去说他坏话或者怎么样的,领导需要的是解决问题的人,而不是制造问题的人

    七、沟通表达能力

    1.和技术人员的沟通

    跟开发人员阐述缺陷时要简洁明了、清晰易懂。当发现严重缺陷时,也不要大惊小怪,要站在开发人员的角度思考如何解决问题。而不是踩在开发头上,炫耀自己发现问题的能力。

    2.和产品人员的沟通

    当对产品提出意见时,要站在用户的角度去说明自己的想法,而不要主观认为不好而要求产品进行修改。

    3.和上级领导的沟通

    跟领导沟通时要有大局观,不能只考虑自己部门的情况。并且与领导沟通时,尽量直奔主题,不要拐弯抹角,当与领导意见不一致时,也不要直接反驳,应该先给予认可,再阐述自己的想法。

    4.在集体会议中沟通

    在集体会议中不要一味的突出自己的个人能力,不要当话痨,也不要默默无闻。适当的提出一些自己的见解,有助于让大家更加重视你的存在。切记不要在多人会议中,去指责别人和推卸问题。各个部门的同事,都要面子~

    5.与下级员工的沟通

    与下级沟通时不要摆高姿态,不要让下级产生畏惧感,应该更多的为下级解决问题。服务好部门的同事,才能更好的产生凝聚力。

    八、宏观把控能力

    1.有效控制测试时间

    测试周期的时间控制,应当采取多种方法去衡量,例如人员能力,人员数量,项目复杂程度,同类项目的测试经验等多方面去衡量。

    2.有效控制测试成本

    测试成本指的是人员成本跟时间成本,不要浪费每个人的时间跟劳动力,要让每个人充分发挥最大的价值。

    3.有效制定测试计划

    测试计划对于一个项目是核心关键,它的存在为了让测试进行中有依据可查。所以测试计划,一定要切合实际情况,要经过思考和衡量最后得出计划安排。

    4.有效控制组员情绪

    组员的情绪可以直接影响测试进度跟测试的质量,当有组员出现思想问题时,应当及时沟通,采取一些必要的措施去解决问题。而不能装看不见。

    5.有效进行风险评估

    任何项目在进行期间都存在许多潜在的风险,例如,人员离职,生病请假,业务变更,需求变更,服务器或其他组件故障等。应当提前做出相应的解决方案,以免到时候手忙脚乱。

    6.有效控制测试方向

    测试的方向是指测试的目标和测试的范围,很多项目的测试是有针对性的,例如性能测试,所以在测试中,一定要随时清楚测试的目标和目的是什么,以免把时间浪费在无关紧要的业务上。

    展开全文
  • 2、参数化、badboy测试脚本开发以及录制方法,正则表达式之Regextester工具使用、JMETER 组件作 用域等知识点讲解。 3、本课程注重实践每一个知识点都有相对应的实例,本书覆盖的实例多达上百个,提高学员的动手能 ...
  • 测试开发~

    千次阅读 2020-09-01 13:48:49
    1、首先针对测试这边的工作有(可以根据测试流程来回答): 需求分析阶段:需求分析与评审、学习业务...2、针对开发这边的工作: 自动化测试:编写测试脚本,执行测试,分析,提交BUG,跟踪BUG状态、总结 对测试

    一、测试开发的工作内容(如何理解测开 / 为什么选择做测开)

    测试开发的工作内容:

    1、首先针对测试这边的工作有(可以根据测试流程来回答):

    需求分析阶段:需求分析与评审、学习业务流程、提取功能点、编写需求分析说明书

    测试设计阶段:编写测试计划说明书(5W1H)、编写测试用例(涉及自动化测试的话需要编写测试用例脚本)

    测试执行阶段:提交BUG、跟踪BUG修改状态(这里可能会有回归测试,并且在测试执行之前会搭建测试环境)

    测试总结阶段:提交BUG表单、编写测试总结报告

    2、针对开发这边的工作:

    自动化测试:编写测试脚本,执行测试,分析,提交BUG,跟踪BUG状态、总结

    对测试工具的开发

    软件开发(就是开发的工作)

    二次开发(在开发人员开发好的软件上进行二次开发)

     

    你怎么理解测开的?

    测开岗其实分两种,以字节为例,测试开发工程师(技术序列),测试开发工程师(测试序列)。

    技术序列偏向于测试平台的研发工作,偏向于纯开发,很少涉及具体业务测试,测试序列偏向业务测试,代码开发工作较少,目前各个公司实际上区分不太明显,大部分还是偏向于业务测试,少数分的特别清楚如字节。

    但是部门公司面试标准是和开发对齐的,问的问题有时候会和开发没有特别大的区别、手撕算法难度也差不多,所以准备时应以开发岗的要求来做准备。

     

    为什么做测开?

    因为我的师兄师姐基本都是做开发或者算法,所以特通过他们了解了一些关于开发和算法岗的情况。测开这个岗位是通过我室友了解到的,后来自己也去了解了一些测开的知识,我觉得相对于开发岗或者算法岗,做测试这个工作更让我有成就感一些,我本身也挺喜欢测开这个工作模式。因为是第一份工作,所以也深入的去了解了一些测开的一些前景,因为现在客户对产品的质量越来越高,所以对产品的测试也越来越重要,比如性能测试和安全测试。因为测开这个岗位需要了解的东西很多,前端、开发、算法都需要了解一些。因此如果需要转岗的话,测开也是比较好转的,人生的第一份工作,我也想有更有可能性一些,不想一开始就把自己定位到某一个岗位上,我也想多学习,多了解一些知识。

     

    怎么理解测试?

    首先,测试是验证实际结果与预期结果是否一致的过程。

    其次,测试的作用是发现并深层次的定位BUG,在一定程度上协助开发找到解决问题的方案。

    再者,测试是为了保证产品的质量,在产品上线之前更可能多的发现产品的缺陷,避免上线后出现出现重大问题。

    二、路由器测试

    [参考](https://blog.csdn.net/qq_14935437/article/details/72768219)
    **(一)功能测试**
    路由器功能通常可以划分为如下方面。
    (1)接口功能:该功能用作将路由器连接到网络。可以分为局域网接口及广域网接口两种。局域网接口主要包括以太网、令牌环、令牌总线、FDDI等网络接口。广域网接口主要包括E1/T1、E3/T3、DS3、通用串行口(可转换成X.21DTE/DCE、V.35DTE/DCE、RS232DTE/DCE、RS449DTE/DCE、EIA530DTE)等网络接口。
    (2)通信协议功能:该功能负责处理通信协议,可以包括TCP/IP、PPP、X.25、帧中继等协议。
    (3)数据包转发功能:该功能主要负责按照路由表内容在各端口(包括逻辑端口)间转发数据包并且改写链路层数据包头信息。(4)路由信息维护功能:该功能负责运行路由协议,维护路由表。路由协议可包括RIP、OSPF、BGP等协议。
    (5)管理控制功能:路由器管理控制功能包括五个功能,SNMP代理功能,Telnet服务器功能,本地管理、远端监控和RMON功能。通过多种不同的途径对路由器进行控制管理,并且允许纪录日志。
    (6)安全功能:用于完成数据包过滤,地址转换,访问控制,数据加密,防火墙,地址分配等功能。
      路由器对上述功能并非必要完全实现。但是由于路由器作为网络设备,存在最小功能集,对最小功能集所规定的功能,路由器必须支持。因为绝大多数功能测试可以由接口测试、性能测试、协议一致性测试和网管测试所函盖,所以路由器功能测试一般可以只对其他测试无法涵盖的功能作验证性测试。路由器功能测试一般采用远端测试法。
    **(二)易用性测试**
    接口等一些设备好不好用,接口功能可以,但是接上的时候比较费力,不好接等。
      **(三)性能测试:时间性能,稳定性能,压力测试,负载测试**
      路由器是IP网络的核心设备,其性能的好坏直接影响IP网网络规模、网络稳定性以及网络可扩展性。由于IETF没有对路由器性能测试作专门规定,一般来说只能按照RFC2544( Benchmarking Methodology for Network Interconnect Devices)作测试。但路由器区别于一般简单的网络互连设备,在性能测试时还应该加上路由器特有的性能测试。例如路由表容量、路由协议收敛时间等指标。
      路由器性能测试应当包括下列指标。
      (1)吞吐量:测试路由器包转发的能力。通常指路由器在不丢包条件下每秒转发包的极限,一般可以采用二分法查找该极限点。
      (2)时延(时间测试):测试路由器在吞吐量范围内从收到包到转发出该包的时间间隔。时延测试应当重复20次然后取其平均值。
      (3)丢包率:测试路由器在不同负荷下丢弃包占收到包的比例。不同负荷通常指从吞吐量测试到线速(线路上传输包的最高速率),步长一般使用线速的10%。
      (4)背靠背帧数:测试路由器在接收到以最小包间隔传输时不丢包条件下所能处理的最大包数。该测试实际考验路由器缓存能力,如果路由器具备线速能力(吞吐量=接口媒体线速),则该测试没有意义。
      (5)系统恢复时间:测试路由器在过载后恢复正常工作的时间。测试方法可以采用向路由器端口发送吞吐量110%和线速间的较小值,持续60秒后将速率下降到50%的时刻到最后一个丢包的时间间隔。如果路由器具备线速能力,则该测试没有意义。
      (6)系统复位:测试路由器从软件复位或关电重启到正常工作的时间间隔。正常工作指能以吞吐量转发数据。
      (7)稳定性、可靠性测试
      由于大多数路由器需要每天24小时,每周7天连续工作,作为Internet核心设备的骨干路由器的稳定性和可靠性尤其重要。所以用户需要了解露由器的稳定性和可靠性。
      路由器的稳定性和可靠性很难测试。一般可以通过两种途径的到:(1)厂家通过关键部件的可靠性以及备份程度计算系统可靠性;(2)用户或厂家通过大量相同产品使用中的故障率统计产品稳定性和可靠性。当然,用户也可以通过在一定时间内对试运行结果的要求来在一定程度上保证路由器的可靠性与稳定性。

      在测试上述RFC2544中规定的指标时应当考虑下列因素。
      帧格式:建议按照RFC2544所规定的帧格式测试;帧长:从最小帧长到MTU顺序递增,例如在以太网上采用64, 128, 256, 512, 1024, 1280, 1518字节;认证接收帧:排除收到的非测试帧,例如控制帧、路由更新帧等;广播帧:验证广播帧对路由器性能的影响,上述测试后在测试帧中夹杂1%广播帧再测试;管理帧:验证管理帧对路由器性能的影响,上述测试后在测试帧中夹杂每秒一个管理帧再测试;路由更新:路由更新即下一跳端口改变对性能的影响;过滤器:在设置过滤器条件下对路由器性能的影响,建议设置25个过滤条件测试;协议地址:测试路由器收到随机处于256个网络中的地址时对性能的影响;双向流量:测试路由器端口双向收发数据对性能的影响;多端口测试:考虑流量全连接分布或非全连接分布对性能的影响;多协议测试:考虑路由器同时处理多种协议对性能的影响;混合包长:除测试所建议的递增包长外,检查混合包长对路由器性能的影响,RFC2544除要求包含所有测试包长外没有对混合包长中各包长所占比例作规定。笔者建议按照实际网络中各包长的分布测试,例如在没有特殊应用要求时以太网接口上可采用60字节包50%,128字节包10%,256字节包15%,512字节包10%,1500字节包15%。除上述RFC2544建议的测试项外还建议测试如下内容。
      ①路由震荡:路由震荡对路由器转发能力的影响。路由震荡程度即每秒更新路由的数量可以依据网络条件而定。路由更新协议可采用BGP。②路由表容量:测试路由表大小。骨干网路由器通常运行BGP,路由表包含全球路由。一般来说要求超过10万条路由,建议通过采用BGP输入导出路由计数来测试。③时钟同步:在包含相应端口例如POS口的路由器上测试内钟精度以及同步能力。④协议收敛时间:测试路由变化通知到全网所用时间。该指标虽然与路由器单机性能有关,但是一般只能在网络上测试,而且会因配置改变而变化。可以在网络配置完成后通过检查该指标来衡量全网性能。测试时间应当根据具体项目以及测试目标而定。一般认为测试时间应当介于60秒到300秒之间。另外一般可以根据用户要求和测试目标作设定选择。路由器性能测试一般可采用远端测试法。
     **(四)一致性测试**
      路由器一致性测试通常采用“黑箱”方法,被测试设备IUT叫做“黑箱”。测试系统通过控制观察点PCO与被测试设备接口。
      不同的测试事件是通过不同的PCO来控制和观察的,按照其应答是否遵守规范,即定时关系和数据匹配限制,测试的结果可分为通过、失败、无结果3种。路由器是一种复杂的网络互连设备,需要在各个通信层上实现多种协议。例如相应的接口的物理层和链路层协议、IP/ICMP等互联网层协议、TCP/UDP等传输层协议、Telnet/SNMP等应用层协议以及RIP/OSPF/BGP等路由协议。
      协议一致性测试应当包含路由器所实现的所有协议。由于该测试内容繁多测试复杂,在测试中可以选择重要的协议以及所关心的内容测试。由于骨干网上路有器可能影响全球路由,所以在路由器测试中应特别重视路由协议一致性测试例如OSPF和BGP协议。由于一致性测试只能选择有限测试例测试,一般无法涵盖协议所有内容。所以即使通过测试也无法保证设备完全实现协议所有内容,所以最好的办法是在现实环境中试运行。路由器一致性测试一般采用分布式测试法或远端测试法。
    **(五)互操作测试**
      由于通信协议、路由协议非常复杂且拥有众多选项,实现同一协议的路由器并不能保证互通互操作。并且因为一致性测试能力有限,即使通过协议一致性测试也未必能保证完全实现协议。所以有必要对设备进行互操作测试。
      互操作测试实际上是将一致性测试中所用的仪表替换成需要与之互通互操作的设备,选择一些重要且典型的互连方式配置,观察两设备是否能按照预期正常工作。
    **(六)网管测试**
      网管测试一般测试网管软件对网络以及网络上设备的管理能力。由于路由器是IP网的核心设备,所以必须测试路由器对网管的支持度。如果路由器附带网管软件,可以通过使用所附带的网管软件来检查网管软件所实现的配置管理、安全管理、性能管理、计帐管理、故障管理、拓扑管理和视图管理等功能。如果路由器不附带网管软件,则应当测试路由器对SNMP协议实现的一致性以及对MIB实现的程度。由于路由器需要实现的MIB非常多,每个MIB都包含大量内容,很难对MIB实现完全测试。一般可以通过抽测重要的MIB项来检查路由器对MIB的实现情况。

    三、Benchmark测试

    benchmark测试在计算机领域中最广泛和最成功的应用是性能测试,主要测试响应时间、传输速率和吞吐量等。此外他也用于功能、可操作性和数据处理开发易用性等方面的测试。benchmark测试有些偏重于硬件,有些偏重于软件,还有些注重于整个系统。在硬件方面广泛应用于评价CPU、内存、I/O接口和外围设备的性能,主要测试两个方面的性能指标:一是硬件传输数据的带宽,称为带宽基准测试;二是数据传输的延迟,称为延迟基准测试。在软件方面,他用于评价操作系统、数据库和中间件以及应用软件的数据处理能力。

    Benchmark测试中最重要的是标准规范,也就是说他是一个评价方式,工具等因素已经不重要,只要大家都用同一标准规范、同一工具进行系统测试,那么测试结果也就具有了比较意义。Benchmark 测试实际上就成了各个厂商展示技术实力的舞台, 任何厂家或者测试者都可以根据组织公布的规范标准, 构建自己最优的系统.
    四、软件用例状态

    具体这些状态都是什么意思呢?

    1.排队(In Queue):测试用例已经指定给某个测试人,不准备在这一个测试阶段运行。

    2.进行中(IP):该测试正在进行,并且会持续一段时间。

    3.阻塞(Block):一些因素会导致测试不能进行到底,例如某个功能欠缺或者测试环境的某个部分欠缺。即,希望运行测试,但是目前还不能运行测试。

    4.跳过(Skip):你决定在当前测试阶段跳过某个测试,可能是因为它的优先权相对较低。即,现在可以运行这个测试,但是我不想运行它。

    5.通过(Pass):测试运行结束,测试人得到了预料中的测试结果状态和测试行为。

    6.失败(Fail):在很多情况下,测试人得到预料之外的测试结果,状态或行为,这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。

    7.警告(Warn):在很多情况下,测试人得到预料之外的测试结果,状态或行为,但是这些结果与测试目标差别不是很大

    8.关闭(Close):一个测试在第一个循环中被标为失败或警告,第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后,没有错误出现。将这类测试标记为关闭而不是通过,使得你可以跟踪测试在某一个测试发布中失败的实事
    五、SDV测试

    产品研发阶段:
    SIV:SYSTEM INTEGRATION VERIFY 系统集成验证
    SDV:SYSTEM DESIGN VERIFY 系统设计验证
    SIT:SYSTEM INTEGRATION TEST系统集成测试
    一般这三种都由开发 人员做。

     产品测试阶段:
    ST:SYSTEM TEST系统集成测试

    六、冒烟测试&可用性测试&回归测试

    测试领域,冒烟测试(smoke test)、可用性测试(sanity test)和回归测试(regression test)彼此之间很相似,范围也有重叠,所以比较容易混淆:都是在需求变更或问题修改后对系统全面测试之前的一种预测试,都是为了发现是否在界面和代码层面引入了问题。

      我们可以用一个和河流相关的类比来更好的理解它们之间的差别,在类比之前,我们先了解下这几个测试的简单定义:
      Smoke Testing:测试新特性有关的所有方面 (广度) ,但不深入,用以判断我们是否需要执行进一步的测试。
      Sanity Testing:测试新特性的有限正常功能,深入测试。
      Regression testing:回归新特性所有相关功能,避免引入代码变更存在问题以及引入新问题,深入全面。

      如果我们拿一条河流来比喻,比如1000英尺宽,在水里含有杂质(可以比作软件中的bug),那么这三种类型的测试可以被看作如下:
      对于Smoke Testing:为了找到河面所有的杂质,但不包括水面以下的。
      对于Sanity Testing:为了找到某个特定范围内所有的杂质(比如200英尺半径内),这不包含所有表面的杂质,但包含了那个范围内水面下直到水底的杂质。
      对于Regression Testing:为了这片水域所有的杂质,表面的以及水面以下的

    七、Daily test

    目的 :可以对DailyBuild的版本进行风险控制,快速验证版本功能和质量,减少手工测试,提升版本质量.

    流程: 如图所示,各个迭代组把每日构建的版本下载到自己独立的服务器/环境,执行完整的/较完善的版本级测试用例(验证所有功能/特性的测试用例),及时发现问题(各个迭代组的代码可能出现耦合,或者开发的特性相互影响),根据问题的严重性进行定位,更新版本。

    其中,测试的内容包括:基本功能验证、老特性回归测试、新特性冒烟测试 。

     

    术语解释

    DailyBuild---根据情况,每日合入各个迭代组完成的特性/功能,快速生成现实可用的版本。

    DailyTest---对DailyBuild的版本进行测试,发现问题,及时反馈解决。

    回归测试---在旧本已验证正确的测试用例,在新版本继续使用,验证功能模块。回归测试作为软件生命周期的一个组成部分,在整个软件测试过程中占有很大的工作量比重,软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中,新版本的连续发布使回归测试进行的更加频繁,而在极端编程方法中,更是要求每天都进行若干次回归测试。[百度]

    冒烟测试---冒烟测试(smoke test)在测试中发现问题,找到了一个Bug,然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug,或者是否会对其它模块造成影响,就需要针对此问题进行专门测试,这个过程就被称为Smoke Test。

    八、测试驱动开发

    测试驱动开发,英文全称Test-Driven Development,简称TDD,是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能代码之前先编写测试代码,然后只编写使测试通过的功能代码,通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码,并加速开发过程。

    九、刷新率

    1、刷新率

    刷新率是指电子束对屏幕上的图像重复扫描的次数。刷新率越高,所显示的图象(画面)稳定性就越好。刷新率高低将直接决定其价格,但是由于刷新率与分辨率两者相互制约,因此只有在高分辨率下达到高刷新率这样的显示器才能称其为性能优秀。

    注意,虽然它的计算单位与垂直扫描频率都是Hz,但这是两个截然不同的概念。75Hz的画面刷新率是VESA订定无闪烁的最基本标准,这里的75Hz应是所有显示模式下的都能达到的标准。

    影响因素1

    软件

    影响因素2

    硬件

    影响因素3

    行频

    十、测试管理体系/流程

     一、IPD

    1、IPD概念

    集成产品开发,Integrated Product Development

    2、IPD作为先进的产品开发理念,其核心思想概括如下:

    a) 新产品开发是一项投资决策。IPD强调要对产品开发进行有效的投资组合分析,并在开发过程设置检查点,通过阶段性评审来决定项目是继续、暂停、终止还是改变方向。

    b) 基于市场的开发。IPD强调产品创新一定是基于市场需求和竞争分析的创新。为此,IPD把正确定义产品概念、市场需求作为流程的第一步,开始就把事情做正确。

    c) 跨部门、跨系统的协同。采用跨部门的产品开发团队(PDT:Product Development Team),通过有效的沟通、协调以及决策,达到尽快将产品推向市场的目的。

    d) 异步开发模式,也称并行工程。就是通过严密的计划、准确的接口设计,把原来的许多后续活动提前进行,这样可以缩短产品上市时间。

    e) 重用性。采用公用构建模块(CBB:Common Building Block)提高产品开发的效率。

    f) 结构化的流程。产品开发项目的相对不确定性,要求开发流程在非结构化与过于结构化之间找到平衡。

    IPD框架是IPD的精髓,它集成了代表业界最佳实践的诸多要素。具体包括异步开发与共用基础模块、跨部门团队、项目和管道管理、结构化流程、客户需求分析($APPEALS)、优化投资组合和衡量标准共七个方面,IPD框架如下图所示:

    3、下面分别介绍IPD框架中的几个方面:

    A、市场管理

    市场管理从客户、投资、市场等产品生存的外在客观环境因素来影响产品的特性和生命。包括:

    a)需求分析

    可以说,没有需求就没有产品,缺乏好的、及时的市场需求是项目方向偏离和产品失败的最主要原因。IPD使用一种用于了解客户需求、确定产品市场定位的工具——$APPEALS进行需求分析。 $APPEALS从八个方面衡量客户对产品的关注,确定产品的哪一方面对客户是最重要的。$APPEALS的含义如下:$-产品价格(Price);A-可获得性(Availability);P-包装(Packaging);P-性能(Performance);E-易用性(Easy to use);A-保证程度(Assurances);L-生命周期成本(Life cycle of cost);S-社会接受程度(Social acceptance)。

    b)组合分析

    IPD强调对产品开发进行有效的投资组合分析。如何正确评价、决定企业是否开发一个新产品,以及正确地决定对各个新产品的资金分配额,就需要测定新产品的投资利润率。只有明确了投资利润率的各种静态和动态的决定因素和计算方法,企业才能对产品战略做出正确的判断和决策,进而确定产品开发的投资。

    企业能否有效地掌握投入资金的对策,取得好的产品资金效果,提高资金运营效率,是一个大的战略问题,也是企业业务投资组合计划的任务。尤其是经营多种产品的生产企业,要正确地决定资金投入对策,还必须研究产品结构,研究企业各种产品的投入、产出、创利与市场占有率、市场成长率的关系,然后才能决定对众多产品如何分配资金。这是企业产品投资组合计划必须解决的问题。企业组成什么样的产品结构?总的要求应是各具特色,经济合理。因此,需要考虑服务方向、竞争对手、市场需求、企业优势、资源条件、收益目标等因素。

    投资组合分析要贯穿整个产品生命周期,在开发过程设置检查点,通过阶段性评审来决定项目是继续、暂停、终止还是改变方向。通常在各个阶段完成之后,要做一次GO/NO GO决策,以决定下一步是否继续,从而可以最大地减少资源浪费,避免后续资源的无谓投入。

    c)衡量指标

    投资分析和评审的依据是事先制订的衡量指标,包括对产品开发过程、不同层次人员或组织的工作绩效进行衡量的一系列指标。 如产品开发过程的衡量标准有硬指标(如财务指标、产品开发周期等)和软指标(如产品开发过程的成熟度);衡量标准有投资效率、新产品收入比率、被废弃的项目数、产品上市时间、产品盈利时间、共用基础模块的重用情况等。

    B、流程重整

    IPD中的流程重整主要关注于跨部门的团队、结构化的流程、项目和管道管理。在结构化流程的每一个阶段及决策点,由不同功能部门人员组成的跨部门团队协同工作,完成产品开发战略的决策和产品的设计开发,通过项目管理和管道管理来保证项目顺利地得到开发。

    a)团队

    组织结构是流程运作的基本保证。在IPD中有两类跨部门团队,一个是集成产品管理团队(IPMT),属于高层管理决策层; 另一个是产品开发团队(PDT),属于项目执行层。IPD团队框架可参考如下:

    IPMT和PDT都是由跨职能部门的人组成,包含了开发、市场、生产、采购、品质、财务、制造、技术支援等不同部门的人员,其人员层次和工作重点都有所不同。IPMT由公司决策层人员组成,其工作是确保公司在市场上有正确的产品定位,保证项目保证资源、控制投资。IPMT同时管理多个PDT,并从市场的角度考察他们是否盈利,适时终止前景不好的项目,保证将公司有限的资源投到高回报的项目上。

    PDT是具体的产品开发团队,其工作是制定具体产品策略和业务计划,按照项目计划执行并保证及时完成,确保小组将按计划及时地将产品投放到市场。

    PDT是一个虚拟的组织,其成员在产品开发期间一起工作,由项目经理组织,可以是项目经理负责的项目单列式组织结构。

    b) 流程

    IPD产品开发流程被明确地划分为概念、计划、开发、验证、发布、生命周期六个阶段,并且在流程中有定义清晰的决策评审点。这些评审点上的评审已不是技术评审,而是业务评审,更关注产品的市场定位及盈利情况。决策评审点有一致的衡量标准,只有完成了规定的工作才能够由一个决策点进入下一个决策点。下面是典型的产品开发流程:

    ①在概念阶段初期,一旦IPMT认为新产品、新服务和新市场的思想有价值,他们将组建并任命PDT成员。

    ②PDT了解未来市场、收集信息、制定业务计划。业务计划主要包括市场分析、产品概述、竞争分析、生产和供应计划、市场计划、客户服务支持计划、项目时间安排和资源计划、风险评估和风险管理、财务概述等方面信息,所有这些信息都要从业务的角度来思考和确定,保证企业最终能够盈利。

    ③ 业务计划完成之后,进行概念决策评审。IPMT审视这些项目并决定哪些项目可以进入计划阶段。

    ④在计划阶段,PDT综合考虑组织、资源、时间、费用等因素,形成一个总体、详细、具有较高正确性的业务计划。

    ⑤完成详细业务计划以后,PDT提交该计划给IPMT评审。如果评审通过,项目进入开发阶段。PDT负责管理从计划评审点直到将产品推向市场的整个开发过程,PDT小组成员负责落实相关部门的支持。

    ⑥在产品开发全过程中,就每一活动所需要的时间及费用,不同层次人员、部门之间依次做出承诺。

    c)管理

    项目管理是使跨部门团队集合起来更好地行动的关键。首先要有一个目标即项目所要达到的效果,一旦我们将客户的需求转换为对产品的需求时,就可以制定详细计划。该计划中的各部分将具体划分为每个职能部门的工作,即这个计划不只是研发部门的计划,也是公司各个部门共同的计划。 一个产品从概念形成到上市期间会涉及到许多不同的紧密相联的活动,就好像不同职能部门彼此之间是有关系的。同样在一个项目中他们彼此之间的活动也是有关联的,所有的活动加起来就是整个的产品开发。

    接下来安排活动的时间,然后对每个活动进行预算和资源的调配,在项目实施过程中还需要不断地与计划对照,因为没有任何一个计划是完善的,所以可以在细的层面上对计划进行一定的调整,但是PDT做出的承诺不能改变。整个项目的进行过程都需要PDT的参与,因此,PDT在产品开发全流程中自始至终存在。

    管道管理类似于多任务处理系统中的资源调度和管理,指根据公司的业务策略对开发项目及其所需资源进行优先排序及动态平衡的过程。

    C、产品重整

    IPD提高开发效率的手段是产品重整。产品重整主要关注于异步开发和共用基础模块(CBB)。

    ①开发

    异步开发模式的基本思想是将产品开发在纵向分为不同的层次,如技术层、子系统层、平台层等。不同层次工作由不同的团队并行地异步开发完成,从而减少下层对上层工作的制约,每个层次都直接面向市场。

    通常,在产品开发过程中,由于上层技术或系统通常依赖于下层的技术,因此,开发层次之间的工作具有相互依赖性,如果一个层次的工作延迟了,将会造成整个时间的延长,这是导致产品开发延误的主要原因。 通过减弱各开发层次间的依赖关系,可以实现所有层次任务的异步开发。

    为了实现异步开发,建立可重用的共用基础模块是非常重要的。

    ②模块

    共用基础模块(Common Building Blocks, CBB)指那些可以在不同产品、系统之间共用的零部件、模块、技术及其他相关的设计成果。由于部门之间共享已有成果的程度很低,随着产品种类的不断增长,零部件、支持系统、供应商也在持续增长,这将导致一系列问题。 事实上,不同产品、系统之间,存在许多可以共用的零部件、模块和技术,如果产品在开发中尽可能多地采用了这些成熟的共用基础模块和技术,无疑这一产品的质量、进度和成本会得到很好的控制和保证,产品开发中的技术风险也将大为降低。 因此,通过产品重整,建立CBB数据库,实现技术、模块、子系统、零部件在不同产品之间的重用和共享,可以缩短产品开发周期、降低产品成本。 CBB策略的实施需要组织结构和衡量标准的保证。

    不管是异步开发还是共用基础模块的实现,都需要很高水平的系统划分和接口标准制订,需要企业级的构架师进行规划。

    4、关键要素

    ①、跨部门团队,包括进行管理的产品评审委员会及具体执行开发过程的产品开发团队(PDT)。

    ②、结构化的流程。IPD流程分为6个阶段及4个主要决策评审点(DCP),这些阶段和决策评审点由跨部门团队进行计划和管理。6个阶段包括概念、计划、开发、验证、发布 及生命周期,每个阶段有其阶段性的目标、关注点及需交付的成果。

    ③、一流的子流程,包括计划与控制、阶段决策、技术评审、以用户为中心的设计、CBB-重用、文档管理、质量控制、物料管理、软硬件设计、技术管理及管道管理等。

    ④、IPD工具:包括业务及技术上的工具。

    ⑤、考评:包括团队和个人绩效考核两个方面:首先是基于产品开发团队(PDT)的指标,如上市时间(TTM)、盈利时间和公用构建模块(CBB)等;其次是基于个人的指标,包括进度或计划完成率、质量、公用构建模块、关键行为指标等。

    5、实施IPD注意事项

    借鉴业界成功实施IPD公司的经验总结,一个组织实施IPD时要密切注意如下两个方面:

    ①、整体规划、分步实施。

    IPD涉及7个方面,如果全面深入实施,需要投入比较多的时间和成本,但大部分企业没有这样做的必要,IPD的7个要素是相互关联,又彼此独立的,企业完全可以根据自己实际情况和需要,分步实施,结合国内企业的实际研发能力,建议优先实施:结构化流程、项目管理、异步开发与公共基础模块3个方面。

    ②、IPD实施要借助信息化工具。

    实施IPD就需要制定一系列流程、制度、方法、模板,尤其跨部门项目团队、分层分级的计划管理、衡量指标的落地执行都需要借助IT化手段,从而降低操作难度;实践证明能够很好支撑IPD落地的工具有:微软Project Server、IBM Rational系列工具、青铜器RDM研发管理系统。IPD工具至少要满足如下特点:

    1) 支撑研发决策管理,工具要能自动汇总资源、财务、进度等数据,同时要能跨项目对比分析,从而有效支撑领导商业决策分析。

    2) 同时满足产品、项目、部门的管理需要,产品要提供资源计划、产品规划、市场情报收集分析能力;项目要提供计划、团队沟通、交付文档管理、需求测试管理能力;部门要提供资源池分析管理能力

    3) 强大报表分析能力,能够自动汇总进度、财务、交付、质量等量化数据,并且按照不同维度对比分析,满足多项目管理的需要。

    6、IPD优点

    集成产品开发是从企业的流程重组和产品重组的角度,保证产品的立项开发、产品开发的人力资源有效调配。依据一个完整的框架和管理流程,给企业管理带来的主要优点在于:

    ①产品研发周期显著缩短;

    ②产品成本降低;

    ③研发费用占总收入的比率降低,人均产出率大幅提高;

    ④产品质量普遍提高;

    ⑤花费在中途废止项目上的费用明显减少。

    二、CMMI

    1、CMMI含义

    Capability Maturity Model Integration,即能力成熟度模型集成

    2、CMM

    2.1CMM含义

    能力成熟度模型,Capability Maturity Model

    2.2CMM等级划分

    软件能力成熟度模型是一种对软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述形成的标准。CMM的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护进行过程监控和研究,以使其更加科学化、标准化、使企业能够更好地实现商业目标。

    CMM是一种用于评价软件承包能力并帮助其改善软件质量的方法,侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级:一级为初始级,二级为可重复级,三级为已定义级,四级为已管理级,五级为优化级。

    CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征:

    (1)初始级(initial)。工作无序,项目进行过程中常放弃当初的计划。管理无章法,缺乏健全的管理制度。开发项目成效不稳定,项目成功主要依靠项目负责人的经验和能力,他一但离去,工作秩序面目全非。

    (2)可重复级(Repeatable)。管理制度化,建立了基本的管理制度和规程,管理工作有章可循。 初步实现标准化,开发工作比较好地按标准实施。 变更依法进行,做到基线化,稳定可跟踪,新项目的计划和管理基于过去的实践经验,具有重复以前成功项目的环境和条件。

    (3)已定义级(Defined)。开发过程,包括技术工作和管理工作,均已实现标准化、文档化。建立了完善的培训制度和专家评审制度,全部技术活动和管理活动均可控制,对项目进行中的过程、岗位和职责均有共同的理解 。

    (4)已管理级(Managed)。产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势,如预测偏差,实现及时纠正。

    (5)优化级(Optimizing)。可集中精力改进过程,采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据,并可据进行分析,从而得出最佳方法。

    3、CMMI与CMM

    CMMI是CMM模型的最新版本。早期的CMMI(CMMI-SE/SW/IPPD),SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展,演绎成为一种被广泛应用的综合性模型。

    CMM模型主要用于软件过程的改进,促进软件企业软件能力成熟度的提高,但它对于系统工程、集成化产品和过程开发、供应商管理等领域的过程改进都存在缺陷,因而人们不得不分别开发软件以外其他学科的类似模型。

    4、CMMI模型表示法

    在CMMI中,每一种CMMI学科模型都有两种表示法:阶段式表示法和连续式表示法。

    不同表示法的模型具有不同的结构。连续式表示法强调的是单个过程域的能力,从过程域的角度考察基线和度量结果的改善,其关键术语是“能力”;而阶段式表示法强调的是组织的成熟度,从过程域集合的角度考察整个组织的过程成熟度阶段,其关键术语是“成熟度”。

    (1)阶段式表示法

    软件CMM是一种阶段式模型,该模型经过多年的成功使用已经被证明是有效的,这为选择阶段式表示法模型提供了最强有力的证据。考虑从不成熟组织向成熟组织的发展过程,阶段式表示法具有两方面优势。

    首先,阶段式模型为支持组织的过程改进提供了一个过程平台,该模型将软件组织的软件能力成熟度描述为5级。对于着眼于改善过程成熟度的组织来说,阶段式模型提供了一种明确的、行之有效的跨越式发展途径。阶段式模型中所描述的组织的五个成熟度等级中,每实现一次等级间的跨越,组织就致力于解决某一方面的问题。例如,组织从成熟度等级1到成熟度等级2,主要致力于项目管理过程的改进;从成熟度等级2到成熟度等级3,主要致力于广泛的组织级过程的改进;从成熟度等级3到成熟度等级4,主要致力于过程定量管理的过程的改进;从成熟度等级4到成熟度等级5,主要致力于技术革新和优化过程的改进。通过这种方式,阶段式模型确定了组织进行过程改进的最佳次序。

    其次,阶段式模型可以为组织定义一个过程成熟度等级,便于进行跨组织的比较。在阶段式模型中,每一个过程域都被指定归属到一个成熟度等级中。因此,基于阶段式模型为组织所定义的成熟度等级中,过程域的预期范围和应用将变得非常清晰。这样,在对不同的组织进行比较时,只要对比组织所达到的不同的成熟度等级,即可知道不同组织在执行过程域方面所存在的差别。

    阶段式表示法存在两方面的缺点:一是阶段式表示法采用分组形式,将过程域划分到五个等级中。在一般情况下,一个组织要到达某一个等级,必须满足该等级及其低等级的所有过程域,因而缺乏灵活性。另外,阶段式表示法的每个等级都会出现同时进行多个过程改进的情况,因而工作量大,所花费的成本也很大。

    (2)连续式表示法

    相比之下,连续式模型不如阶段式模型常用,采用连续式模型也有如下两方面的优势:

    首先,连续式模型为用户进行过程改进提供了比较大的自由度。如同上面所说,阶段式模型确定了组织进行过程改进的最佳次序,但同时也限定了用户在进行过程改进时必须遵循单一的改善路径。而连续式模型则允许用户根据组织的业务目的来选择过程改进活动的次序。在连续式模型中,用户可以选择定义组织的成熟度等级,同时还可以选择定义更适合于自身业务环境的过程域的次序。组织可以在一个自己选择的次序中使过程域达到给定的能力等级,而不必遵循单一的阶段式模型的原则。

    其次,基于连续式模型对组织的过程进行评估,其评估结果具有更好的可见性。在连续式模型中,可以为每个过程域定义多个能力等级,从而可以增强对过程改进中强项和弱点的认识。由于连续式模型是对每个个别的过程域进行单独的评定,并给出个别过程域的能力等级特征图,这样更便于观察。

    连续式表示法也存在两方面的缺点:一是由于连续式表示法没有规定过程域应用的顺序,因而组织的过程改进需要软件过程改进专家的指导,以便确定组织需要改进的过程和改进的先后次序。另外,尽管组织应用连续式表示法进行了过程改进,但难以与其他软件组织进行组织间过程能力的比较。 

    5、CMMI级别

    CMMI共有5个级别,代表软件团队能力成熟度的5个等级,数字越大,成熟度越高,高成熟度等级表示有比较强的软件综合开发能力。

    CMMI一级,执行级。在执行级水平上,软件组织对项目的目标与要做的努力很清晰,项目的目标可以实现。但是由于任务的完成带有很大的偶然性,软件组织无法保证在实施同类项目时仍然能够完成任务。项目实施能否成功主要取决于实施人员。

    CMMI二级,管理级。在管理级水平上,所有第一级的要求都已经达到,另外,软件组织在项目实施上能够遵守既定的计划与流程,有资源准备,权责到人,对项目相关的实施人员进行了相应的培训,对整个流程进行监测与控制,并联合上级单位对项目与流程进行审查。二级水平的软件组织对项目有一系列管理程序,避免了软件组织完成任务的随机性,保证了软件组织实施项目的成功率。

    CMMl三级,明确级。在明确级水平上,所有第二级的要求都已经达到,另外,软件组织能够根据自身的特殊情况及自己的标准流程,将这套管理体系与流程予以制度化。这样,软件组织不仅能够在同类项目上成功,也可以在其他项目上成功。科学管理成为软件组织的一种文化,成为软件组织的财富。

    CMMI四级,量化级。在量化管理级水平上,所有第三级的要求都已经达到,另外,软件组织的项目管理实现了数字化。通过数字化技术来实现流程的稳定性,实现管理的精度,降低项目实施在质量上的波动。

    CMMI五级,优化级。在优化级水平上,所有第四级的要求都已经达到,另外,软件组织能够充分利用信息资料,对软件组织在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程,运用新技术,实现流程的优化。

    由上述的5个级别可以看出,每一个级别都是更高一级的基石。要上高层台阶必须首先踏上所有下层的台阶。

    三、TMMI

    1、TMMI是基于敏捷开发模型

    2、TMMI讲究持续开发、持续集成、持续测试

    3、TMMI参照CMMI测试体系

    4、TMMI评估范围

    十一、

     

    展开全文
  • 2、参数化、badboy测试脚本开发以及录制方法,正则表达式之Regextester工具使用、JMETER 组件作 用域等知识点讲解。 3、ant 介绍以及作用、ant 下载及安装、ant build.xml 详解。 4、Jenkins 构建自动化平台、...
  • 对于在公司成为一位优秀的测试开发工程师,我觉得下面这篇文章涉及到的是我们需要的,稍微进行改动https://blog.csdn.net/sinat_21026543/article/details/79909062 测试流程方面:从最开始的分析需求开始,逐步地...

    对于测试的基本知识,可以查看软件测试相关书籍

    对于在公司成为一位优秀的测试开发工程师,我觉得下面这篇文章涉及到的是我们需要的,稍微进行改动https://blog.csdn.net/sinat_21026543/article/details/79909062

    测试流程方面:从最开始的分析需求开始,逐步地跟着项目走完整个测试流程,包括纯手工测试,包含了自动化的测试流程,包含了性能测试的测试流程,直至每一个测试报告的最终形成,理解一个科学,正确,严谨,正规化的测试流程。

    测试方法方面:注重理论知识和实际操作相结合,在理论知识方面,购买一些书籍,从最基础的软件测试理论到各种各样的程序设计语言,再到自动化测试,包括Java语言的自动化测试,Python语言的自动化测试,到性能测试的各项性能指标的分析,数据分析都是书籍上的知识来获得的,在淘宝上面有各种各样的书籍和视频教程,实际操作中注重细节,不懂得地方就去请教,对比理论和实际的区别,为什么有这种区别。通过一个个的项目来夯实理论知识和实际操作,每一次做完项目进行一个总结,自己学到了哪些新的技术和方法?遇到了哪些新的问题?以后再遇到怎么处理?

           新的知识补充方面:随着项目的不同,所运用的知识也不同,每一次学习不同的知识既是工作项目的需要,也是自己学习新知识的契机,比如说学习python语言,本来我们测试人员是不用写代码的,或者说可以用Java写,但是目前市面上都在用python语言来写自动化测试脚本,肯定是有它的道理的,那么我当时给自己的目标并不是仅仅为了满足写自动化脚本那么简单,我还想把python语言全部学会,我下定决心之后就立即着手执行,因为我本来就是开发出身,会代码,所有的语言都是相通的,都有变量,流程控制语句,和方法三大内容。JavaScript和Python都是弱类型,解释性的语言,所以在学习的时候我就在对比起来学习,很快学会了这门语言,所以我个人觉得,不管做什么,我们不仅仅要会用它,而且要知道它为什么这样用?最好是能够精通,对我们的测试工作是十分有利的。

           知识结构方面:我们作为一个测试人员,不仅仅要做好本职工作,把自己的测试技术练好,而且还要一个广泛涉猎,对前台,后台,硬件知识,网络知识都应该去学习,对我们快速定位bug,提出有效针对性的修改硬件非常有好处,如果有条件的话,尽量向全栈发展。开发的发展方向是向深度和精度发展,而测试是一个向广度发展的岗位,需要不同的知识来融合,因为我们测试的是一个集成的,有多种技术融合而成的系统项目,就需要我们广泛涉猎和学习,所以从职业规划和寿命度上面来看,测试的工作也是非常的不错,所以不断的学习才是硬道理!

           团队的氛围方面:和开发人员,测试人员,需求人员以及上级相处要从大局出发,我们的每一个人员都是一个项目不可或缺的一份子,必须团结起来,才能为最后产品的顺利交付打好基础条件,所以同事之间的相处是最需要拿捏分寸的,特别是开发人员,人和人都是相互的,只要讲道理,相信别人是会理解的,总之一句话:从整个项目的大局出发,把工作做好。

           回首测试经历,我总结了以下几点:

           1.不断学习,不能丧失对新知识学习的渴望,对旧的知识形成体系,夯实基础,测试理论知识基本上这么多年以来没有变过,主要是一些方法和工具的改变和升级,广泛涉猎相关知识,为测试工作服务;

           2.搞好内部团结,建立起亲密的同事关系,不仅是对个人社交能力还是对自己的工作上的能力都是一个提升,都是百利而无一害的!

    /*/*/
    一、业务分析能力

    1.分析整体业务流程

    不了解整个公司的业务,根本就没办法进行测试

    2.分析被测业务数据

    了解整个业务里面所需的数据有哪些?哪些是需要用户提供的?哪些是自己提供的?有哪些可以是假数据?有哪些必须是真数据?添加数据的时候可以用哪个库?

    明白了整个软件的数据库架构,才能知道哪一个数据是从哪一个表里头带出来的,它的逻辑是什么,有没有连带关系。

    3.分析被测系统架构

    用什么语言开发的?用的是什么服务器?测试它的话需要用什么样的环境进行测试?整体的测试环境是什么样的?

    如果缺少了,需要进行环境搭建,架构搭建。一般去一家新公司之后,架构是搭建好的,了解它即可,熟悉之前的这些老员工们使用什么样的架构去做的。

    4.分析被测业务模块

    整个软件有哪些模块,比如说首页面、注册页面、登录页面、会员页面、商品详情页面、优惠券页面等等

    明白有多少个模块需要测试,每个模块之间的连带关系,进而怎样进行人员分工

    5.分析测试所需资源

    我需要几台计算机,需要几部手机,手机需要什么样的系统,什么样的型号。

    比如测一个网站的性能的时候,电脑的配置达不到测试并发5000人的标准,要么升级电脑的硬件配置,要么多机联合,多机联合时需要几台电脑,都需要提前筹划。

    6.分析测试完成目标

    我的性能目标是什么样的?我的功能目标是什么样的?我要上线达到的上线标准是什么样的?

    性能目标,比如我要达到并发5000人的时候,CPU占用率不能高于70%,内存占用率不能高于60%,响应时间不能超过5秒

    功能目标,比如整体的业务流程都跑通,所有的分支流程都没有问题,所有的接口都能够互相调用,整体的UI界面没有问题,兼容性没有问题等

    把这些问题都弄清楚,测试的思路会非常的清晰

    二、缺陷洞察能力

    1.一般缺陷的发现能力

    至少你要满足一般缺陷的发现能力,这个是最基本的,如果要连最简单的一般的缺陷都发现不了的话,别说优秀测试工程师了,你说你是测试我都不信

    2.隐性问题的发现能力

    在软件的测试过程当中有一些缺陷藏的比较深,有的是性能方面的问题,有的是功能方面的问题,它需要有一些设定特定的条件的情况下才会出现这样的问题。

    比如说买双鞋必须选择的是什么品牌,必须选择是红颜色,必须选择44号,而且必须选择用特定的支付方式才会出现这样的bug的时候,那么这种就属于特别隐性的bug,对于这样的问题的发现能力一定要比别人更强,要找到一些别人可能发现不了的bug

    3.发现连带问题的能力

    当发现了一个缺陷之后,能够想到通过这个缺陷可能会引发其他哪个地方出现问题,这就叫做连带的问题。而不是说发现这一个bug之后提了这一个就算完了,一定要有一个察觉,可能其他地方也存在这样的问题。

    4.发现问题隐患的能力

    有些软件里边可能有一些操作模块,或者是代码写的接口,表面上没有什么问题,但是它是有隐患的,比如说这个接口写的不稳定,当他传的数据有一些问题的时候,可能它最后返回的结果就是报错就是报404或者报乱码。

    5.尽早发现问题的能力

    如果你只能停留在界面级别的话,那你根本就没有办法达到尽早发现问题的这个能力

    你必须要等到前端人员把每个界面都做好了之后才能进入测试,而我能比你早一个月进入测试了,然后我比你结束测试时间快一个月,而你又比我晚一个月,那么咱俩的薪资一下就拉开了

    6.发现问题根源的能力

    需要知道这个缺陷它到底是由什么原因产生的,是属于什么类型的缺陷,是ui前端人员做的问题,还是后台接口人员做的问题?

    不仅要找到这个bug,还要知道这个bug产生的原因,这样的测试人员是非常棒的,而且很是受人尊敬,提bug的方式也就不一样了

    三、团队协作能力

    1.合理进行人员分工

    合理的进行人员分工是提高效率的重要保证

    2.协助组员解决问题

    比如说测试在赶进度,或者这个软件项目的质量把控是一个团队来把控的,协助组员解决问题就显得尤为关键

    3.配合完成测试任务

    一个团队里边的人员分工,他们的任务都是不一样的,这就是咱们说的配合。你的东西做完了,要轮到我了,我的性能测完了之后该轮到你了,所以整个的一个流程下来之后,大家应该是各司其职,配合得非常紧密的一个过程

    4.配合开发重现缺陷

    我给你提bug,你改我的bug,咱们的目的只有一个,就是让这个软件变得更好,所以在这样的情况下,咱们就一定要配合开发

    5.督促项目整体进度

    既然是一个团队协作的过程,就一定要互相的去督促对方,包括督促开发去改bug,因为开发人员他们有时候工作很忙,他们不知道要先改哪些问题,要后改哪些问题,但是往往有一些缺陷,它影响了测试的这个时间,影响了测试的进度,那么这个时候就需要测试员去督促开发人员,让他尽快的去解决你棘手的问题。这个东西能够提高咱们的测试效率

    6.出现问题勇于承担

    愿意背锅的最后都成为了领导,不愿意背锅的最后依然是员工

    四、专业技术能力

    1.掌握测试基础知识

    基础知识就是根基,根基打好了,你才能够更有效地往后期发展,也就是为了以后的学习做一个铺垫。如果根基都没打好,功能测试不会,就想直接学性能,那性能是做不好的

    2.娴熟运用测试工具

    熟悉工具和熟练使用工具完全是两个概念,熟悉工具基本上等同于不会,遇到过很多简历上写会使用什么什么工具,都没有实际能力。比如loadrunner只会一个简单的录制,增强一下脚本,觉得会用了,那知识会用了1/5,其他4/5 都不会。

    3.了解工具操作原理

    它是怎么样给服务器发送请求的,是用什么样的方式去发送请的,是用什么样的方式去监控的,它的操作原理是什么样的,咱们要把这件事情搞清楚,这样的话能有助于更好的去使用这些东西。包括一些请求的协议,每个协议代表什么意思,它是用来干什么的。

    4.自主完成测试任务

    一定要能够自己完成一个独立的内容,独立的工作,这件事情领导你交给我好了,放心我能给你搞定,要的是这样的人

    5.找出问题出现原因

    找出缺陷的时候,不仅要看它的表面,还要看它的本质

    6.提供问题解决方案

    发现问题不是能力,发现问题并提出解决方案才是真的能力

    7.提供完整测试报告

    测试报告能够说明你表达的清不清楚?领导能不能看懂?还有就是能不能够把你整个测试的过程给它梳理得非常详细,人家能够通过你的报告,能够了解到整个的项目的情况,而不是只了解一个片面的情况

    8.了解相关技术领域

    触类旁通

    五、逻辑思考能力

    1.判断逻辑的正确性

    面试官也经常会给测试人去出一些逻辑题,逻辑题能够分析出来你这个人思维有没有?活跃不活跃?还有他的维度,包括他想的问题的全面性,都能够判断得出来。

    比如说去买一样商品,它的里边逻辑就会经常会出现很多问题,比如说它的会员的级别,什么样的级别去买什么样的商品,它的价格不一样,什么情况下会给优惠券,什么样的情况下不给优惠券?达到多少钱的情况下才能够使用优惠券?如果说这里边的逻辑出现了问题的话,那么整个的业务不用再测了

    2.对可行性逻辑分析

    要去测一个网站的逻辑的时候,一定要先思考这一个业务流程可能会涉及到哪些逻辑,这些逻辑哪些是可行的,有些是正向逻辑,有些是逆向逻辑,都要考虑全面,而不是说只是把正向的逻辑测试全面了,逆向逻辑不考虑。其实往往更容易出错的地方就是逆向逻辑

    3.思维导图梳理思路

    思维导图工具能够起到什么作用,能够让你更有效的进行测试,能够让你的思路更清晰

    4.站在客观角度思考

    去测试的时候,不要仅仅只是站在测试人员的角度上去对整个网站进行测试,还更多的要站在用户的角度,要替用户考虑

    六、问题解决能力

    1.技术上的问题

    把自己的个人能力提升起来,多跟别人虚心请教,多去自己想办法解决问题

    2.工作中的问题

    在任何的企业里边去工作,肯定会遇到一些工作当中的一些不愉快的事情,而不是什么事情都会让你很顺心。所以要去处理工作上的一些不顺心的事情,不要把它带到你的工作上,或者是你的生活上,尽可能的去跟别人沟通,去解决这个工作上遇到的麻烦

    3.同事间的问题

    在工作当中可能会涉及到跟开发人员的沟通,跟产品人员的沟通,跟ui人员的沟通,跟这三方的人员去沟通的时候,就要用不同的沟通方式

    4.领导层的问题

    如果你觉得你的领导不好,或者说你觉得对你的领导一些建议,不要的去跟同事之间去说他坏话或者怎么样的,领导需要的是解决问题的人,而不是制造问题的人

    七、沟通表达能力

    1.和技术人员的沟通

    跟开发人员阐述缺陷时要简洁明了、清晰易懂。当发现严重缺陷时,也不要大惊小怪,要站在开发人员的角度思考如何解决问题。而不是踩在开发头上,炫耀自己发现问题的能力。

    2.和产品人员的沟通

    当对产品提出意见时,要站在用户的角度去说明自己的想法,而不要主观认为不好而要求产品进行修改。

    3.和上级领导的沟通

    跟领导沟通时要有大局观,不能只考虑自己部门的情况。并且与领导沟通时,尽量直奔主题,不要拐弯抹角,当与领导意见不一致时,也不要直接反驳,应该先给予认可,再阐述自己的想法。

    4.在集体会议中沟通

    在集体会议中不要一味的突出自己的个人能力,不要当话痨,也不要默默无闻。适当的提出一些自己的见解,有助于让大家更加重视你的存在。切记不要在多人会议中,去指责别人和推卸问题。各个部门的同事,都要面子~

    5.与下级员工的沟通

    与下级沟通时不要摆高姿态,不要让下级产生畏惧感,应该更多的为下级解决问题。服务好部门的同事,才能更好的产生凝聚力。

    八、宏观把控能力

    1.有效控制测试时间

    测试周期的时间控制,应当采取多种方法去衡量,例如人员能力,人员数量,项目复杂程度,同类项目的测试经验等多方面去衡量。

    2.有效控制测试成本

    测试成本指的是人员成本跟时间成本,不要浪费每个人的时间跟劳动力,要让每个人充分发挥最大的价值。

    3.有效制定测试计划

    测试计划对于一个项目是核心关键,它的存在为了让测试进行中有依据可查。所以测试计划,一定要切合实际情况,要经过思考和衡量最后得出计划安排。

    4.有效控制组员情绪

    组员的情绪可以直接影响测试进度跟测试的质量,当有组员出现思想问题时,应当及时沟通,采取一些必要的措施去解决问题。而不能装看不见。

    5.有效进行风险评估

    任何项目在进行期间都存在许多潜在的风险,例如,人员离职,生病请假,业务变更,需求变更,服务器或其他组件故障等。应当提前做出相应的解决方案,以免到时候手忙脚乱。

    6.有效控制测试方向

    测试的方向是指测试的目标和测试的范围,很多项目的测试是有针对性的,例如性能测试,所以在测试中,一定要随时清楚测试的目标和目的是什么,以免把时间浪费在无关紧要的业务上。

    高级测试开发工程师需要具备的能力

    转自:https://blog.csdn.net/linsongbin1/article/details/52240449?utm_source=blogxgwz1

    熟悉本系统
    测试人员参与测试的系统的各种业务场景,必须做到精熟 。一旦需求有改动,可以清楚快速的知道上下文。同时可以清楚的知道哪些点是需要重点测试的。

    熟悉跟本系统有通讯的上下游系统业务
    跟本系统有通讯的上下游系统也要非常熟悉。这样一旦系统出现问题,可以知道影响的范围。

    熟悉公司主流程业务
    熟悉公司主流程业务。虽然不是自己测试的系统,但是熟悉公司主流程业务,可以让测试人员在考虑问题的时候,有更好更广的思路。

    逻辑思维好 气场也要好

    互联网应用一般是切分成多个子系统的,各个系统都有自己的业务范围,一个任务的完成,通常要有多个部门或者小组进行协作。这个时候,就不可避免的进行各种会议沟通,小组内的或者小组之间的。那么测试人员如果脑子不好使,不能快速的理解别人的意图和想法,会很容易被人忽悠或者陷入各种坑,到时候就会有无穷无尽的测试任务了。另外,当对方太强势的时候,测试人员不能太弱势,应该根据自己对业务和系统理解,提出自己的意见,该做的就做,不应该做的别硬塞过来。积极配合对方,但不是傻傻的啥都做。

    掌控系统上线排期

    如果开发任务非常的多,测试人员要测试的功能也就非常的多。这个时候,如果功能的上线时间都是由开发经理或者PMO等来定,那测试人员就只能进行无穷无尽的加班。这样是不行的。测试人员有自己专业,对业务精熟,必须清楚的知道哪些任务的优先级是高的,哪些是低的,将任务进行优先级排序。规定某个时间段里,就只能上多少个功能。测试小组能够承受的最大任务队列是多少,测试人员必须有个底。测试任务超过这个队列,可以根据优先级把部分任务挤出去。

    能编写覆盖关键路径的测试用例

    对业务需求准确的理解后,测试人员能根据业务需求,设计关键的测试用例,能够完整的覆盖业务关键路径和场景,保证只要这些重点用例能通过,就说明需求的重点功能已经OK了。重点功能OK了,就算立刻上线,如果出现问题,也只是小问题。当然能够用测试用例覆盖所有当然是最好的。

    定位问题的能力

    测试人员在测试系统的时候,不能一遇到问题,就马上找开发,自己必须深入思考一下,出现问题的可能原因,多找一些数据验证一下,最好能做到问题可重现。

    熟悉测试技术

    在测试互联网应用的时候,测试至少得掌握下面的技术和概念: 
    1. 懂得用jmeter进行性能测试; 
    2. 懂得搭建性能测试需要的环境,例如服务器、redis、memcache等等; 
    3. 懂得如何编写性能测试报告。例如至少包含接口响应时间、QPS、最佳并发数、CPU使用情况、内存情况、抖动、GC情况等等。 
    4. 懂得上下文切换、内存溢出、内存泄露、QPS、稳定性测试等等的概念。 
    5. 要懂得如何做线上UAT验证,尤其是那种需要多系统合作的项目,UAT是极其重要的步骤。

    约束开发人员,保证开发质量

    当开发提测代码的时候,测试人员应该具备下面的意识:

    让开发人员先把master分支的代码merge或者rebase到自己分支上,保证提测的时候,代码已经包含了master的代码,这样可以提前发现问题。
    代码功能测试完毕后,必须再做一次回归测试。这个时候必须强烈的约束开发人员,不许再提交代码了。除非是bug。不然的话,测试人员回归测试完后,开发人员跑来告诉测试说,代码有改动。这样的话,测试人员辛辛苦苦的回归测试就白测了,又得重新回归一次。
    测试人员必须回收master分支的代码提交权限,一旦开发者要提交代码,只能通过和测试沟通,说明代码做了什么改动。绝对不能让开发人员悄悄的提交代码,这种行为非常造成线上故障的。
    如果功能模块是跨系统的,也即是会调用另外一个系统的接口。这种的,测试人员一定要要求各个系统之间的开发必须做【开发联调】。测试人员必须强制要求开发做到这一点。不然到时候可能出现各种接口调用不通呀、接口入参出参理解错了呀,这样会及其严重的阻碍测试的进度。如果没做【开发联调】,测试人员是可以不测的,直接打回。


    要懂的写代码进行接口自动化测试

    现在微服务非常的流行,各大互联网公司都在搞微服务接口。针对微服务接口,测试人员一定要懂得编写代码去进行接口自动化测试。大家想想看,假设某系统有50个微服务接口,测试人员测试完一次后,开发人员修改了其中10个接口的代码,这个时候应该可以通过跑自动化case来验证这10个接口的改动有没有影响到其他40个接口。这种回归测试的效率非常的高。如果每次都得人工手动的进行接口回归测试,那测试人员就得累死了。
     

    展开全文
  • java开发转测试开发经历

    千次阅读 多人点赞 2021-02-08 14:25:11
    1、背景 我从毕业一直做java开发已经两年半了,到目前为止...3、为什么转测试开发 其实根据工作内容接触到财务知识,我最先考虑的是做会计,走财务审计方向。中间报班考证学习了一阵子,迷茫了起来,不是因为我发现自

    1、背景

    我从毕业一直做java开发已经两年半了,到目前为止也挺喜欢开发的。

    2、为什么想转行

    想转行是由多方面考虑的,一:我的开发技能没达标,只能找到外包里的开发工作

    二:开发前景对女生不够友好,难以获得认可(个人感受)

    至于第一点其实也可以在我辞职后补下开发技能找到非外包的开发工作,由于我之前的开发工作体验感很差很差,导致我已经不再想做开发了。

    3、为什么转测试开发

    其实根据工作内容接触到财务知识,我最先考虑的是做会计,走财务审计方向。中间报班考证学习了一阵子,迷茫了起来,不是因为我发现自己不喜欢财务了,是因为大学非财务专业现在想转行太难了,也没发现对财务行业的喜欢值得我去拼命转到这行业,这行业也没有值得我拼命转过去的优势。

    后面跟朋友聊天,想到了测试(之前不考虑这个因为我之前的工作经历对测试行业很有偏见),又根据自身的优劣势(包括性格),选择了测试开发行业。

    4、为转测试开发行业所做的准备

    一:网上找他人转测开行的经历,发现有个资料挺适合我了解测试-茹炳盛《软件测试52讲》,了解到测试所需要的软能力与发展前景和基础的测试知识。

    二:看招聘信息,总结测开需要的技能,列出学习计划

    三:根据学习计划,首先学习测试理论知识,买了本《软件测试的艺术》还未看完

    四:学了下当前流行的测试框架原理与基础应用

    五:复习java基础知识

    5、面试经历

    一、面试简历,我写的是开发经历,技能那里加了新学的测试技能

    二、面试时面试官问的最多的问题:

    你为什么从开发转测试

    你上家公司为什么只工作了两个月

    说下你的项目,你在里面负责的部分(由此会问对应的开发知识),遇到一个问题你说怎么解决的

    java基础知识的提问

    测试基础知识的提问(问的最多的是测试方法)

    给你出个场景题,你怎么设计测试用例

    6、面试感受

    对于开发刚转测试的,我觉得最重要的是突出自己开发技能(优势),所以开发知识一定要牢固;而测试技能就算再事后学习,由于没有工作经历,其实对他们来说你这方面也是你的弱势。说这两句话不是说不需要学习测试知识了,毕竟转的是测试行业,还是需要有些专业度的。学习测试最重要的是学习测试的思想,可以多看下别人的测试用例怎么写的,多看点关于这方面的书籍。个人建议准备好再去投简历找工作,因为当你在各种招聘软件上做好简历后,你会收到各种招聘沟通,近期的面试机会会很多,前期准备充足,防止丢失机会。

    结果:我找到了一个相对来说我挺满意的公司,我喜欢那里的公司文化和工作环境,工作内容也符合我想找的,工资不太高不过对于转行的来说还行吧。

    7、个人感受

    对于开发行业,我依旧遗憾又不甘的,每次看到别的女性开发,我都好羡慕。但我不想在做那一行了,自我安慰测开也会有开发呢,而且我私下可以自学开发技能呀这样会增强我测开的优势。自我安慰完依旧有些羡慕,我问过自己若是现在有份开发的工作,公司还行,我会去做么?我应该不会吧(毕竟离职后提高下开发技能可以实现这个呢),测开更适合我,我的软能力能帮我做的更好(工作时我已做到不会纠结开发行业,专心做测试)。

    目前在努力的学习测试实战,遇到的有关技术方面的,会有开发基本和测试行业都会用的,我会努力私下学习这些。

    好好学习,天天向上,坚持就是胜利!

    加油!

     

    展开全文
  • 分享一份适合练手的软件测试实战项目

    万次阅读 多人点赞 2020-11-21 19:28:50
    最近,不少读者托我找一个能实际练手的测试项目。开始,我觉得这是很简单的一件事,但当我付诸行动时,却发现,要找到一个对新手友好的练手项目,着实困难。 我翻了不下一百个web网页,包括之前推荐练手的政府网站...
  • 测试开发成长学习路线--实践篇

    万次阅读 多人点赞 2018-06-22 00:43:39
    现在,事实是,我现在就干着一份测试开发或者开发测试的工作,而且是高级岗位。我们的实践之路或者学习路线不一定都适合每个人,这里只是我个人的一些分享。1.目前的状态 差不多坚持学习了两年,说实话,学习了一部....
  • 软件测试面试题(面试前准备篇)

    万次阅读 多人点赞 2019-09-27 10:42:37
    目录 一、问题预测 让简单介绍下自己(每次面试开场) 让说下自己会的内容 看了哪些书籍(有问到) ...了解过哪些技术博客/论坛(有问到) ...是否了解软件测试需要掌握哪些知识...二、介绍一下公司项目 三、技能...
  • 测试岗/测试开发岗面经合集

    万次阅读 多人点赞 2019-08-17 16:04:21
    目录测试岗/测试开发岗面经一面(30min-1h)二面/三面(不一定有)(30min-1h)HR面(30-45min)测试岗/测试开发岗面试真题自我介绍项目/实习介绍计算机网络Linux命令数据库与SQL手写SQLC++/Java/PythonC++Python...
  • 大家知道,测试开发或者开发测试范围很大,一个人的精力和你当前的项目经历,决定了你属于某一个领域的具体的测试开发的工作。在这里,我不纠结测试开发和开发测试有何不同,有一个叫法罢了。今天这里要讨论的是如何...
  • 微信小程序测试方案

    千次阅读 2019-05-19 15:13:42
    小程序架构 小程序主要分为两个主要的部分:view模块和service模块。view模块负责UI展示,它由wxml和wxss转换...小程序主要分为三个版本类型:开发版、体验版、正式版。开发板和体验版无需审核,需要给微信号配置权...
  • 软件测试工程师经典面试题

    万次阅读 多人点赞 2018-10-27 23:55:52
      软件测试工程师,和开发工程师相比起来,虽然前期可能不会太深,但是涉及的面还是比较广的。前期面试实习生或者一年左右的岗位,问的也主要是一些基础性的问题比较多。涉及的知识主要有MySQL数据库的使用、Linux...
  • 软件测试入门视频教程

    万人学习 2015-01-22 16:21:44
    软件测试入门视频培训教程:该课程将带你走进“软件测试”的大门,具体内容包括软件测试环境搭建、软件开发模型、产品模型、CMM模型、测试用例、等价类划分、边界值划分、白盒测试、单元测试、bugfree搭建、系统测试...
  • 初级测试开发工程师应该学些什么

    千次阅读 多人点赞 2019-02-27 21:07:11
    作为一个毕业半年的我来说,换了两份工作,现在在游戏公司做测试开发工程师,也就不到两个月吧。之前在学校学了C/C++,数据结构,算法设计等,但也只是考试过了,还是菜鸟一枚。然后来到公司,有做一些兼容性测试之类...
  • 前端项目开发流程

    千次阅读 2017-06-26 11:13:21
    前端的开发过程中主要有以下流程: 编写代码->单元测试->检查语法->整合代码->生成文档->压缩代码->部署测试环境->测试->发布。 产品最终的结果是原型图,而原型图可以理解为设计的草图 设计师的结果是psd文件,他...
  • 阿里测试开发实习生面经

    千次阅读 2018-04-19 19:21:47
    一面: 之前同学内推了阿里的测试开发岗位,也许由于内推时部门写的是阿里集团,所以隔了一个月才接到阿里的面试。因为不在杭州,所以方式是电面。 先是一位小姐姐打电话来约面试时间,说话非常的温柔,态度也特别...
  • 一个完美的开发过程是这样的:测试先行,开发人员会些设计一些边界场景的测试用例,比如数据的取值范围从极大到极小、循环语句超出限制范围等等许多极端情况。这些测试代码会作为产品代码的一部分,以自检代码或者...
  • 软件测试简历,这一点你是否漏掉

    万次阅读 多人点赞 2017-11-29 21:04:11
    几乎所有的测试简历都在长篇大论谈如何做测试,参加过多少项目测试测试过程是怎么样的,测试如何管理,会黑盒、白盒、灰盒、彩盒.....、会写方案、测试用例。从这些内容中我无法看出你会什么,技术上哪些是你的...
  • 字节跳动测试开发工程师面试经验

    千次阅读 2020-07-03 00:56:38
    面试岗位:客户端测试开发工程师 这已经是第五次面字节跳动了,哎,不堪回首,前四次太久远除了单链表的逆序以外没记得别的了~ 1.自我介绍 2.项目流程 3.详述之前负责过的模块,测试难点在哪 4.除了功能测试在项目...
  • 《软件自动化测试开发》认真看过的读者应该都知道,介绍的主要是自动化测试基础以自动化测试框架为主线,同时附带提到了自动化平台的功能。 第一本书是偏向于Java语言开发。   然后   第二本书,第一本...
  • 软件测试项目实战

    万次阅读 多人点赞 2018-11-08 16:18:26
    【软件测试项目实战】   目录 : 一、项目职责与分工 二、项目立项 三、测试流程 四、测试人员主要工作 五、小结   一、项目职责与分工: 1、产品经理 ------> 负责设计产品的原型图和PRD。 ...
  • 游戏测试一年半总结

    万次阅读 2018-10-13 20:11:20
    2015.06毕业后在一家做移动APP的项目里担任软件测试工程师。前期一年工作学习都在有序的进行,对于老板的每次画饼都听的津津有味。项目在后期一个功能需求提出都耗时一两个月,工作生活太过于平静,上班等下班,爱...
  • 什么是测试开发工程师?

    千次阅读 2019-11-22 07:30:00
    什么是测试开发工程师?测试开发工程师 (Software Development Engineer in Test,简称SDET)是指那些既可以称作是开发人员,同时也负责...
  • 2019年互联网企业软件测试面试题(常考)

    万次阅读 多人点赞 2019-04-22 09:32:26
    很多软件测试工程师在面试互联网企业的时候都会遇到考官给的几道面试题,这也反应了测试工程师对企业的重要性,今天传智播客整理了一份2019年的互联网企业软件测试面试题,希望能帮助到大家。 2019年互联网企业软件...
  • 接口测试工具Postman接口测试图文教程

    万次阅读 多人点赞 2018-07-11 13:10:03
    市场上有很多优秀的,完善的接口测试工具,比如SoapUI,Postman等,能够高效的帮助后端开发人员独立进行接口测试。这里使用Postman接口测试工具,此处以请求方式为POST的userLogin登录接口为例。
  • ...amp;...作为一名深爱测试开发工程师岗位的QA,本文总结了我在百度做测试的近两年的一些经验和对测试开发这一岗位的理解,以及如何有针对性的达到BAT对测试开发工程师的岗位要求。希望本文能让大...
  • 软件项目测试流程的规划

    千次阅读 2018-06-09 16:41:50
    前言软件测试是在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程测试项目的启动、规划以及测试项目需求分析往往是很多软件服务型企业的薄弱环节所在。软件测试...
  • 【软件测试】面试中介绍项目你该这么说!

    千次阅读 多人点赞 2020-10-16 09:00:00
    黑马程序员视频库播妞微信号:heiniu526传智播客旗下互联网资讯、学习资源免费分享平台测试人员在找工作的过程中,通常有一个问题是很难绕开的。就是要如何向别人介绍自己之前做过的项目。下...
  • 一系列自动化测试的开源项目介绍

    万次阅读 多人点赞 2018-11-21 14:14:22
    本文针对性能测试、Web UI 测试、API 测试、数据库测试、接口测试、单元测试等方面,为大家整理了github或码云上优秀的自动化测试开源项目,希望能给大家带来一点帮助。 一、性能自动化测试 1、项目名称:基于...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,142,592
精华内容 457,036
关键字:

测试开发项目