测试啊，测试，工作啊，工作，我该拿你如何是好，踏实的做，慢慢的积累
测试用例的写法
上一篇 /
下一篇 2012-02-06 17:08:06
测试用例一般来说，是按照需求说明说来写的，很多时候我就是直接粘贴过来的，当然还要自己修改下，有一次，是在用户手册出来之后才补写的，更好，复制粘贴起来更是方便速度快非常多。当然在写
测试用例前先要把说明书看几遍，业务流程都看明白了。所以写测试用例的过程中，发现不少需求中业务逻辑没有写全的地方。虽说熟悉一些需求，但要按照要求中的，测试人员要比需求更了解业务还是做不到的。现在写起来，还没有章法，好像测试用例设计的方法也没有用过。真是(⊙o⊙)…
现在主要说的是，测试用例要详细到什么程度，这个指的是在测试步骤中怎么写，比如：点击新建项目，进入项目新建页面，还是这步省略掉，直接写新建项目页面如何如何。我认为这个详细度要与需求保持一致的原则来写测试用例。即，需求中写出了新建项目。。。，那么测试用例中也要写出来，需求中没有涉及，测试用例中就不必写了。若是反过来，需求不是很详细，测试用例写详细了，最后出来的系统，想必是不符合的，还需要再根据系统调过来。
我之前，就会写一些自己臆想的步骤上去。接下来，就一直对比的系统改啊改。
一次开会，经理说，需求中对于某些页面不需要写特别详细，这个要留给开发人员来设计，但是对于一些业务规则，则是必须说清楚，说明白的。恩，比较同意这种看法。（背景：我们现在是自己开发自己的软件，不是给别人做）
看了别人写的测试用例的设计可从几个方面着手，例如：功能、性能、可靠性等。这些是我没有想到的，目前为止，写的只是功能方面的测试用例。接下来要试着写写。
继续补充0215：测试用例在写之前还需要对其进行设计，对这个框架进行设计，分功能性测试用例和非功能性测试用例。功能性测试用例可以从产品特性的分类也就是功能模块来划分。非功能性测试用例，则是从具体的质量特性需求来划分。这个非功能性设计，目前我还没有涉及过。
收藏
举报
TAG:
