51Testing软件测试论坛

标题: 测试不能深入，好着急。希望前辈指点指点！ [打印本页]

作者: 行走中 时间: 2010-12-23 20:04
标题: 测试不能深入，好着急。希望前辈指点指点！
我把自己的工作向前辈陈述一下：
新模块提交后，我要做的：
1、首先要测试用例：
流程校验的用例，分异常和正常：每个节点都必须写清楚，当然这个过程必须保证自己是完全明白了新模块的流程。不是做表面工作。
页面校验的用例，分异常和正常：页面的新增内容必须写到
功能校验的用例，分异常和正常：增、删、改、查最常见，每个都要有正常和异常。页面上的每个按钮都得写到
总结：写的不是特别具体，但大致就是这么写用例的。一般情况下，我都特别注意写异常用例，尽量把自己考虑到的异常情况都写出来。但毕竟自己才工作没多久，身边的测试前辈有限，所以不知道自己的用例还有哪方面要注意的，我很想提高自己写测试用例的能力。希望前辈指点！！
2、执行测试
按自己写的用例执行测试，同时这也是检察自己用例写的是否正确、详细的过程。当然页面校验和功能校验要即兴多想，多测。工作时，一般是遇到问题先记录下来，然后及时和开发沟通。
3、提交BUG
公司用的是QC，“BUG的摘要”，我是按系统的导航写。这是提高文字沟通能力的最直接途径，但要想描述好一个BUG对目前的我来说，是要花一些时间的。不知道前辈能不能给我指点一下描述BUG时应该注意的问题？以及我要怎么提交自己的文字沟通能力？
4、回归测试
在学校的时候，总觉得写用例花费时间好多，还不如多测出几个BUG来得实在。但现在是真的认识到写好的、详细的、准确的用例是有很大好处的。回归测试时就足见其作用。项目快上线时，哪有时间再一点儿一点儿看需求，理思路。如果有好的用例，按照它执行一遍，效率应该很高的。我自己这样觉得，也不知道对不对？

这基本上就是我目前全部的测试工作。马上要压力测试了，到现在一点儿想法都没有，还不知道怎么弄呢？

常见的功能测试点总结了一些，虽然是东拼西凑，但觉得还是比较详细。可我目前好想就停留在了这些浮浅的问题上，根本不知道还要往什么地方考虑？开发新做的页面，我相信自己能测的很详细；可如果是开发修改原来的，我就一头雾水了。我不知道自己的问题出在哪儿？迷茫中！

作者: piaomiaoheng 时间: 2010-12-23 23:54
我觉得首先是开发的文档要全，比如需求说明书，概要说明书等等，然后你先写测试方案，分析被测模块之间的关系，可以和开发沟通，从开发需求对应测试需求，写测试点，根据点细化到用例，这样下来用例就水到渠成了

作者: 行走中 时间: 2010-12-24 09:57
回复 2# piaomiaoheng
我们公司有需求说明书，设计说明书，就是没有测试需求说明书。我也没见过真正的测试需求说明书，不过相信随着工龄的增加，能接触到这个文档。谢谢

作者: 微笑流淌 时间: 2010-12-24 10:21
回复 3# 行走中

测试需求说明书？？只有需求说明书的吧！

作者: 行走中 时间: 2010-12-24 11:10
回复 4# 微笑流淌
根据需求说明书编写测试需求说明书。有的呀!

作者: 微笑流淌 时间: 2010-12-24 11:21
回复 5# 行走中

哦，以前没有听说过这个名字！以前看到好多都是根据需求说明书来写测试计划、测试用例的。
学习了！

作者: 懂行 时间: 2010-12-24 15:03
前来向给位前辈学习

书村网玄幻小说阅读网小说8090 野蛮王座争隋官声叛逃者篡唐官场新贵龙蛇演义武神仙葫武装风暴

作者: 懂行 时间: 2010-12-24 15:05
帮顶一下，我也是新手

书村网玄幻小说阅读网小说8090 野蛮王座争隋官声叛逃者篡唐官场新贵龙蛇演义武神仙葫武装风暴

作者: Gasgoo 时间: 2010-12-24 16:01

顶。。。

作者: 行走中 时间: 2010-12-24 16:53

