6.5 测试实施。
6.5.1 设计测试用例。
在整个项目中，本文作者负责平台中大部分功能需求的测试工作，下面将采用等价类划分法或者边界值分析法对其中一些有代表性的功能进行测试用例设计。
1、运营管理端登录模块测试用例的设计，只有输入的密码和该用户名匹配，才能成功登录，否则失败，具体用例设计如下表 6.2 所示。
2、微信客户端登录模块的实现，登录微信端时，只需输入手机号，点击获取验证码，然后输入验证码登录即可。只需要判断手机号的位数是否是 11，不需考虑平台中是否存在该用户，并且平台对输入的手机号位数做了限制，最大 11位。用例设计具体见下表 6.3。
3、微信支付充值功能的实现，为自己余额充值时，只需输入合理的金额，点击充值即可，合理的金额输入范围是 1 到 1000000，此处采用边界值分析法，用例设计具体见下表 6.4。
4、运营管理端订单查询功能测试用例设计，在该部分中存在许多条件查询，设计测试用例时，必须尽可能的覆盖全面，用例设计具体见下表 6.5。
5、通过文件批量添加充值卡功能，文件格式是以.xls 为后缀的 Excel 文件，大小不超过 2M，表中不存在相同卡号的充值卡，同时不能和平台中现有的充值卡相同，一旦相同，全部添加失败。测试用例设计见表 6.6。
同时针对文件大小，采用边界值分析法设计测试用例。具体测试用例设计见表 6.7。
6.5.2 配置测试环境。
测试环境软硬件配置如下表 6.8。
首先配置好 JDK 和 Tomcat 的环境变量，然后将项目部署到 Tomcat 服务器上，连接数据库服务器，点击 Tomcat 的 startup.bat 启动项目运行。
6.5.3 使用人工测试。
对平台的功能性测试，微信端和安卓端都采用人工测试，如登录微信端，微信端充值等功能。对于 Web 中的功能采用 Selenium IDE 自动化测试。
1、微信登录功能测试。
微信登录功能测试采用的是人工测试，根据 6.5.1 中设计的测试用例实施测试，得出的测试结果表如 6.9。
在实际测试时发现，使用第三方 Submail 短信服务时，经常发生接收短信延迟，导致多次获取验证码的情况。通过代码检查发现，这个问题和实现方式无关，而是 Submail 短信服务本身的延迟问题。这个问题在平台上线后，遭到许多用户反馈，此后会就此问题和 Submail 短信服务平台进行沟通。
2、微信支付充值功能测试。
微信支付充值功能测试采用的是人工测试，根据 6.5.1 中设计的测试用例实施测试，得出的测试结果表如 6.10。
从测试结果表中可以看出，当输入 0.9 时，界面无任何变化，如图 6.4 所示，和预期结果“充值失败，金额太小”不符。继续多次输入小于 1 的数，得到同样的结果。通过对代码检查发现，if…else 语句中没有调用到“充值失败，金额太小”的提示弹框方法。只需将该提示框对应的方法加载到 if…else 语句中即可。
修改完成后，通过再次对该用例多次测试得出预期结果。
3、运营管理端批量添加充值卡功能测试。
对于批量添加充值卡功能，需要使用等价类和边界值两种方法测试。首先是使用等价类划分进行测试，得出的结果表如表 6.11 所示。
从第 8、9 个用例可以看出，测试结果和预期结果不一致。编号和充值卡号是一一对应的，以第 8 个用例为例，如图 6.6 所示，文件中存在编号为 500607，同时平台中已存在 500607 的充值卡，在上传时，文件中排在 500607 前面的500606 却上传成功。
为了保证数据的一致性和完整性，无论是文件中存在相同充值卡还是文件中有和平台中相同的充值卡，上传时，都不能导入。建议为了解决此类问题，增加级联操作，当存在相同充值卡时，全部导入失败。对此部分代码修改后，经过多次测试发现，当存在相同卡号的充值卡时，全部导入失败。
其次使用边界值法对文件的大小边界测试，如表 6.12。
通过上述测试测试结果和预期结果对比，发现与预期结果一致，该功能暂时可行。这只是其中一组测试用例，而在实际应用中，对于每个功能，不能只通过一次测试判断成功与否，必须经过多次验证。
6.5.4 使用 Selenium IDE 测试。
主要是使用 Selenium IDE 对运营管理端的某些功能进行功能测试，例如登录功能，订单查询等功能，下面将按照 6.5.1 节中的测试用例进行测试。
1、登录功能测试。
（1）首先保证页面元素完整，且各元素位置合适。
（2）录制脚本。在 FireFox 浏览器中打开 Selenium IDE，点击录制，然后在浏览器中输入 http://119.29.110.236:8080/HxfBizWeb/console! layout. action 地址，在输入框中用户名和密码点击登录按钮。
（3）录制完毕，执行测试。结果如图 6.6 所示，录制所有测试用例，然后一起执行，结果显示正确执行 5 个测试用例，错误数为 0，同时可以在 Log 中查看结果，并且可以在浏览器中看到执行过程，并且确实登录成功跳转到主页面。
并且通过对所有的测试用例实施测试得到测试结果表如表 6.13。
从上表中可以看出，测试结果同预期结果一致。以使用 songyizhi 和 123 登录为例，如图 5.4 所示，输入用户名 songyizhi 和密码 123，选择运营端，点击登录，得出 6.7 所示结果图，跳转到主页。
2、订单查询功能测试。
（1）首先保证页面元素完整，且各元素位置合适。
（2）录制脚本，选择条件进行查询。
（3）录制完毕，实施测试。执行测试时，出现如图 6.8 结果，执行错误，原因是由于使用了Panel面板导致，需要对脚本进行修改，修改后的脚本如下所示，并且修改后测试结果如图 6.9。
修改后的脚本：
同理，对于其他用例，采用同样的处理方法，在此不作赘述。经过对所有测试用例实施测试之后，得出如表 6.14 所示结果。
由于篇幅限制，仍有部分条件组合测试用例结果未能列出，但在实际测试中，将测试结果和预期结果对比，发现测试结果仍符合预期。
6.6 测试结果分析。
在此次测试中，所有的 bug 都是通过柠檬 bug 管理器管理的，在该管理器中可以设计测试用例，提交 bug，还能用图的形式统计 bug 情况。图 6.11 是按bug 状态统计的结果。
从图中可以看出，迄今为止总共向 bug 管理器中提交了 167 个 bug（由于在该项目的前期本文作者没有加入，也没有统计 bug），再加上对前面 bug 的统计，会发现大概测试出了 320 左右的 bug，并且 bug 已经解决了 94.61%，平台的功能已经基本稳定，还有一些不影响使用的 bug 由于程序员对工作重要性判断的问题搁置了，后续将会处理。
通过使用人工和 Selenium IDE 测试方法反复对功能进行测试发现，当如登录功能一样不涉及一些复杂多变的页面插件技术时，使用自动化测试能比人工测试节约一倍时间完成测试；但对如订单查询功能一样使用像 Treegrid 和 Panel等插件的功能，使用 Selenium IDE 时，每次执行都要重新定位，花费人工测试的两倍时间完成测试。在实际应用中，应当选择合适的方法进行测试，避免浪费时间，增加开发成本。
通过迭代和回归测试，功能基本完善，平台可以稳定运行，并且项目已验收并上线。经过一段时间的试运行，通过用户反馈发现，页面友好性得到了用户的称赞，简单的下单操作也符合用户的需求。
6.7 本章小结。
本章节主要讲述的是对平台的测试，以登录、订单查询、充值等功能为例设计测试用例，然后使用人工和 Selenium IDE 执行测试，然后对测试结果分析。
通过对平台测试发现，不是每个功能采用 Selenium IDE 的测试效果都比人工测试好，在实际测试时，应该选择合适的方法测试对应的功能。
