| summergroup2008's profile软件实现技术小组BlogListsNetwork |  Tools  Help |
|
|
June 26 测试部分的一点资料和总结http://msdn.microsoft.com/zh-cn/library/aa292191(VS.71).aspx（来源：msdn visual studio开发中心）
这个链接的内容和老师介绍的部分很一致，提供了一些详细信息。 为了节省时间，我们采取一人阅读、搜索和整理相关资料。然后对全组讲述，和对于不清楚或者存在问题的部分全组讨论的形式进行学习。
时间：6月25日 参加人员：全组 讲述：陈旭明 记录：孙文晶
1、基于需求的测试
对需求提出了三点要求：A、明确的，只能用一种方式解释。B、必须可以以一种确保程序编译的方式来测试。 C、所有要求都应该是绑定的
对于绑定的理解：有人认为是需求要绑定到特定的代码实现逻辑， 有人认为需求要和测试用例一一对应。我们在这一项的理解上存在一些不一致，并不能互相说服，暂时认为两者均可
根据A B 两项重新核查了我们之前定义的需求， 认为第7项：合法的开关门响应时间为一秒。存在二义性，即响应时间，指的是接到指令到开始执行开关门动作的时间，还是接到指令，到开关门动作完成的时间。 经讨论，将其明确定义为前者。
2、测试方法
对于单元测试和集成测试。我们相对比较熟悉，有比较多的了解，对于老师上课时也讲到的回归测试，大多数成员相对比较陌生。根据我们对课程讲解的总结，回归测试指修改了旧代码后，重新进行测试，来确认修改有没有造成新的错误或者为其他代码引入错误。根据网页中列出的策略和内容，进行了进一步的理解。理解了有效的回归测试十以测试库为基础，我们总结回归测试的基本过程：
之后，我们回到电梯系统的test plan 部分的讨论，准备以测试优先级、测试类型、输入、执行步骤、期望输出为主要的字段、来设计和规划测试用例。 并形成初步文档。
由Test专题课程想到的~ 之前对Test过程的了解比较简单和片面。当郁老师提出关于Test概念问题的时候，还真的有些茫然。其实，如今人们对软件的质量越来越重视，就必然导致软件测试的地位越来越重要，毕竟测试是用来验证软件是否能够实现所期望功能的主要途径。在软件工程中，为测试规定了一个明确独立的阶段，而这使得我们产生了一个误解，认为测试是在软件开发后期才开始。是一个单独的阶段。而这次课通过郁老师的讲解，给我印象很深的是：测试贯穿于软件生命周期的每一个阶段。并且初步了解了在各个阶段中的测试应用。产品定义阶段的test plan. 设计阶段的test spec,开发阶段的测试工具开发和用例实现，检查阶段的Test passes check,还有发阶段的一些涉及到测试的工作。
老师还介绍了好多测试方法，还对其中一些举例和进行比较。
课后我们希望将这次了解到的测试知识有选择的深入讨论，并把它运用到这次电梯模拟的项目中来。并进行了初步的讨论。初步结果如下：
项目的测试目标为一个类，并且这个类有多个状态和状态转换，所以按照三部分来测试： 1、 基本接口（方法）的测试：根据接口的前置条件执行基本的功能测试。 2、 状态转换测试：每一个状态转换应该有至少一个测试用例去覆盖。本类中的状态转换包括电梯的状态转换和门的状态转换。 3、 其他测试：特殊需求和没有覆盖到的需求的测试。 先发上来，我们还希望根据各自对这部分知识的深入，进一步的讨论确定test plan. 电梯响应请求策略的讨论 之前我们的场景描述中，乘客可以通过两种方式与电梯系统交互。即：
1、通过电梯内部的控制面板设定目标楼层
2、通过每个楼层的上、下呼叫按钮 进行呼叫
电梯系统将按照一定的策略处理这些用户输入，我们对电梯的响应策略作了讨论， 讨论总结如下：
我们大致认为电梯可以有三种策略来处理用户的目标和呼叫请求：
1、先请求的先得到服务
这个策略主要是从实现简单出发而提出的。将所有呼叫和目标按到达时间排队，然后一一完成，这只需要设计一个将目标排队的数据结构。但是由于这不符合显示系统的运行策略。大多数组员，不同意这个方案。
2、按方向服务
这个策略是指在安全的前提下，一次将一个方向上的所有呼叫和目标全部完成，然后调转运行方向完成另一个方向上的呼叫和目标。
3、响应时间最短
我们希望电梯系统对所有的请求，能够做到在最短的时间内响应。
对于方案3，我们所想到的算法，都会引起频繁调转电梯方向。我们认为实现比较复杂，同时也不符合实际电梯系统的应用。所以经过讨论，我们决定采用方案2
从这个策略出发，讨论了可能出现的所有分支情况：
关于需求 我们初步讨论的电梯系统的需求如下：
一、场景描述
1、楼层数设为10。（为了简化测试用例的编写）
2、电梯的初始状态：停在一层，所有按钮未按下
3、乘客可通过电梯内部的控制面板选择要去的楼层，这里将这个选择叫做目标楼层
4、乘客也可通过外面的向上或者向下两个按钮呼叫电梯，这里将这个交互叫做呼叫
5、乘客还可以通过电梯内的开门关门按钮控制电梯的开关门状态
二、按优先级定义的需求
三、需求规约
1、电梯具有上升、下降、停止三种状态。
2、电梯在上升和下降过程中视为匀速运动，相邻层之间的运行时间设为3秒
3、一次将一个方向上的所有呼叫和目标全部完成、再调转方向完成另一个方向上的所有目标和呼叫
4、设置安全策略： 如果电梯正向第I层驶来，位于I层和相邻层之间，则出于安全考虑，忽略I层的请求或目标
5、电梯门状态为open,closed,opening,closing.电梯运行时电梯门始终保持为closed(即电梯上升和下降状态下，开门请求被拒绝)
6、电梯门正常开启时间为1秒，状态保持时间（即等待乘客上下时间）为5秒
7、合法请求下的开、关门响应时间为1秒
8、电梯门处于opening或者closing状态时，开关门请求被忽略
四、电梯系统功能定义
类成员说明
June 23 一些疑问这门课对我而言，就像刚刚接触许多其他课程一样，一些疑问会一直在我脑子里打转：这到底是门什么样的课程？什么叫软件实现技术？这门课的意义在哪里？其实，这些比较“白痴”的问题，对我而言，不是很好回答。我往往是在一门课快结束的时候，才体会到这门课真正的意义，才知道自己通过这门课学到了什么。 从小到大上过太多标准的lecture式的课程，对这些发自本能的问题甚至都已经失去了思考的动力，只知道遵照别人的安排，努力去让自己适应。从本科开始，互动式的课程慢慢从无到有，从少到多。到了研究生阶段，发现授课的过程基本都有了相当的互动。好多东西，需要自己从头去搞明白了。 软件实现技术，就跟景阳老师所传达给我们的，是一种优秀、高效的工程实践和习惯，是一种对技术的新的体验和理解。这是所有涉足技术领域并想有所深入的人都必须面对的。虽然只上了几次课，但是我已经发现我们所有的组员都对这次合作、领悟、交流的机会有很高的期待。相信这会是一次十分令人期待的发现过程。 June 16 编程之美！不要误会，这里不是长篇讨论各种高深技术问题，只是谈一下自己的一些体会。
通过老师对这次PHONE类的点评，突然想到一句话：优秀是一种习惯，这种习惯一旦养成，想做一只快乐的小猪都很难。
诚然，编程是一件很枯燥的事情，那么如何从中找到乐趣，那就是不断使其优秀。所谓学为止境，编程也是没有止境的。
把编程当作一件美好的事物，一件你手底下的工艺品，当你完成的作品能拿到高分，能得到别人的认可，这何尝不是一件兴奋的事情呢！
很遗憾这次没有拿到一个满意的分数，但至少学到一件事情，优化永无止境。
再说说这次小组项目，我们选的电梯类，从我们比较熟悉的应用来做。
就想景阳老师说的，重在体验整个过程，这个例子只要是学计算机方面出身的即使没动手编过，至少也听过不下几次。
但用微软的项目步骤来进行整个项目的定义，开发和测试，我们都是第一次。
首先我觉得一个重要的方面就是进度，微软非常的注重项目的进度控制，一个产品需要在合适的时间推出，才能赢得市场和客户。
当编程不再那么玄妙了时候，那时间变的尤为重要，这就要协调好各成员间的进度。
当一个人用心血完成一件作品的时候是多么的兴奋呢，当一个团队凝结六个人心血的作品出来的时候又会是如何的场面呢。
这编程美妙的时刻，让我们一同完成和分享吧！ 小组会议纪要
6月16日软件实现技术会议记录
June 13 关于mini project实现mini project的体会：
1、 需求分析和实现方案设计占用了mini project的大部分时间。 我们遇到的问题：课堂上不清楚的需求没有及时提问，而是讨论的形式确定。对需求的理解产生了严重的偏差。 甚至导致了项目完全偏离了题目要求，同时没有很好的了解老师给出的测试用例。 首先是老师给出的3个测试用例： 1） 电话的拨号音或者呼叫音在超过10秒之后，、转入BUSY状态。 2） 测试每个按键是否与返回的铃声一致 3） 测试键入的电话号和个人是否吻合 可能的测试用例还有 1） 两次按键间隔在0。3秒以内，报错，第2个键无效。 2） 按键回音超过1秒 3） 按键间隔超过5秒，就进入忙状态 4） 对输入大于或者小于8个数字时，电话状态的表示 5） 对于输入无效号码的返回 6） 拨号过程中挂机如何处理 其实从测试用例完全可以弄清楚那些模糊的需求 事实证明 需求分析的重要性了
以前做项目的时候一直都忽略需求，总是做个形式写个废话的文档，其实那是因为 自己对项目的需求完全的了解才使项目得以正常继续下去。这次mini project对我来说是 一次很好的锻炼，老师估计模糊的需求，以及一些让我们自己考虑和添加的需求。 自己在做这个项目的时候 没有仔细分析需求 而是想当然的按照自己的意愿来实现功能。 现在才明白，需求不是你程序员的需求，而是客户的需求，不能想当然，而应该认真分析， 沟通（比如这次如果课堂上有向老师提问那么 应该就不会发生项目的死亡）。 2、 寻找最佳的solution~
经过和其他组同学的讨论最后终于理解了这次 project的需求，再来就是实现上的问题了。
对于相同的需求，每个人的解决方案不同，而这些方案的优劣，来自于对需求的深刻理解，以及之前的开发经验。 还同时涉及对需求所设置的电话场景的理解我们在这些理解的基础上讨论，选择最优。 这次的要求是三个类 void SwitchOnHookOffHook() //对应电话待机与挂断状态 void PressKeyPadButton(int nKey) //对应电话的按键动作 SPEAKERSOUNDS GetSoundFromSpeaker() //对应听取电话的铃声状态 对于第一个Switchonhooloffhool（）实现起来相对简单，仅仅只要判断电话是待机还是挂断状态。 关键在于PressKeyPadButton()如何判断按键的时间间隔，对太快太慢进行处理 以及SPEAKERSOUNDS GetSoundFromSpeaker()类中电话的各种状态的转化 3、感想：虽然是一个小项目，但是真正要用工程化方法在短时间内做出来还是有一定难度的
同时，这次并没有先写概要设计以及画出相关的UML图，我觉得也是项目出现问题的一个重要方面 其实UML图可以很好的指导项目的编写，特别是在需求发生了变化，可以清楚的清晰的做改动 Anyway 失败的开始不等于失败的结束，也许这次的项目出现的问题会促使我们更好的进步。
大家一起加油吧~ -------------陈旭明--------------------- 微软精品课程初体会！一直想写点东西，可惜一直找不出时间一拖再拖。
微软帝国---每个IT人关注的焦点，敬畏，反感，艳羡，各种心态都有，但不可否认它做得很成功。
虽然仰慕已久，但还是第一次有幸感受微软老师带来的课程。
都说微软员工都是技术牛人，确实有一定道理。
听蒋严冰老师介绍微软开发产品流程，角色，职责等各种情况，神往许久，终于目睹微软许景阳老师的风采。
没有精彩的演讲，没有过多的宣传，自我介绍完毕就开始编程，让人始料未及又在情理之中。这正符合微软踏实的作风，多说无益，手底下见功夫。
正像软许景阳老师说的自己做的东西才能记住，也只有自己做的时候才能发现问题。
June 10 SummerGroup~成立`~~~！！经过联系和讨论，我们终于确定了~成员名单和角色 晒晒先~~~
|
|
|
