写给测试小白:如何快速找到bug？如何写测试用例？
在软件测试工作中找到bug是这个职位本身的责任，所以对于许多新生和新生来说，这个过程会有点痛苦，毕竟，项目经验不多，想要快速切入寻找bug往往更痛苦。
{img}685c6b9424fda94
下面我就用自己的经验来普及如何在工作中快速发现系统的不足或缺陷。
1、熟悉你做的产品
不管你是Dev、Test或PM，熟悉自己开发的产品越多越好。你不仅要熟悉自己开发的模块，还要改变与自己模块相关的其他模块，以及它们是如何合作的。例如，数据库中的一个字段是如何被每个模块使用的，这有助于您在设计阶段找到bug，并尽量降低维修成本。
同样，您需要熟悉本产品的以前版本，因为未来无法兼容和升级的产品可能很难被用户认可。在测试过程中，如果您发现您的产品与以前不兼容或不一致，80％这是个bug。
2、尽快发现bug
众所周知，bug修复的成本与bug被发现的时间成指数有关。越早开始找bug，能找到的bug越多，对项目的贡献越大。
3、每天Review别人的bug
如果你的团队没有每天的bugreport，我建议你建立一个。事实上，技术上应该没有困难。通过bug跟踪系统的API或数据库，您可以获得您想要的数据。这样，通过每天学习观察他人的bug，整个团队更容易找到bug，也不会找到duplicatedbug。现在经常有人跑过来问我一个bug是不是已知的问题，因为我每天都看bugreport。
4、在你的日常生活中准备更多的测试模式
该模型是一个非常时尚的词，因为它非常有用。在日常测试中，准备更多的测试模式，你会有一个很大的惊喜，有时使用一个模式，你可以找到10个错误并非不可能。例如，使用特殊字符作为输入数据；断开网络查看UI是否会显示；在本地化版本中，每个字符串提示是否本地化；
5、多测试各模块之间的合作
每个模块之间的测试往往是我们测试的弱点，但模块之间的合作对用户至关重要。通常，模块A中的数据是合法的，但B中的数据是非法的。我们必须找出这些数据，通常是错误的
6、编写自动测试代码
你当然不打算每天做同样的事情，这太无聊了，这只是对你智慧的侮辱。但一旦我们不做这些测试，突然有一天早上，我们发现我们的产品以前可以很好地工作，所以每个人都很混乱，有些人急于修复它，有些人正在寻找谁。
7、查看产品代码
通过查看产品代码，您经常可以找到一些DeadCode或逻辑bug，这些bug通常是您无法通过手动测试找到的。
第一次怎么写用例？
有很多朋友第一次写用例，不知道从哪里开始，虽然有些公司给出了相关的解释文件，但写作仍然不方便，有很多方法：功能导向用例（边界值、等价类等），用户导向用例（场景法），用户，功能结合导向用例。
那么对于第一次编写用例，应该如何高效地编写用例呢？应该注意什么？
1、功能导向用例是根据系统需要实现的每个功能编写用例。该用例侧重于功能实现，而不考虑每个功能之间的关联。因此，虽然用例已经达到功能覆盖，但不一定达到逻辑覆盖，因此该方法通常与其他方法结合使用。功能导向用例是每个用例编写器早期最常用的方法。
2、用户导向用例是根据用户的习惯，以用户使用系统的每个目的为目标，以每个目标的实现为基础设计测试用例。然而，对于这类用例的设计，初学者可能会有很多困惑（以下是我第一次写作时的困惑，以及我后来采取了什么解决方案）
1、编写用例的第一步我该怎么办？
了解系统，首先从测试的角度深入了解系统的每个功能和业务逻辑，绘制业务逻辑图(即系统能做什么)。
其次，从用户的角度列出用户使用系统的目的(即用户使用该系统时想做什么？)
2、如何确定用户目标？
由于两个原因，无法确定用户目标：a>不熟悉系统，b>不了解用户背景。第一个原因是你自己的原因。你只能回去看文档。对于第二个原因，你可以从‘系统能做什么’中计算出‘用户能做什么’，然后总结‘用户可能想做什么’。当然，这样做的前提是你对系统非常熟悉。
3.这个月我要做什么？
如何总结刚进入测试行业(使用测试管理工具进行总结)：
1)分类导出测试管理工具中的所有缺陷，总结哪些模块容易产生哪些缺陷，重点关注未发现或未考虑的缺陷。
2)如果测试新工作的第一级是从执行用例开始的，那么第二级是编写测试用例。详细阅读测试管理工具中的用例，学习他人的用例编写方法和想法。你可以在业余时间试着自己写，看看你写的和别人写的用例之间的差距，以便不断改进。重要说明；注重用例编写方法和思想的学习，而不是僵化。
3)进入一些测试论坛，与大家分享自己的困惑和经验，在学习中不断进步。
所谓的功夫在诗歌之外，测试理论知识是如此之多，理论知识将继续参与项目，一个项目实践，锻炼他们发现错误的能力，即使随机测试，好测试和坏测试，他们发现问题的能力是完全不同的。以上是一点个人理解，不一定在桌子上，你看官员，也请阅读更多的建议。
