写给测试小白：怎么快速找到bug？怎么写测试用例？

软件测试工作中找bug就是这个岗位本身立足的职责，那么对于很多新人和新入行的同学们来说，这个过程会有点苦逼，毕竟经历的项目经验不多，想快速的切入寻找bug往往会比较痛苦。

那下面我就以自身的经验来普及下如何在工作快速找出系统的不足或缺陷。

1、熟悉你做的产品

不管你是Dev、Test或者PM，熟悉自己开发的产品越多越好，你不但应该熟悉自己开发的模块，也应改熟悉和自己模块相关的其他模块，他们之间是怎样协作的。比如数据库中的某个字段，是如何被各个模块使用的，这利于你在设计阶段就能够找到Bug，把修复的成本降到最低。

同样，你需要熟悉这个产品以前的版本，因为无法向后兼容和升级的产品恐怕很难获得用户的认可。在测试过程中，如果你发现你的产品和以前不兼容或者不一致，80％的情况，这是一个Bug。

2、尽早的去发现Bug

我们大家都知道，Bug修复的成本是和Bug被找到的时间成指数关系的。越早开始找Bug，你能找到的Bug也就越多，对项目的贡献也就越大。

3、每天Review别人的Bug

如果你的团队没有每日的Bug Report，我建议你们建立一个，其实技术上应该没有任何的难度，通过Bug追踪系统的API或者数据库，你完全可以得到你要的数据，这样，整个团队通过学习每天察看别人的Bug，你可以更加容易发现Bug，也不会发现那种Duplicated Bug。现在经常有人跑过来问我，某个Bug是不是一个已知的问题，因为我每天都看Bug Report。

4、在你的日常生活中多准备一些测试的模式

模式是一个很时髦的词，因为它很有用。在日常的测试中，多准备一些测试模式，你会有非常大的惊喜，有时候一个使用一个模式，你可以找到10来个Bug也不是不可能的。比如，使用特殊字符作输入数据；断开网络看UI是否会Crash；在本地化版本中，各个字符串提示是否被本地化；

5、多测试各个模块之间的合作

各个模块之间的测试往往是我们测试中的薄弱点，对于用户来说模块间的合作却至关重要。往往一个数据在模块A中是合法的，在B中却是非法的，一定要找出这些数据，往往者都是Bug

6、编写自动测试代码

你肯定不原意每天都去做同样的事情，那样太没有意思了，简直就是对你的智慧的侮辱。但是一旦我们不进行这些测试，突然有一天早上，我们发现我们的产品以前能够很好工作的功能突然就不工作了，于是大家乱作一团，有人急着修复它，有人在找是谁Check in的。

7、查看产品代码

通过查看产品代码，你往往能找到一些Dead Code或者逻辑上的Bug，这些Bug常常是你无法通过手工测试找到的。

初次怎么写用例？

有很多朋友初次写用例，不知道从何下手，虽然有的公司给出了相关说明文档，但是写起来还是不能得心应手，编写用例方法有很多种：功能导向用例（边界值、等价类等等），用户导向用例（场景法），用户、功能相结合导向用例……

那么对于初次编写用例，应该怎样高效率的编写用例？应该注意点什么？

一、功能导向用例是按照系统需要达到的每一个功能，进行编写用例，这样的用例着重点在功能实现上，而没有考虑到每个功能之间的关联，因而虽然用例已经达到功能覆盖，却不一定达到逻辑覆盖，因而这种方法通常会和其他方法结合使用。功能导向用例是每个用例编写者前期最常用的方法。

二、用户导向用例是按照用户的习惯，将用户使用系统的每个目的作为一个目标，以每个目标实现为基点设计测试用例，但是设计这一类用例，初写者，可能会产生很多困惑（下面写一下我第一次写的时候有哪些困惑，并针对这些困惑，后来采取了怎样的解决方案）

1、编写用例的第一步我该做什么？

理解系统，首先站在测试的角度深入理解系统的每个功能与系统业务逻辑，画出业务逻辑图（即：系统能做什么）。

其次站在用户的角度，列出用户使用系统的目的（即：用户使用这个系统，想干什么？）

2、怎样确定用户目标？

不能确定用户目标，可能由2方面原因造成:a>对系统不够熟悉，b>不了解用户背景。对于第一点原因，那是你自己的原因，只有回过去头看文档了，对于第二点原因，可以从‘系统能做什么’推算出‘用户可以做什么’然后再总结出‘用户可能想做什么’，当然这样做的前提是你对系统已非常熟悉。

3.这个月我将做什么？

刚进入测试行业是怎样总结的（利用测试管理工具进行总结）：

1）把测试管理工具中的缺陷全部分类导出，总结一下哪些模块容易产生哪些缺陷，重点看一下自己没发现或没有考虑到的缺陷。

2）如果说测试新人工作的第一层次是从执行用例开始，那么第二层次就是编写测试用例了。把测试管理工具中的用例详细看几遍，学习别人的用例编写方法和思想，空闲时间可以自己试着编写，看自己编写的与别人编写的用例差距在哪，从而不断完善。重要说明；着重用例编写方法和思想的学习，而不要死搬硬套。

3）进入一些测试论坛，把自己的困惑和经验和大家一起分享，在学习中，不断进步。

总结：

正所谓功夫在诗外，测试理论知识就是那么多，理论知识掌握之后就要不断的参与到项目中来，一个一个项目的练习，锻炼自己的发现Bug的能力，就算随机测试，一个好的测试和一个坏的测试，他们发现问题的能力也是完全不同的。以上完全是个人的一点体悟，未必上的了台面，各位看官，看的时候也请多多指教。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31407649/viewspace-2639293/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31407649/viewspace-2639293/