一个测试菜鸟的Y项目总结

一个测试菜鸟的Y项目总结

（引用请注明出处）

作者：许奔

博客地址：http://www.cnblogs.com/xuben

邮箱：3231435@163.com

QQ：420524900

 

之前写过《一个测试菜鸟的X项目总结》，写完后直接跟进现在的Y项目。

说实话，与X项目相比，Y项目是一个极小的项目，逻辑极其简单，却让我得到更多反思的时间。这期间，总结了《从达芬奇画蛋到测试的责任心》和《发散思维：四个按钮下的复杂逻辑》，以及，现在的项目总结。

希望大家看后能有所收获，更希望能集思广益，大家一起发现更多的方法，提出更多的建议。这里，谢谢《基于实际测试的功能测试点总结》的作者，虽然我不知道你是谁，但你这份文档对我帮助非常大。在这份文档的基础上，我也加了很多自己的总结，以后一并贴出来。现在开源是主流，希望测试思想也像开源社区一样，将所有思维聚集起来，碰撞出更多的火花。

一、对项目的认识

（一）项目主要逻辑

这个项目按我的理解，主要逻辑就是三个方面：权限、时间和域。

1、从权限上说，Creator（文档创建者），GC（文档协调员），Sub-GC（副协调员），Admin（系统管理员）和DM（文档管理员）都有不同的权限。谁能编辑文档，谁能发表评论，谁能对文档或评论进行解锁，谁能删除文档，谁能委派权限等等都需要理清楚；

2、从时间上说，文档内部截止日期、文档外部截止日期、文档协调员预警日期、文档管理员预警日期都需要设计相应测试用例进行单独及并发测试。对于本系统而言，时间是一个非常关键的因素，它控制了自动发送邮件的几个条件。但在构造逻辑上却有很大的不足——比如“文档发表日期 < 内部截止日期 < 外部截止日期”这个条件没有设置（用户未提出需求，却会造出逻辑上的混乱）；

3、从域上说，每一个域有相应的文档及评论，每一个域由不同的人员组成。域的内部文档，及域之间的文档都需要进行相应设计——比如说一个域的人员进入别的域创建文档或评论，在选择文档资源（Document Source）时会发生冲突（因为文档资源通过域进行过滤），这样，当其它域的管理者进入该文档进行编辑时，文档资源会产生缺失的情况；

 

（二）项目主要功能

项目主要功能有：创建/删除文档、创建/删除评论、编辑文档、向导页面、上传/下载文件、搜索和发送邮件。

1、创建/删除文档：主要检查创建/删除文档的条件，满足条件是否能顺利创建/删除相应文档，不满足条件或条件缺失时是否仍能创建/删除文档；

2、创建/删除评论：同上；

3、编辑文档：主要检查文档编辑者的权限——符合权限的文档编辑者能否顺利编辑并保存文档，不符合权限的文档编辑者是否也能编辑并保存文档；

4、向导页面：向导页面是对该域内所有文档的一个向导，有哪些文档，文档下有哪些评论、有哪些链接、有哪些上传模板，通过向导页面可以直接编辑该文档或直接针对该文档发表评论,或下载相应模板、点击相关链接等等。向导页面主要检查每一个链接是否正确，能否正常引导至相应页面，搜索功能是否正确等等；

5、上传/下载文件：主要检查基本文件（.txt/.doc/.xls/.ppt）能否正常上传下载，超大文件（大于10M）或特殊文件（如快捷方式等）如何处理；

6、搜索：主要是对搜索框的每个输入条件及搜索组合进行验证。搜索不是逻辑难点，但却是用户最频繁使用的一项功能。保证最基本功能的准确无误，需要非常耐心并仔细地进行连续不断的重复操作才能完成；

7、发送邮件：通过各种自动发送邮件条件及收发邮件人进行测试，并与手动发送邮件进行对比。缺少相应发送人（比如GC）时，邮件能否发送成功等等；

 

（三）细节问题

小项目由于逻辑相对简单，所以更需要关注于细节，纵观所有上报的BUG，很大一部分是图标显示、时间显示、强制输入、字数限制、Excel显示、不一致、提示、排序、单词拼写、语法、界面设计等等，这些错误看似简单，却会让用户觉得开发、测试人员不够专业。对项目整体的印象会大打折扣。

下面，就这些简单错误进行一些说明：

1、                        图标显示问题：页面有的图标直接显示错误（红叉）；有的图标点击之后报错（刷新出错）；有的图标刷新后不出现等等；

2、                        时间显示问题：系统最上方有个显示最后登录时间的地方，时间显示无法更新，或更新出错；

