1.首先测试经过变更的部分,然后测试没有变化的部分

2.首先测试核心功能,然后测试辅助功能,测试产品所完成的关键和常用功能,测试完成产品基本任务的功能

3.首先测试能力,然后测试可靠性

4.首先测试常见情况,然后测试少见情况

5.首先测试常见威胁,然后测试罕见威胁。最有可能出现的压力和错误情况进行测试

6.首先测试影像大的问题,然后测试影像小的问题。测试在出现失效的情况下会产生大量破坏的产品部件

7.首先测试最重要的部分,然后测试没有要求的部分。测试对团队其他人有重要意义的任务部分的任何问题。

8.测试人员如果对产品,产品必须与之交互的软件和硬件以及将使用软件的人越了解,越有肯能更快地找出重要问题

9.测试结束的含义(完备测试可能的含义),完全发现了产品中每个问题;完全检查了产品的每个部分;完成了自认为是有用和经济的测试;尽自己所能,完全达到了项目团队制定的目标;完成了约定的测试;完成了在一定条件下人所能够测试的所有内容;完成了自己知道如何测试的所有内容;完成了自己所承担的测试部分,不考虑其他人的工作;完成了对产品很广,但不是很深的测试;完成了对产品的一种测试;用完了分配给测试的时间;

“完备”的定义并不是在项目一开始就能够最终确定的,随着测试项目的进展,随着新测试任务的突然出现,需要重新考虑。

为了解决在完备性上的普遍沟通问题,可让客户详细了解测试过程。总结自己实施的测试,以及为什么值得实施这些测试,并告诉客户自己没有做的其他值得做的测试,以及为什么没有做这些测试。

10.质量来源与构建产品的人,有时这对他们来说是要背负的沉重负担。测试员使命中的很大一部分,就是帮助他们更有效地对付真正的负担。如果测试员自认为是项目团队中唯一关心交付好产品的人,就不能很好地完成这部分使命。

11.避免问题的关键就是不关注问题,而是关注自己的目标。(针对场外因素)

12.当测试员获得控制产品发布的权力之后,同时也承担了产品质量的全部责任。大多数有效的项目团队,都采用某种方式的集体决定是否发布产品。如果测试员被授权决定产品的发布,会毫不犹豫建议立即坚持与项目团队的其他角色一起分担这种权力

13.测试员的大脑是经过仔细调谐的推理机器,用精神力量做好事,而不是坏事

14.研究认识论,有助于测试。如何搜集和评估证据;如何进行有效推论;如何使用不同逻辑形式;拥有合理的信念意味着什么;形式和费形式推理之间的差别;非形式推理的常见谬误;自然语言的含义与模糊性;如何做出好的决策;

将认识论运用于软件测试,要问与以下类似的问题:怎么知道软件足够好;如果软件并不是足够好,怎样才能知道;怎样知道完成了足够的测试;

研究认识论可以帮助测试员设计有效的测试策略,更好地意识到自己工作中的错误,理解自己的测试能够证明什么、不能证明什么,并编写无懈可击的测试报告

推荐书籍:《批判性思维的工具:心理学的元思想》《思考与决策》《研究的技巧》

15.认知性理学是测试的基础

人的感觉和记忆可靠性;信念从哪里来;信念如何影像人的行为;做出决策所使用的偏见和捷径;如何了解并分享所知道的信息;如何考虑复杂的事情;在压力下如何思考;如何识别模式;如何把想法和事务分类;如何注意事务之间的差别;记忆事件中的失真;如何构建部分记忆的事件

《旷野中的认知》《理论与证据:科学推理的能力的开发》

16.带着问题阅读,带着见解阅读,带着经验阅读。或者说要有问题才去阅读,要有见解、理解才去阅读,要有经验才去阅读。阅读源于人生,生活

17.测试需要推断,并不只是做输出与预期结果的比较

流行的观点认为,测试员只是执行测试用例,并对照预期结果比较执行结果。这种观点把测试看做是简单的比较活动,没有看到一些聪明人必须设计测试,并确定预期输出。测试设计人员几乎重来没有得到过应该测试什么的权威知道,更不要说应该期望什么了。可以得到的知道是要解释的主题。在现实中,大多数测试设计都是基于推断,或基于与测试员的推断有关的经验。不仅如此,这些推断还要随时间发生变化。像测试员那样思考,就是要掌握探索式推断的艺术。数学和科学推理过程是探索式的,而不是脚本化的。

《证明与反驳:数学发现的逻辑》

18.不要将实验与测试混淆起来

实验的含义:可能表示测试员执行一段探索式测试,产生一些没有文档或实验产品的临时性实验。实验的概念是自包含的、实在的,与其他方便实验不同,但也是受限的。

测试:至少包括以下四种活动

配置:准备要测试的产品,将其置于正确的起始状态

运行:输入、输出

观察:对比

评估:评估

19.运用试探法快速产生测试思路

测试边界;测试所有错误消息;测试与程序员的配置不同的配置;运行比较难设置的测试;避免冗余测试

20.测试员不能避免偏向,但是可以管理偏向

