按照业务流和数据流写测试用例
曾经看过一些公司写的测试用例，通常都是从业务流的角度来写测试用例，比如进入画面，点了什么按钮，出来什么结果。当然在一些数据检查的时候也会写一些输入**，会报错之类。数据流在测试用例中并没有得到足够的体现。作为一个完整的详细设计书，它应该写清楚数据的增删改查，当然很多详细设计书没有写到这种程度，可是我们换个角度想，开发人员也是在这种不是很详细的设计下进行开发的，他们要根据式样的理解，写出满足条件的SQL文。
测试人员是不是同样需要根据式样的理解，写出满足条件的SQL文呢。反映到我们的用例中，然后可以通过用例评审的方法，达成双方式样理解的一致性。
作为功能测试而言，在我看来，数据的增删改查是最重要的测试点，应该清楚数据在程序中的流动，并将其反映到用例中，比如画面刚进入，我们需要写出数据的抓取条件是怎样的，也就是SQL文中的查，当然有时候也会做一些增删改，根据式样情况了，但画面刚进入的时候，最多做的是查的处理。比如点了什么按钮，数据做个什么抓取，数据库中的数据会有什么变化。如果是插入，插入的每一项值是否对，如果是修改，修改的条件是否对，修改的值是否设置的对。如果是删除，删除的条件对吗。
写完测试用例后，我们就要造出基本的测试数据，这数据要包括有效和无效的数据，有了基本的测试数据，程序就能顺利的转起来。在测试过程中你可以根据你的用例要求修改数据。当然如果安排给你的时间比较多，你可以将各种情况的数据都造出来。 同感
页:
[1]
