团队作业 (二)

5 实现

5.1 编码

5.1.1 代码约定

1.文件编码

2.自定义的函数名使用通俗易懂,一目了然的名字

4.列长限制

注意花括号的匹配,在代码换行时至少缩进4个空格,缩进不要用tab,增强代码的可读性和美观性。

5.注释

注释应少而精,注释的作用只是用来增加重要的代码段的易读性,代码的关键处应有注释。

6.变量声明

每次只声明一个变量,不要使用组合声明,需要变量时再声明,不推荐同时初始化很多变量,尽快将刚刚定义的变量进行初始化。

7.命名约定

变量命名应遵循见名知意、简洁的原则,变量名的定义要以可读性为主,不要使用模糊的变量名进行定义,同时也要避免中英文混用。

8.成员顺序

每个自定义函数功能模块应该以某种逻辑排序成员,使维护者能解释这种排序逻辑。

9.慎用条件判断。

10.使用大括号合理的囊括循环的代码段。

11.减少代码嵌套

减少嵌套方法:(1)合并初始条件条件相同的代码段;(2)利用return以省略else;

5.1.2 代码编写原则

1)关键代码段的注释应该尽可能全面

对于方法的注释应该包含详细的入参和结果说明,自定义函数的注释应该包含该函数本身功能的说明。

2)多次使用的相同变量最好归纳成常量

多处使用的相同值的变量应该尽量归纳为一个常量,定义为define类型,直接引用,并且可以方便日后的维护。

3)尽量少的在循环中执行方法调用

尽量在循环中少做一些可避免的方法调用,这样可以节省方法栈的创建。

4)常量的定义可以放到define中。以减少常量定义和引用的次数。

5)包装类和基本类型的选择

如果使用基本数据类型来做局部变量类型,尽量使用基本数据类型,因为基本类型的变量是存放在栈中的,包装类的变量是在堆中,栈的操作速度比对快很多。

6)尽早的将不再使用的变量引用赋给NULL

7)如果引用指针的话最后要关闭指针,并对开辟的内存空间进行有效回收,避免内存资源空间的浪费。

8)函数最短原则(不多于30行)。

9)变量单一职能原则(一个变量只允许承担一个责任,针对每次赋值,创建一个独立。对应的临时变量。循环变量和收集结果变量除外)。

10)函数单一职能原则(一个函数只做一件事情)。

11)for循环单一职能原则(一个for循环只做一件事情,也许你会考虑效率问题,但不经过测试是没有发言权的)。

11)三次原则(事不过三,三则重构)。

5.2 测试要点

5.2.1 登录测试要点

登陆测试要点:
使用合理的测试用例对游戏界面的测试
1.按照游戏界面的提示,按下正确的按键。观察程序的反应。
2.输入默认值,空白,空格;
3.如果程序只允许输入字母,尝试输入数字;反之,尝试输入字母,
4.强制输入程序不允许的输入数据,观察程序是否能正确处理非法数据。

5.2.2 主界面测试要点

主界面测试要点:对用户按键输入进行测试。当用户按下错误的按键,系统如何处理。

测试方法:

1)当用户按下指定的按键是观察系统给出的相应。如单击“帮助”,正确执行操作;再按一下帮助按钮,退出帮助界面。
2)对非法的输入或操作给出相应的相应,并应该给出足够的提示说明。
3)对可能造成数据无法恢复的操作必须给出明确的错误提示信息,给用户重新输入的机会。

5.3 测试结果和总结

对该项目的测试结果符合预期的结果,对各个模块都做了相应的单元测试,谈谈个人的一些看法,比如没有需求,也没什么任何文档或有少量不全文档;提交测试大部分是到了开发的后期,有一部分项目是快验收了,才提交测试。面对这些问题,一直未有很好的解决办法,个人觉得测试人员针对这些问题可以自己作一些调整,以期更好的完成测试工作:

  1. 得到了测试任务之后,可以首先看看功能能不能正常走通。

  1.1 根据功能做一个基本的测试计划,并写明一些测试方法(如边界值,等价类划分等)。

  1.2 开始要实施测试了,一边写测试用例一边执行,如果可以最好是先写测试用例然后执行,没时间写完整的用例时,可以列出需求点,针对每个需求点来进行测试。同时在执行中及时的补充与修改。

  1.3 要整理出对功能中不明白之处,可以找相关人员可以是PM沟通。这个一定要坚持直到得到明确的答案。

  2. 学会换位思考,将自己当成客户

