糊涂的项目经理,混乱的测试工作.还想设计好测试用例?手里拿着一点也不详细的需求文档,领导居然让我们写测
糊涂的项目经理,混乱的测试工作.还想设计好测试用例?
手里拿着一点也不详细的需求文档,领导居然让我们写测试用力.
项目立项到现在,需求没有一天不变的.主要功能还不明确.还让我们设计测试用力.能行吗?
在这里抱怨一下:
Test Cases天天改，后来我就不改了。等着最后的需求文档来了再说。
每个项目的需求文档都是模棱两可的。你们的项目都是这样子的吗？一问到细节，都是拍脑门想出来的解决办法。有时候还需要我们测试人员给他们设计功能。你们也是这样吗？
[解决办法]
1、需求文档不可能一开始就很详细，也不可能规定很多细节，需求一定是会变化的，但是项目经理应该对需求的变化进行一些控制。
2、不是很详细的需求文档，也可能写测试用例。需求文档达到什么详细程度，测试用例就只能写到什么详细程度，测试肯定是随着系统需求不断地完善。
3、不管是不是拍脑袋想出来的，只要需求文档中没有明确写出来的需求细节，测试用例就不涉及。
4、测试人员也可以给开发人员提建议，但是一般不参与设计工作。
[解决办法]
你可以逐步细化
我理解你的，在软件开发过程中，变更是绝对的，不变是相对的
说句敏捷思想中冠冕堂皇的话：我们要积极拥抱变化
但是敏捷思想中有些东西也可以借鉴，你在测试用例的设计过程中就会发现需求如果发生变化，测试用例修改的幅度很大，能不能将测试用例设计的可以应对变化呢？设计扩展性较强的测试用例，当然这会有难度
而且现实情况是客户往往自己都不知道自己要做什么
这就要求需求调研的人员，尽量采取原型的方法，逐步的与客户确认，当然现实情况经常有的客户很忙不配合，（这个应该是在项目初期与客户协商好的，每周占用客户半天的时间确认需求），之后可以敏捷的开发出来这部分需求（WEB应用框架现成的情况下，2周就可以开发出来），让客户参与测试提出修改意见
客户的配合参与是很关键的
说服客户也是很有依据的，如果需求变更，我们所有的设计文档都需要变化，都需要重新评审，会浪费很多成本和工时，会导致项目延期与质量低下（不过，真的就有蛮不讲理的客户，就看销售和项目经理的本事了，欧美的部分客户还是比较规矩的，只要开始答应的事情落实到纸面的，之后会给予必要的支持）
BTW：你可以先写比较稳定的需求部分的测试用例，毕竟经常变化的部分有限
一家之言仅供参考
祝你成功
[解决办法]
加油
[解决办法]
我总是想，虽然我不是最好的，但我也不是最差的，所以面对上面的问题如果是我，我不会抱怨，因为别人都能在如此烂的基础上做自己的事情，为什么我就不能，第一个爆发的人绝对不是我。我不是最好的，所以我也不会把这么烂的东西做到最好。我要做的就是在现有基础上做的好一点，再好一点，尽力而为，不求结果好坏。
[解决办法]
[解决办法][解决办法]认真分析被测试对象 把所有的测试需求点细分
评估被测试对象 哪些存在变更风险 对可能不会变更的部分先设计测试用例
测试用例最好能分解成各个步骤，注意可复用性 像一个脚本的不同部分一样 最后组合起来 这样就算需求变更的再厉害 修改起来也很方便
对于界面等改动太大的部分 可能就需要等最终需求再定夺了
[解决办法]如果你不能容忍的话，可以选择离开……
[解决办法]2楼说的“客户的配合参与是很关键的”很对。
你们大量细节的需求其实是要从客户那里挖来的，你能不能尽可能去了解客户？你们有没有一个与客户沟通的窗口？
需求文档乱七八糟很正常，有时候放在那儿跟没有一样。但是测试需求要明确，这是建立在你对产品的熟悉对客户的熟悉基础上。
这两个熟悉，应该能在一定程度上保证你测试通过的，客户也满意。
[解决办法]跟客户沟通应该是项目经理的工作，那么测试经理就要跟项目经理沟通。
测试经理要拿鞭子赶着“糊涂”的项目经理做正确的事。
[解决办法]首先，测试工作不是软件质量的最后守门员，所以，如果从测试角度讲，所有东西都在最后其他人都齐备了才能动手，那么测试这个角色在软件开发过程中真的就可有可无了，换句话说，开发完全可以兼职测试了（测试用例谁不会写啊，呵呵）。
软件开发的三个角色：PM、Dev和Test是相辅相成共同支撑软件的质量的。如果其他两个角色做的很到位，那么Test所做的工作就会很容易，反之，就如同你现在的状态，就会很郁闷。在你所描述的情况下，PM没有很好的尽到他的责任，但并不是说你就可以以此为依据放任此种情况发展下去。很多时候，PM只能从很窄的一个视角去观察所开发的产品，甚至很多PM根本就不懂技术，所以他们所写出的需求文档或产品定义，虽下笔千言，在技术人员看来确是一堆废话。同时，他们的思考问题的方式可能和我们技术人员不同，他们可能意识不到他们前一个功能设计和后一个功能设计的深层次矛盾之处，只有在开发和测试人员实现到该处的时候，才会意识到。这些都是PM的失职所致，但是作为Test，可以帮助PM，甚至是Dev，帮助这两个角色进步。
我知道在很多公司，Test往往不被受到重视，都是在后期才参与到项目中，职责也基本就是写Test Case，但是合理的开发流程中，在最初始阶段，Test就应当参与进来，包括需求文档和功能说明的编写，至少Test可以review这些文档。在这个review的过程中，Test应当从自己的视角去“审视”目标产品，在这个阶段就找出PM功能设计中的缺陷或矛盾之处，指出并要求PM修正文档。这个应该算是Test所做的第一次测试吧，这个阶段的测试对象不是目标产品，而是PM的文档。这个时候，也是项目开发的初期阶段，Test就从自己的职责上保证了产品的质量。在你的例子中，PM对产品需求的定义不清，变来变去，有时候是PM本身能力的问题，有时候是和其他甲方合作，甲方自己的问题。但是无论哪种情况，Test都要尽量去引导他们向正确的方向。你可能做不到，但不要不去做。 在此之后，开发人员开始了产品代码实现相关的设计工作，在这一阶段，Test仍然需要参与，他们要去review开发人员的设计，从这个角度去保证产品的质量，同时对“可测试性”提出要求。比如你要完成自动化测试，需要特定的内部接口，那么在这个阶段就应当提出来。这个过程，是开发和测试共同进步的时间。同时，Test也应当和开发一起，帮助PM发现潜在的“变更可能性”，当前的设计能够承受多大的需求变更？需求变更会带来多大的成本？如果PM不知道这些，他们始终会肆无忌惮的“变”下去。
完成了上面的所有，这个时候可能才开始写测试用例。哦，我忘了，中间应该还有个测试设计的过程，不过在最后这个阶段，测试设计应该是已经完成或者已经水到渠成了吧。所以说，不要怕写不出测试用例，在整个产品的开发过程中，对于Test来讲，写测试用例是相对靠后的一步，而且不是最困难的那一步。再多提两句，就是你的测试用例对变化的适应性问题。好的测试用例，能够很好的适应小范围的变化，就像模块化编程一样，测试用例也同样可以“模块化”（这里我指的是纯粹意义上的测试用例，而不是说自动化测试程序中的测试用例函数）。把你测试逻辑中不变的部分封装起来，这会使你更容易面对各个方面的变化。同时，如果你的测试用例里应用了和开发人员完全相同的算法或思考逻辑，那么恭喜你，你走错路了，因为你们用重叠的方法去分别实现/验证了相同的内容，这种测试用例是没有太大意义的，换句话说，这些东西归到单元测试还将就了。如果你的测试逻辑依赖于开发人员的实现逻辑，那么这一依赖将迫使你跟随开发人员的每次变更而变更，会很被动。这也是绝大多数情况下测试用例改来改去的一个主要原因吧。
希望上面胡乱写下的东西能多少对你有点帮助
[解决办法]
嗯，祝福。等结贴拿分。吼吼。
