请各位大侠帮我看看我的测试用例啦！

joeypeng_87

我现在在做个图书馆1月份的借还书记录的软件测试！因为是刚刚接触这个行业，所以有些不懂，望大家帮我看看啦！
其中客户需求是：要查询1月份的图书馆的借还书的记录，其中一定要是有借有还的才可以算有效的噢！
其中我写的如下：
编号                用例描述                                  预期结果
01                      1月1日借出1本书，在1月2日还回          可以显示此条记录
02                      1月1日借出1本书，2月1日还回            提示输入错误
03                      1月15日借出1本书，2月1日还回           提示输入错误
04                       1月31日借出1本书，2月1日还回           提示输入错误
05                        1月1日还回1本书                               提示输入错误
06                       1月15日还回1本书                        提示输入错误
07                      1月31日还回1本书                         提示输入错误
08                       1月15日，1月16日分别借出2本书，        可以显示这四本书的记录
                   在1月17日还回6本书（其中分别有
                   15、16日的各两本书的记录）            
09                            1月15日，1月16日分别借出2本书，         不显示这几本书的记录           
                      在1月17日还回6本书，
                      （不包括15日和16日的书的记录）
因为时间有些紧，可能考虑不全，希望大家帮帮我拉！谢谢拉

scorix

先不说设计的怎么样，格式还是需要改进的。

用例编号：编号应该是唯一的，同时也应能够自解释，便于日后查找。如BMS_ST_FUNC_SEARCH_001，即图书管理系统_系统测试_功能_查询_001。
用例项目：表明你要测的对象是什么，如：查询1月份的图书馆的借还书的记录
用例标题：表明这个用例测试的出发点和关注点，如：查询1月份借出图书并于1月份归还的记录
重要级别：高/中/低，或其他划分方式
预置条件：表示从什么条件下开始
输入：列举需要输入的参数
操作步骤：测试的每一步操作
预期结果：

测试是一个可控的过程，从这个角度来说，没有预置条件和操作步骤是无法保证整个过程是可控的，而且即使发现了bug也有可能无法重现。

dinah968

楼上的说得好详细哦，学到了

119139107

多谢2楼发表的意见
受益匪浅
学习中。。。。。。

wgs0923

先想好采用什么方法编写测试用例吧`

tester_ran250

2楼的“查询1月份借出图书并于1月份归还的记录”的这句话可是很有用的哦！这就是一个很好的边界值条件，分别考虑在此范围内的情况和范围外的情况，还有一些极端的情况，也应给在测试用例中体现出来，比如说：查询时系统崩溃

jacktan

建议都很好。。

smallsky

比如12月份借的书，在一月份还！这种情况是不是也该考虑进去啊

scorix

其实我没有办法帮你衡量你的测试用例是好是坏。。。
因为你给出的只是客户的原始需求，而不是需求分析后得出的需求规格。
仅靠这个原始需求来分析设计用例是有一定风险的
1、查询1月份的记录。是当前年份的1月份的记录还是所有年份1月份的？或是特定年份的？
2、借还书。是借书或还书？还是借书并还书？
3、记录。记录包含哪些字段？如何验证这些字段的正确性？
4、用户只需要查询1月份的记录？他不需要其他11个月的？
说真的，这种需求哪怕你测得再好都是白搭的。哪个用户可能接受只能查询1月份记录的系统？