1.需求分析在测试前拿到产品需求文档，进行需求分析及需求评审前先对需求文档进行详细的阅读，对有疑问的地方进行标注。具体可从以下进行：a.分析产品功能点b.产品核心竞争力c.Kano模型、马斯洛需求分析、多问几个为什么、上下文分析法2.制订测试用例工欲善其事，必先利其器；对测试而言，测试用例就是器，做好了才能把好关a.使用思维导图列举测试大纲，尽量发散，想到什么就写什么，；先放后收，对知识点进行总结和归纳，标记重点测试模块，删除冗余及重复测试点。b.可使用边界值法、等价类划分法、错误推测法、因果图法等设计案例c.根据测试大纲制定测试用例，需包含模块名、测试优先级、操作步骤、期望结果、测试结果、备注3.评审测试用例a.测试作为主导，联合开发、项目经理、PM进行测试用例评审b.可先讲解测试大纲，让开发、项目经理、PM心中对测试用例有个大概；后再进行详细测试用例讲解4.执行测试a.根据测试用例执行测试b.发现问题保留现场，记录测试方法，通知开发解决问题c.覆盖测试用例之外若有时间可进行探索性测试5.提交Bug并推动Bug解决a.在Bug管理工具上提交Bug，详细记录测试步骤b.根据Bug严重程度划分Bug等级:致命、严重、一般、提示c.推动开发解决问题，记录问题进展，一般聊天沟通，若问题严重则需通过邮件推动解决6.回归测试a.对已修复的Bug进行验证b.对Bug所在模块进行基本功能测试；整体进行冒烟测试，确保不会因为修改Bug而引起其他功能出现问题7.编写并提交测试报告可使用金字塔原理设计测试报告，先总后分，上级统领下级，下级推导出上级，环环相扣a.对Bug进行汇总，筛选出各个等级的Bug存活情况b.制订Bug发现及解决曲线图，一般版本正常应是前期多，后期收敛，存活的是级别较低的Bugc.总结归纳版本情况，评估发布与否
测试流程依次如下：
1、需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。--testingteam
2、测试计划:根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等。---testingleaderortestingmanager
3、用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。---testingleader,seniortester
4、执行测试：根据测试用例的详细步骤，执行测试用例。--everytester(主要是初级测试人员)
5、执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。--everytester(主要是初级测试人员)
6、defecttracking：追踪leader分配给你追踪的bug.直到bugfixed。--everytester
7、测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug.
8、用户体验、软件发布等。
测试的有2种方法
答：黑盒测试和白盒测试
黑盒：这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
黑盒测试又叫做功能测试或数据驱动测试。
白盒：此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。
通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。
软件测试按过程分为三个步骤
答：单元测试：单元测试又称模块测试，是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
集成测试：在运行（可能是不完整）的应用中保证软件单元被结合后能正常操作的测试执行的阶段
系统测试：当应用作为整体运行时的测试执行阶段
软件测试的步骤是什么？
1)测试过程按4个步骤进行，即单元测试（UnitTesting）、集成测试（IntegratedTesting）、确认测试（ValidationTesting）和系统测试（SystemTesting）及发版测试。
2)开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
3)集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
4)确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
应该考虑进行如何测试的测试方法
黑盒测试(Blackboxtesting)——不考虑内部设计和代码，根据需求和功能进行测试。
白盒测试(Whiteboxtesting)——根据应用软件的代码的内部逻辑，按照代码的语句、分支、路径和条件进行测试。
功能测试（functionaltesting）——对一个应用软件的功能模块进行黑盒测试。这种测试应当由测试人员进行。但这并不意味着程序员在推出软件之前不进行代码检查。（这一原则适用于所有的测试阶段。）
系统测试——针对全部需求说明进行黑盒测试，包括系统中所有的部件。
回归测试(regressiontesting)——每当软件经过了整理、修改、或者其环境发生变化，都重复进行测试。很难说需要进行多少次回归测试，特别是是到了开发周期的最后阶段。进行此种测试，特别适于使用自动测试工具。
负荷试验(loadtesting)——在大负荷条件下对应用软件进行测试。例如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。
压力测试(stresstesting)——经常可以与“负荷测试”或“性能测试”相互代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。
性能测试(performancetesting)——经常可以与“压力测试”或“负荷测试”相互代替。理想的“性能测试”(也包括其他任何类型的测试)都应在质量保障和测试计划的文档终予以规定。
可用性测试(usabilitytesting)——是专为“对用户友好”的特性进行测试。这是一种主观的感觉，取决于最终用户或顾客。可以进行用户会见、检查、对用户会议录像、或者使用其他技术。程序员和测试人员通常不参加可用性测试。
安装/卸载测试(install/uninstalltesting)——对安装/卸载进行测试(包括全部、部分、升级操作)。
安全测试(securitytesting)——测试系统在应付非授权的内部/外部访问、故意的损坏时的防护情况。这需要精密复杂的测试技术。
兼容性测试(compatabilitytesting)——测试在特殊的硬件/软件/操作系统/网络环境下的软件表现。
α测试(alphatesting)——在开发一个应用软件即将完成时所进行的测试。此时还允许有较小的设计修改。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
β测试(betatesting)——当开发和测试已基本完成，需要在正式发行之前最后寻找毛病而进行的测试。通常由最终用户或其他人进行这种测试，而不是由程序员和测试人员来进行。