测试员是有偏向的,这使得测试员选择一部分测试的可能性要比其他测试大。如果有一段很长的编辑字段,测试员也许更可能输入诸如111111111,而不是43235233,因为输入字符重复的字符串,要比从09的随机数更容易。也许这是一种很小的偏向,但仍是一种偏向。更糟的偏向是,大多数的测试员倾向于测试最可视化的功能,不管是不是重要的功能。此外,大多数测试员还倾向与考虑认为与自己类似的用户,倾向于使用非常简单、非常荒谬的输入,而不是具有中等复杂度的现实输入。

21.过于详细没有什么好处。当编写测试过程时,要避免与测试概念无关的细化。包括所有必要的信息和设计与解释测试所需的细节,但是要让未来的测试员有创造性和判断力的执行,让未来测试员引入变化以使现在所编写的测试过程新鲜、高效。

22.关注测试员、覆盖率、潜在问题、活动和评估的组合测试手段

一种测试手段的分类系统,“五要素测试系统”,人们可以做的所有测试都可以在以下五个方面进行描述。

测试员:进行测试的人

覆盖率:测试了哪些内容

潜在问题:测试的原因

活动:如何测试

评估:怎样判断通过还是不通过

23.功能测试、极值测试、基于需求的测试(覆盖率:测试在这个需求文档中列出的所有内容;潜在问题:测试不满足这个需求的各种方式;评估)、用户测试

24.关注测试内容的基于覆盖率的测试手段

功能测试、特性或功能集成测试、菜单浏览、域测试、等价类分析、边界测试、最佳代表测试、输入字段测试大纲或矩阵、用各种方法映射和测试编辑字段、逻辑测试、基于状态的测试、路径测试、语句与分支覆盖率、配置覆盖率、基于规格说明的测试、基于需求的测试、组合测试

25.关注测试原因基于问题的测试手段

输入约束、输出约束、计算约束、存储约束

26.关注测试方法的基于活动的测试手段

回归测试、脚本测试、冒烟测试、探索式测试、游击式测试、场景测试、安装测试、负载测试、长序列测试(可靠性测试、耐力测试)、性能测试

27.关注测试是否通过的基于评估的测试手段

自校验数据、与已保存的结果进行比较、与规格说明或其他权威文档比较、基于理念的测试

28.及时报告缺陷。不要等到第二天或下午才报告程序错误,不要等到忘记了一些关键细节才报告。拖延的时间越长,程序错误被解决的可能性就越小。

29.小缺陷也值得报告和修改。小错误会使客户感到困惑,并降低客户对产品的其他部分降低信心

30.时刻明确严重等级和优先级之间的差距。严重等级表示程序错误影响或后果,优先级表示什么时候公司要求修改错误。

31.不可重视的错误会是公司能够交付的最昂贵的缺陷。有事程序的表现没有办法重现。看到程序错误一次,但不知道如何使其再次出现。如果产品交付客户后还出现这种情况,会影响客户对产品的信心。在报告不可重现的程序错误时,要明确说明自己不能重现这个程序错误。

32.当报告小缺陷时,要特别注意使报告简明,并经过充分分析。当要报告一个不可重现的程序错误,特别是在项目后期时,需要格外注意努力重现该程序错误。如果做了大量后续测试任然不能重现产生该程序错误,则说明这个程序错误是不可重现的,并描述操作的定位工作,以及所遇到的程序错误征兆

33.注意自己的语气,所批评的每一个人都会看到报告。错误报告带有责备或居高临下的语气是没有溢出的。称程序员不够专业、思想保守或愚蠢都是得不偿失的。

34.使自己的报告具有可读性,即使对象是疲劳和暴躁的人。要使重现步骤的描述简洁

一次只走查该程序错误一步

为每一步编号

不要跳过重现问题所需的任何步骤

列出使读者能够重现失效的最少步骤集

通过空行使报告更容易浏览

使用简短句子

说明实际发生了什么,自己预期会发生什么

如果后果很严重,但是测试员有理由怀疑程序员不理解为什么很严重,可解释为什么自己认为很严重

要始终保持中立语气

35.测试惰性不能成为程序错误修改推迟的原因。

如果测试经理要求程序员不要修改程序错误,只因为修改会影响太多的检查单、脚本或其他测试工作制品,因此要占用太多的管理时间,那么说明测试过程存在致命缺陷

36.自动化测试目标:迅速检查出新版本中的不稳定更新;尽可能迅速暴露回归程序错误;尽快报告问题,因为这会使程序错误修改更容易

37.拓展测试领域,不要不断重复相同的测试,离开自动化测试就不能完成某些测试,而另外一些自动化测试则会大大扩展测试范围。

负载测试

性能基准测试

配置测试

耐力测试

竞争条件

组合错误

38.为了有效地应用解决方案,需要清楚地理解问题

39.使用IEEE标准829作为测试文档

 

1.首先测试逻辑较复杂的部分,然后测试逻辑较简单的部分。逻辑较复杂的部分在用例阶段使用测试思想尽量将可能性考虑全面

 

内容来源于网络如有侵权请私信删除

文章来源: 博客园

原文链接: https://www.cnblogs.com/qm1219/p/16310500.html

你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!