1.软件的生命周期：
计划阶段--需求分析--设计阶段--编码阶段--测试阶段--运行与维护
2.你在测试中如果发现了一个bug，但是开发经理认为这不是bug，你该怎么处理？
1、先将bug提至缺陷管理库中进行备案（比如，禅道）
2、然后获取bug的判断依据和标准：根据产品说明、需求说明书、设计文档、原型图等，来确认实际结果与计划的是否不一致
3、如果没有文档依据，根据同行或类似软件的一般特性来说明实际结果和计划的是否有不一致的地方，来确认是否是缺陷；
根据用户的一般使用习惯；
与设计人员、开发人员、客户代表等相关人员相关探讨确认；
合理的论述，向测试经理说明自己判断的理由，等待测试经理给出最终的决定，如果仍然存在争议，可通过公司政策所提供的渠道，向上级反映，并由上级做出决定。
3.给你一个网站，你如何测试？
1.首先找出需求说明、网站设计说明等文档，分析测试需求；
2.制定测试计划，来确定测试范围和测试策略，一般包括以下几个部分：功能测试、性能测试、界面测试、兼容性测试、数据库测试、安全性测试；
3.设计测试用例：
功能性测试不限于以下几个方面：
链接测试，链接是否正常跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回；
提交功能的测试，多媒体元素是否可以正常加载和显示，多语言支持是否支持语言的选择等；
界面测试不限于以下几个方面：
界面是否风格美观统一；
页面布局是否合理、重点内容和热点内容是否突出；
控件是否正常使用；
对于必须但未安装的控件，是否有自动下载并安装的功能；
文字检查；
性能测试不限于以下几个方面：
压力测试（又称强度测试），在系统资源特别低的情况下运行软件系统的情况，目的是找到软件在哪里失效以及如何失效的地方；
负载测试，指数据在超负荷的环境下进行，程序是否能承担；
（负载测试通常描述一种特定类型的压力测试——逐步增加用户数量或用户请求来对系统（程序）进行加压。比如现实中有个系统提供在线查询服务，那我们从比较小的负载开始，逐渐增加模拟查询请求的数量或用户量， 直到系统响应时间超时，就是说的负载测试。这儿加压的类型必须是应用提供的服务类型，也就是工作负荷。
负载测试的目标是测试在一定负载情况下的系统性能（不关注稳定性，也就是说不关注长时间运行，只是得到不同负载下相关性能指标即可）；实际中我们常从比较小的负载开始，逐渐增加模拟用户的数量（增加负载）， 观察不同负载下应用程序响应时间、所耗资源，直到超时或关键资源耗尽，这就是所说的负载测试，它是测试系统的不同负载情况下的性能指标。
压力测试的目标是测试在一定的负载下系统长时间运行的稳定性，但是这个负载不一定是应用系统本身造成的。比如我们经常利用脚本或工具事先吃掉服务器的一部分cpu、内存或带宽等，创造出一定的负载环境并测试被测应用系统在此环境下的事物处理能力，响应时间等等。压力测试尤其关注大业务量情况下长时间运行系统性能的变化（例如是否反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复）；压力测试是测试系统的限制和故障恢复能力，它包括两种情况：
1.稳定性压力测试：在选定的压力值下，长时间持续运行。通过这类压力测试，可以考察各项性能指标是否在指定范围内，有无内存泄漏、有无功能性故障等；
2.破坏性压力测试：在稳定性压力测试中可能会出现一些问题，如系统性能明显降低，但很难暴露出其真实的原因。通过破坏性不断加压的手段，往往能快速造成系统的崩溃或让问题明显的暴露出来；
针对压力测试和负载测试的区别，打个比喻：
这儿有个服务员，对应咱们的应用系统吧。
压力测试，就是给这位服务器外部压力，比如长时间不让他休息，不给开工资等，看看服务员会不会开小差（无法及时响应请求），或者罢工（宕机）之类的。
负载测试就是在单位时间内逐步加大这位服务员的工作量，看看此服务员在不同的工作量下完成服务的速度和质量，从而了解到该服务员的工作能力。
压力测试和负载测试能够帮组我们了解到一个服务器的抗压能力和工作能力，当然也能帮我们评估一个系统或软件的性能瓶颈与质量。）
数据库测试，一般考虑连结性，对数据的存取操作，数据内容等验证问题。
兼容性测试：浏览器的兼容性、操作系统的兼容性、软件平台的兼容性、数据库的兼容性
安全性测试：基本的登录功能的检查；是否存在溢出错误，导致系统崩溃或权限泄露；相关开发语言的常见安全性问题检查例如SQL注入等；如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持。
开展测试，并记录缺陷，合理的安排测试进度提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。定期评审，对测试进行评估和总结，调整测试的内容。