稿件管理系统测试项目经验总结.doc

稿件管理发布系统测试项目经验总结 经过近两周时间，稿件管理发布系统测试工作基本完成了，收获很多，但还有很多不足，希望在之后的学习中以此为借鉴，完善测试过程。 收获： 了解了做一个项目的大概步骤；要想做一个好的项目，测试要贯穿整个开发过程，在做项目之前要做好充分的准备，如环境配置、文档准备、资料收集等。在一个项目中至少要有以下几个文档：需求分析报告、测试设计报告、测试用例设计报告、bug报告及测试报告。对一个测试人员来说，测试设计报告是一个前提，首先要保证测试设计合理，并且内容齐全。这样才能更直接、准确地进入下一项目步骤。测试用例是整个项目的重点，在一个项目中测试用例必须经过三方面的评审，评审通过才能执行。一是自我检查，二是测试人员互相评审，三是项目经理评审。一个好的测试用例要覆盖全测试需求，测试用例的设计要合理、正规。测试用例不在于多，要在于覆盖全，测试用例的多少在一定程度上并不代表质量的高低，所以说，测试人员对于测试用例的设计一定要细心且全面。接下来是bug记录，在bug记录中一定要详细给出测试的重现步骤。一个bug报告中所包含的标题有：缺陷ID、缺陷标题、缺陷描述、缺陷的重现步骤、缺陷的严重级或者优先级、测试模块、缺陷提交人、缺陷的版本及证明是缺陷的视频或者截图等。最后是测试报告，在测试报告中最突出的问题就是测试缺陷的分析，测试用例中缺陷有多少，通过率是多少，有哪些建设性的意见，及最终得测试结果，是通过还是没通过。 了解了如何写测试计划、测试用例、bug报告、测试报告等； 测试计划的内容包括引言、测试背景、测试组织结构、测试策略、测试计划、测试环境及测试总结。在整个测试计划中最重要是测试的详细计划，当然在测试之前，要评估好测试的工作量分配及进度安排，人员规划等，测试计划的书写要有一定得逻辑，要能够真实反应测试项目。测试进度的安排要合理。 测试用例报告是一个项目中的重点，描写一个测试用例包括测试需求ID、测试需求标题、用例ID、用例步骤、期望结果、测试结果、测试人员、所属模块、严重级、备注等。在测试用例报告中重点在于测试步骤要尽可能地详细，测试需求、标题等要描述清楚。 Bug报告也是测试项目中的重点，也是最让人有成就感的报告，bug报告中缺陷要描述清楚、正确评估缺陷的严重级别。 测试报告是一个项目的总结性报告，测试报告主要包括引言、测试设计简介、测试结果分析、测试结论及建议。 （三）了解了如何有条理地书写测试用例；首先测试用例要覆盖需求，根据项目的需求分析或者软件，设计测试用例。其次，写复杂的测试用例要掌握一些方法。例如决策表法，要先把影响因素和测试用例的个数做成表格形式，以便于详细分析设置用例的多少。在设计测试用例的过程中最常用的是等价类划分法，基本上每个测试用例的设计都要考虑正反两个方面。在这划分过程中遵守着尽量覆盖尚未覆盖的有效等价类，仅覆盖一个尚未覆盖的无效等价类原则。 不足： 需求分解不彻底；在本次项目执行过程中，我们发现在需求手册中很多地方描述很模糊或者很简单，不能很好地向设计者呈现要设计软件的细节操作步骤，从而，对于软件测试人员来说就很难辨别测试结果是否符合要求，换句话来说，如果一个测试人员想把需求描写的很模糊的地方测试清楚就必须和客户不停的交流、沟通，在一定程度上影响项目的进度。以上是从客户需求角度来说的。对于客户只提供软件而没有需求的情况下，项目组人员就要人怎分析测试需求，详细分解。 测试用例覆盖不了测试需求；一开始感觉设计的测试用例可以覆盖需求了，但是执行后才发现很多细节部分没有写全，例如稿件管理发布系统用谷歌浏览器打开就会出现很多错误，稿件管理系统在浏览器的应用上存在一定得兼容性问题，等等。针对这种情况，我们需要在执行之前，详细地了解用户需求及真实软件的运用效果。两者相结合，设计更全面的用例。 对bug的辨识度还有待提高；在测试用例执行时，会发现很多细节性的问题，不容易判断它是不是一个bug。例如稿件管理发布系统中高级查询里的版本查询，虽然说它支持的是模糊查询，但是输入很多.时查询的结果仍然是正确的，如果把它归类为非法版本号，非法版本号输入后查询结果应该是查不到，而不是查询到正确的结果。在一开始我将其定义为bug，但是和其他人讨论之后，觉得可以不是bug，第二天又去考虑觉得还是bug。虽然说各人的判断标准不同，但是总该有一个统一的标准。想这类问题还要在以后的项目实行过程中不断总结经验。 测试执行方法及步骤还存在很大的改善空间；在测试用例设计中不只是功能测试，它还包括性能测试、界面测试、安全测试等，对于这些测试，测试用例设计时步骤不是很详细，操作时就存在一定得困难。例如：性能测试中系统支持20人并发访问系统，这就要求我们要尽量组织20人去集体测试，怎么去组织，要做哪些事情，诸如此类准备