嘀嘀嘀—— 倒车！请注意！倒车！请注意！
Bilibili：非职业天使 战网国服：图南#51221 Steam：尸体A
前排广告君表示要辞职了!!! 这个up根本不更新还到处发广告！
一、简述
-
题目要求
- 能够自动生成四则运算练习题
- 可以定制题目数量
- 用户可以选择运算符
- 用户设置最大数（如十以内、百以内等）
- 用户选择是否有括号、是否有小数
- 用户选择输出方式（如输出到文件、打印机等）
- 最好能提供图形用户界面（根据自己能力选做，以完成上述功能为
-
任务分配
- 驾驶员：<X司机> 代码地址：<Pair_Programming>
- 领航员：<J指挥> 代码地址：<Pair_Programming_Test>
（点♂击♂名♂字♂打♂开♂链♂接）
二、代码测试
1、测试用例
- 测试对象：getOperatorArray()，buildItems()，dealError()
- 覆盖标准：针对方法的每一个传出结果进行条件组合覆盖
- 用例设计：
- getOperatorArray()有四个传入参数，一个传出参数，全是布尔变量。所以结果只有两种，true和false。当所有传入为false时，结果为false。因此共16种用例。
- buildItems()有一个传入参数，一个传出参数。当传入为正数，传出1；其他传入时传出皆为0。因此只有两种用例。
- dealError()里面每个if下都是直接返回，并且不同的if之间判定条件有交叉，不能单纯的画出流程图判断都覆盖了哪些条件。因此针对每一种结果进行条件组合覆盖。
- 当结果为0时，所有输入合法，一组用例即可；
- 当结果为1时，max、sum输入不合法。各自不合法+同时不合法共三种，还有最后一个布尔判定，所以有六种用例。
- 当结果为2时，max、sum值能通过程序（即字符串转换成 int 和 float），但是sum值太大。此时判定条件与之前有交叉，理论上也属于“不合法”。max值固定合法，sam为大数，后面布尔有两种情况。因此共两种用例。
- 当结果为3时，sum、max必须合法，最后条件必为false，只有一种用例。
修改建议：
如果想细分“不合法”的条件就应该sum为一类，max为一类。sum里包括输入不为正和输入太大；max包括输入不为正。不然合并在一起大家都是不合法，写成交叉数学逻辑上没错，但是不符合逻辑习惯。
顺便max也可加入“不能过大”的条件。小学数学不需要太多大数，万以内就足够了。
2、自动测试
- 测试技术：采用Junit进行自动测试。
- 代码：<Coding>
1 public class MainActivityTest {
2
3 @Test//动态处理运算符数组并返回checked值
4 public void getOperatorArray() {
5 assertEquals(true,new MainActivity().getOperatorArray(true,true,true,true));
6
7 assertEquals(true,new MainActivity().getOperatorArray(true,true,true,false));
8 assertEquals(true,new MainActivity().getOperatorArray(true,true,false,true));
9 assertEquals(true,new MainActivity().getOperatorArray(true,false,true,true));
10 assertEquals(true,new MainActivity().getOperatorArray(false,true,true,true));
11
12 assertEquals(true,new MainActivity().getOperatorArray(true,true,false,false));
13 assertEquals(true,new MainActivity().getOperatorArray(true,false,true,false));
14 assertEquals(true,new MainActivity().getOperatorArray(false,true,true,false));
15 assertEquals(true,new MainActivity().getOperatorArray(true,false,false,true));
16 assertEquals(true,new MainActivity().getOperatorArray(false,true,false,true));
17 assertEquals(true,new MainActivity().getOperatorArray(false,false,true,true));
18
19 assertEquals(true,new MainActivity().getOperatorArray(true,false,false,false));
20 assertEquals(true,new MainActivity().getOperatorArray(false,true,false,false));
21 assertEquals(true,new MainActivity().getOperatorArray(false,false,true,false));
22 assertEquals(true,new MainActivity().getOperatorArray(false,false,false,true));
23
24 assertEquals(false,new MainActivity().getOperatorArray(false,false,false,false));
25 }
26
27 @Test//构建随机式，成功则返回1,失败则返回0
28 public void buildItems() {
29 assertEquals(1,new MainActivity().buildItems(10));
30 assertEquals(0,new MainActivity().buildItems(-10));
31 }
32 @Test//出错逻辑处理,返回出错类型并返回出错类型,返回0则无错,1为max、sum输入不合法，2为sum太大，3为没选操作符
33 public void dealError() {
34 assertEquals(0,new MainActivity().dealError("10","10",true));
35
36 assertEquals(1,new MainActivity().dealError("10","-10",true));
37 assertEquals(1,new MainActivity().dealError("10","-10",false));
38 assertEquals(1,new MainActivity().dealError("-10","10",true));
39 assertEquals(1,new MainActivity().dealError("-10","10",false));
40 assertEquals(1,new MainActivity().dealError("-10","-10",true));
41 assertEquals(1,new MainActivity().dealError("-10","-10",false));
42
43 assertEquals(2,new MainActivity().dealError("999999999","10",true));
44 assertEquals(2,new MainActivity().dealError("999999999","10",false));
45
46 assertEquals(3,new MainActivity().dealError("10","10",false));
47 }
48 }
-
测试结果：所有测试用例都通过测试。截图如下。
3、代码审查表
|
重要性 |
激活 |
级别 |
检查项 |
|
总计 |
|||
|
命名 |
|||
|
重要 |
Y |
20 |
命名规则是否与所采用的规范保持一致？ |
| Y |
20 |
是否遵循了最小长度最多信息原则？ |
|
|
重要 |
Y |
50 |
has/can/is前缀的函数是否返回布尔型？ |
|
注释 |
|||
|
重要 |
Y |
10 |
注释是否较清晰且必要？ |
|
重要 |
Y |
10 |
复杂的分支流程是否已经被注释？ |
| N |
10 |
距离较远的}是否已经被注释？ |
|
| N |
10 |
非通用变量是否全部被注释？ |
|
|
重要 |
Y |
50 |
函数是否已经有文档注释？（功能、输入、返回及其他可选） |
| Y |
10 |
特殊用法是否被注释？ |
|
|
声明、空白、缩进 |
|||
| N |
20 |
每行是否只声明了一个变量？（特别是那些可能出错的类型） |
|
|
重要 |
Y |
40 |
变量是否已经在定义的同时初始化？ |
|
重要 |
Y |
40 |
类属性是否都执行了初始化？ |
| Y |
20 |
代码段落是否被合适地以空行分隔？ |
|
|
Y |
20 |
是否合理地使用了空格使程序更清晰？ |
|
| Y |
20 |
代码行长度是否在要求之内？ |
|
| N |
20 |
折行是否恰当？ |
|
|
语句/功能分布/规模 |
|||
| Y |
20 |
包含复合语句的{}是否成对出现并符合规范？ |
|
| N |
20 |
是否给单个的循环、条件语句也加了{}？ |
|
| Y |
20 |
if/if-else/if-else if-else/do-while/switch-case语句的格式是否符合规范？ |
|
| Y |
40 |
单个变量是否只做单个用途？ |
|
|
重要 |
Y |
20 |
单行是否只有单个功能？（不要使用；进行多行合并） |
|
重要 |
Y |
40 |
单个函数是否执行了单个功能并与其命名相符？ |
|
Y |
20 |
操作符＋＋和— —操作符的应用是否复合规范？ |
|
|
规模 |
|||
|
重要 |
Y |
20 |
单个函数不超过规定行数？ |
|
重要 |
Y |
100 |
缩进层数是否不超过规定？ |
|
重要 |
Y |
100 |
是否已经消除了所有警告？ |
|
重要 |
Y |
40 |
常数变量是否声明为final？ |
|
重要 |
Y |
80 |
对象使用前是否进行了检查？ |
|
重要 |
N |
80 |
局部对象变量使用后是否被复位为NULL？ |
|
重要 |
Y |
70 |
对数组的访问是否是安全的？（合法的index取值为[0, MAX_SIZE-1]）。 |
|
重要 |
Y |
20 |
是否确认没有同名变量局部重复定义问题? |
| Y |
20 |
程序中是否只使用了简单的表达式？ |
|
|
重要 |
Y |
20 |
是否已经用（）使操作符优先级明确化？ |
|
重要 |
Y |
20 |
所有判断是否都使用了（常量==变量）的形式？ |
| Y |
80 |
是否消除了流程悬挂？ |
|
|
重要 |
N |
80 |
是否每个if-else if-else语句都有最后一个else以确保处理了全集？ |
|
重要 |
Y |
80 |
是否每个switch-case语句都有最后一个default以确保处理了全集？ |
| Y |
80 |
for循环是否都使用了包含下限不包含上限的形式？（k=0; k<MAX） |
|
|
重要 |
Y |
40 |
XML标记书写是否完整，字符串的拼写是否正确? |
| Y |
40 |
对于流操作代码的异常捕获是否有finally操作以关闭流对象? |
|
| Y |
20 |
退出代码段时是否对临时对象做了释放处理? |
|
|
重要 |
Y |
40 |
对浮点数值的相等判断是否是恰当的？（严禁使用==直接判断） |
|
可靠性（函数） |
|||
|
重要 |
Y |
60 |
入口对象是否都被进行了判断不为空？ |
|
重要 |
Y |
60 |
入口数据的合法范围是否都被进行了判断？(尤其是数组) |
|
重要 |
Y |
20 |
是否对有异常抛出的方法都执行了try...catch保护？ |
|
重要 |
Y |
80 |
是否函数的所有分支都有返回值？ |
|
重要 |
Y |
50 |
int的返回值是否合理？（负值为失败，非负值成功） |
| Y |
20 |
对于反复进行了int返回值判断是否定义了函数来处理？ |
|
| Y |
60 |
关键代码是否做了捕获异常处理? |
|
|
重要 |
N |
60 |
是否确保函数返回CORBA对象的任何一个属性都不能为null? |
|
重要 |
N |
60 |
是否对方法返回值对象做了null检查，该返回值定义时是否被初始化? |
|
重要 |
N |
60 |
是否对同步对象的遍历访问做了代码同步? |
|
重要 |
N |
80 |
是否确认在对Map对象使用迭代遍历过程中没有做增减元素操作？ |
|
重要 |
N |
60 |
线程处理函数循环内部是否有异常捕获处理，防止线程抛出异常而退出? |
| N |
20 |
原子操作代码异常中断，使用的相关外部变量是否恢复先前状态? |
|
|
重要 |
Y |
100 |
函数对错误的处理是恰当的？ |
|
可维护性 |
|||
|
重要 |
Y |
100 |
实现代码中是否消除了直接常量？（用于计数起点的简单常数例外） |
| Y |
20 |
是否消除了导致结构模糊的连续赋值？（如a= (b=d+c )） |
|
| Y |
20 |
是否每个return前都要有日志记录? |
|
| Y |
20 |
是否有冗余判断语句？（如：if (b) return true; else return false;） |
|
| N |
20 |
是否把方法中的重复代码抽象成私有函数? |
三、UI测试 ——参考自<APP的UI测试>
- 欢迎界面美观。
-
标题栏文字描述正确，背景颜色合理。
-
背景颜色与字体颜色和背景色相搭配.
-
布局合理。控件，文字，线条位置，数量，颜色合理，跟整体风格搭配。
-
界面文字无错别字。文字大小，颜色，位置一致。
-
控件大部分使用正常。
-
提示框设计合理，提示语友好，简明。
-
列表型界面有上下滑动效果。
-
窗口适应差，不能横向。
-
功能入口不明显。
修改建议：
1、右上角菜单为无效菜单，需删除。
2、右下角生成按钮图标不明确，更像是“刷新”。建议按钮上标注文字“生成题库”。
3、界面窗口不能自动适应各种类型的屏幕。
4、应提示用户点击算式查看答案。
四、功能测试
APP本体：点击下载APP
测试环境：荣耀畅玩6X Android7.0
测试流程：安装->运行->基本功能测试->异常处理测试
测试截图：
进入APP：欢迎界面美观，停留时间合理。
输入非法字段，弹出提示。
题数过多，弹出提示。
生成题目
测试结果：
- 能够自动生成四则运算练习题 √
- 可以定制题目数量 √
- 用户可以选择运算符 √
- 用户设置最大数（如十以内、百以内等）√
- 用户选择是否有括号、是否有小数 √
- 用户选择输出方式（如输出到文件、打印机等）×
- 最好能提供图形用户界面 √
五、评价
我的小伙伴果然超级厉害，很快就写完了程序，而且还做出了界面，已经可以发布了~ 但是有一些细节需要处理。比如对“不合法”条件的理解，判定条件之间有交叉；还有界面右上角无效菜单，右下角生成按钮图标不明确，界面窗口不能自动适应各种类型的屏幕，也没提示用户查看答案的方法。
还有最重要的是不能导出生成的题目。这应该在开发的最一开始就决定的。我们的题意其实是想给老师做一个程序，让他们出题方便。但是我的小伙伴没有考虑这一点，只完成了基本的功能，这样只能让学生自己下载app然后使用了。但是小学生怎么可以让他们随便玩手机呢！理想的情况应该是导出一个.txt或者.doc，老师可以再进行编辑，然后打印出来当卷子给学生使用。而且可以把正确答案再单独导出一份，方便老师批改卷子。
如果只是这样的app给学生使用的话，其实还可以做成自测小程序，让学生自己输入算的答案，最后点击提交，程序可以对比答案，直接给出分数。
六、总结
过这次作业，我对敏捷编程有了初步的认识和体验。两个人一起能够互相监督，互相帮助。说来惭愧，代码都是我的小伙伴独立完成的，我只能看看，再研究研究是怎么写的。毕竟当初选修的Android课是全英文授课，没听懂就算了，自己也没课后研究，现在有点想吃后悔药了orz
本来作业中测试的本意是想锻炼我们熟练掌握覆盖标准和自动测试，但是最初我们的程序没有能测试的地方。整个功能的实现都在一个大类里，而且我们生成的随机算式是没办法进行测试的。输出是一个随机的数，我们怎么可能确定我们的期望值呢。为了能够测试，我的小伙伴又特意把程序大改了一遍，全部划分成小方法，设好了传入参数和传出参数，好让我能够有测试的东西。
我们一起预约了研修室，改了一下午程序，后来又预约了一小时，最后总算是有点成果了。想想其实如果准备工作充足，把程序的结构和功能提前设计明白，就没这么多麻烦事了。果然开发初期的工作真的很重要啊，大的方向把握好了才能走向成功的道路。我作为领航员却没有准备好初期工作，是我的失误。如今有了经验教训，以后一定再也不犯这个错误了。
时间紧迫，作为作业，我们只能这样把它提交了。但是作为一个成品，它还需要更多的修改和完善。如果有机会，我们可以把它好好做完，并投入使用。