3、                        强制输入问题：这个项目有很多需要强制输入的地方，背景色为绿色。但在测试过程中发现有些背景色为绿色的并不需要用户输入也能保存（比如弹出新项后有两个文本框，背景色都为绿色，表示此项为必填项。但事实上，只需要填写其中一个文本框就可以保存。这就产生一个问题，该把哪一个文本框设为绿色？最好的方法是，填写其中一个文本框后另一文本框绿色底色消失，但这在实现上非常复杂）；而有的背景色并非绿色，但保存时提示需要输入；

4、                        字数限制问题：很多输入框都没有字数限制，导致大量输入保存数据库出错；

5、                        Excel显示问题：页面弹出Excel时同一列数据数据有的跨列显示，而有的则本列显示；同一列数据字母都是左对齐，数据却都是右对齐等等；

6、                        不一致问题：很多下拉菜单旁边都有一个“更多”按钮，点击此按钮弹出页面选项与下拉菜单选项出现不一致（即其中之一显示错误）；

7、                        提示问题：有的页面该项只允许输入正整数，另一个页面同一项却允许输入负数和零（比如SiteLinks的SortCode不能填负数和零，但Category的SortCode就可以），但输入时缺少应有的提示，输入字母或负数保存后该项变为零；

8、                        排序问题：页面每个下拉菜单标题都可以点击排序，有些链接点击排序错误，有些点击后页面错误；

9、                        单词拼写问题：这是最小的问题，却也是最能体现专业化程度的问题。单词拼写错误出现比例直接体现整个团队的责任心和职业度；

10、                    语法问题：同上，需要的不是开发、测试技术，而是责任心和认真的态度；

11、                    界面设计问题：这是最能体现人性化的一点，比如一个页面是否应该按域进行过滤；页面应该显示15条记录还是30条记录；记录显示框应该按照记录的数目动态调整还是保持静态大小；保存新记录后页面该倒序排序还是正序排序；子项输入框应该直接显示还是隐藏；左侧列表项的链接应该展开还是关闭；下拉菜单标题应该单排显示还是双排显示等等；界面设计是整个设计的重头，对于小型项目而言尤其如此。在界面设计时应尽可能地与用户进行沟通，有时候一个小小的改动会让用户觉得方便很多，对项目的满意度也会相应提高；

二、经验和教训

经验：

1、学习使用Bug Tracking系统（以前是用TD上报Bug）；

2、学习设计测试场景（比如根据自动发送邮件条件进行相应场景设计）；

3、学习关注细节（“细节问题”里提及的问题不仅是开发人员犯错误，更是我之前一直忽略的地方）；

4、学习通过设计文档找答案（以前只注意需求文档，很多设计的细节都跑去问项目经理。其实设计文档里很多细节都写得很清楚）；

5、学习更专业地填报BUG（以前填BUG都较为随意，语法单词不太注意，也没有具体的再现问题的步骤，造出很多误解）；

6、学习更深入地进行测试（比如通过SQL注入测试系统访问的安全性和搜索的有效性）；

 

教训：

1、不注意细节（很多细节都视而不见或是觉得无关紧要，对质量的理解仅仅停留在功能或逻辑错误的层次上）；

2、设计测试场景能力还有待提高；

3、随机测试成分较大，对测试总结不够，测试流程相对简单；

4、与项目经理沟通过于频繁，沟通后未能及时形成记录，导致同一个问题重复沟通；

5、测试人员之间的交叉测试程度不够；

 

 

三、对未来改进的一些建议

经过这次完整的项目测试，学到了很多，也发现了很多问题。对于未来项目的测试，我如下几个不太成熟的建议：

1、项目经理在与测试人员沟通后，测试人员需要撰写一份自己对项目的理解及未来的测试要点，便于及早发现测试人员的理解误差，及时纠正理解上的失误，避免测试设计上的失误；

2、除了最基本的测试文档外，测试人员应尽早编写测试流程文档，将测试流程固化下来，并在未来的测试过程中不断对流程进行更新；

3、测试场景设计需要更专业化；

4、测试遇到不确定的地方，需要进行多次测试确定BUG产生的真正原因；

5、BUG回归不是一个BUG的回归，而是对这一类BUG的回归，回归BUG时需要将场景应用到相似页面上进行测试；

6、必须时刻清楚BUG产生的真正原因（多与开发沟通），通过真正原因找出系统漏洞，并在此基础上有针对性地设计场景进行深入测试；

7、发布新版本后，项目经理需要将逻辑变化及改动点罗列出来并简要描述，这样测试人员才能更有针对性地验证BUG及根据修改设计相应测试场景；

转载于:https://www.cnblogs.com/xubensave/archive/2009/03/20/2430393.html