😖
问题重点

:one:回归测试
  • 修改了==旧代码==后,重新进行测试以确定没有引入==新的错误==或导致其他代码产生错误
  • ==产品修正==了bug或增加了功能,生成==新的版本==,对这个版本进行测试
  • 保证变化没有对产品原有功能造成破坏,最可靠的方式是对产品进行==全面的测试==
  • 因为准确的确定产品修改部分的相关部分往往很有难度,==范围==不好确定。具体采用哪种==回归方式==,要由这个产品的质量要求、人力资源、时间进度等因素来决定
  • ==α测试== 是由一个用户在==开发环境==下进行的测试,属于==非正式验收==(验收测试的一种)
    • 可以从软件产品==编码结束==之时开始,或在==模块(子系统)测试完成==之后开始
    • 非正式验收测试,在==确认测试过程中==产品达到一定的稳定和可靠程度之后再开始的α测试
  • ==β测试== 是由软件的多个用户在一个或多个用户的==实际使用环境==下进行的测试,属于==验收==
:two:==一次成功的测试==是指运行测试用例后发现了程序错误
:three:验收测试在alpha阶段前,非==最终用户==实施,α测试,β测试为用户实施,区别在于是否为最终用户
:four:测试的关键问题是==如何选择测试用例==
:five:==风险曝光度==(riskexposure)=错误出现率(风险出现率)X错误造成损失(风险损失)
:six:==既可以用于黑盒测试,也可以用于白盒测试的方法==:边界值法在黑盒测试中,我们可以不涉及代码来取边界值;但是也可以在设计代码时,比如在条件覆盖等白盒测试方法中取到边界值,因为往往边界值的位置容易出错所以是两种测试都可以用
  • tip:==边界值分析法为黑盒,边界值法为白盒==
:seven:软件测试==主要工作内容==是验证和确认
  • ==验证(verification)==是保证软件正确地实现了一些特定功能的一系列活动, 即保证软件以正确的方式来做了这个事件(Do it right)
    • 确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程
    • 程序正确性的形式证明,即采用形式理论证明程序符合设计规约规定的过程
    • 评审、审查、测试、检查、审计等各类活动,或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告
  • ==确认(validation)==是一系列的活动和过程,目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件做了你所期望的事情。(Do the right thing)
:eight:==Junit==是一个Java语言的面向==白盒==测试的==单元测试==框架
:nine:==错误推测法==是经验分析,属于黑盒测试
:keycap_ten:==系统测试计划设计参考==文档软件测试计划、软件需求规范、迭代计划
  • 可行性报告是软件开发前做好,用于证明该计划可行的,没有必要参考
:one::one:==app压力测试==(又==边界值容错测试==,==极限负载测试==)
  • 存储压力:由于手机采用的是栈式存储,所以当一个存储块满了之后,程序员不做相应处理的话,就会导致其他存储区被删除
  • 边界压力:边界处理问题一直是容易被忽略的地方
  • 响应能力压力:有时 某些操作可能处理的时间较长,如果在处理期间,继续进行其他操作时候就会出现问题
  • 网络流量压力:执行较大数据流量的功能同时,在进行其他操作,使得网络流量始终处于很高的状态,检验各个功能是否依然正常工作,是否存在因为网络流量瓶颈引起的某功能异常
:one::two:==路径覆盖同时实现判定覆盖==
:one::three:测试的==粒度==由测试阶段的推进而增大
:one::four: