基本理论篇

Q:什么是软件测试

软件测试的经典定义是:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。

Q:软件测试分为几个阶段, 各阶段的测试策略和要求是什么

软件测试按阶段划分可以分为单元测试、集成测试、系统测试和<验收测试>(不一定有)几个阶段

单元测试测试策略:

  • 自顶向下的单元测试策略:比孤立单元测试的成本高很多,不是单元测试的一个好的选择。
  • 自底向上的单元测试策略:比较合理的单元测试策略,但测试周期较长。
  • 孤立单元测试策略:最好的单元测试策略。

集成测试的测试策略:

  • 大爆炸集成:适应于一个维护型项目或被测试系统较小

  • 自顶向下集成:适应于产品控制结构比较清晰和稳定;高层接口变化较小;底层接口未定义或经常可能被修改;产口控制组件具有较大的技术风险,需要尽早被验证;希望尽早能看到产品的系统功能行为。

  • 自底向上集成:适应于底层接口比较稳定;高层接口变化比较频繁;底层组件较早被完成。

  • 基于进度的集成:

    • 优点:具有较高的并行度;能够有效缩短项目的开发进度。
    • 缺点:桩和驱动工作量较大;有些接口测试不充分;有些测试重复和浪费。

系统测试的测试策略:

数据和数据库完整性测试;功能测试;用户界面测试;性能评测;负载测试;强度测试;容量测试;安全性和访问控制测试;故障转移和恢复测试;配置测试;安装测试;加密测试;可用性测试;版本验证测试;文档测试

Q:测试计划工作的目的是什么?测试计划文档的内容应该包括什么?其中哪些是最重要的

软件测试计划是指导测试过程的纲领性文件。包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。

测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。
所以其中最重要的是测试策略测试方法(最好是能先评审)。

