软件测试 实践项目 手机软件测试最佳实践
- 作者: 你的亲爹临死前居然
- 来源: 51数据库
- 2020-04-15
一个成功软件测试项目有什么经验？
本文以一个工作流测试项目为例， 总结了在测试过程中积累的经验，探讨了目前国内软件开发企业在软件测试过程中遇到的问题以及解决的方法。
测试项目背景和实施情况工作流在某公司软件产品线中占有重要地位。
Workflow项目是5系列中的一个小版本，主要增加了任务代办、任务代理、以及任务交接等功能，同时还修复了一些易用性和功能性的Bug。
下面，我们大概介绍一下这个项目的实施情况： ● 项目规模与测试人员配置： ○ 项目代码行数：5万行 ○ 开发人员配置：开发人员5名、实习生1名 ○ 测试人员配置：测试设计人员1名、测试执行人员2名、实习生1名 ● 项目测试时的系统部署情况： ● 测试预期与测试执行情况整个测试项目是比较成功的，项目的时间执行情况和预期的测试指标度量都比较接近。
发现Bug总数和缺陷密度都达到了要求的标准。
当然，测试周期的实际值比计划值晚了两周，原？因是在系统测试后期，为了满足PSO部门提出的定时器需求造成了一定的延期。
回顾整个项目的测试过程，我有几点小小的感悟，愿在此和大家一起分享。
测试如何尽早介入 基于以前的测试经验，我们也越来越认识到测试人员应该尽早介入项目的重要性。
简单地沿用测试V模型往往出现很多问题，特别是在项目进度拖延的情况下更是如此。
如果测试人员一味固执地被要求严格按照V模型定义的标准来开展测试工作的话，则结果往往是在项目初期测试人员工作量极度不饱和（很多测试人员无所事事），而到了项目后期，一旦项目经理决定压缩测试时间，测试人员就不得不加班加点地工作。
但是，不少朋友实践“测试人员尽早介入”的效果并不理想，例如： ● 测试人员参加项目前期的各种会议，会被当作“专职的”会议记录员。
● 测试人员参加代码评审，又不甚了解程序开发语言，浪费了时间其丢失了自信。
那么，在这个XXX5.2 Workflow项目中我们是怎么做的呢？实际上，在项目开发初期，测试人员可以开展很多有价值的工作，例如： ● 评审需求文档的正确性和可测试性；根据需求文档整理和分析测试需求，清晰明确的测试需求是测试设计的基础。
● 在开发设计过程中，根据需求文档和设计文档进行测试设计，测试设计方案是测试用例的保证。
● 和项目团队中的集成组和开发组协？商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。
● 开发人员每天下午4:30之前提交所有可编译的代码，每天晚上进行日编译； ● 开发经理根据版本稳定情况，每周提交测试申请单。
● 测试人员根据测试进度需要，提取测试版本。
● 提前准备测试环境，包括数据库环境，操作系统和web应用服务器，以及复杂集群环境。
● 如果项目需要，还可以在此阶段研究一下自动测试工具，包括一些准备外包测试的工作。
根据产品的成熟度调整测试策略开发测试一盘棋。
测试经理应该有大局观，保持测试策略总与开发的进展相一致，保证最终的软件成果最佳（而不是测试部发现Bug数最多）。
在这个XXX5.2 Workflow项目过程中，我们合理制定了不同阶段的测试策略，收到了很好的效果。
来源于考试大 产品开发期同情的测试 要忍！要在这个能够发现大批Bug的黄金时段学会做减法。
就现实而言，这个阶段的产品，大多难以满足系统测试的条件。
如果进行穷兵黩武式的测试，无疑会加重开发人员的焦虑心情，甚至对测试产生逆反心理。
另一方面，测试工作不应停滞，特别是不少测试人员对产品的了解还流于皮毛，抓紧时间进行“测试练兵”非常有必要。
因此，“产品开发期”的测试切忌生硬。
其实，此时程序人员也知道产品还不成熟，所以要告诉测试执行人员： ● 这个阶段不要提交界面简单错误和易用性方面的Bug（可以先记录下来到项目末期提交），否则会使开发人员质疑测试人员只会发现简单的Bug。
● 换位思考，了解此时开发人员最关心的是功能是否能正确运行，多对基本功能进行测试。
产品成熟期积极的测试 随着产品的不断成熟，主要功能的实现已经趋于完善，关键路径的测试已经不成问题。
此时的程序员们，压力已经大大减轻，他们的工作重点也从“构建”转移到了“修复Bug”，这个阶段程序人员对于Bug的接受程度是最高的，对Bug的修复和反馈也非常积极。
于是，此时的测试工作应对整个产品的细节和所有路径进行覆盖测试，保证测试的全面性，层层深入地测试产品值得测试的各个部分，尽可能多的发现并报告Bug。
软件测试项目的启动、规划有哪些呢？
一般地，项目启动过程组包括两个过程[参见PMBOK2004版]：即制定项目章程和制定项目初步范围说明书；而项目规划过程组则会综合项目的成本、范围、时间、质量、风险、人力、沟通、采购等因素制定项目计划，该项目计划将用于指导项目的实际执行。
对任一项目而言，有三个文件是非常重要的。
即：项目章程、项目范围说明书，项目管理计划。
这三个文件均产生于项目启动阶段和项目规划阶段。
其中项目章程被认为是三大文件之首（项目章程、项目范围说明书，项目管理计划）。
一个项目，不论大小，都应该有项目章程。
一个典型的项目章程包括如下内容：1）项目名称及背景描述；2）项目经理任命及职责范围界定；3）项目业务需求描述；4）项目发起的原因；5）主要项目干系人及其初步需求；6）产品及预期交付成果描述；7）项目假设和约束条件。
项目章程由项目发起人（Sponso）签发，自签发之日起，项目经理即获得法定权力。
项目经理在获得法定权力之后的第一动作是制定项目初步范围说明书。
为了制定这份文档，他她将广泛地收集来自项目发起人的需求，以便在项目计划正式编制之前，与项目发起人在项目范围的理解上达成一致。
项目初步范围说明书还将在后续项目范围规划过程中进一步细化，并融入项目客户、执行组织、项目干系人等各方面需求，进而形成完整的项目范围说明书。
项目初步范围说明书编制完成以后，项目经理将进入项目计划编制阶段。
这个阶段将会涉及项目管理方方面面的规划、计划。
比较典型的有项目范围基线、项目成本基线、项目进度计划、项目质量计划、项目风险分析及应对计划、人力资源计划、项目沟通计划以及项目采购计划。
这些计划、规划经过权衡、调整，最终将集成为一个完整的项目管理计划。
项目管理计划经由项目发起人、高级管理层审批以后，即可生效。
此后，项目经理将召开项目开工会议（Kickoff meeting），宣布项目正式开始进入执行阶段。
我想应聘软件测试职位,简历中的实践经验怎么写？
首先，说一下你的项目，你在里面有着一个怎样的位置，最好，详细的说出你最熟悉的某个模块，重点是在测试用例上，一般面试官都会问到你是怎样进入测试的，如何评判你是一个好的测试员，你可这样说， 主要工作：1确定测试范围，制定测试策略，写测试计划； 2熟悉业务流程； 3设计测试用例； 4 执行用例：进行功能测试，接口测试，容错测试，界面测试，安全测试，初始化测试，文档测试，可用性测试，性能测试，负载测试，稳定性测试，恢复测试，配置测试，安装测试； 项目心得：通过项目实战，掌握了从测试需求分析到编写测试计划的方法和技巧，并掌握了测试用例的设计最后，要说一下，你对测试的理解，如果没有，你就要说，你看过哪些软件测试类的书籍，平时自己都做了哪些实际性的测试，你在学校的实践活动啊，这些都会给你加分的...
请问：给你个项目你要怎么进行软件测试？
测试流程你先要熟悉需求，公司应该会有一个需求文档，时间够的话，需求文档也要测，这时候要用到静态测试，检查需求说明书写的是否符合清晰无歧义等要求，然后你就要了解系统，通过对系统的了解在加上需求说明书你就可以写下测试计划了，测试计划一般来说好一点的公司的测试组都有一个模板，写就好，测试计划写好了，就要写测试用例了，可以根据性能测试，功能测试，兼容性测试等这些方面来写，还有要把测试方法使用到例如等价类，边界值等那些方法，接着测试用例写好了，下面就要执行测试用例，发现bug，公司应该会有一些bug管理工具，写好后提交，交给开发人员修改，然后开始写缺陷报告，记住要写一些具体的统计性的数据，那样更有说服力，像bug覆盖率等，当然测试用例中最好也要加一些，那样维护起来比较好。
下面呢，就是比较麻烦的回归测试，经过回归测试之后，基本上就不会有什么问题，系统就可以上线了，接下来呢就是维护的工作 了。
因为这个测试的流程不同的公司是不同的，具体问题具体分析，要结合实际去测试，你要注意如何能够科学有效的测试，并且要注意维护，这就要做到测试的文档话，什么时候都有据可依，测试的时候不要追求完美，没有必要的测试是会浪费时间的，不同的系统都有它核心的模块，只要保证用户常用的模块不出问题就没事，基本的系统都是单元到集成 这不仅是白盒，黑盒也一样，通常流程测试是最重要的，时间短的话，只要保证系统能够正常运行就是关键，接口测试是这时候的主要测试目标。
...
什么是软件测试项目管理
项目管理是一个管理学分支的学科，指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望。
项目管理是对一些与成功地达成一系列目标相关的活动（譬如任务）的整体。
这包括策划、进度计划和维护组成项目的活动的进展。
软件测试的具体工作内容包括哪些呢？
软件测试的具体工作内容包括：理解用户的需求和体验，校正设计和项目计划，运用良好的测试方法和实践，撰写有效的测试计划，设计有效的测试用例，推动自动化测试，调查分析bug的根本病因，追求卓越的技术和业务能力，充分的团队合作，以及紧密地联系和关注用户和合作伙伴。
李和恒个人的理解是，软件测试就像沙滩上的寻宝人，你不可能知道沙里埋了些什么、有多少、在哪里。
寻宝人要在尽量短的时间里面挖出尽量值钱的宝物。
但极为讽刺的是，你不可能挖出所有的宝物，而且所有的宝物日后都会浮现出来，比如地震海啸地质运动什么的。
在这里，测试工程师就是寻宝人，宝物就是 bug。
至于用什么办法寻宝，那是技术上的问题了。
技术总是日新月异的，所以我对合格的软件测试工程师的期望是：狂热追求宝物，具有大局观，充分了解沙滩，最后才是了解并改革寻宝工具。
软件测试 项目总结怎么写啊？高手指教下
能表达得有条理就可以了。
不必介意格式。
总结无非就是总结经验，吸取教训咯，本人什么时候参加了什么项目的测试这个项目是干什么的我在项目组中做了什么遇到了什么困难 如何解决的通过这个项目我学习到了什么我要感谢谁谁谁我以后要在什么方面加强此致 敬礼附件一X项目的测试工作到今天算是全部结束了，除了后期维护必要的一些回归测试和用户使用手册的撰写外，整个测试阶段告一段落。
从10月底进入项目，在测试经理的帮助下开始学着写项目测试文档，到根据文档的每日功能测试及回归测试，再到整个项目进行迭代后对测试文档的重新架构及整体回归测试，直至最后的统一交付测试，我个人提交总BUG数为244个。
在这244个BUG的提交和回归过程中，在测试文档的写作及修订中，我对整个项目的逻辑及架构逐步清晰，对项目之间所需的复杂交互的认识也越发深入，对项目功能逻辑上的测试如何进行也更加明晰。
下面我简单谈谈对项目的认识、经验和教训，以及对未来改进的一些建议！一、对项目的认识进入这个项目是在今年十月底，当时测试经理和C已经把Setting（当时是Admin）部分的测试结束了，所以我直接开始接着D的测试文档继续往下写（当时是从Revenue的Report部分开始，即现在的Report模块）。
因为跳过了逻辑部分，所以对整个项目逻辑理解很不够，开始写的测试文档也非常浅显，就是描述了一下页面布局。
这里我的感觉是，测试人员进入项目初期，项目经理有必要指派专门人员与测试人员沟通，帮助其理清整个项目的顺序逻辑。
当时C简单地跟我介绍了一下整个项目，我的感觉是沟通不够，对逻辑理解比较欠缺。
Report部分写完，就直接开始测试——用自己刚写完的文档进行测试，效果显然不够理想。
因为测试人员刚进行该模块测试文档的编撰，再让他对该模块进行测试，这样做的一个后果就是，测试人员会先入为主地觉得自己不需要按部就班地照着文档进行测试（因为文档就是自己写的）。
还有一个很大的问题就是，倘若测试人员在文档撰写上存在严重漏洞的话，他在测试时仍然不可能发现自己的漏洞所在。
所以我建议测试文档撰写人员与测试人员最好不要是同一个人，这样有助于发现测试文档构建的漏洞。
测试完Report后，紧接着开始进行Expense模块测试文档的撰写。
这时我开始接触到一些逻辑，即Expense与Setting部分联系的逻辑。
这时遇到的问题最多最杂，随时随地都需要与C，甚至项目经理进行沟通。
由于之前对主功能（Setting部分）的不熟悉，这种一边沟通一边撰写的测试文档可以说是漏洞百出。
由于项目时间也比较紧，我需要在一周内完成整个Expense模块的测试文档，所以最终完成的文档很不理想。
这里我觉得还是之前沟通不到位的问题，应该有一个对整个项目非常熟悉的人来帮助测试人员理清整个项目逻辑再进行测试文档撰写，而不是一开始就撰写测试文档。
接着就是根据自己撰写的Expense文档对Expense模块进行测试，效果也不够理想。
这里我还有一个建议就是，如果测试人员在初始进入项目时没有得到及时沟通，至少需要给他一周时间先对主功能（即Setting部分）进行完整测试，对照需求手册及主功能发现的BUG，对主功能进行深入理解。
Expense测试完成后，开始对整个项目进行回归测试。
在这个过程中，我逐渐理清了整个项目的逻辑，也开始试图修改以前的文档。
但由于文档量太大，文档结构不够清晰，时间也比较紧，修改难于进行。
大部分原因是我经验不足造成的，之前撰写测试文档时，思路过于混乱，想到哪里写到哪里，导致最后文档难于维护和修改。
回归测试结束后，整个系统逻辑已经比较清晰。
这时项目进行新一轮的迭代，用户需求改了很多，其中包括增加、修改大量功能、名称，以及对整个系统结构进行重构。
这对测试文档而言改动点非常多（包括结构顺序改变、测试编号订正、功能模块名称修改等），而且需求文档并未因此变化，造成最后测试文档与需求文档的不匹配。
这是一个协调的过程，系统迭代后，需求文档应及时随着系统进行修改。
迭代开发过程中，测试基本上是项目改到哪就测到哪，这里面最大的问题不是发现修改模块的BUG，而是发现修改该模块后牵涉到的其它模块出现的BUG。
这种连带BUG的产生可以说是防不胜防，让测试人员苦恼不已。
到现在我也没想出解决办法，只能说对模块之间的联系及交互逻辑理解仍需加深。
迭代开发后期，开始对整个系统从头回归一遍，这时候又发现了许多以前从未出现的BUG。
这个时期大家都很烦躁困惑，曾经运转良好的页面，突然出现存储问题；曾经更新正常的功能，突然无法更新；曾经显示正常的Excel，突然显示错误… …这些都让人苦恼，当然，这些应该都是正常现象。
测试人员在测试后期尤其需要提高警惕，不能漏过任何一个功能点，更不能忽略任何一次貌似无用的查询、翻页、按键。
最后，是大家一起进行的交付测试，人员包括了所有的编程人员及测试人员。
这期间，除了对基本功能的回归测试外，还包括了并发测试及性能测试（这主要是编程人员在做），除此之外，我将过去提交修正过的所有BUG重新验证了...
目前市面上有哪些软件测试（众测）平台
你问的应该是软件测试吧，软件测试主要是为了让产品上线之前，做个杀BUG的环节，也就是产品上线前的最后的质量保证。
我首推【搜狗众测】，基本测试的东西都是搜狗自己的软件，这个在很大程度上，保证了项目样本的质量（不会像某些测试混入些有害的软件），虽然奖励不是太突出，但是我是抱着学习项目经验去的，所以我去的还不错，有空的时间做一做也未尝不可。
软件测试笔试题：请描述项目业务流程,你负责的测试工作,遇到哪些...
做需求分析（小组内做需求分析，有不懂的问产品经理），测试经理制定测试计划（测试分组，测试模块分工，测试时间以及进度安排），各成员分工写用例，小组内审核用例，等开发研发完毕，然后测试组介入测试，根据测试用例和功能分工任务来测试，测试的时候注意浏览器的兼容性，执行过程发现缺陷，提交bug，开发人员修改bug，验证bug，并对bug进行一定的操作，比如说关闭或者激活，到这里测试完成，且不存在不严重的bug，写好测试报告，提交测试报告并通过运维发布，上线后，关注web是否正常运行。
我负责的工作是：参与需求分析，用例编写，用例评审，提交bug和跟踪。
遇到的问题：遇到的问题，可能有时候需求理解不太正确，需要跟产品或者是老大进行沟通确认，其他的没有了。
...
项目开发中软件测试类型的分类有哪些呢？
单元测试（Unit test）：是针对模块组件或方法的测试。
在本人的操作中，一般是开发员工作范围内的测试；在具备组件接口规范的情况下，一般需要做一个测试工具模拟调用环境，编写测试实例，通过断点情况监视模块实际工作是否正常。
一股采用这种方式开发的单一功能模块质量都是非常高的。
但是如果没有统一的模块规范，那么开发与测试的工作量接近一比一；但如果模块是按统一的标准开发的，那么同一套测试套件就可以用到各个模件上，从而节省了测试时间。
本人认为这属于开发部门工作范围内的测试，与QAQC部门没有什么大的关系，事实上，在这一层次的用例也不是QC可以做到和理解的。
白箱测试：在理解内部流程的情况下针对逻辑流程设计测试实例，目的是找出极限边缘以及内在的逻辑错误。
单元测试中白箱测试的比例很高，（原因不难理解，还有谁比作者自己更理解模块的构造流程的）。
黑箱测试：这是QC部门的主要工作。
黑箱测试主要在于编写测试实例。
不过在实际操作中，都是把最不懂技术的成员分配做测试，最高技术水平就是会用VSS，所以也就别指望编什么测试实例。
所谓的黑箱测试，常常是对着菜单按钮，这个按下去，噢，有东西出来了，对的，打个勾——其实，这时侯的实例就是一个个按下去然后看看有没有输出，而且只限于界面方面，内在的部分和边缘情况大概是不用指望的。
但据作者所知，在CMM达到四以上的国外软件公司中，黑箱测试是对软件评价的最主要方式，通过合适的测试实例，除了最常见的可用性测试外，还包括压力测试，和怪用测试（Monkey test）。
压力测试：评价一个系统极限可以承受的压力是多少，同时在超负荷后的的响应情况；同时，在极限状况下，一些平时不太出现的ug也会浮现出来。
所以，这个测试作者认为不应该单独由QC部门进行，而应该由开发部门与QC部门联合进行。
理想的系统在极限测试状况下就算响应不及，也不至于当机，并在负荷恢复正常后一段时间内可以恢复正常运转。
这时当初对Windows恶评的原因之一：像网站一旦超出100-200个concuent,Windows不但罢工还死掉了；不得不重启系统（当然，Windows任意硬重启都能死鱼翻生，大多数情况下吧，也属一种难能可贵的优点）；而linux在超出负荷后一般情况下下降曲线不至于太明显——不过这也不是绝对的，作者就发现一旦Linux在极限状态下进入内存抖动时，死相和Windows差不了多少；所以内存不至于耗干是Linux可靠性能超过Windows的重要因素。
回归测试：在修改其中一个模块后看其他模块有什么问题。
作者认为这个测试是过程化程序的观念产物，在模块化软件中相互耦合程度低，而且服从统一的调动协议，是不是修改真是自家里的事情，和他人（模块）没有半点相干。
整体测试：把不同的模块连结后，看看联合工作情况如何。
这实际上是对接口协议的测试。
作者认为是可以作为接口互动部分的设计一部分工作，没有必要摆出来作为流程之一。
同理还有系统测试，反正最后整个系统运行起来是什么情况。
看似大，但如果前面已经做到好好的，这里如果出问题那才叫怪呢！ Alpha测试：放任内部成员胡作非为的测试； Beta测试：让全世界的坏人都胡作非为的测试。
