最新一期班级的web实战项目已经结束，除了必要提交的一些测试相关文档外，还特意给每位学生布置了一个作业：
写一篇关于项目实战的心得，内容主要是总结项目经验不足以及项目收获。就好像真实工作中，项目完结后的项目总结一样。借此希望培养大家的自我认识和总结能力。
当然不排除有个别些同学会提交一些“流水账”给老师，不过总体而言，发现很多童鞋还是很有感触的。
现给大家做下部分作业分享，这些来自于新手测试人员的经验，希望可以帮助正在读这篇文章且处在测试入门的你，能少走弯路。
@柠檬班45期来自广州学员-猫咪：
通过参与项目实战，更加清晰测试工作一个完整流程：测试计划-测试用例-用例评审-执行测试-提交BUG-回归BUG-BUG关闭-BUG分析与总结-写测试报告的每一个阶段。
在编写测试用例的过程过重新复习了一次等价类，边界值，流程图，场景法，错误分析法等各种方法，懂得考虑功能交互以及隐含需求的挖掘。进一步巩固了测试知识。
了解一个新的BUG管理工具-禅道，初步掌握了禅道的基本应用功能，以前公司使用的BUG管理工具是TD。熟悉web端的测试方式。
懂得了需求分析的重要性，操作web端功能不熟悉，执行用例比较慢，执行效率不高，从而更加认识到需求分析和熟悉业务操作的重要性，一定要理解需求，熟悉业务流程。
对于写测试报告，再次熟悉了写测试报告的规范内容。以及如何使用BUG管理工具导出图表。
@柠檬班45期来自杭州的学员--VV：
对于没有测试经验的我来说，这次的测试项目真正的让我有了测试整个流程的体验，前面几节课的理论也有了真正的应用。这个模拟真实场景的体验让我也体会到了很多思维方式上的不足。
首先是需求分析部分。这次的项目是第一次有了需求规格说明书，需要我们对需求进行学习以及分析.
老师对于项目需求的讲解也让我了解到了需求分析时对业务流程熟悉的重要性。在自己画完业务流程图后确实对于整个项目操作的流程更加的清晰明确。
在测试用例的编写部分是学习到最多的。
1、在测试用例的编写上首先一个用例尽量覆盖所有有效类、一个用例只覆盖一个无效类。
2、在测试步骤的编写上可以融入很多正常功能测试的测试点，这样就能避免测试用例的繁琐冗余。
3、对于一些错误格式长度的测试用例编写，可以写在同一个测试用例中，并在测试输入中明确写出错误的类型以及长度和组合，便于后续的测试及测试用例的补充，整体也不会显得太过繁琐复杂。
4、子项目的测试用例编写应该每个输入框都分开分析，如手机号输入框和密码输入框，如果手机号密码一起写容易漏掉一些测试点。
5、在测试点的分析上需要更严谨的正反面思维方式以及更多发散的思维，根据长度、组合、必填、重复这四个点对功能进行正反面的测试点分析.
一一写出各方面对应的数据要求，不能只在脑海里无序的想，在测试中还要有一定的发散思维，对用例进行完善，如对于超时验证码的验证这个就是我原来没有想到的一个测试点。
@柠檬班45期来自上海的学员--杯子：
一个实战项目全程跟下来，对小白的我来说，从听的时候懵懵懂懂，到自己编写测试用例、再修改、再执行、再找bug并跟踪，最后编写测试报告，可以说还是学到很多的。
在需求分析评审阶段，老师一开始先是发了前后台的需求规格说明书以及业务流程图等让我们自己进行预习，理解，之后再课上逐一的讲解了金融公司的项目的联系以及相对应的系统操作，同时把成员架构也解释了一下。
之后按照大致需要测试的模块以及人员的情况进行分组，以便更好地测试。
到了设计阶段，我个人觉得这是整个测试的关键，一个好的测试用例的编写可以省去后期很多的麻烦，这就需要提前和项目经理、产品经理再三确认产品的需求.
我主要要通过等价类、边界值等用例设计方法按照说明书中的需求去一一寻找出测试点，因为以前从没有经历过编写测试点，这就更需要我耐心，沉得住气去慢慢摸索，归纳出一条方法。
给出的说明书中先要仔细通读，然后研究每个模块中他所要进行测试的点。
首先要进行的是冒烟测试，对大体流程能否顺利完成进行的测试，如果主流程都无法完成更不要说后期的测试；
之后每一个可以输入字段的文本框肯定也都是一个测试点，关于手机号，验证码，密码这类都需要运用到等价类、边界值这些分析方法；
其次每一次鼠标点击也都是一个测试点，我要看能否顺利的跳转，能否给出正确的反应。
除了这些测试点我还要自己去深度挖掘这份说明书中隐含的一些需求以及行业标准，比如不同银行卡的构成是什么样的，长度的边界值是多少，诸如此类，只有更好的了解了这些知识才能帮助我把测试点更全面的罗列出来。
整理完测试点之后测试用例的编写就会较容易了，我这时候根据所罗列的测试点来编写测试数据，然后写出测试步骤，预期。这样初步的测试用例就可以完成了，后期如果还有根据场景法以及错误推测法整理出的测试点也直接往里添加就可以了。
设计阶段结束就应该是执行阶段了，根据整理的测试用例来一一进行测试，有问题的就在禅道提交bug。在找bug的阶段要注意的是bug最好都有截图配，如果是偶现bug那最好多执行几次。其次不要提交重复bug，这样对开发、对自己都是很浪费时间的。
等自己测试完毕bug也都提交完毕，等待开发修改bug并且重新部署测试环境，我们进行回归测试进行追踪，解决了就关闭bug，没有就继续跟踪直到最后达到上线标准。
最后就是评估阶段，我们测试都结束了之后需要编写一份测试报告，汇报测试情况.
具体的执行情况包括实际案例总数、案例成功率、执行个数、成功个数等等，除此还有bug的提交情况，已解决的、未解决的、延期解决的这些情况都需要在报告中体现出来。
@柠檬班45期来自福建的学员--礼：
本次测试经历了一个项目完整的软件测试工作流程，使我们真实体会到了测试工作的具体流程是怎么样的。经过此次测试后，我从中学到了以下几点：
第一，需求的分析与评审。
对项目需求的分析深度直接关系到后面测试的内容是否完整，所以这第一步也是非常重要的一步。经过此次需求分析我从中发现了自己对于功能交互方面的需求分析还不够充分，还需要更加深入的分析才可以。
第二，测试用例的设计与评审。
测试用例的设计直接关系到我们测试结果的质量，首先，测试用例的覆盖率应当达到100%；其次，测试用例的优劣也很重要；最后，测试用例在设计时应当结合多种用例设计方法对系统进行更加深入的测试。
测试人员在用例设计时应当具有发散性思维，多考虑用户真实操作环境可能出现的情况，从而进行用例的设计可以使测试内容更加完善。
第三，测试工作的开展。在进行系统的正式测试前应先进行冒烟测试对系统主要流程正常验证，冒烟测试是正式测试前最基本的且必须进行的测试，是后面的测试的基础。
测试工作正式开始的时候，除了按照测试用例对系统进行全部的测试外，测试人员还应当通过发散性的思维对系统真实操作环境可能出现的情况进行更加深入的测试。
======================
因为篇幅有限，所以我们这次只分享了三位同学的作业，以后有好的作业会再拿出来给大家分享，这些都是来自柠檬班内部学员一些心得分享，如果想要交流可以后台留言哦。
PS：
柠檬班明天有公开课哦
2018年开年第一次公开课
由咱们的华华老师主讲
专门给跳槽换工作的你所准备的
《年后跳槽必杀技》
閱讀更多 檸檬班軟件測試 的文章