这是非常重要的,在测试中你可能会发现,有时无法关注测试的重点。

有时客户表达的需求,开发团队所理解的需求,以及客户真正使用时的需求,有重大的差别;

  这时你需要静下心来,将自己当成客户,如果是客户他会怎样来操作这个界面,同时他要这个功能主要想完成哪些工作,如何才能更方面操作、更快捷的完成工作。

  如此反复几次,这种思考方式将对你的测试非常有利。

  3. 非常复杂的业务逻辑,学会庖丁解牛,分解成一小块一小块测试

  有时你会碰到这种情况,所要测试的模块业务逻辑非常复杂。

  这时你该怎么办呢?工作中一定要静下心来,认真仔细的分析这个业务。由简单到复杂,简单的测试通过后才能做复杂的测试。而不是一开始就做复杂的测试。

  4. 求助开发或PM

  还有一种业务或者服务,因为作为测试开发经验较少,所以有时程序的方法还不是很了解。也不知道这个功能是怎么实现的,但为了做到百分百的测试。你需要求助于开发或PM,让他们来帮你完成测试方法或用例。

  同时更重要的是,你要以他们给的方法和用例为基石,设计出更好的更全面的测试方法。

程序源代码:https://coding.net/u/xiaotangyuan/p/heibaiqi/git/blob/master/%E9%BB%91%E7%99%BD%E6%A3%8B.cpp

时间: 2024-10-22 03:53:34

团队作业 (二)的相关文章

团队作业二之需求调研

这次的软件工程团队合作我们我们小组准备合作制作一个针对校内师生的购书网站,简单来说就如同京东淘宝当当那些大型电商网站一样,但我们能力有限,只能面对我们学校师生制作一个购书网站,来解决教科书购书难,使用过后闲置的问题,如今学期过半,也早已没有那种为教科书无处订购.价格昂贵的问题而发愁了.但在刚刚开学的时候,我们却感觉这是个很头疼的问题,向学长学姐借的书目不全.单人购买的昂贵.找不到集体购买的渠道,着实让我们很伤脑筋,,每个学期初买书需要将近400块钱费用,有的同学会向学长学姐借书,但是不能保证学长

团队作业二

各组结合所选项目,编写项目的规格说明书(Spec),Spec应至少包含以下内容: 1. Spec的目标 2. 项目的典型用户和场景 3. 项目的用例模型 4. 项目中涉及到的术语,它们的含义是什么? 5. 用户是如何使用软件的功能的? 1.Spec的目标 信息管理系统是一个十分基础且必要的应用程序,几乎每个公司,每个组织都会有一个属于自己的信息管理系统,方便增删改查管理人员的信息.此Spec是为了更好的阐述本程序的细节问题,使开发更具体,内容包括项目的典型用户和场景,项目的用例模型,项目中涉及到

团队作业3---需求改进&系统设计

一.需求&原型改进 1.团队作业2改进 补充a:市面上还有哪些同类的四则运算生成软件呢?  之前在作业一的时候有稍微提到过,市面上的四则运算软件太过于杂乱,要么就是广告连篇,要么就是收费后才能使用全部功能,这给用户带来了诸多的不便,以下是一些我们调查的四则运算生成软件: (1)随机四则运算生成器 2.1.50 这个软件下载来使用之后,发现是未注册版,需要我们去消费才能使用,这显然在市场竞争中是没有什么优势的. 而且经常在使用过程中出现网络错误等提示: 或许是软件的兼容性做的不大好,我们来看一下它

团队作业成绩分配

