标签：机械 理解 沟通 计划 相关 结构 null 内核 子函数
小组成员：
1.王海汀
2.夏国平
3.张慧鑫
4.李鑫
5.黄伟
1.1 开发背景
程序建立的目标是为了解决现实中的问题。在寝室断电之后，伴随而来还有网络不畅。这时对于睡眠质量不太好的同学就需要有消遣娱乐的活动。因此我们决定开发 这样一款单机操作的黑白棋游戏。
1.2 开发目标
兼容性强，提示清楚，操作简单，具有存档记忆动能，最重要的是可以玩家与玩家进行对战。
1.3 参考资料
《构建执法》（第二版）邹欣，人民邮电出版社；
《代码大全》，（第二版）史蒂夫.麦克康奈尔，电子工业出版社；
《统一软件开发过程》Ivar.Jacobson，机械工程出版社。
该软件是一款集竞技性和娱乐性的一款棋牌类软件，它可以解决同学在寝室断网的情况下的无聊问题，可以进行两人对战，同学之间相互切磋，增进感情。
首先是打开软件，按S开始游戏，按Q退出游戏：
接下来选择S开始的界面，进入游戏，WASD对应上左下右移动，O确定落子，H是提示当前玩家可以落子的位置：
如图是点开H之后的帮助界面，黑子先行：
接下来走了几步：
很简单的风格，不需要什么复杂的设计
也是通过简单的绘图工具实现的，将操作的事项列在棋盘的下方，方便使用者查看。
（3）输赢判断：
通过if判断，根据对方棋子的位置来判断自己是否可以落子，如果可以的话就选择可以落子的地方落子，如果不能的话，那么游戏结束。
Windows操作系统，32位或64位均可
主函数里包含游戏欢迎界面函数，棋盘界面初始化函数，游戏主体函数和退出函数。
初始化游戏界面函数里包含输出棋子函数，有效区域函数；
控制棋子函数里包含显示棋子函数；
1.文件编码
2.自定义的函数名使用通俗易懂，一目了然的名字
4.列长限制
注意花括号的匹配，在代码换行时至少缩进4个空格，缩进不要用tab，增强代码的可读性和美观性。
5.注释
注释应少而精，注释的作用只是用来增加重要的代码段的易读性，代码的关键处应有注释。
6.变量声明
每次只声明一个变量，不要使用组合声明，需要变量时再声明，不推荐同时初始化很多变量，尽快将刚刚定义的变量进行初始化。
7.命名约定
变量命名应遵循见名知意、简洁的原则，变量名的定义要以可读性为主，不要使用模糊的变量名进行定义，同时也要避免中英文混用。
8.成员顺序
每个自定义函数功能模块应该以某种逻辑排序成员，使维护者能解释这种排序逻辑。
9.慎用条件判断。
10.使用大括号合理的囊括循环的代码段。
11.减少代码嵌套
减少嵌套方法：（1）合并初始条件条件相同的代码段；（2）利用return以省略else；
1）关键代码段的注释应该尽可能全面
对于方法的注释应该包含详细的入参和结果说明，自定义函数的注释应该包含该函数本身功能的说明。
2）多次使用的相同变量最好归纳成常量
多处使用的相同值的变量应该尽量归纳为一个常量，定义为define类型，直接引用，并且可以方便日后的维护。
3）尽量少的在循环中执行方法调用
尽量在循环中少做一些可避免的方法调用，这样可以节省方法栈的创建。
4）常量的定义可以放到define中。以减少常量定义和引用的次数。
5）包装类和基本类型的选择
如果使用基本数据类型来做局部变量类型，尽量使用基本数据类型，因为基本类型的变量是存放在栈中的，包装类的变量是在堆中，栈的操作速度比对快很多。
6）尽早的将不再使用的变量引用赋给NULL
7）如果引用指针的话最后要关闭指针，并对开辟的内存空间进行有效回收，避免内存资源空间的浪费。
8）函数最短原则（不多于30行）。
9）变量单一职能原则（一个变量只允许承担一个责任,针对每次赋值，创建一个独立。对应的临时变量。循环变量和收集结果变量除外）。
10）函数单一职能原则（一个函数只做一件事情）。
11）for循环单一职能原则（一个for循环只做一件事情，也许你会考虑效率问题，但不经过测试是没有发言权的）。
11）三次原则（事不过三，三则重构）。
登陆测试要点：
使用合理的测试用例对游戏界面的测试
1.按照游戏界面的提示，按下正确的按键。观察程序的反应。
2.输入默认值，空白，空格；
3.如果程序只允许输入字母，尝试输入数字；反之，尝试输入字母，
4.强制输入程序不允许的输入数据，观察程序是否能正确处理非法数据。
主界面测试要点：对用户按键输入进行测试。当用户按下错误的按键，系统如何处理。
测试方法：
1）当用户按下指定的按键是观察系统给出的相应。如单击“帮助”，正确执行操作；再按一下帮助按钮，退出帮助界面。
2）对非法的输入或操作给出相应的相应，并应该给出足够的提示说明。
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
6 维护
6.1：维护方法
1,建立明确的软件质量目标和优先级。事先开始做组织工作，需要建立维护机构，申明提出维护申请报告的过程及评价过程：为每一个维护申请规定的处理步骤；还必须建立维护活动的登记制度以及规定评价和评审的标准。
2,使用提高软件质量的技术和工具。模块化和结构化程序设计，使用结构化程序设计技术，提高现有系统的可维护性。
3,进行明确的质量保证审查。
4,验收检查是一个特殊的检查点的检查，是交付使用前的最后一次检查，是软件投入运行之前保证可维护性的最后机会。
5,周期性的维护审查，并选择可维护的程序设计语言。
6,好的文档是建立可维护性的基本条件。程序应当成为其自身的文档，即在程序中插入注释，以提高程序的可理解性，并缩进，空行等明显的视觉组织来突出程序的控制结构。
6.2：维护文档
6.3：功能拓展方法
在软件维护过后，有些用户可能需要更多的软件功能，这样我们就需要给软件功能进行拓展。为了估计软件维护的有效程度，确定软件产品的质量，并且确定在维护中的实际开销，所以在功能拓展中应当做好事先的拓展方案以及市场调查。
iptables的扩展实现：为了实现新的扩展，需要在iptables的源代码目录下的extensions目录添加新的功能的代码。iptables的扩展功能框架非常清晰，只需要按照iptables的match结构xtables_match和target结构xtables_target的定义，实现相应的功能即可。
C语言程序员也可以实现这样的功能！可以实现一下tc的扩展。以tc中的filer为例。tc的用户可以实现自己的filter的实现，并将生成的so库文件放置在tc的库目录下。那么该扩展功能既可以被tc支持。同时，还要编写一个tc的内核实现模块并加载。这样，新的功能，在不重新编译tc，不重启机器的情况下，就得以支持了。也是我们期待的结构。
标签：机械 理解 沟通 计划 相关 结构 null 内核 子函数
原文地址：http://www.cnblogs.com/wanghaiting/p/6115462.html
