测试前的准备！这个让我好头痛！矛盾中！请大家赐教！

lulu8120

业务确定，UC/UI确定，编写db这个时间段测试组一般做那些测试前 准备工作？

一开始整理业务，整理操作流程，然后确定操作人员！再整理模块间的业务关联。
等DB确定后，我开始整理每个模块相关的TABLE，以及所涉及到的状态字段。（由于写测试用例，实在是件费时的活，再加上公司对文档没有要求，所以没有写）

对于功能测试做到以上，我觉得都很费时间了，而且很矛盾
1、需要费时间在这么多事情上嘛？
2、真正提交测试后，这些整理的文档能用上多少？
3、是不是有必要做这些！？
4、还是，有更合理更需要考虑的我没想到？……:s

TestTip

没有人写需求吗？测试人员不负责写需求，而是去理解需求。当然实际情况各有不同。
测试文档在测试过程中很有用的，测试是根据测试文档（例如测试计划，测试用例）来做的。




－－－－－－－－－－－－－－
《我在微软做软件测试》在我的个人网站www.TestTip.com

skinapi

文档起到两个作用：
1、有助于理清自己的思路；
2、方便沟通，和提高沟通的效率。

ericwu

功能测试虽然麻烦，但结果的好坏直接影响客户的使用效果。
前期的准备很重要，对测试来讲，方案，计划，case都是很关键的过程，缺一不可。
楼主还是认真准备的好。

云层

磨刀不误砍柴功

lulu8120

功能测试最大的基础是业务！只有对业务有很全面的了解，才能考虑到每个模块间的衔接，而且知道一些状态位的改变会对整个业务模块有什么影响！然后，就可以做联动测试！我认为这样才是个比较完整的测试！

因为业务的不一样，也许有的是比较单纯的，有的是N多个模块相互关联的！
在前期写测试用例时，基本上是考虑不全的！

我有个很不专业，但是确实不得不承认是比较方便的方法：在测试ING的时候，tester脑子立刻把所有的测试数据和边界值等等考虑进去，再看数据库保存，再联想相关测试，最后写测试用例，方便以后回归测试！当然，这样也会考虑不全面！

总之，测试方法没有个定式，适合自己就可以！

cherry8163

看了楼上们的讨论，让我的眼睛突然明亮了许多，对测试的理解也深入了很多，谢谢了！

千里

写了测试用例知道自己考虑不全面，没写测试用例连自己是否考虑全面了都不知道。