团队作业一分配情况: 得分7分   人数6人 张航 7.5分     刘羽霏 7.5分     王向阳 7.5分 赵峻 6.5分     张元爽 6.5分     彭雪峰 6.5分 团队作业二分配情况: 得分6分   人数6人 张航 6分     刘羽霏 6分     王向阳 6分 赵峻 6分     张元爽 6分     彭雪峰 6分

团队作业八——第二次团队冲刺(Beta版本)第6天

团队作业八--第二次团队冲刺(Beta版本)第5天 一.每个人的工作 (1) 昨天已完成的工作 简单模式逻辑代码涉及与相关功能的具体实现 (2) 今天计划完成的工作 修改完善注册登录内容界面,编辑错题文件写入. (3) 工作中遇到的困难 今天花了较多时间在完善登录注册界面上,这让我们比较担心,如果每天都花很多时间在解决之前的问题,当天的任务又做不好,会不会赶不上进度.如果每天都不能正常完美的完成每天任务,那冲刺最后一天结束的时候,又哪里再有一个明天给我们完善代码.且今天还遇到了写入SD存储卡文件

团队作业八——第二次团队冲刺(Beta版本)第4天

团队作业八--第二次团队冲刺(Beta版本)第4天 一.每个人的工作 (1) 昨天已完成的工作 做一下用户注册的功能和登录功能. (2) 今天计划完成的工作 完成界面跳转 (3) 工作中遇到的困难 界面跳转涉及到逻辑性相对复杂,所以具体做的时候会出现一些小的问题. (4) 每个人的贡献比 二.燃尽图 三.代码 package com.example.asus.app_sizeyunsuan; import android.content.Intent; import android.suppor

团队作业八——第二次团队冲刺(Beta版本)第5天

团队作业八--第二次团队冲刺(Beta版本)第5天 一.每个人的工作 (1) 昨天已完成的工作 完成界面跳转界面. (2) 今天计划完成的工作 简单模式逻辑代码涉及与相关功能的具体实现 (3) 工作中遇到的困难 错题本功能完成过程中遇到一些问题 (4) 每个人的贡献比 二.燃尽图 三.代码 package com.example.asus.app_sizeyunsuan; import android.os.Environment; import android.support.v7.app.A

第5周团队作业2:团队贡献分分配

Echo队共有成员7人,团队贡献分共350分.我们经过讨论确定了一套分配团队贡献分的方案,现将相关内容记录如下: 一.方案原则 1.分数的分配应当能够反映出每位成员对团队的真实贡献.即贡献越多的成员将得到越多的团队贡献分,贡献较少的成员将获得相对较低的团队贡献分. 2.分数的分配方案应当充分调动成员的积极性.即对于积极参与团队贡献的成员,应当给予鼓励:对于较少参与团队贡献的成员,应让其感受到一种紧迫感. 二.方案考虑 1.每项作业要“悬赏”一定的分数,对全程参与的成员给予相应的分数.如此一来利于

团队作业八——第二次团队冲刺(Beta版本)第7天

团队作业八--第二次团队冲刺(Beta版本)第6天 一.每个人的工作 (1) 昨天已完成的工作 登录注册功能的完善与实现和简单测试模块的优化 (2) 今天计划完成的工作 修复昨天写入SD存储卡文件权限问题,以及中级和高级功能的实现. (3) 工作中遇到的困难 只完成了部分,具体见明天... (4) 每个人的贡献比 二.燃尽图 三.代码 由于今天班级活动和班聚耽误了下午和晚上的时间,我们只完成了部分,完整的代码明天会补上的 四.模块部分截图 同样明天见... 五.项目进展 今日计划内容被打乱,只完

团队作业四-团队项目汇总

一.Daily Scrum Meeting[Alpha] 团队作业4--第一次项目冲刺(Alpha版本)预备工作 团队作业4--第一次项目冲刺(Alpha版本)第一天 and 第二天 团队作业4--第一次项目冲刺(Alpha版本)第三天 团队作业4--第一次项目冲刺(Alpha版本)第四天 团队作业4--第一次项目冲刺(Alpha版本)第五天 团队作业4--第一次项目冲刺(Alpha版本)第六天and第七天 二.Daily Scrum Meeting[Beta] 三.git git地址: htt