目录
5 ATM系统测试
5.1 单元测试
5.1.1 制定单元测试计划
5.1.2 设计单元测试用例
编辑
5.1.3 执行单元测试
5.1.4 单元测试报告
5.2 集成测试
5.2.1 制定集成测试计划
5.2.2 设计集成测试用例
5.2.3 执行集成测试
5.2.4 集成测试总结
5.3 系统测试
5.3.1 制定系统测试计划
5.3.2 设计系统测试用例
5.3.3 执行系统测试
5.3.4 系统测试总结
5.4 验收测试
博客：
5 ATM系统测试
5.1 单元测试
在单元测试期间着重从模块接口、局部数据结构、重要的执行通道、出错处理通路、边界条件进行测试。
5.1.1 制定单元测试计划
(1)测试目标
本次单元测试的目标为ATM系统中的各个类，主要检查类的实现是否完全满足类的说明所描述的要求。
(2)测试方法
单独地看待类的成员函数，与面向过程程序中的函数或过程没有任何本质的区别，几 乎所有传统的单元测试中所使用的方法，都可在面向对象的单元测试中使用。对于存在继承关系的类，要先测试父类，再测试子类，且测试子类时只需测试与父类不同的地方及所调用的方法发生变动的成员函数。
本次单元测试中，对类成员函数的测试大多釆用白盒测试方法中的基本路径测试法。
此方法是在程序控制流图的基础上，通过分析程序的环路复杂度，导出基本可执行路径集合，从而设计测试用例的方法。其设计出的测试用例能够保证在测试中程序的每个可执行语句至少执行一次。
(3)进入准则
1)编码阶段已经审核完成；
2)项目经理已经批准了单元测试计划；
3)測试组己经设计好测试用例，经过测试组组长的检查，并通过项目经理批准，本项目的单元测试人员为开发人员;
4)测试资源已经到位(软件、硬件、人力)。
(4)结東准则
1)测试遇到的所有问题已经记录下来：
2)所有测试用例都已运行；
3)95%的测试用例已经成功通过；
4)测试结果已经记录，测试分析报吿已经提交项目经理检査；
(5)考虑事项
1)按类进行划分，每个类的每个重要函数作为一个单元，毎个单元釆用基本路径礙 盖法来设计测试用例；
2)接口是否正确；
3)局部数据结构是否正确；
4)边界处理是否正确；
5)错误处理是否正确。
5.1.2 设计单元测试用例
（1）账户转账代码
public void transfer(int money,String id)throws Exception//转账
{
if(id.equals(Test.currentAccount.id))
{
throw new Exception("不能转给自己");
}
if(money>this.money)
{
throw new Exception("余额不足");
}
if(money<0) {
throw new Exception("不能转入负数");
}
for(int i=0;i<Test.usersList.size();i++)
{
if(Test.usersList.get(i).id.equals(id))//找到要转帐的用户
{
Test.usersList.get(i).money+=money;//转入
this.money-=money;//扣钱
FileWriter fw=new FileWriter(Test.file);
formatter = new SimpleDateFormat("yy-MM-dd HH:mm:ss");//声明时间格式
currentTime=new Date();//获取当前时间
String dateString=formatter.format(currentTime);//转换时间格式
fw.write(Test.recordString.append(dateString+"\t向"+id+"\t转出"+money+"元\r\n").toString());//Test类中的静态字符串拼接上这个字符串覆盖写入当前用户文档
fw.close();
/********************向转入目标写入转账信息*************************/
try {
fr = new FileReader(id+".txt");//字符流
}
catch (Exception e)
{
System.out.println("字符流创建失败");
}
BufferedReader bfr = new BufferedReader(fr);
String temp="";
String temp1;
while ((temp1 = bfr.readLine()) != null)
{
temp+=temp1;
}
temp=temp.replace("元","元\n\r")+dateString+"\t由"+Test.currentAccount.id+"\t转进"+money+"元\r\n";
System.out.println(temp);
fw=new FileWriter(id+".txt");
fw.write(temp);
fw.close();
JOptionPane.showMessageDialog(null,"转账成功");
Test.usersListUpdate();//更新用户文档
return;
}
}
throw new Exception("目标用户不存在");
}
（2）数据流图
（3）.环路复杂度为9，独立路径共有9条，则：
路径1：1-2-3-4-6-7-8-9-22-23
路径2：1-2-3-5-6-7-8-9-22-23
路径3：1-2-3-5-6-7-10-11-22-23
路径4：1-2-3-5-6-7-10-12-13-22-23
路径5：1-2-3-5-6-7-10-12-14-15-22-23
路径6：1-2-3-5-6-7-10-12-14-16-17-22-23
路径7：1-2-3-5-6-7-10-12-14-16-18-21-22-23
路径8：1-2-3-5-6-7-10-12-14-16-18-19-20-22-23
路径9：1-2-3-4-6-7-10-12-14-16-18-19-20-22-23
(4)导出测试用例
一条独立路径可对应一条测试用例。
针对每条独立路径，设计对应的測试用例如下：
路径l:该路径前提是储户输入账户密码错误，可在账户密码输错的情况下测试；
路径2:数据库的账户信息表中无转账对象账号且账户密码错误，但出现“系统中无该转账对象”错误提示前提是账户密码正确，由于路径1已对账户密码的错误提示进行了测试，则在对本路径测试时可在账户密码正确的情况下测试：
路径3:该情况的转账对象账号与本账号一致，可在转账对象账号与本账号相同的情况下测试；
请重新输入该种情形要求数据库中有退货产品但又不进入循环体，但这种情况不可能发生, 所以不再设计测试用例；
路径4:所输入的转账对象账号在数据库的AS_CardInfo账户信息表中不存在，可输入未在系统中申请的账号作为转账对象账号，进行本路径的测试；
路径5:所输入的账户余额小于转账金额，余额不足，无法进行转账操作，可选择账户余额小于所输入转账金额的账户进行转账操作，以此完成本路径测试；
路径6:本账户货币类型与转账对象货币类型不一致，无法进行转账操作，可选择货币类型与本账户不相同的转账对象进行转账操作，以此完成本路径测试；
路径7:所输入的储户编号与账户编号在数据库的AS_CardInfo账户信息表中不相对应，无法进行转账操作，可在账户编号与储户编号不对应的情况下测试。
路径8:所输入的储户编号与账户编号在系统中存在（在系统中已申请）且储户编号与账户编号相对应，且本账户余额充足，可进行转账操作，在该种情况下可以选择账户余额大于或等于所输入转账金额的账户、账户密码正确、账户货币类型与转账对象账户一致的已存在账户进行测试；
路径9:所输入账户密码错误，转账对象在系统中存在，所输入的储户编号与账户编号在系统中存在（在系统中已申请）且储户编号与账户编号相对应，且本账户余额充足。账户密码已在路径1测试完毕，转账对象是否存在已在路径2验证，其他功能也已验证，本路径不再测试。
综合上述分析，需要两类测试用例如下:
(1)账户密码输入错误，其预期结果为输出“账户密码输入错误，请重新输入！”错误提示，不做转账事务处理，对应路径1：
数据库的退货表中含退货产品，且至少有一个退货产品的退货原因为空，至少有一个退货产品的退货原因为null,至少有一个退货产品的退货原因已给出，分别对应 Path4、Path5. Path6。其预期结果为所有未给定退货原因的产品均给出退货原因，所有退 货产品都设定了对应的开单金额信息.
(2)账户密码输入错误，所输入的转账对象账号在数据库的AS_CardInfo账户信息表中不存在，其预期结果为输出“账户密码输入错误，请重新输入！”错误提示，提醒储户重行确认转账账号，对应路径2：
(3)账户密码输入正确，转账对象账号与本账号一致，其预期结果为输出错误提示，提醒储户重行确认转账账号，对应路径3：
(4)账户密码输入正确，转账对象账号在系统中不存在且账户密码输入错误，其预期结果为输出错误提示“转账对象账号在系统中不存在，请重新确认转账对象账号”，对应路径4；
(5)账户密码输入正确，余额不足，其预期结果为输出错误提示“本账户余额不足，请重新选择存款金额或更换账户”，对应路径5：
(6)账户密码输入正确，本账户货币类型与账户对象货币类型不一致，其预期结果为输出错误提示“本账户货币类型与账户对象货币类型不一致，请重新输入”，对应路径6：
(7)账户密码输入正确，所输入的储户编号与账户编号在数据库的AS_CardInfo账户信息表中相对应，其预期结果为输出错误提示“所输入的储户编号与账户编号，请重新输入！”，对应路径7：
(8)账户密码输入正确，所输入的储户编号与账户编号在数据库的AS_CardInfo账户信息表中不相对应，其预期结果为输出错误提示“所输入的储户编号与账户编号，请重新输入！”，对应路径8：
(9)所输入的储户编号与账户编号在系统中存在（在系统中已申请）且储户编号与账户编号相对应，且本账户余额充足，其预期结果为输出操作成功提示“转账成功，请查阅交易记录！”，对应路径9；
(9)所输入账户密码错误，所输入的储户编号与账户编号在数据库的AS_CardInfo账户信息表中不相对应，其预期结果为输出错误提示“所输入的储户编号与账户编号，请重新输入！”，对应路径9；
2、申请账户
1）关键代码
1.start
2.
conn = DataAccess.getConnection();
prep = conn.prepareStatement("select * from card where sid = ? and cid = ?");
prep.setString(1,_sid);
prep.setString(2,_cid);
rs = prep.executeQuery();
3. if(rs.next())
4. {
System.out.println("该储户已申请过此账号，不可重复申请！");
return 5;
}
//返回值为5，该储户已申请过此账号
rs.close();
prep.close();
5.endif
//判断所输入的顾客号是否在储户表里存在
6. prep = conn.prepareStatement("select * from customer where sid = ?");
prep.setString(1, _sid);
rs = prep.executeQuery();
if(rs.next())
flagCus = 1;
rs.close();
prep.close();
//判断所输入的商品号是否在账户表里存在
prep = conn.prepareStatement("select * from card where cid = ?");
prep.setString(1,_cid);
rs = prep.executeQuery();
if(rs.next())
flagCom = 1;
rs.close();
prep.close();
7. if(flagCus==1
8.&& flagCom==0)
9. {
//所输入的储户号在系统中存在,申请开通的账户不存在，执行插入操作
String sql = "insert into card values(?,?,?,?,?,?)";
prep = conn.prepareStatement(sql);
prep.setString(1,_cid);
prep.setString(2,_ctype);
prep.setString(3,_opendate);
prep.setString(4,_password);
prep.setString(5,_sid);
prep.setString(6,_total);
prep.executeUpdate();
flag=1;
}
10.else{ 插入失败 if(flagCus==0 && flagCom==1)
//判断所输入的顾客号在顾客表里不存在，所输入的商品号在商品表里存在，返回3
{ System.out.println("该储户不存在且该账户已被申请，请先在本银行申请储户身份并更换账户号！");
flag = 2; }
else{
if(flagCus==0 )
//判断所输入的顾客号在顾客表里不存在，所输入的商品号在商品表里存在，返回3
{ System.out.println("该储户不存在，请先在本银行申请储户身份！");
flag = 2; }
if(flagCom==1)
//判断所输入的顾客号在顾客表里不存在，所输入的商品号在商品表里存在，返回3
{ System.out.println("该账户已被申请，请更换账户号！");
flag = 2; }
}
}
11.endif
12.stop
2）程序流图
3）独立路径
已知判定节点为3，边数为14-12+2=4,环路复杂度为4，独立路径共有4条，则：
路径1：1-2-3-4-12
路径2：1-2-3-5-6-7-10-11-12
路径3：1-2-3-5-6-7-8-10-11-12
路径4：1-2-3-5-6-7-8-9-11-12
4）导出测试用例
一条独立路径可对应一条测试用例。
针对每条独立路径，设计对应的測试用例如下：
路径l:该路径该储户已申请过此账号，可选择数据库AS_CardInfo信息表中存在的账户编号进行测试；
路径2:数据库的账户信息表中无此储户编号，无法进行账户申请：
路径3:该情况储户不存在和该账户已被申请的情况至少存在一种，可选择在系统中还未申请的储户编号或已申请的账户编号进行测试；
路径4:所输入的储户号在系统中存在,申请开通的账户在系统中不存在，即还未申请，执行插入操作，可选择在系统中已申请的储户编号以及未经申请的账户编号进行本路径；的测试；
综合上述分析，需要两类测试用例如下:
(1)所输入的储户号在系统中存在,申请开通的账户不存在，其预期结果为输出“账户密码输入错误，请重新输入！”错误提示，不做转账事务处理，对应路径1：
数据库的退货表中含退货产品，且至少有一个退货产品的退货原因为空，至少有一个退货产品的退货原因为null,至少有一个退货产品的退货原因已给出，分别对应 Path4、Path5. Path6。其预期结果为所有未给定退货原因的产品均给出退货原因，所有退 货产品都设定了对应的开单金额信息.
(2所输入的储户号在系统中存在,申请开通的账户存在，所输入的转账对象账号在数据库的AS_CardInfo账户信息表中不存在，其预期结果为输出“账户密码输入错误，请重新输入！”错误提示，提醒储户重行确认转账账号，对应路径2：
(3)账户密码输入正确，转账对象账号与本账号一致，其预期结果为输出错误提示，提醒储户重行确认转账账号，对应路径3：
(4)账户密码输入正确，转账对象账号在系统中不存在且账户密码输入错误，其预期结果为输出错误提示“转账对象账号在系统中不存在，请重新确认转账对象账号”，对应路径4；
3、取款
1）关键代码
@Override
public void actionPerformed(ActionEvent e) {
if(e.getActionCommand().equals("确定"))//点击确定按钮
{
flag1=false;
flag2=false;
try {
int money1=Integer.parseInt(money.getText());
if(money1%100==0) {
flag1=true;
}
if(money1<=5000) {
flag2=true;
}
if(flag1&&flag2) {
Test.currentAccount.outMoney(Integer.parseInt(money.getText()));
JOptionPane.showMessageDialog(null, "取款成功");//弹窗
yue.setText("账户余额:"+Test.currentAccount.money);//更新余额显示
}
if(!flag1) {
JOptionPane.showMessageDialog(null, "系统不支持非100元整钞取款\n 请重新输入取款金额 ！ ");//弹窗
money.setText("");
}
if(!flag2){
JOptionPane.showMessageDialog(null, "系统不支持存款超过5000元\n 请重新输入存款款金额 ！ ");//弹窗
money.setText("");
}
}
catch (ClassCastException e1)
{
JOptionPane.showMessageDialog(null, "输入数据类型错误，请输入整数");//捕获Test类中outmoney方法的异常
}
catch (Exception e1)
{
JOptionPane.showMessageDialog(null, e1.getMessage());
}
}
else
{
iframe.setVisible(false);//隐藏
}
}
2）数据流图
3）独立路径
已知判定节点为3，边数为14-12+2=4,环路复杂度为4，独立路径共有4条，则：
路径1：1-2-3-4-5-10
路径2：1-2-3-6-7-10
路径3：1-2-3-6-8-9-10
路径4：1-2-3-4-6-8-9-10
4）导出测试用例
一条独立路径可对应一条测试用例。
针对每条独立路径，设计对应的測试用例如下：
路径l:该路径前提是储户输入账户密码错误，可在账户密码输错的情况下测试；
路径2:数据库的账户信息表中若所输入的储户编号以及账户编号在评价表里存在且对应，进行取款操作：
路径3:在该情况下所输入的储户编号以及账户编号在评价表里不相对应，且账户编号均不存在，账户密码为空，储户编号可能存在，可输入在系统中不存在的储户编号和账户编号进行测试；
路径4:所输入的储户编号以及账户编号在数据库的AS_CardInfo账户信息表里不相对应，在该情况下账户编号存在，账户密码正确，储户编号可能不存在，无法进行取款更新操作，可输入在数据库的AS_CardInfo账户信息表中里不存在且不相对应的储户编号以及账户编号，进行本路径的测试；
综合上述分析，需要三类测试用例如下:
(1)账户密码输入错误，所输入的储户编号以及账户编号在评价表里相对应，其预期结果为输出“账户密码输入错误，请重新输入！”错误提示，不做取款事务处理，对应路径1：
(2)账户密码输入正确,所输入的储户编号以及账户编号在评价表里不相对应，其预期结果为输出“取款成功！”操作成功提示，对应路径2：
(3)账户密码输入正确或为空,所输入的储户编号以及账户编号在评价表里不相对应，所输入的储户不存在或该账户已被申请，其预期结果为储户不存在的均输出错误提示“该储户不存在，请先在本银行申请储户身份！”，账户已被申请的均输出错误提示“该账户已被申请，请先申请此账户或重新确认账户编号！”，提醒储户先申请此账户或重新确认账户编号，对应路径3；
(3)所输入的储户编号以及账户编号在评价表里不相对应，存在所输入的储户不存在的情况，其预期结果为储户不存在的均输出错误提示“该储户不存在，请先在本银行申请储户身份！”，提醒储户先申请此账户或重新确认账户编号，对应路径4；
5.1.3 执行单元测试
（1）搭建单元测试环境
- 执行单元测试的软硬件环境
- 待测单元
- 驱动模块和桩模块
单元是整个系统的一部分，不能单独运行。为了执行单元测试用例需要开发驱动模块和桩模块。驱动模块是用来模拟调用函数的一段代码。它可以替代调用被测单元的模块:桩模块用于模拟被测单元所调用函数的一段代码。它可以替代被测单元调用的模块。
4)单元测试用例
（2）执行测试
在执行测试时，应如实记录测试的过程和结果。若实际结果与预期结果相同，则测试用例状态为通过，否则为失败，并给出缺陷报告。
5.1.4 单元测试报告
(1)测试执行情况
测试用例覆盖率达到 100%，98%的测试用例已经成功通过。
(2)主要问题及解决情况
1）主要问题
- 个别模块接口参数本应给定默认值，但未给出;
- 部分判定中的条件运算符、逻辑运算符错误
- 存在错误处理提示描述不清晰的情况;
- 部分 sql 语构造错误。
2）解决情况
相关程序员对发现的缺陷进行了修复，并对可能存在类似问题的程序模块进行了核实
(3)测试结论
单元测试基本结束，可以进行集成测试。
5.2 集成测试
集成测试是在单元测试的基础上，将程序单元按照概要设计要求逐步组装成系统时的测试，主要检查程序单元集成在一起时能否正常工作。集成测试可以发现单元间接口、功能组合是否达到预期、误差累积、数据结构等方面存在的问题。
集成测试跨越产品多个模块，如为了完成出库操作，测试用例包括销售单管理、供应商管理等相关操作，需要考虑集成测试时单元的集成顺序和集成方式。传统软件测试中常用的集成方式有一次性集成和增量式集成。而增量式集成又细分为自上而下集成和自下而上集成，它们是根据系统功能组织结构和调用关系进行集成测试的。在面向对象方法中，协作集成是针对系统完成的功能，将可以相互协作完成特定功能的类集成在一起进行测试。面向对象集成测试主要对系统内部的相互服务进行测试，如成员函数间的相互作用、类之间的消息传递等。
5.2.1 制定集成测试计划
（1）测试目标
在单元测试的基础上，通过将所有单元/模块按照设计要求逐步集成测试，来发现单元接口间数据传递是否有误、单元集成在一起后是否满足既定功能和性能、误差积累是否超过预期等。
(2)测试方法
面向对象的集成主要是类与类的集成。本次集成测试采用功能集成测试方法。也就是以功能为引导，从功能的入口方法开始，逐步集成需要调用的方法所属类的过程。
(3)进入准则
- 所需单元的单元测试完成;
- 项目经理已经批准了集成测试计划
- 测试组已经设计好测试用例，经过测试组组长的检查，并通过项目经理批准，本项目的集成测试人员为开发人员、测试人员;
- 测试资源已经到位(软件、硬件、人力)。
(4)结束准则
- 测试用例覆盖率达到100%:
- 缺陷修复率达到95%以上;
- 单元模块集成后效果与设计说明书一致;
(5)考虑因素
建议增量集成的方式，不推荐将通过单元测试的所有类进行一次性集成测试，避0免问题一次性爆发而导致很难错误定位。
5.2.2 设计集成测试用例
在进行面向对象的集成測试时，一般情况下可以根据顺序图、状态图等动态模型来分 析某操作所涉及的类和类之间的消息传递过程，也可以从对象模型中获取类之间的关系进 而进行集成。
此处以出库单管理为例阐述集成测试用例设计的思想。
（1）分析业务消息传递过程
账户信息管理主要由账户信息管理页面、账户取款页面等，这几个类相互协作完成所需功能。
在进行账户信息管理时，首先进入账户信息管理页面，分别点击“申请账户”、“删除账户”、“账户存款”、“账户取款”、“账户转账”、“修改账户基本信息”、“修改账户密码”、“查询账户信息”按钮进行相关操作。
CardTest.insert()->CardTest.insertCard()->CardDao.insertCard(CardDto c)->CardDao.save()'来完成申请账户操作。
- 点击“查询账户信息"按钮，跳转到查询账户信息页面，输入相应信息后点击“查询账户信息”则依次调用
CardTest.find()->CardTest.findAllCard()->CardDao.findAllCard(CardDto c)->CardDao.save()'来完成查询账户信息操作。
- 点击“账户取款"按钮，跳转到账户取款页面，输入相应信息后点击“账户取款”则依次调用
CardTest.update()->CardTest.updateCard_Qu()->CardDao.updateCard_Qu(CardDto c)->CardDao,save()'来完成申请账户操作。
- 点击“账户存款"按钮，跳转到账户存款页面，输入相应信息后点击“账户存款”则依次调用
CardTest.update()->CardTest.updateCard_Cun()->CardDao.updateCard_Cun(CardDto c)->CardDao.save()'来完成申请账户操作。
- 点击“账户转账"按钮，跳转到账户转账页面，输入相应信息后点击“账户转账”则依次调用
CardTest.update()->CardTest.updateCard_Trans()->CardDao.updateCard_Trans(CardDto c)->CardDao.save()'来完成申请账户操作。
- 点击“更新账户密码"按钮，跳转到更新账户密码页面，输入相应信息后点击“更新账户密码”则依次调用
CardTest.update()->CardTest.updateCard_Pwd()->CardDao.updateCard_Pwd(CardDto c)->CardDao.save()'来完成申请账户操作。
- 点击“更新账户基本信息"按钮，跳转到更新账户基本信息页面，输入相应信息后点击“更新账户基本信息”则依次调用
CardTest.update()->CardTest.updateCard_Info()->CardDao.updateCard_Info(CardDto c)->CardDao.save()'来完成申请账户操作。
- 点击“删除账户基本信息"按钮，跳转到更新账户基本信息页面，输入相应信息后点击“删除账户基本信息”则依次调用
CardTest.delete()->CardTest.deleteCard_Info()->CardDao.deleteCard_Info(CardDto c)->CardDao.save()'来完成申请账户操作。
由以上分析，可得到账户信息管理消息传递过程，如下图所示。
5.2.3 执行集成测试
根据测试用例设计结果，搭建测试环境并测试，实际结果填写完整。在执行测试时，应如实记录测试的过程和结果，若实际结果与预期结果相同，则测试用例状态为通过，否则为失败，并给出缺陷报告。
（1）账户取款集成过程如下图所示：
1）该过程调用了CardTest的update()、updateCard_Qu()方法，并将参数_ed.getCid()、_ed.getCtype()、_ed.getOpendate()等传给CardDao的updateCard_Qu()方法，未出现错误。
2）在进行该用例测试时，出现冗余无用的参数，本用例账户的货币类型_ed.getCtype()和账户开卡日期_ed.getOpendate()，经测试，传过来的值未空，属于无效冗余的参数，应删除CardDao。Update_Qu()方法中出现的_ed.getCtype()、_ed.getOpendate()。
（2）账户存款集成过程如下图所示：
1）该过程调用了CardTest的update()、updateCard_Info()方法，并将参数_ed.getCid() _ed.getCtype() _ed.getSid()等传给CardDao的updateCard_Info()方法，未出现错误。
2）在进行该用例测试时，出现显示操作成功语句表述不清晰的情况，本用例的操作成功语句“加过的金额”，用户对该操作语句无法正确理解，应改为“转账后账户对象金额为：”，便于用户理解。
（3）账户转账集成过程如下图所示：
1）该过程调用了CardTest的update()、updateCard_Trans()方法，并将参数_ed.getCid()、_ed.getPassword()、_ed.getSid()等传给CardDao的updateCard_Trans()方法，未出现错误。
2）在进行该用例测试时，出现冗余无用的参数，本用例的参数本账户的账户余额_ed.getTotal()，经测试，传过来的值未空，属于无效冗余的参数，应删除CardDao。Update_Trans()方法中出现的_ed.getTotal()。
5.2.4 集成测试总结
(1)测试执行情况
测试用例覆盖率达到 100%，95%的测试用例已经成功通过主要问题及解决情况2
（2）主要问题及解决情况
主要问题：
- 类方法接口在传递数据时出现部分数据丢失现象;
- 新增出库单的响应时间超过了用户的性能需求
- 部分异常处理未能捕获;
解决情况
项目组成员集中对类间消息传递所用的接口再次进行统一说明。牵涉到数据库操作时响应时间较长，因此对数据库操作进行了优化。发现的缺陷 98%被修复。
（3）测试结论
系统测试基本结束，可以进行系统测试工作
5.3 系统测试
5.3.1 制定系统测试计划
（1） 测试目标
将已经集成确认的软件与计算机硬件、外设、网络等其他元素结合在-起进行-系列 的测试，验证系统是否符合需求规格的定义.对于找到与需求不符或与之矛盾的地方，要 找出错误原因和位逍.然后进行改正。
（2） 测试内容
本系统测试的測试内容包括功能测试和非功能测试两大部分。
1）功能性测试
对银行系统的所有功能模块进行测试，包括，出庫单的录入和査询、入库单的 录入和査询、出入库査询、调拨在途查询、退货原因录入及修改、库存盘点、库存信息明 细査询、仓库报表査询、盘点盈亏录入和修改等，
2）非功能性测试
易用性测试：菜单、按钮操作正常、灵活，功能清晰，符合使用者习惯；
数据备份与恢复测试：系统中重要数据按照重要程度定期及时备价；
性能测试；测试系统响应数据是否在Is范围内”系统在多用户并发情况下是否运转正常。
（3） 进入准则
1） 集成测试已成功完成；
2） 集成测试中发现的问题都已修改：
3） 测试组已经设计好系统测试案例，并经过测试组负责人的检査，得到项目经理的
批准；
4） 测试所需资源（硬件、软件、人力资源等）到也
（4） 结束准则
1） 已经运行了系统测试的所有测试用例
2） 遇到的所有问题/错误己经记录下来
3） 99%的测试用例己成功通过
4）没有严重的问题/错误存在
5） 系统测试报告己经完成并经过项目经理检査认可
（5） 考虑因素
1）要同时考虑合理的、有效的输入和不合理的、无效的输入；
2）应重点对修改部分和修改产生的影响部分进行回归测试’
5.3.2 设计系统测试用例
（1）细化测试需求
对“修改账户信息"的功能需求进行分析后，可以明确以下7点：
- 修改类型有五种：修改账户基本信息、修改密码、账户转账、账户取款、账户存款。五种出座类型对应的修改界面不同，业务流程也不尽相同，需要分别进行测试：
2） 修改账户类型时，开卡日期、交易日期都是由系统按照特定原则自动生成.其中，储户编号、账户编号有相应的编码规范；货币类型由账户自行确认，账户密码由账户输入，系统在其输入后对其进行验证；操作人为系统当前储户；交易日期为系统当前日期，利用DateTimeFormatter.ofPattern("dd-MM-yyyy")自动生成；开卡日期为系统当前储户申请本账户时的日期，由系统利用利用DateTimeFormatter.ofPattern("dd-MM-yyyy")自动生成，无需验证。时測试时应检测这些生成的信息是否符合系统要求；
3） 修改账户信息时，如果修改类型选择账户取款，操作员根据弹出的请求提示输入账户编号、储户编号、账户密码、取款金额等相关信息，点击表单下侧的“取款”按钮，弹出“取款成功！”或者“取款失败，账户密码错误，请重新输入密码！”等操作提示，若取款成功，点击“取消”操作成功的弹窗后，可以查询本账户的交易记录，对取款金额、货币类型、取款日期等进行查看和确认。如果取款失败，点击“取消”操作失败弹窗后，在刷新后的原有账户取款页面进行账户信息的重新输入和确认（如，重新输入账户密码、当账户余额不足时重新输入取款金额等等）。储户编号、账户编号、账户密码、取款金额是账户取款的根本和前提，为必填项。
测试时，应检验系统在进行操作人输入的账户密码、取款金额是否成功获取、账户余额是否小于取款金额，还应检验系统在完成取款流程后，是否能够正确的读取此次交易的具体信息，如本次交易的交易金额、货币类型、交易日期等信息。
另外，账户取款页面中含査询交易信息、取消、选定、确认取款等多个功能，应作为一个测试点单独进行测试。
4） 修改账户操作完成之后，事务类型选择查询交易信息后，操作员点击“输入账户编号”按钮，弾出账户信息输入页面，在账户信息右侧的编辑框中输入账户编号（例如“c01”、“c02”）、储户编号（例如“s01”、“s02”）及其账户密码，对此账户的交易记录进行模糊査询，选取指定交易类型（“转账”、“取款”、“存款”等）进行账户信息的筛选和查询。账户编号、账户密码是查询交易信息的根本和前提，为必填项。
测试时，应检验系统能否正确地搜索账户信息和账户交易信息、能否正确地进行账户金额的增减等。
5） 修改账户信息时，修改类型选择账户转账后，操作员根据弹出的请求提示输入账户编号、储户编号、账户密码、转账金额、货币类型、转账对象账号等相关信息，点击表单下侧的“转账”按钮，弹出“转账成功！”或者“转账失败，转账对象与本账户的货币类型不一致，请重新输入！”等操作提示，若转账成功，点击“取消”操作成功的弹窗后，可以查询本账户本次的交易记录，对转账金额、交易日期、转账对象等进行查看和确认。如果转账行败，点击“取消”操作失败弹窗后，在刷新后的原有账户转账页面进行账户信息的重新输入和确认（如，重新确认转账货币类型、当账户余额不足时重新输入转账金额、修改转账对象账号等等）。储户编号、账户编号、账户密码、转账对象、转账金额是账户存款的根本和前提，为必填项。
测试时，应检验系统在进行操作人输入的账户密码、本账户货币类型与转账对象货币类型是否一致、转账金额是否成功获取、本账户余额是否小于转账金额、转账对象账号在系统中是否存在等等，还应检验系统在完成转账流程后，是否能够正确的读取此次交易的具体信息，如本次交易的交易金额、交易类型、交易对象、交易日期等信息。
6）修改账户信息时，如果修改类型选择账户存款，操作员根据弹出的请求提示输入账户编号、储户编号、账户密码、所存货币类型、存款金额等相关信息，点击表单下侧的“存款”按钮，弹出“存款成功！”或者“存款失败，账户密码错误，请重新输入密码！”等操作提示，若存款成功，点击“取消”操作成功的弹窗后，可以查询本账户的交易记录，对存款金额、货币类型、存款日期等进行查看和确认。如果存款失败，点击“取消”操作失败弹窗后，在刷新后的原有账户存款页面进行账户信息的重新输入和确认（如，重新输入账户密码、当账户余额不足时重新输入存款金额等等）。储户编号、账户编号、账户密码、货币类型、存款金额是账户存款的根本和前提，为必填项。
测试时，应检验系统在进行操作人输入的账户密码、所放入的纸币类型与账户所储存的货币类型是否一致、存款金额是否成功获取，还应检验系统在完成存款流程后，是否能够正确的读取此次交易的具体信息，如本次交易的交易金额、货币类型、交易日期等信息，检验本次交易的交易类型是否为“存款”，交易日期是否有误。
操作员填写账户信息时后，可以选择保存、提交、返回等操作。"保存" 操作类似于暂存为草稿，其状态仍为"未执行”：“提交”操作将账户信息（账户密码、账户编号、交易类型等）提交给系统，使出库单生效，出原单状态更新为"已执行”："返回"操作返回到系统主界面。在测试时，应对这些操作依次测试，并检验系统是否正确地进行了相应操作。
- 测试时应特别注意，操作员完成此次交易之后，查询交易记录页面是否增加了本次完成的操作交易记录。
- 设计测试用例
修改账户信息对应不同种的修改操作，分别为账户取款、账户存款、账户转账、账户基本信息更新、账号密码修改，每种修改操作对应的业务流程和操作信息不同，因此，测试时应针对这五种出库操作结合对应的业务流程分别进行测试。此外，每种修改操作均可以以场景法为导引、配合等价类划分方法、边界值分析法和错误推测法进行测试用例的设计。
修改账户信息测试用例设计
| 前置条件 | 操作员登录系统，并进入修改账户信息操作界面 | |||
| 业务场景 | 用例描述 | 測试步0/«18 | 预期给果 | 实际结果 |
| 场景1 | 用户进行取款事务 | 1.修改类型选择账户取款 2输入账户编号、储户编号、账户密码、取款金额等相关信息 3,点击表单下侧的“取款”按钮 | 取款操作成功 | 取款操作成功 |
| 用户进行存款事务 | 1.修改类型选择账户存款 2.输入账户编号、储户编号、账户密码、所存货币类型、存款金额等 3.点击表单下侧的“存款”按钮 | 存款操作成功 | 存款操作成功 | |
| 用户进行转账事务 | 出修改类型选择账户转账 2.输入账户编号、储户编号、账户密码、转账金额、货币类型、转账对象账号等 3.从点击表单下侧的“转账”按钮 | 转账操作成功 | 转账操作成功 | |
| 用户进行更改账户基本信息事务 | 1事务类型选择更改账户基本信息事务 2.输入账户编号、储户编号 3.从点击表单下侧的“更新账户基本信息”按钮 | 更改账户基本信息成功 | 更改账户基本信息成功 | |
| 查询交易信息 | 1事务类型选择查询交易信息 2.输入账户编号、储户编号 3选取指定交易类型 | 更新账户密码成功 | 更新账户密码成功 | |
| 场景2：返回到ATM信息管理主界面 | 用户执行返回操作 | 1进入“查询账户信息”页面 2.。输入账户编号、账户密码。 2.选中某条交易记录 3.点击“保存”按钮。 | 成功返回系统主界面 | 成功返回系统主界面 |
5.3.3 执行系统测试
根据测试用例设计结果，搭建测试环境并测试，实际结果填写完整。在执行测试时，应如实记录测试的过程和结果，若实际结果与预期结果相同，则测试用例状态为通过，否则为失败，并给出缺陷报告。
5.3.4 系统测试总结
(1)测试执行情况
测试用例覆盖率达到 100%，99%的测试用例已经成功通过
（2）主要问题及解决情况
主要问题：
- 类似操作的界面风格不太一致;部分必填项未给出明确标识;
- 部分异常情况未能捕获;
- 打印功能存在异常。
- 搜索功能响应时间较长
解决情况：
项目组成员集中讨论了界面风格中存在的不一致情况，达成了共识，统一了界面风格;发现的缺陷 98%被修复，并对可能存在类似问题的功能模块进行了核实。
（3）测试结论
系统测试基本结束，可以进行验收测试工作
5.4 验收测试
验收测试是部署软件之前的最后一个测试操作，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。它让系统用户决定是否接收系统。验收测试是以用户为主的测试。
博客：
【软件工程】ATM系统的设计与实现_早睡第一人的博客-CSDN博客
