拿到需求文档之后要进行需求分析,之后会召开需求评审会议,评审通过后,开发按照需求文档进行软件设计和编码,测试组长或主管按照需求文档制定测试计划,组员按照计划分配的任务模块编写测试用例,待开发提测后,进行冒烟测试,测试不通过打回给开发重新编码重新提测,通过后开始执行用例,执行过程中如果发现bug,要分析定位,跟踪bug的处理,测试完成后出具测试报告,由业务进行验收测试,验收通过等待产品发布上线。
思想原理:按照测试流程的5个阶段来讲的,即:需求分析阶段、软件测试计划的制定、测试用例的设计阶段、用例执行阶段、测试报告
最常使用的测试用例设计方法包括等价类划分法、边界值分析方法、场景法、错误推测法。
其中,最容易发现错误的是边界值法,使用最多的是场景法。以注册为例:首先从需求确定用户名和密码的长度类型约束,根据需求写测试点,然后设计测试数据,编写测试用例。
1.用例的必要元素要完整,比如编号、标题、前置条件、操作步骤、预期结果、实际结果、优先级
2.要结合测试用例的设计方法充分考虑合法不合法的输入以及边界条件,即使用等价类、边界值、场景法、错误推断法。
3.在编写测试用例时要保证所有的用例100%的覆盖到需求文档,同时尽量保证测试用例单个覆盖最小化原则,也就是说不能出现一个测试用例对应多个测试点的情况,另外还要对测试用例进行维护和更新,写测试用例的时候保证语言表达简单清晰明了,方便他人执行,
软件测试的目的是尽可能少的时间内找到尽可能多的缺陷,保障软件的质量。其实,软件测试是确认所测软件的功能是否满足软件需求规格书提及的,是否按照规格书所要求的那样正常实现。同时,软件测试是测试人员在测试过程中向开发反馈对软件的质量,让开发人员对BUG进行修复,而且软件测试过程中发现许多缺陷的话,表明这个软件的开发过程有问题,需改正开发过程。
测试计划包括引言、测试基本内容(测试目的、测试范围、测试环境、测试工具、测试人员)、实施计划(任务分配、进度安排)、风险控制、测试要输出的工件/文档、需求上线的标准等。
测试报告包括:引言、测试基本内容(测试目的、测试范围、测试环境、测试工具、测试人员)、测试结果(用例执行量、用例通过量、Bug量和bug解决量)及缺陷分析(不同严重程度的bug量有多少,产生的原因是什么,后续如何规避)、测试结论和建议,交付文档。
交付文档有测试用例、提交的 bug报告、测试报告、测试计划方案。
测试报告的侧重点是测试结果和缺陷分析,测试结论。
一条 bug 信息至少需要以下几条:
bug 标题;bug 产生的模块;bug 对应的版本;bug 严重级别;优先级;bug 详细现象描述,包括 bug 出现的操作步骤,报错日志信息、bug 截图等等。
提交高质量的软件缺陷记录需要做到以下几点:
1.严格按照测试流程执行测试:参考需求以及详细设计等前期文档设计出高效的测试用例,然后严格执行测试用例,对发现的问题要充分确认肯定,然后再向外发布。(排出缺陷不是网络或环境问题等主观因素造成的)
2.规范提交 Bug:注重唯一性,一个 bug 说明一个问题或者说明一类问题可重现。
3.提交 Bug 注意准确性:提供这个 bug 的精确步骤,要让开发人员容易看懂一致(要注意bug标题中要包含关键步骤和具体现象);Bug 描述及所有信息要前后一致,不可有歧义完整性。
4.明确指明缺陷严重等级和优先级:明确严重等级和优先等级之间的差别,优先解决优先级高的问题。
5.Bug 附录:能附带 bug 现象截图的就带截图,有报错日志的就贴上日志信息客观性。
6.不可重现的缺陷也要记录:首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现,若尽力之后仍不能重现,仍然要报告此缺陷,但在报告中要注明无法再现,缺陷出现的频率。
7.明确指明缺陷类型:根据缺陷的现象,总结判断缺陷的类型。如,功能缺陷、界面缺陷、数据缺陷,合理化建议这是最常见的缺陷或缺陷类型,其他形式的缺陷或缺陷也从属于其中某种形式。
按照开发阶段划分,软件测试可以分为单元测试、集成测试、系统测试和验收测试;
1.单元测试:针对每个单元的测试,以及确保每个模块能正常工作为目标;
2.集成测试:对已测试过的模块进行组装,进行集成测试,目的在于检验与软件设计相关的程序结构问题;
3.系统测试:检验软件产品能否与系统的其他部分(比如硬件、数据库及操作人员)协调工作;
4.验收测试:检验软件产品质量的最后一道工序,主要突出用户的作用,同时软件开发人员也应有一定程度的参与。
回归测试有两类:用例回归和错误回归;用例回归是过一段时间以后再回头对以前使用过的用例在重新进行测试,看看会重新发现问题。错误回归,就是在新版本中,对以前版本中出现并修复的缺陷进行再次验证,并以缺陷为核心,对相关修改的部分进行测试的方法。
验收测试是以用户为主的测试,软件开发和 QA 人员也应该参加,测试一般在用户所在地进行,由用户验证软件产品是否满足了所有的需求的一系列的验收测试工作。
仅限于内部测试稳定后,根据合同中需求由发包商进行验收测试。验收测试的目的是为了以发现”未实现的需求”为目的,以评估”适合使用”为目标,该类测试的不是以发现缺陷为主要目的。
Alpha 测试和 Beta 测试的区别:两者的主要区别是测试的场所不同。
alpha 测试是公司内部在模拟实际操作环境下进行的一种验收,公司内部会组织内部员工进行的测试,alpha 测试不能由程序员或者测试完成。
Beta 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试,beta 测试不能由程序员或测试员完成。
开发人员说不是 bug,有两种情况,一是需求没有确定,所以可以找产品经理进行确认,评估是否需要改动,三方商量确定好后再看是否要改。
二是这种情况开发认为不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出 BUG 的依据是什么,如果被用户发现或出了问题,会有什么不良结果。如果还是有分歧,可以将这个问题提出来,跟开发经理和测试经理进行确认,确定是 bug 的话,一定要坚持自己的立场,让问题得到最后的确认。
各个公司可能不同,以下仅供参考,具体根据公司实际情况执行。
1.系统测试用例设计已经通过评审;
2.按照系统测试计划完成了系统测试;
3.核心代码 100% 经过 Code Review(代码走查);
4.系统测试的功能覆盖率达 100%;
5.严重错误和主要错误的缺陷修复率必须达到 100%,不允许存在功能性的错误;次要错误和一般错误的缺陷修复率必须达到 85%以上,允许存在少量功能缺陷,后续版本解决;对于较小错误的缺陷修复率最好达到 60%~70%以上;对于测试建议性的问题,可调低优先级;
6..由开发经理,测试经理,项目经理共同确认后发布上线。
第一要考虑需求当中的覆盖范围,ui界面、功能、性能、易用性、安全性、兼容性当中都有哪一类型,六大测试内容当中最难分析的就是功能
第二要充分考虑业务场景,限制条件,涉及到的岗位/角色/用户,关联的外部系统(是否调用外部接口)、内部系统(是否需要跨模块协作,功能上是否存在依赖,下发是否需要同步)、同时要预估一下风险(是系统依赖会不会导致测试时间不明确,延期提测,测试数据的造数等)
测试经验越多,测试能力越高。所以我的职业发展是需要时间积累的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前 3 年积累测试经验,按如何做好测试工程师的要点去要求自己,不断更新自己改正自己,做好测试任务。
技术方向:测试人员—自动化的路线(面试前先询问一下有没有自动化)、性能测试、大数据测试
管理方向:测试人员---测试组长或者项目经理
坚持底线和原则;做测试应该要有一定的协调能力,因为测试人员经常要与开发接触处理一些问题,如果处理不好的话会引起一些冲突,这样的话工作上就会不好做。还有测试人员要有一定的耐心,有的时候做测试很枯燥乏味。除了耐心,测试人员不能放过每一个可能的错误。
虽然我的测试技术还不是很成熟,但是我觉得我还是可以胜任软件测试这个工作的,因为做软件测试不仅是要求技术好,还有有一定的沟通能力,耐心、细心等外在因素。综合起来看我认为我是胜任这个工作的。
测试对象是模块内部的程序错误,目的是消除局部模块逻辑和功能上的错误和缺陷。测试依据是模块的详细设计,测试方法是采用白盒测试。
加班的话我没有太多意见,但是我还是觉得如果能够合理安排时间的话,不会有太多时候加班的。
加班可以接受,自己之前的项目也是要加班的。不要很明显的去拒绝
根据我以前的工作和学习经验,我认为做好工作首先要有一个良好的沟通,只有沟通无障碍了,才会有好的协作,才会有更好的效率,再一个就是技术一定要过关,做测试要有足够的耐心,和一个良好的工作习惯,不懂的就要问,实时与同事沟通这样的话才能做好测试工作。
因为之前了解软件测试这个行业,觉得他的发展前景很好。
要有架构师、开发经理、测试经理、程序员、测试员、产品经理。我在里面主要是负责所分到的模块执行测试用例。
体现自己的个人优势
仅是一个测试执行者,不折不扣的去完成领导交代的事情,保证自己的工作有质有量,同时还可以帮助同事做一些交叉测试。
是一个偏管理者,体现自己的管理优势,任何一个团队的管理者可替代性比较低,如果我离职,短期内很难找到替代我的人,其次我对业务知识了解比较深,很多时候开发和业务都要咨询我的意见以及询问一些业务逻辑
1)业务复杂,比如贷前审批,他征信检查这个版块就会设计很多规则,要造的测试数据会特别多,一次性需要铺设七八十条数据,场景比较多,易容易遗漏或出错,测试环境是使用挡板来解决
2)通用的说法:1.业务和开发不在同一场地,需求分析和其他沟通成本比较大,没有书面化的输出,容易造成三方信息不一致(业务、开发、测试),从测试来看只认有文档说明的需求变更,没有说明当做不存在,测试要强势一点;
2.项目的测试流程不够规范,没有任何的测试过程文档输出,起初经常会出现测试背锅的情况,解决方法制定和完善测试流程,测试负责人和开发负责人共同去将规范的测试流程执行起来,加强了测试过程的记录,这样就有迹可查;
从软件测试的定义和目的来讲:软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入数据和预期的输出结果),并根据这些测试用例去运行程序,以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布。
从软件测试质量保证的方向上讲:一个产品的测试质量如何要从3个角度来考虑:
时间:测试的时间是否充足
人力:测试要投入的人力是否充足
范围:测试对需求文档的覆盖范围
以上任何一个环节出错都有可能导致测试质量低下,所谓的软件测试就是在尽可能短的时间内找出尽可能多的bug,没有缺陷的软件是不存在的。
需求分析:全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价,制定初步的项目计划。
测试准备:组织测试团队、培训、建立测试和管理环境等。
测试设计:按照测试要求进行每个测试项的测试设计,包括测试用例的设计和测试脚本的开发等。
测试实施:按照测试计划实施测试。
测试评估:根据测试的结果,出具测试评估报告。
SQA 就是独立于软件开发的项目组,通过对软件开发过程的监控,来保证软件的开发流程按照指定的 CMM 规程(如果有相应的 CMM 规程),对于不符合项及时提出建议和改进方案,必要时可以向高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入,从而减少后期软件的维护成本。SQA 主要的工作活动包括制定 SQA 工作计划,参与阶段产物的评审,进行过程质量、功能配置及物理配置的审计等;对项目开发过程中产生的数据进行度量等等。
项目在开发过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制,配置管理的使用取决于项目规模和复杂性及风险的水平。软件的规模越大,配置管理就越显得重要。还有在配置管理中,有一个很重要的概念,那就是基线,是在一定阶段各个配置项的组合,一个基线就提供了一个正式的标准,随后的工作便基于此标准,并只有经过授权后才能变更这个标准。配置管理工具主要有 CC,VSS,CVS,SVN 等,我只用过 SVN,对其他的工具不是很熟悉。
测试并不能够最大限度的保证软件的质量,软件的高质量是开发和设计出来的,而不是测试出来的,它不仅要通过对软件开发流程的监控,使得软件开发的各个阶段都要按照指定的规程进行,通过对各个阶段产物的评审,QA 对流程的监控,对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方式,是软件质量保证工程的一个重要组成部分。
出现以上的情况,如果仅仅想通过测试来提高软件质量,那几乎是不可能的,原因是没有足够的时间让你去测试,少而不规范的文档导致测试需求无法细化到足够且有针对性的测试。所以,作为公司质量保证的应该和项目经理确定符合项目本身适合的软件生命周期模型,明确项目的开发流程并督促项目组按照此流程开展工作,所有项目组成员(项目经理更加重要)都要制定出合理的工作计划,加强代码的单元测试,在客户既定的产品交付日期范围内,进行产品的持续集成等等,如果时间允许可以再配合客户进行必要的系统功能测试。
掌握基本的测试基础理论
本着找出软件存在的问题的态度进行测试,不要以挑刺的形象出现
可熟练阅读需求规格说明书等文档
以用户的观点看问题
有强烈的质量意识
细心和责任心
良好的有效的沟通方式(与开发人员及客户)
具有以往的测试经验能够及时准确的判断出高危险区在何处
必须经过测试基础知识和理论的相关培训
测试人员必须熟悉系统功能和业务
测试要有计划,而且测试方案要和整个项目计划协调好
必须实现编写测试用例,测试执行阶段必须根据测试用例进行
易用性,功能,分支,边界,性能等功能性和非功能性需求都要进行测试
对于复杂的流程一定要进行流程分支,组合条件分析,再进行等价类划分准备相关测试数据
测试设计的一个重要内容是要准备好具体的测试数据,清楚这个测试数据是测试那个场景或分支的。
个人任务平均每三个测试用例至少应该发现一个 BUG,否则只能说明测试用例质量不好
除了每天构建的重复测试可以考虑测试自动化外,其他暂时都不要考虑去自动话
答:如果公司项目要求需要加班,我会积极参与,我们之前公司也有加班,所以这种情况我了解。也能完成好工作。
因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比 ISO 质量认证一样,测试同样也需要质量认证,这个时候就需要在团队中开展软件测试的工作。在测试的过程中发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。
测试类型有:功能测试、性能测试、界面测试
功能测试在测试工作中占有比例最大,功能测试也叫黑盒测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行
界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象
区别在于,功能测试关注产品的所有功能,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注产品整体的多用户并发下的稳定性和健壮性。界面测试则关注与用户体验相关内容,用户使用该产品的时候是否已用,是否易懂,是否规范(用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)。做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没有问题的,然后再考虑性能的问题。
答:测试 3 人,老大负责分配我们的任务,每个人负责对应的模块或者是不同的客户端,完成自己的一段时间的任务就行。
答:1、上家公司比较清闲,不利于我的长期发展,所以离职了
2、上家公司的业务比较少,基本上是事情比较少的情况,年轻人要多奋斗下,所以我选择离职,去更加忙一点的公司。(2 选 1)
答:首先会召开需求分析会议,参加人员有产品、开发和测试,主要是探讨需求主要的一些功能点;然后开发就排期进行开发,主管开始编写测试计划,对我们进行任务分配。
我们参考需求规格说明书及原型图编写测试用例,写完之后会进行用例评审,有评审修改的就修改整理形成最终的用例版本;开发人员版本编译完成后,我们会先进行预测,主要对主功能业务进行测试,如果主业务流程不通过,直接返回给开发进行修改。预测通过,依据测试用例进行系统测试。测试过程中,提交 bug,跟踪 bug,进行回归测试直至不存在严重 bug,满足用户需求,测试完后编写测试报告;产品发布上线后,关注 web 是否正常运行,要进行常规的维护性测试。
答:写过;1、测试计划包括:项目信息、参与文档、测试范围、测试策略、测试时间人员安排、测试环境;2、测试报告包含:项目背景、参考资料、测试范围、测试结果及缺陷分析、测试结论与建议,风险评估;3、交付文档:主要是测试用例、测试计划、测试报告。
先在出现问题的环境上尽量重现,保持浏览器环境、出现问题的特定账号等的一致,多次尝试仍然不能重现,也要记录到 bug 平台,将出现问题的特征步骤尽量描述清楚,附带问题截图及日志截图、注明偶现;如果项目时间允许,bug 等级高,需要开发协助重现;如果时间不允许,记录到 BUG 平台后续在跟进。
答:Bug 的生命周期,就是一个 bug 被发现到这个 bug 被关闭的过程,生命周期中一般缺陷状态:新建、指派、已解决、待验、关闭
如果待验证的 bug 在验证是没有解决好,我们需要重新打开(激活)→指派→已解决→待验,循环这个过程,中间其他状态:重新打开、拒绝、延期等
答:首先确认开发环境是否跟自己测试环境一致,确认在测试环境能重现,如果确认是缺陷跟开发保持有效沟通,如果是级别较低的建议性 bug,可以先记录到 bug 平台,先保留沟通。如果是 bug 级别较高的问题,对应需求文档的预期结果跟开发说明,更有说服力;耐心讲解 BUG 的危害,不行就找产品确认,确实是 BUG 注明情况并再次指派给开发
答:身份证末尾 X 结尾的, 实名认证显示成功,但是在后面提现的时候,会报错,后面发现是保存到库里面的,都是小写 X 的,导致提现这边不识别,印象深刻的原因是因为花了一定的时间去找到这个 bug,并且自己尝试定位到原因,所以印象深刻。
分析问题:首先查看问题的情况,紧急程度,如果问题比较严重,要先汇报给组长或者项目负责人,讨论解决办法。我们测试要想办法,可以去测试环境中复现,或者是协助开发在生产上查日志,分析定位问题。
1、一般问题下个版本修复即可,或者发个小补丁。
2、严重问题影响到主流程,可能要回退到上个版本(迫不得已十分严重),或者是紧急发补丁修复。
1、开启定时器扫描读取;
2、必须有一个.ok文件,扫描到.ok文件后,再去拿对应的文件;
3、注意文件的加密解密;
4、我们读取的接口文件是一个压缩包,里面有2个txt文档,一个为index,一个为存放数据,index文件里面的文件名必须与另外一个文件的名字一致,才能读取到;
5、注意文件的大小、数据条数的上限;
6、注意文件的命名规则,例如我们是T09_A02_20220708_100001_000001.zip,如果文件名错了是直接解析失败的。