首先,我认为的测开是测试和开发工作都在做的。
一方面,据我了解,在近几年,国内对软件测试越来越重视,并且从用户角度来说,对于同类产品,可能会更加注重产品的质量和服务,所以我觉得测试的发展前景是非常好的。
其次,测试在一个项目开发的过程中是非常重要的一环。测试是产品上线的最后一道把关,如果测试工作做得到位,就能避免很多的问题,像最近中秋国庆12306高峰期买票老进不去,这其实就是性能做的不够好。测试人员的责任非常大,责任越大成就感就越大。我很喜欢这样的工作。
另一方面,测开还有一部分开发工作,无论是自动化脚本还是测试工具或框架,都提高了测试的效率,为质量效率保证工作提供了有力的保障。并且测开的所需技术广度也是很高,所以我认为测开会激发我对这个岗位的热爱和持续学习的态度。
首先从岗位名字来看,要求测开工程师即要懂测试,又要懂开发。其次这个岗位融合了开发角色和质量意识,要求我们兼具开发人员的技能和测试人员的思维。总的来说,测试开发工程师的定位就是保障产品的质量和提高测试的效率。
技能点:会开发,了解测开的基本理论
性格优势:
有责任感,举例:实习过程中赶需求愿意加班,按时按质量的提交需求,有实际项目开发经验,明白测试在整个项目的重要性,举例实习过程中测试部门会反馈给我们问题;
做事细致,有条理,会事先做好详细的计划安排,本科组织部经历 + 比如实习过程中,写接口前会写好接口文档,写完接口后,会进行测试,设计好详细的测试样例,比如… ;
初级测试工程师:测试计划、测试文档、测试执行、结果整理等,门槛不高。
测试开发工程师:核心-编程能力、自动化能力。
测试架构师:在整个测试架构上参与和管理测试,更强调测试流程管理和质量监管,以及白盒测试能力,对测试工具和平台的开发等


下面就按照上面思路来梳理购物车的测试点。

白盒测试是:
也称逻辑驱动测试,测试者知道被测对象的内部结构和逻辑实现,将其视作一个透明的盒子,针对其中实现细节的状态、结构、路径进行测试覆盖
目的主要是验证「白盒子」内部的结构和运作是正常的
常通过单元测试动态地进行测试,或code review的方式静态地进行检查
黑盒测试是:
也称数据驱动测试,测试者无需知悉被测对象内部实现方式,将其视作一个黑色不透明的盒子,只考虑对产品明确提供的功能特性针对性进行输入,检测其输出
目的主要是验证「黑盒子」承诺对外提供的功能是否按规范、规格说明的要求正确实现了
常通过在用户界面(GUI),以用户的角度进行有效、无效操作
设计秒杀场景的测试用例时,需要考虑以下几个方面:
并发场景:测试在高并发下系统的稳定性和性能。可以模拟多个用户同时参与秒杀活动,设置不同的线程数和请求间隔时间,测试系统的响应时间和吞吐量等指标。
库存场景:测试系统对库存的管理和控制。可以设置不同的库存数量和秒杀人数,测试系统是否能正常抢购并准确控制库存数量。
安全场景:测试系统的安全性。可以模拟攻击者对系统进行DDoS攻击或SQL注入等攻击方式,测试系统的抗攻击能力。
异常场景:测试系统处理异常情况的能力。可以模拟网络故障、服务器宕机、重启等异常情况,测试系统是否能够快速恢复和处理异常情况。
业务场景:测试系统对业务逻辑的处理能力。可以模拟不同的用户身份、优惠券使用、活动时间等不同的业务场景,测试系统的处理能力和正确性。
例如,可以设计以下测试用例:
在高并发场景下,测试系统的响应时间和吞吐量是否满足要求。
设置不同的库存数量和秒杀人数,测试系统是否能正常抢购并准确控制库存数量。
模拟攻击者对系统进行DDoS攻击或SQL注入等攻击方式,测试系统的抗攻击能力。
模拟网络故障、服务器宕机、重启等异常情况,测试系统是否能够快速恢复和处理异常情况。
模拟不同的用户身份、优惠券使用、活动时间等不同的业务场景,测试系统的处理能力和正确性。

