如果你有一个苹果，我有一个苹果，我们交换以后还是一人一个苹果，但如果你有一种思想，我有一种思想，我们交换以后，每个人便拥有了两种思想。

我的测试思路

上一篇 / 下一篇  2007-06-26 08:09:24

查看( 2132 ) / 评论( 24 ) / 评分( 14 / 0 )

我的测试思路

比如接到一个模块的测试任务，我首先看这个模块上有多少个功能点，统计后思考测试所要占用的时间。随机在模块上做一些功能操作，主要查看各种连接是否正确，用专业语言讲就是“冒烟测试”。然后在看界面上的布局，是否美观、是否符合公司UI设计规范的要求。

初步的测试后，就要详细对每个功能点下功夫测试。测试功能点从上到下，或者从左到右依次的进行测试。可以用个记事本把需要测试的功能点记录下来，如果测试过就在功能点后面打勾，避免遗漏。测试的前提就是要熟悉所要测试模块的需求，有的时候可能忘记了需求就要查看需求文档或者与系统需求工程师沟通确认。避免直接与开发人员沟通模块上的功能使用，开发人员的思路可能会左右你的测试思路。

首轮做的是界面测试主要查看界面的设计风格和界面中文字的测试，逐字看有无错别字；提示框信息是否有语病。接下来的测试就要查看一些易用性的操作。第二轮主要是测试功能点就是要输入一些正常值，保证功能可用。输入的值可以正常显示，功能基本满足需求等。如上述测试都满足，第三轮的测试就要一些非法值也就是健壮性的测试。在输入框或者查询框中可用输入一些特殊字符，看能否正常保存或者有无查询结果。也可以做一些超长字符和边界值的操作，此时要对比数据库设计和需求中数据字段所要求的长度。在这些测试过程中可能会出现一些非法的操作，同时要查看系统有无友好提示。比如必添项没有添写要有提示框；删除时的提示框等。

上面说的是单个模块的测试，如果模块间有接口，这个接口上的测试在集成测试阶段是必不可少的。测试方法也有几个，比如说数据流的测试，数据流能否正确的从前一个环境流转到下一个环节，如有回退情况能否正常回退。用户管理上的测试就与权限和登录关系密切。这些都属于多个模块的接口测试。如果有与硬件系统相关的接口，那么硬件方面的联动测试也是不可缺的。

测试的最后一个环节就是要执行测试用例，公司内所撰写的测试用例基本上都概括了需求，虽然用例上的case可能不满足测试的全部要求，但是满足需求的内容，走一遍测试用例就避免了需求上功能的遗漏。

以上是我个人的测试方法，大家有好的方法可以与我沟通，相互学习。

下面总结了一些测试时常用的特殊字符，给开发人员一个参考。

特殊字符

！◎＃￥％……※×（）——＋§』『“：？』《～卍卐

~!@#$%^&*()_+|{}:”<>?,./;’[]= -☆☉♂△◇◆ф℅℉‰я↖∈∏∑∨∧∞√≌⊕⑦⒀∷┎┡╬╮

<td> </td>  < > </>

数字

1234567890

字母

ABCDEFGHIJKLMNOPQ

Abcdefghijklmnopq

汉字

壹贰叁肆伍陆柒捌玖拾

UNICODE编码

伂伉伄佸伨侃侂佢輲鼲缴縲

 


收藏 举报

TAG:

andrewli的个人空间 引用 删除 andrewli   /   2011-11-07 10:48:34
评 5 分
引用 删除 zll19827   /   2011-11-04 14:41:01
评 1 分
Mr.曾的个人空间 引用 删除 Mr.曾   /   2011-10-30 17:39:52
得先感谢下bambooluzhu  将博主挖出来，时隔3年多了也， 总得来说同意博主的观点， 测试人员不能乱测，所谓的随机测试，本质上也是一种测试方法，但是在整体的测试把握上的确是需要分步骤的，根据每个人的习惯和环境不同，这个顺序可以不一样，但必须要有。有了步骤后，你的测试线条就非常清晰，遗漏的地方就要小很多了
Mr.曾的个人空间 引用 删除 Mr.曾   /   2011-10-30 17:39:47
评 5 分
引用 删除 wendi1986   /   2011-10-29 18:58:33
感觉楼主分析的很细，测试每个公司都不同的，所以我们这边都是按照普遍流程来做测试分工，各有个的不同吧。个人认为
引用 删除 wendi1986   /   2011-10-29 18:57:08
评 3 分
引用 删除 yantl88   /   2011-10-26 22:57:38
我塞，大哥，您做测试好多年了吧
引用 删除 bambooluzhu   /   2010-09-07 10:55:22
对我还是有帮助的
开车兜风 引用 删除 ruanyongjie   /   2007-07-09 20:34:25
没有介意,没有介意,非常感谢
我测故我在 引用 删除 caicai1724   /   2007-07-09 17:50:54
呵呵,实践是检验真理的唯一标志,是好是坏,从测试工作执行结果和产品发布以后的用户反馈中就可以看出的,我只是以我以往的经验说出了我的想法,呵呵,别介意哈.
开车兜风 引用 删除 ruanyongjie   /   2007-07-06 09:48:39
只能说各人对于所测试对象的思路和侧重点不一致，各有各自的想法。
逆水行舟 引用 删除 魔海   /   2007-07-03 22:26:40
不管时间是不是紧，随意性的测试只能在软件测试后期才开始做。虽然随意性的测试可以发现一定的bug，但这终究是“芝麻”。每一次的测试是要有详细计划的，不能随意。比较同意zuima2141的观点。
逆水行舟 引用 删除 魔海   /   2007-07-03 22:00:35
博主的软件应该是给国外客户的吧？我也测试过类似的软件，客户对界面显示效果要求非常严格，所有的显示效果包括字体及大小都必须得到客户的确认。如果你们的前提是功能及逻辑都没有问题的话，这样测试还是可以的。
开车兜风 引用 删除 ruanyongjie   /   2007-07-03 08:35:01
上述的测试思路，是针对单个模块的测试，而不是对整个软件系统的测试， 所以我个人觉得没有什么“测试策略”只是单纯的单元测试和功能测试。
对于你说的这句话“好的测试最忌讳“随意性”，我的看法和你不一样，我觉得“随意性”测试很重要，如果测试时间紧的话我首先采取“随意性”测试然后再去按照相关的流程走，这要可以节省很多时间，如果时间富裕的话那么就先严格的走完各个流程，最后进行“随意性”测试这样可以把遗漏的部分找到，谢谢
随阳的个人空间 引用 删除 zuima2141   /   2007-07-02 23:06:01
看来你们公司的测试还处于原始阶段阿，不要介意，没有贬义。处于同行的角度，发表一下看法。
哪些功能点，哪些需要加强，等到测试的时候再考虑，已经晚了。这些在开发进行需求分析，到概设之前就应该有了，也就是所谓的“测试策略”，要保证一点，开发转测试之后，测试是按既定方案执行的。因为好的测试最忌讳“随意性”。猴子测试方法也是在严格测试流程测试之外的一种有益补充，绝对不是主流测试方法。
拿到转测试的版本，才开始分析测试重点，测试步骤，这已经是很“随意了”。：）
开车兜风 引用 删除 ruanyongjie   /   2007-06-29 23:06:29
没有记错的话 "caicai1724" 南昌大姐，首先要说明一点我不是"做表面工作"而我公司和客户对界面这方面有比较严格的要求,所以我的思路是先测试界面后测试功能.　如果你有什么建议还望指点，谢谢
我测故我在 引用 删除 caicai1724   /   2007-06-29 17:47:00
我比较同意魔海的观点,就测试的目的来说,你没有抓住重点测试.
我测故我在 引用 删除 caicai1724   /   2007-06-29 17:44:11
"系统功能我的测试原则是先让开发人员修改界面问题后再修改功能问题。因为我公司客户对界面有特别高的要求，还有如果部分原因是修改完系统的功能后 部分系统的界面很难调整。"
很奇怪的现象,界面要求反而高于功能,无法理解,这样重点做表面功夫,很容易出问题的.
开车兜风 引用 删除 ruanyongjie   /   2007-06-28 16:59:35
谢谢 “魔海"大哥的指点，  是这样的在我们公司里系统的逻辑验证在原型评审会上就会提出来的包括系统的界面设计，若有问题，是要等原型修改确定完成后，才开始开发的，所以我们在这方面很少存在问题，甚至没有问题。而我在测试过程中不会刻意去查找此类问题。而系统功能我的测试原则是先让开发人员修改界面问题后再修改功能问题。因为我公司客户对界面有特别高的要求，还有如果部分原因是修改完系统的功能后 部分系统的界面很难调整。 所以我的测试思路是这样的～
逆水行舟 引用 删除 魔海   /   2007-06-28 16:37:58
测试的主要目的是尽可能多的发现系统存在的问题，但是就目前的测试工作来说，主要工作是在验证系统是否正确实现了用户的需求。
所以我的建议是把系统功能及逻辑的验证放在首位，而此类bug在修复的时候应该是最消耗时间的。这样的问题越早发现及解决对整个项目的进度及质量绝对有好处。
而您认为的测试用例的用途过于简单，或者是写的过于简单，你说的一、二、三轮的测试应该都是包含在测试用例中的，而你做这些测试只是测试用例中某些用例对应的测试数据。
个人观点，尽供参考。
 

评分：0

我来说两句

Open Toolbar