论测试用例的意义与编写

ivy112

欢迎大家拍砖！


最近项目做新产品，是基于原型开发的一个项目。

背景如下：
研发团队基于需求画了原型，方便理解和给客户推销编好了demo。但是在开发过程中，开发人员实现需求的时候没有严格按照原型和demo进行开发，如果有比较类似的框架或者界面就直接使用了。直接后果造成了产品和原型和demo不一致。

而demo和原型没有很好的维护，demo和原型也不一致。

开发交付给测试的时候，发现测试的产品和demo不一样，和原型也不一样。

在需求人员讨论过程中，他们又有的时候觉得应该修改需求，原型也改了，demo可能也改了。


测试进入的时候，按照管理团队的要求基于原型和demo写。

但是实际产品很有差距，最初的测试用例编写是一个人，后面执行的是另外一个人。

测试用例编写的时候很用心，基本上按照业务流程逻辑进行，但是和现在的系统有差异；

执行测试用例的人执行的时候发现功能点要在很细的测试用例里面找，也不好修改。

就提出来，希望测试用例按照功能点来写，然后测试用例按照当前的最新的系统的功能点来编写。当前的系统还处于有部分改动中。


我想到了测试用例的意义是什么？如何来编写测试用例？

测试用例是一个可操作性的文档，告诉执行者如何进行测试。应该基于业务逻辑进行。如果有很详细的需求说明书，并且需求变动不大的情况下写详细的测试用例；

对于系统很了解，知道业务逻辑，或者对系统有丰富的经验，可以基于经验和场景的测试。这个时候的测试用例应该是一个个场景。

在各个不同的情况下怎么编写测试用例呢？

736446347

这就是开发与测试沟通严重不到位，在研发团队，无论哪一级变更任何东西，至少要经过领导批准，其次各部门通告，确认修改项后方可进行修改，这里说的测试用例编写完成到后面需求变更了，用例随需求更新而更新，当然不是写完了就等待执行就行了，用例的存在是让测试人员更好的更快的发现BUG，当然很重要。至于你后面说的如何写用例，如何操作就如何写，想要得到什么结果就是预期结果，写出雏形在进行用例评审进行二次补充就好了。

zhaobinhs

我个人一直都不是以测试用例为核心，因为测试用例会在你测试前，中，后都会有所变化的，因为需要在整个生命周期或多少都会有所变化的，一成不变的需要很少。
我的核心在测试点上，
首先，测试点的修改量相对测试用例来说要小很多
其次，每个测试点下对应该测试点所囊括的所能涉及到的测试用例作为一个独立的单元，这样即使需要和原型发生了变化，对你整体测试影响也不会太大

jingzizx

1/其实你这种情况是大部分人都会遇到过:因为需求改动/研发重新设计,导致原先测试用例需要改动.
目前来说,我们还是要保持一个好的心态,积极应对这些问题,现实无法改变,改变我们自己.
2/测试用例还是很重要的,用例中不仅要说明测试前置,操作步骤,预期结果等因素,它更重要的是说明了你测试的策略.
如你按照场景测试,用例设计时肯定是按照场景来进行设计的,思路有了,用例也就有了.比如年找业务逻辑进行设计,基本上也是这样.
3/对于变动,我们还是要区分是否业务逻辑发生变化,如果业务逻辑没变化,用例中大的框架就不需要改动,只要修改一些页面显示及数据传输,
如果业务逻辑都变了,那需要重新进行大的修订.
4/写用例时,开始可以略写,要包含各个功能点信息,不能遗漏功能点,在根据原形进行细化即可.

何以笙萧默

1、首先，用例还是很重要的，因为写用例的时候可以尽量写的比较全面，让你有所准备的进行测试，让测试更有方向性。总好过直接测试，这里侧一点那里测一点，这样很容易遗漏。
2、关于需求变更。首先需要执照测试以及开发的相关负责人，然后再知照到底下人员，做到大家都清楚需求。
3、用例是需要维护的，每一轮的测试结束以后我们的测试人员需要对用例进行维护，更改用例等等。或者在写用例的时候我们要写的具有灵活性
4、另外个人建议编写用例最好是比较详细，而大概的需求框架以及场景则需要测试人员心理有数。
暂时就这么多。

anyanlong

1.个人感觉用例是很重要的，测试离开用例后会造成管理混乱（不知道哪些测了哪些没测），进度估算没有依据，测试点覆盖不全等问题；
2.像项目需求修改这些问题，我想绝大多数测试人员都遇到过。对于这些我们是没有办法去避免的，所以只能去适应它，但是适应并不是抛弃掉测试用例；
3.关于需求变更的问题，建议在产品开发前期用例只编写测试点，以覆盖到所有功能项为目标，到正在有测试产品/模块的时候，再去把用例细化；
4.另从项目管理出发，需求变更时需要项目经理通知相关人员，不能只有特定的开发人员知道；
5.最后，不要抱有在开始把测试用例编写好后就万事大吉的思想，测试用例在整个测试过程中是一直在变化的，需要我们不间断的维护，直至测试终结。