今天任务是了解H模型，H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期与其他流程并发的进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行，并且可以根据被测物的不同而分层次进行。
H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备,尽早执行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展
今天进步点点，明天前进一大步。知识需要积累。我们切不可心浮气粗。通过这几天对测试用例设计方法的学习。我进行了测试用例管理的深思。
1、从功能的角度，功能是每个项目测试的重点，通常在测试人员得到需求文档的时候，我们就开始设计测试用例，那么这个时候需求文档上列出都是功能以及部分一些业务逻辑等，所以在测试用例的第一阶段就是完成功能的用例设计。不过这里，肯定会让很多人疑惑，其实功能、业务还有UI，都是有关联的，而且很多时候无法分解的。这里后面我会举个例子说明哈，但绝非都是可以分类，只是谈谈如何分解的方法，最重要的就是不要遗漏就行。
2、从UI的角度，UI通常是指界面测试，这个应该不难理解，但要想与功能点进行分解，也不是那么容易区分的，所以我们来直观的说明哈。界面测试，注重样式，外观、整洁、摆放以及易用性，还包括用户体验等。
3、从业务的角度，这个相对来说，还比较好理解，业务通常是指一连串的动作所连接起来的流程，这个流程必须有行为和目标，或者说方向。业务通常是一个项目或者产品设计的核心，当下，越来越多的应用业务流程都是非常复杂，所以对于业务的用例设计，就是考验一个测试人员的业务水平如何。
今天我终于要来时实践测试我们公司的网站了。带我的刘姐今早把握喊到他的跟前，我了我一些关于测试的的基本知识。值得高兴的是：我都能应答如流。第一次和真正的测试人员有了比较深入的了解。从刘姐对测试的理解中，我也感受到做测试人员并非易事。作为一个测试人员必须具备有耐性、有较强的沟通能力、一定的合作意识等基本素质。对于这些基本素质要求，下班之后我进行了自我反省。我觉得自己好事一个比较有亲和力、有耐心的人。可能稍微欠佳的就是沟通能力不是很强。觉得自己以后应该在沟通方面取得更大的进步。为了做好一个合格的软件测试人员，我必须努力做到这些。
今天主要研究W模型
V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W模型（如下图）。在模型中不难看出，开发是“V”，测试是与此并行的“V”。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEE1012-1998《软件验证与确认（V&V）》的原则。
W模型由Evolutif公司提出，相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。
W模型也有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。
这周的工作任务主要是完成旅行网的第一轮测试，由于数据库的设计不合理还有待遇写的不够规范导致我们系统打印不出来，后来把代码的合理性，还有新版本的功能都做完了的上线了。
1、完成了后台bug的修改。
2、完了管理学生的条件的查询。
3、完成了申请打印的条件查询。
4、票务管理新增加了一个功能代理商可以修改代理商信息。
在完成这几个任务需要的时间我们很少了，这是由于全段时间我们对我们这个系统做过很多的修改功能，还有自己对宇整个代码的流程也是越来熟悉，让我更加有成就感，因为我不会为了一个简单的文件而去浪费时间去学习，还有我们可以自己单独去很多功能了，我就会觉得我们现在的待遇不行。想到这里我们就会觉得自己的心里不平行。
今天主要是进行系统测试和评估测试。同时整个开发过程中我们小组也协同项目经理对各个方面进行了质量评审。从各个方面对不同的工件进行了评审，其中大部分通过了，不可避免地其中也有一些问题，但是我们采取了相应的纠正措施，保证了各个工件的质量。
学任何东西都应该认真研究，否则一知半解还不如不学；另外要注重把平时所学和实际相联系。熟练的专业技能是一个公司生存和发展的资本。现在主要的任务还是多学习，多积累。
怀揣着最初的梦想、保持着那份激情和耐心、我继续着我软件学习的路程。今天我开始了测试用例设计方法的学习。
测试用例是软件测试的核心
软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。测试用例的设置
我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。
按功能测试是最简捷的，按用例规约遍历测试每一功能。
对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。
实习的第一周
按照公司安排，分配到基站那边熟悉设备和操作器件任务是认识基站设备RBS2206(室内宏蜂窝)的组成，请点各基站设备资产，登记载波的开启情况，进行备用电池的放电测试，门禁系统的开启关闭操作，空调温度的调整(一般为26度)等
由于我们队员较多，队长安排我们向另外两名早来的实习生学习我们的工作地点是海珠区的中国移动的各个基站点(主要分布在楼宇天台和地下停车场)，时间是每天早上9点钟到下午6点，中午休息一会儿工作任务较为简单，操作起来单调机械，需要乘坐面包车到处去各个点奔波抱着学习和吃苦的态度，还是认真的完成任务起先进入基站都感觉好奇，认真地向队长和队员们请教问题有的问题都觉得太简单，但书本上从未涉及过，还是坦诚地向别人请教
这一周的工作下来，学会了基站的各个部件的位置组成和实物外观，结合所学书本上的知识，加深了各器件的了解和提高了实际动手操作能力学会了与来自不同教育背景和生活地方的同事的交流与合作，深感工作上要不耻下问和同事间要合作紧密才能很好地完成工作任务
实习的第二周
依然是在基站学习工作任务与上一周的大概相同，熟悉基站设备，备用电池的放电测试，不过开始进行故障处理和部分时间进行巡检
工作地点仍然是海珠区的广东移动的基站机房与室外基站，不过检查的基站点与上一周略为不同，都第一次进入检查时间上也一样，虽然我们组要值夜班，考虑到我们实习生的身份，暂时不作安排
这一周的工作与之前的工作内容大致相同，其中故障处理较多，故障处理一般就是更换基站设备，如CDU，TRU(载波)，DXU等，更换设备有一套标准的流程，实践动手不能马虎了事还有部分巡检，需要用OMT软件连接设备，主要用来定位基站设备故障工作上依然单调枯燥，但不能放松，以免出现安全事故或工作不到位，给下一步流程的工作的同事带来重复的麻烦
实习的第三周
基站工作结束，开始做网优相关工作，网优主要包括路测，验收，楼宇普查，扫频等任务，是比基站的工作复杂一点，是处理解决信号问题的主要人员
工作地点是广州移动的业务数据中心，我所在的组是西区，位于体育中心和珠江新城一带，工作时间与之前一样第一天由负责人说明工作流程和注意事项，没有接触到实际的网优工作，都是一些送文件和设备给同事使用的跑腿工作
这一周的工作不多，负责人的一番指导和教悔也让我认识网优这一职位属于干活多薪资少的工作，需要耐心努力地学习理论和操作知识，吃苦耐劳踏实工作才能完成工作
实习的第四周
这一周才是接触到网优的实际工作，路测，路测就是道路测试信号，由于道路上都可能占用多个小区，甚至是越区覆盖，是网优中分析处理问题的一个很好的学习过程
工作地点是广州大道位于中山大道及体育东路之间的一段道路，实际上就是天河路一带，时间是凌晨2点开始，因为刚刚进行过割接小区，所以测试一下割接后小区占用情况数据显示信号强度正常，只存在局部地点出现质差，割接成功
这一周的工作是和一位路测队长学习，在测试过程中繁繁出现问题，手机电池没电，数据线连不通，电脑鼠标不动，没有带上3G卡，最后测试时间缩短减少电池使用时间，回公司更换数据线，暂时没有测试3G与2G切换情况信号测试前的设备检查是否完好，测试软件的熟悉准备都是测试前必须注意的问题
昨天把所有的记错本学生掌握的正确的知识点还有错误的知识点都统计出来，虽然功能已经实现了，但是我们我觉得这个模块是真的没有做完的，因为虽然功能可以正常的显示了，但是我们没有测试所有的学生的显示的结果是根据我们需求来的，今天的主要任务就是做测试，我在打印所有的学生的记错本的时候发现我在每一个学生的记错本中打印所有学生的错误知识点了，这就是一个集合没有在循环内生成的原因。
所以我们以后工作都需要自己测试过所有的功能才去提交。这样是一个好的习惯，只要这样我们在工作提交的时候我不需要每个时候都知道我们的工作是否已经完成了，如果不去测试而且把我们做的东西提交上去我们，我们的客户发现我们的产品都不好，让我们的用户觉得这个东西不成熟，这样我们就会失去很多的用户。
现在对测试工作有了全新的认识，测试能力是要不断提高的；可扩展性：具备可以进行测试工作的基本功能，在功能和性能上还需完善和补充，好在可扩展性好，还有优化的余地。测试工作在很大程度上改变了我的思维方向，几个月前的我对任何事物都几乎是在没有任何依据的情况下，盲目的乐观自信，而现在面对事物时我习惯性的以怀疑的角度切入，正因为怀疑，就会对事物追根刨底，对自己和自己所要处理的事物具备更强烈的责任心。所以作为一个测试人来说怀疑是出发点，体现在测试人身上的品质就是责任心。旁观测试组中一个个兢兢业业工作着的同事们，想到原来生病的不只我，他们病得更重，我不禁哑然失笑，一下子觉得自己病得理直气壮了，也坚定了自己将测试工作进行到底的决心。
如何设计测试用例，如何评审测试用例，最后如何管理测试用例，这都是我们测试工作中必须要去改进的问题。在之前的公司，由于团队工作任务繁忙，我们没有太多的时间去管理和优化测试用例，也因此对用例方面少了太多的思考，而且虽然有对于用例的评审，但一直以来，我认为是做得不够好的，毕竟每次评审下来，感觉效果没有预期的那么好，主要还是没有足够的时间去管理，所以无法引起重视。不过，现在我想我需要花大量的时间来管理用例了，而且要保证有序的进行，最后输出让团队中各个成员都认为满意而且高效的测试用例。对于用例管理的根本问题，我个人认为是分类上，如何有效的维护和优化用例，就是需要前期明确的分类规划，根据分类的优先级一步一步地来完成就可以了，到最后，我们也可以有效把控的测试覆盖度。
当前，我们大致可以把测试用例分称三个方面，分别是功能、UI和业务流程，从这三个角度来进行设计。
1、从功能的角度，功能是每个项目测试的重点，通常在测试人员得到需求文档的时候，我们就开始设计测试用例，那么这个时候需求文档上列出都是功能以及部分一些业务逻辑等，所以在测试用例的第一阶段就是完成功能的用例设计。不过这里，肯定会让很多人疑惑，其实功能、业务还有UI，都是有关联的，而且很多时候无法分解的。这里后面我会举个例子说明哈，但绝非都是可以分类，只是谈谈如何分解的方法，最重要的就是不要遗漏就行。
2、从UI的角度，UI通常是指界面测试，这个应该不难理解，但要想与功能点进行分解，也不是那么容易区分的，所以我们来直观的说明哈。界面测试，注重样式，外观、整洁、摆放以及易用性，还包括用户体验等。
3、从业务的角度，这个相对来说，还比较好理解，业务通常是指一连串的动作所连接起来的流程，这个流程必须有行为和目标，或者说方向。业务通常是一个项目或者产品设计的核心，当下，越来越多的应用业务流程都是非常复杂，所以对于业务的用例设计，就是考验一个测试人员的业务水平如何。
下面通过一个证券交易平台上的买入和撤单业务，进行具体说明：
业务说明：买入业务包括股票代码、当前价格、买入价格，买入股票数量、确定买入按钮和取消按钮;
撤单业务包括选择撤单的未成交业务、撤单成功、撤单失败以及取消撤单按钮;
以上只是大致列举了一部分。
功能点：买入按钮、取消按钮、选择撤单、撤单按钮和取消撤单按钮等
UI界面测试：股票代码、当前价格、买入价格、买入股票数量，所有的文本框;买入成功/失败的提示框;撤单成功/失败的提示框;撤单成功/失败的业务状态等
业务测试：买入业务，从输入买入表单的数据，到提交表单，到最后买入的表单显示的位置，以及买入提交但未成交，可以撤单，完成撤单的业务，到撤单成功或者失败等，这一连串的工作组合就是一个业务流程。
其实这里就存在一个争议性的问题，对于买入和撤单，既可以作为功能点，也可以作为一个业务逻辑来设计，但从本质上来讲，功能点注重单独的操作，而业务流重的在是一个流程，还需要具体业务去甄别。功能点的设计更主要对这个买入和撤单的按钮本身进行用例设计;而业务则是需要从买入和撤单之前的输入到最后输出这样一个过程来设计。
以上也只是大概的一个简单的说明，具体的操作还得根据自己的实际流程来执行，毕竟测试用例的管理是一个长期的积累和沉淀的过程，好的方法都是总结出来的。对于测试来说，用例是基础，对于回归测试、自动化、性能等等都是根本，管理好测试用例，也就是提高测试的工作质量。
这周过得可真够累。由于公司购物网要在规定实践发布，昨天我们主管就通知我们周六加班。我们办公室的哥哥姐姐很不情愿的申请了加班申请。本想可以好好休息一下了，可明天还得下班啊，想想多么悲催啊！
周六很不情愿地从床上爬起来，一大早跑到公司，加班的公司确实比上班时间安静多了。比较喜欢安静的我看都这种情况，工作激情又一次被调动起来了。周六一整天我热情满满的测试各个模块的.添加业务功能。在做测试时，虽然有些头晕，但还是静下心来完整了本天的测试工作。觉得特有成就感。从这件事情，我认识到，公司加班有时候是没办法的事情。我们做员工的有时候要理解，但当加班过分时，我们做员工的也要勇敢的说NO。员工既要承担自己的任务又要适当地维护自己的权力。这是我这周的心得。
这周的工作主要是对我们整个系统进行检查bug，由于我们的项目做完过程中是没有需求文档，很多的需求根本就不知道要做成什么样子，导致我们在做集成测试中会遇到各种各样的问题。当我遇到问题的时候我们只能以我们现在需求来判断我们原来做过的系统的功能是否完成的标准。
今天在迁移数据的时候，搞的人很烦，由于我们原来历史数据数据太多的冗余。导致我们现在的新系统的数据一直都说不是很完善。还有就是下午遇到我们我们推荐的题目没有找到在数据库里面导致我们打印记错本的报错。这一些都是数据的不完善的造成的结果。
进过今天的遇到的问题我想了很多，因为今天的发生的问题我们完成可以通过数据的判断可以解决这些，所以以后写代码的时候多考虑如果没有数据我们写的代码会不会报错呢？还有就是我们写的东西不错在界面中报错。
到现在为止我都工作了2个多月了，时间过的飞快，然而自己的想法也是越来越多。因为马上就面临到毕业的时候。一个打算就是自己赶快把自己学校的事情都搞定，还有一个想法就是自己毕业后尽量跑到沿海地方去，自己不要只要会搞技术还要学会怎么去处理业务逻辑。这样的自己才能成长的更快。
今天一如既往的在研究软件测试的计划的编写，通过今天的学习我主要明白了编写软件测试的重要性和目的：
测试计划是软件测试中最重要的步骤之一，它在软件开发的前期对软件测试做出清晰，完整的计划，不光对整个测试起到关键性的作用，而且对开发人员的开发工作，整个项目的规划，项目经理的审查都有辅助性作用。
2、测试计划的目的
测试计划描述所要完成的测试，包括测试背景、测试目的、风险分析、所需资源、任务安排和进度等：
（1）将需求和总体设计分解成可测试，应该测试，推迟测试和无法测试的范围
（2）对每个范围制订测试的策略和方法
（3）制订release和停止测试的标准
（4）准备测试所需要的环境
（5）确定测试风险
（6）确定软件测试目标
（7）确定测试所需要的资源其它相关信息
（8）制订测试进度和任务安排
做测试已不知不觉有两个月了。现在我仅自我总结以下如何做好测试计划工作。
1.明确测试的目标，增强测试计划的实用性
编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确
2．坚持“5W”规则，明确内容与过程
“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。
3．采用评审和更新机制，保证测试计划满足实际需求
测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员。
4.分别创建测试计划与测试详细规格、测试用例
应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。