软件测试经验与教训之测试工程师如何思考?如何测试?
1.研究认识论更有助于软件测试,以下是直接与软件测试有关的认识论
1】拥有合理的理念意味着什么
2】自然语言的含义与模糊性
3】如何使用不同的逻辑形式
4】形式和非形式推理之间的差别
5】如何进行有效的推论
6】如何收集与评估证据
7】如何做出好的决策
2.很多人认为测试很简单特别是手工测试。因为即使是优秀的测试工程师和普通的测试工程师表面上看上去没有多大的区别。就算是很难发现的bug在你发现了之后,别人也会觉得不过如此。
3.测试工程师在设计测试的时候头脑中可能会有一个想象的图景,知道自己想要得到的结果是什么。这都是基于某个产品模型,如果这个模型是有缺点的,那么测试也是有缺点的。
因此要不断的完善模型,学会一种模型就是学会了观察产品的一种方法
4.测试不但要做输入和输出和预期结果的比较,还要进行推断。产品文档肯定不会把细节全部写清楚,作为测试不能每一个问题都去问产品因此需要自己推断。
5.作为产品一致性是评估程序的主要标准
- 与历史一致。现在的功能行为与以前的行为一致。
- 与我们的想像一致。功能行为与机构的项目预期一致。
- 与可比较的产品一致。功能行为与可比较产品的类似功能一致。
- 与所声明的内容一致。功能行为与承诺提供的功能一致。
- 与用户的预期一致。功能行为与我们认为是用户想要的功能一致。
- 产品内部一致。功能行为与产品内部可比较的功能或功能模式的行为一致。
- 与用途一致。功能行为与明确的用途一致。
6.为了很好的测试产品,测试工程师必须研究她。必须深入她。这是一种探索的过程
探索测试可以通过前向思索,后向思索,侧向思索的方式来测试
前向测试:根据已知的探索未知的,从所看到的探索还没有看到的,注意支流和副作用。例如:看到打印菜单项,点击一下会发生什么情况。 有可能是让你选择要打印的内容,有可能是提示 你没有权限等等。
后向测试:从怀疑或者想象的东西,返回已知的,尝试证实或者否定自己的推测。 例如:可以查看文件,那有没有打印文件的方法呢??打开菜单看有没有打印的选项。
侧向测试:自己的工作由于新冒出的想法而转移,然后再将探索主题回到主线索上。 例如:看到一张很有意思的图片,那可以打印更复杂的图吗??
7.使用诱导推断逻辑发现推测
【诱导推断是测试工程师每天使用的关键推理形式】
- 收集一些数据并要找出其中的意义
- 构造可能说明这些数据的各种解释
- 收集更多的证据,以确定或否定每种解释
- 从候选解释中,选择能够最一致地说明所有重要数据的解释,如果没有足够的证据证实任何结论,则继续探索
当测试在判断产品是什么而不是什么,产品应该怎么样运行或不应该怎么样运行是可以使用诱导推论
- 1.收集更多的数据
- 2.收集更重要的数据
- 3.收集更可靠的数据
- 4.理解应用于数据的原因和结果
- 5.找出数据可以更多,更好的解释,只要找到了某个解释可以说明所有重要数据,并且明显得到比其他解释更好的解释,那么就可以确定这个解释
- 6.收集更多否定每个解释的数据
- 7.收集更多区分解释的数据
【尽管诱导推断过程并不提供绝对确定性,但是多数情况下这都是最佳手段】
8.使用猜想与反驳逻辑评估产品
以下三种猜想并尝试反驳的方法可以应用于测试和评估产品
1.测试的目的是显示产品是失败的,要比显示产品是正常更有利,寻找方法反驳其正常运行。
2.有关软件(软件有怎样的行为,如何好等)已经牢固形成的信念应该受到质疑。这样才会用各种方法来把这个信念给超越
3.需要警惕,有人声称运用了各种方法来确认了产品的测试。任何量的测试都不能提供产品质量的确认性。
作为测试工程师必须认识到谁的关于质量的观点最重要(并不是每个人的观点同等重要) ,然后了解对于产品他们要什么,不要什么。
9.测试至少包含以下四种活动:
。配置:准备要测试的产品,要将其置于正确的初始状态。 否则测试结果会受到不良 变量的影响
。运行:向产品输入数据,向产品发布命令,以某种方式与产品交互。
。观察:收集查看产品有关行为信息,输出数据,系统的整体状态,与其他产品交互等方面信息
。评估:运用规则,推理或可检测所观察到数据中存在问题的机制。
10.测试复杂产品时:可以先研究复杂的产品30分钟或一小时。然后拆解成单个功能,单个流程。经过几次轮回后,就会明白产品的模式以及轮廓,这样就可以更系统更具体的测试和研究策略
但是即使是这样时间长了以后测试工程师依然会脑子一团浆糊,因此需要停下来干点别的,如上个厕所,抽颗烟
11.运用试探法快速产生测试思路,以下是采用试探法测试的一些例子:
。测试边界【即边界值分析法】:
。测试所有错误信息:错误处理的代码与一般主流代码相比,一般比较弱
。测试与程序员的配置不同的配置:程序员已经配置好的,基本上已经测试过了。
。运行比较难设置的测试:容易配备的测试更有可能被执行过
。避免冗余测试:重复的测试产生的价值很小
12.测试工程师在测试的时候总有些偏向,如需要输入很长的一段字段,很多人输入111111111 这些相同的数字,因为输入字符重复的字符串比输入0到9 更加省事。
还有碰巧遇到的用户对产品的意见,放在了更重要的地位。因此测试工程师需要抵御这种偏向,一般可以通过多样化测试可以抵御过强的偏向,集体讨论也可以把一个测试工程师的偏向降到最低
13.测试工程师可以把用户想的笨一些,把自己想的笨一些,可以发现更多的问题。
14.要注意其他测试员所发现的自己本来也可以发现,但是却没有发现的问题
如果遗漏一个问题,检查这种遗漏是只是碰巧没有发现那个特定的问题还是测试策略的遗漏了。如果是测试策略遗漏了则要改进测试策略。
15.测试工程师感到困惑时,一定要提出来。如对产品感到困惑,对逻辑感到困惑。要提出别人不敢提的问题
第一次接触产品或功能时,要注意使自己困惑和烦恼的地方。可能用户在使用的时候也会有这个烦恼
与团队新成员一起工作时,观察他们在了解 产品时的反应
16.警惕陷入测试惯例。对某个特定的功能太熟悉了,导致运用越来越窄的方式进行测试
17.设计测试用例的时候避免过于详细,要让测试员有创造性和判断力的执行用例。 如 :测试搜索的时候,要搜索 以权天下,设计模糊搜索的时候,可以直接写模糊搜索而不是 写 输入 以权进行搜索
18.重新发明东西至少有两个原因:通过改造使其适应新条件,了解其工作原理。而要掌握他,这两个方面都需要。 要想精通测试也要掌握这两点
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!