测试经验越多,测试能力越高。所以我的职业发展是需要时间积累的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前 3 年积累测试经验,按如何做好测试工程师的要点去要求自己,不断更新自己改正自己,做好测试任务。
做测试应该要有一定的协调能力,因为测试人员经常要与开发接触处理一些问题,如果处理不好的话会引起一些冲突,这样的话工作上就会不好做。还有测试人员要有一定的耐心,有的时候做测试很枯燥乏味。耐心加技术是测试人员在企业中生存之道
虽然我的测试技术还不是很成熟,但是我觉得我还是可以胜任软件测试这个工作的,因为做软件测试不仅是要求技术好,还有有一定的沟通能力,耐心、细心等外在因素。综合起来看我认为我是胜任这个工作的。
测试的目的是找出软件产品中的错误,使软件尽可能的符合用户的要求。当然软件测试是不可能找出全部错误的。
一般来说分为 5 个阶段:单元测试、集成测试、确认测试、系统测试、验收测试
测试对象是模块内部的程序错误,目的是消除局部模块逻辑和功能上的错误和缺陷。测试依据是模块的详细设计,测试方法是采用白盒测试。
加班的话我没有太多意见,但是我还是觉得如果能够合理安排时间的话,不会有太多时候加班的。
根据我以前的工作和学习经验,我认为做好工作首先要有一个良好的沟通,只有沟通无障碍了,才会有好的协作,才会有更好的效率,再一个就是技术一定要过关,做测试要有足够的耐心,和一个良好的工作习惯,不懂的就要问,实时与同事沟通这样的话才能做好测试工作。
因为之前了解软件测试这个行业,觉得他的发展前景很好。
要有架构师、开发经理、测试经理、程序员、测试员。我在里面主要是负责所分到的模块执行测试用例。
软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例 (即输入数据和预期的输出结果),并根据这些测试用例去运行程序,以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布。
需求调查:全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价,制定初步的项目计划。
测试准备:组织测试团队、培训、建立测试和管理环境等。
测试设计:按照测试要求进行每个测试项的测试设计,包括测试用例的设计和测试脚本的开发等。
测试实施:按照测试计划实施测试。
测试评估:根据测试的结果,出具测试评估报告。
简单点,测试计划里应有详细的测试策略和测试方法,合理详尽的资源安排等,至于测试用例,那是依赖于需求 (包括功能与非功能需求) 是否细化到功能点,是否可测试等。
掌握基本的测试基础理论
本着找出软件存在的问题的态度进行测试,不要以挑刺的形象出现
可熟练阅读需求规格说明书等文档
以用户的观点看问题
有强烈的质量意识
细心和责任心
良好的有效的沟通方式 (与开发人员及客户)
具有以往的测试经验能够及时准确的判断出高危险区在何处
必须经过测试基础知识和理论的相关培训
测试人员必须熟悉系统功能和业务
测试要有计划,而且测试方案要和整个项目计划协调好
必须实现编写测试用例,测试执行阶段必须根据测试用例进行
易用性,功能,分支,边界,性能等功能性和非功能性需求都要进行测试
对于复杂的流程一定要进行流程分支,组合条件分析,再进行等价类划分准备相关测试数据
测试设计的一个重要内容是要准备好具体的测试数据,清楚这个测试数据是测试那个场景或分支的。
个人任务平均每三个测试用例至少应该发现一个 BUG,否则只能说明测试用例质量不好
除了每天构建的重复测试可以考虑测试自动化外,其他暂时都不要考虑去自动话
因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比 ISO 质量认证一样,测试同样也需要质量认证,这个时候就需要在团队中开展软件测试的工作。在测试的过程中发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。
测试类型有:功能测试、性能测试、界面测试
功能测试在测试工作中占有比例最大,功能测试也叫黑盒测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行
界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象
区别在于,功能测试关注产品的所有功能,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注产品整体的多用户并发下的稳定性和健壮性。界面测试则关注与用户体验相关内容,用户使用该产品的时候是否已用,是否易懂,是否规范 (用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)。做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没有问题的,然后再考虑性能的问题。
答:等价类、边界值、错误推测法、场景法,我个人常用的方法就是这些
答:alpha 测试是公司内部在模拟实际操作环境下进行的一种验收,公司内部会组织内部员工进行的测试,alpha 测试不能由程序员或者测试完成。
Beta 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试,beta 测试不能由程序员或测试员完成。
答:首先会召开需求分析会议,参加人员有产品、开发和测试,主要是探讨需求主要的一些功能点;然后开发就排期进行开发,主管开始编写测试计划,对我们进行任务分配。
我们参考需求规格说明书及原型图编写测试用例,写完之后会进行用例评审,有评审修改的就修改整理形成最终的用例版本;开发人员版本编译完成后,我们会先进行预测,主要对主功能业务进行测试,如果主业务流程不通过,直接返回给开发进行修改。预测通过,依据测试用例进行系统测试。测试过程中,提交 bug,跟踪 bug,进行回归测试直至不存在严重 bug,满足用户需求,测试完后编写测试报告;产品发布上线后,关注 web 是否正常运行,要进行常规的维护性测试。
测试报告交付文档有哪些?
答:写过;1、测试计划包括:项目信息、参与文档、测试范围、测试策略、测试时间人员安排、测试环境;2、测试报告包含:项目背景、参考资料、测试范围、测试结果及缺陷分析、测试结论与建议,风险评估;3、交付文档:主要是测试用例、测试计划、测试报告。
先在出现问题的环境上尽量重现,保持浏览器环境、出现问题的特定账号等的一致,多次尝试仍然不能重现,也要记录到 bug 平台,将出现问题的特征步骤尽量描述清楚,附带问题截图及日志截图、注明偶现;如果项目时间允许,bug 等级高,需要开发协助重现;如果时间不允许,记录到 BUG 平台后续在跟进。
答:Bug 的生命周期,就是一个 bug 被发现到这个 bug 被关闭的过程,生命周期中一般缺陷状态:新建、指派、已解决、待验、关闭
如果待验证的 bug 在验证是没有解决好,我们需要重新打开(激活)→指派→已解决→待验,循环这个过程,中间其他状态:重新打开、拒绝、延期等
答:首先确认开发环境是否跟自己测试环境一致,确认在测试环境能重现,如果确认是缺陷跟开发保持有效沟通,如果是级别较低的建议性 bug,可以先记录到 bug 平台,先保留沟通。如果是 bug 级别较高的问题,对应需求文档的预期结果跟开发说明,更有说服力;耐心讲解 BUG 的危害,不行就找产品确认,确实是 BUG 注明情况并再次指派给开发
答:身份证末尾 X 结尾的, 实名认证显示成功,但是在后面提现的时候,会报错,后面发现是保存到库里面的,都是小写 X 的,导致提现这边不识别,印象深刻的原因是因为花了一定的时间去找到这个 bug,并且自己尝试定位到原因,所以印象深刻。
## 文章首发于 TesterHome 与个人公众号 转载请注明出处!