测试不能深入，好着急。希望前辈指点指点！

行走中 · 发表于 2010-12-23 20:04:08

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

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

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

zwb131442 · 发表于 2011-1-28 15:55:19

如：【关联】按钮，【并文】按钮，两者的关联，曾经测出11个缺陷。
所以举一返三很重要
希望对你有帮助

zwb131442 · 发表于 2011-1-28 15:53:16

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

061001 · 发表于 2011-1-11 09:42:10

都说的挺好的，顶一下

行走中 · 发表于 2011-1-11 09:27:15

回复 23# caoase
谢谢了。受益

caoase · 发表于 2011-1-10 22:30:04

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

卟給力吖 · 发表于 2011-1-9 16:50:47

测试人员一般都是按照需求规格（也可称作设计规格或需求说明）来编写测试方案，再根据方案细化到测试用例

lemon206135 · 发表于 2011-1-8 11:26:34

不错~

行走中 · 发表于 2010-12-31 09:17:53

zyy0818 · 发表于 2010-12-29 16:58:24

回复 14# wangsc_testing

学习了^6^

slm601 · 发表于 2010-12-29 10:09:50

关注中。。。

yff20080818 · 发表于 2010-12-28 15:43:59

继续关注中。。。

pztanglin · 发表于 2010-12-28 09:17:02

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

行走中 · 发表于 2010-12-27 15:15:33

回复 14# wangsc_testing
谢谢前辈指点！

wangsc_testing · 发表于 2010-12-27 14:43:16

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

fishthirtythree · 发表于 2010-12-27 14:04:02

来学习学习

liaojuan · 发表于 2010-12-27 09:53:34

回复 1# 行走中

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

ailen1986 · 发表于 2010-12-24 17:37:04

楼主写的很不错啊，体会不错呵呵很给力啊！

行走中 · 发表于 2010-12-24 16:53:18

Gasgoo · 发表于 2010-12-24 16:01:54

顶。。。

		自动登录	找回密码
密码			(注-册)加入51Testing

[原创] 测试不能深入，好着急。希望前辈指点指点！

站长推荐 /1