测试开发_测试开发面经 - CSDN
精华内容
参与话题
  • 测试开发需要学习的知识结构

    千次阅读 2019-04-01 16:49:25
    努力成为一个优秀的测试开发从业者,加油!!!       一些视频链接:我这有一些软件测试的视频,你可以点开看看。转行互联网测试需要哪些技能? - 假装在测试的回答 - 知乎作为一名软件...

    转载:https://blog.csdn.net/sinat_21026543/article/details/79909062

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

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


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

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

    白盒与黑盒测试什么区分

    1、黑盒测试


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

    2、白盒测试

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

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

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

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

    b黑盒测试技术( 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 更是需要这方面的测试,在外国有一种专门干这一行的人叫安全顾问,可以审核代码,提出安全建议,出现紧急事件时的处理办法等,在国内没有听说哪里有专门搞安全技术测试的内容。

    黑盒测试: 

      · 等价类划分方法
      · 边界值分析
      · 错误推测
      · 因果图方法
      · 判定表驱动分析方法
      · 正交实验设计方法:取正交的测试用例组合
      · 功能图分析方法
    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)至少经历一次

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

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

      例如:

      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)分支覆盖又称判定覆盖:使得程序中每个判断的取真分支和取假分支至少经历一次,即判断的真假均曾被满足。上例需要设计测试用例使其分别满足下列条件即可(1A=trueB=trueCtrueD=false2A=trueB=falseCfalseD=false

    3)条件覆盖:要使得每个判断中的每个条件的可能取值至少满足一次。上例中第一个判断应考虑到A=trueA=falseB=trueB=false第二个判断应考虑到CtrueCfalseD=trueD=false,所以上例中可以设计测试用例满足下列条件(1A=trueB=trueCtrueD=true2A=falseB=falseCfalseD=false

    4 路径覆盖:要求覆盖程序中所有可能的路径。所以可以设计测试用例满足下列条件(1A=trueB=trueCtrueD=true2A=falseB=falseCfalseD=false3A=trueB=trueCfalseD=false4A=falseB=falseCtrueD=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.有效控制测试方向

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

    展开全文
  • [心得] 测试开发工程师成长之路

    万次阅读 多人点赞 2016-10-19 23:57:08
    随着测试在软件开发周期中越来越受到重视,BAT大部分开始取消了测试工程师职位,全部变成了测试开发职位。需要在具有测试能力的基础上兼备开发能力;另一方面自动化测试成为趋势,利用开发的技巧解决测试中的问题以...

    不懂业务基础,做手动测试就是瞎做。自动化测试也是如此。

    随着测试在软件开发周期中越来越受到重视,BAT大部分开始取消了测试工程师职位,全部变成了测试开发职位。需要在具有测试能力的基础上兼备开发能力;另一方面自动化测试成为趋势,利用开发的技巧解决测试中的问题以提高测试效率,降低QA与RD的人力比。

    潜意识里面测试的技术含量没有开发高。客观地说,在软件编码方面测试开发的技术含量确实不如纯正的开发职位,更不用说测试职位了。如果希望在测试的职业生涯上有所发展的人,先参与几年的研发工作,毕竟那才是软件工程中的主体,然后在开发过程中培养测试意识,这也是程序员的职业素养。现在许多测试理论,无论白盒测试还是黑盒测试,无论单元测试、集成测试还是系统测试,大部分的方法论都是开发人员提出来的。再一次证明,不参与软件主体的研发工作是不可能深入理解测试的。

    测试开发工程在公司一般有两种,一种是单纯为测试团队开发测试工具或者系统。另一种就是在测试过程中发挥主观能动,利用自动化把重复劳动降至最低,比如开发适用于特定场景的测试工具、测试脚本和测试用例。

    测试可以涵盖的方面很多,但人的精力毕竟有限,测试开发工程师也必须拥有自己的核心竞争力,选定一个方向是个不错的做法,致力成为某方面的专家,比如单元测试(不要认为是开发人员做的,很多开发人员没有单测意识和技巧)、性能测试、安全测试。

    测试开发工程师需要培养自己的大局观,这个是在职业过程中有意培养的,公司现阶段的任务是什么?侧重点是什么?在大公司需要顺势而为,QA的本职工作是保证质量,需要借助与流程、工具和其他外部资源,所以在工作的时候尽量与大方向契合。比如公司去年是QA内部水平提高的一年,需要QA具备单元测试、Code Review方面的能力,今年是保证质量的前提下,提高软件发布周期,主推持续集成。

    2V(Validation和Verification)是QA的基本职责,即保证两点:Validation,软件按照既定的需求开发,没有偏离产品方向;Verification,软件在满足需求的基础上保证其正确性,从功能、性能、安全等各个方面验证。

    软件背后是人,是PM制定的需求,是RD进行开发的, 那测试背后实际上测的是人而不是软件。人总是可能存在思维漏洞的,人总是可能犯错误的,所以永远会有bug,但有些人心细,有些人负责,自己开发完后会自己进行单测、功能测试,以致后续能发现他的bug已经很少了。

    无论在大公司还是小公司,大家都有压力,都要发展,心态就很重要了,以创业者而不是打工者的心态来工作看待很多问题就截然不同了。

    自动化测试的技能塔:
    核心驱动是创新意识
    平台架构能力是调试能力,框架设计能力和设计模式
    再下一层是代码,数据结构和算法基础
    再下一层是测试能力,设计,执行,流程和业务
    最底下一层是细心,责任心,沟通和学习能力

    学过的东西或解决过的问题,要善于经常性地把它总结和记录下来,否则时间久了就忘了。

    高质量的自动化测试脚本所必备的能力。
    良好的代码功底、数据结构和算法,可以开发出高质量的自动化脚本,这会极大地减少后期自动化脚本的维护成本。

    roadmap:
    应届工作3年:打测试基础,学脚本编程
    换1份工作坚持2年:中级升级到高级的关键时期
    再换1份工作坚持3年:解决更难问题
    再换1份工作坚持3年:深入钻研技术

    也就是10年磨一剑,养成一个牛X的测试开发工程师。

    展开全文
  • 我是如何从测试开发做到年薪百万的

    万次阅读 多人点赞 2018-01-18 08:26:32
    2017年的结束,意味着我...从“程序员”转变成“程序员猎头”8年前我还是一个在望京索尼爱立信(简称索爱)的测试开发工程师。从测试开发工程师转行为IT猎头,这事说来有点偶然。刚毕业3年的我,参加2010年华中科技大
        

    2017年的结束,意味着我从事猎头的工作已经有8年了。在过去的三年里,有超过200万的个人业绩,成为公司100多名猎头顾问中的Top Billers (业绩最好的顾问)之一,而我个人的年收入也连续三年达到了100万。

    从“程序员”转变成“程序员猎头”

    8年前我还是一个在望京索尼爱立信(简称索爱)的测试开发工程师。


    从测试开发工程师转行为IT猎头,这事说来有点偶然。刚毕业3年的我,参加2010年华中科技大学北京校友会的活动,我认识了能源学院毕业的师兄J,他创建了一家猎头公司,专门为IT互联网企业提供专业人才、中高级人才“寻聘服务”(俗称猎头)。在聊天中,谈到我在索尼爱立信公司以及从事测试开发工作,也谈到了手机行业的变化,测试开发工作的“无聊”,以及我对未来的迷茫。J师兄建议我到他猎头公司去做“顾问” (就是帮助各IT、互联网客户公司招聘人才)。 他说有计算机专业知识转行做IT猎头、服务程序员,这种转变的跨度也不算大,如果爱上了这门工作,业绩应该会比一般文理科毕业更容易取得好业绩,他还说了什么猎头是一个终身职业等等。


    就这样,我从工作了18个月左右的索爱离职,糊里糊涂地加入了J师兄的猎头公司,上班地点由望京转去了世贸天阶。


    640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1


    刚开始做猎头还是有一些不习惯的,需要每天从公司人才数据库里头找人、当然也会在社交网络上去找人,向这些潜在候选人打电话,告诉他们什么公司需要什么样的人,薪水很高、可以增长30-50%,公司很牛拿C轮融资什么的。每天需要打很多电话,并且经常会被程序员们鄙视......“你是猎头啊,对不起,没空!” 。电话的秒挂率很高,公司会有一些资深的顾问对我们传帮带,教我们如何“基于价值思考”, “如何结构化沟通”,“如何捕捉程序员的职业想法” 等等。


    慢慢地,我掌握了一些向程序员推荐职业机会的技巧,如何抓住程序员的一些真实想法,在理解程序员的内心想法方面我要比一般的同事好,因为我之前就是程序媛,有时在电话沟通中我也直接告诉他们我曾经也是程序员,这增加不少亲和感,有共同语言。

    2010年是我入行第一年,当年我完成了8个offers (推荐的人才有8个人被客户录用、入职),取得了46.8万的个人业绩(公司过往几年,新顾问首年平均业绩只有26万),2010年我的个人收入也达到了19.8万,这比我在索尼爱立信的16万还是多了好几万。猎头顾问的收入构成一般是基本工资加业绩提成,业绩提成大约占50%左右。

    移动互联、人工智能是中国程序员薪资集体飞跃的两个分水岭


    从2010年开始,外资企业在IT人才吸引力方面有明显滑落,雇主吸引力转向了本土的互联网公司,人才需求也转向了移动开发(android,iOS),以及新型的前端开发,当然JAVA语言开发一直长盛不衰。


    2012年开始,移动人才简直是“争夺战”。到了2013年、2014年,3~4年移动开发经验的工程师薪水很快冲到了24k/月平均线。“移动互联”是中国程序员薪水整体跃升的第一个分水岭,2012年之前程序的工资大部分在15~18k的区间内,经历了“移动互联”及后来的“大众创业”淘金期,中国程序员的工资很快进入了22~26k的主体区间。


    很显然中国程序员的第二次跃升机会来了,这次跃升依赖于“人工智能”,现在3~4年工作经验,与AI沾边的程序员薪水基本上都在30-35K的区间。

    640?wx_fmt=jpeg


    这就是做IT互联网猎头的趣味性。以前我做测试开发,每天的工作就写写代码、指导测试,与其他工程师,产品经理扯扯,这样过日子。朝九晚五(当然很多同胞996),几乎没有时间与精力,也没有兴趣关注行业的一些动态。做猎头,你需要关注这些新事物。时刻关注着市场有哪些公司能够成为“独角兽”,并把它们发展成为公司客户。


    “独角兽”公司的猎头招聘很好做,为什么?

    1. 知名度在资本以及“风口”下一名度急剧拉升,大家都知道;

    2. 资本驱动下疯狂烧钱,很有钱给offer大方(与BAT抢人才)。


    因此猎头一般都很喜欢做“独角兽”的招聘生意,然而并不是等一家公司成为独角兽,你才去把它发展为客户,作为顾问你或多或少要有一些“ 慧眼”。


    2013年我把滴滴发展成为客户,在2013-2015年,累计帮助滴滴(及快的)招募了80-90人,为公司取得了几百万业绩。2015年,在我进入公司的第五年,被提拔为猎头经理,公司为我组建一个团队,让我带领6-7名猎头顾问。


    管理,在很大程度上考验一个管理者对“时间使用价值”的态度


    在2015年,我被提拔为MC (Managing Consultant,咨询经理),我开始带领6-7名猎头顾问,我需要在处理自己业务与管理一个团队之间不断平衡。一开始,我扮演这个角色并不太成功,我的手下隔年留存率不高(说明他们的个人发展、业绩以及收入诉求等没有达到个人期望),新同事的平均业绩也不高。我发现之所以我的团队管理得不好的根本原因在于我的时间分配不太合适,在2015年那会儿,几乎75%的时间在处理个人的业务,在团队成员技能发展、团队业务管理等方面时间投入不够。从2016年开始重视团队成员的管理,我与公司管理层一起摸索出一套管理方法。

    640?wx_fmt=jpeg


    由于长期招募互联网人才,接触了很多互联网技术、产品与运营等各方面的专家,或多或少受到了一些互联网思维的影响,我们开始对猎头顾问进行“画像”,对每一个顾问从以下四个维度:敬业度(engagement), 效率(efficiency ),流程(process ),表现(performance)四个维度进行度量,采集日常业务行为数据,对顾问的“输出能力”进行简单建模,我的注意力也在关注团队成员的EEPP,不断地提升他们在这四个方面的表现,现在基本上能够做到“基于数据洞察”团队成员的业务技能、以及拟定靠谱的下属成员业绩输出能力发展的路径。


    不是说做猎头久成不可管理者,在每一个领域都会有机会从“业务专家” 转向“管理者”的机会与必要性,任何企业运作管理都需要管理和领导力,像我老板一样,领导着一个200多人的猎头公司,这对他的领导力是有很高要求的!管理做得好不好,关键还是你对管理花费时间的意愿,很多人认为短时间内没有产出,不愿意花时间“管理”,因此团队久带不好。

    “程序员的背景”让我变得更专业!


    随着公司规模不断地发展壮大,建立一套体系化的知识用来培训初级猎头顾问变得非常必要。在2017年,公司指派我负责建立“互联网职位知识库”的项目。我在csdn等社区上搜索一些知识,开始对互联网的典型职位,包括前端、后台、架构、移动、测试开发,运维基运维开发,安全、产品等各职位建立了“知识图谱” (也就是每个职位关键技术需求集),反复对非计算机专业毕业的猎头顾问(大多数是文理科)尽心个培训,让他们基本上能看得懂职位描述,以及人才的简历,这对提高我公司的猎头顾问整体水平起到了很大作用!

    8年工作经验的二线本科,如何拿到华为18级 offer ?


    我在猎头圈内一个朋友,也是计算机相关专业毕业的,毕业后做了3年JAVA开发。由于是二线本科,在跳槽时经常收到“鄙视”。很多一线互联网公司(更不用说BAT),对程序员的基本要求就是“985,211, 硕士优先,ACM啥啥的成绩…” 二线本科在互联网行业的做程序员,那也是鄙视链中的“底层”,正儿八经的“码农”。即是“混进”了华为这样的大公司,也许十年八年也就是15、16级别。


    我的这位朋友在求职过程中屡遭鄙视之后,也是一次偶然机会“转行”成为了互联网IT猎头顾问,他比我还厉害,经常每年业绩超过300万,每年都要帮助BAT这样剧透搞掂好几个p9, t4级别的大牛。于是2016年,他从一家外企猎头企业跳槽到华为并拿到了18级的offer, 成为“高招组”(高端人才招聘组)成员。

    640?wx_fmt=jpeg


    互联网人才竞争非常激烈,猎头服务满足不了企业效率需求,很多一线互联网公司都组建自己内部“高招组”,这些人都是有几年猎头公司经验。据我了解,腾讯,华为,美团,头条这些公司都有很多招聘经理矮子猎头行业,他们的级别于薪酬也不低。某家互联网公司“高招组”组长年薪酬在200万左右。

    或许你也可以成为一个牛逼“程序员猎头”!

    作者:杜丽丽,科锐福克斯人才顾问有限公司。

    电子邮件:68730560@qq.com,欢迎加入猎头行业。

    展开全文
  • 我在这篇文章里也讲过,测试开发的关键字是效率。 对于测试开发人员,我的理解是:这个岗位的核心职能还是测试,是通过开发的手段提升测试的效率。这里有个前提,也就是在保障质量的前提下。 如果测试开发的核心...

    我在这篇文章里也讲过,测试开发的关键字是效率

    对于测试开发人员,我的理解是:这个岗位的核心职能还是测试,是通过开发的手段提升测试的效率。这里有个前提,也就是在保障质量的前提下。

    如果测试开发的核心职能是测试,那么测试开发岗位实际上是传统手工测试职位的加强版。

    如果一个团队的手工测试人员比较多,那么会造成下面一些问题

    • 会有人质疑技术含量是不是不够高,从而导致团队规模过大

    • 只能通过增加人力资源的方式来提高生产力

    • 团队的工作与测试外包团队几乎相同,并非不可替代

    • 更高层的管理者看不到这个团队的潜力,这个可能会被定位成是工具,在做战略收缩的时候会被优先考虑

    如果测试团队中有一些部分成员能做一些测试开发的工作,比如通过自动化方式去提升测试效率,通过监控平台的方式去监控线上的问题,那么对于整个测试团队来说,是有很积极的影响的

    • 可以通过技术的提升和积累来提高生产力

    • 生产力的提升可以减少团队的规模

    • 跟外包团队比起来,拥有一些不错测试开发能力的测试团队还是有一定的竞争力的

    • 更高层的管理者可以看到这个团队的潜力,通过对测试技术的钻研和积累,每个团队成员都能或多或少得到提升,从而整个团队也就相应的增值了

    现在我们回到问题:为什么现在那么多公司都要招聘测试开发?

    我想大概这应该是格局更高一点的测试管理者通过招聘加速其团队转型,从而导致测试开发的需求量增加的结果吧。

    转自:http://www.cnblogs.com/nbkhic/p/7093685.html

    展开全文
  • 投一大波简历,自己依旧懵懵懂懂,尽管我投的是C++开发工程师,但是总有人想把朕转到测试开发岗,我也不能像个小白一样傻不拉几就同意啊,于是,查啊查,总算对这些岗位有个初步了解。 1、开发工程师 顾名思义就是...
  • 测试自动化平台 | 测试开发工程师的进阶之路

    万次阅读 多人点赞 2018-05-24 10:23:44
    https://mp.weixin.qq.com/s/WU5h8FW6BT5YZtlsSuCIcw「摘要」随着...本文将概述测试工程师的现状及发展方向,并着重介绍测试开发工程师的发展及所需具备的技能,以及本部门搭建的测试平台的概况和意义。一、测试工程...
  • 什么是测试开发

    2019-06-22 11:02:47
    aaa 转载于:https://www.cnblogs.com/Chamberlain/p/10730856.html
  • 测试开发工程师常见面试题

    千次阅读 2019-01-18 10:49:18
    功能测试用例的设计 举例: (一).我想要回家,让你给我买一张票,然后设计测试用例 答案: 1.确定需求(回家回哪,需要什么票,买什么时候的票) 2.开始测试 2.1功能测试(我去买票(买火车票,飞机票),买到...
  • 开发环境、测试环境、生产环境 -- 区别

    万次阅读 多人点赞 2020-08-05 09:18:57
    开发环境(development):开发环境是程序猿们专门用于开发的服务器,配置可以比较随意, 为了开发调试方便,一般打开全部错误报告。(程序员接到需求后,开始写代码,开发,运行程序,看看程序有没有达到预期的功能...
  • 再谈开发人员和测试人员的比例

    万次阅读 热门讨论 2010-11-19 21:00:00
    软件企业中开发人员和测试人员的比例往往是管理者关注的一个问题,也可能是下面测试经理头疼的问题,似乎没有人知道什么样的比例是合适的。幸好,倒是有个学者做个这方面的调查得到一些数据,可以供那些对此感兴趣的...
  • 开发环境就是每个开发人员电脑上的开发环境,只有开发人员可以配置和开发,写数据测试放在测试环境) 2.测试环境:新开发和配置通过系统传输到测试环境,进行功能测试,可以创建数据。(开发人员开发完上传到 SVN...
  • 在一些软件大会上,人们常常会问这样一个问题:测试人员与开发人员的比例究竟多少是合理的?而这样的问题,很难直接给出一个答案。为什么会有这样的问题,可能来自于两方面的压力:许多公司领导总是希望得到一个合理...
  • 微信公众号开发测试帐号

    万次阅读 2018-01-10 10:33:01
    扫描关注后登录 ...填写JS接口安全域名 ,设置JS接口安全域后,通过关注该测试号,开发者即可在该域名下调用微信开放的JS接口,请阅读微信JSSDK开发文档。 注意:不知道啥原因,用自己的帐号申请测试
  • 浅谈TDD、BDD与ATDD软件开发

    万次阅读 2014-03-25 09:16:21
    测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行...
  • 问题: 第一次开发小程序...小程序开发官方文档提供了详细的教程,链接:小程序开发官方文档 二 小程序的限制 使用官方的开发工具 点击下载 配置合法的域名,需要https协议(测试的情况不需要) 三 配置本地开...
  • 开发环境、测试环境、生产环境 到底是什么?

    万次阅读 多人点赞 2019-02-20 14:08:19
    开发环境:开发环境是程序猿们专门用于开发的服务器,配置可以比较随意, 为了开发调试方便,一般打开全部错误报告。 测试环境:一般是克隆一份生产环境的配置,一个程序在测试环境工作不正常,那么肯定不能把它...
  • 软件测试模型——V模型 & W模型

    万次阅读 2018-08-19 15:53:45
    以“编码”为黄金分割线,将整个过程分为开发测试,并且开发测试之间是串行的关系 单元测试和集成测试:是测试程序的执行能否满足软件设计的需求 系统测试:是检测系统的功能、质量、性能能否满足系统的要求...
  • 敏捷开发流程总结

    万次阅读 多人点赞 2010-07-20 15:36:00
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以...
  • 测试开发工程师常见面试题(随时更新)

    万次阅读 多人点赞 2018-08-10 18:51:19
    功能测试用例的设计 举例: (一).我想要回家,让你给我买一张票,然后设计测试用例 答案: 1.确定需求(回家回哪,需要什么票,买什么时候的票) 2.开始测试 2.1功能测试(我去买票(买火车票,飞机票),买到...
  • 开发环境:开发环境是程序猿们专门用于开发的服务器,配置可以比较随意,为了开发调试方便,一般打开全部错误报告。 测试环境:一般是克隆一份生产环境的配置,一个程序在测试环境工作不正常,那么肯定不能把它...
1 2 3 4 5 ... 20
收藏数 1,804,474
精华内容 721,789
关键字:

测试开发