需求调查:全面了解系统概况、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价,制定测试计划。
测试设计:按照测试计划完成测试设计,包括测试用例的设计,并且对编写完毕的测试用例进行评审和完善。
测试执行:按照测试计划执行测试用例,并对 Bug 进行跟踪管理。
在开发提测之后,先执行冒烟用例(冒烟测试就是版本转测试之前,对系统的基本功能进行简单的测试),冒烟测试通过之后,再执行其他用例。
在执行测试用例过程中,要根据用例步骤操作系统,对比执行出来的实际结果和预期结果是否一致。
如果一致测试通过。
实际结果与预期结果不一致测试失败,需要提交 Bug 进入 Bug 管理流程。
Bug 修改好之后要回归验证,确认改好了并且没有新增问题。
老功能回归测试。
测试评估:总结测试工作。根据测试的结果,出具测试评估报告。
上线:监控线上产品,及时发现并解决线上问题。
点赞是否会泄露用户信息
代码错误:因为代码编写错误导致的缺陷。一般来说,如果没有其它类型的原因,默认为引起缺陷的原因为代码错误
需求不清晰:在需求中没有具体定义、需求设计缺陷、或者需求理解存在二义性的场景下产生的 Bug。
需求变更:产品需求移交后中途变更需求时产生的 Bug。这种场景一般时因为需求的变更开发与测试获取的需求信息不一致。
新引入问题:开发改 Bug 时,产生新的 Bug
配置问题:客户配置不正确,或者未导入正确配置产生的 Bug
覆盖升级:因版本覆盖升级导致的 Bug
性能问题:系统卡顿,响应慢等
兼容问题:由于不同硬件设备和操作系统的区别产生的 Bug
线上故障:线上版本的影响主流程的 Bug
现在大部分系统前后端架构是分离的,接口作为前后端数据交互的,它的质量是必须要通过接口测试去保障的。
而且系统越来越复杂,传统的靠前端测试已经大大降低了效率,而且现在都推崇测试左移,希望测试能更早的介入测试,那接口测试就是一种及早介入的方式。如果是只测试功能,是需要等前后端都完成才能进行测试。
而如果是接口测试,只需要前后端定义好接口,那这时自动化就可以介入编写接口自动化测试代码。手工接口测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。
而且只依赖前端进行数据限制已经完全不能满足系统的安全要求,现在绕过前端直接对接口发起请求非常容易。在这种情况下就需要从接口层面进行验证。尤其是涉及到用户的隐私信息,如身份证,银行卡等,需要看是否加密传输,保证系统的安全性。
可以检验接口是否按照约定返回响应
可以修改请求参数,突破前端页面输入限制,检验系统的异常处理能力。比如边界值处理错误,输入异常值接口抛异常,输入参数多或者少接口抛异常等等
可以检验系统的安全性。比如明文传输、返回结果含有敏感信息,没对用户身份信息做校验,没做恶意请求拦截等等
可以通过接口测试并发场景,检验系统的性能和稳定性。比如接口并发多条相同操作,响应时间过长,



不同浏览器
不同系统
移动设备
不同分辨率
打开界面需要多久
点击登录后需要多久
接口测试,性能测试。主要用于web应用程序的负载测试
接口测试。提供功能强大的Web API和HTTP请求的调试,它能够发送任何类型的HTTP请求。
浏览器 web 应用测试框架
稳定性测试
软件附带在sdk中,适用于android和ios,通过adb shell,生成用户或系统的伪随机事件。
压力测试结果:崩溃crash,无响应anr,
基本命令:adb shell monkey 1000。