Q:缺陷(Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录

提交BUG时,描述应该包括以下的信息:

  • BUG产生对应的软件版本和模块
  • 开发的接口人员
  • BUG 的优先级
  • BUG 的严重程度
  • BUG 可能属于的模块,如果不能确认,可以用开发人员来判断
  • BUG 标题,需要清晰的描述现象
  • BUG 描述,需要尽量给出重现 BUG 的步骤
  • BUG 附件中能给出相关的日志,截图或者视频

高质量的 BUG 记录就是指很容易理解的 BUG 记录,所以对于描述的要求高,能提供的信息精准,很好的帮助开发人员定位。

Q:软件测试原则

所有的测试软件测试都应追溯到用户需求
这是因为软件测试的目的是使用户完成预定的任务,并满足用户的需求,而软件测试的所揭示的缺陷和错误使软件达不到用户的目标,满足不了用户的需求。

应当将“尽早地和不断地进行软件测试”作为软件测试者的座右铭
测试需求贯穿整个软件的生命周期,缺陷修复成本随着各个阶段的靠后而提升。从平时的醒目中已看出,需求阶段引入的bug不比设计阶段少,如何保证好需求的稳定有效已经至关重要。

完全测试是不可能地,测试需要终止
即Zero Bug与Good Enough;本条给我们灌输的是一种测试执行通过的标准。显示任何测试通过不可能达到0bug。那我们就应该达到Good Enough。这条原则是一种权衡投入/产出比的原则:测试既不能不充分也能过,我们需要制定测试通过标准和测试内容,比如:遗留的bug数&严重程度,测试用例的执行率&通过率等来解决上面的问题。

软件测试无法显示软件潜在的缺陷
进行测试时可以查找并报告发现的软件缺陷和错误,但是不能保证软件的缺陷和错误能全部找到,继续进一部测试可能还会找到一些,也就是说测试只能证明软件存在错误而不能证明软件没有错误。

充分注意测试中的集群现象
即80-20原则;这条主要想告诉我们的就是缺陷的集群现象,发现缺陷越多的模块就需要投入更多的人力精力去测试。

程序员应避免检查自己的程序
为了达到测试目的,应由客观、公正、严格的独立的测试部门或者独立的第三方测试机构进行测试。

尽量避免测试的随意性
制定严格的测试计划,并把测试时间安排的尽量宽松,有组织、有计划、有步骤的开展测试活动。

回归测试的关联性
回归测试的关联性一定要引起充分注意。修改一个错误而引起更多错误出现的现象并不少见。

关注程序不该做的事
检查程序应该完成哪些功能,这只是测试工作的一半,测试工作的另一半是,检查程序完成了哪些不应该完成的功能。

个人篇

Q:测试人员该有的素质

保持怀疑
对产品的质量持有一颗敢于怀疑的心,质量不是开发人员说”我做完了而且也测过了”就可以保证的。直到你测完最后一轮,最后一个用例之前,你都应该对产品的质量持怀疑态度。这个态度是混口饭吃的最基本技能。

永不妥协
不要对产品质量妥协,哪怕开发口口声声说这个问题不好改,改不了,一改就要延期之类的话。妥协意味着你成功的把质量不好这口黑锅华丽的背在了自己的身上。

让用户满意
产品或项目成功的标志之一是能够让用户满意,很显然用户是不会对一个bug频出的系统/产品满意的。

从用户角度思考
- 从用户角度去思考,如果你是一个特定的用户(年龄,身份,职业)你应该会怎么使用这个产品
- 从场景的角度去思考,在哪些场景下会使用到这个产品

分清主次
要分清楚任务的优先级,优先级高的先做,依此类推。在没有分清优先级的情况下不要盲目的开始测试。

从不承诺100%的覆盖率
做不到也不可能做到。

倾听建议
别人的建议有些是金玉良言,有些则可以忽略不计。做测试的时候你不是一个人在战斗,多听听别的的有效建议是没有坏处的。

尽早开始
尽早开始重要的模块的测试工作。因为问题发现的越早解决的成本就越低。另外早点开始测试重要的模块或功能可以尽可能多的增加测试时间,拿时间换质量一般来说是效果的。这个建议的另一个说法就是想办法让重要的模块可以尽早的开始测试。

确定并管理风险
在做项目测试的时候,一个好的测试同学需要有发现项目质量上可能出现的风险的能力。另外当发现了项目风险的时候,我们还需要能够将风险管理起来,让风险可以被控制,可以被解决。

做市场调研
看看友商的产品做的怎么样,有什么好的地方,有什么不好地方。好的地方我们的产品可以学习,不好的地方我们可以预防和改进。这是站在产品人员的角度去看待自己的项目或产品,因为好的测试在某些时候需要具备好的产品人员的素质。

培养BA技能
BA就是业务分析师的意思,在某些项目里,这类同学被称为产品狗。这要求测试人员有分析需求的能力,哪些需求是真需求,哪些需求是伪需求。真需求就玩命的测,伪需求在时间允许的情况下尽量的测。这也是产品视角,这也是为什么有很多测试同学转去做产品的原因。

不要忘了异常情况
只测试正常的流程往往是不太够的,一些异常的情况我们也需要进行测试。另外不出意外的话异常情况的测试用例数量是要多于正常情况的。测试异常情况有助于我们发现bug,也有助于我们换个角度看待产品和项目的业务行为。

Be a Good Judge of Your Product
做那个对项目/产品最有发言权的人。学会交涉在保证项目质量的前提下我们要尽可能多的通过交涉和协商保障自己的利益。交涉意味着在某些情况下我们需要做出让步,退一步海阔天空,但前提是,退的这一步不影响项目或产品的质量。停止指责出问题的时候第一要务是先把问题解决掉,而不是指责相关责任人。

做一个好的观察者
观察项目,观察开发的流程,观察测试的流程,发现问题,提出问题,引导团队去解决问题。

Q:你有哪些优秀特质:(结合自身即可)

  • 有韧性
  • 有耐心
  • 做事有条理性
  • 喜欢挑战
  • 有信心做好每一件事情
  • 较强的沟通能力

能力篇