在没看到界面的情况下如何写测试用例
在没有看到界面，拿到的需求也是非常不具体的初始需求，现在的需求已经有了很大的变动，并且需求以后还会再变，在这种情况下该怎么写测试用例呀？我现在只是列出了几个相对稳定的需求的测试点，在这种情况下写的了测试用例吗？真是伤脑筋。 我自己一点点拙劣的想法！
一般的界面都会有一些通用的控键等，最初的设计者不见得会设计出合理的完整的界面，这样的话改动会很大。我从事界面测试的时候，一般设计文档内都会有策划自己起草的最初界面版式，以及相关的控键，按照他需求的功能点设计测试案例，根据自己测试其他同种类型的界面的经验，写出相关已经设计完毕的控键、功能的测试项。如果有改动的话当然要随时更新测试案例，不过任何改动我都会要求设计人员提前给出相应的设计案，或者草图。他们拿给程序的设计案，我都会要一份过来。很多问题在程序没有开始写代码的时候都给他指出来问题所在。特别是一些界面的设计可能需要预留一些位置给新的功能。一般情况策划都会考虑到，没有考虑到的地方，测试也可以直接提出来。案例其实只是为了让自己测试执行时将每一个设计需求都考虑在内，让自己不要遗漏重要的功能点。目标不是编写案例，是为了测试执行。现在很多测试部门都将测试案例作为重点考核测试员的参考，其实不见得是一种最好的方法。不过可以肯定一点，一个好的测试员的确案例也可以写的覆盖面很全。但是水平一般的也可以通过很长时间写一个完整的案例。我自己一些拙劣的想法：如果测试员经验足够方法正确，甚至没有测试案例也同样可以将一个系统测试再短时间内测试达到最大覆盖率！ 还是等需求比较稳定的时候再写吧，不然会做很多无用功吧
不过现在可以考虑测试策略啊什么的啊 多谢adinqueen，我想现在最重要的还是了解最新的需求。 写个测试用例概要吧，写细了到时候需求变动，用例也跟着改一大串。 嗯嗯，现在就是没有写具体的操作 没有界面也有输入输出的，只不过没有步骤了。 可以分成两个部分，即功能点部分和人机交换部分（UI）。
分别对每个部分描述测试用例。
对UI部分可以规定一个简单的规则。 flyingpig能在说清楚点吗？如何对ui规定一个简单的规则呢
如果分别对每部分描述测试用例的话，实施起来的工作量会不会加大
谢谢！ 个人认为不是拿到界面才去写用例的,根据当前的需求写用例.
用例根据需求的调整(一般不会太大的变动)而完善...
明确了需求才能开发,测试..... 呵呵 公司的需求一般都不会做的很详细，用例要涉及到具体的操作，没有界面用例写不了很具体、明确、清楚。 根據需求規格的文件，把粗略的測試用例先寫出來，
這樣比較可以壓縮實測時，又要寫測試用例的時間~ 个人建议：首先像flyingpig说的区分UI界面和功能。关于UI首先向客户进行确认，保证一个大的框架，或者给客户一个原型图，让客户确认，这样就可以确定了几本的UI了。在UI没有办法确认的时候，首先设计输入数据和预期结果，操作步骤可以简化，但是数据和预期结果要设计完整。
楼主还提到了需求不稳定，这个是当前软件开发的大问题，这个问题测试似乎很难去改变，毕竟是整个软件开发的事情，测试改变不了。但是测试可以用一些方法保证最小返工，就是将整个测试用例设计分成一个个的单元，首先做最稳定的单元（应该有吧，如果这个都没有，那么就要向项目负责人反映了），然后做普通的，以此类推这样可以保证返工量小点。同时，每次设计的用例都保留，对于返工做相应的记录，这样做可以明确让项目管理者知道你（或者说整个测试组）的工作量，这样可以明确责任，否则测试往往会承担原本不是自己应该承担的责任！ 多谢大家的意见sdlkfj3，很有帮助呦！！ 可以考虑叫美工（如果公司有这个条件的话）根据需求写一个demo，这样就好办了
页:
[1]