作者: ailen1986 时间: 2010-12-24 17:37
楼主写的很不错啊，体会不错呵呵很给力啊！

作者: liaojuan 时间: 2010-12-27 09:53
回复 1# 行走中

有同感顶下，希望有经验前辈给力

作者: fishthirtythree 时间: 2010-12-27 14:04
来学习学习

作者: wangsc_testing 时间: 2010-12-27 14:43
工作中我们不可能永远都测试的是新系统，很多时间我们都在测试修改过的系统。对于修改的系统，先搞清楚为什么修改的，一般原因有二：一是需求发生变化，二是系统缺陷修复。对于原因一，若有需求变更文档，那最好不过了，按照文档来设计测试，若没有需求变更文档，也不用迷茫，完全可以把需求变更当做系统缺陷修复后进行回归测试一样来做，你只要找到与修改部分相关联的功能模块，对其进行合理有效的测试，相信没有什么问题，当然，对于需求变更带来的“回归测试”需要考虑的更多一定，更细致一点；对于原因二，就不用说了，回归测试的测试要点相信你知道。

作者: 行走中 时间: 2010-12-27 15:15
回复 14# wangsc_testing
谢谢前辈指点！

作者: pztanglin 时间: 2010-12-28 09:17
我个人觉得这样的流程是比较合理的
根据客户需求 - check -->
开发的产品需求说书  - 提取 -->
产品功能列表  - 编写 -->
测试用例  - 搭建 -->
测试环境 - 执行 -->
测试用例 - 提交 -->
测试报告 - 执行 -->
回归测试 - 提交 -->
测试报告 - 总结 -->
测试经验和需要的改进点

作者: yff20080818 时间: 2010-12-28 15:43
继续关注中。。。

作者: slm601 时间: 2010-12-29 10:09
关注中。。。

作者: zyy0818 时间: 2010-12-29 16:58
回复 14# wangsc_testing

学习了^6^

作者: 行走中 时间: 2010-12-31 09:17
up

作者: lemon206135 时间: 2011-1-8 11:26
不错~

作者: 卟給力吖 时间: 2011-1-9 16:50
测试人员一般都是按照需求规格（也可称作设计规格或需求说明）来编写测试方案，再根据方案细化到测试用例

作者: caoase 时间: 2011-1-10 22:30
这个问题比较多，俺一个一个来回答。
不知道前辈能不能给我指点一下描述BUG时应该注意的问题？以及我要怎么提交自己的文字沟通能力？
这里要注意重现BUG的步骤要清晰，要一脉相承，就是说最好公司能有一个比较稳定的格式。这样，开发重现BUG的时候，看报告就很容易了。
回归测试时就足见其作用。项目快上线时，哪有时间再一点儿一点儿看需求，理思路。如果有好的用例，按照它执行一遍，效率应该很高的。我自己这样觉得，也不知道对不对？
系统部稳定的时候，自动化的效率比就一点几，远远比不上手动灵活，但是做回归测试的时候，效率能够提高千倍这很正常。
常见的功能测试点总结了一些，虽然是东拼西凑，但觉得还是比较详细。可我目前好想就停留在了这些浮浅的问题上，根本不知道还要往什么地方考虑？开发新做的页面，我相信自己能测的很详细；可如果是开发修改原来的，我就一头雾水了。我不知道自己的问题出在哪儿？
开发对项目进行变更的回忆你最好参加，然后，最好能根据开发文档和需求文档，自己做一份简略的测试计划或者测试方案。

作者: 行走中 时间: 2011-1-11 09:27
回复 23# caoase
谢谢了。受益

作者: 061001 时间: 2011-1-11 09:42
都说的挺好的，顶一下

作者: zwb131442 时间: 2011-1-28 15:53
感觉你只把表面的功能覆盖掉了，那么请问，逻辑性的呢？
你写的用例是否是根据公司业务流程来写的？
逻辑性的缺陷，往往需要对公司业务熟悉，不然只能表面。

作者: zwb131442 时间: 2011-1-28 15:55
如：【关联】按钮，【并文】按钮，两者的关联，曾经测出11个缺陷。
所以举一返三很重要
希望对你有帮助

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)