@另维

文章目录理解那些性能指标概念响应时间 RT每秒事务数量 TPS每秒查询数 QPS每秒请求数 QPS吞吐量每秒点击数 HPS每秒 / 每分钟调用次数 CPS/CPM压力工具中的线程数和用户数与 TPS业务模型响应时间如何设置小结两个层面定义性能场景的需求指标：业务指标和技术指标。所有的技术指标都是在有业务场景的前提下制定的，而技术指标和业务指标之间也要有详细的换算过程。常见性能指标：理解那些性能指标概念响应时间 RTResponse Time。可以简单理解为：网络传输（请求）时间+服务器处理（

文章目录LoadRunner 的基本原理LoadRunner 的主要模块Virtual User GeneratorLoadRunner ControllerLoadRunner Analysis如何基于 LoadRunner 性能测试性能需求收集及负载计划制定录制并增强虚拟用户脚本识别被测应用使用的协议录制脚本完善录制得到的脚本验证脚本的正确性创建并定义性能测试场景执行性能测试场景分析测试报告LoadRunner 的基本原理后端性能测试工具通过虚拟用户脚本生成器生成基于协议的虚拟用户脚本，然后根据性能

移动端应用可以细分为三大类：Web App、Native App 和 Hybrid App。以下主要介绍这三类移动应用的测试方法，以及移动专项测试的思路与方法。文章目录三类移动应用的特点三类不同移动应用的测试方法移动应用专项测试的思路和方法交叉事件测试兼容性测试流量测试耗电量测试弱网络测试边界测试总结三类移动应用的特点Web App 指的是移动端的 Web 浏览器，和 pc 端的 Web 浏览器无差，只是依附的操作系统不再是 Windows 或 Linux了，而是 IOS 和 Android。Web

文章目录常用的七种性能测试方法后端性能测试前端性能测试代码级性能测试压力测试配置测试并发测试可靠性测试性能测试的四大应用领域能力验证能力规划性能调优缺陷发现小结常用的七种性能测试方法根据实际项目经验可以分为以下七种，接着我们来详述每一种。后端性能测试其实我们平时听到的性能测试大多指后端性能测试，也就是服务器性能测试。是通过性能测试工具模拟大量的并发用户请求，然后获取系统性能的各项指标，并且验证各项指标是否符合预期的性能需求的测试手段。这里的性能指标，除了包括并发用户数、响应时间和系统吞吐量外，还应

对软件性能最普遍的理解就是软件处理的及时性。但其实，从不同的系统类型，以及不同的视角去讨论软件性能，都会有所区别。文章目录不同类型的系统，软件性能的关注点各不相同中断用户严重的软件性能运维人员严重的软件性能软件设计开发人员眼中的软件性能算法设计包含的点：架构设计包含的内容性能最佳实践包括地点数据库相关地点软件性能的可测试性包含的点性能测试人员眼中的软件性能衡量软件性能的指标并发用户数响应时间系统吞吐量不同类型的系统，软件性能的关注点各不相同Web 类应用和手机端应用，一般以终端用户感受到的端到端的响

文章目录需求覆盖率代码覆盖率最常用的三种代码覆盖率指标代码覆盖率的价值代码覆盖率的局限性代码覆盖率工具代码覆盖率工具的实现原理小结从广义角度讲，测试覆盖率主要分为两大类，一类是面像项目于的需求覆盖率，另一类是更偏向技术的代码覆盖率。需求覆盖率测试对需求的覆盖程度，通常是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以把证软件产品的质量。我们通常采用 ALM，Doors 和 TestLink 等需求管理工具来建立需求和测试的对应关系，并以此计算测试覆盖率

什么是自动化、为什么自动化测试自动化测试的本质是先写一段代码，然后去测试另一段代码为什么自动化？优势？自动化测试可以替代大量的手工机械重复性操作，测试工程师可以把更多的时间花在更全面的用例设计和新功能的测试上；自动化测试可以大幅提升回归测试的效率，非常适合敏捷开发过程；自动化测试可以更好地利用无人值守时间，去更频繁地执行测试，特别适合现在非工作时间执行测试，工作时间分析失败用例的工作模式；自动化测试可以高效实现某些手工测试无法完成或者代价巨大的测试类型，比如关键业务 7×24 小时持续运行的系统

什么是单测，如何做好单测单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类。单元测试都是以自动化的方式执行，所以在大量回归测试的场景下更能带来高收益。单元测试的对象是代码，以及代码的基本特征和产生错误的原因，然后你必须掌握单元测试的基本方法和主要技术手段，比如什么是驱动代码、桩代码和 Mock 代码等。第一，代码的基本特征与产生错误的原因要做到代码功能逻辑正确，必须做到分类正确并且完备无遗漏，同时每个分类的处理逻辑必须正确

利用对需求的理解、严密的逻辑推理能力，迅速找出软件中的潜在缺陷，并以缺陷报告的形式递交给开发团队，是与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。开发工程师可以根据缺陷报告快速理解缺陷，并精确定位问题。同时，通过这个缺陷报告，开发经理可以准确预估缺陷修复的优先级、产品经理可以了解缺陷对用户或业务的影响以及严重性。虽然软件企业通常都有缺陷管理系统，比如典型的 ALM（以前的 Quality Center）、JIRA、Bugzilla、BugFree 和 Mantis 等。当使用这类系统递

为个人博客项目的用户登录设计测试用例的过程中，让我发觉用例是越写越多，更多的用例覆盖率会越高，但是也慢慢发现这可能是一个没有穷尽的测试，同时测试的周期或长。衡量下来什么才算是好的测试用例？特此贴上用例设计的链接什么才算好的测试用例通常，第一反应可能会是“发现了软件缺陷的测试用例就是好的用例”，那“如果说测试用例发现了缺陷就是好用例，那么在该缺陷被修复后，同样的用例难道就不是好用例了吗？”。可能我们还会说“发现软件缺陷可能性大的测试用例就是好用例”，这话还是蛮有道理的，“又该用什么方法来量化测试用例发

以上登录仅仅考虑的时网页中登录的部分情况。关于 APP 登录测试1、登录失败后二次登录（1）输入正确的用户名，不输入密码，点击登录；登录失败后，再次输入正确的密码登录并观察登录情况（2）输入正确的用户名和错误的密码登录失败后，再次输入正确的密码登录并观察登录情况（3）输入未注册的用户和任意密码登录失败后，再次输入正确的用户名和密码，观察登录情况2、修改密码后（1）修改完密码后是否重定向到登录界面（2）修改完密码后，分别使用原密码和新密码登录（3）在其他终端修改密码后，本终端是否自动下线？下.

文章目录软件开发的模型软件测试的模型软件的生命周期：从产品设想到不再使用而结束的时间，可以分为 6 个阶段：需求分析、计划、设计、编码、测试、运行和维护软件开发的模型✅瀑布模型（Waterfall Model）其他模型的基础框架，每个阶段只执行一次，是先行顺序进行的开发模型优点：强调开发的阶段性、早期计划和需求调查、强调产品测试缺点：不能适应变化的需求，由于单一流程风险性往往推迟至后期测试才显露✅螺旋模型（Spiral Model）开发初期需求不很明确的渐进式的开发，适用于规模大复杂度